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> > 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 -- 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 [email protected] https://www.ietf.org/mailman/listinfo/netmod
