Paul Hoffman wrote:
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.
The idea that updates appear in the Errata database is a
good one. As to your proposal: why make it temporary?
I don't see the point. Folks often find an RFC on the IETF
tools server, the HTML version has any obsoleted / updated
by info. Additionally it has a link to any errata, but for
this discovery method errata are not necessary to find the
obsoleted by / updated by info.
They might also find the RFC meta data with the RFC editor
search engine, e.g., <http://purl.net/net/rfc/3700> or in
some Wikis [[purlnet:rfc/3700|RFC 3700]]. Same situation
as above, the RFC meta data directly offers any available
obsoleted by / updated by / errata info.
If what you propose boils down to "the errata should have a
backlink to the HTML version and/or to the RFC meta data"
it is of course fine, that is one simple global fix to the
errata user interface.
Apparently John's proposal was about the at least 60 days
between the approval of an obsoleting / updating RFC, and
the time when it gets its number. For RFCs blocked by a
MISSREF that could be years or forever. For RFCs killed
by an appeal it is forever, intentionally.
In both cases abusing the errata procedure to circumvent
RFC 2026 would be just that, net abuse. And it is already
easy enough for folks risking it anyway, for an example see
the 1123 RFC errata - hopefully IDNAbis will sanction this
stunt in a real standards track RFC.
Frank
_______________________________________________
IETF mailing list
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf