Subject: Re: WG Review: Yet Another Mail (yam)

From: Bill McQuillan <[email-masked]>
Date: Tue, 12 May 2009 11:24:33 -0700

> If an existing protocol implementation is conforming to the Draft Standard
> version of the protocol specification, it must also be conforming to the
> resulting Full Standard version. Hence, specification changes that
> create a violation of this requirement are out of scope of the working
> group charter.

This part of the charter worries me. It presumes that no Draft Standard can
be ambiguous!

On the off chance that a Draft Standard *is* ambiguous in some way that has
caused two implementations to be non-interoperable, but arguably
conforming, it seems that the WG must drop the Standard from consideration
without any chance of some engineering judgement (or even horse-trading) to
get the implementations to become interoperable and to resolve the
ambiguity.

OTOH, maybe that WAS the intent of the charter.

-- 
Bill McQuillan <[email-masked]>

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 12 May 2009 11:35:07 -0700

Bill,

The language in the draft charter is meant to constrain what kinds of changes 
can be made to a specification by YAM.  Specifically, when moving a spec from 
Draft to Full, any changes MUST NOT be of the type that make a a conforming 
implementation suddenly become non-conforming.  In other words, whatever is 
deemed conforming for Draft MUST still be conforming for Full.

That "deemed conforming" can sometimes be a judgment call is certainly true, but 
I don't see how that changes the nature of the constraint being offered here.

If there is language that you would find more workable for the goal I've cited, 
suggest away!

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: John C Klensin <[email-masked]>
Date: Tue, 12 May 2009 14:36:47 -0400

--On Tuesday, May 12, 2009 11:24 -0700 Bill McQuillan
<[email-masked]> wrote:

>> If an existing protocol implementation is conforming to the
>> Draft Standard version of the protocol specification, it must
>> also be conforming to the resulting Full Standard version.
>> Hence, specification changes that create a violation of this
>> requirement are out of scope of the working group charter.
> 
> This part of the charter worries me. It presumes that no Draft
> Standard can be ambiguous!
> 
> On the off chance that a Draft Standard *is* ambiguous in some
> way that has caused two implementations to be
> non-interoperable, but arguably conforming, it seems that the
> WG must drop the Standard from consideration without any
> chance of some engineering judgement (or even horse-trading) to
> get the implementations to become interoperable and to resolve
> the ambiguity.
> 

As I have understood it, the intent was to move what can be
moved without controversy and then to come back, with a
recharter, and figure out what, if anything, should be done
next.  So, if the case you describe is detected, that
specification would not be a YAM candidate, at least under the
initial charter.

    john

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 12 May 2009 14:39:39 -0400

On Tue, May 12, 2009 at 11:35:07AM -0700, Dave CROCKER wrote:

> changes can be made to a specification by YAM.  Specifically, when moving 
> a spec from Draft to Full, any changes MUST NOT be of the type that make 
> a a conforming implementation suddenly become non-conforming.

Does this mean that if a Draft Standard really is ambiguous, and
different implementations have different interpretations that turn out
to be non-interoperable, YAM won't be allowed to pick one and say,
"This is what it meant"?  (I think this is what the original concern
being raised was.  Anyway, it seems like a less-than-ideal rule to
me.)

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 12 May 2009 14:45:49 -0400

> being raised was.  Anyway, it seems like a less-than-ideal rule to

Never mind.  John Klensin's response at the same time explained the
plan to me.  Sorry for the noise.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Tony Hansen <[email-masked]>
Date: Tue, 12 May 2009 15:54:35 -0400

I just wanted to reinforce what John is saying. Step 1 of the charter
for all RFCs being considered by YAM is a review. The output of that
review 1) may indicate that it's completely ready for immediate
advancement to Full Standard, or 2) it may indicate that it's NOT ready
for immediate advancement to Full Standard, possibly for the very
reasons you brought up or for various other reasons that indicate that
it's not ready for prime time. If #2 is discovered, the YAM WG will make
a recommendation as to what needs to be done to the document, and the
document would be removed from further consideration by YAM.

What happens to the document outside of YAM at that point is not the
direct concern of YAM itself. It's even conceivable that someone outside
of the YAM framework may choose to work on the document in parallel to
YAM. Or when YAM's initial charter is concluded, the YAM WG may
recharter to then reconsider those documents it chose not to immediately
advance.

	Tony Hansen
	[email-masked]