ietf
[Top] [All Lists]

Re: draft-housley-two-maturity-levels-00

2010-06-20 05:01:15
At 23:10 19-06-10, Dave CROCKER wrote:
Thanks for reviving this topic. As the YAM working group has been finding, trying to elevate even the most well-established and widely-used protocols to Full standard remains problematic.

It is problematic because there isn't any consensus on what an Internet Standard is and the requirements to attain that level of maturity.

In Section 2 of draft-housley-two-maturity-levels-00:

  "The requirements for Proposed Standard are unchanged; they remain
   exactly as specified in RFC 2026."

Quoting Section 4.1.1 of RFC 2026:

  "A Proposed Standard specification is generally stable, has resolved
   known design choices, is believed to be well-understood, has received
   significant community review, and appears to enjoy enough community
   interest to be considered valuable.  However, further experience
   might result in a change or even retraction of the specification
   before it advances.

   Usually, neither implementation nor operational experience is
   required for the designation of a specification as a Proposed
   Standard.  However, such experience is highly desirable, and will
   usually represent a strong argument in favor of a Proposed Standard
   designation."

The reader will note that neither implementation nor operational experience is required. In practice, the IESG does "require implementation and/or operational experience prior to granting Proposed Standard status". Implementors do not treat Proposed Standards as immature specifications.

This proposal removes Draft Standard and Internet Standard and replaces it with Interoperable Standard. I won't quibble over the choice of the name yet. In Section 5:

  'The requirement for six months between "Proposed Standard" and
   "Interoperable Standard" is removed.  If an interoperability report
   is provided with the initial protocol action request, then the
   document can be approved directly at the Interoperable Standard
   maturity level without first being approved at the Proposed Standard
   maturity level.'

What this proposal advocates is in effect having one level of maturity, i.e. turning the Proposed Standard into Standard".

  "In practice the annual review of Proposed Standard documents after
   two years has not taken place.  Lack of this review has not revealed
   any ill effects on the Internet Standards Process."

There seems to be a confusion between the Internet Standards Process and the Internet Standards Track. An over-simplified view of the process is that it is about publishing RFCs. Documents are published once one can get through the DISCUSSes raised by the IESG and simply forgotten. As the IESG does not conduct the review of Proposed Standard documents, the authors are happy and the IETF Community does not complain as it has either forgotten or doesn't know that there should have been such a review.

If the IETF only needs a publishing mechanism, it could adopt this proposal as-is and do away with the IESG. I'll note that the IESG is supposed to make its final determination known in a timely fashion. The overall processing time currently is approximately 250 days.

In Section 6:

  'The current rule prohibiting "down references" is a major cause
   of stagnation in the advancement of documents.'

There isn't any current rule that prohibits "down references". The reason for discouraging downward references is to have the specification at the same maturity level. "Downward reference by annotation" can still be used. That allows the community to balance the importance of getting a document published.

In Section 7:

  "In several situations, a Standard is obsoleted by a Proposed Standard"

A Standard is not obsoleted by a Proposed Standard. A RFC with a status of Internet Standard can be obsoleted by a RFC at Proposed Standard.

In Section 8:

  "On the day these changes are published as a BCP, all existing Draft
   Standard and Standard documents automatically get reclassified as
   Interoperable Standard documents"

One of the benefits of doing this is that the IP Version 6 Addressing Architecture can be recognized as a "Standard" for whatever definition of standard this community finds suitable.

In the Acknowledgements Section:

  "In May 2010, the IESG discussed the topic at length and came to the
   conclusion that the current situation was becoming more and more
   difficult."

The current situation would certainly become more and more difficult if a particular charter is invoked.

This document has RFC 2606 as an Informative Reference. That should at the very least be a Normative Reference.

Regards,
-sm
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf