Re: [netmod] Does the YANG "status" statement inherit from its parent node?

On Wed, Dec 21, 2016 at 1:32 AM, Martin Bjorklund <mbj@tail-f.com> wrote:

> Ladislav Lhotka <lhotka@nic.cz> wrote:
> > Martin Bjorklund <mbj@tail-f.com> writes:
> >
> > > Robert Wilton <rwilton@cisco.com> wrote:
> > >> Hi,
> > >>
> > >> The definition of "status" in RFC 7950 in section 7.21.2 (full text
> > >> below), states:
> > >>
> > >> If no status is specified, the default is "current".
> > >>
> > >> From my interpretation of the text in the draft, this implies that the
> > >> status of the "new" child leaf in the following example is "current",
> > >> and that this example is allowed!
> > >>
> > >> My questions are:
> > >>  - Is my interpretation of the current text correct?
> > >
> > > Yes.
> > >
> > >>  - Is this actually the best behaviour, or should it inherit like the
> > >>    config statement?
> > >
> > > I think the idea was that if the status != current, it is better for
> > > the reader if it is explicitly stated.
> > >
> > >>  Should I raise an errata for this?
> > >
> > > No.
> > >
> > > However, we could have said that a current node under a deprecated
> > > node (etc) in the same module is an error, in order to force people
> > > (through the useage of YANG validators) to detect and fix this.
> >
> > Since "current" is the default, correctly deprecating a subtree would
> > mean to explicitly add the "status" statement to every single node in
> > the subtree.
>
> Yes.
>

Please explain what it means for YANG to say
"The parent node is deprecated and going away but the child nodes are not.
They are current and are staying around."  This does not seem to make any
sense.

Clearly an obsolete node removes all access of its descendant nodes.
There is no way to access /foo/child if /foo has been removed from the
server.
So how do I access a deprecated /foo/child node inside an obsolete /foo
container?

Andy

>
> > I think that "obsolete" should apply to the whole subtree, no matter
> > what status descendants have, and "deprecated" should apply to the whole
> > subtree except for parts that are obsolete.
>
> Maybe, but this is not how it works in YANG 1 and 1.1.  For the
> reasoning behind this, see above.  Maybe this is not perfect, and
> something that we should look into if we update YANG.  But I don't
> think this is a problem.
>
>
> /martin
>
>
>
> >
> > Lada
> >
> > >
> > >
> > > /martin
> > >
> > >
> > >
> > >>
> > >> container old {
> > >>   status deprecated;
> > >>   leaf new {
> > >>     description "what status do I have?";
> > >>   }
> > >> }
> > >>
> > >> Thanks,
> > >> Rob
> > >>
> > >>
> > >> Full 7.21.2 text from 7950:
> > >>
> > >> 7.21.2.  The "status" Statement
> > >>
> > >>    The "status" statement takes as an argument one of the strings
> > >>    "current", "deprecated", or "obsolete".
> > >>
> > >>    o  "current" means that the definition is current and valid.
> > >>
> > >>    o  "deprecated" indicates an obsolete definition, but it permits
> > >>       new/continued implementation in order to foster interoperability
> > >>       with older/existing implementations.
> > >>
> > >>    o  "obsolete" means that the definition is obsolete and SHOULD NOT
> be
> > >>       implemented and/or can be removed from implementations.
> > >>
> > >>    If no status is specified, the default is "current".
> > >>
> > >>    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
> > >>      }
> > >>
> > >
> > > _______________________________________________
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netmod
> >
> > --
> > Ladislav Lhotka, CZ.NIC Labs
> > PGP Key ID: 0xB8F92B08A9F76C67
> >
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>