Subject: Re: Last Call: <draft-eggert-tcpm-historicize-00.txt> (Moving the Undeployed TCP Extensions RFC1072, RFC1106, RFC1110, RFC1145, RFC1146, RFC1263, RFC1379, RFC1644 and RFC1693 to Historic Status) to Informational RFC

From: Mykyta Yevstifeyev <[email-masked]>
Date: Thu, 03 Feb 2011 17:03:31 +0200

Hello all,

While I fully agree with what this document proposes.  This might be an 
editorial comment but I 've noticed that RFC 1072 is not mentioned to be 
made Historic despite the option specified by it is made obsolete.  What 
is more, referencing all the documents made obsolete normatively is OK?  
Here I suggest only RFC 4614 to be mentioned in this way.

However I'd like to raise some questions not directly connected to this 
document.  I wonder why those who said a few weeks ago that 
historicizing some documents in the similar situation is not appropriate 
do not object now.  The arguments of these folks were that RFC 2026 sets 
the criteria for Historic status as 'replaced by other doc' and did not 
consider 'being deprecated' (what exactly we have in the current case) 
as weighty reason for historicizing document.

Moreover, there are no clear procedures for moving documents to 
Historic.  So everybody who wants to propose to move some RFC to 
Historic must think out what procedures should be used or find them out 
in the most recent documents.

Up to this day there are neither any clear definition of Historic RFC 
status nor procedures for historicizing RFCs.  Should this continue?

Mykyta Yevstifeyev

02.02.2011 23:51, The IESG wrote:
> The IESG has received a request from the TCP Maintenance and Minor
> Extensions WG (tcpm) to consider the following document:
> - 'Moving the Undeployed TCP Extensions RFC1072, RFC1106, RFC1110,
>     RFC1145, RFC1146, RFC1263, RFC1379, RFC1644 and RFC1693 to Historic
>     Status'
>    <draft-eggert-tcpm-historicize-00.txt>  as an Informational RFC
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2011-02-16. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
>
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-eggert-tcpm-historicize/
>
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-eggert-tcpm-historicize/
>
>
>
> No IPR declarations have been submitted directly on this I-D.
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce
>

---

From: Lars Eggert <[email-masked]>
Date: Thu, 3 Feb 2011 19:40:40 +0200

Hi,

On 2011-2-3, at 17:03, Mykyta Yevstifeyev wrote:
> While I fully agree with what this document proposes.  This might be an editorial comment but I 've noticed that RFC 1072 is not mentioned to be made Historic despite the option specified by it is made obsolete.

you mean it's missing from Section 2? Good catch. I'll add that in my working copy.

>  What is more, referencing all the documents made obsolete normatively is OK?  Here I suggest only RFC 4614 to be mentioned in this way.

I guess they could become informative references, but you could also argue that they are required background reading and hence should be normative.

Lars

---

From: Benjamin Niven-Jenkins <[email-masked]>
Date: Fri, 4 Feb 2011 00:00:57 +0000

Mykyta,

On 3 Feb 2011, at 15:03, Mykyta Yevstifeyev wrote:
> However I'd like to raise some questions not directly connected to this document.  I wonder why those who said a few weeks ago that historicizing some documents in the similar situation is not appropriate do not object now.  The arguments of these folks were that RFC 2026 sets the criteria for Historic status as 'replaced by other doc' and did not consider 'being deprecated' (what exactly we have in the current case) as weighty reason for historicizing document.

I am not sure which of the many "move to historic" proposals you have proposed recently you are referring to but IMO there is a difference between your proposals and that of Lars, namely:

Your proposals fell into one of two categories:
1) Protocol X is old so we should make it historic for housekeeping reasons
2) URI Y has never been used so we should make it historic

Whereas while Lars' document is doing some housekeeping it is really saying "if you implement TCP you don't need to implement these bits anymore" so it has a clear value to people writing new TCP stack implementations.

In comparison your proposals were housekeeping for the sake of housekeeping and provided no value to the wider community.

HTH
Ben

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Fri, 04 Feb 2011 16:13:21 +0200

Benjamin,

RFC 4644, that is a reason to have this document written says:

>   The RFCs listed here define extensions that have thus far failed to
>     arouse substantial interest from implementers, or that were found to
>     be defective for general use.

I. e. these options are out-of-use and did not gain the implementators' 
popularity. Nearly the same is with IRTP, which I referred to.

Nevertheless I agree that this purpose of this draft is to say "if you 
implement TCP you don't need to implement these bits anymore"; the 
purpose of moving i.e. IRTP to Historic is contiguous - "this technology 
was eventually defined but revealed itself unacceptable/uninteresting; 
further implementations are discouraged"

Mykyta Yevstifeyev