Re: [netmod] YANG Versioning Weekly Call Minutes - 2021-04-13

On Wed, Apr 14, 2021 at 6:55 AM Balázs Lengyel <balazs.lengyel@ericsson.com>
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 <netmod-bounces@ietf.org> *On Behalf Of *Sterne, Jason
> (Nokia - CA/Ottawa)
> *Sent:* 2021. április 13., kedd 20:30
> *To:* Andy Bierman <andy@yumaworks.com>
> *Cc:* netmod@ietf.org
> *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 <andy@yumaworks.com>
> *Sent:* Tuesday, April 13, 2021 2:16 PM
> *To:* Sterne, Jason (Nokia - CA/Ottawa) <jason.sterne@nokia.com>
> *Cc:* netmod@ietf.org
> *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) <
> jason.sterne@nokia.com> 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
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
>