Subject: Proposed IESG Statement Regarding RFC Errata for IETF Sream RFCs

From: The IESG <[email-masked]>
Date: Wed, 16 Apr 2008 08:16:59 -0700 (PDT)

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 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf-announce

---

From: Lisa Dusseault <[email-masked]>
Date: Thu, 17 Apr 2008 08:45:43 -0700

I can assure you, I at least was anticipating that the IESG (and other  
people handling errata) would be doing *more* work in classifying  
errata if we have the three categories.  The goal as I see it is to  
avoid presenting 50 errata on an RFC to a user, without any sorting or  
focus, when only three of them are crucial to interoperability.  If we  
overwhelm implementors with more than a page worth of errata, most of  
which are junk, implementors will be well justified in ignoring errata.

An important part of the errata handling, therefore, is to make the  
difference clear to the implementor.  When an implementor clicks  
"Errata" for an RFC, they should see the short-list of crucial errata  
and at the end, a link to "Other possible errata" (or other wording).  
With that kind of interface, I don't think readers of errata need to  
care about the exact difference between categories: the essential  
difference, to them, is which ones have been brought to their  
immediate attention.

Lisa

On Apr 17, 2008, at 7:13 AM, Paul Hoffman wrote:

> At 8:16 AM -0700 4/16/08, The IESG wrote:
> Assuming that both categories will be in the errata repository, the  
> difference between these two may be clear to the IESG, but it will  
> not be clear to readers of the errata. I suspect that the two  
> categories were created so that the IESG only needs to consider  
> "errors that could cause implementation or deployment problems or  
> significant confusion", not the minor stuff, but this  
> differentiation will simply cause more arguments about what errors  
> would cause problems of what magnitude.
>
> In the end, it is probably better for readers of the errata to have  
> just one category, and for the IESG to not waste its time  
> differentiating between the two categories.
>
> --Paul Hoffman, Director
> --VPN Consortium
>

---

From: "David Harrington" <[email-masked]>
Date: Thu, 17 Apr 2008 09:39:35 -0700

Hi,

I read this document. On a quick read, this seemed very reasonable.

David Harrington
[email-masked]
[email-masked]
[email-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of The IESG
> Sent: Wednesday, April 16, 2008 8:17 AM
> To: IETF Announcement list
> Cc: [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]
> Subject: Proposed IESG Statement Regarding RFC Errata for 
> IETF Sream RFCs 
>