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@xxxxxxxx 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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf