On Tue, Sep 5, 2017 at 11:54 PM, Martin Bjorklund <m...@tail-f.com> wrote:
> Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de> 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.
>
>
Lifecycle status of abstract definitions (identity, typedef, grouping)
should only
be changed it applies to all possible usage of the definition. Modules that
use
these external definitions should only override the deprecated or obsolete
status
with extreme caution.
The uses-stmt should not even have a status-stmt since conformance is only
for the
conceptual grouping expansion, not for the grouping or the uses statements.
The only useful interpretation is that it applies to actual data nodes
(after all
nested groupings have been expanded).
I would refine your "auto-refine" a bit :-)
It does not increase the status enum, just lower it to the uses-stmt status
value
uses(current) -> do not convert any status during expansion
uses(deprecated) --> convert current to deprecated; leave obsolete
unchanged
uses(obsolete) --> convert current and deprecated to obsolete
There is still no ability to say that an expanded data node is deprecated,
e.g., deprecate some but not all of the nodes from the uses expansion.
> /martin
>
>
Andy
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
