Noel and all,
The meaning of Historic has alway been a bit unclear. Neither 2026 nor
its predecessors say enough about this category for RFCs; particularly,
it fails to describe what are the procedures for moving RFCs to
Historic, whether one is allowed to publish documents directly to
Historic, what RFCs may be historicized etc. The current IESG statement
clears up one of these issues, ie. how to move IETF Stream RFCs to
Historic; but what does it actually means was limited to the following
pieces of text from RFC 2026:
1)
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. (Purists have suggested that the
word should be "Historical"; however, at this point the use of
"Historic" is historical.)
2)
A specification may have been superseded by a more recent
Internet Standard, or have otherwise fallen into disuse or disfavor.
(not explicitly stated; may be deduced from the meaning that Historic is
described)
3)
Following each such review, the IESG
shall approve termination or continuation of the development effort,
at the same time the IESG shall decide to maintain the specification
at the same maturity level or to move it to Historic status.
(from Section 6.2)
4)
Once the new version has reached the
Standard level, it will usually replace the previous version, which
will be moved to Historic status.
5)
In this case, or when it is felt for some other
reason that an existing standards track specification should be
retired, the IESG shall approve a change of status of the old
specification(s) to Historic.
The cited extracts generally assume that Historic is mostly used to mark
documents removed from Standards Track in order to denote that they are
not Internet Standard at any maturity level any more and new
implementations should not depend on Historic RFCs. Currently Historic
is considered in a bit an other way (see below); eg. Experimental and
Informational documents are also moved to Historic freely (see eg. RFC
6247), even though they have no relationship to Standards Track and it's
fully up to the implementor to evaluate the protocol and decide whether
to implement or not implement it (unlike Standards Track, which was
intended as "IETF recommends to use this").
RFC 4844 does not mention clearly, but Historic documents may
occasionally be published by IETF (I also saw 2 Historic RFCs published
by IRTF and a number - by Independent Submissions Editor) directly.
Procedures for moving non-IETF-stream RFCs to Historic are still unclear.
There were some proposals regarding Historic; eg. the NEWTRK WG document
(http://tools.ietf.org/id/draft-ietf-newtrk-cruft-00.txt), which is
expired but was partly incorporated in IESG Statement on Historic
(http://www.ietf.org/iesg/statement/designating-rfcs-as-historic.html),
and my proposal
(http://tools.ietf.org/html/draft-yevstifeyev-genarea-historic-03).
None of them progressed further.
Some drafts registered by datatracker as "Internet Standards Process
Rev. 4" (http://tools.ietf.org/id/draft-lear-ietf-rfc2026bis-00.txt and
http://tools.ietf.org/id/draft-moonesamy-stds-process-00.txt) also say
extremely little about Historic status compared with 2026.
http://tools.ietf.org/id/draft-carpenter-rfc2026-changes-02.txt, Section
3.12 proposed to change current Historic description to:
A specification that has been superseded by a more recent
specification or is for any other reason considered to be obsolete
may be assigned to the "Historic" level by the IESG. (Purists have
suggested that the word should be "Historical"; however, at this
point the use of "Historic" is historical.)
assuming that any RFC may be moved to Historic by IESG, overlooking
other streams' authorities (this draft was issued in 2008, long after
RFC 4844). This draft wasn't ultimately processed, even though it
entered IESG review.
So what's the meaning of Historic? As Ronald mentioned, the formulation
"to be obsolete" in RFC 2026 may be understood differently; one may
think that it means "nobody uses the protocol", which is impossible to
determine and then say for sure. The second person may think that "the
protocol's possibilities may safely be provided by other protocol",
which is easier to determine, but applying such definition might create
problems with interoperability. The third opinion may be "the protocol
is known to have technical/security/other omissions and its use should
be discouraged". The others may also have other views on Historic,
which does not facilitate the Internet Standards process.
And what could/should be done? I think, IESG and the whole community,
cooperating with IAB, IRSG and ISE, should determine the definition of
Historic which will be fine enough to cover all existing issues with it,
and then either publish such approach as BCP or incorporate when
updating RFC 2026. This will eliminate the problems with different
issues with procedures for and understanding of Historic RFCs as well as
clear up one of "dark places" in IETF process.
Of course, just my opinion.
Mykyta Yevstifeyev
18.07.2011 18:33, Noel Chiappa wrote:
> From: Ronald Bonica<rbonica@xxxxxxxxxxx>
> RFC 2026's very terse definition of HISTORIC. According to RFC 2026,
> "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." That's the entire definition.
> Anything more is read into it.
> ...
> A more likely interpretation is as follows:
> "the IETF is not likely to invest effort in the technology in the
> future"
> "the IETF does not encourage (or discourage) new deployments of this
> technology.
But in giving other interpretations, are you thereby not comitting the
exact error you call out above: "Anything more is read into it."?
To me, "Historic" has always (including pre-2026) meant just what the
orginal meaning of the word is (caveat - see below) - something that is
now likely only of interest to people who are looking into the history of
networking. (The dictionary definition is "Based on or concerned with
events in history".) I think "obsolete" is probably the best one-word
description (and note that 'obsolete' != 'obsolescent').
(Caveat: technically, it probably should have been 'historical', not
"historic" - "historic" actually means 'in the past, but very noteworthy',
e.g. 'CYCLADES was a historic networking design', so not every historical
protocol is historic.)
Noel
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf