Ladislav Lhotka <lho...@nic.cz> wrote:
> Martin Bjorklund <m...@tail-f.com> writes:
>
> > Robert Wilton <rwil...@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
>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
