Juergen Schoenwaelder <[email protected]> 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 _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
