Subject: Proposed text for IESG Handling of Historic Status

From: Sean Turner <[email-masked]>
Date: Thu, 02 Jun 2011 15:17:30 -0400

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>

---

From: Sam Hartman <[email-masked]>
Date: Thu, 02 Jun 2011 15:47:20 -0400

I'd prefer that we not clutter abstracts with instructions to the RFC
editor and prefer that the IESG only recommend such statements in the
introduction.
I'm OK with whatever here though: the IESG should go do something
intelligent in this space.

---

From: John C Klensin <[email-masked]>
Date: Thu, 02 Jun 2011 16:04:27 -0400

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
<[email-masked]> wrote:

> The IESG is considering making this statement on the IESG
> Handling of Historic status.
> 
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 2 Jun 2011 13:14:45 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Sam Hartman
> Sent: Thursday, June 02, 2011 12:47 PM
> To: Sean Turner
> Cc: [email-masked]; The IESG
> Subject: Re: Proposed text for IESG Handling of Historic Status
> 

+1

-MSK

---

From: Scott Brim <[email-masked]>
Date: Thu, 2 Jun 2011 17:45:56 -0400

> that was used when (and before) 2026 was adopted.

Agree, but producing such a "no one cares anymore" RFC and getting it
through the process should be lightweight enough already. It should slide
right through. I hope we don't need yet another special process because our
normal process is too heavy.

Scott

---

From: Pete Resnick <[email-masked]>
Date: Thu, 2 Jun 2011 17:51:17 -0500

On 6/2/11 4:45 PM, Scott Brim wrote:
>
> On Jun 2, 2011 4:05 PM, "John C Klensin" <[email-masked] 
> <mailto:[email-masked]>> wrote:
> >But for the "no one cares about it any more" cases, it seems like a
> through the process should be lightweight enough already. It should 
> slide right through. I hope we don't need yet another special process 
> because our normal process is too heavy.
>

I have no strong opinion on what exactly we should do on this point, but 
the IESG can already do exactly what John wants with no change to 
process. (See the end of 2026 sec. 6.2.) We would just have to decide to 
do it.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

---

From: SM <[email-masked]>
Date: Thu, 02 Jun 2011 19:33:31 -0700

>that was used when (and before) 2026 was adopted.

Agreed.  It's easier to do a Last Call.  If anyone objects, go 
through I-D path to explain why the RFC should be reclassified.

Regards,
-sm

---

From: John C Klensin <[email-masked]>
Date: Thu, 02 Jun 2011 23:05:17 -0400

--On Thursday, June 02, 2011 17:51 -0500 Pete Resnick
<[email-masked]> wrote:

>> Agree, but producing such a "no one cares anymore" RFC and
>> getting it  through the process should be lightweight enough
>> already. It should  slide right through.

For better or worse, I don't believe that has been the
experience in recent years.

>> I hope we don't need
>> yet another special process  because our normal process is
>> too heavy.

> I have no strong opinion on what exactly we should do on this
> point, but the IESG can already do exactly what John wants
> with no change to process. (See the end of 2026 sec. 6.2.) We
> would just have to decide to do it.

My point exactly.

      john

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Fri, 03 Jun 2011 09:50:08 +0300

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:
> specification or is for any other reason considered to be obsolete is 
> assigned to the "Historic" level.
>
> of an Internet Standard are permitted to "honor the installed base," 
> as per RFC 2026.
>
> header to Historic, then the authors must include an explicit 
> statement for the RFC editor to do so; preferably in the abstract and 
> 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.
>

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 04 Jun 2011 21:12:56 +0100

>and a note in the Introduction ought to be sufficient.
I don't mind having a note in the Abstract, if editors of a particular 
document want to make a possibly stronger (and easier to find) statement 
about moving something to Historic.

>that was used when (and before) 2026 was adopted.
+1.

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 04 Jun 2011 21:59:40 +0100

> excessive to clarify this regulation in the IESG statement additionally.

My understanding is that any RFC can be moved to Historic. But if this 
is not clear from RFC 2026, maybe it is worth clarifying.

> 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 
> moved to Historic status without the necessity to publish a separate 
> RFC for this purpose.  Here I agree with John Klensin.  Let's adopt 
> (1) an individual or a group of individuals apply to the appropriate 
> AD for moving some specification to Historic;
>

 From the pedantic deparment:

As a matter of clarification: it is already possible to move an RFC to 
Historic without new draft using the datatracker. The RFC is added to 
datatracker (just like a draft), etc. This is not going to be a 
management item, it would appear as a proper document on IESG agenda.

"Management items" are second class citizens during IESG telechats...

> (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.

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Sun, 05 Jun 2011 07:40:31 +0300

04.06.2011 23:59, Alexey Melnikov wrote:
>> 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.
>>
>> 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.
>
It isn't really clear from RFC 2026 - so let's mention this in the 
statement.
> management item, it would appear as a proper document on IESG agenda.
This is possible as well and even more preferable.  I surely don't know, 
but I haven't seen any RFCs moved to Historic in this way, but I agree 
this way is good.

So, I'd like to make the following corrections to my proposal:

(1) the reclassification issue should firstly be discussed in the 
appropriate WG (or on the appropriate mailing list);

(2) once a rough consensus is achieved, an individual or a group of 
individuals apply to the appropriate AD for moving some RFC to Historic;

(3) upon ensuring the adequate pre-IESG community involvement, the AD 
adds the RFC in the Datatracker with the Interned Status "Historic" and 
requests the Secretariat to issue a 2-to-4-week Last Call on 
reclassification;

(4) once community consensus is determined, AD brings the question to 
IESG's attention by issuing a ballot and putting the issue on the IESG 
agenda;

(5) as soon as IESG approve the reclassification, the announcement is 
sent to RFC Editor and copied to IETF Announce list containing request 
to change the particular RFC's status to Historic.

Here the new (1) was missing from the old one; other changes incorporate 
Alexey's comment.

All the best,
Mykyta Yevstifeyev

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 4 Jun 2011 23:39:21 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexey Melnikov
> Sent: Saturday, June 04, 2011 2:00 PM
> To: Mykyta Yevstifeyev

If 2026 doesn't limit what types of RFCs can become Historic, then I presume any of them can.  I'm not sure we need to make that explicit.

---

From: Barry Leiba <[email-masked]>
Date: Tue, 7 Jun 2011 01:23:01 +0000

> If 2026 doesn't limit what types of RFCs can become Historic, then I presume
> any of them can.  I'm not sure we need to make that explicit.

I'm sure we don't.  There's no need to change anything in this regard.

Barry

---

From: Fred Baker <[email-masked]>
Date: Mon, 6 Jun 2011 18:49:43 -0700

I think that there are three sets of proposed state changes - what the author would like to do, what the working group if any agrees to do, and what the IESG wants to instruct the RFC Editor should ultimately be done. There is no reason they all have to be the same. For example, a document author might want to make a document a proposed standard, the working group decide it should be informational, and the IESG decide that at most it wants to make the document experimental - or make the document it obsoleted historic(al).

Rather than put more data into the Internet Draft, I would suggest putting the Working Group's view into the Shepherd's Report, and the IESG's view into the announcement and the note to the RFC Editor.

On Jun 2, 2011, at 12:17 PM, Sean Turner wrote:

> The IESG is considering making this statement on the IESG Handling of Historic status.
> 
> 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>