Hi, YANG data is hierarchical. It makes no sense at all the consider the descendant nodes current when the parent is deprecated or obsolete. If the parent goes away then it is impossible to access any descendant nodes, so the default status of 'current' is meaningless in this case.
If you augment somebody else's subtree and they decide to deprecate or obsolete it, your data is also deprecated or obsolete. That's how hierarchcal data works. Andy On Wed, Dec 21, 2016 at 2:30 PM, Juergen Schoenwaelder < [email protected]> wrote: > 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: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 <http://www.jacobs-university.de/> >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
