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

On Tue, Sep 5, 2017 at 11:14 AM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> On Tue, Sep 05, 2017 at 05:40:23PM +0000, Kent Watsen wrote:
> >
> >
> > With all the deprecating of "-state" trees going on these days,
> > the 'status' statement is getting lots of use.
> >
> > I understand that some feel that the status statement needs to be
> > placed on every node, since it is not inherited.  This sentiment
> > likely stems from RFC 7950 stating "If no status is specified,
> > the default is current" and, of course, it not stating that status
> > is inherited.
> >
> > I appreciate that this is just following rules, but it seems
> > excessive and I don't understand how any other interpretation
> > makes sense.
>
> There is in my view no problem worth to be solved and today's YANG
> rules are clear.
>
> <outing>
>   I am a big fan of definitions that can be copied and moved around
>   without changing meaning just because they appear in a different
>   context. I would even prefer to have config true/false not inherited
>   down the schema tree but rather have no config statement default to
>   config true and everything config false needs an explicit
>   statement. Side effect free cut and paste is a feature that is for
>   me worth the price of a few more explicit statements. Even a human
>   reader can skip over these statements very quickly.
> </outing>
>
>

Blind cut-and-paste is not a good design goal.

I still don't know what it means to define hierarchical data and say the
parent is deprecated but not the descendant nodes.

This is rather non-intuitive, as is the idea that all descendant nodes need
to
be manually edited (status is not inherited).  It also means the objects
expanded from
groupings cannot ever be changed (clearly a bug in YANG).

We have not seen these issues yet because this is the first time 'status
deprecated'
is being used.

> > Also I question how it's supposed to work for a grouping that
> > is used once in a deprecated tree and again in a not deprecated
> > tree.  What if the grouping is defined in another RFC?  Would
> > we need to copy the grouping into the current module in order
> > to set status deprecated on all of its nodes?
>
> It would be nice to simply use refine but unfortunately section 7.13.2
> of RFC 7950 does not allow to refine the status (which in my view is
> an oversight but the RFC says what it says).
>
> /js
>
>
Andy

> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>