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(_at_)att(_dot_)com
John C Klensin wrote:
--On Tuesday, May 12, 2009 11:24 -0700 Bill McQuillan
<McQuilWP(_at_)pobox(_dot_)com> 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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf