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 tony@xxxxxxx John C Klensin wrote: > > --On Tuesday, May 12, 2009 11:24 -0700 Bill McQuillan > <McQuilWP@xxxxxxxxx> 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. >> >> OTOH, maybe that WAS the intent of the charter. > > 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 _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf