Proposed IESG Statement Regarding RFC Errata for IETF Sream RFCs

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

 



The IESG is considering the following statement to guide the handling of
RFC Errata for IETF Stream RFCs.  Your review and comment on this policy
is encouraged.

Russ Housley
on Behalf of the IESG


- - - - - - - - - - - -


Proposed IESG Statement Regarding RFC Errata for IETF Sream RFCs

   These are strong guidelines and not immutable rules.  Common sense
   and good judgment should be used by the IESG to decide what is the
   right thing to do.  Errata are meant to fix "bugs" in the
   specification and should not be used to change what the community
   meant when it approved the RFC.  These guidelines only apply to
   errata on RFCs in the IETF stream.  They apply to new errata and
   not errata that had already been approved.

   After an erratum is reported, a report will be sent to the authors and

   Area Directors (ADs) of the WG in which it originated.  If the WG has
   closed or the document was not associated with a WG, then the
   report will be sent to the ADs for the Area most closely associated
   to the subject matter.  The ADs for the area will review it, either
   themselves or by delegating, and classify it as falling under
   one of the following states:

   o  Approved - The errata is appropriate under the criteria below and
      should be available to implementors or people deploying the RFC.

   o  Rejected - The errata is in error, or proposes a change to the RFC
      that is clearly inappropriate to do with an errata.  In the latter
      case, if the change is to be considered for future updates of the
      document, it should be proposed using other channels than errata,
      such as a WG mailing list.

   o  Archived - The errata is not a necessary update to the RFC.
      However, any future update of the document should consider this
      errata, and determine whether it is correct and merits including
      in the update.

   Guidelines for review are:

   1.  Only errors that could cause implementation or deployment
       problems or significant confusion should be Approved.

   2.  Things that are clearly wrong but could not cause an
       implementation or deployment problem should be Archived.

   3.  Errata on obsolete RFCs should treated the same as errata on
       non-obsolete RFC where there is strong evidence that some
       people are still making use of the related technology.

   4.  Trivial grammar corrections should be Archived.

   5.  Ugly typos that are clearly bogus typos but would not cause any
       confusions to implementation or deployments should be Archived.

   6.  Changes which are simply stylistic issues or simply make things
       read better should be Archived.

   7.  Changes that modified the working of a protocol to something that
       might be different from the intended consensus when the document
       was approved should be either Archived or Rejected. Deciding
       between these two depends on judgment. Changes that are clearly
       modifications to the intended consensus, or are of major
       importance, should be Rejected. In unclear situations, small
       changes can be Archived.

   8.  Changes that modify the working of a process, such as changing
       an IANA registration procedure, to something that might be
       different from the intended consensus when the document was
       approved should be Archived.

_______________________________________________

IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

[Index of Archives]     [IETF]     [IETF Discussion]     [Linux Kernel]

  Powered by Linux