On Wed, Apr 14, 2021 at 6:55 AM Balázs Lengyel <[email protected]> wrote:
> Hello Andy, > > I remember when we wrote these rules, we were concentrating on config and > did not spend much time considering state data. > > > > There are rules that are good for config but not for state. E.g. > > - RFC7950 does not allow changing the mandatory statement from false > to true; as this could make a valid configuration that does not include an > optional leaf invalid. > - On the other hand, changing a state leaf from mandatory false to > true means always including the leaf in a <get> response. That should be a > compatible change. > > Do you agree, that at least in some cases different compatibility rules > for state and configuration data makes sense? > I do not agree that this change is needed in the YANG standard. I do agree that sometimes the YANG change rules get violated. If this happens then incrementing the major version number may alert a developer that NBC changes exist in a new module revision. IMO a new YANG RFC is needed in order to contradict ANY NORMATIVE TEXT in RFC 7950. The alternative seems to be to create 2 separate YANG compatibility tracks, one called YANG 1.1 and another for "NBC-capable YANG". As if routinely breaking backward compatibility was a good thing Regards Balazs > > Andy > > > *From:* netmod <[email protected]> *On Behalf Of *Sterne, Jason > (Nokia - CA/Ottawa) > *Sent:* 2021. április 13., kedd 20:30 > *To:* Andy Bierman <[email protected]> > *Cc:* [email protected] > *Subject:* Re: [netmod] YANG Versioning Weekly Call Minutes - 2021-04-13 > > > > Hi Andy, > > > > Thx for taking a look. > > > > Yes - agree with the "orderly" comment. That was very brief shorthand for > the minutes. By "remove" it could even just mean marking as "obsolete" > (with deprecated as an optional intermediate step). > > > > We aren't trying to redefine the rules for config. But it is worth > considering whether some of those aren't really good for state. > Implementations may be ignoring some of those rules for state because they > don't really fit. > > > > Jason > > > > *From:* Andy Bierman <[email protected]> > *Sent:* Tuesday, April 13, 2021 2:16 PM > *To:* Sterne, Jason (Nokia - CA/Ottawa) <[email protected]> > *Cc:* [email protected] > *Subject:* Re: [netmod] YANG Versioning Weekly Call Minutes - 2021-04-13 > > > > > > > > On Tue, Apr 13, 2021 at 7:12 AM Sterne, Jason (Nokia - CA/Ottawa) < > [email protected]> wrote: > > YANG Versioning Weekly Call Minutes - 2021-04-13 > > > > Primary discussion was around the BC/NBC rules for state. > > > > Value space for config false: > > - more informative if you actually remove the enum from the model if it > isn't used anymore (vs leaving it in and servers just not returning it) > > - a server implementation should deviate if it doesn't return something > ever (schema should try to accurately define the API) > > - standard module -> remove the item if it isn't part of the API anymore > > > > > > I assume you mean to use the status-stmt to transition from current -> > deprecated -> obsolete > > in an orderly fashion. Especially since sec 11 is very clear: > > > > Obsolete definitions MUST NOT be removed from published modules, > > since their identifiers may still be referenced by other modules. > > > > > > > > - NMDA operational DS has a copy of config true, so increased value space > in config automatically casues increased value space in "state" > (operational) > > - a config true MTU in the operational DS and a dedicated config false > "oper-mtu" leaf should have the same rules for increasing value space > > > > Maybe a better formulation of the state rules is to take the 7950 rules > and apply minimal text changes. Rob will take a stab at this. > > > > 7950: > > o A "must" statement may be removed or its constraint relaxed. > > > > Adjusted 7950 text: > > o A "must" statement may be added, removed, or changed > > > > > > 7950: > > o A "range", "length", or "pattern" statement may expand the allowed > > value space. > > Adjusted 7950: > > o A "range", "length", or "pattern" statement may expand or reduce the > allowed > > value space. > > > > > > I strongly object to this WG creating an "adjusted YANG 1.1" standard. > > IMO there is no need or WG consensus to create any sort of replacement for > RFC 7950. > > > > If YANG 1.1 needs non-backward-compatible changes (which it doesn't IMO) > then a new > > YANG 2.0 RFC must be written to accomplish that. > > > > It is possible to introduce support for NBC changes in a way that does not > change YANG 1.1 > > at all. E.g.: > > > > Rule 1 of 1: > > - If any change is made that violates a MUST or MUST NOT provision of > RFC 7950, > > sec. 11, then the major revision number in the semver string MUST be > incremented. > > > > > > > > > > Jason > > > > Andy > > > > > > ---------------------------------------------- > > Weekly webex call details: > > Meeting number (access code): 171 069 0374 > > Meeting password: semver? > > Occurs every Tuesday effective Tuesday, September 1, 2020 until Tuesday, > August 24, 2021 from 9:00 AM to 10:00 AM, (UTC-04:00) Eastern Time (US & > Canada) > > 9:00 am | (UTC-04:00) Eastern Time (US & Canada) | 1 hr > > https://ietf.webex.com/ietf/j.php?MTID=ma7627a2ae7b770537cff5f5b89293c70 > > Tap to join from a mobile device (attendees only) > > +1-650-479-3208,,1710690374## Call-in toll number (US/Canada) > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod > >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
