Overall, I'd suggest that the goal should be to merely recognize and
document the maturity levels that already exist in practice, not to change
them.
My understanding is that the process for advancing from Experimental to
Proposed today largely involves review of implementation experience (e.g.
the results of the "experiment"), and in Transport, a demonstration that the
proposal is not catastrophic to the Internet. Sometimes the changes
required can be substantial (e.g. changes made in EAP going from RFC 2284 to
3748, and in SIP going from 2543 to 3261), but I don't think this should
hinder advancement to Proposed. Problems in interoperability are often
addressed in "bis" documents, so we shouldn't require a detailed interop
assessment either (that's for Draft level). I can imagine blocking
advancement of a "bis" to Proposed in only a limited number of situations,
such as where there was no implementation experience. Today "recycling at
Experimental" is pretty rare -- if there is motivation for a "bis" typically
this implies that there was interest/usefulness.
From: Yoav Nir [mailto:ynir(_at_)checkpoint(_dot_)com]
Sent: Tuesday, June 22, 2010 1:00 AM
To: Bernard Aboba
Cc: ietf(_at_)ietf(_dot_)org
Subject: Re: draft-housley-two-maturity-levels-00
I like this proposal, but there should be a (relatively) easy process to
advance from Experimental to Proposed, especially if implementation
experience shows no need for bits-on-the-wire changes.
We should be able to say that for a particular experimental RFC there have
been this many independent implementation, and they interoperate OK, and
only so-and-so clarifications need to be added, and the document is ready
for "Proposed".
On Jun 21, 2010, at 9:09 PM, Bernard Aboba wrote:
Russ,
I'd also like to think you for revisiting this topic.
I support the recommendation to eliminate the "Standard" maturity level, and
also agree with your recommendation on Maturity Level 2 (similar to Draft
Standard).
We need more thought on what to do with the other levels though.
In practice, we often see a document initial go to Proposed Standard, then
go through a "bis" to enable clarifications and interop improvements.
Often these changes are too substantial to enable advancement to Draft, but
they nevertheless represent an important advancement in status.
I'd like to see some way that this advancement can be recognized formally.
Also, in some areas (e.g. Transport) the first stage is publication of an
Experimental RFC. These documents are published with the understanding that
implementation experience will be incorporated into a future revision.
So perhaps the hierarchy should be:
a. Experimental.
b. Proposed Standard (e.g. a "bis").
c. Interoperable Standard/Draft Standard.
<ATT00001..txt>
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf