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