|
Doug, all, 30.01.2011 20:51, Doug Ewell wrote: I've recently thought on how to formulate this criterion. My most current thoughts are the following: c. The RFC describes the technology that is not possible to be used  in the current Internet because of its technical characteristics or  possible problems with its implementation. However this is not a final variant - any other proposals are welcome. Agreed here. See what I think below. --------- And now a few questions for discussion: 1) Should historicizing Informational RFCs be allowed? My proposal is to allow this only if they describe the protocol (see Section 4.2.2 of RFC 2026) with the authors' approval REQUIRED. 2) Definition of obsolete RFCs are still unclear. The most recent what I have is: The RFC SHALL be considered to be obsolete if it meets the following  criteria:  a. It has been publicly available for at least 7 years;  b. During this period of time the technology, described in this RFC  has not been seen used in the Internet; or  c. The RFC describes the technology that is not possible to be used  in the current Internet because of its technical characteristics or  possible problems with its implementation. Any proposals on this? 3) Procedures on Experimental RFCs to Historic. What I have in my working version is different from what is in -01 version. See below: 3.2.3. Experimental RFCs  Procedures for historicizing Experimental RFCs depend on their origin  and the way it is being historicized with. 3.2.3.1. Separate Historicizing Document  The procedures described in this section apply to the case, mentioned  as 'b' at the beginning of Section 3.2 (separate historicizing  document).  If the Experimental RFCs has been processed on IETF stream [RFC4844],  'IETF Consensus' [RFC5226] is REQUIRED to historicize it.  If the Experimental RFCs has been processed on IAB stream [RFC4844],  'IETF Consensus' [RFC5226] and IAB Chair approval is REQUIRED to  historicize it.  If the Experimental RFCs has been processed on IRTF stream [RFC4844],  'IETF Consensus' [RFC5226] and IRTF Chair approval is REQUIRED to  historicize it.  If the Experimental RFCs has been processed on Independent  Submissions stream [RFC4844], 'IETF Consensus' [RFC5226] and authors'  approval is REQUIRED to historicize it. In essential cases the  approval of the director of the area the historicized document is  considered to be related to MAY be used instead the authors' one.  In the cases described above IESG is responsible for recording their  approval. 3.2.3.2. Superseding Document Historicizes the Superseded One  The procedures described in this section apply to the case, mentioned  as 'a' at the beginning of Section 3.2 (superseding document  historicizes the superseded one).  The superseding document that is being processed on the same stream  [RFC4844] as the superseded one MAY move it to Historic without any  special procedures; a simple mention of such action is therefore  REQUIRED in superseding document.  If the superseding document is being processed on the stream,  different from that of superseded one, the approval of corresponding  party is REQUIRED. Section 3.2.3.1 describes some cases that apply  this one as well (for IAB-, IETF-, and Independent Submissions  streams [RFC4844]). Historicizing IETF-stream documents by non-IETF-  stream ones SHALL be made following usual procedures for RFCs of such  stream with IETF Chair approval REQUIRED. 4) Are there any thoughts on other consideration connected with historic docs.? Except referencing, there might be appropriate to discuss what should be done with IANA registries defined by Historic RFCs. Anything else? All the best, Mykyta Yevstifeyev
|
_______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf