As Promised, an attempt at 2026bis

[Eliot Lear <[e-mail]>]

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 mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf