Re: [netmod] 'status' statement needed on every node

[Juergen Schoenwaelder <[e-mail]>]

On Tue, Sep 05, 2017 at 10:50:03PM +0000, Kent Watsen wrote:
> 
> 
> 
> >> I still don't know what it means to define hierarchical data and say the
> >> parent is deprecated but not the descendant nodes.
> >
> > It is odd but can happen anyway. A current augmentation of something
> > that got deprecated likely stays current. I would hope that tools warn
> > if they see this but that's it.
> 
> This example seems to provide support for saying status should be
> inherited.

No, I do not support your conclusion. I think it is crucial that
whoever maintains an augmenting module is actually aware that his
module depends on something deprecated. Silently deprecating (and
eventually obsoleting) definitions maintained by other parties is in
my view not a good idea. It is far better to clearly indicate that
there is some work to do by the augmenting module maintainer.

> But, to be clear, you agree that if a parent is deprecated,
> than its decedents should be deprecated as well, right? 

Yes.
 
> >> This is rather non-intuitive, as is the idea that all descendant
> >> nodes need to be manually edited (status is not inherited).
> >
> > Not a big deal. The benefit is that a reader like me knows clear that
> > the definition I am look at is deprecated, no need to search backwards
> > to find out.
> 
> tree diagrams do this too, though I like Martin's approach of removing
> the deprecated -state trees from the tree diagram altogether.
> 
> 
> 
> >> It also means the objects expanded from groupings cannot ever be
> >> changed (clearly a bug in YANG).
> >
> > Yes, bug in YANG.
> 
> Is this the same issue I raised?
> 
>   import ietf-foo {
>     prefix f;
>   }
> 
>   container bar {
>     uses f:foo;
>   }
> 
>   container baz {
>     status deprecated;
>     uses f:foo;            <-- oops, descendants not deprecated!
>   }                           (not a problem if status inherited)

I think I look at this very differently. If something is defined in
f:foo that is current, then this is inherited where f:foo is
used. What we need is a way to refine that if the usage context has
differnet requirements, like we allow to refine other properties of a
grouping to adapt it to the usage context.

/js

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