ietf
[Top] [All Lists]

Re: Last Call: <draft-housley-two-maturity-levels-06.txt> (Reducing the Standards Track to Two Maturity Levels) to BCP

2011-05-08 01:03:53
At 09:13 05-05-2011, The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'Reducing the Standards Track to Two Maturity Levels'
  <draft-housley-two-maturity-levels-06.txt> as a BCP

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf(_at_)ietf(_dot_)org mailing lists by 2011-06-02. Exceptionally, comments 
may be

From Section 1:

  "This document proposes several changes to the Internet Standards
   Process defined in RFC 2026 [1].  In recent years, the Internet
   Engineering Task Force (IETF) has witnessed difficulty in advancing
   documents through the maturity levels: Proposed Standard, Draft
   Standard, and finally Standard.  These changes are designed to
   simplify the IETF Standards Process and reduce impediments to
   standards progression while preserving the most important benefits of
   the IETF engineering approach."

There is a documented case where the difficulty occurred at the IESG level. I could not find anything in draft-housley-two-maturity-levels-06 to reduce that impediment.

  "In addition, IETF working groups and IESG members provide much
   more scrutiny than is called for by RFC 2026 [1] prior to
   publication as Proposed Standard."

As much as I would like to use the IESG as a scapegoat, the reality is that IETF working groups also work briskly to on impediments. Section 4 mentions that "the rules that prohibit references to documents at lower maturity levels are a major cause of stagnation in the advancement of documents". I beg to disagree. Quoting RFC 4897:

  "With appropriate community review, the IESG may establish procedures
   for when normative downward references should delay a document and
   when downward references should be noted."

There is an IESG statement [1] about that. I'll highlight the following sentence:

  "Normative references specify documents that must be read to
   understand or implement the technology in the new RFC, or
   whose technology must be present for the technology in the
   new RFC to work."

Quoting RFC 2026:

  "Standards track specifications normally must not depend on
   other standards track specifications which are at a lower maturity
   level or on non standards track specifications other than referenced
   specifications from other standards bodies."

Let's take a document moving to Draft Standard as an example. When we talk about "down-ref", it is the maturity that is the issue. What it means, in my opinion, is that the referenced (normative) Proposed Standard can be changed in ways which affect the stability of the "Draft Standard" document. An implementation that is compliant with the Draft Standard may end up being incompliant overnight as the group that worked on the referenced Proposed Standard found some good reason for adding some requirements. Having down-refs on the "No Fly" list can be an impediment. By explicitly calling out the down-ref during a Last Call, the IETF offers a means to evaluate whether the document can live with the down-ref.

I commented a week ago on the down-refs in RFC 5953 which is being advanced to Draft Standard. One of the down-refs could be fixed easily. Another one could be addressed with some rewording. Sometimes, such a change is not possible. In a distant future, the IETF community might come to terms with the notion that down-refs are not evil.

From Section 2:

  "Note that the distinct requirement from RFC 2026 [1] for reports of
   interoperability testing among two or more independent
   implementations is intentionally subsumed by the requirement for
   actual deployment and use of independent and interoperable
   implementations."

This draft conflates interoperability and deployment. Having a two-track level sounds reasonable at first glance. My garden variety protocol might qualify for "Internet Standard" now that wide-spread deployment has been watered down to actual deployment.

From the same section:

  "The Last Call is intended to identify unused portions of the
   specification that greatly increase implementation complexity
   without burdensome implementation testing and documentation."

That sounds like a good idea. I would strongly support the removal of all the key words that are literally sprinkled in specifications nowadays. It is always a good idea to kill the pet peeve that you strong-armed the editor into adding through "consensus by exhaustion". But identifying the unused portions of the specification tends to reopen old wounds.

Going back to Section 1:

  "One desired outcome is to provide an environment where the
   IETF community is able to publish Proposed Standards as soon as rough
   consensus is achieved."

That can mean reviewing how IESG evaluation is carried out. If you want to provide such an environment, one possible step is to remove DISCUSSes at Proposed Standard level and have the IESG only use rough consensus as a measure of whether a document can be published or not.

Consensus is a double-edged sword. Let's assume that a group of well-known vendors implement a specification and people who do not have an existing implementation oppose the proposal. Should the IETF ignore the latter and allow publication? That is a question which I would like not to answer because it puts fairness into question. RFC 5657 offers a path out of the quagmire by highlighting the need for interoperability.

Section 3 mentions that:

  "Lack of this review has not revealed any ill effects on the
   Internet Standards Process."

I strongly object to that statement. If there aren't any ill effects, why is there a Last Call for this proposal? If the IESG did not perform more scrutiny than intended, would we have seen more proposals at Draft Standard?

Instead of removing the annual review, it would be better to set a sell-by date for documents at Proposed Standard. The IETF can then leave it to one or more advocates to make a convincing argument that the specification meets the multiple implementation and feature support requirements of the IETF Standards Process. The implementation report is a measure of whether specifications are actually being implemented.

A RFC misses its objective if only the working group participants understand how to implement the specification. The text in a RFC is only clear if someone out there can read the document and turn it into running code which can interoperate.

From Section 6:

  "In several situations, an RFC that has reached the full Standard
   maturity level has been obsoleted by a RFC at Proposed Standard
   maturity level, causing great confusion about which specification
   ought to be implemented."

Some people still refer to STD 10, well, the RFC number. Most people refer to its revision even though that version has been obsoleted ten years ago.

A Draft Standard can be viewed as a contract. It specifies that the specification is stable. If the IETF working group decides to do some gross rewriting of the document, they are gently reminded that the document will be slapped with a Proposed Standard label instead of qualifying for Internet Standard. The final level is a test of time. That's where the IETF says that the widespread deployment of the technology did not bring down the Internet.

In Section 1:

  "A specification shall remain at the Proposed Standard maturity level
   for at least six (6) months before consideration for advancement to
   the Internet Standard maturity level.  The six months begins when the
   RFC is published."

As a specification is obviously a RFC, it is redundant to specify when the clock begins.

Is six months enough to assess the maturity of a specification? If it is a move from Proposed Standard to Draft Standard, that may be a workable minimum. But that is way too short for widespread deployment experience.

The draft-housley-two-maturity-levels-06 effort is a good thing. I commend the authors for that. I unfortunately have to give it a "Do Not Publish" rating as it misses the mark.

Regards,
-sm

1. http://www.ietf.org/iesg/statement/normative-informative.html
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf