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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf