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

[Martin Bjorklund <[e-mail]>]

Andy Bierman <[e-mail]> wrote:
> On Tue, Sep 5, 2017 at 3:50 PM, Kent Watsen <[e-mail]> 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.  But, to be clear, you agree that if a parent is deprecated,
> > than its decedents should be deprecated as well, right?
> >
> >
> >
> right -- the RFC says this has to be done manually.
> A missing status-stmt means status=current.
> 
> 
> 
> >
> > >> 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)

As Andy explains below, this should be:

   container baz {
     status deprecated;
     uses f:foo {
       status deprecated;
     }
   }

> According to my interpretation of 7.21.2, this is a MUST NOT:
> 
>    If a definition is "current", it MUST NOT reference a "deprecated" or
>    "obsolete" definition within the same module.
> 
>    If a definition is "deprecated", it MUST NOT reference an "obsolete"
>    definition within the same module.
> 
>    For example, the following is illegal:
> 
>      typedef my-type {
>        status deprecated;
>        type int32;
>      }
> 
>      leaf my-leaf {
>        status current;
>        type my-type; // illegal, since my-type is deprecated
>      }
> 
> The term "reference" is not really defined above.
> It should also clearly apply to "uses" (e.g., your example) and  leafref
> path-stmt.
> 
>    leaf foo {
>      type string;
>      status deprecated;
>   }
> 
>   leaf bar {
>     type leafref { path /foo; }
>   }
> 
> If it apples to path-stmt, then why not all XPath?

B/c in XPath it is even ok to refer to non-existing nodes.  And you
might have things like /baz/*.

> Why doesn't "reference" include descendant nodes?
> 
> The text in 7950 is too strict and can cause a massive ripple-effect when
> any status-stmt is changed.
>  At the same time it is too vague to be useful to implementors.

While I agree that it is not clear what it means to have a "current"
child to a "deprecated" node, I don't think this is a big issue.  If a
node is deprecated, it is ok for an implementation to not implement
it.  Obviously this means that no child nodes to that node is
implemented either, regardless of their status, if they are augmented
in, or comes from a grouping.



/martin