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

[Andy Bierman <[e-mail]>]

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)
>
>
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?
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.


> K.
>
>
>
>
>
Andy