On 03-Jan-26 05:58, Fernando Gont wrote:
On 02/01/2026 13:33, Robinson, Herbie wrote:
This might be an unusual case, because IKE can negotiate around it, but
in general, assuming you can remove a feature you’re your because the
IETF has deprecated it will get you into trouble with your customers/
clients or whatever. The practical meaning of deprecated means you
don’t have to support it in new implementations and should try to stop
fixing bugs in it.
If you plan to use it one way or another, you have to address security
bugs. (Otherwise it feels a bit like, in the context of software
development, folks asking to archive repos so that they don't need to
process SAST security alerts, but then otherwise use and reference such
repos).
In the context of the IETF, I seem to recall there was a discussion
about what e.g. Deprecated means (probably an RFC). And IIRC it boils
down to "we believe this is not a great idea anymore".
As far as I know, the IETF has never adopted a general definition of
"deprecate", and the various RFCs that use the word "deprecate", or that
achieve the same effect using other words, are all tailored to the particular
case. But really they all amount to "SHOULD NOT" which is well defined in
RFC 2119:
"4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that
there may exist valid reasons in particular circumstances when the
particular behavior is acceptable or even useful, but the full
implications should be understood and the case carefully weighed
before implementing any behavior described with this label."
Thus, the decision is left to implementors and operators. Deciding to
write down a SHOULD NOT for AH (or EH in general) is the only thing the
IETF can do.
Whether this should be implemented by a sysctl, a compile-time option,
or by removing the code really isn't an IETF question.
A MUST NOT would be stronger than deprecation but I really doubt
that there would be consensus for that, because we literally cannot
know whether there is current running code somewhere that depends
on AH.
That said, if I had to, the first phase would be to implement a sysctl
that can disable the feature -- such that you can still accommodate
folks that use the feature if you need to.
Thanks,
_______________________________________________
Int-area mailing list -- [email protected]
To unsubscribe send an email to [email protected]
