> I spent a few minutes trying to look up the precise definition of > "Historic Documents" in the IETF standards process. Since the definition > appears to be extremely vague and may not clearly apply in this case,
FWIW, the definition of "Historic" is in RFC 2026, and I agree with Yaron that it's not exactly precise: 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.) There is a subtle distinction between Obsolete and Historic - an Historic RFC is always Obsolete, but an Obsolete RFC may not be Historic. Before going any further, let me say that I strongly agree with Yaron on priorities: > I strongly suggest that we avoid this rathole (and move to the next one), > by adopting the proposed wording below. Manav's I-D is an Independent > document and so its content is completely up to its author; OTOH, I'd > rather not waste the group's energy on not-very-important process > matters. What does matter is that implementers and standards bodies > understand the strengths and weaknesses of our protocols. In order to obsolete AH, the draft header needs to say "Obsoletes: 4302", in addition to its discussion of making RFC 4302 Historic. Both of the foregoing require that the draft not be Informational; I'd go further and suggest that with suitable editing and review, this could be a Best Current Practice (BCP) RFC, as the primary goal is to document the following as current design practice: > > "AH should not be > > preferred when designing new protocols and all attempts must be made > > to use ESP-NULL" I believe that a BCP can be used to cause a standards track RFC to become obsolete. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 [email protected] Mobile: +1 (978) 394-7754 ---------------------------------------------------- > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Yaron Sheffer > Sent: Saturday, December 31, 2011 2:26 PM > To: Dacheng Zhang(Dacheng) > Cc: [email protected]; Melinda Shore; Yoav Nir; Jack Kohn > Subject: Re: [IPsec] 答复: Moving Authentication Header (AH) to Historic > > I agree that people should prefer ESP-null for all new uses. > > I spent a few minutes trying to look up the precise definition of > "Historic Documents" in the IETF standards process. Since the definition > appears to be extremely vague and may not clearly apply in this case, I > strongly suggest that we avoid this rathole (and move to the next one), > by adopting the proposed wording below. Manav's I-D is an Independent > document and so its content is completely up to its author; OTOH, I'd > rather not waste the group's energy on not-very-important process > matters. What does matter is that implementers and standards bodies > understand the strengths and weaknesses of our protocols. > > Wishing us all a Happy New Year 2012! > > Yaron > > On 12/31/2011 05:58 AM, Dacheng Zhang(Dacheng) wrote: > >>> If folks dont want to move AH to historic then perhaps this document > >>> could be modified to say something in the lines of - "AH should not be > >>> preferred when designing new protocols and all attempts must be made > >>> to use ESP-NULL" > > [Dacheng Zhang] > > Really like this suggestion. +1 > >>> Jack > > _______________________________________________ > > IPsec mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ > IPsec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
