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

[Ladislav Lhotka <[e-mail]>]

Martin Bjorklund píše v St 06. 09. 2017 v 10:49 +0200:
> Radek Krejčí <[e-mail]> wrote:
> > Dne 6.9.2017 v 08:52 Martin Bjorklund napsal(a):
> > > 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;
> > >      }
> > >    }
> > 
> > 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.

But it also affect augments, and the author of the module where something is
being deprecated may not have access to the augmenting module.

Lada

> 
> > > > 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67