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