> >Without commenting specifically on whether 1.1 is ready for
> >the standards track (since I haven't reviewed it), I do want
> >to direct attention to the language in RFC 2026 describing the
> >criteria for Proposed Standard. In particular, note that
> >"neither implementation nor operational experience is required"
> >but there should be "no known technical omissions".
>> Nor does the document preclude waiting for operational experience.
>> Sane men often "exceed requirements" to insure the right thing is
> being done.
Apparently sane people often use the same words to mean different
things, with the result that they cannot understand each other.
Some people think "Proposed Standard" should apply to whatever
a working group comes up with, whether or not it has known technical
omissions. Others think that the term gives them the blessing to
ship products and will strongly object to changing a Proposed
Standard - even if the change is needed - if it would cause their
products to fail to interoperate with the revised standard.
My point is that we have a definition of the words "Proposed Standard"
in RFC 2026. The purpose of the definition is to help people understand
what it means when IETF calls something a Proposed Standard.
(I've often thought we should change the names - in particular
it's easy to get the idea that Proposed is more mature than Draft.)
If the IPP group wants to wait awhile before asking IESG to approve 1.1
as a Proposed Standard, that's up to the IPP group. I just don't
want it to do so based on misconceptions about what the term means.
Keith