Re: Proposed text for IESG Handling of Historic Status

Hello,

The proposed statement is mostly fine.  But, since RFC 2026 gives very 
little information on some issues, I'd like you considered them in the 
statement.

First, for RFCs of what categories is it legitimate to move them to 
Historic.  Whether Experimental or Informational RFCs could be 
considered for such action?  As far as I understand RFC 2026, Historic 
can be assigned to Standards Track documents; however it won't be 
excessive to clarify this regulation in the IESG statement additionally.

I support the opinion that the information on what the particular RFC 
moves to Historic shouldn't go in the Abstract; the current practice is 
also the same (see eg. http://tools.ietf.org/html/rfc6265, end of 
Section 1).  Let's mention it is only put in the Introduction.

The proposed statement says almost nothing about how the RFC may be 
moved to Historic status without the necessity to publish a separate RFC 
for this purpose.  Here I agree with John Klensin.  Let's adopt 
something like proposed in 
http://tools.ietf.org/id/draft-ietf-newtrk-cruft-00.txt, but more 
lightweight.  What I mean is that the procedure should be:

(1) an individual or a group of individuals apply to the appropriate AD 
for moving some specification to Historic;

(2) AD asks Secretariat to issue a 2-to-4-week Last Call on 
reclassification;

(3) once community consensus is determined, AD brings the question to 
IESG's attention via putting it on agenda as "Management Issue";

(4) if IESG does not object, the announcement is sent to RFC Editor and 
copied to IETF Announce list containing request to change the particular 
RFC's status to Historic.

Such procedure seems lightweight enough not to create dozens of new RFCs 
reclassifying the old ones but have the appropriate community involvement.

Mykyta Yevstifeyev

02.06.2011 22:17, Sean Turner 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@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
>