Re: Old transport-layer protocols to Historic?

06.01.2011 23:45, Doug Ewell wrote:
> 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.
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
> --
> Doug Ewell | Thornton, Colorado, USA | http://www.ewellic.org
> RFC 5645, 4645, UTN #14 | ietf-languages @ is dot gd slash 2kf0s 
>
>
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf