[rfc-i] RFC Errata - Slippery Slope

[Danny McPherson]

Upon rereading this draft and discussing this some offline with
Bob, Olaf and others, I figured I'd kick a message here for
discussion.

Section 1.1 of draft-rfc-editor-errata-process-00 shares this
observation:

[...]

    Another issue with errata is that some of the reported errors are  
not
    simply editorial, but rather correct technical contents of RFCs.  A
    savvy implementer of the specification can often, but not always,
    figure out what was intended by the RFC as published, but technical
    errors should be announced somehow.  Furthermore, posting technical
    errata for Standards Track documents should always involve the IESG,
    as a matter of correct process.  Technical errata may require much
    review and discussion among the author(s), Area Directors, and other
    interested parties.

    We note that allowing technical errata is a slippery slope: there  
may
    be a temptation to use errata to "fix" protocol design errors,  
rather
    than publishing new RFCs that update the erroneous documents.  In
    general, an erratum is intended to report an error in a document,
    rather than an error in the design of the protocol or other entity
    defined in the document, but this distinction may be too  
imprecise to
    avoid hard choices.  For the IETF stream, these choices should be
    made by the IESG, not the RFC Editor.

[...]

The current draft process doesn't distinguish between technical and
editorial errata.  Are more specific guidelines needed here?  Guidelines
that are generic to all streams with respect to distinguishing  
between errors
in documents and errors in protocol, e.g. what happens with errata  
that are
rejected because they would change the protocol although they clearly
and unambiguously demonstrate an error? Is there a need to keep such
information around and tag it?

I know Bob Braden has some information of the RFC Editor bits (he's
clued me in here already), I'm sure he'll share those with the folks  
here
as well.  I'm wondering more about what folks here believe needs to
happen on the process front.

The second question is if there is a need to describe in more detail the
stream dependent management of such normative changes. For the IETF
stream it would probably mean 'back to the WG/sponsoring AD and work
on a new RFC'. How about the independent, IAB, and IRTF stream?

Also, are the current guidelines regarding notification to ietf-announce
sufficient, or should each status change trigger some note every time
an erratum is verified, rejected to altered?

I'm quite interested in seeing more discussion on this.

-danny