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
>