08.01.2011 18:02, Lixia Zhang wrote:
On Jan 6, 2011, at 10:01 PM, Mykyta Yevstifeyev wrote:
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?
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.
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
RFC 5645, 4645, UTN #14 | ietf-languages @ is dot gd slash 2kf0s
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf
|