There are literally billions of computers connected to the Internet (not counting mobile phones). How can you prove that a feature isn't being used?
Putting out a warning and saying "No-one complains" doesn't cut it, because a lot of users ignore warnings and it's impossible to check a billion computers for warnings. This really comes down a judgement call and it depends on what feature you are talking about and what system you are talking about. Arguments for removing deprecated features: o You remove the risk of users who still use it hitting bugs. o You remove the cost of any maintenance. Arguments against removing deprecated features: o Users will never upgrade any of their systems to pick up bug fixes because they don't have time to reconfigure something, or worse, because they have an old system that is critical to their business and they can't upgrade it. This will hurt your reliability numbers much more than having unused AH code sitting in there. One of the things we learned early on at Stratus is that the single biggest factor in terms of overall system reliability is getting users to update to the latest bug fix release. They won't do that if you make incompatible changes. o You will spend more time fielding the angry complaints from customers who are unable to figure out why you suddenly broke it (that's always their perspective) than you would leaving the feature in. Note that it usually works to tell customers you don't fix bugs in deprecated features; so, the maintenance load for leaving them in is very little. So, my point is that, yes, we should deprecate AH, because it's a maintenance nightmare from the standpoint of implementing new features. But we shouldn't be assuming that "deprecate" means it's going to actually disappear any time soon. From the IETF point of view, "deprecate" can only mean we aren't going to update any new standards to accommodate AH. > -----Original Message----- > From: Tom Herbert <[email protected]> > Sent: Friday, January 2, 2026 11:51 AM > To: Robinson, Herbie <[email protected]> > Cc: Fernando Gont <[email protected]>; int-area <[email protected]>; > 6MAN <[email protected]> > Subject: Re: [Int-area] Re: [IPv6]Re: Fwd: New Version Notification for draft- > herbert-deprecate-auth-header-00.txt > > On Fri, Jan 2, 2026 at 8:33 AM Robinson, Herbie > <[email protected]> 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. In the case of AH, > deprecation means that we don’t have to figure out what to do about every new > case where it’s incompatible with some new Internet protocol (or the existing > places where it doesn’t work). > > Herbie, > > If a protocol is deprecated that should mean that no one is using it or the > code > that implements it. In that case, we want to remove unused code from > implementations because maintaining the it is not without cost and > unused/untested code becomes a liability and a risk when someone tries to use > it. > > To deprecate a protocol like this we can take a phased approach that has been > used for other features being deprecated. First, we'll disable it to be > compiled > by default and give a nice warning that the protocol is being deprecated. Once > that's fully deployed and if no one complains the feature is being deprecated > then the code for the protocol can safely be removed. > > Tom _______________________________________________ Int-area mailing list -- [email protected] To unsubscribe send an email to [email protected]
