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

[Juergen Schoenwaelder <[e-mail]>]

On Wed, Dec 21, 2016 at 08:21:08AM -0800, Andy Bierman wrote:
> 
> IMO the default should be inherit from parent, like the config-stmt.
> It clutters the YANG module to add a status-stmt to every descendant node.

Yes, explicit status statements clutter the module but they make it
very explicit for the reader that stuff is deprecated or obsolete.  In
SMIv2, we had explicit status clauses everywhere and I have been a big
fan of making current a default so this does not clutter the
module. But I am also a big fan of making a status != current very
explicit so a reader knows for sure which definitions can be ignored.
(Perhaps it is just me but I often search in RFCs and/or YANG modules
and then having to track back the tree to find out whether something I
hit is deprecated or obsolete is a real burden. (In hindsight, I
probably would have preferred to have config true not inherited but
work like the status statement - having to search along the nesting
structure to find out what something means is actually not that reader
friendly - and bits are cheap these days. And the priority order back
in a day was 'readers first, writers second, tool makers last'.)

> The status also applies to augment.  If /foo is deprecated than any
> external augments that adds nodes under /foo is also deprecated.
> (Most obvious when you change deprecated to obsolete).

I may disagree with this, in particular for 'deprecated'. Assuming
there are multiple organizations involved, I think we have a problem
if one organization can deprecate augmentations maintained by another
organization.

Deprecated essentially says 'this will go away, stop using it if you
can'.

> >   container a {
> >     status deprecated;
> >     container b {
> >       status current;
> >     }
> >   }

I think this example is actually not complete non-sense. It says 'this
container will go away, stop using it if you can'. There is still
something current under it and this should be fixed. And this is in
particular true for augmentations, e.g.,

augment /a {
  container c {
  }
}

should be OK - tools may generate warnings to tell the maintainer of
the augmentation to pay attention to the fact that /a may get retired.

Now, the IETF may decide that for published modules, something current
in a deprecated container is to be avoided. But this is then a policy
decision, from the language point of view I consider the case of
something current under a deprecated container not a real error.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <http://www.jacobs-university.de/>