Re: [netmod] Shepherd review on draft-ietf-netmod-yang-instance-file-format-10

[Kent Watsen]

Hi Balazs,

Please find my comments below.

K.


> On Apr 7, 2021, at 9:56 AM, Balázs Lengyel  
> wrote:
> 
> Hello Kent,
> Thanks for the thorough review and sorry for my absence and hence the earlier 
> slow response.

Join the club ;)


> See answer below as BALAZS4. Removed already agreed parts.
> What is the next step?

Time for me to attempt the shepherd writeup again, and then publish it for IESG 
review.

K.


> Regards Balazs
>  
> From: Kent Watsen mailto:kent+i...@watsen.net>> 
> Sent: 2021. április 2., péntek 2:20
> To: Balázs Lengyel  >
> Cc: netmod@ietf.org 
> Subject: Re: [netmod] Shepherd review on 
> draft-ietf-netmod-yang-instance-file-format-10
>  
> Please see below for responses.  (One question pending)
>  
> Kent // shepherd
> 
> On Mar 23, 2021, at 6:01 PM, Balázs Lengyel  > wrote:
>  
> Hello Kent,
> I am resuming my work on draft-ietf-netmod-yang-instance-file-format. 
> Regards Balazs
>  
>  
> From: Kent Watsen mailto:kent+i...@watsen.net>> 
> Sent: 2020. április 9., csütörtök 22:11
> To: Balázs Lengyel  >
> Cc: netmod@ietf.org 
> Subject: Re: [netmod] Shepherd review on 
> draft-ietf-netmod-yang-instance-file-format-10
>  
> Hi Balazs,
>  
> BTW, I assume that you wish to publish this as-is and follow-up later with an 
> update to adjust for the “semver” work - correct?
> K.
>  
> BALAZS4:  Yes, correct. 

Ack.


> Semver will take time and may undergo changes, so it would be too early to 
> adapt this draft/RFC to it. However, two items already deal with Semver:
> The instance data files themselves will not have a Semver revision as the 
> concept of compatibility is not defined for instance data.
> The YANG module ietf-yang-instance-data already includes:
>  “... If other methods
> (e.g., revision-label) are defined to identify
> individual module revisions those MAY be used
> instead of using a revision date.”

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] I-D Action: draft-ietf-netmod-rfc6991-bis-06.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Modeling WG of the IETF.

Title   : Common YANG Data Types
Author  : Juergen Schoenwaelder
Filename: draft-ietf-netmod-rfc6991-bis-06.txt
Pages   : 41
Date: 2021-04-14

Abstract:
   This document introduces a collection of common data types to be used
   with the YANG data modeling language.  This document obsoletes RFC
   6991.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6991-bis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netmod-rfc6991-bis-06
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc6991-bis-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc6991-bis-06


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Andy Bierman]

On Wed, Apr 14, 2021 at 6:55 AM Balázs Lengyel 
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  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 think this is a topic for the yang-next list.
There is a list of about 100 issues that people would like to fix or change
in YANG.
If the WG ever decides to work on yang-next then I will be happy to
participate in that work.

IMO the YANG-based approach to dealing with NBC in the wild in not going to
work.
Improvements to the protocol will help but they are not in scope here.
Support for warnings would help real implementations right now.
It was a mistake to remove (rather than fix) warnings in NETCONF (and
now also RESTCONF).




> Regards Balazs
>
>
>

Andy


> *From:* netmod  *On Behalf Of *Sterne, Jason
> (Nokia - CA/Ottawa)
> *Sent:* 2021. április 13., kedd 20:30
> *To:* Andy Bierman 
> *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 
> *Sent:* Tuesday, April 13, 2021 2:16 PM
> *To:* Sterne, Jason (Nokia - CA/Ottawa) 
> *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.ste...@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 

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

[Andy Bierman]

On Wed, Apr 14, 2021 at 6:55 AM Balázs Lengyel 
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  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  *On Behalf Of *Sterne, Jason
> (Nokia - CA/Ottawa)
> *Sent:* 2021. április 13., kedd 20:30
> *To:* Andy Bierman 
> *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 
> *Sent:* Tuesday, April 13, 2021 2:16 PM
> *To:* Sterne, Jason (Nokia - CA/Ottawa) 
> *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.ste...@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 

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

[Juergen Schoenwaelder]

On Wed, Apr 14, 2021 at 01:55:04PM +, Balázs Lengyel wrote:

> * On the other hand, changing a state leaf from mandatory false to true 
> means always including the leaf in a  response.

Where do you get this from?

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Balázs Lengyel]

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  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?

Regards Balazs

 

From: netmod  On Behalf Of Sterne, Jason (Nokia - 
CA/Ottawa)
Sent: 2021. április 13., kedd 20:30
To: Andy Bierman 
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 mailto:a...@yumaworks.com> > 
Sent: Tuesday, April 13, 2021 2:16 PM
To: Sterne, Jason (Nokia - CA/Ottawa) mailto:jason.ste...@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) 
mailto:jason.ste...@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



smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod