Radek Krejčí <[email protected]> wrote:
> Dne 6.9.2017 v 08:52 Martin Bjorklund napsal(a):
> > Andy Bierman <[email protected]> wrote:
> >> On Tue, Sep 5, 2017 at 3:50 PM, Kent Watsen <[email protected]> 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;
> > }
> > }
>
> despite I see this explanation of status in uses as useful, I don't
> see anything in RFC that would support this.
I'm just saying that also "uses" can, and should be in this case,
marked as 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.
>
> what about the mandatory nodes inside a deprecated container?
> Formally, they are not deprecated (default status is current) so
> still mandatory, right?
mandatory or not doesn't matter; mandatory doesn't mean "must
implement", but "must exist if the parent exists".
/martin
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
