Sean,
Seems fine to me but, like Sam, I'd prefer to not clutter
abstracts For a specification RFC that is rendered Historic by
a new specification, the combination of an "Obsoletes" header
and a note in the Introduction ought to be sufficient.
While the IESG is considering this, I would encourage you to
also consider the model used to make a specification that is
simply and obviously obsolete (and in A/S terms "not
recommended") Historic without having to have an I-D written and
processed into RFC via the same process used to create Standards
Track documents. In the cases in which we want to move a
specification to Historic because it is a bad idea, having an
RFC to explain why it was a bad idea seems appropriate. But for
the "no one cares about it any more" cases, it seems like a
lighter-weight procedure, such as a Last Call on the question
"does anyone believe that our impression that no one cares is
incorrect?" might be in order (and much closer to the procedure
that was used when (and before) 2026 was adopted.
best,
john
--On Thursday, June 02, 2011 15:17 -0400 Sean Turner
<turners(_at_)ieca(_dot_)com> wrote:
The IESG is considering making this statement on the IESG
Handling of Historic status.
We would appreciate community feedback.
Please can we have feedback by Thursday 9th June.
Thanks
spt
<statement begins>
RFC 2026 states the following:
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.
In practice, the Historic status is not automatically assigned
to RFCs that have been "obsoleted". That is, when an RFC that
contains the "Obsoletes: RFC XXXX" header is published the RFC
editor does not automatically apply the Historic status to the
XXXX RFC. Note that in some situations this is perfectly
acceptable because multiple versions of an Internet Standard
are permitted to "honor the installed base," as per RFC 2026.
If authors wish to change the status of RFCs that are in the
obsoletes header to Historic, then the authors must include an
explicit statement for the RFC editor to do so; preferably in
the abstract and introduction. Further, when an AD sponsors a
draft that includes the obsoletes header, then the AD should
ask the authors whether the authors intended to move the
RFC(s) listed in the obsoletes header to Historic status.
If an author wishes to publish a document directly to Historic
status the preferred approach is to publish an I-D with the
"Intended Status: Historic" in the header.
Moving a document to Historic status means that the document
is "not [an] Internet Standards in any sense," as per RFC 2026.
</statement ends>
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf