At 07:02 PM 7/27/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-08.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-08-24. Exceptionally, comments
may be
From Section 2.1:
"no existing published requirements are relaxed".
Are these published requirements BCPs?
From Section 2.2:
'This maturity level is a merger of Draft Standard and Standard as
specified in RFC 2026 [1]. The chosen name avoids confusion between
"Draft Standard" and "Internet-Draft".'
Shouldn't that be "Internet Standard" instead of "Standard"?
"The request for reclassification is sent to the IESG along with an
explanation of how the criteria have been met.
The criteria are:
(1) There are at least two independent interoperating implementations
with widespread deployment and successful operational experience.
(2) There are no errata against the specification that would cause a
new implementation to fail to interoperate with deployed ones.
(3) There are no unused features in the specification that greatly
increase implementation complexity."
The document that has been the subject of innumerable messages
highlights how difficult it can be to reclassify a RFC. Moreover, it
amplified the divide between application folks and operators. The
IESG could have used the review clause from RFC 2026 and:
(i) requested an implementation report from the people in favor of the
proposed standard; and
(ii) a statement about deployment to determine whether there are operational
issues that have to be addressed.
I don't know whether application folks and operators agree that
cross-area requires mutual understanding.
The creation of interoperable protocol implementations requires clear
specifications. Interoperability does not mean that the protocol
would not have unintended effects on the network. That is where
operational experience comes in. It can serve as valuable input to
improve a specification. For what it is worth, there approximately
75 implementation reports have been submitted since 1996.
A two-step maturity level folds the two different classes of issues
into one. Quoting RFC 5657, which this draft unfortunately does not reference:
"Moving documents along the standards track can be an important signal
to the user and implementor communities, and the process of
submitting a standard for advancement can help improve that standard
or the quality of implementations that participate."
During a discussion on another mailing list, it has been mentioned
that such an effort has a cost. Lumping all the issues together can
only increase that cost.
Strangely, this draft argues for measuring "interoperability through
widespread deployment of multiple implementations from different code
bases". It will be more difficult to remove features once
implementations are widely deployed. Keeping the feature fight
within the Draft Standard discussion can reduce the level of
controversy at the last step. As a side note, it would be less
costly if feature evaluation was based on implementations instead of
what people would like to keep (only one implementation of a feature).
Once a Proposed Standard is published, it is expected that people
will go and write code, if they have not done so yet, and evaluate
whether their implementation can interoperate with other
implementations. I don't see anything in this draft that encourages that.
In the RFC 5000 range, there are 7 Internet Standards, 13 Draft
Standards and 537 Proposed Standards. One of the arguments for this
draft is that it reduces the number of IESG evaluations, and other
review cycles, from three to two. Basically, this draft is to adjust
the environment so that the IESG can review everything. It does not
reduce the barrier of "intended proposed standards" to the RFC 2026
level. It does not offer any incentive to advance document along the
Standards Track.
I unfortunately cannot support this draft.
Regards,
-sm
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf