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

From: Balázs Lengyel <[email-masked]>
Date: Wed, 27 Feb 2019 10:19:55 +0000

Hello,

The feature statement may have a status substatement. But what
does it mean if a feature is deprecated or obsolete? Some ideas:

All if-feature statements using it should be removed. But what
to do with "if-feature oldFeature AND otherFeature" ;

The feature is always considered true/false

this is a bug in rfc7950, there should not be such a
substatement

something else

regards Balazs

--
Balazs Lengyel Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909 email: [email-masked]

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 27 Feb 2019 11:33:03 +0100

On Wed, Feb 27, 2019 at 10:19:55AM +0000, Balázs Lengyel wrote:
>    Hello,
> 
>    The feature statement may have a status substatement. But what does it
>    mean if a feature is deprecated or obsolete? Some ideas:
> 
>      * All if-feature statements using it should be removed. But what to do
>        with "if-feature oldFeature AND otherFeature" ;
>      * The feature is always considered true/false
>      * this is a bug in rfc7950, there should not be such a substatement
>      * something else
>

Deprecated means the feature is deprecated, you should not use it in
new definitions. A feature is not "true or false", a feature can be
implemented or not. A current definition being conditional on a
deprecated feature may be something tools should warn about.

Obsolete means the feature is obsolete, it likely should only be used
in obsolete definitions. A current definition likely should not depend
on an obsolete feature and if that happens, then likely brainware
needs to look at the situation and resolve it.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Balázs Lengyel <[email-masked]>
Date: Wed, 27 Feb 2019 11:16:55 +0000

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?

regards Balazs

On 2019. 02. 27. 11:33, Juergen
Schoenwaelder wrote:

Hello,

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 27 Feb 2019 13:34:25 +0100

>    So should I configure myTimer or not? I assume yes, correct?

Your server will tell you by announcing the features it implements.

The compiler used by the server developer will likely tell him that
there is something to look at.

/js

---

From: Kent Watsen <[email-masked]>
Date: Wed, 27 Feb 2019 16:09:17 +0000

> On Feb 27, 2019, at 6:16 AM, Balázs Lengyel <[email-masked]> wrote:
> 
> feature oldFeature {
>   status obsolete;
> }
> leaf myTimer {
>   if-feature oldFeature ;
>   mandatory true;
>   config true;
>   status current;
>   type string;
> }

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".   

Then the answer to your question above would be "no", as "if-feature" takes precedence.

Kent

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 27 Feb 2019 17:48:16 +0100

> 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.)

/js

---

From: Andy Bierman <[email-masked]>
Date: Wed, 27 Feb 2019 09:27:04 -0800

On Wed, Feb 27, 2019 at 8:48 AM Juergen Schoenwaelder <
[email-masked]> wrote:

> > 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.
> >

There is a huge difference between conformance and server capabilities.
The status-stmt is about conformance -- the expected usage for any
implementation
of the particular statement.

Whether a server actually implements something that is deprecated or
obsolete
is a completely different issue.

(It is also another issue that YANG got the deprecated status completely
wrong)

Andy

> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: Kent Watsen <[email-masked]>
Date: Wed, 27 Feb 2019 18:17:09 +0000

> On Feb 27, 2019, at 11:48 AM, Juergen Schoenwaelder <[email-masked]> wrote:
> 

But a server can choose to not implement that revision of the module or, with https://github.com/netmod-wg/yang-next/issues/63 <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

---

From: Randy Presuhn <[email-masked]>
Date: Wed, 27 Feb 2019 10:42:05 -0800

Hi -

On 2/27/2019 10:17 AM, Kent Watsen wrote:
...
> 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.

Are you saying that legacy boxes sitting in dark closets
would somehow be updated to provide this indication?

Randy

---

From: Kent Watsen <[email-masked]>
Date: Wed, 27 Feb 2019 20:09:44 +0000

Hi Randy,

> would somehow be updated to provide this indication?

Assuming YANG-next resolves the issue, and there is sufficient motivation then, yes, sys-admins would need to blow the dust off their servers (and clients) and update them to YANG-next.  Otherwise, the status-quo prevails, which may be okay for some.

Kent

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Thu, 28 Feb 2019 09:40:54 +0000

Hi Randy,

Please see inline with [RW] ...

-----Original Message-----
From: netmod <[email-masked]> On Behalf Of Randy Presuhn
Sent: 27 February 2019 18:42
To: [email-masked]
Subject: Re: [netmod] Obsolete feature - what does it mean?

Hi -

> 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.

Are you saying that legacy boxes sitting in dark closets would somehow be updated to provide this indication?

[RW] 
Actually, I don't think that would be required.  Obsoleting a node requires a new revision of the YANG module, so it only depends on which revision of the YANG model is implemented by the device.  Hence, if you update the legacy box to use the new YANG module which now contains status obsolete nodes, that you should also update the legacy box software at the same time to not implement the obsoleted nodes.

Thanks,
Rob

Randy

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Thu, 28 Feb 2019 09:49:17 +0000

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 <[email-masked]> On Behalf Of Kent Watsen
Sent: 27 February 2019 18:17
To: Juergen Schoenwaelder <[email-masked]>
Cc: [email-masked]
Subject: Re: [netmod] Obsolete feature - what does it mean?

On Feb 27, 2019, at 11:48 AM, Juergen Schoenwaelder <[email-masked]<mailto:[email-masked]>> wrote:

On Feb 27, 2019, at 6:16 AM, Balázs Lengyel <[email-masked]<mailto:[email-masked]>> wrote:

feature oldFeature {
 status obsolete;
}
leaf myTimer {
 if-feature oldFeature ;
 mandatory true;
 config true;
 status current;
 type string;
}

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.

Kent // contributor