Please find in draft-lear-ietf-rfc2026bis-00.txt a preliminary revision
of, well, RFC 2026. It contains the following changes:
1. A new two step process for standardization where the second step
is optional. In other words, you get an STD # at the first step.
This is a bit of compromise position. The idea is to reflect
reality of the existing ONE STEP process but allow that some might
wish to indicate that a standard is indeed more mature.
2. A suggested mapping from PS/DS/IS is included.
3. A request is made for appropriate relabelling.
4. There is no mandatory timeline for the IESG to reconsider
standards on that first step, but they may do so in a manner of
their choosing after the two year mark.
5. Intellectual Property considerations have been removed and now
reference BCPs 78 and 79. These documents have changed several
times and I imagine will evolve again. There should be no need to
rev or update 2026bis based on such changes.
6. RFC 2026 actually says that one needn't submit an Internet-Draft
in order for the RFC Editor to consider publishing an independent
submission, but it DOES say that if you submit just a text the
Editor will create an Internet Draft. We've changed that so all
RFCs should first be Internet Drafts.
7. Some examples are updated to refer to more relevant standards
(e.g., Goodbye, DECNET).
There are other modest changes. At this point in time, Scott Bradner
and I solicit community input. While discussion on the IETF main list
might be a good starting point, if it seems to go on for some period of
time, we will find another list for this purpose. If we find
substantial support, we will ask the IESG to advance the document.
Scott and I argue that 2026 must be revised and not merely updated
because standards maturity issues are splattered across 2026.
There are a few known problems with the draft:
* Currently the new maturity levels are Level 1 and Level 2. The
problem with this is that if someone in the future for some reason
wants to try a three step process, there's no room for another
level. We'll come up with schnazzier names (your suggestions
welcome - perhaps we could have a name that standard standard
contest ;-).
* As currently written the document does not specify how to handle
the case when one is updating a mature version of a standard with
an immature version. Take for example RFCs 82[12] and 28[12]. I
have some ideas as to how to handle this case, but your comments
are most welcome.
* There is a typo in the draft- my intention was for L2 standards to
require two interoperable implementations, not three.
* The Acknowledgment section needs updating already. Mike O'Dell
first and Fred Baker later have espoused ideas that come close to
this, Ran Atkinson advised a similar proposal this year, and Scott
Brim has spotted some existing problems.
If you would like a set of imperfect contextual diffs, you can find them
at http://www.ofcourseimright.com/pages/lear/2026bisdiffs.txt.
Regards,
Eliot
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf