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/
Bill McQuillan 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.
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf