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

["Rob Wilton (rwilton)" <[e-mail]>]

Unfortunately a deviation is not a good fit to mark that an obsolete node is implemented.

Assuming that I’m reading RFC 7950 correctly, it doesn’t allow you to “deviate add” a data node, nor can you change the status (e.g. from obsolete to deprecated).  So, I think that we would need to change the capabilities of the deviate statement in YANG Next if we wanted to go down this path.  Although, I’m not actually convinced that it is really required/helpful.

My thoughts on this:

1) Deprecated nodes should always be implemented, i.e. effectively handled the same as if they were status "current" but annotated that they will disappear in future. Perhaps this can be changed by fixing the language (e.g. in YANG Next) and/or through a "deprecated-nodes-implemented" leaf reported in YANG library (e.g. in the Semver draft).

2) Obsoleted nodes SHOULD NOT be used by a client, and SHOULD NOT be implemented by a server.  I think that RFC 7950 pretty much says this today anyway.

I don't think that it helps to force a server to remove them.  The Semver draft also has a leaf to indicate whether or not all obsolete nodes are implemented, but I'm not that convinced that it is truly useful.  In that I think that the rules above still give implementation flexibility but should still be sufficient for reasonable interop.

Thanks,
Rob


From: netmod <[e-mail]> On Behalf Of Kent Watsen
Sent: 27 February 2019 18:17
To: Juergen Schoenwaelder <[e-mail]>
Cc: [e-mail]
Subject: Re: [netmod] Obsolete feature - what does it mean?




On Feb 27, 2019, at 11:48 AM, Juergen Schoenwaelder <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> 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: https://github.com/netmod-wg/yang-next/issues/27, 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 https://github.com/netmod-wg/yang-next/issues/63 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