Re: [netmod] Obsolete feature - what does it mean?

Kent Watsen <> Wed, 27 February 2019 18:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BFDE013108E for <>; Wed, 27 Feb 2019 10:17:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id a2zJNifW9nxB for <>; Wed, 27 Feb 2019 10:17:11 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 383B313109B for <>; Wed, 27 Feb 2019 10:17:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug;; t=1551291429; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=WvCih2vQVVUmjSXitFztRrg7oKL+9llq3So9jqHaJiI=; b=hGamVEgCgzbtlbGDuxr3p5qIL9gTywQ+BrNnpVHboEVBtYeBAG7wVHpIenvGSIwm G/Hu2+vfoApYyPYwVifyC7RH9lp5h711zwmuffjzSd59DbzuMhTQteeOY8ntuiYNLyL 04WhHpYc8BhfBqPk12szzhbPWIVg3+JTMoUGamJc=
From: Kent Watsen <>
Message-ID: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_C299E246-400A-4B0A-AD16-870EDBCFE5D4"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Wed, 27 Feb 2019 18:17:09 +0000
In-Reply-To: <>
Cc: Balázs Lengyel <>, "" <>
To: Juergen Schoenwaelder <>
References: <> <> <> <> <>
X-Mailer: Apple Mail (2.3445.102.3)
X-SES-Outgoing: 2019.02.27-
Archived-At: <>
Subject: Re: [netmod] Obsolete feature - what does it mean?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 27 Feb 2019 18:17:14 -0000

> On Feb 27, 2019, at 11:48 AM, Juergen Schoenwaelder <> wrote:
> On Wed, Feb 27, 2019 at 04:09:17PM +0000, Kent Watsen wrote:
>>> On Feb 27, 2019, at 6:16 AM, Balázs Lengyel <> wrote:
>>> feature oldFeature {
>>>  status obsolete;
>>> }
>>> leaf myTimer {
>>>  if-feature oldFeature ;
>>>  mandatory true;
>>>  config true;
>>>  status current;
>>>  type string;
>>> }
>>> So should I configure myTimer or not? I assume yes, correct?
>> This issue is captured here:, which was updated as of this morning with this very example.
>> Of course, the problem is in RFC 7950:
>>   o  "obsolete" means that the definition is obsolete and SHOULD NOT be
>>      implemented and/or can be removed from implementations.
>> I recommend replacing "SHOULD NOT be implemented" with "is not implemented".
> When an IETF WG decides to obsolete something, I am forced to break
> old clients because of this decision? Note sure this makes business
> sense (says an academic).
> There is a huge difference between modules where the implementors have
> change control over the modules and modules where change control is
> far outside the implementors hands and where clients and servers are
> implemented by different organizations in an open and largely
> uncoordinated way. We always have to keep this in mind when we create
> rules.
> The SHOULD NOT allows a server implementor to take a well-informed
> decision that there are old clients you care about and that this makes
> a business case for supporting obsolete definitions on a server.
> Another aspect here is that we do not make a clear distinction between
> server and client. It can very well be that "deprecated" and
> "obsolete" mean slightly different things to servers and
> clients. (Servers tend to have a natural desire to not break clients
> unnecessarily.)

But a server can choose to not implement that revision of the module or, with <> deviate the "status" statement.

I want "obsolete" to mean as it does everywhere else: out of use, no longer supported, not expected to work, etc.

Perhaps there is a line between having "status obsolete" versus disappearing the node altogether?   Maybe within the same "major" version (to use a sem-ver term), "obsolete" leaves it to the server's discretion, whereas the next major version disappears the node?

If so, then there should be a way for the server to indicate which discretionary choices it made.   I'd suggest that "obsolete" defaults to "not-implemented" and thus only servers that want to continue support for the node need to indicate anything.  A deviation would be a good fit for this.

Kent // contributor