ietf
[Top] [All Lists]

RFC Errata proposals -- a missing piece

2008-06-02 03:55:36
Hi.

Mark Andrews's recent note "RFC 3484 Section 6 Rule 9" suggests
to me that there is a missing piece in the recent IESG and RFC
Editor errata-handling proposals.  

Without taking a position on whether his particular change
should be made, there is a potential problem when maklng a
substantive change quickly is important.

I suggest that it would be useful to add an additional explicit
state category to the the RFC Editor's list, one that would
presumably be handed out of band (although I'd have no objection
to having it automated).   The description would read something
like the following:

        5. Standards change: When a document has been approved
        (via Protocol Action Notice or equivalent) that updates
        or obsoletes an existing Standards Track or BCP
        document, an erratum entry may be added that points to
        the action notice and the approved Internet-Draft.  This
        is intended to be a short-lived entry, providing
        information to the community for important cases during
        the period between IESG approval and publication of the
        new RFC.  These notices are intended to exceptional
        circumstances and will be added at the discretion of the
        RFC Editor (e.g., in circumstances when it appears that
        RFC publication of the new document will be delayed) or
        at the request of the IESG or a relevant Area Director.

In other words, while I agree that errata are an undesirable way
to  make a substantive technical change to a standards-track
document, I'm sympathetic to Mark's concern that the process of
getting consensus on, and publishing, an RFC may take too long,
especially given notions of 60 day publication holds to allow
for appeals.  This change would provide an errata-based
mechanism for warning the community that one or more provisions
of a standards-track document were already considered
inappropriate or obsolete, thereby largely cutting publication
delay out of the timeline, without introducing additional
process mechanisms or using errata inappropriately.

   john

_______________________________________________
IETF mailing list
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf