On Sat, Dec 31, 2011 at 7:29 PM, <[email protected]> wrote: > 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.)
The question, for me, is: do "Historic", "retired", and "obsolete" refer strictly to the ability of new standards to depend on the old ones, or does it go further to requiring implementors to also obsolete (i.e., declare intention to remove) the feature from their products? Section 6.4 is a bit more specific: As the technology changes and matures, it is possible for a new Standard specification to be so clearly superior technically that one or more existing standards track specifications for the same function should be retired. 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. [...] Elsewhere we have a requirement that normative references of standards-track documents not be to non-stantards-track documents. That helps me interpret RFC2026 as limiting the effect of "Historic" to forbidding the dependence of new standards on old ones. Do we have any reason to imagine that AH will ever be sufficiently more appropriate than ESP for any protocol that we are not yet ready to retire AH? I don't, but maybe I'm not imaginative enough. For the record, and with the above understanding of the meaning of "Historic", I'm firmly in support of the proposal that we move AH to Historic. Nico -- _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
