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

[Sterne, Jason (Nokia - CA/Ottawa)]

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) 
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
___
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 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 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
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Sterne, Jason (Nokia - CA/Ottawa)]

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

Jason

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

Re: [netmod] [netconf] YANG Push module errors

[Robert Varga]

On 06/04/2021 09:04, Ladislav Lhotka wrote:
>> I see. Okay, thanks for the clarification and yes, if this was explicitly 
>> mentioned in the RFC it would be great. Although, the validity of your 
>> example was not in question. Rather something like:
>>
>> container foo {
>> if-feature X;
>> container bar;
>> }
>>
>> augment /foo/bar {
>> container Y;
>> }
>>
>> I am just going to assume this is what you meant and simply that the 
>> requirement is that any schema path must point to an existing schema node, 
>> ignoring any "if-feature" statements.
> I think it also depends on whether features are set before or after 
> processing the modules. In the former case, an augment statement with an 
> effectively missing target node can IMO be silently ignored, without even 
> parsing its contents.

This very case has been discussed here:
https://mailarchive.ietf.org/arch/msg/netmod/Icd5c8J27P3UKjloNG8VC9fApoM/

FTR the original request for OpenDaylight lives here:
https://jira.opendaylight.org/browse/YANGTOOLS-859 and it provides some
additional context.

As an implementation author, I certainly did not like the implications
of the request, but Andy brought up a very important point in that thread:

> The modules are valid.
> The conformance decision (i.e., which features are advertised and which are
> not by a server implementation)
> does not change the compile-time validity of the YANG modules

i.e. even if the YANG modules are being interpreted as part of
assembling a server implementation, if-feature processing phase comes
only after cross-statement relationships have been established and
therefore the augment is valid, but 'container Y' disappears just as
'container bar' does.

This is further reinforced by Martin's response in this (related)
thread:
https://mailarchive.ietf.org/arch/msg/netmod/9JgPZphOdim-wLZA3NrSe3I1un4/

Regards,
Robert



OpenPGP_signature
Description: OpenPGP digital signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] AD review of draft-ietf-netmod-geo-location-07

[Rob Wilton (rwilton)]

Hi Chris,

> -Original Message-
> From: Christian Hopps 
> Sent: 13 April 2021 03:38
> To: Rob Wilton (rwilton) 
> Cc: Christian Hopps ; netmod@ietf.org; draft-ietf-
> netmod-geo-location@ietf.org
> Subject: Re: AD review of draft-ietf-netmod-geo-location-07
> 
> 
> 
> > On Mar 7, 2021, at 3:48 PM, Rob Wilton (rwilton) 
> wrote:
> >
> > Hi Chris,
> >
> > Apologies for the delayed AD review of this document.
> >
> > I found that this document to be interesting, enlightening, and well
> written, so thank you.
> >
> >
> > I only have a few minor comments, the rest are grammatical nits. Some I
> spotted manually; the rest are from a beta version of a grammar tool that
> I am playing with.
> >
> > Minor comments/questions:
> >
> > 1.
> > In the YANG module, the pattern statements have 3 ranges of characters,
> > but the description only indicates two ranges.  Is there a reason that
> > the following pattern doesn't work?
> >  pattern '[ -@\[-~]*';
> 
> From an old email on the list: "These 3 ranges seem to make pyang happy. I
> don't know why I need to break up the second range into 2 adjacent ranges
> like that to make pyang not complain, but complain it does if I just use:
> '[ -@\[-~]*'"
[RW] 

Okay. 


> 
> > 2.
> > I note that the YANG module allows just a lat, or a long, or a height
> > to be specified, rather than requiring at least a pair of lat/long or
> > x/y coordinates.  I think that this is fine (and keeps the model
> > flexible), but wanted to check that this is the intentional.
> 
> > 3.
> > I also note that that grouping doesn't require that any coordinates be
> > specified at all.  I presume that this is intentional, it makes sense
> > to me (e.g., if it is intended to be optional).
> 
> My answer to a thread on the list asking for removal of some of the
> mandatory designations which cause problems:
> 
> "The intention was for a location node to be required if the  location> container was present. Apparently this will only work if
> "container geo-lcoation" is a presence container. I'm not even sure that's
> all that smart of a requirement (e.g., maybe someone just wants to
> indicate the reference-frame for an object). I'll remove the mandatory
> from location."
[RW] 

Okay.


> 
> 
> > 4. In the YANG module,
> > "v-east is the rate of change (i.e., speed) perpendicular
> > to truth-north as defined by the geodetic-system.";
> >
> > As a nit, this doesn't actually define whether a positive v-east
> > value is in the East or West direction.  I appreciate that this is
> > obvious, but for the other two components in the vector, it is
> > unambiguously specified.
> 
> How about:
> 
>   "v-east is the rate of change (i.e., speed) perpendicular
>to the right of truth-north as defined by
>the geodetic-system.";
[RW] 

LGTM.


> 
> 
> >
> > 5.
> > In Security Considerations:
> >
> >   Since the grouping defined in this module identifies locations,
> >   authors using this grouping SHOULD consider any privacy issues that
> >   may arise when the data is readable.
> >
> > Perhaps, expand this paragraph to give an example, e.g., revealing
> > the physical location of a device, or data center.
> 
> How about:
> 
> "Since the grouping defined in this module identifies locations,
> authors using this grouping SHOULD consider any privacy issues
> that may arise when the data is readable (e.g., customer device
> locations, etc)."
[RW] 

LGTM.


> 
> 
> >
> > The rest are just grammar nits:
> >
> >
> >   In addition to identifying the astronomical body we also need to
> >   define the meaning of the coordinates
> > =>
> >   In addition to identifying the astronomical body, we also need to
> >   define the meaning of the coordinates
> 
> fixed
> 
> >
> >   In addition to the "geodetic-datum" value we allow refining the
> >   coordinate and height accuracy using "coord-accuracy" and "height-
> >   accuracy" respectively.
> > =>
> >   In addition to the "geodetic-datum" value, we allow refinement of the
> >   coordinate and height accuracy using "coord-accuracy" and "height-
> >   accuracy" respectively.
> 
> fixed
> 
> >   This is the location on or relative to the astronomical object.  It
> >   is specified using 2 or 3 coordinates values.
> > =>
> >   This is the location on, or relative to, the astronomical object.  It
> >   is specified using 2 or 3 coordinates values.
> 
> fixed
> 
> >   The intent of the grouping being defined here is to identify
> >   where something is located, and generally this is expected to be
> >   somewhere on or relative to Earth (or another astronomical body).
> > =>
> >   The intent of the grouping being defined here is to identify
> >   where something is located, and generally this is expected to be
> >   somewhere on, or relative to, Earth (or another astronomical body).
> 
> fixed
> 
> >   At
> >   least two options are available to YANG models that wish to use this
> >   grouping with objects that are changing