Subject: RE: Old transport-layer protocols to Historic?

From: "Doug Ewell" <[email-masked]>
Date: Thu, 06 Jan 2011 14:45:31 -0700

Lixia Zhang <lixia at cs dot ucla dot edu> wrote:

> PS: on the other hand, what would a "historical status" imply?  the ideas obsolete?

Every now and then, someone proposes to move a given RFC to Historic,
not merely to reflect an observation that a process or protocol is
obsolete, but as an active attempt to deprecate it, regardless of its
currency or relevance.

I remember a few months ago, it was proposed (evidently not for the
first time) to move FTP to Historic, on the basis of its lack of
airtight 21st-century security features, with no consideration for the
innumerable existing systems and processes that have no need for
top-notch security, and rely daily on FTP.

I often see comments on this list about whether the "outside world"
views the IETF as irrelevant.  Declaring a commonly used, core process
or protocol as Historic because something better exists might be a
perfect example of this.

--
Doug Ewell | Thornton, Colorado, USA | http://www.ewellic.org
RFC 5645, 4645, UTN #14 | ietf-languages @ is dot gd slash 2kf0s

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Fri, 07 Jan 2011 08:01:23 +0200

06.01.2011 23:45, Doug Ewell wrote:
> Lixia Zhang<lixia at cs dot ucla dot edu>  wrote:
>
I think that the author of RFC2026 was wrong while writing the 
definition of Historic status. This document says that Historic should 
be assigned only to that documents that were standards and now are 
obsolete. But why do we need such narrow definition? Non-standards RFCs 
are not made Historic while obsoleting, according to 2026. Moreover, 
such status will just duplicate the obsoleted-by one. When there will be 
the attempt to revise RFC 2026, we should put there that Historic status 
is to be assigned to that documents that are considered to be 
/deprecated/. I fully share the opinion of Doug here.

As for NETBLT, I am strongly against moving it to Historic, rather than 
specifying by Standards Track Document. There has been one attempt to do 
that by John White in 1995 (see draft-white-protocol-stack), but IMO 
(that likes strange, but...) we can align this document with the most 
current needs of Internet and publish.

Mykyta
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 7 Jan 2011 01:30:46 -0500

I have also seen attempts to make a standard Historic with the
supposed reason being to "clear things out" for the introduction of
some better replacement. That seems like just nonsense to me. If it is
so obvious that a replacement is superior, the replacement document
can do the move of earlier document to Historic...

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street
 Milford, MA 01757 USA   +1-508-634-2066 (home)
 [email-masked]

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Fri, 07 Jan 2011 08:39:37 +0200

> can do the move of earlier document to Historic...
As I've mentioned before, I think that the problem is the definition of 
Historic status. It is not correct. It duplicates the obsoleted-by 
status (if that can be called like this). It is really inappropriate for 
its real reason - indicating the deprecated (but not obsoleted) docs. 
Moreover, 'obsoleted' means the same as 'deprecated' or 'non-current' 
(see http://www.synonym.com/synonyms/obsolete/ or 
http://dictionary.sensagent.com/obsolete/en-en/#synonyms). So it is a 
problem in RFC2026.

All the best,
Mykyta Yevstifeyev
> On Thu, Jan 6, 2011 at 4:45 PM, Doug Ewell<[email-masked]>  wrote:

---

From: Eliot Lear <[email-masked]>
Date: Fri, 07 Jan 2011 15:13:21 +0100

On 1/7/11 7:39 AM, Mykyta Yevstifeyev wrote:
> As I've mentioned before, I think that the problem is the definition
> of Historic status. It is not correct. It duplicates the obsoleted-by
> status (if that can be called like this). It is really inappropriate
> for its real reason - indicating the deprecated (but not obsoleted)
> docs. Moreover, 'obsoleted' means the same as 'deprecated' or
> 'non-current' (see http://www.synonym.com/synonyms/obsolete/ or

As an exercise some time ago, we looked at the 2000 RFCs to determine
which of the Proposed Standards could be deprecated.  We found 61 out of
125 such memos could be marked as Historic, the point being that we
wanted to the RFC Editor series to reflect the fact that in the IETF's
opinion, nobody was using the work.  Not that the work was bad or
broken.  In this case, it would have been impractical to list 61
documents as "Obsoletes/Obsoleted-by".  See RFC-4450 for a more complete
description of what happened.

Eliot

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 7 Jan 2011 09:15:43 -0500

I'm not keen to start a language war, but. . .

> http://dictionary.sensagent.com/obsolete/en-en/#synonyms). So it is a  

. . .I fully disagree with that, regardless of what those claims of
synonymy say.  To deprecate something is to express disapproval.  To
mark something as obsolete doesn't do that; it merely says that the
marked thing is outdated.  There is a useful distinction here worth
maintaining.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Lixia Zhang <[email-masked]>
Date: Sat, 8 Jan 2011 08:02:46 -0800

On Jan 6, 2011, at 10:01 PM, Mykyta Yevstifeyev wrote:

> I think that the author of RFC2026 was wrong while writing the definition of Historic status. This document says that Historic should be assigned only to that documents that were standards and now are obsolete. But why do we need such narrow definition?

My understanding is that we want a well defined set of Internet standard protocols, with minimal ambiguity.

> Non-standards RFCs are not made Historic while obsoleting, according to 2026.

that is correct.
and I do not see anything wrong with it.

> Moreover, such status will just duplicate the obsoleted-by one. When there will be the attempt to revise RFC 2026, we should put there that Historic status is to be assigned to that documents that are considered to be deprecated. I fully share the opinion of Doug here.
> 
> As for NETBLT, I am strongly against moving it to Historic, rather than specifying by Standards Track Document.

unless there is clearly identified need for a protocol like NETBLT (as its name suggested, it is a specialized protocol for bulk data transfer only), I do not see the need to move NETBLT to standard.

In case such a need is identified, personally I think we need a clear problem statement first, so that we better understand the context the protocol will be applied to.  We (the MIT crew at the time) did various trials of NETBLT after the RFC998's publication, and collected a list of issues for further investigation (of course we did not do it, as everyone moved on to other burning fires, and NETBLT served its purpose of proof-of-concept).

> There has been one attempt to do that by John White in 1995 (see draft-white-protocol-stack), but IMO (that likes strange, but...) we can align this document with the most current needs of Internet and publish.
> 
> Mykyta
>> --

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Sat, 08 Jan 2011 18:16:02 +0200

08.01.2011 18:02, Lixia Zhang wrote:
>> definition of Historic status. This document says that Historic 
>> should be assigned only to that documents that were standards and now 
>> are obsolete. But why do we need such narrow definition?
>
> My understanding is that we want a well defined set of Internet 
> standard protocols, with minimal ambiguity.
>
Where do we have it in RFC2026?  Also see 
http://www.ietf.org/mail-archive/web/ietf/current/msg65052.html for some 
thoughts on 'obsolete' and 'obsoleted' terms.
>
>> Moreover, such status will just duplicate the obsoleted-by one. When 
>> there will be the attempt to revise RFC 2026, we should put there 
>> that Historic status is to be assigned to that documents that are 
>> considered to be /deprecated/. I fully share the opinion of Doug here.
>>
>> As for NETBLT, I am strongly against moving it to Historic, rather 
>> than specifying by Standards Track Document.
>
> unless there is clearly identified need for a protocol like NETBLT (as 
> its name suggested, it is a specialized protocol for bulk data 
> transfer only), I do not see the need to move NETBLT to standard.
Nobody currently wants that.  We want to publish it as Experimental (if 
you refer to draft-white-tsvwg-netblt) but updated.
>
> In case such a need is identified, personally I think we need a clear 
> problem statement first, so that we better understand the context the 
> protocol will be applied to.  We (the MIT crew at the time) did 
> various trials of NETBLT after the RFC998's publication, and collected 
> a list of issues for further investigation (of course we did not do 
> it, as everyone moved on to other burning fires, and NETBLT served its 
> purpose of proof-of-concept).
>
>> There has been one attempt to do that by John White in 1995 (see 
>> draft-white-protocol-stack), but IMO (that likes strange, but...) we 
>> can align this document with the most current needs of Internet and 
>> publish.
>>
>> Mykyta
>>> --
>>> Doug Ewell | Thornton, Colorado, USA |http://www.ewellic.org

---

From: Bob Hinden <[email-masked]>
Date: Sat, 8 Jan 2011 13:45:00 -0800

Hi,

> I think that the author of RFC2026 was wrong while writing the definition of Historic status. This document says that Historic should be assigned only to that documents that were standards and now are obsolete. But why do we need such narrow definition? Non-standards RFCs are not made Historic while obsoleting, according to 2026. Moreover, such status will just duplicate the obsoleted-by one. When there will be the attempt to revise RFC 2026, we should put there that Historic status is to be assigned to that documents that are considered to be deprecated. I fully share the opinion of Doug here.

If you think RFC20206 is wrong, then propose changes to it and see if people agree with the changes.  Until it is changed, IMHO you should not propose actions based on what you as an individual think is incorrect.  There needs to be a community consensus that RFC2026 is wrong before any action should be taken.

Bob

---

From: "Doug Ewell" <[email-masked]>
Date: Sat, 8 Jan 2011 19:33:51 -0700

Bob Hinden replied to Mykyta:

> If you think RFC20206 is wrong, then propose changes to it and see if 
> people agree with the changes.  Until it is changed, IMHO you should 
> not propose actions based on what you as an individual think is 
> incorrect.  There needs to be a community consensus that RFC2026 is 
> wrong before any action should be taken.

RFC 2026 says: "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."

My concern (which may not be quite the same as Mykyta's) is how 
aggressive some people might be in declaring a specification like FTP to 
be superseded or obsolete.  "Inappropriate for high-security uses" does 
not by any means imply "inappropriate for all uses."

---

From: John C Klensin <[email-masked]>
Date: Sat, 08 Jan 2011 06:52:36 -0500

+1

--On Friday, January 07, 2011 09:15 -0500 Andrew Sullivan
<[email-masked]> wrote:

>> Moreover, 'obsoleted' means the same as 'deprecated' or
>> 'non-current'   (see
>> http://www.synonym.com/synonyms/obsolete/ or  
>> http://dictionary.sensagent.com/obsolete/en-en/#synonyms). So
>> it is a   problem in RFC2026.
> 
> . . .I fully disagree with that, regardless of what those
> claims of synonymy say.  To deprecate something is to express
> disapproval.  To mark something as obsolete doesn't do that;
> it merely says that the marked thing is outdated.  There is a
> useful distinction here worth maintaining.
> 
> A