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

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.

> 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
> 