Historic status (was Another look at 6to4 (and other IPv6 transition issues))

[Mykyta Yevstifeyev <[e-mail]>]

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<[e-mail]>
>
>      >  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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ietf
>