Re: netwrk stuff

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Jul 21, 2006, at 8:27 AM, Dave Crocker wrote:

David Harrington wrote:
Why not start everything at Experimental, and if it gains market success then it moves to Full.

why not make the smallest change we can, rather than alter the existing, basic mechanism for entering standards track (and, for that matter, why not preserve the use of labels that already have a valid role)?

It is fortunate from both a support and review standpoint, few RFCs are stand alone. The discussion within DKIM WG lead to a declaration that RFC282x is the "supported" standard. Clearly these labels do _not_ play a valid role when designating what is current, supported, or stable. Efforts aimed at inuring labels with greater significance though formulaic time constraints or surveillance of use seems misguided and ultimately futile.

Imagine that a reference document email.3 defines a set of RFCs. Attempting to impose a level of compliance, acceptance, or endurance upon each RFC individually increases the administrative burden and ultimately leads to confusion when a set includes RFCs at different levels of assessment. It is fairly common to see a composite of libraries, kernels, and applications be defined as either Current or Stable. Those wanting to use these amalgams in a production environment normally select the set designated as Stable. Those developing a new product would likely use the Current set.

While the IESG or the IETF may attempt to dub which sets are Current or Stable, the system would be better served with a scheme that offers a serialized set. The DKIM WG could declare that email.3 is considered Stable and supported by their effort. When combined with the WG drafts, the new set could become email.4 Current. Let those building systems and testing interchange make the determination when email.4 can be considered Stable and when email.2 is considered Obsolete. It seems unlikely that the IETF would want to venture into conformance testing or run deployment surveys.

The labels that seem to have value are those that indicate how the authors of the RFC expect the information to be used, such as Guidance, Experimental, Core, or Extension. While the current structure attempts to offer what is obsoleted or updated by a draft, this really only indicates what might be considered Current and not what is actually Obsolete or "Historic". It is painful for everyone to track what is being modified and what represents Current and which of the previous Currents represent Stable. By having a reference of email.n, then just the number changes and keeping track of these changes becomes much simpler. Fewer changes go unnoticed and these should receive better review. The IETF becomes more productive. RFQs make a simpler reference to what is desired. This would even allow a prediction of the reference yet to be completed.

There is a draft that better describes this at:
http://www.sonic.net/~dougotis/newtrk/

-Doug



_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]