Re: [netmod] Does the YANG "status" statement inherit from its parent node?

[Randy Presuhn <[e-mail]>]

Hi -

On 12/21/2016 3:55 PM, Andy Bierman wrote:
>
>
> On Wed, Dec 21, 2016 at 3:41 PM, Juergen Schoenwaelder
> <[e-mail]
> <mailto:[e-mail]>> wrote:
...
>     Perhaps I am blinded by the way @deprecate or __attribute__
>     ((deprecated)) or [[deprecated]] work in various programming
>     languages. All these annotations do not deprecate my code, they just
>     cause the generation of warnings so that I get aware of the issue and
>     can do my homework.
>
>
> There are no protocols that let you manage orphaned data nodes
> without any parent.  No way to represent it in XML or JSON either.
> No way to specify a RESTCONF target resource that leaves out
> some intermediate data nodes.

Deprecating (or obsoleting) a definition does not orphan data nodes.
Perhaps I'm blinded by the way SNMP works, but it seems to me that
a robust client will need to be able to process data corresponding
to deprecated (or obsolete) definitions.  Likewise, developers
of server-side software may find themselves in situations where
supporting obsolete definitions is a commercial necessity.  Things
certainly played out that way in the SNMP world.  I agree with Juergen
that tool-generated warnings seem to be the correct way to go.

> It seems obvious that the deprecated warning (this node may go away)
> also applies to all descendant nodes.  Once the node is changed from
> deprecated to obsolete, all the descendant nodes are gone as well,

No, they're not *gone*.  The *advisability* of implementing them has
changed, but the definitions still exist, and implementer judgement
is still needed.  The change in status only means that a client is
less able to rely on the assumption that those definitions will be
supported by a given system - but there's very little that it can
rely on being implemented anyway, so it doesn't really change much
for a robust client.

> so ignoring the warning because YANG says the default is current seems
> unwise.

I do agree with this bit of conclusion, but sometimes after looking
at a warning and considering the larger context, ignoring the
warning *is* the right thing to do.

Randy