Hi, I read this document. On a quick read, this seemed very reasonable. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com > -----Original Message----- > From: ietf-announce-bounces@ietf.org > [mailto:ietf-announce-bounces@ietf.org] On Behalf Of The IESG > Sent: Wednesday, April 16, 2008 8:17 AM > To: IETF Announcement list > Cc: iaoc@ietf.org; iab@iab.org; iesg@ietf.org; > rfc-editor@rfc-editor.org > Subject: Proposed IESG Statement Regarding RFC Errata for > IETF Sream RFCs > > 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 > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > _______________________________________________ IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
