Skip to main content

Changes to the Internet Standards Process defined by RFC 2026
draft-carpenter-rfc2026-changes-02

Revision differences

Document history

Date Rev. By Action
2015-10-14
02 (System) Notify list changed from brian.e.carpenter@gmail.com to (None)
2008-07-27
02 (System) State Changes to Dead from AD is watching by system
2008-07-27
02 (System) Document has expired
2008-02-18
02 Russ Housley State Changes to AD is watching from Waiting for AD Go-Ahead by Russ Housley
2008-02-18
02 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2008-02-06
02 Amanda Baber IANA Last Call comments:

As described in the IANA Considerations section, we understand this document
to have NO IANA Actions.
2008-01-30
02 Samuel Weiler Request for Last Call review by SECDIR is assigned to Susan Thomson
2008-01-30
02 Samuel Weiler Request for Last Call review by SECDIR is assigned to Susan Thomson
2008-01-21
02 Amy Vezza Last call sent
2008-01-21
02 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2008-01-18
02 Russ Housley State Changes to Last Call Requested from AD Evaluation::AD Followup by Russ Housley
2008-01-18
02 Russ Housley Last Call was requested by Russ Housley
2008-01-18
02 (System) Ballot writeup text was added
2008-01-18
02 (System) Last call text was added
2008-01-18
02 (System) Ballot approval text was added
2008-01-18
02 Russ Housley Intended Status has been changed to BCP from Informational
2008-01-18
02 Russ Housley
  (1.a)  Who is the Document Shepherd for this document? 

      Russ Housley

  (1.b)  Has the document had adequate review both from …
  (1.a)  Who is the Document Shepherd for this document? 

      Russ Housley

  (1.b)  Has the document had adequate review both from key members of
      the interested community and others?  Does the Document Shepherd
      have any concerns about the depth or breadth of the reviews that
      have been performed?

      It has had some discussion on ietf@ietf.org.  The IETF Last Call
      on this document will clearly cause more.

  (1.c)  Does the Document Shepherd have concerns that the document
      needs more review from a particular or broader perspective, e.g.,
      security, operational complexity, someone familiar with AAA,
      internationalization or XML?

      No

  (1.d)  Does the Document Shepherd have any specific concerns or
      issues with this document that the Responsible Area Director
      and/or the IESG should be aware of?  For example, perhaps he or
      she is uncomfortable with certain parts of the document, or has
      concerns whether there really is a need for it.  In any event, if
      the interested community has discussed those issues and has
      indicated that it still wishes to advance the document, detail
      those concerns here.

      No

  (1.e)  How solid is the consensus of the interested community behind
      this document?  Does it represent the strong concurrence of a few
      individuals, with others being silent, or does the interested
      community as a whole understand and agree with it?

      Since this document did not come from a WG, IETF Last Call is
      needed to determine consensus.

  (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
      discontent?  If so, please summarise the areas of conflict in
      separate email messages to the Responsible Area Director.  (It
      should be in a separate email because this questionnaire is
      entered into the ID Tracker.)

      No

  (1.g)  Has the Document Shepherd personally verified that the
      document satisfies all ID nits?  (See
      http://www.ietf.org/ID-Checklist.html and
      http://tools.ietf.org/tools/idnits/).  Boilerplate checks are not
      enough; this check needs to be thorough.  Has the document met all
      formal review criteria it needs to, such as the MIB Doctor, media
      type and URI type reviews?

      OK

  (1.h)  Has the document split its references into normative and
      informative?  Are there normative references to documents that are
      not ready for advancement or are otherwise in an unclear state?
      If such normative references exist, what is the strategy for their
      completion?  Are there normative references that are downward
      references, as described in [RFC3967]?  If so, list these downward
      references to support the Area Director in the Last Call procedure
      for them [RFC3967].

      OK

  (1.i)  Has the Document Shepherd verified that the document IANA
      consideration section exists and is consistent with the body of
      the document?  If the document specifies protocol extensions, are
      reservations requested in appropriate IANA registries?  Are the
      IANA registries clearly identified?  If the document creates a new
      registry, does it define the proposed initial contents of the
      registry and an allocation procedure for future registrations?
      Does it suggested a reasonable name for the new registry?  See
      [I-D.narten-iana-considerations-rfc2434bis].  If the document
      describes an Expert Review process has Shepherd conferred with the
      Responsible Area Director so that the IESG can appoint the needed
      Expert during the IESG Evaluation?

      OK

  (1.j)  Has the Document Shepherd verified that sections of the
      document that are written in a formal language, such as XML code,
      BNF rules, MIB definitions, etc., validate correctly in an
      automated checker?

      N/A

  (1.k)  The IESG approval announcement includes a Document
      Announcement Write-Up.  Please provide such a Document
      Announcement Writeup?  Recent examples can be found in the
      "Action" announcements for approved documents.  The approval
      announcement contains the following sections:

      Technical Summary

        This document defines a number of changes to RFC 2026, the basic
        definition of the IETF standards process.  While some of them are
        definite changes to the rules, the intention is to preserve the main
        intent of the original rules, while adapting them to experience and
        current practice. RFC 2026 has been in force since 1996, and has proved
        robust and adequately flexible for the main part.  However, some
        provisions have led to practical difficulties or lack clarity.  The
        changes defined here are intended to tackle those issues.

      Working Group Summary

        There was a major attempt at updating the standards process by the
        NEWTRK WG several years ago, and by other non-WG efforts. These
        efforts have failed to reach any kind of consensus. This document
        aims at clearing up relatively minor aspects of the process rules
        without any fundamental change to current practice. It has
        been discussed in the IETF as a whole. [Add more after Last Call]

      Document Quality

        This document is structured as a set of changes to RFC 2026. It
        attempts to clarify the IETF rules applied in practice, so
        in that sense it documents running code.
2008-01-16
02 (System) Sub state has been changed to AD Follow up from New Id Needed
2008-01-16
02 (System) New version available: draft-carpenter-rfc2026-changes-02.txt
2007-12-30
02 Russ Housley State Changes to AD Evaluation::Revised ID Needed from AD Evaluation by Russ Housley
2007-12-30
02 Russ Housley State Changes to AD Evaluation from Publication Requested by Russ Housley
2007-09-25
02 Russ Housley Draft Added by Russ Housley in state Publication Requested
2007-09-25
01 (System) New version available: draft-carpenter-rfc2026-changes-01.txt
2007-06-27
00 (System) New version available: draft-carpenter-rfc2026-changes-00.txt