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

[Martin Bjorklund <[e-mail]>]

Juergen Schoenwaelder <[e-mail]> wrote:
> 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.

I think that marking the uses statement with status deprecated should
mean that all nodes in the grouping are "auto-refined" with status
deprecated.  Listing them all in explciit refine doesn't help
anyone imo.


/martin