My perception is that often in the IETF, protocol and process design
works best that codifies and regularizes what is already being deployed.
The model that seems to be emerging is that we now have a lot of
revisions of first-generation protocols, with the recent slew of LDAP
announcements as one example. They are typically marked as
'rfc1234bis'; the I-D database currently lists around 85 of these
drafts as being active. The act of revising an earlier RFC presumably
indicates that there is sufficient community interest in the
technology and that this is maintenance based on implementation
experience rather than a new protocol development.
By default, declaring that '*bis' efforts are the second level of
maturity unless there is an objection during last call would be
sufficient to differentiate them from first, largely pre-
implementation specs. (Naturally, RFCs that were perfect on first try
could get petitioned into the second maturity level, with a simple
method of collecting support from N independent parties, convincing
and AD and based on a last call.)
I don't see why the grouping/labeling of RFCs can't proceed in
parallel, but in a different group. This seems much more mechanical
and tools-oriented and could probably be done more readily on an
experimental basis. If whatever mechanism is chosen doesn't work out,
we can phase it out or supplement it with something else. Such
experimentation seems harder to do, without major confusion, for
standards maturity levels.
On Jun 10, 2006, at 3:17 AM, Brian E Carpenter wrote:
I invite the IETF community to read this draft and discuss the choices
it suggests, between now and the Montreal IETF.
Brian
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf