Begin forwarded message:
> From: IESG Secretary <[email protected]> > Subject: Updated IESG Statement on Designating RFCs as Historic > Date: July 20, 2014 at 10:25:10 AM EDT > To: IETF Announcement List <[email protected]> > Reply-To: <[email protected]> > > Date: 20 July 2014 > > RFC 2026 defines a "Historic" status for documents: > > A specification that has been superseded by a more recent > specification or is for any other reason considered to be obsolete > is assigned to the "Historic" level. > > However, the only instructions in 2026 for its use are in section 6, and > those are to move full "Internet Standard" status documents to > "Historic" status, thereby "retiring" the technology in the standard. > This differs from the "Obsoletes:" header that is put on documents as > per RFC 2223. The "Obsoletes:" header indicates a replacement version of > the same technology, rather than a retirement of the technology itself. > Using "Obsoletes:" is simply a matter of indicating this in the header > of the RFC. Moving a document to "Historic" status requires a specific > IETF-wide Last Call and a formal action of the IESG. > > - A document is obsolete when there is a newer version that replaces > it. RFC 821 is obsoleted by RFC 2821, which is, in turn, obsoleted > by RFC 5321. The technology that RFC 821 describes — SMTP — is still > current technology, but the documentation of it in RFC 821 is > obsolete. > > - A document is labelled Historic when what it describes is no longer > considered current: no longer recommended for use. > > We have reclassified RFCs as Historic through different mechanisms and > with different documentation over time. All reclassifications have > suffered from a common problem: there is no direct reference from the > RFC that has been made Historic to the explanation of why that action > was taken. > > There now exists a new type of document, "status-change" documents, to > fill this gap. These documents are kept in the datatracker, are not > Internet drafts, and are not published as RFCs, but they are archival > documents that are linked to the RFCs whose status is changed. Much as > an Internet draft that requests Historic status might be named "draft- > jones-9191-to-historic", a status-change document requesting that action > might be "status-change-9191-to-historic. Such status change documents > are created by an Area Director, and can be requested by individuals or > working groups. > > A major advantage of a status-change document is that it adds > traceability: when the now-Historic RFC is displayed in the datatracker, > there is a pointer directly to the status-change document, making the > explanation more readily accessible. See RFC 5617 for an example: > > https://datatracker.ietf.org/doc/rfc5617/ > > Note the line in the header that says "Status changed by > status-change-adsp-rfc5617-to-historic". > > The current process, then, of moving an RFC to Historic status is to > follow one of these, depending upon the level of documentation and > discussion of the documentation required: > > 1. An AD creates a status-change document containing a relatively > brief explanation of the reason for the status change. A four-week > last call is issued for the status-change document, after which the > IESG evaluates and ballots on the status change. If the change is > approved, the documentation for the change remains in the status- > change document, which is readily available through the datatracker. > > This method is best when the explanation is not extensive and does > not need much documentation development. The discussion about > whether the action itself is correct may, of course, still be > extensive. > > 2. An individual or a working group posts an Internet Draft containing > an explanation of the reason for the status change. The I-D is > discussed and iterated as usual for I-Ds. At some point, it is sent > to an appropriate AD to request publication. The AD creates a > status-change document, with an explanation that points to the I-D. > The I-D and the status-change are then last-called together, after > which the IESG evaluates and ballots on both. If the change is > approved, the content of the I-D is moved into the status-change > document, and the I-D is marked as "dead", having served its > purpose. > > This method is best when the explanation is not extensive, but needs > document discussion and development. > > 3. As #2 above, except that the I-D might also contain other > information. In this case, after IESG approval the I-D is sent to > the RFC Editor. When the RFC is published, the status-change > document is changed to point to the RFC instead of the I-D. > > This method is best when the explanation is extensive, the > explanation is part of another piece of work that involves > publication of an RFC, or, in exceptional cases, when the consensus > of the community or of the IESG is that having the information in an > RFC is important. > > All cases involve a status-change document, which provides the mechanics > for separately approving the Historic RFC's status change and for tying > the explanation to the Historic RFC. In all cases, the approval of the > status-change document will result in a "Protocol Action" or "Document > Action" announcement. > > An RFC may be published directly as Historic, with no earlier status to > change (see, for example, RFC 4870). This is usually done to document > ideas that were considered and discarded, or protocols that were already > historic when it was decided to document them. Those publications are > handled as are any other RFCs. As there is no status change, no status- > change document is used. > > Documents having Historic status means that those documents are "not > Internet Standards in any sense," as per RFC 2026. >
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
