> 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
david.black@... Mobile: +1 (978) 394-7754
----------------------------------------------------
> -----Original Message-----
> From:
ipsec-bounces@... [mailto:
ipsec-bounces@...] On Behalf Of Yaron Sheffer
> Sent: Saturday, December 31, 2011 2:26 PM
> To: Dacheng Zhang(Dacheng)
> Cc:
ipsec@...; 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
> >
IPsec@...
> >
https://www.ietf.org/mailman/listinfo/ipsec>
> _______________________________________________
> IPsec mailing list
>
IPsec@...
>
https://www.ietf.org/mailman/listinfo/ipsec_______________________________________________
IPsec mailing list
IPsec@...
https://www.ietf.org/mailman/listinfo/ipsec