[netmod] Re: WGLC on system-config-05

[Rob Wilton (rwilton)]

Hi authors, chairs, WG,

I’m generally supportive of this work, but I think that there are still some 
potential corner cases that are not covered, or it isn’t entirely obvious how 
they are handled.

Comments below.





Moderate level comments:



(1) p 7, sec 2.3.  Inactive-Until-Referenced



   There are some system configuration predefined (e.g., application

   ids, anti-x signatures, trust anchor certs, etc.) as a convenience

   for the clients, which must be referenced to be active.  The clients

   can also define their own configurations for their unique

   requirements.  Inactive-until-referenced system configuration is

   generated in  immediately when the device is powered on, but

   it is not active until being referenced.



I'm not sure whether Inactive-Until-Referenced actually needs to be defined, or 
to put it another way, I'm not sure whether this type of configuration is 
special to system datastores at all.  If a configuration (either explicitly in 
 or implicitly from ) defines a QoS policy that is not 
referenced from anywhere, (e.g., not applied to any interfaces) then I think 
that it up to the server to decide whether that unreferenced QoS policy is 
reported in operational or not, depending on server implementation.





(2) p 9, sec 5.1.  Conceptual Model of Datastores



   When the device is powered on, immediately-active system

   configuration is generated in  and active immediately, but

   inactive-until-referenced system configuration only becomes active if

   referenced by client-defined configuration.  However, conditionally-

   active system configuration will only be created and active when

   specific conditions on system resources are met.



I think that it should be "merged with system" not "merged into system" since 
the running configuration never ends up in the system datastore.





(3) p 9, sec 5.1.  Conceptual Model of Datastores



  additional nodes to a list entry or new list/leaf-

   list entries appearing in  extends the list entry or the

   whole list/leaf-list defined in  if the server allows the

   list/leaf-list to be updated.



How is this achieved?  This appears to suggest that there are two different 
merging behaviours (one choice is to be additive, the other is to replace), and 
it seems to be down to the server to choose what to do on a case-by-case basis. 
 I think that it would be cleaner to define a single merge behaviour if that is 
feasible (even if it is slightly less flexible).  Also, potentially it is 
appropriate for the merge behaviour to be different for list vs leaf-list 
(e.g., always merge list entries, but do a simple replace on leaf-lists).





(4) p 9, sec 5.1.  Conceptual Model of Datastores



  If a server implements

   ,  MUST be merged into .



This sentence is just repetition and can be deleted.  The text above is still 
normative without the RFC 2119 MUST.





(5) p 13, sec 5.4.  Modifying (Overriding) System Configuration



   For instance, descendant nodes in a system-defined list entry may be

   modifiable or not, even if some system configuration has been copied

   into  earlier.  If a system node is non-modifiable, then

   writing a different value for that node MUST return an error.  The

   immutability of system configuration is defined in

   [I-D.ma-netmod-immutable-flag].



I think that some care is needed here.  E.g., if the modification was being 
done to , then it isn't writing a different value to  
that would return an error, but instead the  or  operation 
that would fail.





(6) p 13, sec 5.4.  Modifying (Overriding) System Configuration



   A server may also allow a client to add data nodes to a list entry in

by writing those additional nodes in .  Those

   additional data nodes may not exist in  (i.e., an *addition*

   rather than an override).



Earlier, the text in 5.1 seems to suggest that a list-entry could be 
overwritten.  Is the intention that this is always a merge?  I.e., it is 
possible to override entries, but there is no way that running can remove a 
list entry that is defined in .



This section, 5.4., seems somewhat of a repeat of what is specified in section 
5.1, and arguably it would be nice if this text could be co-located and only 
specified once (for brevity and to avoid ambiguity).  I’m wondering if the 
merge behaviour generally needs to be specified more explicitly.







Minor level comments:



(7) p 0, sec



   This document defines how a management client and server handle YANG-

   modeled configuration data that is defined by the server itself.  The

   system-defined configuration can be referenced (e.g. leafref) by

   configuration explicitly created by a client.



Perhaps 'instantiated' by the server itself rather than 'defined' by the server.





(8) p 0, sec



   The Network Management Datastore Architecture (NMDA) defined in RFC

   8342 is updated with a read-only 

[netmod] Re: WGLC on system-config-05

[Rob Wilton (rwilton)]

[Resending due to mailer issues.]



Hi authors, chairs, WG,

I’m generally supportive of this work, but I think that there are still some 
potential corner cases that are not covered, or it isn’t entirely obvious how 
they are handled.

Comments below.





Moderate level comments:



(1) p 7, sec 2.3.  Inactive-Until-Referenced



   There are some system configuration predefined (e.g., application

   ids, anti-x signatures, trust anchor certs, etc.) as a convenience

   for the clients, which must be referenced to be active.  The clients

   can also define their own configurations for their unique

   requirements.  Inactive-until-referenced system configuration is

   generated in  immediately when the device is powered on, but

   it is not active until being referenced.



I'm not sure whether Inactive-Until-Referenced actually needs to be defined, or 
to put it another way, I'm not sure whether this type of configuration is 
special to system datastores at all.  If a configuration (either explicitly in 
 or implicitly from ) defines a QoS policy that is not 
referenced from anywhere, (e.g., not applied to any interfaces) then I think 
that it up to the server to decide whether that unreferenced QoS policy is 
reported in operational or not, depending on server implementation.





(2) p 9, sec 5.1.  Conceptual Model of Datastores



   When the device is powered on, immediately-active system

   configuration is generated in  and active immediately, but

   inactive-until-referenced system configuration only becomes active if

   referenced by client-defined configuration.  However, conditionally-

   active system configuration will only be created and active when

   specific conditions on system resources are met.



I think that it should be "merged with system" not "merged into system" since 
the running configuration never ends up in the system datastore.





(3) p 9, sec 5.1.  Conceptual Model of Datastores



  additional nodes to a list entry or new list/leaf-

   list entries appearing in  extends the list entry or the

   whole list/leaf-list defined in  if the server allows the

   list/leaf-list to be updated.



How is this achieved?  This appears to suggest that there are two different 
merging behaviours (one choice is to be additive, the other is to replace), and 
it seems to be down to the server to choose what to do on a case-by-case basis. 
 I think that it would be cleaner to define a single merge behaviour if that is 
feasible (even if it is slightly less flexible).  Also, potentially it is 
appropriate for the merge behaviour to be different for list vs leaf-list 
(e.g., always merge list entries, but do a simple replace on leaf-lists).





(4) p 9, sec 5.1.  Conceptual Model of Datastores



  If a server implements

   ,  MUST be merged into .



This sentence is just repetition and can be deleted.  The text above is still 
normative without the RFC 2119 MUST.





(5) p 13, sec 5.4.  Modifying (Overriding) System Configuration



   For instance, descendant nodes in a system-defined list entry may be

   modifiable or not, even if some system configuration has been copied

   into  earlier.  If a system node is non-modifiable, then

   writing a different value for that node MUST return an error.  The

   immutability of system configuration is defined in

   [I-D.ma-netmod-immutable-flag].



I think that some care is needed here.  E.g., if the modification was being 
done to , then it isn't writing a different value to  
that would return an error, but instead the  or  operation 
that would fail.





(6) p 13, sec 5.4.  Modifying (Overriding) System Configuration



   A server may also allow a client to add data nodes to a list entry in

by writing those additional nodes in .  Those

   additional data nodes may not exist in  (i.e., an *addition*

   rather than an override).



Earlier, the text in 5.1 seems to suggest that a list-entry could be 
overwritten.  Is the intention that this is always a merge?  I.e., it is 
possible to override entries, but there is no way that running can remove a 
list entry that is defined in .



This section, 5.4., seems somewhat of a repeat of what is specified in section 
5.1, and arguably it would be nice if this text could be co-located and only 
specified once (for brevity and to avoid ambiguity).  I’m wondering if the 
merge behaviour generally needs to be specified more explicitly.







Minor level comments:



(7) p 0, sec



   This document defines how a management client and server handle YANG-

   modeled configuration data that is defined by the server itself.  The

   system-defined configuration can be referenced (e.g. leafref) by

   configuration explicitly created by a client.



Perhaps 'instantiated' by the server itself rather than 'defined' by the server.





(8) p 0, sec



   The Network Management Datastore Architecture (NMDA) defined in RFC

   

Re: [netmod] YANG Versioning: filename recommendations for YANG Semver

[Rob Wilton (rwilton)]

Hi Andy,

Thanks for the comments.  We discussed this last week in our weekly meeting and 
agreed that a short experimental RFC covering just the filename might be a good 
way forward.

To respond to your technical concern, I think that ‘#’ should be fine in XML, 
JSON and YAML without quoting (YAML shouldn’t treat it is as comment if it 
isn’t directly preceded by a space).  Python would need it to be quoted.  I.e., 
I still think that this is likely to be a reasonable approach?

Lou, I think that it was you who raised this issue at IETF 119.   Are you okay 
with the proposal to move this to a separate experimental draft to unblock 
taking the module versioning draft to last call?

Regards,
Rob


From: Andy Bierman 
Date: Wednesday, 10 April 2024 at 22:11
To: Rob Wilton (rwilton) 
Cc: Jason Sterne (Nokia) , 
netmod@ietf.org , Joe Clarke (jclarke) 
Subject: Re: [netmod] YANG Versioning: filename recommendations for YANG Semver


On Tue, Apr 9, 2024 at 7:01 AM Rob Wilton (rwilton) 
mailto:rwil...@cisco.com>> wrote:
Hi Andy,

For me, it seems likely that vendors using YANG Semver will want to use a 
filename that can contain the Semver label, and I still see some advantages for 
everyone to do it in a similar way.  E.g., it is very likely that internally we 
will just use this format, but will probably strip or convert it before 
publishing them.

But I agree that we shouldn’t formally change the filename format in YANG 1.1, 
and that would be best left for YANG 2.0 (obviously if agreed at that time).

My question is whether we can find some middle ground where we at least 
informally document the format in an appendix now (i.e., as non-normative 
text), so that if folks are starting to use a format, then they could choose 
this one, but not to change the extension representation/API when naming YANG 
modules.
Such an appendix might start with something like:


“During this work it was discussed that having a filename format that allows 
for the Semver, rather than the revision-date to be expressed in the filename, 
would be beneficial.  It was concluded that making such a change would risk 
breaking existing tooling and hence would be better deferred to a further 
revision of the YANG language.  The proposed format is ‘informatively’ 
documented below, which might be adopted in a future revision of YANG.
… 


Would such an approach potentially be acceptable to you?  Or are you strongly 
against saying anything at all?  Note the motivation for considering put this 
in is because a comment was raised during IETF 119 about avoiding an 
undocumented de facto standard – I would like to get consensus on this draft so 
that we can get it published an move on.

I tried 3 YANG compilers on a filename with the extension and it caused a 
warning in 2 of them and no problem at all in the other.
However, the '#' character is used in config files to mean 'comment to end of 
line', so this syntax would be a problem.
The "module-name@revision-date" pattern is used by several tools already.

I don't think changing the file-naming convention for YANG 1.1 is a good idea.
It should be in a separate Experimental RFC.


Regards,
Rob

 Andy



From: netmod mailto:netmod-boun...@ietf.org>> on 
behalf of Andy Bierman mailto:a...@yumaworks.com>>
Date: Wednesday, 3 April 2024 at 19:07
To: Joe Clarke (jclarke) mailto:jcla...@cisco.com>>
Cc: Jason Sterne (Nokia) 
mailto:40nokia@dmarc.ietf.org>>, 
netmod@ietf.org<mailto:netmod@ietf.org> 
mailto:netmod@ietf.org>>
Subject: Re: [netmod] YANG Versioning: filename recommendations for YANG Semver
Hi,


On Wed, Apr 3, 2024 at 10:34 AM Joe Clarke (jclarke) 
mailto:jcla...@cisco.com>> wrote:


From: Andy Bierman mailto:a...@yumaworks.com>>
Date: Tuesday, April 2, 2024 at 17:40
To: Joe Clarke (jclarke) mailto:jcla...@cisco.com>>
Cc: Jason Sterne (Nokia) 
mailto:40nokia@dmarc.ietf.org>>, 
netmod@ietf.org<mailto:netmod@ietf.org> 
mailto:netmod@ietf.org>>
Subject: Re: [netmod] YANG Versioning: filename recommendations for YANG Semver


On Tue, Apr 2, 2024 at 2:11 PM Joe Clarke (jclarke) 
mailto:jcla...@cisco.com>> wrote:
Thanks, Andy.  See inline below.

I do not agree with these recommendations to change the file names of YANG 
modules.
The OFFICIAL YANG version is RFC 7950 - YANG 1.1.
Any module using YANG version 1.1 needs to follow the rules in RFC 7950.
Additional file naming that can be ignored by YANG 1.1 tools is OK.

[JMC] We had this conversation on our call today.  I agree with you that tools 
can be unaware of YANG Semver and attempt to load a file named foo#1.2.3.yang 
as a module named “foo#1.2.3”, which would disagree with the module name 
defined within the module.


This can never happen since the '#' char is not allowed in a YANG module name.
YANG 1.1 tools look for MODNAME[@DATE].EXT.
If the YANG module name is not in this format the tool will not find the module.

[J

Re: [netmod] YANG Versioning: filename recommendations for YANG Semver

[Rob Wilton (rwilton)]

Hi Andy,

For me, it seems likely that vendors using YANG Semver will want to use a 
filename that can contain the Semver label, and I still see some advantages for 
everyone to do it in a similar way.  E.g., it is very likely that internally we 
will just use this format, but will probably strip or convert it before 
publishing them.

But I agree that we shouldn’t formally change the filename format in YANG 1.1, 
and that would be best left for YANG 2.0 (obviously if agreed at that time).

My question is whether we can find some middle ground where we at least 
informally document the format in an appendix now (i.e., as non-normative 
text), so that if folks are starting to use a format, then they could choose 
this one, but not to change the extension representation/API when naming YANG 
modules.

Such an appendix might start with something like:


“During this work it was discussed that having a filename format that allows 
for the Semver, rather than the revision-date to be expressed in the filename, 
would be beneficial.  It was concluded that making such a change would risk 
breaking existing tooling and hence would be better deferred to a further 
revision of the YANG language.  The proposed format is ‘informatively’ 
documented below, which might be adopted in a future revision of YANG.

… 


Would such an approach potentially be acceptable to you?  Or are you strongly 
against saying anything at all?  Note the motivation for considering put this 
in is because a comment was raised during IETF 119 about avoiding an 
undocumented de facto standard – I would like to get consensus on this draft so 
that we can get it published an move on.

Regards,
Rob


From: netmod  on behalf of Andy Bierman 

Date: Wednesday, 3 April 2024 at 19:07
To: Joe Clarke (jclarke) 
Cc: Jason Sterne (Nokia) , 
netmod@ietf.org 
Subject: Re: [netmod] YANG Versioning: filename recommendations for YANG Semver
Hi,


On Wed, Apr 3, 2024 at 10:34 AM Joe Clarke (jclarke) 
mailto:jcla...@cisco.com>> wrote:


From: Andy Bierman mailto:a...@yumaworks.com>>
Date: Tuesday, April 2, 2024 at 17:40
To: Joe Clarke (jclarke) mailto:jcla...@cisco.com>>
Cc: Jason Sterne (Nokia) 
mailto:40nokia@dmarc.ietf.org>>, 
netmod@ietf.org 
mailto:netmod@ietf.org>>
Subject: Re: [netmod] YANG Versioning: filename recommendations for YANG Semver


On Tue, Apr 2, 2024 at 2:11 PM Joe Clarke (jclarke) 
mailto:jcla...@cisco.com>> wrote:
Thanks, Andy.  See inline below.

I do not agree with these recommendations to change the file names of YANG 
modules.
The OFFICIAL YANG version is RFC 7950 - YANG 1.1.
Any module using YANG version 1.1 needs to follow the rules in RFC 7950.
Additional file naming that can be ignored by YANG 1.1 tools is OK.

[JMC] We had this conversation on our call today.  I agree with you that tools 
can be unaware of YANG Semver and attempt to load a file named foo#1.2.3.yang 
as a module named “foo#1.2.3”, which would disagree with the module name 
defined within the module.


This can never happen since the '#' char is not allowed in a YANG module name.
YANG 1.1 tools look for MODNAME[@DATE].EXT.
If the YANG module name is not in this format the tool will not find the module.

[JMC] Of course.  We (authors on the call) were debating what a tool would do 
with the filename if it didn’t understand this YANG Semver naming.

The issue is obviously not the 2 lines of code to parse "#" instead of "@".
IMO this file name change is operationally disruptive and not really needed.
How come OpenConfig modules do not use this naming scheme?
Is it because they are following the RFC 7950 file naming rules?

[JMC] This naming scheme hadn’t been introduced.  OpenConfig doesn’t use the @ 
convention, either.  They just have naked module names from what I can see 
(https://github.com/openconfig/public/tree/master/release/models).  I know that 
at least one vendor is already using YANG Semver and the ‘#’ notation for file 
naming.  I believe it is in part because of this the chairs wanted us to 
revisit the naming.


So the revision-date is the only field that can be relied upon since the same 
SemVer (e.g. "1.0.0") could be released several times,
each one containing different content.

[JMC] Just as with revision-date, the YANG Semver identifier must be unique.  
You cannot have multiple “1.0.0” identifiers for the same module with different 
content.  That 1.0.0 would be tied to a revision of a unique date.



I do not see any net value by changing the filename spec so it is different 
than YANG 1.1.
Duplication of files is a bug, not a feature.

Tools usually rely on a proprietary search path configuration to find modules.
Some clients rely on  and always use the modules from the server.
This is stable and has been the practice since 2016.

IMO this is an NBC change to YANG 1.1, so it should not be done at all.
Adding YANG extensions is fine, and I support that part of this work.


Joe


Andy


Joe


Andy

Re: [netmod] Modeling of veth pairs

[Rob Wilton (rwilton)]

Yes possibly.  Florian would you be interested in helping if we were to do that?

Regards,
Rob

From: Scott Mansfield 
Date: Tuesday, 27 February 2024 at 14:16
To: Rob Wilton (rwilton) , Florian Kauer 
, netmod@ietf.org 
Subject: RE: Modeling of veth pairs
Could we add this case to the intf-ext work?

We could use this as an example.  If a new module is what is desired, I will 
support that too.

Regards,
-scott.

From: Rob Wilton (rwilton) 
Sent: Tuesday, February 27, 2024 8:55 AM
To: Florian Kauer ; netmod@ietf.org
Cc: Scott Mansfield 
Subject: Re: Modeling of veth pairs

Hi Florian,

Some very quick thoughts on this:

I’m assuming that these Virtual Ethernet interfaces are really only Ethernet 
emulations at layer 2 rather than layer 1.  I.e., I presume that there is no 
configuration for speed, duplex, flow-control, etc?  But they would each have 
their own a MAC address?   I think that this would mean that these interfaces 
are probably more ethernet-like as defined in 
draft-ietf-netmod-intf-ext-yang-13 - Common Interface Extension YANG Data 
Models<https://datatracker.ietf.org/doc/draft-ietf-netmod-intf-ext-yang/>.

I suspect that you will want to define a new IANA iftype for these interfaces.  
The alternative would be ethernetCsmacd that is used for all physical Ethernet 
interfaces but not LAG.  But using that IANA iftype would then mean that you 
would likely pickup the configuration for physical Ethernet interfaces that I 
don’t think that you really want.

You could use an Interface naming convention to represent the binding, e.g., 
veth1-left, veth1-right, but it may be better to be more flexible, in which 
case, I would probably recommend having new configuration under each v-eth 
interface with a leaf-ref to indicate what its peer interface is.

So, yes, I think that you would need to a new model to define these, but it 
should be pretty small and simple.  And if you did want to do something like 
this in the IETF, then I suspect that NETMOD is probably the best WG.

Regards,
Rob
// As a contributor/author of draft-ietf-netmod-intf-ext-yang.


From: Florian Kauer 
mailto:florian.ka...@linutronix.de>>
Date: Tuesday, 27 February 2024 at 09:02
To: netmod@ietf.org<mailto:netmod@ietf.org> 
mailto:netmod@ietf.org>>
Cc: Rob Wilton (rwilton) mailto:rwil...@cisco.com>>, 
scott.mansfi...@ericsson.com<mailto:scott.mansfi...@ericsson.com> 
mailto:scott.mansfi...@ericsson.com>>
Subject: Modeling of veth pairs
Hi,
I would like to model a veth pair in YANG, preferrably without proprietary 
models.
In Linux, these veth pairs are basically just this:

  +--+   +--+
  |Socket|   |Socket|
  +--+   +--+
 |  |
  +--+   +--+
  |Stack |   |Stack |
  +--+   +--+
 |  |
  +--+   +--+
  |veth1 |   |veth2 |
  +--+   +--+
 |  |
 +--+

So all packets that egress veth1, appear at the ingress of veth2 and vice versa,
i.e. similar to two physical interfaces of the same device directly connected 
via a cable.
Also see https://man7.org/linux/man-pages/man4/veth.4.html

The only thing I specifically found regarding veths and YANG was
https://doc.6wind.com/turbo-router-2.x/user-guide/cli/network-interface/types/veth.html<https://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-00890e5f712ca52f=1=b797b9fa-a764-402f-bcce-ceb3cfffca50=https%3A%2F%2Fdoc.6wind.com%2Fturbo-router-2.x%2Fuser-guide%2Fcli%2Fnetwork-interface%2Ftypes%2Fveth.html>
where they seem to use a proprietary model that provides "link-interface" to 
link
the two interfaces together.

The other option I thought about was to represent the "virtual cable" as
Internal LAN, i.e. IANA type 247 (ILAN). This would look like this:

  +--+   +--+
  |Socket|   |Socket|
  +--+   +--+
 |  |
  +--+   +--+
  |Stack |   |Stack |
  +--+   +--+
 |  |
  +--+   +--+
  |veth1 |   |veth2 |
  +--+   +--+
 |  |
  +-+
  |  ilan0  |
  +-+

However, that would still require to specify the link between the veth1 and 
ilan0
as well as veth2 and ilan0 with some kind of parent/child or higher/lower layer 
interface link.
The higher-layer-if and lower-layer-if of RFC 8343 is only ro and
while draft-ietf-netmod-intf-ext-yang provides "parent-interface", it would
not work here because ilan0 has two parents (i.e. we would need a 
"child-interface"
or a way to specify multiple parent interfaces).

Also, what could be the interface type of veth1 and veth2?

Any ideas on this? Or do we need to specify something new to support this?

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

Re: [netmod] Modeling of veth pairs

[Rob Wilton (rwilton)]

Hi Florian,

Some very quick thoughts on this:

I’m assuming that these Virtual Ethernet interfaces are really only Ethernet 
emulations at layer 2 rather than layer 1.  I.e., I presume that there is no 
configuration for speed, duplex, flow-control, etc?  But they would each have 
their own a MAC address?   I think that this would mean that these interfaces 
are probably more ethernet-like as defined in 
draft-ietf-netmod-intf-ext-yang-13 - Common Interface Extension YANG Data 
Models<https://datatracker.ietf.org/doc/draft-ietf-netmod-intf-ext-yang/>.

I suspect that you will want to define a new IANA iftype for these interfaces.  
The alternative would be ethernetCsmacd that is used for all physical Ethernet 
interfaces but not LAG.  But using that IANA iftype would then mean that you 
would likely pickup the configuration for physical Ethernet interfaces that I 
don’t think that you really want.

You could use an Interface naming convention to represent the binding, e.g., 
veth1-left, veth1-right, but it may be better to be more flexible, in which 
case, I would probably recommend having new configuration under each v-eth 
interface with a leaf-ref to indicate what its peer interface is.

So, yes, I think that you would need to a new model to define these, but it 
should be pretty small and simple.  And if you did want to do something like 
this in the IETF, then I suspect that NETMOD is probably the best WG.

Regards,
Rob
// As a contributor/author of draft-ietf-netmod-intf-ext-yang.


From: Florian Kauer 
Date: Tuesday, 27 February 2024 at 09:02
To: netmod@ietf.org 
Cc: Rob Wilton (rwilton) , scott.mansfi...@ericsson.com 

Subject: Modeling of veth pairs
Hi,
I would like to model a veth pair in YANG, preferrably without proprietary 
models.
In Linux, these veth pairs are basically just this:

  +--+   +--+
  |Socket|   |Socket|
  +--+   +--+
 |  |
  +--+   +--+
  |Stack |   |Stack |
  +--+   +--+
 |  |
  +--+   +--+
  |veth1 |   |veth2 |
  +--+   +--+
 |  |
 +--+

So all packets that egress veth1, appear at the ingress of veth2 and vice versa,
i.e. similar to two physical interfaces of the same device directly connected 
via a cable.
Also see https://man7.org/linux/man-pages/man4/veth.4.html

The only thing I specifically found regarding veths and YANG was
https://doc.6wind.com/turbo-router-2.x/user-guide/cli/network-interface/types/veth.html
where they seem to use a proprietary model that provides "link-interface" to 
link
the two interfaces together.

The other option I thought about was to represent the "virtual cable" as
Internal LAN, i.e. IANA type 247 (ILAN). This would look like this:

  +--+   +--+
  |Socket|   |Socket|
  +--+   +--+
 |  |
  +--+   +--+
  |Stack |   |Stack |
  +--+   +--+
 |  |
  +--+   +--+
  |veth1 |   |veth2 |
  +--+   +--+
 |  |
  +-+
  |  ilan0  |
  +-+

However, that would still require to specify the link between the veth1 and 
ilan0
as well as veth2 and ilan0 with some kind of parent/child or higher/lower layer 
interface link.
The higher-layer-if and lower-layer-if of RFC 8343 is only ro and
while draft-ietf-netmod-intf-ext-yang provides "parent-interface", it would
not work here because ilan0 has two parents (i.e. we would need a 
"child-interface"
or a way to specify multiple parent interfaces).

Also, what could be the interface type of veth1 and veth2?

Any ideas on this? Or do we need to specify something new to support this?

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

Re: [netmod] [Technical Errata Reported] RFC7950 (7021)

[Rob Wilton (rwilton)]

Hi,

I'm trying to decide how to process this errata.

Regarding the issue raised in the errata, I think that RFC 7950 is probably 
inconsistent because section 5.1.1 allows an import by revision-date to be 
updated to a newer revision-date, but section 11 seems to implicitly exclude it.

It is worth noting that section 11 doesn't seem to make any mention of adding 
or changing import statements at all, so perhaps this errata should be 
broadened to also cover that, or is that already intended to be covered by the 
catch all paragraph.  The YANG module revision handling document could also be 
updated to clarify these two points.

Any thoughts for the authors or WG on how to process this errata?

Regards,
Rob


> -Original Message-
> From: RFC Errata System 
> Sent: Tuesday, July 12, 2022 4:42 PM
> To: m...@tail-f.com; war...@kumari.net; Rob Wilton (rwilton)
> ; kent+i...@watsen.net; joe...@bogus.com;
> lber...@labn.net
> Cc: balazs.leng...@ericsson.com; netmod@ietf.org; rfc-edi...@rfc-editor.org
> Subject: [Technical Errata Reported] RFC7950 (7021)
> 
> The following errata report has been submitted for RFC7950,
> "The YANG 1.1 Data Modeling Language".
> 
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid7021
> 
> --
> Type: Technical
> Reported by: Balazs Lengyel 
> 
> Section: 11
> 
> Original Text
> -
> A definition in a published module may be revised in any of the
>following ways:
> 
>o  An "enumeration" type may have new enums added, provided the old
>   enums's values do not change.  Note that inserting a new enum
>   before an existing enum or reordering existing enums will result
>   in new values for the existing enums, unless they have explicit
>   values assigned to them.
> 
> Corrected Text
> --
> A definition in a published module may be revised in any of the
>following ways:
> 
>o  The "revision-date" substatement of an existing "import" statement
>   may get a changed argument.
> 
> 
>o  An "enumeration" type may have new enums added, provided the old
>   enums's values do not change.  Note that inserting a new enum
>   before an existing enum or reordering existing enums will result
>   in new values for the existing enums, unless they have explicit
>   values assigned to them.
> 
> Notes
> -
> In section 5.1.1 it is stated that a module may be republished with an updated
> "import"
> statement. This is needed, otherwise a user of the revision-date statement
> (inside an import) would never be able to migrate to a newer version of the
> imported module.
> 
> However in section 11.  Updating a Module   this change is not listed in the 
> list
> of allowed updates, thus it is forbidden.
> 
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.
> 
> --
> RFC7950 (draft-ietf-netmod-rfc6020bis-14)
> --
> Title   : The YANG 1.1 Data Modeling Language
> Publication Date: August 2016
> Author(s)   : M. Bjorklund, Ed.
> Category: PROPOSED STANDARD
> Source  : Network Modeling
> Area: Operations and Management
> Stream  : IETF
> Verifying Party : IESG
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Aiming to charter a new "Network Management Operations" WG

[Rob Wilton (rwilton)]

Hi,

I just wanted to let everyone know that I'm trying to charter a new "Network 
Management Operations" WG.  We are in the process of discussing the charter 
scope, WG name, and initial work, currently on the ne...@ietf.org open mailing 
list.  I'm hoping to get put a draft version of the charter in the Datatracker 
by this Thursday so that it can be considered by the IESG next Thursday.

Please join this list if you are potentially interested in the new work 
(although, it seems fairly likely that the working group will get chartered 
with a different name and email address).

If you would like to see what has been discussed so far, then please look at 
the archives here: https://mailarchive.ietf.org/arch/browse/netmo/, and in 
particular the outline of my plan here: 
https://mailarchive.ietf.org/arch/msg/netmo/xgkZ1hqYnndqlIYFMXmk6pn_l_s/, and 
details of the initial charter here: 
https://mailarchive.ietf.org/arch/msg/netmo/i9d4SqPtbGJmU0KZtauC3YTJFbE/

Regards,
Rob

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

Re: [netmod] draft-ietf-netmod-rfc8407bis: must + error-message for "config false"

[Rob Wilton (rwilton)]

Specifically regarding MUST statements on state date, RFC 8342 section 5.3, 
also has this statement (which effectively aligns to Jürgen's last paragraph):

SHOULD conform to any constraints specified in the data
   model, but given the principal aim of returning "in use" values, it
   is possible that constraints MAY be violated under some circumstances
   (e.g., an abnormal value is "in use", the structure of a list is
   being modified, or remnant configuration (see Section 5.3.1) still
   exists).  Note that deviations SHOULD be used when it is known in
   advance that a device does not fully conform to the 
   schema.

   Only semantic constraints MAY be violated.  These are the YANG
   "when", "must", "mandatory", "unique", "min-elements", and
   "max-elements" statements; and the uniqueness of key values.
 
   Syntactic constraints MUST NOT be violated, including hierarchical
   organization, identifiers, and type-based constraints.  If a node in
does not meet the syntactic constraints, then it
   MUST NOT be returned, and some other mechanism should be used to flag
   the error.

Regards,
Rob


-Original Message-
From: netmod  On Behalf Of Jürgen Schönwälder
Sent: Wednesday, November 1, 2023 7:46 AM
To: mohamed.boucad...@orange.com
Cc: netmod@ietf.org
Subject: Re: [netmod] draft-ietf-netmod-rfc8407bis: must + error-message for 
"config false"

Here is what RFC 7950 says:

  7.5.4.1.  The "error-message" Statement

 The "error-message" statement, which is optional, takes a string as
 an argument.  If the constraint evaluates to "false", the string is
 passed as  in the  in NETCONF.

Since state data is not (directly) modified by processing RPCs, which
 would carry the ? If the answer is 'none',
then why define an  for state data?

My take has always been that operational state data should report as
much as possible the true state of the device - even if the current
state violates certain constraints. The entity to check constraints
would be a managing system, not the managed system. That said, the
wording in section 7.5.4.1 indicates that the designers had servers
processing RPCs in mind.

/js

On Tue, Oct 31, 2023 at 10:40:15AM +, mohamed.boucad...@orange.com wrote:
> Hi all,
> 
> In the context of https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-yang/, 
> Dhruv has received in the past a comment about the use of "must + 
> error-message" for "config false" data nodes. He reported that comment at 
> https://mailarchive.ietf.org/arch/msg/yang-doctors/gWnXnyNHPVv_nZB1PQjThAwP1JY/,
>  but without any follow-up.
> 
> rfc7950#section-8.1 includes a provision for the use of "must" for state 
> data, but silent about the use of error-message. Some guidance for authors 
> may be useful here.
> 
> The following options are being considered:
> 
> (1) Remove both must and error-message for config false data nodes
> (2) Remove error-message but keep the must
> (3) keep both
> 
> I think that (3) is OK as this is a formal way to detect anomalies in state 
> data, but I'm open to hear what the WG thinks.
> 
> Opinions whether we need to include a mention about this in 
> draft-ietf-netmod-rfc8407bis are welcome.
> 
> Thank you.
> 
> Cheers,
> Med
> 
> 
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
> falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged 
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete 
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been 
> modified, changed or falsified.
> Thank you.

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


-- 
Jürgen Schönwälder  Constructor 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
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [Editorial Errata Reported] RFC6991 (7647)

[Rob Wilton (rwilton)]

Hi,

Looking at this erratum, I agree that it would be better that the module prefix 
is used consistently for references to other types within the same module, but 
the existing YANG is not wrong.

In YANG, I generally expect prefixes are used when referencing data nodes or 
types in other imported modules, hence without a prefix I would naturally 
assume that the types/data nodes either exist in the current module or they are 
part of the set of primitive types.  Given there is only a small set of 
primitive types, I think that it is reasonably easy to differentiate between 
these two sets without needing the extra prefix.

Hence my proposal is to reject this erratum, but perhaps Jürgen you can update 
your copy of rfc-6991bis to make these consistent please?  And yes, I 
appreciate that I need to finish processing my AD review of your doc.

Regards,
Rob


> -Original Message-
> From: netmod  On Behalf Of Jürgen Schönwälder
> Sent: Monday, September 25, 2023 12:25 PM
> To: David Martínez García 
> Cc: netmod@ietf.org
> Subject: Re: [netmod] [Editorial Errata Reported] RFC6991 (7647)
> 
> Interesting. I would have removed all prefixes that are not strictly
> necessary. Why do you think having the prefixes is a good thing?
> 
> /js
> 
> On Sat, Sep 23, 2023 at 10:34:21AM +0200, David Martínez García wrote:
> > Hello,
> >
> > > Using the prefix is perhaps redundant but surely not wrong.
> >
> > Yes, I definetely agree with this.
> >
> > > Which consistency are you looking for, use of prefixes only when
> > > absolutely necessary, or always use prefixes?
> >
> > My proposal is to always use prefixes when defining typedefs that point to
> other typedefs different than the base/primitive ones (such as string, uint32,
> enumeration, etc.).
> >
> > Thank you.
> >
> > - David.
> 
> --
> Jürgen Schönwälder  Constructor 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
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Poll on YANG Versioning NBC Approach

[Rob Wilton (rwilton)]

Hi Jürgen,

Please see inline ...

> -Original Message-
> From: netmod  On Behalf Of Jürgen
> Schönwälder
> Sent: 12 September 2023 14:11
> To: Jan Lindblad (jlindbla) 
> Cc: netmod@ietf.org
> Subject: Re: [netmod] Poll on YANG Versioning NBC Approach
> 
> The two options mix things together. Option 1 says updating YANG 1 and
> YANG 1.1 to allow YANG modules to be modified _based on
> draft-ietf-netmod-yang-module-versioning_ but this document has much
> more in it than just changing a MUST to SHOULD.
[Rob Wilton (rwilton)] 

I think that for this first poll this is the question that we should initially 
focus on.  I.e., at a starting point, do you agree to updating RFC 6020, RFC 
7950, to allow changing the MUST to a SHOULD without a new YANG 1.2?

If we can get consensus on this part, then I think that we can try and tackle 
getting consensus on the other updates in 
draft-ietf-netmod-yang-module-versioning to decide whether to include those in 
a document that updates existing versions of YANG without a change in the YANG 
versioning number, or whether those changes should be deferred to a new version 
of YANG (which I hope that the WG starts after this versioning work completes - 
but I'll no longer be an AD at that stage).


> 
> There are features in draft-ietf-netmod-yang-module-versioning that
> you can use only with new tools that implement the features. I am not
> sure why tools that support different variants of YANG 1 and YANG 1.1
> are any easier in practice than a tool that says clearly what it
> implements.
[Rob Wilton (rwilton)] 

I hear two concerns:
(1) Existing tooling handling YANG 1 and YANG 1.1 modules must handle NBC 
changes anyway because they see them in the wild and that won't change.  E.g., 
it is 99% likely that OpenConfig will still continue to use Yang 1 modules.
(2) All existing tooling won't be able to handle YANG 1.2 without tooling 
changes. 

> 
> I continue to believe the questions are badly phrased. Instead of
> discussing properties and trade-offs of solutions, we discuss the
> version number. And we accept that bumping the version number is
> considered too costly but at the same time the entire work is about
> introducing version numbers to data models (where the same logic will
> sooner of later apply). Yes, for me, this is real-world irony.
[Rob Wilton (rwilton)] 

I see this as: What are we able to do now without changing the YANG versioning 
number, and without breaking existing tools, to help solve real world issues 
today?  I.e., the aim is to bound our solution by what we are pragmatically 
able to support in YANG 1/YANG 1.1 without breaking existing tooling (which 
should already ignore existing statements that they don't understand).

Yang 1.2/2 should be worked on, but that will probably include other changes as 
well and involve some level of effort from tool vendors to support.  It will 
also probably also take many years.

Regards,
Rob


> 
> /js
> 
> PS: There is no need to update YANG 1.1 modules to YANG 1.2 as long
> as you do not use YANG 1.2 rules and mechanism.
> 
> On Tue, Sep 12, 2023 at 12:43:56PM +, Jan Lindblad (jlindbla) wrote:
> > Jürgen, all,
> >
> > I see the irony in changing the YANG RFC(s) without updating the YANG
> language version number, but digging a bit deeper, I think the question is not
> as clear-cut as it might seem at first.
> >
> > Altering the contents of the backwards-compatibility section of RFC 6020
> (sec 10) and RFC 7950 (sec 11) clearly implies changes in YANG module
> authors' behavior.
> >
> > Speaking as a YANG compiler implementor, however, I don't see any
> changes that have to made to the compiler because of this RFC change. There
> are no new keywords, none are removed. There is no change in the meaning
> of existing keywords. There is no difference in the output the compiler needs
> to generate.
> >
> > So while there are changes to the YANG *standard* (meaning RFCs) there is
> no actual change to the YANG *language*. If we require user's to mark their
> modules with version 1.2 (or 2.0), from the compiler's pov, that would just
> be an alias for YANG 1.1. It means a fair amount of trouble to update all the
> tools out there to accept "yang-version 1.2" but do nothing new. It also adds
> a burden to YANG module implementors, since they would have to go
> through all YANG 1.1 modules and mark them 1.2, for no change in meaning.
> For organizations with some modules still on YANG 1.0, the bar is even
> higher.
> >
> > I think the most pragmatic approach in this case would be to change the
> RFC text in the backwards-compatibility sections and not update the yang-
> version number as long as no change is required in the compilers. If anyone
> can point to actual things

Re: [netmod] Poll on YANG Versioning NBC Approach

[Rob Wilton (rwilton)]

Further to Jan's comments, given that all organizations (vendors, SDOs, and 
industry consortia) producing YANG modules all occasionally update then in NBC 
ways to fix bugs and issues, then I presume that all pragmatic YANG tooling is 
obliged to handle cases where modules change in NBC ways.

Hence, I see changing the following paragraph in RFC 7950 section 11 from

   Otherwise, if the semantics of any previous definition are changed
   (i.e., if a non-editorial change is made to any definition other than
   those specifically allowed above), then this MUST be achieved by a
   new definition with a new identifier.

to

   Otherwise, if the semantics of any previous definition are changed
   (i.e., if a non-editorial change is made to any definition other than
   those specifically allowed above), then this SHOULD be achieved by a
   new definition with a new identifier.

really as bugfix to RFC 7950 (given that it how everyone is interpreting it) 
rather than a new version of YANG.

If, the landscape was different and everyone defining YANG 1 and YANG 1.1 
modules was only making BC changes, then I would advocate for a new version of 
YANG, but that is not where we are, as has Jan as explained below, I think that 
defining a new version of YANG for this will just cause pain/confusion rather 
than any wider benefit to the industry.

Regards,
Rob

// As a contributor



> -Original Message-
> From: netmod  On Behalf Of Jan Lindblad
> (jlindbla)
> Sent: 12 September 2023 13:44
> To: Jürgen Schönwälder 
> Cc: netmod@ietf.org
> Subject: Re: [netmod] Poll on YANG Versioning NBC Approach
> 
> Jürgen, all,
> 
> I see the irony in changing the YANG RFC(s) without updating the YANG
> language version number, but digging a bit deeper, I think the question is not
> as clear-cut as it might seem at first.
> 
> Altering the contents of the backwards-compatibility section of RFC 6020 (sec
> 10) and RFC 7950 (sec 11) clearly implies changes in YANG module authors'
> behavior.
> 
> Speaking as a YANG compiler implementor, however, I don't see any changes
> that have to made to the compiler because of this RFC change. There are no
> new keywords, none are removed. There is no change in the meaning of
> existing keywords. There is no difference in the output the compiler needs to
> generate.
> 
> So while there are changes to the YANG *standard* (meaning RFCs) there is
> no actual change to the YANG *language*. If we require user's to mark their
> modules with version 1.2 (or 2.0), from the compiler's pov, that would just
> be an alias for YANG 1.1. It means a fair amount of trouble to update all the
> tools out there to accept "yang-version 1.2" but do nothing new. It also adds
> a burden to YANG module implementors, since they would have to go
> through all YANG 1.1 modules and mark them 1.2, for no change in meaning.
> For organizations with some modules still on YANG 1.0, the bar is even
> higher.
> 
> I think the most pragmatic approach in this case would be to change the RFC
> text in the backwards-compatibility sections and not update the yang-version
> number as long as no change is required in the compilers. If anyone can
> point to actual things the compiler needs to do differently, I'd be interested
> to hear.
> 
> Best Regards,
> /jan
> 
> 
> 
> > On 12 Sep 2023, at 07:55, Jürgen Schönwälder
>  wrote:
> >
> > I disagree with the poll. There are important teachnigal differences
> > behind the two options that this polls tries to hide.
> >
> > Updating YANG 1 and YANG 1.1 means creating YANG 1' and YANG
> > 1.1'. There is no way that a new versioning approach will be
> > understood by existing YANG tooling. That's an illusion.
> >
> > /js
> >
> > On Mon, Sep 11, 2023 at 10:39:39PM +, Kent Watsen wrote:
> >> WG,
> >>
> >> Please help the YANG-versioning effort move forward by participating in
> the following poll:
> >>
> >>  - https://notes.ietf.org/netmod-2023-sept-poll  (Datatracker login
> required)
> >>
> >> Kent and Lou
> >>
> >
> >> ___
> >> netmod mailing list
> >> netmod@ietf.org
> >> https://www.ietf.org/mailman/listinfo/netmod
> >
> >
> > --
> > Jürgen Schönwälder  Constructor 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
> 
> ___
> 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] Adoption poll for draft-haas-netmod-unknown-bits-02

[Rob Wilton (rwilton)]

As a contributor.

I think that Jeff has obviously found a modelling issue, and documenting some 
collective guidance on how to handle that is useful.  IIRC, an effort was 
recently started to do an RFC 8407 (YANG Author Guidelines) bis document and 
depending on what and how much needs to be written about this issue, then that 
might be a better home than a separate RFC.

However, I agree with others, that the approach documented in the ID is perhaps 
not the best solution.  Specifically, sometimes/always just reporting the raw 
hex value alongside the bits value seems like a simple, effective, and robust 
solution, and perhaps we could recommend a standard name prefix or suffix for 
the name of the raw value leaf relative to the bits value leaf.

In addition, I think that if we wanted a more efficient solution that doesn’t 
require modelling two leaves, then perhaps this could be considered as a 
potential YANG Next issue.  I.e., is there is a small change or addition to a 
future revision of the YANG language (or encodings) that could allow this to be 
better handled.

Regards,
Rob


From: netmod  On Behalf Of Jeffrey Haas
Sent: 17 August 2023 16:38
To: Italo Busi 
Cc: netmod@ietf.org
Subject: Re: [netmod] Adoption poll for draft-haas-netmod-unknown-bits-02

Italo,



On Aug 8, 2023, at 8:14 PM, Italo Busi 
mailto:Italo.Busi=40huawei@dmarc.ietf.org>>
 wrote:

Hi Kent,

I am a bit struggling about how to reply to this poll …

I think that having some guidelines about how to deal with unknown bits when 
reporting information received from a protocol is quite useful. In other words, 
the I-D is addressing an issue that needs to be resolved

This draft was created because such guidance was lacking.  Minimally, I'm happy 
that it's created useful discussion on the matter.

-- Jeff

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

Re: [netmod] YANG Versioning: Key Issue #1 - Allow NBC changes in YANG 1.0 & YANG 1.1 or not?

[Rob Wilton (rwilton)]

Hi Martin,

You may have just seen my comment to Juergen, but with an AD hat on, I think 
that what you propose is not a valid option.

My understanding is that the IETF process does not allow an RFC to choose to 
ignore a MUST statement in another RFC for pragmatic reasons (I would DISCUSS 
on this and suspect that many other ADs would as well).   If you are sometimes 
allowed to ignore the rule then one would correctly argue that would be a 
SHOULD not a MUST ...  If the goal is to have the module update rules of RFC 
7950 be interpreted differently then the only choices are to bis RFC 7950 or 
write another RFC that updates it.

I currently allow the RFC 7950 module update rules to be interpreted 
pragmatically on the understanding that the RFC 7950 rules would be loosened to 
allow it.

Regards,
Rob


> -Original Message-
> From: netmod  On Behalf Of Martin Björklund
> Sent: 18 July 2023 04:48
> To: jason.ste...@nokia.com
> Cc: netmod@ietf.org
> Subject: Re: [netmod] YANG Versioning: Key Issue #1 - Allow NBC changes in
> YANG 1.0 & YANG 1.1 or not?
> 
> What about Option 4 - Pragmatic Adherence to Current RFC7950 Rules
> 
> - As it works today; the IETF *has* published bugfixed modules that break
> the
>   rules.  (and many vendors do this as well)
> - (Possibly) Introduce rev:non-backwards-compatible
> 
> This would allow 6991bis to update date-and-time to follow the updated
> semantics for RFC3339 timestamps (which imo is the only reasonable
> thing to do - the consuequences of this change is handled by SEDATE).
> 
> 
> /martin
> 
> "Jason Sterne (Nokia)"  wrote:
> > Hi all,
> >
> > At the request of the NETMOD chairs, and on behalf of the YANG
> Versioning weekly call group, here's a summary of Key Issue #1 for the
> versioning work (i.e. for the Module Versioning and YANG Semver WGLC).
> >
> > We'd like to suggest that the WG has a strong focus on deciding on this
> specific issue first. Then we'll move on to tackle other key issues. The idea 
> is
> to try and avoid getting tangled in a web of multiple intertwined issues.
> >
> > Key Issue #1 is the following:  Allow NBC changes in YANG 1.0 & YANG 1.1
> or not?
> >
> > For now please avoid debating other issues in this thread (e.g. multiple vs
> single label schemes, whether YANG semver is a good scheme, etc). Let's
> focus on K1 and work towards a WG decision.
> >
> > ###
> > K1) Allow NBC changes in YANG 1.0 & YANG 1.1 or not?
> >
> > Option 1 - Update RFC7950 to Allow NBC Changes
> > ---
> > - Module Versioning modifies 7950 to allow NBC changes
> > - guidance that NBC changes SHOULD NOT be done (impact to user base)
> > - rev:non-backwards-compatible is a YANG extension
> > - introduction in published YANG does not impact current tooling
> (ignored until recognized)
> > PROS:
> > - address fundamental requirement of this versioning work (requirements
> doc)
> > - allows gradual adoption in the industry. YANG authors can immeditately
> start publishing with the new extensions.
> > - move faster to produce modules in the IETF (accept some
> errors/iteration)
> > - address the liaison from external standards bodies in a reasonable
> timeframe
> > - authors believe work is ready
> > - broad vendor support
> > - rough alignment with OpenConfig (use YANG 1.0 + OC Semver)
> > CONS:
> > - perception that we're "cheating" by not bumping our own spec's version
> > - Not fundamentally mandatory for clients or servers using YANG
> (mandatory for YANG claiming conformance to Module Versioning).
> >
> > Option 2 - RFC7950-bis: Publish a new version of the YANG language to
> allow NBC changes
> > ---
> > - NBC changes only allowed in a new (future) version of YANG
> > - TBD: YANG 1.2 vs 2.0 (note YANG 1.1 isn't BC with YANG 1.0)
> > - Content = Module Versioning + YANG Semver + very limited YANG NEXT
> items
> > - rev:non-backwards-compatible tag is a language keyword
> > - consequence: any use of it breaks all YANG 1.0/1.1 tooling that hasn't
> been updated
> > - TBD how to handle small NBC changes in IETF in the short term (i.e. non
> conformance to 7950)?
> > - RFC6991 bis - change the use/meaning of ip-address (or change
> datetime)
> >   - YANG date-and-time (because of SEDATE date string changes)
> >
> > PROS:
> > - address fundamental requirement of this versioning work (requirements
> doc)
> > - clear delineation of changes in the YANG language
> > - consistent with philosophy that version number changes for significant
> changes in a spec (avoids concern that YANG is changing without bumping
> the version of YANG)
> > - can do this with mandatory YANG keywords which helps increase
> conformance to the new rules
> > CONS:
> > - difficult to roll out in the industry. Tools need upgrading before they
> won't error on a YANG 1.2 module.
> > - Authors can't 

Re: [netmod] YANG Versioning: Key Issue #1 - Allow NBC changes in YANG 1.0 & YANG 1.1 or not?

[Rob Wilton (rwilton)]

Hi Jürgen, WG,

Writing as an author:
I think that the authors, who have invested a lot of time and effort in this, 
are really just looking for a path forward to reach consensus, if that is 
possible.

I don't think that presenting the 3 options was intended to mean that 
participants just have to choose 1, 2, or 3, but to try and highlight the main 
options that available and some of benefits/concerns that the authors have 
thought of when considering these options as a starting point for a discussion. 
 There may be other choices and there may be pros/cons that we have missed.

With an AD hat on:
It would be really nice if we are able to discuss some of these at IETF 117, 
but I don’t know if you, Andy or Martin are planning on attending (local or 
remote)?  Or, if timing doesn't work for IETF 117, then we could try and setup 
a set of virtual interim meetings (or even an in-person interim) if we thought 
that we could unblock and make progress ...

My biggest concern here is that the WG doesn't reach any consensus on a way 
forward that has sufficient energy for the WG to find a solution.  I still 
regard that my current AD position of allowing small breaking changes to IETF 
YANG modules (i.e., that don't strictly follow RFC 7950 section 11 rules, but 
where the likely harm is easily outweighed by the benefit), is valid only 
because the WG is working on a proper solution that enabled these changes to 
happen.  E.g., if the WG conclusions ends up being that the RFC 7950 rules are 
fine as they are, and there is no problem here to be fixed, then my 
interpretation is that the IETF/IESG will also be required to strictly follow 
these rules.

Rob


> -Original Message-
> From: netmod  On Behalf Of Jürgen Schönwälder
> Sent: 17 July 2023 11:50
> To: Jason Sterne (Nokia) 
> Cc: netmod@ietf.org
> Subject: Re: [netmod] YANG Versioning: Key Issue #1 - Allow NBC changes in
> YANG 1.0 & YANG 1.1 or not?
> 
> Dear Jason,
> 
> the three options come with a bunch of details that make it hard to
> support any of them. I think what is needed is a dialog, not a choice
> of given options (for a yet to be determined set of issues and options
> to come).
> 
> /js
> 
> On Mon, Jul 17, 2023 at 05:52:00PM +, Jason Sterne (Nokia) wrote:
> > Hi all,
> >
> > At the request of the NETMOD chairs, and on behalf of the YANG
> Versioning weekly call group, here's a summary of Key Issue #1 for the
> versioning work (i.e. for the Module Versioning and YANG Semver WGLC).
> >
> > We'd like to suggest that the WG has a strong focus on deciding on this
> specific issue first. Then we'll move on to tackle other key issues. The idea 
> is
> to try and avoid getting tangled in a web of multiple intertwined issues.
> >
> > Key Issue #1 is the following:  Allow NBC changes in YANG 1.0 & YANG 1.1
> or not?
> >
> > For now please avoid debating other issues in this thread (e.g. multiple vs
> single label schemes, whether YANG semver is a good scheme, etc). Let's
> focus on K1 and work towards a WG decision.
> >
> > ###
> > K1) Allow NBC changes in YANG 1.0 & YANG 1.1 or not?
> >
> > Option 1 - Update RFC7950 to Allow NBC Changes
> > ---
> > - Module Versioning modifies 7950 to allow NBC changes
> > - guidance that NBC changes SHOULD NOT be done (impact to user base)
> > - rev:non-backwards-compatible is a YANG extension
> > - introduction in published YANG does not impact current tooling
> (ignored until recognized)
> > PROS:
> > - address fundamental requirement of this versioning work (requirements
> doc)
> > - allows gradual adoption in the industry. YANG authors can immeditately
> start publishing with the new extensions.
> > - move faster to produce modules in the IETF (accept some
> errors/iteration)
> > - address the liaison from external standards bodies in a reasonable
> timeframe
> > - authors believe work is ready
> > - broad vendor support
> > - rough alignment with OpenConfig (use YANG 1.0 + OC Semver)
> > CONS:
> > - perception that we're "cheating" by not bumping our own spec's version
> > - Not fundamentally mandatory for clients or servers using YANG
> (mandatory for YANG claiming conformance to Module Versioning).
> >
> > Option 2 - RFC7950-bis: Publish a new version of the YANG language to
> allow NBC changes
> > ---
> > - NBC changes only allowed in a new (future) version of YANG
> > - TBD: YANG 1.2 vs 2.0 (note YANG 1.1 isn't BC with YANG 1.0)
> > - Content = Module Versioning + YANG Semver + very limited YANG NEXT
> items
> > - rev:non-backwards-compatible tag is a language keyword
> > - consequence: any use of it breaks all YANG 1.0/1.1 tooling that hasn't
> been updated
> > - TBD how to handle small NBC changes in IETF in the short term (i.e. non
> conformance to 7950)?
> > - RFC6991 bis - change the use/meaning of ip-address (or 

Re: [netmod] New Version Notification for draft-ma-netmod-immutable-flag-07.txt

[Rob Wilton (rwilton)]

Hi Qiufang,

It may be the WG understanding has moved on, but the latest version of the 
document hasn’t quite caught up, or otherwise I don’t find it clear, or seem to 
take very different interpretation of it.

Please see inline … (this is all with reference to -07).


From: maqiufang (A) 
Sent: 09 June 2023 16:39
To: Rob Wilton (rwilton) 
Cc: Kent Watsen ; Jan Lindblad (jlindbla) 
; Jürgen Schönwälder 
; Andy Bierman ; 
netmod@ietf.org
Subject: RE: [netmod] New Version Notification for 
draft-ma-netmod-immutable-flag-07.txt

Hi, Rob

Thanks for sharing your concerns, but I think there might be some 
misunderstanding that needs to be clarified, please see my reply inline.

From: Rob Wilton (rwilton) [mailto:rwilton=40cisco@dmarc.ietf.org]
Sent: Friday, June 2, 2023 7:01 PM
To: Kent Watsen mailto:kent+i...@watsen.net>>; Jan 
Lindblad (jlindbla) mailto:jlind...@cisco.com>>; Jürgen 
Schönwälder 
mailto:jschoenwaelder@constructor.university>>;
 Andy Bierman mailto:a...@yumaworks.com>>
Cc: maqiufang (A) mailto:maqiufa...@huawei.com>>; 
netmod@ietf.org<mailto:netmod@ietf.org>
Subject: RE: [netmod] New Version Notification for 
draft-ma-netmod-immutable-flag-07.txt

Hi Kent, all,

Writing as a contributor, I still have strong concerns with this draft.

From a YANG architecture perspective, I believe that the contents of the 
running datastore should be entirely under the client’s control, and servers 
should accept any valid configuration, and be able to move from any valid 
configuration to any other valid configuration.  We also already have the 
server datastore draft that I think should be the mechanism to allow a server 
to include server-controlled configuration before it is merged with running and 
validated as intended, that is somewhat outside the client’s control.  I.e., I 
think that having a clean split of ownership and responsibilities between a 
running datastore (managed by the client) and other datastores (e.g., intended 
and system-controlled) managed by the server is a good clean architecture.
I agree with you that the client should have fully control over the contents of 
the running datasore, but I don't see this draft(-07) conflicting with that 
goal. Maybe we should make it more explicit in the document, but it is already 
the case the immutable configuration can only be created by the system (and 
present in )
[Rob Wilton (rwilton)]
I think that the document is unclear about how it interplays with the system 
datastore, e.g., I find very few references to the system datastore, so I think 
that it would be helpful for that to be clarified.


E.g., section 1.2, starts with: “ The "immutable" concept defined in this 
document only documents existing write access restrictions to writable 
datastores.”, which I read as saying that the immutable flag is purely about 
// datastores because  and  are 
not writable datastores (as per RFC 8342, section 5), but from your comments 
below, I don’t think that is now the intent.

Further, even just having the server creating immutable configuration in 
, and allowing the client to theoretically have complete control over 
what is in , can still cause the server to reject config changes to 
running if  +  is merged to  and the “immutable” 
configuration in  means that  fails to validate, hence 
causing the change to  to be rejected.

If the immutable configuration is always immutable, then that is probably okay, 
since that configuration will always have been rejected.  But it isn’t clear to 
me what actual configuration is going to be marked at immutable.  E.g., could 
this include certificates that you don’t want the client to be able to change?  
If so, what happens if the client copies the certificate into  to 
fulfil a leafref dependencies, and then the system certificate gets updated by 
an out of bound process.  The copy of the certificate in system would have 
changed and now it would be different and conflict with the version of the 
certificate in running.

I think that it would be useful to have an example list of configurations that 
we expect to be handled this way.  I.e., to ensure that add


, other cases like the client creates a node instance but cannot modify that 
afterwards is the non-transactional behaviour we’ve discussed before and should 
be avoided.
[Rob Wilton (rwilton)]
I agree that this should be avoided, but section 2 of the document starts with:

2.  Solution Overview

   Already some servers handle immutable configuration data and will
   reject any attempt to the update of such data.  This document allows
   the existing immutable data node or instance to be formally
   documented by YANG extension or metadata annotation rather than be
   written as plain text in the description statement.

I interpret this as: Some servers already do this (i.e., effectively breaking 
transactional behaviour), and that we accept that this happens and provide a 
way to document (and 

Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts

[Rob Wilton (rwilton)]

> -Original Message-
> From: tom petch 
> Sent: 26 June 2023 16:41
> To: Rob Wilton (rwilton) ; Martin Björklund
> 
> Cc: netmod@ietf.org
> Subject: Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts
> 
> From: Rob Wilton (rwilton) 
> Sent: 26 June 2023 13:01
> 
> Hi Tom,
> 
> > -Original Message-
> > From: tom petch 
> > Sent: 26 June 2023 12:57
> >
> > From: netmod  on behalf of Rob Wilton (rwilton)
> > 
> > Sent: 13 June 2023 17:25
> >
> > Hi Martin,
> >
> > > -Original Message-
> > > From: netmod  On Behalf Of Martin Björklund
> > > Sent: 07 June 2023 08:22
> > >
> > > But the two drafts go way beyond fixing the problem your three
> > > examples illustrate.
> > [Rob Wilton (rwilton)]
> >
> > The actual goals of this work (i.e., the set of drafts) is aiming to 
> > address the
> > requirements stated here: https://datatracker.ietf.org/doc/html/draft-ietf-
> > netmod-yang-versioning-reqs-07.  Although never taken to RFC, I believe was
> > effectively last called and achieved WG consensus for the NETMOD WG.
> > Hopefully the chairs can chime in and keep me honest if I'm wrong on this
> > point.
> >
> > 
> > May be or may be not but there is no such I-D in the datatracker for NETMOD
> > nor can it be downloaded from the FTP site so effectively there are no
> > requirements to justify this substantial change.  Based on what I can 
> > access,
> the
> > module versioning I-D does not look like a good idea.
> [Rob Wilton (rwilton)]
> 
> Are you saying that you are unable to access the link above, i.e.,
> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-versioning-reqs-
> 07
> 
> Or are you saying that because this is currently an expired draft it isn't 
> valid, in
> which case, that would seem to be trivial to fix?
> 
> 
> I am saying that to review a draft, I download it in plain text and edit it 
> and my
> first choice is to look for it in
> https://www.ietf.org/ietf-ftp/internet-drafts/]
> and this draft is not there.
> My second choice is the datatracker for the WG, NETMOD in this case, under
> Active Internet Drafts and again it is not there.  At that point, I do not 
> look
> further, at least not during WGLC
[Rob Wilton (rwilton)] 

Okay.  In this particular case, I don't think that the fact that it isn't an 
active draft should prevent you from considering its contents as having achieve 
WG consensus.  But Joe Clarke, the editor for that document, is in the process 
of republishing it as -08.

Regards,
Rob


> 
> Tom Petch
> 
> Regards,
> Rob
> 
> 
> >
> > Tom Petch
> >
> > The shape/structure/content of the drafts is very similar to when these
> > documents were adopted in March 2020:
> >
> > Your comments on these document at adoption time are here
> >
> (https://mailarchive.ietf.org/arch/msg/netmod/r5TD0NDNgUbtX9EHZfB5hJJctN
> > 8/).  From that email, it is clear that you didn't support the YANG Semver
> > scheme, but my reading is that you were broadly supportive of the YANG
> > module versioning draft.
> >
> > Here are your review comments of the YANG module versioning draft at
> > adoption time:
> >
> https://mailarchive.ietf.org/arch/msg/netmod/MTGomxcdyNOmB7mgsFhItLKN
> > Jgk/
> >
> > Here is a thread where you are discussing supporting different revision 
> > label
> > schemes:
> >
> https://mailarchive.ietf.org/arch/msg/netmod/cEBiZKUSk0n7BeFwdiyaejc_Tsg/
> >
> > I appreciate that everyone has the right to change their mind at any point,
> but
> > as stated previously, I don't think that the shape of the solution has 
> > really
> > changed substantially since they were adopted.
> >
> >
> >   If the goal is to indicate that non-backwards
> > > compatible changes have occured, a single new extension statement
> > > could solve that.  (As I probably have stated before, personally I
> > > don't think this is necessary).
> >
> > That is one goal.  Another is to acknowledge that non-backwards-compatible
> > changes will occur, potentially even on branches.  Another is to align with 
> > the
> > versioning scheme that is being broadly used by the industry (but with
> > extensions to support a branched history).
> >
> >
> > >
> > > Apart from the updates to RFC 7950 section 11, I am mostly concerned
> > > about the additional complexity the "pluggable" revision-label scheme
> > > brings

Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts

[Rob Wilton (rwilton)]

Hi Tom,

> -Original Message-
> From: tom petch 
> Sent: 26 June 2023 12:57
> To: Rob Wilton (rwilton) ; Martin Björklund
> 
> Cc: netmod@ietf.org
> Subject: Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts
> 
> From: netmod  on behalf of Rob Wilton (rwilton)
> 
> Sent: 13 June 2023 17:25
> 
> Hi Martin,
> 
> > -Original Message-
> > From: netmod  On Behalf Of Martin Björklund
> > Sent: 07 June 2023 08:22
> >
> > But the two drafts go way beyond fixing the problem your three
> > examples illustrate.
> [Rob Wilton (rwilton)]
> 
> The actual goals of this work (i.e., the set of drafts) is aiming to address 
> the
> requirements stated here: https://datatracker.ietf.org/doc/html/draft-ietf-
> netmod-yang-versioning-reqs-07.  Although never taken to RFC, I believe was
> effectively last called and achieved WG consensus for the NETMOD WG.
> Hopefully the chairs can chime in and keep me honest if I'm wrong on this
> point.
> 
> 
> May be or may be not but there is no such I-D in the datatracker for NETMOD
> nor can it be downloaded from the FTP site so effectively there are no
> requirements to justify this substantial change.  Based on what I can access, 
> the
> module versioning I-D does not look like a good idea.
[Rob Wilton (rwilton)] 

Are you saying that you are unable to access the link above, i.e., 
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-versioning-reqs-07

Or are you saying that because this is currently an expired draft it isn't 
valid, in which case, that would seem to be trivial to fix?

Regards,
Rob


> 
> Tom Petch
> 
> The shape/structure/content of the drafts is very similar to when these
> documents were adopted in March 2020:
> 
> Your comments on these document at adoption time are here
> (https://mailarchive.ietf.org/arch/msg/netmod/r5TD0NDNgUbtX9EHZfB5hJJctN
> 8/).  From that email, it is clear that you didn't support the YANG Semver
> scheme, but my reading is that you were broadly supportive of the YANG
> module versioning draft.
> 
> Here are your review comments of the YANG module versioning draft at
> adoption time:
> https://mailarchive.ietf.org/arch/msg/netmod/MTGomxcdyNOmB7mgsFhItLKN
> Jgk/
> 
> Here is a thread where you are discussing supporting different revision label
> schemes:
> https://mailarchive.ietf.org/arch/msg/netmod/cEBiZKUSk0n7BeFwdiyaejc_Tsg/
> 
> I appreciate that everyone has the right to change their mind at any point, 
> but
> as stated previously, I don't think that the shape of the solution has really
> changed substantially since they were adopted.
> 
> 
>   If the goal is to indicate that non-backwards
> > compatible changes have occured, a single new extension statement
> > could solve that.  (As I probably have stated before, personally I
> > don't think this is necessary).
> 
> That is one goal.  Another is to acknowledge that non-backwards-compatible
> changes will occur, potentially even on branches.  Another is to align with 
> the
> versioning scheme that is being broadly used by the industry (but with
> extensions to support a branched history).
> 
> 
> >
> > Apart from the updates to RFC 7950 section 11, I am mostly concerned
> > about the additional complexity the "pluggable" revision-label scheme
> > brings.
> [Rob Wilton (rwilton)]
> 
> It feels like we are somewhat going in circles:
> 
> 1.The original proposal was to embed regular Semver 2.0.0 for the version
> numbers.
> 
> 2. That scheme was extended to what is being labelled as "Yang Semver"
> because regular Semver didn't support some level of branching that the
> vendors require to support customers on older releases over a much longer
> time period.  Semver 2.0.0 works best when the updates are always committed
> to the head of a linear sequence of versions, and if a bug needs to be fixed 
> in
> an older version then the user is forced to migrate to the latest version.
> 
> 3. If I recall correctly, you didn't like YANG Semver (and possibly not even
> Semver), and if I also recall correctly from a conversation then I think that 
> it is
> because you envisaged more advanced branching schemes and perhaps a
> version number scheme that follows branch history (and hence cannot also
> contain semantic meaning).  Based on that feedback, and an in-person side
> meeting, we moved to a revision label scheme, an nbc-marker, and
> standardizing a versioning scheme to fit into the revision-label scheme
> separately.  This was all in place when these documents were adopted.
> 
> Based on those who are or have participated in the weekly calls, I also 
>

Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts

[Rob Wilton (rwilton)]

Hi Martin,

> -Original Message-
> From: netmod  On Behalf Of Martin Björklund
> Sent: 07 June 2023 08:22
> To: rwilton=40cisco@dmarc.ietf.org
> Cc: netmod@ietf.org
> Subject: Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts
> 
> Hi,
> 
> But the two drafts go way beyond fixing the problem your three
> examples illustrate.
[Rob Wilton (rwilton)] 

The actual goals of this work (i.e., the set of drafts) is aiming to address 
the requirements stated here: 
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-versioning-reqs-07.
  Although never taken to RFC, I believe was effectively last called and 
achieved WG consensus for the NETMOD WG.  Hopefully the chairs can chime in and 
keep me honest if I'm wrong on this point.

The shape/structure/content of the drafts is very similar to when these 
documents were adopted in March 2020:

Your comments on these document at adoption time are here 
(https://mailarchive.ietf.org/arch/msg/netmod/r5TD0NDNgUbtX9EHZfB5hJJctN8/).  
From that email, it is clear that you didn't support the YANG Semver scheme, 
but my reading is that you were broadly supportive of the YANG module 
versioning draft.

Here are your review comments of the YANG module versioning draft at adoption 
time:
https://mailarchive.ietf.org/arch/msg/netmod/MTGomxcdyNOmB7mgsFhItLKNJgk/

Here is a thread where you are discussing supporting different revision label 
schemes:
https://mailarchive.ietf.org/arch/msg/netmod/cEBiZKUSk0n7BeFwdiyaejc_Tsg/

I appreciate that everyone has the right to change their mind at any point, but 
as stated previously, I don't think that the shape of the solution has really 
changed substantially since they were adopted.


  If the goal is to indicate that non-backwards
> compatible changes have occured, a single new extension statement
> could solve that.  (As I probably have stated before, personally I
> don't think this is necessary).

That is one goal.  Another is to acknowledge that non-backwards-compatible 
changes will occur, potentially even on branches.  Another is to align with the 
versioning scheme that is being broadly used by the industry (but with 
extensions to support a branched history).


> 
> Apart from the updates to RFC 7950 section 11, I am mostly concerned
> about the additional complexity the "pluggable" revision-label scheme
> brings.
[Rob Wilton (rwilton)] 

It feels like we are somewhat going in circles:

1.The original proposal was to embed regular Semver 2.0.0 for the version 
numbers.

2. That scheme was extended to what is being labelled as "Yang Semver" because 
regular Semver didn't support some level of branching that the vendors require 
to support customers on older releases over a much longer time period.  Semver 
2.0.0 works best when the updates are always committed to the head of a linear 
sequence of versions, and if a bug needs to be fixed in an older version then 
the user is forced to migrate to the latest version.

3. If I recall correctly, you didn't like YANG Semver (and possibly not even 
Semver), and if I also recall correctly from a conversation then I think that 
it is because you envisaged more advanced branching schemes and perhaps a 
version number scheme that follows branch history (and hence cannot also 
contain semantic meaning).  Based on that feedback, and an in-person side 
meeting, we moved to a revision label scheme, an nbc-marker, and standardizing 
a versioning scheme to fit into the revision-label scheme separately.  This was 
all in place when these documents were adopted. 

Based on those who are or have participated in the weekly calls, I also believe 
that the solution has reasonable industry support:
 - Representatives from Cisco, Ericsson, Huawei, Juniper, Nokia have all 
participated in the calls at various stages.
 - Other SDOs (3GPP at least, and ITU?) are waiting for this work.
 - OpenConfig is using Semver and has been for years.  I don't know if they 
will adopt IETF's particular solution, but I do think that we would at least be 
fairly aligned. 

I want to find a way that we can just get this work finished and published so 
that the authors and WG can move on to other, hopefully more interesting, stuff.

Is the solution perfect?  No, but engineering solutions never are.

Is the solution good enough?  I believe so, yes.

Regards,
Rob

// As an author and participant in this work for 5+ years.


> 
> 
> 
> 
> /martin
> 
> 
> 
> 
> "Rob Wilton \(rwilton\)"  wrote:
> > I'm wondering whether we are in the realm of missing the bigger
> > picture here, or perfection being the enemy of good enough.
> >
> > My first example:
> >
> > The sedate WG (https://datatracker.ietf.org/wg/sedate/about/) has
> > recently been rechartered to respecify the meaning of the date string
> > in a non-ba

Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts

[Rob Wilton (rwilton)]

I'm wondering whether we are in the realm of missing the bigger picture here, 
or perfection being the enemy of good enough.

My first example:

The sedate WG (https://datatracker.ietf.org/wg/sedate/about/) has recently been 
rechartered to respecify the meaning of the date string in a non-backwards 
compatible way.  Yes, this same date string format that is very widely 
implemented and deployed.  I originally had a block on the new charter until it 
was pointed out that the IETF specification was being updated because it was 
inconsistent with the ISO time specification and inconsistent with how the date 
string was actually being used by implementations.  I.e., the specification is 
being updated to reflect reality.  I.e., fixing the specification in a 
non-backwards compatible way ends up being pragmatically the right thing to do 
(and this is entirely allowed by the IETF process).

Ideally, the date-and-time typedef in YANG would also be updated to match the 
update to the definition in RFC 3339 by SEDATE.  But this is clearly not 
compliant with section 11 of RFC 7950 (because the value space of allowed 
values is being narrowed).  The only available choice would be to define a new 
date-and-time-2 typedef which modules could then update to.  Of course, you 
cannot update the existing leaves to use the new date-and-time-2 typedef 
because that also violates section 11.  So, you end up with two datetime leaves 
everywhere the date-and-time typedef is used, hopefully with one deprecated 
(and at some point, obsoleted).  Of course, defining the new datetime version 
leaves could also break any loosely related modules that may have xpath 
expressions dependent on that date-time leaf (that the updating module author 
may not even know about) which would need to be updated to depend on either of 
the leaves.  I also don't think that RFC 7950 is clear about whether deprecated 
leaves must be implemented by all implementations or not, so realistically 
clients will need to handle setting either (or perhaps in some cases, both) of 
the datetime leaves, depending on implementation, probably with a different mix 
across modules (in vast stages of being updated).  What happens if some 
instances of those datetime leaves are mandatory configuration and become 
obsolete?  Is a client required to set it or not, the pragmatic answer being 
that again RFC 7950 is unclear and again this will likely be implementation 
dependent.  What about if some of those datetime leaves are list keys?  I 
believe that the only solution that RFC 7950 allows for would be to duplicate 
the list, deprecating the old one, again requiring updates to all augmenting 
modules, and corresponding impact and churn on clients and servers. 

I suspect that OpenConfig may also have a date-and-time typedef.  I can be 
certain about how they would handle this same issue - they will just update the 
definition.  Some clients/servers may have minor impacts when they update to a 
new version of the model, but the impact and effort required is minimal, and I 
think several orders of magnitude less then the potential resultant churn than 
would happen by strictly following the RFC 7950 section 11 rules.

Some may argue that I'm not being pragmatic, and that this could just be 
handled as a bugfix, changing the existing type.  This is one of the key things 
that the YANG versioning is trying to accomplish and allow.  It isn't aiming to 
say that module designers have carte blanch to change modules in non-backwards 
compatible ways.  Instead, it is saying that in some cases, the pragmatic 
solution is to knowingly break the RFC 7950 rules and make a breaking change 
because that causes less impact.  Further, a key aim of the versioning work is 
that it is much better to be explicit that a breaking change has occurred such 
that a client can easily be warned of that change and take any mitigation 
necessary - which in the datetime instance above, is quite possibly that no 
mitigation is required at all.

Finally, I will note that rfc-6691-bis contains a change to the datetime 
definition that is not backwards compatible with the existing definition 
because the semantics of the leaf are being redefined.


A somewhat similar second example:

The YANGs IP address type handling of zone information is very similar to my 
first issue, where OpenConfig came to the pragmatic conclusion that (in their 
models) 100% of the use cases of IP addresses only use the numeric form without 
zone identifiers, and hence when someone sees the typedef ip_address, this is 
what they are thinking of, so they just pragmatically updated their definition 
of ip_address type.

Somewhat related to this, I will note that rfc-6691-bis contains a change to 
the ipv4-address and ipv6-address regex definition that is not backwards 
compatible with the existing definition (it narrows the valuespace for zone-ids 
restricting it to ASCII letters and digits whereas previously it allowed for 

Re: [netmod] New Version Notification for draft-ma-netmod-immutable-flag-07.txt

[Rob Wilton (rwilton)]

Hi Kent, all,

Writing as a contributor, I still have strong concerns with this draft.

From a YANG architecture perspective, I believe that the contents of the 
running datastore should be entirely under the client’s control, and servers 
should accept any valid configuration, and be able to move from any valid 
configuration to any other valid configuration.  We also already have the 
server datastore draft that I think should be the mechanism to allow a server 
to include server-controlled configuration before it is merged with running and 
validated as intended, that is somewhat outside the client’s control.  I.e., I 
think that having a clean split of ownership and responsibilities between a 
running datastore (managed by the client) and other datastores (e.g., intended 
and system-controlled) managed by the server is a good clean architecture.

I appreciate that not all servers allow clients to fully control their running 
configuration, but I think that a better solution (for management clients) so 
to encourage servers to migrate towards the goal of giving full ownership over 
running to the clients.  Hence, I’m particularly concerned about standardizing 
a YANG meta-data annotation that allows, and arguably even encourages, vendors 
or other SDOs to build immutable properties into their management models that 
breaks this goal.  I think that we need to be really careful here that we are 
not creating yet another fork of NETCONF/YANG with a fairly fundamentally 
different architecture to what we are currently aiming for.

I am somewhat more amenable to an annotation that indicates that if a 
particular leaf is modified it will potentially cause a more impactful change, 
by effectively causing a delete and re-add of the parent list/container 
(changing interface type could be an example of this).  But I don’t think that 
this stop clients from modifying the leaf to a new valid state, instead, the 
server should perform any necessary orchestration steps to apply the 
configuration rather than pushing that as extra orchestrations steps onto the 
client.  There is also part of me that questions how useful such an annotation 
or metadata would really be given that there are many other data nodes that 
have wide impact if they are modified.  So, from this perspective, I think that 
“immutable” is perhaps the wrong name.


Finally, I still question the assertion “Clients believe that "config true" 
nodes are modifiable even though the server is allowed to reject such a 
modification at any time.“ and regard it as possibly a bit disingenuous or 
perhaps being overplayed.  I’m not sure whether this assertion is coming from 
the YANG language (i.e., does RFC 7950 state this – I couldn’t quickly find 
it), or from NETCONF?  To me, it makes sense that a NETCONF server can reject a 
configuration change for various reasons (e.g., invalid yang, out of memory, 
some bug or flaw in the implementation), but I don’t think that really means 
that it is okay for a server (from a client’s perspective) to arbitrarily 
reject configuration.  A slightly strawman, but, e.g., would it be valid for a 
server to reject a request based on whether a generated random number was odd 
or even?  Can a server reject a config request because although the YANG schema 
indicates that it should be a number, the server has decided that sometimes it 
will only accept the item as string?  Perhaps according to the NETCONF spec 
these are both valid, but I’m not sure that either of these behaviours are 
helpful to clients or within the spirit of what is expected.



I do think that this is useful and interesting topic to have further 
discussion, particularly because of the external SDO interest - possibly a 
dedicated interim may be helpful – if we can get the key parties together?  As 
to adoption, I’m not necessarily opposed to this because there is definitely 
interest in this work, but personally I would like to see quite significant 
changes, and I suspect that more work is required to reach consensus.

Regards,
Rob


From: Kent Watsen 
Sent: 01 June 2023 21:55
To: Jan Lindblad (jlindbla) ; Jürgen Schönwälder 
; Andy Bierman ; Rob 
Wilton (rwilton) 
Cc: maqiufang (A) ; netmod@ietf.org
Subject: Re: [netmod] New Version Notification for 
draft-ma-netmod-immutable-flag-07.txt

Hi Quifang,

The latest update looks very good to me - IMO, ready for adoption.

Jan, Jurgen, Andy, Rob - can you confirm that your concerns have been addressed?

Thanks,
Kent




On May 25, 2023, at 8:16 AM, maqiufang (A) 
mailto:maqiufang1=40huawei@dmarc.ietf.org>>
 wrote:

Hi, all
This version reflects the input we've received from the mailing list.

Thank you everyone(Jan, Rob, Kent, Jürgen, Andy, Frank et al.) for your great 
comments and suggestions!
Please see if the following updates are good for you:
   *  Use a Boolean type for the immutable value in YANG extension and
  metadata annotation
   *  Define a "with-immutable

Re: [netmod] Comments on draft-ietf-netmod-yang-module-versioning-09

[Rob Wilton (rwilton)]

Hi Juergen, Andy,

With an author/contributor hat on ...

It is unclear to me, from an RFC document perspective, what is being proposed 
here, and appreciate that each of you may have different thoughts as to what is 
being proposed.

E.g., are you proposing:
 (1) That the yang module versioning draft should update RFC 7950 to define a 
yang version "1.2" or "2.0" label, but still keeps the new extensions defined 
in a separate module?
 (2) The same as (1) but also changing the statements to be part of the formal 
YANG language (but still in separate documents that update RFC 7950)?
 (3) To do an RFC 7950-bis for YANG 1.2/2.0, that strictly only includes the 
module versioning work?  E.g., leaving the semantic version numbers as a 
separate draft. 
 (4) To look at YANG 1.2/2.0 in a wider scope, and consider this work alongside 
the other 100 proposed issues/enhancements 
(https://github.com/netmod-wg/yang-next/issues), for the next version of YANG.
 (5) something else ...

My overriding concern here is that there is a pretty clear industry support for 
accepting that non-backwards-compatible changes do sometimes occur and whilst 
it is entirely appropriate for them to be minimized, it is still helpful to 
have a way to accurately indicate when they do occur.  Depending on what the 
actual work is, I think that doing (1) or (2) might take another 4-8 months, 
doing (3) might take 8-12 months, and doing (4) could be another 5 years, and 
it is worth noting that the first draft bringing Semver to IETF was by Benoit 6 
years ago.  I.e., we have already been working on this for a long time.

After the previous module-versioning last-call we attempted to refine the draft 
further to make the functionality more optional, specifically, changing the 
semantics of "recommended-min" for imports to make it suggestive guidance 
rather than changing the actual import behaviour.  So, my reading is that the 
core changes to the YANG specification by this document are really those 
definition in section 3, and I think that these can be mitigated via a CLI 
option to tools that are performing comparisons of YANG modules.

Pragmatically, I would like to see the WG publish these as separate RFCs, in 
the format that they are now, to get this work completed, so that we can move 
on.  Once the versioning work is complete, then I think that it would be 
helpful for the WG to consider doing a rev of RFC 7950, that should include 
this versioning work (including defining formal YANG keywords rather than 
extension keywords) and also evaluate whether some of the other 
proposals/enhancements tracked on github should be considered, along with 
trying to clean up the documents, e.g., moving the NETCONF protocol specific 
parts out of the base YANG spec, moving the XML encoding into its own separate 
document.

Regards,
Rob


> -Original Message-
> From: netmod  On Behalf Of Jürgen Schönwälder
> Sent: 13 May 2023 23:14
> To: Andy Bierman 
> Cc: NetMod WG 
> Subject: Re: [netmod] Comments on draft-ietf-netmod-yang-module-
> versioning-09
> 
> On Sat, May 13, 2023 at 01:13:06PM -0700, Andy Bierman wrote:
> >
> > The only correct way to remove MUST/MUST NOT from the "YANG
> contract"
> > is to introduce a new YANG language version (1.2), and make a new
> contract.
> 
> +1
> 
> > Ironically, the WG seems to understand the importance of proper
> management
> > for NBC changes in YANG content, but not the YANG language itself.
> 
> yup
> 
> /js
> 
> --
> Jürgen Schönwälder  Constructor 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
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Unknown bits - backwards compatibility

[Rob Wilton (rwilton)]

I was looking at this draft again, and since I had read the -02 version of the 
draft I thought that I would send the comments here.

My no hats view here (looking at the latest draft) is:

  *   documenting something here is probably helpful because this is an issue 
that folks are experiencing and providing written guidance on how to handle it 
helpful to the YANG modelling community.
  *   having such a document update RFC 8407 would probably be helpful (to help 
YANG authors find it),
  *   but I'm concerned that the proposed solution is not backwards compatible 
at the instance data level.  E.g., an old client talking to a new server would 
still hit a problem if the server changed from sending an unknown "bit-" to 
a known bit (defined in a backards-compatible module update), and if the old 
client doesn't know/understand the now known bit (because they are still coded 
against the older module version), then the client may break.  This makes me 
think that there is going to be some subtleties around when it is safe to not 
send an unknown bit, hence my suggestion was to call it just "bits" (which is 
already in -02) and *always sending* this leaf may be a more backwards 
compatible choice.  It isn't clear to me, for the "all bits" leaf, whether 
sending this as a raw uint8 - uint64, or binary, and doing the decode on the 
client side (if required) might be a better choice than sending them as a 
generic bits type.

Regards,
Rob

From: netmod  On Behalf Of Italo Busi
Sent: 14 April 2023 09:05
To: Jason Sterne (Nokia) ; Jeffrey Haas 
; netmod@ietf.org
Subject: Re: [netmod] Unknown bits - backwards compatibility

Jason, Jeffrey,

If the need is to report the value of a received protocol field for 
debugging/troubleshooting purposes, I am wondering why not using a binary type 
instead of a bits type or, better, a YANG leaf of bits type for the known bits 
and another YANG leaf of binary type for all known/unknown bits

Trailing zeros can be added when the protocol field is not an integer number of 
octets

In this way there will be no backward compatibility issues when unknown bits 
are assigned and becomes known

My 2 cents

Italo

From: Jason Sterne (Nokia) 
mailto:jason.ste...@nokia.com>>
Sent: mercoledì 12 aprile 2023 23:26
To: Jason Sterne (Nokia) 
mailto:jason.ste...@nokia.com>>; Jeffrey Haas 
mailto:jh...@pfrc.org>>; netmod@ietf.org
Subject: Re: [netmod] Unknown bits - backwards compatibility

It just occurred to me that to avoid the NBC change we could also consider just 
calling this new typedef "raw-bits" and always outputting all the bits in the 
second leaf (whether they are known or not)?  I suspect this was already 
considered though...

Jason

From: netmod mailto:netmod-boun...@ietf.org>> On 
Behalf Of Jason Sterne (Nokia)
Sent: Wednesday, April 12, 2023 5:24 PM
To: Jeffrey Haas mailto:jh...@pfrc.org>>; 
netmod@ietf.org
Subject: [netmod] Unknown bits - backwards compatibility

Hi Jeff,

One topic that came up during the IETF 116 NETMOD meeting was backwards 
compatibility.

>From what I understand, a leaf (e.g. unknown-flags) that uses the unknown-bits 
>typedef would never change its definition in YANG. It would always be defined 
>as unknown-bits with all 64 bit definitions even as more and more bits become 
>"known".  *But* the system would suddenly stop reporting bit-0, then bit-1 in 
>that unknown-flags leaf as those bits become known.

Strictly speaking, that should probably be considered an NBC change although it 
is a bit of a grey zone - the NBC rules for state are fuzzy (theoretically they 
are defined by RFC7950 but it is clear those rules were focused on config, and 
the same goes for all our new versioning work). But I could imagine an 
implementation that was previously seeing bit-0 returned and suddenly stops 
seeing that bit-0 returned (which could cause different 
interpretation/behavior). So in some ways the semantics of the unknown-flags 
leaf has changed. It may be better to just flag this as an NBC change so a user 
would be drawn to look at it, and make a decision that they do or don't have to 
update their handling/use of it?

The known flags leaf would only go through backwards compatible changes though 
(since we'd always be additive in adding bits) - assuming bit positions don't 
change in the protocol.

It would probably help to show an example of what a YANG module looks like for 
step 1 and then step 2 (an unknown becomes known), and also what is returned in 
NETCONF in step 1 and step 2. You partially have that in section 3.2 although 
the YANG model isn't shown and it might be good to explicitly mention that 
 isn't returned (note it may also be valid to return 
).

Jason


From: netmod mailto:netmod-boun...@ietf.org>> On 
Behalf Of Jeffrey Haas
Sent: Monday, April 10, 2023 2:48 PM
To: netmod@ietf.org
Subject: Re: [netmod] Request for WG adoption, 
draft-haas-netmod-unknown-bits-01.txt

Re: [netmod] Unknown bits - backwards compatibility

[Rob Wilton (rwilton)]

Hi Jason,

Yes, I was thinking that you would always return the raw value and the bits 
encoded value, but perhaps a server could optionally elide the raw value when 
it knows that it can be fully represented by the bits value.

Regards,
Rob



From: Jason Sterne (Nokia) 
Sent: 17 April 2023 14:05
To: Rob Wilton (rwilton) ; Italo Busi 
; Jeffrey Haas 
Cc: netmod@ietf.org
Subject: RE: [netmod] Unknown bits - backwards compatibility

Rob & Italo - are you proposing that the "raw-bits" are all always returned 
(whether they are known or not)?
Jason

From: netmod mailto:netmod-boun...@ietf.org>> On 
Behalf Of Rob Wilton (rwilton)
Sent: Monday, April 17, 2023 7:43 AM
To: Italo Busi 
mailto:Italo.Busi=40huawei@dmarc.ietf.org>>;
 Jeffrey Haas mailto:jh...@pfrc.org>>
Cc: netmod@ietf.org<mailto:netmod@ietf.org>
Subject: Re: [netmod] Unknown bits - backwards compatibility


CAUTION: This is an external email. Please be very careful when clicking links 
or opening attachments. See the URL nok.it/ext for additional information.


Italo's suggest was also how I was thinking of this.

We could define a convention for how the "raw" leaf should be named relative to 
the bits decoded leaf, and also what type the "raw" leaf should use.  E.g., in 
the case where the length of the bits field is known (e.g., it is 
defined/constrained by a protocol spec), then it could just use a uint8 - 
through uint64 as appropriate, otherwise I would have thought that binary would 
be appropriate underlying type.

As new bits get defined then the bits type would get updated, but the "raw" 
leaf wouldn't need to change.

Hence a draft could:

  *   Define a convention for naming the "raw value" leaves to be used in 
conjunction with the decodable bits types leaves.
  *   Define typedefs that wrap (uint8 - uint64, and binary) to indicate the 
semantics as representing undecoded bits.
  *   Define a convention for decoding/displaying the new types (perhaps in 
conjunction with the decoded bits type leaf).

Regards,
Rob

// As a contributor.


From: netmod mailto:netmod-boun...@ietf.org>> On 
Behalf Of Italo Busi
Sent: 14 April 2023 15:33
To: Jeffrey Haas mailto:jh...@pfrc.org>>
Cc: netmod@ietf.org<mailto:netmod@ietf.org>
Subject: Re: [netmod] Unknown bits - backwards compatibility

Hi Jeff,

I agree with you on the preference for hex-string versus binary in YANG

I also agree with you concerns with hexdump, but parsing has some issues when 
something is unknown (these are the issues that have triggered your draft and 
this discussion), although I also agree with you that the unknown is for 
'exception cases'

That's why I would prefer:

  *   A YANG leaf of type bits to report known bits (after parsing) which will 
cover "most circumstances"
  *   Another YANG leaf of type hex-string for the 'exception cases' (or for 
those who really loves hexdump)

There is a similar issue when reporting a protocol field representing an 
enumeration. If the received value is known, it would be better to report a 
string/identity name associated with the recived value but when the value is 
unknown it is only possible to report the hexdump of the field

Italo

From: Jeffrey Haas mailto:jh...@pfrc.org>>
Sent: venerdì 14 aprile 2023 14:49
To: Italo Busi mailto:italo.b...@huawei.com>>
Cc: Jason Sterne (Nokia) 
mailto:jason.ste...@nokia.com>>; 
netmod@ietf.org<mailto:netmod@ietf.org>
Subject: Re: [netmod] Unknown bits - backwards compatibility

Italo,


On Apr 14, 2023, at 4:04 AM, Italo Busi 
mailto:italo.b...@huawei.com>> wrote:

If the need is to report the value of a received protocol field for 
debugging/troubleshooting purposes, I am wondering why not using a binary type 
instead of a bits type or, better, a YANG leaf of bits type for the known bits 
and another YANG leaf of binary type for all known/unknown bits

Type binary isn't generically helpful.  The implementation has to do something 
with the base64 stream it gets.  If it's just going to dump it in hex format, 
you might as well just say that and use hex-string.

The use case here is most bits are known and these are exception cases.  
Ideally in most circumstances, the leaf containing the unknowns is absent.

Perhaps a bit of personal context:
"Hey, Jeff... why not just get a hexdump of the packet?"
"I've spent 20+ years looking at different tools' dumps of bits of BGP PDU and 
I'm sick of it.  The code knows how to parse out fields, let it do that work."

-- Jeff (who keeps expecting this conversation to devolve to a proposal for 
netconf streaming tcpdump)

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

Re: [netmod] Unknown bits - backwards compatibility

[Rob Wilton (rwilton)]

Italo's suggest was also how I was thinking of this.

We could define a convention for how the "raw" leaf should be named relative to 
the bits decoded leaf, and also what type the "raw" leaf should use.  E.g., in 
the case where the length of the bits field is known (e.g., it is 
defined/constrained by a protocol spec), then it could just use a uint8 - 
through uint64 as appropriate, otherwise I would have thought that binary would 
be appropriate underlying type.

As new bits get defined then the bits type would get updated, but the "raw" 
leaf wouldn't need to change.

Hence a draft could:

  *   Define a convention for naming the "raw value" leaves to be used in 
conjunction with the decodable bits types leaves.
  *   Define typedefs that wrap (uint8 - uint64, and binary) to indicate the 
semantics as representing undecoded bits.
  *   Define a convention for decoding/displaying the new types (perhaps in 
conjunction with the decoded bits type leaf).

Regards,
Rob

// As a contributor.


From: netmod  On Behalf Of Italo Busi
Sent: 14 April 2023 15:33
To: Jeffrey Haas 
Cc: netmod@ietf.org
Subject: Re: [netmod] Unknown bits - backwards compatibility

Hi Jeff,

I agree with you on the preference for hex-string versus binary in YANG

I also agree with you concerns with hexdump, but parsing has some issues when 
something is unknown (these are the issues that have triggered your draft and 
this discussion), although I also agree with you that the unknown is for 
'exception cases'

That's why I would prefer:

  *   A YANG leaf of type bits to report known bits (after parsing) which will 
cover "most circumstances"
  *   Another YANG leaf of type hex-string for the 'exception cases' (or for 
those who really loves hexdump)

There is a similar issue when reporting a protocol field representing an 
enumeration. If the received value is known, it would be better to report a 
string/identity name associated with the recived value but when the value is 
unknown it is only possible to report the hexdump of the field

Italo

From: Jeffrey Haas mailto:jh...@pfrc.org>>
Sent: venerdì 14 aprile 2023 14:49
To: Italo Busi mailto:italo.b...@huawei.com>>
Cc: Jason Sterne (Nokia) 
mailto:jason.ste...@nokia.com>>; 
netmod@ietf.org
Subject: Re: [netmod] Unknown bits - backwards compatibility

Italo,


On Apr 14, 2023, at 4:04 AM, Italo Busi 
mailto:italo.b...@huawei.com>> wrote:

If the need is to report the value of a received protocol field for 
debugging/troubleshooting purposes, I am wondering why not using a binary type 
instead of a bits type or, better, a YANG leaf of bits type for the known bits 
and another YANG leaf of binary type for all known/unknown bits

Type binary isn't generically helpful.  The implementation has to do something 
with the base64 stream it gets.  If it's just going to dump it in hex format, 
you might as well just say that and use hex-string.

The use case here is most bits are known and these are exception cases.  
Ideally in most circumstances, the leaf containing the unknowns is absent.

Perhaps a bit of personal context:
"Hey, Jeff... why not just get a hexdump of the packet?"
"I've spent 20+ years looking at different tools' dumps of bits of BGP PDU and 
I'm sick of it.  The code knows how to parse out fields, let it do that work."

-- Jeff (who keeps expecting this conversation to devolve to a proposal for 
netconf streaming tcpdump)

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

Re: [netmod] [Trustees] draft-moriarty-yangsecuritytext vs errata

[Rob Wilton (rwilton)]

Hi Kathleen,

The short answer to your question is maybe.  The longer answer is my email 
reply to Stephan and Joel below.

But if you are also okay, or at least don’t object, to the errata path, then I 
will kick off a proposed errata so that it can reviewed/discussed.

Regards,
Rob


From: Kathleen Moriarty 
Sent: 04 April 2023 19:14
To: Stephan Wenger 
Cc: Rob Wilton (rwilton) ; Jürgen Schönwälder 
; Joel Halpern ; 
Deen, Glenn ; trust...@ietf.org; netmod@ietf.org; The 
IESG 
Subject: Re: [netmod] [Trustees] draft-moriarty-yangsecuritytext vs errata

Rob,

Multiple instances could be confusing, agreed. You’ll be going a -bis soon 
anyway to update the considerations, is that correct?

Thank you,
Kathleen
Sent from my mobile device


On Apr 4, 2023, at 1:52 PM, Stephan Wenger 
mailto:st...@stewe.org>> wrote:

Hi Rob,
Thanks for your detailed response.  I will not stand in the way of the errata 
round, as it seems well justified.
Stephan

From: Rob Wilton (rwilton) mailto:rwil...@cisco.com>>
Date: Tuesday, April 4, 2023 at 09:47
To: Jürgen Schönwälder 
mailto:jschoenwaelder@constructor.university>>,
 Stephan Wenger mailto:st...@stewe.org>>, Joel Halpern 
mailto:j...@joelhalpern.com>>
Cc: Kathleen Moriarty 
mailto:kathleen.moriarty.i...@gmail.com>>, 
Deen, Glenn mailto:glenn_d...@comcast.com>>, 
trust...@ietf.org<mailto:trust...@ietf.org> 
mailto:trust...@ietf.org>>, 
netmod@ietf.org<mailto:netmod@ietf.org> 
mailto:netmod@ietf.org>>, The IESG 
mailto:i...@ietf.org>>
Subject: RE: [netmod] [Trustees] draft-moriarty-yangsecuritytext vs errata
Hi Stephan, Joel,

I'm basically coming at this from a similar position as Jürgen.

I regard RFC 8407 as providing general guidance to authors of YANG modules both 
within and outside the IETF.  I.e., it is providing best practice guidelines 
for how YANG modules should be written and documented in specifications.  As 
such, it seems entirely reasonable to me that the at the time that the draft 
was approved by the Netmod WG that the consensus was that the security 
considerations template (or the updated wiki that is references) could be used 
by specifications outside of the IETF.

From the conversations that I had with Glenn recently, my interpretation was 
that template text in RFCs SHOULD have the BEGIN/END TEMPLATE TEXT markers 
around the template text to ensure that the appropriate IETF trust licence 
applies to the template text.  If that interpretation is correct, then the lack 
of these markers just looks like a mistake in RFC 8407.

Joel, to answer the specific question that you asked: No, I don’t think that we 
would necessarily rev RFC 8407, but it is a possible outcome.  The current text 
in RFC 8407 allows for an updated template to be provided on the wiki page and 
used in RFCs without necessarily needing to bis RFC 8407.  Hence I think that 
there are various questions with unknown answers before we end up going down 
the RFC 8407 bis path, e.g., (i) does the community agree with my proposed 
template changes (noting that I haven't even written or provided them yet, only 
proposed changing them), (ii) can this be done just by updating the wiki, (iii) 
is this clarification worth the effort of opening RFC 8407 up for.  I.e., if we 
ask the IEEE to wait for a bis version of this document then I have no 
realistic idea about how long they could be waiting or even if this would 
happen at all.

Having a copy of the template text in a separate RFC also has its downsides for 
the IETF community because there would then be three copies of the security 
template, and if the template text does change as I propose then it seems more 
likely that authors would end up picking the wrong template for their documents.

As for the precedence of using errata, I would be okay with that too - i.e., I 
think that just shows that we can be pragmatic and not get stuck in running 
extra process only for processes sake.

Regards,
Rob


> -Original Message-
> From: Jürgen Schönwälder 
> mailto:jschoenwaelder@constructor.university>>
> Sent: 04 April 2023 16:43
> To: Stephan Wenger mailto:st...@stewe.org>>
> Cc: Joel Halpern mailto:j...@joelhalpern.com>>; Rob 
> Wilton (rwilton)
> mailto:rwil...@cisco.com>>; Kathleen Moriarty 
> mailto:kathleen.moriarty.i...@gmail.com>>;
> Deen, Glenn mailto:glenn_d...@comcast.com>>; 
> trust...@ietf.org<mailto:trust...@ietf.org>;
> netmod@ietf.org<mailto:netmod@ietf.org>; The IESG 
> mailto:i...@ietf.org>>
> Subject: Re: [netmod] [Trustees] draft-moriarty-yangsecuritytext vs errata
>
> We can consider this an editing error since we forgot to put markers
> around the boilerplate. Nobody likely understood that these markers,
> which were originally introduced for code components and to support
> tools, have second legal meaning. This is for me the more sub

Re: [netmod] Comments on draft-ma-netmod-immutable-flag-06

[Rob Wilton (rwilton)]

Hi Kent,

Some of my concern stems from the fact that during the NMDA architecture 
discussions there was a strong desire to make the configuration data stored in 
 to be owned by the client.  I.e., the server has the right to accept 
or reject a particular configuration but ultimately it is the client that 
should control what is in .  Related to this, is the goal of ensuring 
the validation of the configuration is based on the state that the 
configuration represents, not the particular config edit that is being made to 
transition the configuration into that state.  I.e., it should be possible for 
a client to change the configuration from any valid state A to any valid state 
B, without requiring extra client orchestration steps to keep the server happy 
(e.g., you can transition from A to B, but must go via C, D and E on the way).  
Or to put it another way, if such steps are required, then it is much simpler 
(for an automation client) to do those transitional steps on the server than it 
is to expose and force them on to the client.

As you point out, existing implementations don’t always follow these rules 
above, but I regard these as warts in the implementations relative to following 
the ideal architecture above.  As such, I have little issue with a YANG 
extension or metadata annotation to programmatically indicate to clients where 
these aberrations occur for this use case.

But this isn’t what the 3GPP liaison is asking for.  They are requesting to 
bake the edit-config constraints directly into the management APIs defined in 
YANG because this is how their underlying management model is defined and they 
don’t want to change their underlying paradigm.  No longer is YANG just 
defining the configuration data model, but protocol edit-config semantics are 
being merged and baked into the data model defining the management API.

These newly defined management APIs will not just work with existing generic 
YANG clients and orchestrators because I presume that the clients will require 
custom code to be able to successfully interface with the server implementing 
these models.  Perhaps these annotations provide sufficient information for 
YANG clients to generically work around these restrictions?  But even in the 
case that they do then I still question whether that is really helpful.  I.e., 
what is ultimately achieved other than the addition of some extra complexity in 
the automation, and what is the true goal here.  If the aim is to signal to the 
client that there are some properties that cannot be changed without tearing 
down the containing service in a traffic impacting way, then rather than 
marking the properties as being immutable, it might be sufficient to annotate 
them as service impacting if changed.  This might still provide the necessary 
visibility and awareness to the client, whilst avoiding additional 
orchestration complexity for clients.  After all, there are many properties in 
the network configuration models standardized in the IETF (and OpenConfig) that 
are similarly service impacting if changed, that don’t seemingly require any 
protection.

It also feels that we are on the path of fracturing the definition of the 
NETCONF/YANG management protocols, which is somewhat like how OpenConfig 
decided to interpret the pattern statement regex language differently (which 
they have now backtracked on) or their recent statement that servers are not 
generally expected/required to validate leaf ref constraints in the running 
configuration.  Each of these little cuts, whilst innocent and good intentioned 
on their own, risk gradually devaluing the common standards by creating many 
incompatible subvariants of the language and protocols.

Hence, this is why I think Jan’s approach of looking at the individual problems 
that are being solved and having a discussion as to what is the best way of 
solving these individual problems may result in a better overall solution.  
Specifically, is there a compromise that can meet 3GPP’s and ITU’s goals 
without eroding the underlying NETCONF/YANG architecture?

Regards,
Rob

// Still no hats.

From: netmod  On Behalf Of Kent Watsen
Sent: 03 April 2023 22:23
To: Rob Wilton (rwilton) 
Cc: Jan Lindblad (jlindbla) ; 
netmod@ietf.org
Subject: Re: [netmod] Comments on draft-ma-netmod-immutable-flag-06

Hi Rob,


- In terms of properties that cannot be changed once written, I would rather 
see this issue framed more in the direction of it just being extra 
documentation written in a machine-readable way.  Specifically, using the 
annotation to give an indication that servers MAY reject requests to 
create/delete, or change, the configuration, but not requiring that they do so. 
 I.e., at the data model level, I don't think that we should preclude servers 
being able to handle this is in a more client friendly way (e.g., by breaking a 
single client transaction up into multiple internal transactional changes where 
needed).

I agree

Re: [netmod] [Trustees] draft-moriarty-yangsecuritytext vs errata

[Rob Wilton (rwilton)]

Hi Stephan, Joel,

I'm basically coming at this from a similar position as Jürgen.

I regard RFC 8407 as providing general guidance to authors of YANG modules both 
within and outside the IETF.  I.e., it is providing best practice guidelines 
for how YANG modules should be written and documented in specifications.  As 
such, it seems entirely reasonable to me that the at the time that the draft 
was approved by the Netmod WG that the consensus was that the security 
considerations template (or the updated wiki that is references) could be used 
by specifications outside of the IETF.

From the conversations that I had with Glenn recently, my interpretation was 
that template text in RFCs SHOULD have the BEGIN/END TEMPLATE TEXT markers 
around the template text to ensure that the appropriate IETF trust licence 
applies to the template text.  If that interpretation is correct, then the lack 
of these markers just looks like a mistake in RFC 8407.

Joel, to answer the specific question that you asked: No, I don’t think that we 
would necessarily rev RFC 8407, but it is a possible outcome.  The current text 
in RFC 8407 allows for an updated template to be provided on the wiki page and 
used in RFCs without necessarily needing to bis RFC 8407.  Hence I think that 
there are various questions with unknown answers before we end up going down 
the RFC 8407 bis path, e.g., (i) does the community agree with my proposed 
template changes (noting that I haven't even written or provided them yet, only 
proposed changing them), (ii) can this be done just by updating the wiki, (iii) 
is this clarification worth the effort of opening RFC 8407 up for.  I.e., if we 
ask the IEEE to wait for a bis version of this document then I have no 
realistic idea about how long they could be waiting or even if this would 
happen at all.

Having a copy of the template text in a separate RFC also has its downsides for 
the IETF community because there would then be three copies of the security 
template, and if the template text does change as I propose then it seems more 
likely that authors would end up picking the wrong template for their documents.

As for the precedence of using errata, I would be okay with that too - i.e., I 
think that just shows that we can be pragmatic and not get stuck in running 
extra process only for processes sake.

Regards,
Rob


> -Original Message-
> From: Jürgen Schönwälder 
> Sent: 04 April 2023 16:43
> To: Stephan Wenger 
> Cc: Joel Halpern ; Rob Wilton (rwilton)
> ; Kathleen Moriarty ;
> Deen, Glenn ; trust...@ietf.org;
> netmod@ietf.org; The IESG 
> Subject: Re: [netmod] [Trustees] draft-moriarty-yangsecuritytext vs errata
> 
> We can consider this an editing error since we forgot to put markers
> around the boilerplate. Nobody likely understood that these markers,
> which were originally introduced for code components and to support
> tools, have second legal meaning. This is for me the more subtle news
> that likely more people need to understand. A grep over the RFCs found
> BEGIN TEMPLATE TEXT only in RFC 7382. So BEGIN TEMPLATE TEXT is likely
> not widely known and hence we forgot to include it.
> 
> What kind of errata this is, I have no clue. I am also not concerned
> about setting a precedent. I think we should be pragmatic here.
> 
> /js
> 
> On Tue, Apr 04, 2023 at 03:18:11PM +, Stephan Wenger wrote:
> > Hi,
> > Whether to use an erratum as a mechanism to address our little problem is
> not the Trust’s business, and I think the Trust doesn’t and shouldn’t 
> care—after
> all, an accepted erratum is an integral part of the (modified) RFC.
> > However, as an IETF participant I have to ask: Is using errata to change the
> outlicensing regime of (part of) an RFC a precedent the responsible people
> should set?  We are not talking about correcting a typo here…
> > Of course, pragmatically speaking and for this particular case, using an
> erratum may well be the right way forward for all the reasons Rob points out.
> But, if the timing were the driving force for selecting errata over new RFCs, 
> I
> would rather suggest the IEEE folks have to wait a bit longer, while you guys 
> rev
> the RFC.
> > Thanks,
> > Stephan
> >
> > From: Trustees  on behalf of Joel Halpern
> 
> > Date: Tuesday, April 4, 2023 at 08:01
> > To: Rob Wilton (rwilton) , Kathleen
> Moriarty 
> > Cc: Deen, Glenn , trust...@ietf.org
> , netmod@ietf.org , The IESG
> 
> > Subject: Re: [Trustees] [netmod] draft-moriarty-yangsecuritytext vs errata
> > If I am reading you correctly Rob, you are expecting a revision of the
> > relevant RFC?   If that is so, we can probably live with an erratum.
> > The problem otherwise is that folks may not see the erratum, and thus
> > not know what the rules are.  I am willi

Re: [netmod] draft-moriarty-yangsecuritytext vs errata

[Rob Wilton (rwilton)]

Hi Kathleen,

Thanks.  It is unclear to me in your reply as to what the "this" refers to in 
"this was viewed as cleaner".  I.e., does it mean an errata, or AD sponsoring 
your draft?

For, me, if we can get away with doing an errata, i.e., it is sufficient to 
meet the trusts requirements, then I believe that is a better path for the 
following reasons:
(1) Quicker and less work, and I understand that you are under time pressure 
here.
(2) We don't end up with the security template in another RFC.
(3) I'm proposing that the OPS area discussions and refinements to the current 
template text to make it clear about what is expected to be documented.  E.g., 
my reading of the template is that implies that many/most YANG paths or 
subtrees should be documented (and this is seemingly the practice that many WGs 
have been following), but the text in RFC 8407 describing how the template 
should be used is somewhat is different since it refers to documents paths that 
are "especially disruptive if abused" or "especially sensitive information or 
that raise significant privacy concerns".  I.e., the aim is to document the 
exception paths, not giving an overview of all paths/subtrees in the module.  
Hence, I think that this would end up somewhat changing the template text, and 
having one less copy of it seems easier.

Thanks,
Rob


> -Original Message-
> From: Kathleen Moriarty 
> Sent: 03 April 2023 21:14
> To: Rob Wilton (rwilton) 
> Cc: Deen, Glenn ; trust...@ietf.org;
> netmod@ietf.org; The IESG 
> Subject: Re: draft-moriarty-yangsecuritytext vs errata
> 
> Hello Rob!
> 
> Thank you for your offer of AD sponsorship. We also reviewed the idea of using
> errata and I think this was viewed as cleaner in that it would be readily
> apparent that the template text could be used with the need for explanation. I
> think (and correct if I left anything out), either works to achieve the 
> objective
> for this since we’re working directly with the IEEE.
> 
> Best regards,
> Kathleen
> 
> Sent from my mobile device
> 
> > On Apr 3, 2023, at 1:30 PM, Rob Wilton (rwilton)  wrote:
> >
> > I'm getting an out-of-office bounce from Glenn, so adding trust...@ietf.org
> in the hope that either Kathleen or one of the other trustees is give an 
> answer
> more quickly.
> >
> > Thanks,
> > Rob
> >
> >
> >> -Original Message-
> >> From: Rob Wilton (rwilton)
> >> Sent: 03 April 2023 18:19
> >> To: kathleen.moriarty.i...@gmail.com; Deen, Glenn
> >> 
> >> Cc: netmod@ietf.org; The IESG 
> >> Subject: draft-moriarty-yangsecuritytext vs errata
> >>
> >> Hi Glenn, Kathleen,
> >>
> >> In addition to discussing draft-moriarty-yangsecuritytext in the NETMOD WG
> >> session on Friday (where the conclusion was to go the AD sponsored path), I
> >> also raised this issue with the IESG/IAB at the end of the IETF week, and
> >> someone had the suggestion of filling an errata against the YANG Author
> >> Guidelines (RFC 8407) to add the missing  and
>  >> TEMPLATE TEXT> markers to section 3.7.1 of RFC 8407.
> >>
> >> I know that you offered a RFC 8407-bis path, but did you also consider
> whether
> >> adding these markers as errata (which I would regard as being as in-scope
> and
> >> appropriate and could be marked as 'verified')?  If this approach worked
> from
> >> your side, and if there are no objections from the authors or NETMOD, then
> I
> >> was wondering if that could be a more expedient path forward.
> >>
> >> Please let me know if errata would be sufficient from a trust perspective,
> >> otherwise, I'll go the AD sponsored route on Kathleen's draft.
> >>
> >> Regards,
> >> Rob
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] draft-moriarty-yangsecuritytext vs errata

[Rob Wilton (rwilton)]

I'm getting an out-of-office bounce from Glenn, so adding trust...@ietf.org in 
the hope that either Kathleen or one of the other trustees is give an answer 
more quickly.

Thanks,
Rob


> -Original Message-
> From: Rob Wilton (rwilton)
> Sent: 03 April 2023 18:19
> To: kathleen.moriarty.i...@gmail.com; Deen, Glenn
> 
> Cc: netmod@ietf.org; The IESG 
> Subject: draft-moriarty-yangsecuritytext vs errata
> 
> Hi Glenn, Kathleen,
> 
> In addition to discussing draft-moriarty-yangsecuritytext in the NETMOD WG
> session on Friday (where the conclusion was to go the AD sponsored path), I
> also raised this issue with the IESG/IAB at the end of the IETF week, and
> someone had the suggestion of filling an errata against the YANG Author
> Guidelines (RFC 8407) to add the missing  and  TEMPLATE TEXT> markers to section 3.7.1 of RFC 8407.
> 
> I know that you offered a RFC 8407-bis path, but did you also consider whether
> adding these markers as errata (which I would regard as being as in-scope and
> appropriate and could be marked as 'verified')?  If this approach worked from
> your side, and if there are no objections from the authors or NETMOD, then I
> was wondering if that could be a more expedient path forward.
> 
> Please let me know if errata would be sufficient from a trust perspective,
> otherwise, I'll go the AD sponsored route on Kathleen's draft.
> 
> Regards,
> Rob

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

[netmod] draft-moriarty-yangsecuritytext vs errata

[Rob Wilton (rwilton)]

Hi Glenn, Kathleen,

In addition to discussing draft-moriarty-yangsecuritytext in the NETMOD WG 
session on Friday (where the conclusion was to go the AD sponsored path), I 
also raised this issue with the IESG/IAB at the end of the IETF week, and 
someone had the suggestion of filling an errata against the YANG Author 
Guidelines (RFC 8407) to add the missing  and  markers to section 3.7.1 of RFC 8407.

I know that you offered a RFC 8407-bis path, but did you also consider whether 
adding these markers as errata (which I would regard as being as in-scope and 
appropriate and could be marked as 'verified')?  If this approach worked from 
your side, and if there are no objections from the authors or NETMOD, then I 
was wondering if that could be a more expedient path forward.

Please let me know if errata would be sufficient from a trust perspective, 
otherwise, I'll go the AD sponsored route on Kathleen's draft.

Regards,
Rob

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

Re: [netmod] Comments on draft-ma-netmod-immutable-flag-06

[Rob Wilton (rwilton)]

Hi, 

I think that we need to be careful here.  In summary, I agree with a lot of the 
concerns flagged by Jan, both in ensuring that we don't break existing 
NETCONF*/YANG configuration paradigms (*, by NETCONF, I mean NETCONF or 
RESTCONF), but also the approach of considering the best long-term solution to 
each of the specific requirements.

Fundamentally, I generally interpret this draft as saying:  NETCONF/YANG 
doesn't really match the existing management model/API in 3GPP and hence we 
want to make non-backwards compatible changes to NETCONF/YANG to match the 3GPP 
semantics.

Currently in the network management space, this is a strong desire for 
configuration to be intent driven, where it should be possible, in a single 
external transaction to move from any one valid configuration to another valid 
configuration.  E.g., some clients always make any configuration change as a 
full commit replace and leave it to the device to calculate the actual 
configuration change delta that needs to be processed (including deleting and 
recreating objects if that is needed).  E.g., some of our customers really 
dislike it whenever we force them to split a config-updates into two separate 
transactions because it increases the complexity of the orchestration - we end 
up getting bug reports for these sorts of issues and aim to remove them.  So, I 
think that I am fairly strongly opposed to adding an annotation to YANG that 
would mandate this transaction breaking behaviour - it seems to be going in the 
wrong direction of travel for automation.

In terms of a liaison response, I would suggest that we acknowledge the request 
from 3GPP and indicate that we are investigating approaches to address the 
requirements raised, but we need to determine if there are ways that these 
requirements can be met without breaking the core tenets of the NETCONF/YANG 
configuration architecture.  E.g., some parts of the approach described here 
will mean that existing management clients, that are compatible with 
NETCONF/YANG, will not directly work with servers implementing this change.  
Similarly, some of the language is effectively forcing breaking changes onto 
NETCONF/YANG service implementations (e.g., text in the document like "When 
present, it indicates that data nodes based on the parent statement are not 
allowed to be added, removed or updated except according to the exceptions 
argument. Any such write attempt will be rejected by the server.").

Further, I wonder if there are enough issues here to warrant having a dedicated 
interim to discuss this.  I seem to recall the NETMOD chairs suggesting an 
interim on one topic in the recent NETMOD session, but don't recall whether it 
was for this one - sorry!

A few thoughts on the current draft:

- Handling of capabilities is an important topic, and has comes up recently in 
several places, this topic alone might be worth some time being spent on it.  
Having an annotation to indicate capabilities information may be useful, but 
possibly this should be an entirely separate annotation to indicate what it is, 
or perhaps putting capabilities are put under a /capabilities root container 
would be sufficient.

- In terms of properties that cannot be changed once written, I would rather 
see this issue framed more in the direction of it just being extra 
documentation written in a machine-readable way.  Specifically, using the 
annotation to give an indication that servers MAY reject requests to 
create/delete, or change, the configuration, but not requiring that they do so. 
 I.e., at the data model level, I don't think that we should preclude servers 
being able to handle this is in a more client friendly way (e.g., by breaking a 
single client transaction up into multiple internal transactional changes where 
needed).

- For any immutable related metadata annotations, I think that this additional 
metadata should only be returned to clients when explicit requested via a 
separate RPC parameter, and I think that the draft needs to add text for 
protocol capabilities used to indicate whether this new option is supported 
(e.g., along the lines of RFC 6243, with-defaults).

Regards,
Rob

// All comments without an AD hat on.


> -Original Message-
> From: netmod  On Behalf Of Jan Lindblad (jlindbla)
> Sent: 31 March 2023 08:11
> To: maqiufang (A) ; Balazs Lengyel
> 
> Cc: NETMOD Group 
> Subject: [netmod] Comments on draft-ma-netmod-immutable-flag-06
> 
> Quifang,
> 
> Thank you for the excellent presentations at the NETMOD session today. I
> understand how and why the immutability topic is important to 3GPP, and
> several other IETF liaised organizations, and I certainly think we should 
> respond
> to their liaison inquiry in a timely manner.
> 
> In my opinion, that response should be along the lines that we understand and
> support the use cases as put forward in the liaison statement. We should say
> that NETMOD is working on a solution which provides an 

Re: [netmod] system configuration/datastore and the keystore/truststore drafts

[Rob Wilton (rwilton)]

Hi Jürgen, Kent,

If we can take that interpretation (and I agree I think that was the spirit of 
how I thought that NMDA works, particularly for templating and inactive 
configuration).

However, my concern comes from the MUST in this paragraph of RFC 8342 (and RFC 
7950 also states that  must always be valid):

5.1.3.  The Running Configuration Datastore ()

   The running configuration datastore () is a configuration
   datastore that holds the current configuration of the device.  It MAY
   include configuration that requires further transformation before it
   can be applied, e.g., inactive configuration, or template-mechanism-
   oriented configuration that needs further expansion.  However,
MUST always be a valid configuration data tree, as defined
   in Section 8.1 of [RFC7950].

And the current version of the system datastore draft 
(https://datatracker.ietf.org/doc/draft-ietf-netmod-system-config/), 5.1.  
Conceptual Model of Datastores, has text like:

   All above three types of system configurations will appear in
   .  Clients MAY reference nodes defined in , override
   values of configurations defined in , and configure
   descendant nodes of system-defined nodes, by copying or writing
   intended configurations into the target configuration datastore
   (e.g., ).

   Servers MUST enforce that configuration references in  are
   resolved within the  datastore and ensure that 
   contains any referenced system configuration.  Clients MUST either
   explicitly copy system-defined nodes into  or use the
   "resolve-system" parameter.  The server MUST enforce that the
   referenced system nodes configured into  by the client is
   consistent with .  Note that  aware clients know how
   to discover what nodes exist in .  How clients unaware of the
datastore can find appropriate configurations is beyond the
   scope of this document.

But, if the WG agrees that for NMDA, the actual validation happens on 
 and not  then I understand that to mean that  on 
its own may not be valid, and it is only "implicitly valid" after doing the 
processing between  and  and  must always be valid.
 
Further, I think that this means that there isn't any requirement (from a 
validation correctness point of view) to require system configuration to be 
copied into .  Of course, there may be other reasons why a client may 
want system configuration to be copied into , e.g., so that it can be 
returned in a get request of .

If the WG agrees that this is the right direction then I think that it would be 
helpful for the system configuration datastore to perhaps update (or clarify) 
section 5.1.3 of RFC 8342, and perhaps provide an updated diagram with how the 
system datastore fits into the picture.  I think that there would be further 
updates required to the system configuration datastore draft to clarify the 
expected behaviour, and we should also think carefully about the text and 
perhaps examples in the truststore/keystore drafts (since they currently state 
that the keys/certificates must be copied into , and I think that we 
are saying with NMDA that this is not required).

Thanks,
Rob


> -Original Message-
> From: Jürgen Schönwälder 
> Sent: 26 March 2023 13:24
> To: Rob Wilton (rwilton) 
> Cc: netmod@ietf.org
> Subject: Re: [netmod] system configuration/datastore and the
> keystore/truststore drafts
> 
> Rob,
> 
> my reading of Figure 2 of RFC 8342 is that validation happens on
> intended and not on running. I assume the system config is folded in
> between running and intended. This seems to be inline with the
> approach taken by the system config draft. This, of course, leaves is
> open what actually happens if keys are removed and cause a subsequent
> validation error. Ideally, such a transaction key removal transaction
> should fail, but whether this will be enforced if the transaction
> takes place outside the configuration management system may be a bit
> wishful thinking.
> 
> /js
> 
> On Sun, Mar 26, 2023 at 04:28:46PM +, Rob Wilton (rwilton) wrote:
> > Hi,
> >
> > I'm in the process of AD reviewing Kent's keystore and truststore drafts in
> NETCONF.
> >
> > In both of these drafts, there is a desire to be able to use keys or
> certificates that are managed on the device, potentially as part of a TPM,
> and yet be able to reference those keys/certificates from the device
> configuration.  There is also some reference to how this configuration may
> work with the system datastore.
> >
> > https://www.ietf.org/archive/id/draft-ietf-netconf-keystore-27.html#name-
> support-for-built-in-keys gives an example.
> >
> > Looking at the current version of the system datastore,
> https://datatracker.ietf.org/doc/draft-ietf-netmod-system-config/01/, my
> understanding is that this draft reinforces the requirement that  is
&g

[netmod] system configuration/datastore and the keystore/truststore drafts

[Rob Wilton (rwilton)]

Hi,

I'm in the process of AD reviewing Kent's keystore and truststore drafts in 
NETCONF.

In both of these drafts, there is a desire to be able to use keys or 
certificates that are managed on the device, potentially as part of a TPM, and 
yet be able to reference those keys/certificates from the device configuration. 
 There is also some reference to how this configuration may work with the 
system datastore.

https://www.ietf.org/archive/id/draft-ietf-netconf-keystore-27.html#name-support-for-built-in-keys
 gives an example.

Looking at the current version of the system datastore, 
https://datatracker.ietf.org/doc/draft-ietf-netmod-system-config/01/, my 
understanding is that this draft reinforces the requirement that  is 
always valid. Hence any data nodes in the  datastore, that are 
referenced from the configuration in the  datastore, MUST also be 
copied into , so that it validates.  Unreferenced descendant 
configuration (that won't stop  from validating) can be left in 
system, which is then merged with , and validated as part of 
.

This is the approach that the keystore/truststore explains.  However, there is 
separately the issue that the build in keys and certificates may be updated via 
an out of band process, such that the current keys/certificates are stored on 
the device, and a stale copy of the keys/certificates ends up in the running 
configuration.  The keystore/truststore draft mitigates this by stating that if 
the key/certificate config differs between  and , then the 
values in  are ignored and the values in  take priority.  
However, my understanding is that this behaviour is the reverse of what we 
normally expect when merging configuration in the  and  
datastores, where configuration in  overrides configuration in 
.  Ultimately, I think that this means that we would need special 
handling for key/truststore configuration rather than just following the normal 
behaviour.

Hence, I wonder whether we are making this more complex than necessary.  Rather 
than requiring that  is always independently valid from , 
then would it not be simpler to allow  to have invalid configuration 
but always require that whenever  is changed then  is 
updated and must always be valid.  This would allow  to reference 
configuration in  without requiring it to be copied into .

I still think that we should allow the configuration to be copied into 
 for clients that also want  to be validate independently 
from , but otherwise, the requirement of copying keys are 
certificates into running doesn't seem ideal.

Any thoughts?

Regards,
Rob

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

[netmod] Changes to IPv6 zone definition in draft-ietf-netmod-rfc6991-bis-15

[Rob Wilton (rwilton)]

Hi Jürgen, Netmod, & rfc6874bis interested parties,

In my AD review of draft-ietf-netmod-rfc6991-bis-15, Jurgen has proposed a 
change to definition of the zone-id in the ip-address, ipv4-address, and 
ipv6-address types.  These changes move the definition somewhat closer to what 
is in rfc6874bis, but they are still different enough that we don't have wide 
compatibility.

I think that it may be useful to have a discussion to see if we can find a 
technical solution that works both for YANG models and that is compatible with 
being used in URIs.  Hence, I've separated my AD review comments for these two 
specific issues into this separate thread to try and ensure that interested 
parties can be involved in the discussion:

(2) In RFC 6991:
 typedef ipv6-address {
   type string {
 pattern '((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}'
   + '((([0-9a-fA-F]{0,4}:)?(:|[0-9a-fA-F]{0,4}))|'
   + '(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\.){3}'
   + '(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])))'
   + '(%[\p{N}\p{L}]+)?';

In draft-ietf-netmod-rfc6991-bis-15, p 27, sec 4.  Internet Protocol Suite Types
 typedef ipv6-address {
   type string {
 pattern '((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}'
   + '((([0-9a-fA-F]{0,4}:)?(:|[0-9a-fA-F]{0,4}))|'
   + '(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\.){3}'
   + '(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])))'
   + '(%[A-Za-z0-9][A-Za-z0-9\-\._~/]*)?';

I'm not saying that this change is wrong, but this technically looks to be a 
non-backwards-compatible change (depending on whether interface names could 
ever use non-ASCII characters).  Where is the set of allowed characters for 
zone-ids defined?  I couldn't find them in an RFC, RFC 4007 section 11.2 seems 
to indicate that there is no restriction.  draft-ietf-6man-rfc6874bis, which 
I'm currently holding a 'discuss' ballot position on, effectively limits the 
usable character set of zone-ids to the unreserved set in URIs, which seems to 
match those above except for '/' that is allowed above (and used in many 
interface names), but not in the URI's unreserved character set.  A further 
difference is that upper case characters are allowed in this typedef but are 
not allowed when used in the host part of URIs.

Update - I've now seen the thread 'ipv6-address in RFC 6991 (and bis)', and 
Jürgen has put together a useful blog post, thanks!

Given that "interface-name" in RFC 8343, and the text in RFC 4007 section 11.2, 
then arguably the safest thing here would be to allow the zone-id to be 
unrestricted, i.e., "(%.*)?"  However, this would leave 
draft-ietf-6man-rfc6874bis as only being able to support a small fraction of 
interface names as zone-ids in URLs.  The authors of draft-ietf-6man-rfc6874bis 
seem to indicate that it works for all interface names that currently matter 
for their use case.

An alternative solution could be to somewhere define the zone-ids in YANG to 
match the restrictive set in draft-ietf-6man-rfc6874bis (i.e., lower case only, 
and disallow '/').  I think that this would then require that we recommend a 
conversion of interface names into draft-ietf-6man-rfc6874bis compatible 
zone-ids interface-names.  E.g., such a conversion could take the interface 
name, and change any uppercase characters to lower case, and replace any symbol 
that isn't in the allowed character set with '_'.  This conversion is 
effectively one way, and there is a theoretical risk that the converted 
interface names could collide, but this may be unlikely in practice.  
Obviously, this conversation doesn't handle non-ASCII interface names, but I'm 
not sure how realistic it is that they would be used anyway.

This general comment also applies for the same change for 'ipv4-address'.


(3) draft-ietf-netmod-rfc6991-bis-15, p 28, sec 4.  Internet Protocol Suite 
Types

 The canonical format of IPv6 addresses uses the textual
 representation defined in Section 4 of RFC 5952.  The
 canonical format for the zone index is the numerical
 format as described in Section 11.2 of RFC 4007.";

Would it make sense to also change the canonical format for the zone index to 
be interface name (or converted interface name) rather than numeric id (when 
used in YANG models)?

This comment also applies for the same change for 'ipv4-address'.


Thoughts and comments on these two issues are welcome.

Regards,
Rob

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

[netmod] AD review of draft-ietf-netmod-rfc6991-bis-15

[Rob Wilton (rwilton)]

Hi Jürgen,

Thanks for the draft.  Please see my AD review comments below, except for a 
couple of comments related to the change to ipv6-address definition that I've 
spun into a separate thread so that I can include the interested parties of 
draft-ietf-6man-rfc6874bis into the discussion.


Moderate level comments:

(1) p 13, sec 3.  Core YANG Types

 typedef date-with-zone-offset {

Why don't we just call this 'date' rather than 'date-with-zone-offset', 
particularly because the zone information is optional?  Intuitively, from the 
name of this type, I would have expected that zone information as being 
required rather than being optional.

I also note that the current naming convention of this type seems somewhat 
inconsistent from "date-no-zone", since one of them includes "offset" and the 
other does not.

This same comment also applies to 'time-with-zone-offset'.


(2) p 27, sec 4.  Internet Protocol Suite Types

I've moved this comment to a separate thread.


(3) p 28, sec 4.  Internet Protocol Suite Types

I've moved this comment to a separate thread.


Minor level comments:

(4) p 13, sec 3.  Core YANG Types

   description
"The date type represents a time-interval of the length
 of a day, i.e., 24 hours.

I think that it might be helpful if the first part of the description stated 
that the type optionally includes the zone offset, particularly to 
differentiate from the type that excludes it.

This same comment also applies to 'time-with-zone-offset'.


(5) p 14, sec 3.  Core YANG Types

   type date-with-zone-offset {
 pattern '[0-9]{4}-(1[0-2]|0[1-9])-(0[1-9]|[1-2][0-9]|3[0-1])';
   }

Although I can understand why it is modelled this way, i.e., to make the 
relationship between the types clear, there is likely to be a small performance 
overhead of modelling it this way, where this regex for this type is a strict 
subset of date-with-zone-offset.  I wonder whether it would be cleaner to just 
define this type as an equivalent top-level type to date-with-zone-offset, both 
in the definition and description rather than as a derived type?

This same comment also applies to 'time-no-zone'.


(6) p 15, sec 3.  Core YANG Types

 The maximum time period that can be expressed is in the
 range [-89478485 days 08:00:00 to 89478485 days 07:00:00].

I found this notation slightly confusing.  When I originally saw it, I assumed 
that it is talking about time zones, and it only really made sense when 
comparing it to the other periods.

I wasn't sure whether the specific details are that important, and whether 
defining it as -89478485 days to 89478485 days, might be both sufficient and 
easier to read.

E.g.,
 The maximum time period that can be expressed is in the
 range [-89478485to 89478485] days .

If changed, this same comment applies to the other period types as well.


(7) p 15, sec 3.  Core YANG Types

 This type should be range restricted in situations
 where only non-negative time periods are desirable,
 (i.e., range '0..max').";

Isn't this going to be the common mainline case for network configuration?  
I.e., I presume that most cases where periods are intervals are going to be 
reported will be positive.  Hence, it might be helpful to have a separate set 
of types defined for the positive only cases.

This same comment applies to the other period types.


(8) p 16, sec 3.  Core YANG Types

 typedef milliseconds32 {

I was slightly surprised that we don't have a milliseconds64, e.g., the default 
timestamp in Java is given as an int64 in milliseconds.



Nit level comments:

(9) p 21, sec 3.  Core YANG Types

  7950. An earlier version of this definition did exclude

I suggest 'did exclude' -> 'excluded'

Regards,
Rob

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

Re: [netmod] Regarding IPR on draft-ietf-netmod-yang-module-versioning-08

[Rob Wilton (rwilton)]

Hi Jan,

There was a mistake in your email address by Lou, just flagging that you need 
to respond to the original request.

Regards,
Rob


> -Original Message-
> From: Lou Berger 
> Sent: 16 January 2023 22:53
> To: benoit.cla...@huawei.com; lana.w...@huawei.com; e...@juniper.net;
> lind...@cisco.com; j.shoenwael...@jacobs-university.de;
> mjethanand...@gmail.com; wangzi...@huawei.com; Per Andersson
> (perander) ; bill...@huawei.com; Rob Wilton (rwilton)
> ; res...@yahoo.com; balazs.leng...@ericsson.com; Joe
> Clarke (jclarke) ; jason.ste...@nokia.com
> Cc: NetMod WG Chairs ; NETMOD Group
> 
> Subject: Regarding IPR on draft-ietf-netmod-yang-module-versioning-08
> 
> 
> Authors, Contributors, WG,
> 
> In preparation for WG Last Call
> 
> Are you aware of any IPR that applies to drafts identified above?
> 
> Please state either:
> 
> "No, I'm not aware of any IPR that applies to this draft"
> or
> "Yes, I'm aware of IPR that applies to this draft"
> 
> If so, has this IPR been disclosed in compliance with IETF IPR rules
> (see RFCs 3669, 5378 and 8179 for more details)?
> 
> If yes to the above, please state either:
> 
> "Yes, the IPR has been disclosed in compliance with IETF IPR rules"
> or
> "No, the IPR has not been disclosed"
> 
> If you answer no, please provide any additional details you think
> appropriate. If you are listed as a document author or contributor
> please answer the
> above by responding to this email regardless of whether or not you are
> aware of any relevant IPR. This document will not advance to the next
> stage until a response has been received from each author.
> 
> NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES.
> 
> If you are on the WG email list or attend WG meetings but are not listed
> as an author or contributor, we remind you of your obligations under
> the IETF IPR rules which encourages you to notify the IETF if you are
> aware of IPR of others on an IETF contribution, or to refrain from
> participating in any contribution or discussion related to your
> undisclosed IPR. For more information, please see
> https://www.ietf.org/standards/ipr/
> 
> Thank you,
> Lou and Kent
> 
> PS Please include all listed in the headers of this message in your
> response.
> 

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

Re: [netmod] IPR Poll on draft-ietf-netmod-yang-semver-09

[Rob Wilton (rwilton)]

"No, I'm not aware of any IPR that applies to this draft"

Regards,
Rob


> -Original Message-
> From: Kent Watsen 
> Sent: 16 January 2023 23:00
> To: netmod@ietf.org
> Cc: Joe Clarke (jclarke) ; Rob Wilton (rwilton)
> ; Reshad Rahman ; Balázs Lengyel
> ; Jason Sterne (Nokia)
> ; Benoit Claise 
> Subject: IPR Poll on draft-ietf-netmod-yang-semver-09
> 
> [NOTE: A response is needed from all listed in this message's "To" line, the
> authors and contributors listed in the draft]
> 
> 
> Authors, Contributors, WG,
> 
> In preparation for a WGLC Call:
> 
>   Are you aware of any IPR that applies to drafts identified above?
> 
> Please state either:
> 
>   "No, I'm not aware of any IPR that applies to this draft"
> or
>   "Yes, I'm aware of IPR that applies to this draft"
> 
> If so, has this IPR been disclosed in compliance with IETF IPR rules
> (see RFCs 3669, 5378 and 8179 for more details)?
> 
> If yes to the above, please state either:
> 
>   "Yes, the IPR has been disclosed in compliance with IETF IPR rules"
> or
>   "No, the IPR has not been disclosed"
> 
> If you answer no, please provide any additional details you think
> appropriate. If you are listed as a document author or contributor
> please answer the above by responding to this email regardless
> of whether or not you are aware of any relevant IPR. This
> document will not advance to the next stage until a response
> has been received from each author.
> 
> If you are on the WG email list or attend WG meetings but are not
> listed as an author or contributor, we remind you of your obligations
> under the IETF IPR rules which encourages you to notify the IETF
> if you are aware of IPR of others on an IETF contribution, or to
> refrain from participating in any contribution or discussion related
> to your undisclosed IPR. For more information, please see the RFCs
> listed above and
> http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.
> 
> Thank you,
> Kent and Lou
> 
> PS Please include all listed in the headers of this message in your
> response.

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

Re: [netmod] Use of unrestricted string in YANG (was RE: naming scope of a grouping which uses a grouping)

[Rob Wilton (rwilton)]

> -Original Message-
> From: netmod  On Behalf Of Jürgen Schönwälder
> Sent: 12 January 2023 15:46
> To: Italo Busi 
> Cc: netmod@ietf.org
> Subject: Re: [netmod] Use of unrestricted string in YANG (was RE: naming scope
> of a grouping which uses a grouping)
> 
> My take is that arbitrary limites are worse than no limits.
> Robust implementations will reject values that go beyond certain
> implementation and platform specific limits.
> 
> If anything makes sense to standardize, then it is the minimum lengths
> that must be supported, for which we do not really have formal syntax.
[Rob Wilton (rwilton)] 

+1.

It is quite likely that implementations will choose some reasonable limit for 
most of these unlimited strings, so it isn't really that they are unlimited, 
but the limit is set by the implementation rather than at the generic API.  Of 
course, even with YANG, an implementation could deviate all of these unlimited 
length string leaves to indicate what the actual limit is. Whether this would 
be genuinely helpful or end up just being noise by hiding "real deviations" in 
a sea of noise is unclear to me.

And I agree with Juergen, that from an interop perspective, knowing the minimum 
length that all implementations are expected to support may do more to improve 
interoperability.  E.g., knowing that all server implementations are expected 
to support interface descriptions of 256 bytes may be more helpful than knowing 
that some implementations limit them to 1 Mb.

Rob

// No hats.


> 
> /js
> 
> On Thu, Jan 12, 2023 at 12:38:13PM +, Italo Busi wrote:
> > I have seen the comment from Tom about the unrestricted string in YANG on
> other drafts in WG LC or WG adoption poll and I would like to understand what
> is the position of the Netmod WG on this issue
> >
> >
> > Using unrestricted string is quite common practice in existing IETF standard
> YANG models, also as in key attributes (e.g., see RFC8343). However, the
> comments looks valid and it is worthwhile investigating it further
> > From the previous discussion I have understood that Martin does not think
> this is an issue while Andy agrees with Tom …
> >
> > I have a mixed feeling about the resolution but I think this is something 
> > to be
> documented either in RFC7950 (update) or in RFC8407 (update)
> >
> > For integers, RFC7950 defines different built-in types for 8-bit, 16-bit 
> > and 64-
> bit integers, while for string there is only one type and the length sub-
> statement is optional
> >
> > While it is true that unrestricted strings can cause an implementation to 
> > run
> out of memory, it is also true that in some cases it is not trivial to define 
> the
> maximum length for a string attribute
> >
> > Moreover, I am not sure whether restricting the strings would solve the out 
> > of
> memory: what happens if a huge YANG list is configured?
> >
> > What is your view/opinion about using the string type in IETF standard YANG
> models?
> >
> > Thanks, Italo
> >
> > From: Andy Bierman 
> > Sent: mercoledì 21 dicembre 2022 00:30
> > To: Martin Björklund 
> > Cc: ie...@btconnect.com; netmod@ietf.org
> > Subject: Re: [netmod] naming scope of a grouping which uses a grouping
> >
> >
> >
> > On Mon, Dec 19, 2022 at 5:15 AM Martin Björklund
> mailto:mbj%2bi...@4668.se>> wrote:
> > tom petch mailto:ie...@btconnect.com>> wrote:
> > > From: Martin Björklund mailto:mbj%2bi...@4668.se>>
> > > Sent: 19 December 2022 12:18
> > > To: tom petch
> > >
> > > tom petch mailto:ie...@btconnect.com>> wrote:
> > > > draft-ietf-opsawg-sap-12
> > > > defines a grouping sap-list which uses grouping sap-entry.  The 
> > > > groupings
> are intended for import by service specific modules.  The uses does not 
> include
> a prefix; should it?
> > >
> > > From a YANG perspective this is correct.  Since it references a
> > > grouping in the local module, the prefix is optional.
> > >
> > > 
> > > But it will not be the local module when it is used in other modules 
> > > which is
> the only reason it is a grou[ing
> >
> > It doesn't matter how sap-list is used; it is well-defined in the
> > module ietf-sap-ntw.  See section 5.4 in RFC 7950.
> >
> >
> > /martin
> >
> >
> > >
> > > module ietf-sap-vpn
> > >  prefix sap-vpn
> > > import ietf-sap-ntw
> > >  prefix sap
> > > container sap-l2vpn
> > >
> > > list l2vpn-service
> > >  uses sap:sap-list
> 

[netmod] Change in NETMOD Chairs

[Rob Wilton (rwilton)]

I've decided to reduce the number of NETMOD chairs from 3 chairs down to 2.  
Kent and Lou will continue as NETMOD chairs, Joel is stepping down.

For the current amount of work in NETMOD, having two chairs is the optimal 
number.  In addition, having a free third chair slot potentially allows 
community members to try WG chairing alongside experienced chairs.  As a 
reminder, ADs and chairs are always keen to encourage and help IETF 
participants who may be interested in taking on increased leadership 
responsibilities within the IETF.  If that is something that interests you then 
please reach out to me, Warren, or the WG chairs.

I would like to thank Joel for his time and contributions to managing the 
NETMOD WG.

Regards,
Rob

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

[netmod] YANG module versioning: Proposed change to "Import by derived revision"

[Rob Wilton (rwilton)]

Hi Juergen, WG,

draft-ietf-netmod-yang-module-versioning defines section "4.  Import by derived 
revision" that allows an author to specify a minimum revision of a module that 
is allowed to satisfy a YANG import.

IIRC, and hopefully you will correct me if I am wrong, you had two concerns 
about this approach:
(1) It potentially changes the behaviour of a YANG compiler without a 
corresponding version change in the YANG language.
(2) It is embedding version constraint information directly into the YANG 
module.

The main reason for wanting this import was to help specify a minimum import 
dependency, e.g., perhaps a module depends on a new type that is only defined 
in version 1.1 and not available in any of the previous versions.  Here, having 
some level of minimum dependency in the importing YANG module seems broadly 
helpful (like a more helpful version of the existing import by exact 
revision-date), given that in many cases modules may be independently versioned.

Anyway, I would like to propose a change (a softening) of the definition of the 
"revision-or-derived" extension statement in the Module Versioning Draft so 
rather than referring to a hard "minimum required revision" for the import to 
be valid, instead it is changed to refer to a softer "suggested minimum 
revision".  I.e., the intention is that the "revision-or-derived" statement is 
no longer a hard constraint on the import statement at all, it is just a 
suggestion for use by tooling and module readers, and which they are at liberty 
to entirely ignore.

Tools that support the "revision-or-derived" would generally be expected to 
pick a revision that is derived from the revision/version specified in the 
"revision-or-derived" statement but are not required to do so.  E.g., if they 
don't have a suitable version available, then they can import another module 
version.  Further, if such a tool does choose a version that isn't derived from 
the "revision-or-derived" statement then generating a YANG compiler warning 
message would be reasonable, but not required.

The potential benefits of the new approach are:
- arguably, this approach is more compatible with existing YANG 1.1 import 
rules.
- sets of YANG modules that were compiled by tools that don't understand the 
"revision-or-derived" statement would still compile with tools that do 
understand it, possibly with the addition of some warning messages..
- with a branched revision history, there are cases where the tighter import 
constraint isn't so helpful.

If/when YANG 2.0 comes along, we could either keep with the relaxed definition 
proposed above, or possibly tighten the definition to what we have today.

I would be interested in Juergen's and the WG's opinion on this proposed change 
in behaviour.

Regards,
Rob

// As a contributor to the versioning work.

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

Re: [netmod] [Technical Errata Reported] RFC6991 (7062)

[Rob Wilton (rwilton)]

Thanks Jurgen.

I agree, I have rejected this errata.

Regards,
Rob

> -Original Message-
> From: Jürgen Schönwälder 
> Sent: 29 July 2022 17:21
> To: RFC Errata System 
> Cc: war...@kumari.net; Rob Wilton (rwilton) ;
> kent+i...@watsen.net; joe...@bogus.com; lber...@labn.net;
> mazhar.r...@sophos.com; netmod@ietf.org
> Subject: Re: [Technical Errata Reported] RFC6991 (7062)
> 
> Since the ipv4-address-no-zone type is derived from the ipv4-address
> type and the ipv4-address type has the detailed pattern, there is no
> need to repeat the details. An ipv4-address value has to satisfy both
> the ipv4-address-no-zone pattern and the ipv4-address pattern.
> 
> I believe this errata should be rejected.
> 
> /js
> 
> On Fri, Jul 29, 2022 at 10:32:27AM -0700, RFC Errata System wrote:
> > The following errata report has been submitted for RFC6991,
> > "Common YANG Data Types".
> >
> > --
> > You may review the report below and at:
> > https://www.rfc-editor.org/errata/eid7062
> >
> > --
> > Type: Technical
> > Reported by: Mazhar Rana 
> >
> > Section: 4
> >
> > Original Text
> > -
> >  typedef ipv4-address-no-zone {
> >type inet:ipv4-address {
> >  pattern '[0-9\.]*';
> >}
> >description
> >  "An IPv4 address without a zone index.  This type, derived from
> >   ipv4-address, may be used in situations where the zone is
> >   known from the context and hence no zone index is needed.";
> >  }
> >
> > Corrected Text
> > --
> >  typedef ipv4-address-no-zone {
> >type inet:ipv4-address {
> >  pattern '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}'
> >  +  '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])';
> >}
> >description
> >  "An IPv4 address without a zone index.  This type, derived from
> >   ipv4-address, may be used in situations where the zone is
> >   known from the context and hence no zone index is needed.";
> >  }
> >
> > Notes
> > -
> > As per RFC 4001, dotted decimal format of IPv4 address is typically written 
> > in
> decimal digits, formatted as four 8-bit fields that are separated by periods.
> >
> > Instructions:
> > -
> > This erratum is currently posted as "Reported". If necessary, please
> > use "Reply All" to discuss whether it should be verified or
> > rejected. When a decision is reached, the verifying party
> > can log in to change the status and edit the report, if necessary.
> >
> > --
> > RFC6991 (draft-ietf-netmod-rfc6021-bis-03)
> > --
> > Title   : Common YANG Data Types
> > Publication Date: July 2013
> > Author(s)   : J. Schoenwaelder, Ed.
> > Category: PROPOSED STANDARD
> > Source  : Network Modeling
> > Area: Operations and Management
> > Stream  : IETF
> > Verifying Party : IESG
> 
> --
> Jürgen Schönwälder  Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 <https://www.jacobs-university.de/>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] RFC 6991 definition of ipv4-address

[Rob Wilton (rwilton)]

Hi,

Putting aside the discussion about whether we should be changing the use of 
ip-address vs ip-address-no-zone in existing YANG modules for the moment, I 
believe that the current ipv4-address|ipv6-address|ip-address definitions is 
either wrong, or unhelpful for two reasons:

(1) It specifies that If a zone index is not present, then the default zone of 
the device will be used.

Specifically, I interpret this as, if a YANG module uses the type 
ip|ipv4|ipv6|-address when the associated interface is provided via context 
(e.g., either a leaf in a parent key, or a sibling interface-ref leaf) then if 
the device returns a link-local IP address without a zone then it must be 
associated with the default zone of the device and not the associated 
interface.  I.e., the only way that devices return the correct value in this 
case would be to always return the zone information (in ifindex format) for all 
link-local addresses.

(2) The ipv4|v6-address-types specify that the canonical format for zones is 
the numerical format.  I.e., using the ifindex for an interface which isn't 
really meaningful or helpful for clients interacting with a device via YANG, 
and which may have no idea what the associated SNMP IfIndex is.  It seems to me 
that the canonical format for zones should be the interface name, not the 
IfIndex.

I would be interested to understand whether there is any WG consensus that 
these are valid problems with how ip-address (and friends) is defined both for 
implementations that include zone information and also those that don't.

Regards,
Rob

// As a contributor

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

Re: [netmod] yang versioning solution complexity and alternative approaches

[Rob Wilton (rwilton)]

Hi Juergen,

Thanks, please see inline ... 

At the moment I would like to try and make sure that I accurately understand 
the difference in opinion.

> -Original Message-
> From: Jürgen Schönwälder 
> Sent: 08 June 2022 16:38
> To: Rob Wilton (rwilton) 
> Cc: netmod@ietf.org
> Subject: Re: [netmod] yang versioning solution complexity and alternative
> approaches
> 
> Rob,
> 
> discussing details is likely distracting from the main difference in
> our viewpoints so I will only give a top posting response.

Okay.

I believe that the consensus of the authors on the weekly calls is also that 
annotations at the "data definition" level are helpful, alongside module and 
package (i.e., schema level) version numbers.

Hence, my understanding of the main difference is whether 
non-backwards-compatible changes MUST always be explicitly documented at the 
data node level (and hence whether that means that data nodes can never be 
deleted from a YANG module), or whether these annotations are unnecessary, and 
potentially unhelpfully clutter the YANG module in the cases where tooling can 
robustly infer whether the change is backwards compatible or not.

Possibly there is also a second difference of opinion as to whether it is 
appropriate/safe to assume that any changes that are not explicitly marked as 
being non-backwards-compatible are in fact backwards compatible.  I.e., 
specifically, is a "backwards-compatible" annotation also required in the cases 
where a tool cannot safely infer that a change is backwards-compatible.

Do you think that accurately represents the difference in opinion from your 
perspective?


> 
> NBC changes happen to "data definitions" and I believe this is where
> they deserve to be documented. Once you have NBC changes properly
> marked and documented at this granularity, you can generate any
> desirable information easily (perhaps even module version numbers).
> But most importantly, you can algorithmically decide whether a module
> B importing from module A is affected by any NBC changes in A. Module
> version numbers are too course grained to do that, hence they force
> consumers of YANG modules (the readers) to reverse engineer the NBC
> changes to decide if and how they might be affected.
> 
> A NETMOD design principle has been that readers come first, writers
> second, and tool makers last. The versioning solution presented by the
> design team seems to put writers first, leaving readers with the
> exercise to reverse engineer where NBC changes took place. I consider
> this backwards.

It is not the aim of the authors to put writers first at all.  We are also 
trying to make it easy for readers of YANG models, but perhaps have a slight 
difference of opinion of what is easier for readers.

Rob

// All with no hats, and without speaking to the other authors or those who 
attend the weekly versioning meetings.


> 
> /js
> 
> PS: I believe it is generally not decidable whether two YANG module
> revisions are BC or NBC. This does not mean that smart diffing
> tools are not useful but we should not leave the impression that
> they are a solution for readers; they are a useful tool for writers.
> 
> On Tue, Jun 07, 2022 at 12:54:14PM +, Rob Wilton (rwilton) wrote:
> > Hi Jürgen,
> >
> > Thank you for your feedback and apologies for the very delayed reply.  The
> versions authors have been discussing some of the points that you raised in a
> lot of detail and hence I was waiting for this discussion to converge before
> replying to you.
> >
> >
> > > -Original Message-
> > > From: netmod  On Behalf Of Jürgen
> > > Schönwälder
> > > Sent: 09 March 2022 10:16
> > > To: netmod@ietf.org
> > > Subject: [netmod] yang versioning solution complexity and alternative
> > > approaches
> > >
> > > Hi,
> > >
> > > the YANG versioning solution appears to be complex.
> >
> > I think some aspects of the solution are complex, but I'm not sure whether
> they are really avoidable, or whether the complexity comes from wanting to
> solve a complex problem.
> >
> > One aspect of additional complexity is because of a WG desire stated during
> adoption and previous discussions to support different version schemes (E.g.,
> YANG Semver, Open Config's use of vanilla Semver, vendor versioning
> schemes).
> >
> > I think that keeping this flexible is a reasonable choice. I also think 
> > that having
> some version indicator at the module level (or in the case of YANG packages,
> YANG schema level) is beneficial.  For example, if my client is designed to 
> work
> with module x@2.0.0, then if the server has actually implemented x@2.5.2
&

Re: [netmod] yang versioning solution complexity and alternative approaches

[Rob Wilton (rwilton)]

Hi Jürgen,

Thank you for your feedback and apologies for the very delayed reply.  The 
versions authors have been discussing some of the points that you raised in a 
lot of detail and hence I was waiting for this discussion to converge before 
replying to you.


> -Original Message-
> From: netmod  On Behalf Of Jürgen
> Schönwälder
> Sent: 09 March 2022 10:16
> To: netmod@ietf.org
> Subject: [netmod] yang versioning solution complexity and alternative
> approaches
> 
> Hi,
> 
> the YANG versioning solution appears to be complex.

I think some aspects of the solution are complex, but I'm not sure whether they 
are really avoidable, or whether the complexity comes from wanting to solve a 
complex problem.

One aspect of additional complexity is because of a WG desire stated during 
adoption and previous discussions to support different version schemes (E.g., 
YANG Semver, Open Config's use of vanilla Semver, vendor versioning schemes).

I think that keeping this flexible is a reasonable choice. I also think that 
having some version indicator at the module level (or in the case of YANG 
packages, YANG schema level) is beneficial.  For example, if my client is 
designed to work with module x@2.0.0, then if the server has actually 
implemented x@2.5.2 then it is compatible, assuming that module x has been 
updated according to the rules.   x@3.0.0 might also be compatible depending on 
what has changed - but as a client I had better check to see what the changes 
are to determine what the incompatibility is (using tooling).  I.e., I still 
think that version numbers provide more useful guidance (and partial 
relationship) than say revision dates, particularly given that YANG modules are 
not always strictly evolved in chronological order.

It was also clear to me when considering versioning schemes there is no perfect 
one-size fits all solution.  The YANG Semver approach is meant to be a 
pragmatic compromise.  I.e., encourage linear development, encourage 
backwards-compatible changes, but allow for non-backwards-compatible changes to 
occur and allow bugfixes to older revisions if required.

Finally, the wider versioning solution is also aiming to solve multiple 
different problems (e.g., package/schema level versioning, differentiation 
between backwards-compatible and non-backwards-compatible changes, supporting 
some level of branching for bugfixes, improving import dependencies, etc) which 
I think naturally somewhat increases its complexity.  We have somewhat tried to 
put these into separate documents so that each document can focus on specific 
aspects.


> 
> - We introduce version numbers that smell a bit like SemVers but then
>   are not really SemVer.

Yes, and no.  I'm not sure that there is really a canonical industry agreed 
definition of what Semver is, and hence we wanted quite a tight specification 
of what it means in the context of YANG, whilst still aiming to be mostly 
compatible with the Semver 2.0.0 definition.

We created YANG Semver for the sole reason that regular Semver or 
revision-dates are not sufficient to support one of the key requirements.  
Specifically, the need to allow bug fixes to older shipped modules without the 
luxury of forcing both client and server to always migrate to the latest 
version of the module (e.g., as an Open Source software project might be able 
to do).

It is also worth noting that module authors have the choice of never branching 
older versions, and only ever making updates to the latest version, in which 
case YANG Semver is identical to Semver 2.0.0.


> 
> - We have no solution to do meaningful things with these version
>   numbers, it does not even seem to be possible to decide whether
>   X.Y.Z derives from x.y.z or not.

The derivation is based solely on the revision history in the YANG module file. 
 If the previous revision exists in the module's revision history, then the 
revision is derived from it.

The intention is that the version numbers represent a partial ordering.  E.g., 
moving from version X.a.b to X.c.d, where c > a, or c == a and d > b is a 
backwards compatible change.  This relationship breaks down when the 
_compatible and _non_compatible modifiers are used, but I regard these as a 
practical compromise to allow a limited form of branching.

Even with regular Semver it is not possible to know if version X.Y.Z derives 
from x.y.z.  Even with semver 2.0.0, it seems (the spec is somewhat ambiguous) 
that you are allowed to chronologically create 1.2.1 then 2.0.0, then 1.3.1.  
And in this case 2.0.0 will not necessarily contain the content that was added 
in 1.3.1.


 We still seem to believe that
>   having compatibility constraints embedded in module imports are a
>   workable solution even though we acknowledge future breaking
>   changes.

This is a point of confusion, which probably means that we need to improve the 
text, since this isn't our goal for the "import by revision-or-derived".   
Note, we did 

Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

[Rob Wilton (rwilton)]

Hi Randy,



Thanks for summarizing, but I don't really agree with your categorization for 
(1) or (3).



My interpretation of ip-address and the related v4/v6 types, based on RFC 7950, 
is that implementations MUST allow clients to configure zoned IP addresses to 
be fully complaint with the module definition.  If a server implementation does 
not support zoned ip-addresses then it is expected to use a deviation (e.g., to 
replace the type with ip-address-no-zone) to indicate how it does not conform 
to the model.  I don't see that is being any different than an integer datatype 
with a range "1..255" and the server only supporting the client configuring 
values in the range "1..100".



The "may include a zone index" in the ip-address definitions relates to the 
client when writing a value (or server when returning a value), i.e., they 
don't have to always provide zones for all IP addresses.  They can leave them 
out, and when the zone is left out the "default zone of the device will be 
used".



E.g., considering the RFC 6991 and the IP RIB YANG model,


 typedef ipv6-address {
   type string {
 pattern '...'
   }
   description
"The ipv6-address type represents an IPv6 address in full,
 mixed, shortened, and shortened-mixed notation.  The IPv6
 address may include a zone index, separated by a % sign.

 The zone index is used to disambiguate identical address
 values.  For link-local addresses, the zone index will
 typically be the interface index number or the name of an
 interface.  If the zone index is not present, the default
 zone of the device will be used.



 The canonical format of IPv6 addresses uses the textual

 representation defined in Section 4 of RFC 
5952.  The

 canonical format for the zone index is the numerical

 format as described in Section 11.2 of RFC 
4007.";




 |  |+--rw v6ur:ipv6
 |  |   +--rw v6ur:route* [destination-prefix]
 |  |  +--rw v6ur:destination-prefix
 |  |  |   inet:ipv6-prefix
 |  |  +--rw v6ur:description?  string
 |  |  +--rw v6ur:next-hop
 |  | +--rw (v6ur:next-hop-options)
 |  |+--:(v6ur:simple-next-hop)
 |  ||  +--rw v6ur:outgoing-interface?
 |  ||  |   if:interface-ref
 |  ||  +--rw v6ur:next-hop-address?
 |  ||  inet:ipv6-address



So, considering the model above, if a link local IP address was provided as the 
next-hop-address without a zone, then according to the type definition, that 
link-local IP address is associated with the default zone of the device, not 
the "outgoing interface" for the next hop!  If a zone is returned with a 
link-local address (e.g., for a get request) then my expectation is that 
servers return the data using the "interface index number" (since that is the 
canonical form, this should be returned even if it was configured using an 
interface name to identify the zone).  Further, as far as I can tell, 
"interface index number" isn't really well specified in a YANG management API 
and is probably far less meaningful that the interface name in a YANG context.  
I presume that this is if-index in RFC 8343 but that doesn't need to be 
supported if the server doesn't also support SNMP's if-mib.



I suspect that the reason why ip-address (and the v4/v6) variants haven't 
caused any problems in practice is because implementations are mostly wrongly 
treating them as ip-address-no-zone, and assuming that the scope information is 
being provided by other context (e.g., outgoing-interface in the example 
above), or perhaps most operators just configure their devices using global IP 
addresses.



Some further comments inline ...



> -Original Message-

> From: netmod  On Behalf Of Randy Presuhn

> Sent: 15 April 2022 20:25

> To: l...@ietf.org; netmod@ietf.org

> Subject: Re: [netmod] [Lsr] I-D Action: 
> draft-ietf-lsr-ospfv3-extended-lsa-yang-

> 10.txt

>

> Hi -

>

> I took a fresh look at RFC 6991, and a couple of things that have

> already been mentioned in this thread bear repetition.

>

> (1) in both the ipv4-address and ipv6-address typdefs, the zone

> is only optionally present.  This is made clear both in the

> string patterns as well as the descriptions, which state that

> it "may" be present, and clearly specify how its absence is

> to be understood.  Thus it's no surprise that their use has not

> caused any problems.  If the definitions go unchanged, there's

> no demonstrated need for any of the existing uses of these typedefs

> to be revised to employ something else, even if other typedefs

> are available that are more precisely 

Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

[Rob Wilton (rwilton)]

Hi Martin,

I have several concerns with this approach:

(1) I still think that the ip-address type name still ends up being 
non-intuitive (especially for zoned IPv4 addresses - I would be surprised to 
find that there is any deployment for these at all).  I.e., the evidence seems 
to suggest that when engineers think of IP addresses, they don't seem to 
generally think of zoned IP addresses.  I doubt that any fiddling of the type 
description is going to change that perception, not least when the definition 
is different for OpenConfig and in vendors models and ip-address is widely used 
in many published YANG models.

(2) It means that clients of YANG models using the ip-address type have no idea 
whether the server will support zones without either trying the configuration 
(which could subsequently become unsupported in the future) or requiring an 
out-of-band discussion with the device vendor.  For such as basic type this 
doesn't seem great.

(3) For IETF models, does that mean that new models should use 
ip-address-no-zone, and that we should change the approx. 200 usages in 40-50 
published RFCs?  As mentioned previously, this doesn't seem pragmatic, or it 
will take the best part of a decade to happen.  During that time the difference 
between ip-address , ip-address-with-zone, and ip-address-no-zone will probably 
cause even further confusion due to the ambiguity, and differences in 
implementations.

(4) For NMDA models, it means that clients could (but probably never will) 
receive zoned ip addresses back from .  Further, if zoned IP 
addresses are returned, then they are expected to use numerical IDs for the 
zones, which seem to be effectively opaque to the client (other than 
uniqueness).  Clients seem to have a few choices: ignore (error?) on zoned IP 
addresses, ignore the zone (does that make sense), or have additional code to 
handle a case that for 99% of users will probably never happen.  My point being 
that these is also a cost to keeping support for zones in the base ip-address 
types.

Regards,
Rob



> -Original Message-
> From: Martin Björklund 
> Sent: 12 April 2022 08:26
> To: Rob Wilton (rwilton) 
> Cc: netmod@ietf.org; l...@ietf.org
> Subject: Re: [netmod] [Lsr] I-D Action: 
> draft-ietf-lsr-ospfv3-extended-lsa-yang-
> 10.txt
> 
> Hi,
> 
> Here's another suggestion.  We keep the ip-address pattern as is, but
> document in the description that implementations do not have to
> support the optional zone index.  This would essentially document the
> behavior of most current implementations.  (This is actually what I
> suggested in the earliest thread on this topic that I could find:
> https://mailarchive.ietf.org/arch/msg/netmod/KjHGtPqm9D4Q-
> fRb2hVsf4sPuCU)
> 
> 
> 
> /martin
> 
> 
> "Rob Wilton \(rwilton\)"  wrote:
> > Hi all,
> >
> > Thanks for the comments on this thread so far.  It would be nice if we are
> able to come to some sort of rough consensus to a solution.
> >
> > I think that there is consensus that the YANG type ip-address (and the v4/v6
> versions) are badly named as the prominent default type name has been
> given to the unusual variant of including zone information.
> >
> > Based on the comments on this thread, it also seems likely to me that most
> of the usages of ip-address in YANG RFCs is likely to be wrong, and the
> intention was that IP addresses without zones was intended.  At a rough
> count, of the published RFC YANG models at github
> YangModels/standard/ietf/RFC/ to be:
> > 86 uses of ip-address
> > 68 uses of ipv4-address
> > 66 uses of ipv6-address
> >
> > 1 use of ip-address-no-zone
> > 4 uses of ipv4-address-no-zone
> > 4 uses of ipv6-address-no-zone
> >
> > These types appear in 49 out of the 141 YANG modules published in RFCs.
> At a quick guess/check it looks like these 49 YANG modules may appear in 40-
> 50 RFCs.
> >
> > As mentioned previously, it is also worth comparing this to the OpenConfig
> YANG modules:
> > They have redefined ip-address (and v4/v6 variants) to exclude zone
> information and have defined separate types include zone information.
> > There are no explicit uses of the "-zoned" variants of OpenConfig IP
> addresses in the latest OpenConfig github repository.  However,
> approximately a third of the IP address types are still to the ietf-inet-
> types.yang rather than openconfig-inet-types.yang, so in theory some of those
> 58 entries could still intentionally be supporting zoned IP addresses, but I
> would expect that the vast majority would not.
> > I do see some strong benefit if this basic type being defined in the same 
> > way
> in both IETF and OC YANG, and I believe that the OC folks have got the
> d

[netmod] IP address zones in YANG

[Rob Wilton (rwilton)]

Spinning off part of the discussion into a separate thread, but keeping lsr 
cc'ed on the discussion.



I'm trying to get a better understand of how and where zoned IP addresses 
should be used in YANG data models.



RFC 4007 defines zones for IPv6 addresses, but not for IPv4.  Even though RFC 
6991 bis has support for a zoned IPv4 address, I'm struggling to see where 
zoned IPv4 addresses would ever really be used.  Does anyone know of any usage 
or deployments anywhere?



For IPv6, my understanding is that the use of the zone is to add the extra 
interface context for IPv6 link-local addresses.  Is there any use of zones 
outside of this interface context?



The current definition of ipv6-address type and the ip-address nodes in 
ietf-ip.yang seem to make zoned IP addresses hard to use.  The canonical zone 
definition in RFC 6991 is for an (presumably unique) numeric zone identifier, 
but in the YANG management layer it is unclear to me how one maps from this 
numeric id back to the interface name (e.g., for a client to construct a 
suitable zoned IP address in configuration).   ietf-ip.yang uses 
ipv6-address-no-zone for interface IP addresses so it isn't possible to get the 
zone id associated with the link local address.  This feels underspecified to 
me to tie these together and make this work robustly.



I also have a general question about what is the best way of modelling this in 
YANG.  Using a zoned ip address is one choice to link an IP address and 
interface together.  Another choice is to have a separate leaf to scope an IP 
address to a specific interface, wherever that is appropriate and required.



E.g., considering the IP RIB YANG model,



 |  |+--rw v6ur:ipv6

 |  |   +--rw v6ur:route* [destination-prefix]

 |  |  +--rw v6ur:destination-prefix

 |  |  |   inet:ipv6-prefix

 |  |  +--rw v6ur:description?  string

 |  |  +--rw v6ur:next-hop

 |  | +--rw (v6ur:next-hop-options)

 |  |+--:(v6ur:simple-next-hop)

 |  ||  +--rw v6ur:outgoing-interface?

 |  ||  |   if:interface-ref

 |  ||  +--rw v6ur:next-hop-address?

 |  ||  inet:ipv6-address





Given that an outgoing-interface is already provided then it seems that using a 
zoned IP address as a next hop address here would potentially be confusing, or 
at least not required because it is effectively already scoped to the 
outgoing-interface anyway?  It seems like it provides redundant information.



Considering another arbitrary protocol YANG module RFC, this time TWAMP, rfc 
8913, it seems that some of the ip-address fields in the model could in theory 
support link local addresses (e.g., the test-session ones), but it is unclear 
to me whether that was ever the intent, or whether that even makes sense.  For 
the other uses of IP addresses that identify a client or server, it feels like 
using link local addresses is much less compelling.  Modelling these all with 
the same type seems confusing.



 | +--rw test-session-request* [name]

 |+--rw name  string

 |+--rw sender-ip?inet:ip-address

 |+--rw sender-udp-port?  union

 |+--rw reflector-ip  inet:ip-address

 |+--rw reflector-udp-port?   inet:port-number

 |+--rw timeout?  uint64

 |+--rw padding-length?   uint32

 |+--rw test-packet-dscp? inet:dscp

 |+--rw start-time?   uint64

 |+--rw repeat?   uint32

 |+--rw repeat-interval?  uint32

 |+--rw pm-reg-list* [pm-index]

 ||  +--rw pm-indexuint16

 |+--ro state?test-session-state

 |+--ro sid?  string





E.g., I guess that you could use a zoned IP address for the reflector-ip, but I 
suspect that most implementations would not anticipate/support this.  It feels 
to me that a cleaner way of modelling this would be to not use a zoned IP 
address type at all and have a separate egress-interface if:-interface-ref 
(perhaps under an if-feature, to enable and indicate support for test sessions 
over link-local addresses).



My overriding concern here, if we don't change/fix the ip-address type, is that 
we will end up with a set of YANG models that:

  1.  Models this behaviour in different ways for different protocols/features.
  2.  Are entirely ambiguous to clients and implementations as to whether it 
makes sense to support zoned IP addresses and/or whether zoned link-local 
addresses are supported for each leaf.
  3.  We are creating models for a hypothetical use case rather than how these 
protocols are actually being deployed/implemented today.  I.e., I am more 

Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

[Rob Wilton (rwilton)]

Hi Tom,

Please see inline ...

> -Original Message-
> From: tom petch 
> Sent: 13 April 2022 10:22
> To: Rob Wilton (rwilton) ; netmod@ietf.org;
> l...@ietf.org
> Subject: Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-
> yang-10.txt
> 
> From: netmod  on behalf of Rob Wilton
> (rwilton) 
> Sent: 11 April 2022 18:06
> 
> Hi all,
> 
> Thanks for the comments on this thread so far.  It would be nice if we are
> able to come to some sort of rough consensus to a solution.
> 
> I think that there is consensus that the YANG type ip-address (and the v4/v6
> versions) are badly named as the prominent default type name has been
> given to the unusual variant of including zone information.
> 
> Based on the comments on this thread, it also seems likely to me that most
> of the usages of ip-address in YANG RFCs is likely to be wrong, and the
> intention was that IP addresses without zones was intended.  At a rough
> count, of the published RFC YANG models at github
> YangModels/standard/ietf/RFC/ to be:
> 86 uses of ip-address
> 68 uses of ipv4-address
> 66 uses of ipv6-address
> 
> 1 use of ip-address-no-zone
> 4 uses of ipv4-address-no-zone
> 4 uses of ipv6-address-no-zone
> 
> These types appear in 49 out of the 141 YANG modules published in RFCs.  At
> a quick guess/check it looks like these 49 YANG modules may appear in 40-50
> RFCs.
> 
> 
> 
> 
> As is sometimes the case with the processes of the IETF, this ignores any
> issues of transition.  I have pointed out a significant number of WG that have
> modules in I-D which include no-zone, in various states, perhaps increasing
> your figures by an order of magnitude.  What are you going to do with I-D
> e.g. in the RFC Editor queue?  Haul them back?

I think that depends on what consensus is reached.

I have no desire of trying to republish existing RFCs to either change 
"ip-address" to "ip-address-no-zone" or to change "ip-address-no-zone" to 
"ip-address".  I think the pragmatic thing to do would be to potentially flag 
these as errata so that they are hopefully fixed if/when the YANG module is 
eventually updated.

Entirely separately from this specific discussion, it would be good if we (the 
IETF) could come up with a better long-term plan for maintaining and evolving 
IETF YANG modules.


> 
> I think that the plan below is a bad one.  I would introduce types with zone -
> that is a no-brainer - but would deprecate the existing types.

Why is deprecating an existing type a problem?  It is deprecated, not obsolete.

It does not mean that modules can't use "ip-address-no-zone", it would just 
indicate that "ip-address" is the recommended type, if we get to a consensus 
where ip-address should migrate to meaning exactly the same as 
ip-address-no-zone.

There are APIs in Java that have been deprecated for 10+ years that are still 
available for use, but where the recommended is to not use them, or use a 
replacement API instead.

Regards,
Rob


> 
> Tom Petch
> 
> As mentioned previously, it is also worth comparing this to the OpenConfig
> YANG modules:
> They have redefined ip-address (and v4/v6 variants) to exclude zone
> information and have defined separate types include zone information.
> There are no explicit uses of the "-zoned" variants of OpenConfig IP
> addresses in the latest OpenConfig github repository.  However,
> approximately a third of the IP address types are still to the ietf-inet-
> types.yang rather than openconfig-inet-types.yang, so in theory some of
> those 58 entries could still intentionally be supporting zoned IP addresses,
> but I would expect that the vast majority would not.
> I do see some strong benefit if this basic type being defined in the same way
> in both IETF and OC YANG, and I believe that the OC folks have got the
> definition right.
> 
> I see that some are arguing that the zone in the ip-address definition is
> effectively optional, and implementations are not really obliged to
> implement it.  I don't find that argument compelling, at least not with the
> current definition of ip-address in RFC 6991.  I see a clear difference 
> between
> a type defined with an incomplete regex that may allow some invalid values
> and a type that is explicitly defined to included additional values in the
> allowable value space.  Further, I believe that a client just looking at the
> YANG module could reasonably expect a server that implements a data node
> using ip-address would be expected to support IP zones, where they are
> meaningful, or otherwise they should deviate that data node to indicate that
> they don't conform to the model.
> 
>

Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

[Rob Wilton (rwilton)]

Hi all,

Thanks for the comments on this thread so far.  It would be nice if we are able 
to come to some sort of rough consensus to a solution.

I think that there is consensus that the YANG type ip-address (and the v4/v6 
versions) are badly named as the prominent default type name has been given to 
the unusual variant of including zone information.

Based on the comments on this thread, it also seems likely to me that most of 
the usages of ip-address in YANG RFCs is likely to be wrong, and the intention 
was that IP addresses without zones was intended.  At a rough count, of the 
published RFC YANG models at github YangModels/standard/ietf/RFC/ to be:
86 uses of ip-address
68 uses of ipv4-address
66 uses of ipv6-address

1 use of ip-address-no-zone
4 uses of ipv4-address-no-zone
4 uses of ipv6-address-no-zone

These types appear in 49 out of the 141 YANG modules published in RFCs.  At a 
quick guess/check it looks like these 49 YANG modules may appear in 40-50 RFCs.

As mentioned previously, it is also worth comparing this to the OpenConfig YANG 
modules:
They have redefined ip-address (and v4/v6 variants) to exclude zone information 
and have defined separate types include zone information.
There are no explicit uses of the "-zoned" variants of OpenConfig IP addresses 
in the latest OpenConfig github repository.  However, approximately a third of 
the IP address types are still to the ietf-inet-types.yang rather than 
openconfig-inet-types.yang, so in theory some of those 58 entries could still 
intentionally be supporting zoned IP addresses, but I would expect that the 
vast majority would not.
I do see some strong benefit if this basic type being defined in the same way 
in both IETF and OC YANG, and I believe that the OC folks have got the 
definition right.

I see that some are arguing that the zone in the ip-address definition is 
effectively optional, and implementations are not really obliged to implement 
it.  I don't find that argument compelling, at least not with the current 
definition of ip-address in RFC 6991.  I see a clear difference between a type 
defined with an incomplete regex that may allow some invalid values and a type 
that is explicitly defined to included additional values in the allowable value 
space.  Further, I believe that a client just looking at the YANG module could 
reasonably expect a server that implements a data node using ip-address would 
be expected to support IP zones, where they are meaningful, or otherwise they 
should deviate that data node to indicate that they don't conform to the model.

We also need to be realistic as to what implementations will do.  They are not 
going to start writing code to support zones just because they are in the 
model.  They will mostly reject IP addresses with zone information.  Perhaps 
some will deviate the type to ip-address-no-zone, but probably most won't.

The option of respinning approx. 40-50 RFCs to fix this doesn't feel at all 
appealing.  This would take a significant amount of time/effort and I think 
that we will struggle to find folks who are willing to do this.  Although 
errata could be used to point out the bug, then can't be used to fix it, all 
the errata would be "hold for document update" at best.  Further, during the 
time that it would take us to fix it, it is plausible that more incorrect 
usages of ip-address will likely occur (but perhaps could be policed via 
scripted checks/warnings).


I still feel the right long-term solution here is to get to a state where the 
"ip-address" type means what 99% of people expect it to mean, i.e., excluding 
zone information.

Given the pushback on making a single non-backwards compatible change to the 
new definition, I want to ask whether the following might be a possible path 
that gains wider consensus:

(1) In RFC 6991 bis, I propose that we:
(i) define new ip-address-with-zone types (and v4 and v6 versions) and keep the 
-no-zone versions.
(ii) we change the description of "ip-address" to indicate:
- Although the type allows for zone information, many implementations are 
unlikely to accept zone information in most scenarios (i.e., so the description 
of the type more accurately reflects reality).
- A new ip-address-with-zone type has been introduced to use where zoned IP 
addresses are required/useful, and models that use ip-address with the 
intention of supporting zoned IP addresses MUST migrate to ip-address-with-zone.
- In the future (at least 2 years after RFC 6991 bis is published), the 
expectation is that the definition of ip-address will change to match that of 
ip-address-no-zone.

(2) Then in 2 years time, we publish RFC 6991-bis-bis to change the definition 
of ip-address to match ip-address-no-zone and deprecate the "-no-zone" version 
at the same time.

My reasoning as to why to take this path is:
(1) It is a phased migration, nothing breaks, 3rd parties have time to migrate.
(2) It ends up 

Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

[Rob Wilton (rwilton)]

I basically agree with Acee, and I think that we should do (b):

b) Change the types as suggested and accept that doing so breaks
modules where zone indexes are meaningful.

I appreciate that this is an NBC change, but I believe that this is the most 
intuitive definition and is the best choice longer term.  I also note that the 
base ipv4-address/ipv6-address types in OpenConfig (where they use the OC 
copy/version of inet-types and not ietf-inet-types) don't allow a zone to be 
specified and assumes the default zone.  They have separate types in cases 
where a zone is allowed to be specified, i.e., aligned to what (b) proposes.

For modules that are using/wanting zones (if any), then they can migrate to the 
new explicit zone type.   draft-ietf-netmod-yang-module-versioning, if it keeps 
its import "revision-or-derived" extension, would also allow such modules to 
indicate the dependency on the updated revision/definition of 
ietf-inet-types.yang.

Of course, the description associated with the updated ietf-inet-types.yang 
revision should clearly highly the non-backwards-compatible change to the types.

Rob


-Original Message-
From: iesg  On Behalf Of Jürgen Schönwälder
Sent: 07 April 2022 08:35
To: Acee Lindem (acee) 
Cc: l...@ietf.org; The IESG ; netmod@ietf.org
Subject: Re: [netmod] [Lsr] I-D Action: 
draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

Here is roughly what happened:

- RFC 6020 (published ~12 years ago) introduced the ip-address
  type. It included an optional zone index part since zone indexes
  are necessary in certain situations (e.g., configuring services
  listening on link-local addresses or clients connecting to services
  listening on link-local addresses).

- RFC 6991 (published ~9 years ago) added the ip-address-no-zone types
  since people felt that it is useful to also an ip address type
  without the optional zone part for situations where a zone is not
  applicable. The name 'ip-address-no-zone' was picked since the name
  ip-address was already taken.

I understand that the names resulting from this evolution of the YANG
module confuse people not looking up the type definitions. Let me note
that using a type allowing for an optional zone for a leaf that never
needs a zone is not a fatal error (its like using an int where a short
is sufficient) while using a type not allowing for a zone for a leaf
that may need zones is a fatal error (using a short where an int is
required) requiring an update of the definition of the leaf to fix.

What are our options?

a) Do nothing and accept that types are called as they are.
b) Change the types as suggested and accept that doing so breaks
   modules where zone indexes are meaningful.
c) Deprecate the types and create a new module defining new types
   so that modules can opt-in to use better names.
d) Deprecate the -no-zone types and move back to have a single
   type for IP addresses.

Any other options?

How are we going to pick between them?

/js

On Wed, Apr 06, 2022 at 09:02:23PM +, Acee Lindem (acee) wrote:
> Jürgen and netmod WG,  +IESG,
> 
> It is not just the IETF models that are using the inet:ip-address for the 
> standard IPv4/IPv6 addresses without zones. Every vendor’s native models and 
> the OpenConfig models use the base types and expect the standard IP address 
> notation. If we don’t fix this, it is something that people can point to as 
> another example of the IETF being out of touch with reality.
> 
> I thought about more, and it might make the backward compatibility easier if 
> we just leave the existing ip-address-no-zone, ipv4-address-no-zone, and 
> ipv6-address-no-zone types and add *-zone types for the remote possibility 
> that someone actually wants to include the zone.  In the existing RFC 6991 
> BIS document, we could merely remove the zone from the ip-address, 
> ipv4-address, and ipv6-address types and classify this as we would any other 
> bug fix. While including the zone was the original intent of the base types, 
> this is what those of us who work on software products would classify as a 
> requirements bug.
> 
> Thanks,
> Acee
> 
> From: Andy Bierman 
> Date: Tuesday, April 5, 2022 at 3:21 PM
> To: Juergen Schoenwaelder , Andy 
> Bierman , Acee Lindem , "l...@ietf.org" 
> , "netmod@ietf.org" 
> Subject: Re: [netmod] [Lsr] I-D Action: 
> draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt
> 
> 
> 
> On Tue, Apr 5, 2022 at 12:02 PM Jürgen Schönwälder 
> mailto:j.schoenwael...@jacobs-university.de>>
>  wrote:
> On Tue, Apr 05, 2022 at 10:03:25AM -0700, Andy Bierman wrote:
> > >
> > > The best outcome would be to fix ip-address to not include the zone,
> > > introduce ip-address-zone, and deprecate ip-address-no-zone. My take all
> > > the is that all the existing usages do not require zone and this would be 
> > > a
> > > fix as opposed to a change.
> > >
> > >
> > I don't think this will harm our implementations.
> > The type is still string. The pattern will change but 

Re: [netmod] [Technical Errata Reported] RFC7950 (6885)

[Rob Wilton (rwilton)]

Hi,

I agree with Andy, Jurgen, and Randy that this is not a valid errata, and hence 
I will reject it.

Kaja, if you are not aware, there is active work progressing in NETMOD looking 
at versioning and conformance.  A reasonable chunk of time will be spent 
discussing some aspects of this in next weeks NETMOD meeting at IETF 113. A 
closely related issue to what you described came up in the discussions: What 
does a backwards compatible change mean in the context of operational data that 
is being read from the server, as opposed to configuration data that is being 
written to the server.  Specifically, expanding a leaf range on a config true 
item, will equate to an expanded range on the same (logically config false) 
item represented in the NMDA operational datastore view.

After quite a lot of discussion, the conclusion was that trying to either be 
stricter about operational data or trying to describe the changes in a module 
version number wouldn't be useful.  I think that you get to the logical 
conclusion that you can't add or change anything at all!  E.g., if an updated 
version of a module adds a new leaf A, set by client C1, then a separate client 
C2, that doesn't understand the new version of the module won't understand leaf 
A when it reads the config (or operational data) back from the server.  When I 
have thought about this issue, I have always considered that the operator needs 
to coordinate between all their clients, so that if they make use of new 
functionality in one client (e.g., an expanded item range for a config item) 
then they need to ensure that all their other clients interacting with the 
server can handle (or ignore) the changes in the schema.

Note the weekly versioning calls (2-3 pm UK time on Tuesday, the webex link 
will be in the Netmod mail archives) are open to all participants.

Regards,
Rob


> -Original Message-
> From: Jürgen Schönwälder 
> Sent: 16 March 2022 06:13
> To: RFC Errata System 
> Cc: m...@tail-f.com; war...@kumari.net; Rob Wilton (rwilton)
> ; kent+i...@watsen.net; joe...@bogus.com;
> lber...@labn.net; kaja.mohid...@nokia.com; netmod@ietf.org
> Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6885)
> 
> YANG update rules expect clients to be lenient about values they
> received but did not expect. It is possible to debate that design
> choice but this surely is not an errata, hence this errata should
> be rejected.
> 
> /js
> 
> On Tue, Mar 15, 2022 at 10:21:12PM -0700, RFC Errata System wrote:
> > The following errata report has been submitted for RFC7950,
> > "The YANG 1.1 Data Modeling Language".
> >
> > --
> > You may review the report below and at:
> > https://www.rfc-editor.org/errata/eid6885
> >
> > --
> > Type: Technical
> > Reported by: R Kaja Mohideen 
> >
> > Section: 11
> >
> > Original Text
> > -
> >A definition in a published module may be revised in any of the
> >following ways:
> >
> >o  An "enumeration" type may have new enums added, provided the old
> >   enums's values do not change.  Note that inserting a new enum
> >   before an existing enum or reordering existing enums will result
> >   in new values for the existing enums, unless they have explicit
> >   values assigned to them.
> >
> >o  A "bits" type may have new bits added, provided the old bit
> >   positions do not change.  Note that inserting a new bit before an
> >   existing bit or reordering existing bits will result in new
> >   positions for the existing bits, unless they have explicit
> >   positions assigned to them.
> >
> > Corrected Text
> > --
> > See Notes.
> >
> > Notes
> > -
> > When server is exposing updated yang model as mentioned in Section 11,
> particularly with enums, bits having new items - client systems that are not
> updated to use the new yang module will not be able to recognize and use
> the new values.
> >
> > This is problematic when there are multiple clients and those systems are
> getting updated to catch up with yang changes over time. Updated "Client A"
> recognizing new enum and using it (update datastore with new value using
> edit-config), will make, old/not-yet-updated "Client B" to encounter the new
> value (received as response of get-config) that it cannot work with.
> >
> > So, the "backward compatible" ways of updating a yang module should
> consider "multiple clients" scenario and make recommendations in such a
> way that clients are not forced to update all at once.
> &g

Re: [netmod] iana-if-type.yang has multiple revisions with the same date

[Rob Wilton (rwilton)]

Hi William,

IANA have published a new revision with the revision history fixed.

iana-if-type YANG 
Module<https://www.iana.org/assignments/iana-if-type/iana-if-type.xhtml>

Regards,
Rob


From: netmod  On Behalf Of Rob Wilton (rwilton)
Sent: 04 March 2022 14:37
To: William Lupton ; Benoit Claise 

Cc: NetMod WG 
Subject: Re: [netmod] iana-if-type.yang has multiple revisions with the same 
date

Hi William,

I have asked Sabrina in IANA to please publish a new revision with the history 
fixed.

Regards,
Rob


From: netmod mailto:netmod-boun...@ietf.org>> On 
Behalf Of William Lupton
Sent: 04 March 2022 10:15
To: Benoit Claise mailto:benoit.cla...@huawei.com>>
Cc: NetMod WG mailto:netmod@ietf.org>>
Subject: Re: [netmod] iana-if-type.yang has multiple revisions with the same 
date

+1 (not surprisingly). What action? And whose action?

On Thu, 3 Mar 2022 at 19:24, Benoit Claise 
mailto:benoit.cla...@huawei.com>> wrote:
+1  to Jürgen point of view.

Regards, Benoit
From:Jürgen Schönwälder 
mailto:j.schoenwael...@jacobs-university.de>>
To:William Lupton 
mailto:wlup...@broadband-forum.org>>
Cc:NetMod WG mailto:netmod@ietf.org>>
Date:2022-03-03 20:01:06
Subject:Re: [netmod] iana-if-type.yang has multiple revisions with the same date

The obvious thing to do in this particular case (where there are only
allocations of new values) is to collapse the revisions and to move
on. Slightly better would be to ensure this does not happen again.

/js

On Thu, Mar 03, 2022 at 05:45:25PM +, William Lupton wrote:
> > It is too late to do anything about this module.
>
> This module is republished every time a new ifType is added. Are you saying
> that it would be unacceptable to collapse the duplicate revisions next time
> it's updated? If so then we will live with this FOR EVER!
>
> >

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


--
Jürgen Schönwälder  Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 <https://www.jacobs-university.de/>

___
netmod mailing list
netmod@ietf.org<mailto: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] iana-if-type.yang has multiple revisions with the same date

[Rob Wilton (rwilton)]

Hi Andy,

YANG packages are aimed at partly solving the problem you describe below.

In the -00 revision of the packages draft, it included SHA hashes* (YANG leaf 
“checksum”) of the included modules and packages so that a client can determine 
that its local copy of module@A.B.C (or revision-date) 
exactly matches the one that the server is declaring that it is using in the 
YANG package definition.  You can see this in the -00 version (YANG Packages 
(ietf.org)).

The checksum/hashes have been taken out of later revisions of the draft for two 
reasons:

  1.  At the time, we were not sure that we had a canonical representation of a 
YANG module, although possibly this has been mitigated by the YANG module 
versioning draft that effectively defines the file text of the published YANG 
module to be that canonical representation.
  2.  It was thought that it was too complex, and hence better deferred to an 
extension of future version of the YANG packages draft.  We also thought that 
we would need to get real security folks involved to check that we are really 
getting this right.

But either way, longer term, I think that a scheme along these lines this will 
probably be helpful.

Rob
// As an individual contributor


From: netmod  On Behalf Of Andy Bierman
Sent: 03 March 2022 16:56
To: William Lupton 
Cc: NetMod WG 
Subject: Re: [netmod] iana-if-type.yang has multiple revisions with the same 
date



On Thu, Mar 3, 2022 at 1:25 AM William Lupton 
mailto:wlup...@broadband-forum.org>> wrote:
Thanks Andy. What is the next step? Should I (or someone else) email 
i...@iana.org, or can we assume that the relevant IANA 
person will already have seen this discussion?


It seems that RFC 8407 already says what to do (use a different revision-date).
We combine the revision-stmt so there is only 1 revision entry instead of 2.

It is too late to do anything about this module.

I am interested in the OPS issues:
The client MUST be able to produce the same[*] schema tree as the server
in order to have an accurate model of the server's YANG API.

 1) server uses implementation-specific mechanisms (e.g. search path)
 to select the modules it will advertise in its yang-library
 2) client reads the yang-library, which provides all the [name,date] tuples
 and other info needed
 3a) client can use cached yang-library data and locally obtained YANG files
 3b) client can use  (IFF supported by the server) to retrieve the 
YANG files

[*] same can mean a later revision if specific schema definitions have not 
changed

Issues:

1) Is there ANY uniqueness guarantee that [name, date] is GLOBALLY unique.
A: Yes according to RFC 7950, but not really in implementations.
A: No, if revision-label is added and the same revision-date is used in 
multiple release trains.

So if a client cannot rely on [name, date] uniqueness, then it does not really 
know if
step 3a or step 3b is required.

This is currently a solved problem using proprietary means
(e.g., client hacked to know which one, based on server testing).

But now there are more system components, not just a server,
such as YANG Data Instance Files and YANG SID Files.
If the [name, date] tuples are not globally unique here,
then these standards do not work.


Andy






On Tue, 1 Mar 2022 at 14:49, Andy Bierman 
mailto:a...@yumaworks.com>> wrote:

I think that this should be fixed. What's the best way to achieve this?

I think this issue should be resolved as well.
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] iana-if-type.yang has multiple revisions with the same date

[Rob Wilton (rwilton)]

Hi Andy,

On this specific point:

Note that with multiple release trains and the new SERMVER, it is likely
that multiple [name, date, label] tuples resolve to the same [name, date] pair,
making the uniqueness problem even worse.

The module versioning draft explicitly disallows this.  Even when using 
revision-labels/Semver there is a requirement that they are separate revision 
modules with unique revision dates.

Specifically, it contains this text:

   In addition, this document uses the following terminology:

   o  YANG module revision: An instance of a YANG module, uniquely
  identified with a revision date, with no implied ordering or
  backwards compatibility between different revisions of the same
  module.


   This document clarifies [RFC7950] and [RFC6020] to explicitly allow

   non-linear development of YANG module and submodule revisions, so

   that they MAY have multiple revisions that directly derive from the

   same parent revision.  As per [RFC7950] and [RFC6020], YANG module

   and submodule revisions continue to be uniquely identified by their

   revision date, and hence all revisions of a given module or submodule

   MUST have unique revision dates.

And for revision labels:


  Revision labels MUST be unique amongst all revisions of a

  module or submodule.

Regards,
Rob
// As an author/contributor.



From: netmod  On Behalf Of Andy Bierman
Sent: 01 March 2022 14:49
To: William Lupton 
Cc: NetMod WG 
Subject: Re: [netmod] iana-if-type.yang has multiple revisions with the same 
date



On Tue, Mar 1, 2022 at 4:54 AM William Lupton 
mailto:wlup...@broadband-forum.org>> wrote:
All,

Sorry if (as is quite likely) this is a duplicate.

I noticed from https://yangcatalog.org/private-page/BBFYANGPageCompilation.html 
that there's a (long-standing?) problem in 
iana-if-type.yang:
 it has multiple revision statements with the same date:

  revision 2018-06-28 {
description
  "Registered ifType 294.";
  }

  revision 2018-06-28 {
description
  "Registered ifType 293.";
  }
This has presumably happened as a result of an automated update script that 
doesn't check for this case (*)? From a quick scan, I didn't see anything in 
RFC 7950 banning duplicate revision dates, but RFC 8407 section 4.8 says "If 
the module contents have changed, then the revision date of that new module 
version MUST be updated to a date later than that of the previous version" and 
of course yangdump-pro is checking this.

I think that this should be fixed. What's the best way to achieve this?

I think this issue should be resolved as well.
The YANG library identifies each module by a [name, date] tuple.
The  operation uses this tuple to identify a specific revision to 
retrieve.
The import-by-revision mechanism uses this tuple to identify a specific 
revision to import.

If this [name, date] tuple is not unique, then it cannot be mapped to a single 
module revision.

Note that with multiple release trains and the new SERMVER, it is likely
that multiple [name, date, label] tuples resolve to the same [name, date] pair,
making the uniqueness problem even worse.

This is quite significant if a client reads the YANG library from a server
and decides it already has the module cached (based on the [name, date] tuple,
as defined in the standard.  Then it will not use the  operation
to retrieve the module from the server.

YANG artifacts and SID files also rely on this [name, date] tuple uniqueness.

Even with the new versioning drafts, it is impossible for the client to know
"Do you mean the REAL module foo, version -xx-xx, or your private version?"


Thanks,
William

 Andy


(*) In the rare event that multiple changes are made in the same day, perhaps 
the second change should be (strictly wrongly) assigned to the following day. 
In theory this could cause revision dates to run far into the future but in 
practice I don't think this will happen :).
___
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] iana-if-type.yang has multiple revisions with the same date

[Rob Wilton (rwilton)]

Hi William,

I have asked Sabrina in IANA to please publish a new revision with the history 
fixed.

Regards,
Rob


From: netmod  On Behalf Of William Lupton
Sent: 04 March 2022 10:15
To: Benoit Claise 
Cc: NetMod WG 
Subject: Re: [netmod] iana-if-type.yang has multiple revisions with the same 
date

+1 (not surprisingly). What action? And whose action?

On Thu, 3 Mar 2022 at 19:24, Benoit Claise 
mailto:benoit.cla...@huawei.com>> wrote:
+1  to Jürgen point of view.

Regards, Benoit
From:Jürgen Schönwälder 
mailto:j.schoenwael...@jacobs-university.de>>
To:William Lupton 
mailto:wlup...@broadband-forum.org>>
Cc:NetMod WG mailto:netmod@ietf.org>>
Date:2022-03-03 20:01:06
Subject:Re: [netmod] iana-if-type.yang has multiple revisions with the same date

The obvious thing to do in this particular case (where there are only
allocations of new values) is to collapse the revisions and to move
on. Slightly better would be to ensure this does not happen again.

/js

On Thu, Mar 03, 2022 at 05:45:25PM +, William Lupton wrote:
> > It is too late to do anything about this module.
>
> This module is republished every time a new ifType is added. Are you saying
> that it would be unacceptable to collapse the duplicate revisions next time
> it's updated? If so then we will live with this FOR EVER!
>
> >

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


--
Jürgen Schönwälder  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
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Last call on YANG module versioning and Semver

[Rob Wilton (rwilton)]

Hi Netmod WG,

As many of you may already aware, I've been closely involved in authoring both 
the YANG module versioning draft 
(https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-module-versioning/) 
and (https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-semver/).

I will of course follow the normal practice and recluse myself from AD 
responsibility for these drafts once the WG has finished with them, which as 
per Lou's comment of holding the documents after the WGLC has completed so that 
they can go as a set, won't be imminent anyway.  Any IESG processing will be 
handled by another AD, which could be Warren, or possibly someone else chosen 
when the WG is close to finishing with the full set of documents.

Regards,
Rob
 



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

Re: [netmod] [Technical Errata Reported] RFC7950 (6855)

[Rob Wilton (rwilton)]

Hi,

I basically agree with Kent, Randy, Andy.

Alexi,

Thanks for flagging this, and the subsequent discussion.

I can see your point of view that MUST is used in other similar places, and I'm 
sure that in hindsight it would be nice if the language was used consistently 
in equivalent places.

However, I don't think that the lack of a MUST statement makes the other text 
any less normative, or ambiguous.  In particular, there is this paragraph of 
RFC 8174 that updates RFC 2119:

   o  These words can be used as defined here, but using them is not
  required.  Specifically, normative text does not require the use
  of these key words.  They are used for clarity and consistency
  when that is what's wanted, but a lot of normative text does not
  use them and is still normative.

Hence, I have rejected this errata.  If you find the current text to be 
confusing and think that it would be helpful to clarify this is a future 
version of this specification, then I would suggest that you open an issue here 
(https://github.com/netmod-wg/yang-next/issues), and it will get evaluated when 
we get to revising YANG.

Regards,
Rob


-Original Message-
From: Kent Watsen  
Sent: 22 February 2022 15:05
To: Rob Wilton (rwilton) 
Cc: SADOVNIKOV, ALEXEI ; RFC Errata System 
; m...@tail-f.com; war...@kumari.net; Joel Jaeggli 
; Lou Berger ; Randy Presuhn 
; netmod@ietf.org
Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6855)

Move to close this Errata without accepting it.

Kent  // as co-chair



> On Feb 17, 2022, at 5:53 PM, Randy Presuhn 
>  wrote:
> 
> Hi -
> 
> On 2022-02-17 1:01 PM, SADOVNIKOV, ALEXEI wrote:
>> Randy,
>> I definitively see that point, and the line of sparing usage can be somewhat 
>> subjective.
>> In this case, I think use of “MUST” is justified RFC 2119 “actually required 
>> for interoperation or to limit behavior which has potential for causing 
>> harm”.
>> Missing “MUST” statement does leave it open for interpretation, and
> 
> That is simply not true.  The existing text, e.g. "If the container
> defines RPC or action input or output parameters, these subelements
> are encoded in the same order as they are defined within the
> 'container' statement"  leaves no room whatsoever for interpretation.
> 
>> misinterpretation will result in harm – XML payload which encapsulated 
>> without following these ordering rule can be rejected during decapsulation 
>> which does follow the rule.  The XML payload is exchanged between client and 
>> server, often different implementations, hence different interpretation by 
>> different developers will lead to communication failure.
> 
> The existing text is unambiguous, and provides no options in ordering.
> 
>> As such, I do not see how proposed errata is at odds with sparing usage 
>> provision, when it meets the described reason for usage.
>> In other sections of this RFC (7.7.8., 7.8.5. and 7.9.5) “MUST” already used 
>> for same purpose; it is difficult to see how it is any more important in 
>> where ‘MUST’ is used vs to where it is not.
>> Having said all that, the suggested errata can be reduced to exclude section 
>> 7.5.7 and second paragraph of 7.8.5 – in both of this cases the exact 
>> meaning can be referred from section 7.14.4 (as long as “MUST” is present in 
>> there).  Would that resolve your concern of sparing usage?
> 
> Such text-diddling seems utterly pointless to me.
> 
> Randy
> 
> 
>> Best regards,
>> *Alexei Sadovnikov*
>> Principal System Architect
>> Business Solutions
>> AT Business
>> *AT Services, Inc.*
>> 550 Cochituate Road, Framingham, MA 01701
>> m  781.249.1516 |  o  781.249.1516 | _as5...@att.com <mailto:as5...@att.com>_
>> This e-mail and any files transmitted with it are AT property, are 
>> confidential, and are intended solely for the use of the individual or 
>> entity to whom this e-mail is addressed. If you are not one of the named 
>> recipient(s),  or otherwise have reason to believe that you have received 
>> this message in error, please notify the sender and delete this message 
>> immediately from your computer. Any other use, retention, dissemination, 
>> forwarding, printing, or copying of this e-mail is strictly prohibited.
>> *From: *Randy Presuhn 
>> *Date: *Thursday, February 17, 2022 at 2:55 PM
>> *To: *RFC Errata System , "m...@tail-f.com" 
>> , "war...@kumari.net" , 
>> "rwil...@cisco.com" , "joe...@bogus.com" 
>> , "kent+i...@watsen.net" , 
>> "lber...@labn.net" 
>> *Cc: *as549r , "netmod@ietf.org" 
>> *Subject: *Re: 

Re: [netmod] Use XML namespaces in YANG document examples

[Rob Wilton (rwilton)]

Hi Tom,

Thanks for flagging this.

I agree that this text is not helpful in understanding the examples (nor is 
this text present in other YANG module examples), and I will indeed raise this 
in my ballot.

Regards,
Rob


-Original Message-
From: tom petch  
Sent: 12 February 2022 12:54
To: Rob Wilton (rwilton) 
Cc: netmod@ietf.org
Subject: Re: [netmod] Use XML namespaces in YANG document examples

Going back to the original issue and so top-posting.

NSF Monitoring Interface YANG Data Model
is on the IESG Telechat  17feb2022.

It contains the text - not an easy read unless you are an XML expert - 
"In order for the XML
   data to be used correctly, the prefix (i.e., the characters before
   the colon or 'nsfmi' in the example) in the content of the element
   that uses the "identityref" type (e.g., /i2nsf-event/i2nsf-system-
   detection-alarm/alarm-category/) in the YANG module described in this
   document MUST be the same as the namespace prefix (i.e., 'nsfmi' in
   the example) for urn:ietf:params:xml:ns:yang:ietf-i2nsf-nsf-
   monitoring.  Therefore, XML software MUST be chosen that makes the
   namespace prefix information available."

This is the result of discussions between IANA and the XML directorate, which I 
have seen copied to the WG list, and seems to me to be in direct contradiction 
of the consensus of the NETMOD WG list as shown in the discussions this month 
on this thread over the DHCP I-D and a separate thread on the I2NSF I-D in 
January and is likely to be a source of confusion for the future.  

 NSF-Facing Interface YANG Data Model  
is on the same Telechat but I do not see the same text.

I would like an AD to throw a flag, in the shape of a DISCUSS so I am copying 
Robert.

My take is that the text should not be included in any I-D based on the 
consensus of the NETMOD WG (as I perceive it).  One suggestion was that it 
needed an update to RFC7950 to make it justified.

(Also, my rant of 2022, these late stage non-WG interventions should not be 
over-riding the WG discussions but that is not going to change any time soon).

Tom Petch

From: netmod  on behalf of tom petch 

Sent: 11 February 2022 17:03

From: Carsten Bormann 
Sent: 11 February 2022 08:21
>> (I'm also still not sure I've got an answer to my question about using 
>> inconsistent prefixes between YANG and the XML example.  What is being 
>> demonstrated here?)
>>
> 
> If you are referring to
> " Is there a reason to violate the SHOULD?"

I'm referring to the question I was trying to ask when I said this :-)

> I did not see that as related to the thread but thought it was answered 
> anyway by Juergen.  As he said, the SHOULD gets violated when prefix clash 
> which, in the absence of a registry, a namespace, for prefix is possible.

Yes, and thanks to him for answering my question as a general question.

I was answering to a throwaway note that the authors got flak when their XML 
did not use the defined prefix.  My question was: why do that, then?  Maybe 
that was not understood because "ianaift" actually *is* the prefix preferred in 
the YANG module, so my question doesn't make sense.  (I'm not sure what the 
throwaway referred to.)



Try again.

I have commented a number of times on a YANG import which defines a prefix 
other than that in the RFC.  Last month, it was
 import ietf-hardware {
   prefix ietfhw;
Usually, when I comment on this, the authors accept my comment and change the 
prefix - they did on this occasion - but sometimes I get pushback along the 
lines that YANG Guidelines is only a 'SHOULD' and we think that we have a good 
reason to ignore the 'SHOULD' .  To date, I have never agreed with the reason 
and go on commenting:-)  If that is flack, then yes, I have - and will - 
generate flack:-)

Tom Petch


Grüße, Carsten


___
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] Regarding IPR on Regarding IPR on draft-ietf-netmod-yang-semver-06

[Rob Wilton (rwilton)]

"No, I'm not aware of any IPR that applies to this draft"

Thanks,
Rob


-Original Message-
From: Lou Berger  
Sent: 31 January 2022 21:57
To: Joe Clarke (jclarke) ; Rob Wilton (rwilton) 
; res...@yahoo.com; balazs.leng...@ericsson.com; 
jason.ste...@nokia.com; benoit.cla...@huawei.com
Cc: NetMod WG ; NetMod WG Chairs 
Subject: Regarding IPR on Regarding IPR on draft-ietf-netmod-yang-semver-06



Authors, Contributors, WG,

As part of WG Last Call:

Are you aware of any IPR that applies to drafts identified above?

Please state either:

"No, I'm not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3669, 5378 and 8179 for more details)?

If yes to the above, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think
appropriate. If you are listed as a document author or contributor
please answer the
above by responding to this email regardless of whether or not you are
aware of any relevant IPR. This document will not advance to the next
stage until a response has been received from each author.

NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES.

If you are on the WG email list or attend WG meetings but are not listed
as an author or contributor, we remind you of your obligations under
the IETF IPR rules which encourages you to notify the IETF if you are
aware of IPR of others on an IETF contribution, or to refrain from
participating in any contribution or discussion related to your
undisclosed IPR. For more information, please see the RFCs listed above
and
http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.

Thank you,
Lou (Co-Chair)

PS Please include all listed in the headers of this message in your
response.


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

Re: [netmod] Regarding IPR on draft-ietf-netmod-yang-module-versioning-05

[Rob Wilton (rwilton)]

"No, I'm not aware of any IPR that applies to this draft"

Thanks,
Rob


-Original Message-
From: Lou Berger  
Sent: 31 January 2022 21:54
To: Joe Clarke (jclarke) ; res...@yahoo.com; Rob Wilton 
(rwilton) ; balazs.leng...@ericsson.com; 
jason.ste...@nokia.com
Cc: NetMod WG ; NetMod WG Chairs 
Subject: Regarding IPR on draft-ietf-netmod-yang-module-versioning-05



Authors, Contributors, WG,

As part of WG Last Call:

Are you aware of any IPR that applies to drafts identified above?

Please state either:

"No, I'm not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3669, 5378 and 8179 for more details)?

If yes to the above, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think
appropriate. If you are listed as a document author or contributor
please answer the
above by responding to this email regardless of whether or not you are
aware of any relevant IPR. This document will not advance to the next
stage until a response has been received from each author.

NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES.

If you are on the WG email list or attend WG meetings but are not listed
as an author or contributor, we remind you of your obligations under
the IETF IPR rules which encourages you to notify the IETF if you are
aware of IPR of others on an IETF contribution, or to refrain from
participating in any contribution or discussion related to your
undisclosed IPR. For more information, please see the RFCs listed above
and
http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.

Thank you,
Lou (Co-Chair)

PS Please include all listed in the headers of this message in your
response.


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

Re: [netmod] Schema Mount

[Rob Wilton (rwilton)]

Hi Michal,

This isn't directly answering your questions, but I wanted to point out that 
YANG versioning work is currently discussing YANG packages, and how they work 
with Schema mount.  There are weekly calls (which starts in just under half an 
hour), that are open to all:

https://ietf.webex.com/ietf/j.php?MTID=me2c6491ebcc37b8127c1244d244d2754

Regards,
Rob


-Original Message-
From: netmod  On Behalf Of Michal Vaško
Sent: 24 January 2022 13:12
To: netmod 
Subject: [netmod] Schema Mount

Hello,
I wanted to implement this RFC [1] but I have great difficulty understanding 
how exactly it should work so I would like to ask for some clarification.

As for the ietf-yang-library data, they are mentioned several times but I could 
find no details as to how exactly they should look like. There is an example 
[2], which has only 'ietf-yang-library:modules-state' data tree that is 
deprecated. Am I to understand that is what is expected?

Another thing, there are 3 ways mentioned [3] as to when to specify the schema 
(YANG modules) for the mounted data and that only 2nd and 3rd are covered in 
the RFC. However, I was not able to find anything more about the 2nd option 
(implementation-time) and think that everything concerns only the 3rd option 
(run-time).

Lastly, I was also looking at another RFC [4] and its examples. There I could 
see 'ietf-yang-library:yang-library' data tree instead meaning every 
'module-set' and corresponding 'schema' need to be referenced by some 
'datastore'. The consequence would be that one must know the datastore of the 
data before they can be parsed, is that right? Moreover, for parsing one would 
also need the 'ietf-yang-schema-mount:schema-mounts' data (which are found in 
the operation data in the example) but where should the NETCONF/RESTCONF server 
(for instance) get them?

Thanks for any clarification.

Regards,
Michal

___
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] Should the origin="system" be required for system configurations copied/pasted into ?

[Rob Wilton (rwilton)]

Hi Martin,

I think that the proposal is that  should feed into  rather 
than directly into .  The reasoning for this is to allow 
configuration to depend on system defined configuration during validation 
without requiring that configuration to be copied into .  Clients 
would still be allowed to explicitly express the system configuration is 
running as well - e.g., if they wanted a full configuration that they can 
validate off box.
 
In your example below, I would probably mark the origin of the lo interface, 
the name leaf, and description leaf as "intended", but the type is "system".  I 
think that this would be similar to how I would expect a default value to be 
reported.  I.e., if the running config explicitly sets a leaf to its default 
value, I think that it is more informative to report that as origin "intended" 
rather than "origin" default.  But I don't think that RFC 8342 proscribes what 
is be used in these cases.

Regards,
Rob

// As a contributor


> -Original Message-
> From: netmod  On Behalf Of Martin Björklund
> Sent: 24 November 2021 10:44
> To: j.schoenwael...@jacobs-university.de
> Cc: maqiufang1=40huawei@dmarc.ietf.org; netmod@ietf.org
> Subject: Re: [netmod] Should the origin="system" be required for system
> configurations copied/pasted into ?
> 
> Jürgen Schönwälder  wrote:
> > On Wed, Nov 24, 2021 at 03:21:14AM +, maqiufang (A) wrote:
> > >
> > > But suppose the node is a list entry (e.g., an interface) or a leaf with 
> > > the
> same value.  In this case, it is not clear which origin should be used.  I 
> think it
> would be ok to use "system" in this case.
> >
> > For me,  is explicit config and hence it has precedence. The
> > precedence must be a function of how the datastores related, it should
> > not depend on which values a config leaf has.
> 
> Here's a simple example.
> 
> Suppose  has:
> 
>
>  lo
>  loopback
>  added by system
>
> 
> and  has:
> 
>
>  lo
>  set by a client
>
> 
> Now we follow the picture in RFC 8342:
> 
>   ++
>   |  | // subject to validation
>   | (ct, ro)   |
>   ++
> |// changes applied, subject to
> |// local factors, e.g., missing
> |// resources, delays
> |
>dynamic  |   + learned configuration
>configuration|   + system configuration
>datastores -+|   + default configuration
>||   |
>vv   v
> +---+
> |  | <-- system state
> | (ct + cf, ro) |
> +---+
> 
> 
> So now we merge intended and system into operational state.  First we
> add system to get:
> 
>   
> lo
> loopback
> added by system
>   
> 
> and then we add intended to arrive at:
> 
>   
> lo
> loopback
> set by a client
>   
> 
> 
> Doesn't this make sense?
> 
> 
> 
> /martin
> 
> ___
> 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] Should the origin="system" be required for system configurations copied/pasted into ?

[Rob Wilton (rwilton)]

+1 to Juergen's comment.

// As a contributor.


-Original Message-
From: netmod  On Behalf Of Jürgen Schönwälder
Sent: 24 November 2021 09:25
To: maqiufang (A) 
Cc: netmod@ietf.org
Subject: Re: [netmod] Should the origin="system" be required for system 
configurations copied/pasted into ?

On Wed, Nov 24, 2021 at 03:21:14AM +, maqiufang (A) wrote:
> 
> But suppose the node is a list entry (e.g., an interface) or a leaf with the 
> same value.  In this case, it is not clear which origin should be used.  I 
> think it would be ok to use "system" in this case.

For me,  is explicit config and hence it has precedence. The
precedence must be a function of how the datastores related, it should
not depend on which values a config leaf has.

/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

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

Re: [netmod] [Errata Verified] RFC8792 (6739)

[Rob Wilton (rwilton)]

Hi Kent, Qin,

Note that processing for editorial errata, like this one, are now generally 
handled directly by the RFC editor rather than the AD.

I appreciate where you are coming from, and given the RFC 7991 text, I agree 
that strictly this is not strictly a mistake, given it is allowed.  However, I 
can see why Martin raised this, and having the BCP 14 XML tags used 
consistently in the document (either everywhere or not at all) does aid 
readability.

I had flagged this errata up with the IESG on Friday, questioning whether this 
change should really come under the scope of being an errata or whether it just 
required the HTML to be re-generated, and this was discussed by the RFC editor 
and team responsible for the XML Schema.  However, the problem raised is that 
it is the XML that is the canonical definition of the RFC and it is the XML 
that needs modification to fix this issue, and I think that errata is currently 
the only mechanism that we have to make this change.

My bigger concern here is whether using this element in the XML should be 
optional at all.  That means for a given RFC 2119 keyword there are now two 
different ways that it can be represented in a generated HTML RFC: "MUST" and 
highlighted "MUST".   So, I agree that there is something that more generally 
needs to be considered and perhaps fixed here.  I will raise this with the RSE 
in the context of RFC 7991 bis.

Regards,
Rob


-Original Message-
From: iesg  On Behalf Of Kent Watsen
Sent: 19 November 2021 17:06
To: Rob Wilton (rwilton) 
Cc: Erik Auerswald ; netmod@ietf.org; 
i...@ietf.org; adr...@olddog.co.uk; rfc...@rfc-editor.org; Qin Wu 
; m...@lowentropy.net
Subject: Re: [Errata Verified] RFC8792 (6739)

I do not think this Errata should've been verified because RFC 7991 says that 
use of this tag is optional.

2.9.  

   Marks text that are phrases defined in [BCP14] such as "MUST",
   "SHOULD NOT", and so on.  When shown in some of the output
   representations, the text in this element might be highlighted.  The
   use of this element is optional.

I understand that there might be a consistency issue, but to take an RFC from 
having zero errata to non-zero errata over this seems petty.

FWIW, the authors did not have any  elements in the original XML.  Any 
such tags found in the final RFC must’ve been added by a copy editor.

K. // as a contributor




> On Nov 18, 2021, at 9:39 PM, RFC Errata System  
> wrote:
> 
> The following errata report has been verified for RFC8792,
> "Handling Long Lines in Content of Internet-Drafts and RFCs". 
> 
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid6739
> 
> --
> Status: Verified
> Type: Editorial
> 
> Reported by: Martin Thomson 
> Date Reported: 2021-11-18
> Verified by: RFC Editor  
> 
> Section: 7.1.2
> 
> Original Text
> -
> Exceptionally long lines MAY be folded multiple times.
> 
> Corrected Text
> --
> Exceptionally long lines MAY be folded multiple times.
> 
> Notes
> -
> The "MAY" in this text lacks a bcp14 XML tag. This is apparent in the 
> non-text renderings.
> 
> --VERIFIER NOTES--
> This also applies to section 8.1.2
> 
> --
> RFC8792 (draft-ietf-netmod-artwork-folding-12)
> --
> Title   : Handling Long Lines in Content of Internet-Drafts and 
> RFCs
> Publication Date: June 2020
> Author(s)   : K. Watsen, E. Auerswald, A. Farrel, Q. Wu
> Category: INFORMATIONAL
> Source  : Network Modeling
> Area: Operations and Management
> Stream  : IETF
> 

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

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

[Rob Wilton (rwilton)]

Hi Juergen,

My preference would be to last call this document so that other YANG modules 
can make use of the new types.  We can always spin a future bis document if 
further common types are useful.

draft-ietf-netmod-yang-module-versioning also makes use of the 
revision-identifier type defined in this draft.

Regards,
Rob

// As a contributor



-Original Message-
From: netmod  On Behalf Of Jürgen Schönwälder
Sent: 07 November 2021 16:36
To: netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc6991-bis-08.txt

On Sun, Nov 07, 2021 at 08:18:36AM -0800, internet-dra...@ietf.org wrote:
s.
> 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-08.txt
>   Pages   : 41
>   Date: 2021-11-07
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc6991-bis-08
>

This is a mostly editorial update. The draft has no open issues I am
aware of. The WG has to decide whether we wrap this up by sending the
document to WG last call and then through the publication pipeline or
we leave this I-D hanging around just in case more additions get
proposed and finally worked out so that they can be added. In later
case, it is crucial to provide concrete and actionable proposals.
Rough ideas "please add X" where it is left somewhat open what "X"
really boils down to or how "X" will be used makes it difficult to
work out the details.

/js

PS: I have not registered for IETF 112, I guess I will watch the
session recordings once they are available.

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

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

Re: [netmod] Tree diagrams

[Rob Wilton (rwilton)]

Hi Tom, Med, Authors

Tom, thanks for flagging these.

Med, authors, please can you check if the tree diagrams in 
draft-ietf-opsawg-vpn-common-12 or draft-ietf-opsawg-l3sm-l3nm-18 need to be 
updated.  If they do, then given that these documents are in the RFC editor 
queue then we will need to coordinate any corrections with the RFC editor.

Regards,
Rob


> -Original Message-
> From: netmod  On Behalf Of tom petch
> Sent: 15 October 2021 11:03
> To: netmod@ietf.org
> Subject: [netmod] Tree diagrams
> 
> I do not understand tree diagrams.  My expectation is that the same YANG
> should produce the same tree diagram but apparently not.  I look at
> RFC8519 and see
> 
> ||  |  +--:(tcp)
> ||  |  |  +--rw tcp {match-on-tcp}?
> 
> |  |  | +--rw source-port
> ||  |  | |  +--rw (source-port)?
> ||  |  | | +--:(range-or-operator)
> ||  |  | |+--rw (port-range-or-operator)?
> 
> but when imported into 'draft-ietf-opsawg-vpn-common-12' this becomes
>   |  | +--:(tcp)
>   |  | |  +-- tcp
> ..
>   |  | | +-- (source-port)?
>   |  | | |  +--:(source-port-range-or-operator)
>   |  | | | +-- source-port-range-or-operator
> ie the identifiers have gained a 'source'  (or 'destination').
> 
> Also, the structure changes.  Moving on, vpn-common has
> 
>   |  | +--:(tcp)
>   |  | |  +-- tcp
> .
>   |  | | +-- (source-port)?
>   |  | | |  +--:(source-port-range-or-operator)
>   |  | | | +-- source-port-range-or-operator
> ...
>   |  | | +-- (destination-port)?
>   |  | |+--:(destination-port-range-or-operator)
>   |  | |   +-- destination-port-range-or-operator
> which looks fine until this is imported into
> 'draft-ietf-opsawg-l3sm-l3nm-18' when it becomes
> 
>|  | |  | +--:(tcp)
>|  | |  | |  +--rw tcp
> ...
>|  | |  | | +--rw (source-port)?
>|  | |  | | |  +--:(source-port-range-or-operator)
>|  | |  | | | +--rw source-port-range-or-operator
>|  | |  | | |  inet:port-number
> 
>|  | |  | | +--rw (destination-port)?
>|  | |  | +--:(destination-port-range-or-operator)
>|  | |  | |  +--rw destination-port-range-or-operator
>|  | |  | | +--rw (port-range-or-operator)?
> 
> 'destination-port-range-or-operator' has moved and we now have
>|  | |  | +--:(tcp)
>|  | |  | +--:(destination-port-range-or-operator)
> which does not look fine to me; how can this be?
> 
> Earlier drafts of l3nm did not have this feature.
> 
> Tom Petch
> 
> ___
> 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] [OPSAWG] Francesca Palombini's Discuss on draft-ietf-opsawg-l3sm-l3nm-16: (with DISCUSS and COMMENT)

[Rob Wilton (rwilton)]

Carsten & Med,

Thanks for raising this.  I agree with the errata, but this will need to be 
hold for doc update, because we cannot create a different revision of a YANG 
module through the errata process.

Thanks,
Rob


From: iesg  On Behalf Of Francesca Palombini
Sent: 05 October 2021 15:12
To: Carsten Bormann ; mohamed.boucad...@orange.com
Cc: draft-ietf-opsawg-l3sm-l...@ietf.org; ops...@ietf.org; 
opsawg-cha...@ietf.org; The IESG ; netmod@ietf.org
Subject: Re: [OPSAWG] Francesca Palombini's Discuss on 
draft-ietf-opsawg-l3sm-l3nm-16: (with DISCUSS and COMMENT)

Thanks Carsten for noticing this! I did overlook completely that bps was being 
used as bytes per seconds... Thanks Med for clarifying in this document and for 
opening errata https://www.rfc-editor.org/errata/eid6703 . The OPS ADs are on 
it, I am sure.

Francesca

From: Carsten Bormann mailto:c...@tzi.org>>
Date: Tuesday, 5 October 2021 at 09:05
To: mohamed.boucad...@orange.com 
mailto:mohamed.boucad...@orange.com>>
Cc: Francesca Palombini 
mailto:francesca.palomb...@ericsson.com>>, 
The IESG mailto:i...@ietf.org>>, 
draft-ietf-opsawg-l3sm-l...@ietf.org
 
mailto:draft-ietf-opsawg-l3sm-l...@ietf.org>>,
 opsawg-cha...@ietf.org 
mailto:opsawg-cha...@ietf.org>>, 
ops...@ietf.org 
mailto:ops...@ietf.org>>, 
netmod@ietf.org 
mailto:netmod@ietf.org>>
Subject: Re: [OPSAWG] Francesca Palombini's Discuss on 
draft-ietf-opsawg-l3sm-l3nm-16: (with DISCUSS and COMMENT)
Hi Med,

> I confirm that what I meant is "bits per second" to align with rfc8299#6.12.1.

Ah.

> I'm actually for more explicit units similar to what we are using in another 
> active spec:

As long as there is this confusion in YANG units, that is the only way that 
makes sense.
One little tweak I'd have for that spec:

> ==
>  enum bit-ps {
>value 2;
>description
>  "Bits per Second (bit/s).";
>  }
>  enum byte-ps {
>value 3;
>description
>  "Bytes per second (Byte/s).";

Maybe use the actual ISO/IEC 8 notation here: B/s.
(For those that don't know how ISO/IEC 8 allocates "B" for byte, the legend 
"Bytes per second" is unambiguous.)

>  }
> ==
>
> However, we are in a territory where we are trying to map as much to the 
> above service model and hence use the same labels for the units.
>
> FWIW, RFC8466 used to have the following:
>
> =
>  leaf pbs {
>type uint64;
>units "bps";
>description
>  "Peak Burst Size.  It is measured in bytes per
>   second.";
>  }
> =
>
> ...which is weird.

This is really errata land, as "bps" is used as the kitchen slang for "bit/s" 
in all other cases (along with "mbps" for Mbit/s, shudder).

> This is why we don't blindly inherit that draft-ietf-opsawg-l2nm and went for 
> the following:
>
>  leaf pbs {
>type uint64;
>units "bytes per second";
>description
>  "Peak Burst Size.";
>  }

I think this would also benefit from "Bytes per Second (B/s)".

Grüße, Carsten

>
> Cheers,
> Med
>
>> -Message d'origine-
>> De : Carsten Bormann mailto:c...@tzi.org>>
>> Envoyé : lundi 4 octobre 2021 17:50
>> À : BOUCADAIR Mohamed INNOV/NET 
>> mailto:mohamed.boucad...@orange.com>>
>> Cc : Francesca Palombini 
>> mailto:francesca.palomb...@ericsson.com>>; 
>> The IESG
>> mailto:i...@ietf.org>>; 
>> draft-ietf-opsawg-l3sm-l...@ietf.org;
>>  opsawg-
>> cha...@ietf.org; 
>> ops...@ietf.org; 
>> netmod@ietf.org
>> Objet : Re: [OPSAWG] Francesca Palombini's Discuss on draft-ietf-opsawg-
>> l3sm-l3nm-16: (with DISCUSS and COMMENT)
>>
>> On 2021-10-04, at 13:34, 
>> mohamed.boucad...@orange.com wrote:
>>>
>>> bytes per second (bps),
>>
>> Whoa.
>>
>> I know that the IETF doesn't usually care about precision in these things,
>> but "bps" is kitchen slang for "bit/s", so this is very confusing.
>>
>> (Given that we have done the work in RFC 8428 and 8798, I'd rather see
>> that we use it, instead of creating more confusion at each further step.
>> We do have ms and B/s in RFC 8798, because people using SenML asked for
>> that.)
>>
>> Grüße, Carsten
>
>
> _
>
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par erreur, veuillez le signaler
> a 

Re: [netmod] Revision-labels within filenames

[Rob Wilton (rwilton)]

> -Original Message-
> From: Joe Clarke (jclarke) 
> Sent: 14 September 2021 20:38
> To: Rob Wilton (rwilton) ; netmod@ietf.org
> Subject: Re: Revision-labels within filenames
> 
> > I wasn't thinking of a URL to get the revision-label, I was more thinking 
> > of a
> URL to identify the source YANG file for a particular revision.
> >
> > E.g., in the YANG packages examples:
> >
> > https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-packages#
> > appendix-A
> >
> > Ideally, I would like the URLs pointing the source YANG files to be able to 
> > do
> so without requiring any encoding of the '@' or '#' symbol.
> 
> Wouldn't you think these locations would be generated via tooling (i.e.,
> consumable by automation or just having people click)?  I would expect a
> human to look at the other package metadata to get the list of modules and
> their revisions.

I agree that over time, most of these will be generated by tooling.  But I 
suspect that there will still be some cases where simple packages may be 
written and maintained by hand, where the risk is that incorrect URLs will be 
used, albeit, that it would be relatively easy for tooling to validate the URLs.

> 
> >
> > E.g., looking at some of the examples (which seem to have been converted
> somewhere), and hence the @ symbol has been converted to %40, which
> makes the date look like 40k years into the future.
> >
> >   "location": [ "https://tiny.cc/ietf-yang/\
> >iana-crypt-hash%402014-08-06.yang"
> > ],
> >
> > If this location can be something like https://tiny.cc/ietf-yang/iana-crypt-
> h...@2014-08-06.yang or https://tiny.cc/ietf-yang/iana-crypt-
> h...@2.3.1.yang then I think that it would make these URLs more readable.
> 
> I do agree it's more readable, but I don't think it's critical to ensure.

I agree it is not critical, just nice to have.

Thanks,
Rob

> 
> Joe

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

Re: [netmod] Revision-labels within filenames

[Rob Wilton (rwilton)]

Hi Kent,

It was the YANG package definitions that I had in mind.  More details in the 
response that I have just sent back to Joe.

Regards,
Rob


> -Original Message-
> From: Kent Watsen 
> Sent: 14 September 2021 18:19
> To: Joe Clarke (jclarke) 
> Cc: Rob Wilton (rwilton) ; netmod@ietf.org
> Subject: Re: [netmod] Revision-labels within filenames
> 
> 
> 
> >> Sorry, I was on PTO for the meeting where this was discussed.  I don't
> think that it is great that the character needs to be encoded in a URL.
> 
> How often are YANG module names in URLs?
> 
> A website for downloading modules would reference modules by URL but, as
> Joe said, the encoding would be transparent to the end-user (i.e., the
> downloaded filename would NOT have the encoded character in the name).
> 
> K. // contrib
> 

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

Re: [netmod] Revision-labels within filenames

[Rob Wilton (rwilton)]

> -Original Message-
> From: Joe Clarke (jclarke) 
> Sent: 14 September 2021 17:57
> To: Rob Wilton (rwilton) ; netmod@ietf.org
> Subject: Re: Revision-labels within filenames
> 
> On 9/14/21 12:01, Rob Wilton (rwilton) wrote:
> > Hi Joe,
> >
> > Sorry, I was on PTO for the meeting where this was discussed.  I don't think
> that it is great that the character needs to be encoded in a URL.  It would
> seem to make references to YANG files in YANG packages a lot more
> awkward to read/write.
> 
> The writing here will likely still be programmatically driven, but I get the
> reading argument.  While client automation won't care, a user reading
> %233.2.3 does not as easily grok that as #3.2.3.  That said, I wouldn't use 
> the
> URL as a means to get the revision-label.  I'd use the revision leaf in the
> package for a given module.

I wasn't thinking of a URL to get the revision-label, I was more thinking of a 
URL to identify the source YANG file for a particular revision.

E.g., in the YANG packages examples:

https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-packages#appendix-A

Ideally, I would like the URLs pointing the source YANG files to be able to do 
so without requiring any encoding of the '@' or '#' symbol.

E.g., looking at some of the examples (which seem to have been converted 
somewhere), and hence the @ symbol has been converted to %40, which makes the 
date look like 40k years into the future.

  "location": [ "https://tiny.cc/ietf-yang/\
   iana-crypt-hash%402014-08-06.yang" ],

If this location can be something like 
https://tiny.cc/ietf-yang/iana-crypt-h...@2014-08-06.yang or 
https://tiny.cc/ietf-yang/iana-crypt-h...@2.3.1.yang then I think that it would 
make these URLs more readable.

> 
> >
> > Perhaps reusing '@' is pragmatically the best choice.  We already have the
> constraint that a revision label cannot match the format of a revision-date
> anyway.
> >
> > Or, alternatively, if we really want to differentiate, then could '@@' work?
> 
> @@ was discussed, but would likely still trip up current tools that expect '@'
> followed by a revision date.  But if we're good with disrupting this, I'd 
> prefer
> we overload the single '@'.

I'm pretty sure that the existing tools will need to be updated regardless to 
understand the new version labels.  If the tool can't cope then a script needs 
to be used to strip the revision labels from the files, or rename them to their 
equivalent revision dates.

Thanks,
Rob


> 
> Joe
> 
> >
> > Rob
> > // As an author/contributor.
> >
> >> -Original Message-
> >> From: netmod  On Behalf Of Joe Clarke
> >> (jclarke)
> >> Sent: 14 September 2021 15:56
> >> To: netmod@ietf.org
> >> Subject: [netmod] Revision-labels within filenames
> >>
> >> Carsten raised a point at the mic at IETF111 that the chosen
> >> character '#' to separate the module name and module revision-label
> >> in filenames is problematic.  Currently, the YANG module versioning
> >> draft says that if you want to use revision-label within the
> >> filename, you use MODULE_NAME#REVISION_LABEL (e.g.,
> >> my-module#3.2.3.yang).  The reason for a new character is not to
> >> confuse existing tools that expect a revision- date to follow '@'.
> >>
> >> Carsten mentioned that '#' causes problem with shells and within URLs.
> >> While the position of the '#' in the name does not actually trigger
> >> issues with shells (it would if the filename began with a '#'), it
> >> does indeed cause issues in URLs if it's not encoded.  For example,
> >> https://example.com/my- module#3.2.3.yang will result in a 404 since
> >> a file "my-module" does not exist.  Jan also pointed out that '#'
> >> will cause issues in Makefiles, causing developers to have to escape them.
> >>
> >> On the last meeting, the authors and contributors spent some time
> >> running down other characters options, but all have their issues and
> >> require escaping or encoding.  The consensus on that call was that
> >> the #
> >> --> %23 URL encoding won't be as burdensome as initially thought.
> >> Platforms like GitHub (or its ilk) -- which are popular for hosting
> >> modules -- will do this encoding automatically and downloading the
> >> module will produce a filename with the un-encoded '#'.
> >> Additionally, yang-library location will have the encoded version of
> >> the URL (likely generated by tooling), which clients then download and
> typically get the un-encoded '#'.
&g

Re: [netmod] Revision-labels within filenames

[Rob Wilton (rwilton)]

Hi Joe,

Sorry, I was on PTO for the meeting where this was discussed.  I don't think 
that it is great that the character needs to be encoded in a URL.  It would 
seem to make references to YANG files in YANG packages a lot more awkward to 
read/write.

Perhaps reusing '@' is pragmatically the best choice.  We already have the 
constraint that a revision label cannot match the format of a revision-date 
anyway.

Or, alternatively, if we really want to differentiate, then could '@@' work?

Rob
// As an author/contributor.

> -Original Message-
> From: netmod  On Behalf Of Joe Clarke (jclarke)
> Sent: 14 September 2021 15:56
> To: netmod@ietf.org
> Subject: [netmod] Revision-labels within filenames
> 
> Carsten raised a point at the mic at IETF111 that the chosen character '#' to
> separate the module name and module revision-label in filenames is
> problematic.  Currently, the YANG module versioning draft says that if you
> want to use revision-label within the filename, you use
> MODULE_NAME#REVISION_LABEL (e.g., my-module#3.2.3.yang).  The reason
> for a new character is not to confuse existing tools that expect a revision-
> date to follow '@'.
> 
> Carsten mentioned that '#' causes problem with shells and within URLs.
> While the position of the '#' in the name does not actually trigger issues 
> with
> shells (it would if the filename began with a '#'), it does indeed cause 
> issues
> in URLs if it's not encoded.  For example, https://example.com/my-
> module#3.2.3.yang will result in a 404 since a file "my-module" does not
> exist.  Jan also pointed out that '#' will cause issues in Makefiles, causing
> developers to have to escape them.
> 
> On the last meeting, the authors and contributors spent some time running
> down other characters options, but all have their issues and require escaping
> or encoding.  The consensus on that call was that the #
> --> %23 URL encoding won't be as burdensome as initially thought.
> Platforms like GitHub (or its ilk) -- which are popular for hosting modules --
> will do this encoding automatically and downloading the module will produce
> a filename with the un-encoded '#'.  Additionally, yang-library location will
> have the encoded version of the URL (likely generated by tooling), which
> clients then download and typically get the un-encoded '#'.
> 
> Ultimately, we do not foresee filesystems cluttered with "%23" in filenames
> nor do we expect a great deal of manual typing of "%23".  Yes, the '#' will
> cause some additional developer work for use in Makefiles, but the authors
> feel this is acceptable given the overall impact of choosing another 
> character.
> 
> More details on this, including our run-down of other characters can be
> found in GitHub Issue #104 (https://github.com/netmod-wg/yang-ver-
> dt/issues/104).
> 
> Joe on behalf of the YANG versioning authors and contributors
> 
> ___
> 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-instance-file include-defaults leaf

[Rob Wilton (rwilton)]

Hi Balazs, Andy, Netmod,

Sorry for the delayed response.  I would still like to strength the description 
of the defaults.  E.g., RFC 6243 uses MUSTs rather than SHOULDs.

Hence, I have generated some proposed alternative descriptions, that are 
somewhat stricter, but also more generically focussed only on the default 
values.

With these definitions, I think that we could define the “include-defaults” 
default value to be “explicit”, since if the leaf if not included, then I think 
that this effectively what the meaning would be anyway.


In particular, I would propose changing the descriptions as follows:

   leaf includes-defaults {
 type enumeration {
   enum report-all {
 value 1;
 description
   "All data nodes SHOULD be included independent of
 any default values.";
   }
   enum trim {
 value 2;
 description
   "Data nodes that have a default defined and where
 the actual value is the default value SHOULD
 NOT be included.";
   }
   enum explicit {
 value 3;
 description
   "Data nodes that have a default defined and where
 the actual value is the default value SHOULD NOT be
 included. However, if the actual value was set by
 a NETCONF client or other management application
 by the way of an explicit management operation the
 data node SHOULD be included.";
   }
 }

Proposed:

   leaf includes-defaults {
 type enumeration {
   enum report-all {
 value 1;
 description
   "The instance data set includes all data nodes,
including those that contain the schema default.”;
   }
   enum trim {
 value 2;
 description
   "The instance data set excludes all data nodes
that contain the schema default.";
   }
   enum explicit {
 value 3;
 description
   "The instance data set may include some data nodes
that match the schema default and may exclude some
data nodes that match the schema default.”;
   }
 }
 description
   "This leaf provides an indication of how default data
is presented within an instance data set, modelled on
RFC 6243.

Interpretation of the use of defaults depends on the
context of what the instance data set represents.

E.g., if the instance data set represents configuration,
Then include-defaults aligns to the meaning of the
default-handling basic modes in RFC 6243.  If the
instance data set represents operational data from the
operational state datastore [RFC 8342], then
include-defaults aligns to the definition of that
datastore in RFC 8342.”;

Would text along these lines work?

Thanks,
Rob


From: Balázs Lengyel 
Sent: 28 July 2021 23:08
To: Rob Wilton (rwilton) ; Andy Bierman 
Cc: NetMod WG 
Subject: RE: [netmod] yang-instance-file include-defaults leaf

Hello Rob,
Removing the “default trim;” will address Andy’s comment.

Your in-use-values is very specific to one of the use-cases: 
reading/documenting operational values. It is not useful for the other 
use-cases. I think the “documenting operational datastore” use-case could be 
handled by indicating the includes-defaults=report-all. Case (i) would contain 
the value case (ii) will not.
Regards Balazs

From: Rob Wilton (rwilton) mailto:rwil...@cisco.com>>
Sent: 2021. július 27., kedd 17:38
To: Andy Bierman mailto:a...@yumaworks.com>>; Balázs 
Lengyel mailto:balazs.leng...@ericsson.com>>
Cc: NetMod WG mailto:netmod@ietf.org>>
Subject: RE: [netmod] yang-instance-file include-defaults leaf

Hi Andy, Balazs,

So, the reason that I want a flag to indicate whether default values are in use 
is because of this definition of operational in RFC 8342:

   Requests to retrieve nodes from  always return the value
   in use if the node exists, regardless of any default value specified
   in the YANG module.  If no value is returned for a given node, then
   this implies that the node is not used by the device.

It was written this way because otherwise a consumer of operational data cannot 
differentiate between:

(i)  This value is not present because it matches the default 
value specified in the YANG module, and

(ii)This value is not present because the server has failed to 
return it for some reason (e.g., perhaps the daemon that would have provided 
this value is down or not available, or perhaps it is a bug, or perhaps it is 
not implemented and is a 

Re: [netmod] yang-instance-file include-defaults leaf

[Rob Wilton (rwilton)]

Hi Andy,

The comment at the end of my email was:
“With this, I’m not sure whether we need the “includes-default” leaf currently 
specified in the draft, but if we do, then I would think that leaf should be 
entirely optional, i.e., without the default “trim”.”
Regards,
Rob


From: Andy Bierman 
Sent: 27 July 2021 18:00
To: Rob Wilton (rwilton) 
Cc: Balázs Lengyel ; NetMod WG 
Subject: Re: [netmod] yang-instance-file include-defaults leaf

Hi,

None of this addresses my point that a default value of "trim" is not 
appropriate.
Simply remove the default-stmt so that a missing leaf instance means that
no information is provided, rather than meaning defaults were added for 
basic-mode=trim.


Andy


On Tue, Jul 27, 2021 at 8:38 AM Rob Wilton (rwilton) 
mailto:rwil...@cisco.com>> wrote:
Hi Andy, Balazs,

So, the reason that I want a flag to indicate whether default values are in use 
is because of this definition of operational in RFC 8342:

   Requests to retrieve nodes from  always return the value
   in use if the node exists, regardless of any default value specified
   in the YANG module.  If no value is returned for a given node, then
   this implies that the node is not used by the device.

It was written this way because otherwise a consumer of operational data cannot 
differentiate between:

(i)  This value is not present because it matches the default 
value specified in the YANG module, and

(ii)This value is not present because the server has failed to 
return it for some reason (e.g., perhaps the daemon that would have provided 
this value is down or not available, or perhaps it is a bug, or perhaps it is 
not implemented and is a missing deviation).

So, I think that in some cases, the absence of a data node does not necessarily 
mean that the default value is in effect, and I wanted the instance-data 
document to be able to contain and correctly report this data.

I think that this behaviour could be captured by a single leaf.  Another way of 
articulating this would be:

leaf in-use-values {
  type boolean;
  default false;
  description
“Only if set to true, the absence of a value in the
 instance data for a given data node implies that the
node is not used rather than implicitly taking the
 default value specified by any corresponding
‘default’ statement specified in the YANG schema.”;
}

With this, I’m not sure whether we need the “includes-default” leaf currently 
specified in the draft, but if we do, then I would think that leaf should be 
entirely optional, i.e., without the default “trim”.

Regards,
Rob


From: Andy Bierman mailto:a...@yumaworks.com>>
Sent: 10 July 2021 17:41
To: Rob Wilton (rwilton) mailto:rwil...@cisco.com>>
Cc: NetMod WG mailto:netmod@ietf.org>>; Balázs Lengyel 
mailto:balazs.leng...@ericsson.com>>
Subject: Re: [netmod] yang-instance-file include-defaults leaf



On Fri, Jul 9, 2021 at 5:23 AM Rob Wilton (rwilton) 
mailto:rwil...@cisco.com>> wrote:
Andy,

Yes, when I suggested this, I was thinking that a boolean flag might be 
sufficient.  My point being that automatically filtering out default values 
isn’t always the right thing to do.



The solution is simple.
Get rid of the inappropriate "default trim" statement.

If the leaf is present then it identifies the basic-mode that was used to 
include defaults.
If not then the information is either not known, not applicable, or defaults 
were not added.

The "default" statement is a bug because there is no default basic-mode.
All of the basic-modes are in use in deployments and no camp has ever
been able to convince the others that theirs is right.


Andy

E.g., something along these lines:

leaf exclude-defaults {
  type boolean;
  default true;
  description
“Can be used to reduce the size of the content data file.

  When unset or set to true, data nodes that have a default defined and
  where the actual value is the default value are excluded from the content
  data.

  When set to false, data nodes with default value are not filtered, and
  may appear in the content data.”
}

Would this satisfy your concern?

Regards,
Rob


From: netmod mailto:netmod-boun...@ietf.org>> On 
Behalf Of Andy Bierman
Sent: 08 July 2021 18:16
To: NetMod WG mailto:netmod@ietf.org>>
Subject: [netmod] yang-instance-file include-defaults leaf

Hi,

The module has this object:


leaf includes-defaults {

   type enumeration {

 enum report-all {

   value 1;

   description

 "All data nodes SHOULD be included independent of

   any default values.";

 }

 enum trim {

   value 2;

   description

 "Data nodes that have a default defined and where

   the actual value is the default value SHOULD

   NOT be included.";

 }

 enum exp

Re: [netmod] yang-instance-file include-defaults leaf

[Rob Wilton (rwilton)]

Hi Andy, Balazs,

So, the reason that I want a flag to indicate whether default values are in use 
is because of this definition of operational in RFC 8342:

   Requests to retrieve nodes from  always return the value
   in use if the node exists, regardless of any default value specified
   in the YANG module.  If no value is returned for a given node, then
   this implies that the node is not used by the device.

It was written this way because otherwise a consumer of operational data cannot 
differentiate between:

(i)  This value is not present because it matches the default 
value specified in the YANG module, and

(ii)This value is not present because the server has failed to 
return it for some reason (e.g., perhaps the daemon that would have provided 
this value is down or not available, or perhaps it is a bug, or perhaps it is 
not implemented and is a missing deviation).

So, I think that in some cases, the absence of a data node does not necessarily 
mean that the default value is in effect, and I wanted the instance-data 
document to be able to contain and correctly report this data.

I think that this behaviour could be captured by a single leaf.  Another way of 
articulating this would be:

leaf in-use-values {
  type boolean;
  default false;
  description
“Only if set to true, the absence of a value in the
 instance data for a given data node implies that the
node is not used rather than implicitly taking the
 default value specified by any corresponding
‘default’ statement specified in the YANG schema.”;
}

With this, I’m not sure whether we need the “includes-default” leaf currently 
specified in the draft, but if we do, then I would think that leaf should be 
entirely optional, i.e., without the default “trim”.

Regards,
Rob


From: Andy Bierman 
Sent: 10 July 2021 17:41
To: Rob Wilton (rwilton) 
Cc: NetMod WG ; Balázs Lengyel 
Subject: Re: [netmod] yang-instance-file include-defaults leaf



On Fri, Jul 9, 2021 at 5:23 AM Rob Wilton (rwilton) 
mailto:rwil...@cisco.com>> wrote:
Andy,

Yes, when I suggested this, I was thinking that a boolean flag might be 
sufficient.  My point being that automatically filtering out default values 
isn’t always the right thing to do.



The solution is simple.
Get rid of the inappropriate "default trim" statement.

If the leaf is present then it identifies the basic-mode that was used to 
include defaults.
If not then the information is either not known, not applicable, or defaults 
were not added.

The "default" statement is a bug because there is no default basic-mode.
All of the basic-modes are in use in deployments and no camp has ever
been able to convince the others that theirs is right.


Andy

E.g., something along these lines:

leaf exclude-defaults {
  type boolean;
  default true;
  description
“Can be used to reduce the size of the content data file.

  When unset or set to true, data nodes that have a default defined and
  where the actual value is the default value are excluded from the content
  data.

  When set to false, data nodes with default value are not filtered, and
  may appear in the content data.”
}

Would this satisfy your concern?

Regards,
Rob


From: netmod mailto:netmod-boun...@ietf.org>> On 
Behalf Of Andy Bierman
Sent: 08 July 2021 18:16
To: NetMod WG mailto:netmod@ietf.org>>
Subject: [netmod] yang-instance-file include-defaults leaf

Hi,

The module has this object:


leaf includes-defaults {

   type enumeration {

 enum report-all {

   value 1;

   description

 "All data nodes SHOULD be included independent of

   any default values.";

 }

 enum trim {

   value 2;

   description

 "Data nodes that have a default defined and where

   the actual value is the default value SHOULD

   NOT be included.";

 }

 enum explicit {

   value 3;

   description

 "Data nodes that have a default defined and where

   the actual value is the default value SHOULD NOT be

   included. However, if the actual value was set by

   a NETCONF client or other management application

   by the way of an explicit management operation the

   data node SHOULD be included.";

 }

   }

   default trim;


The draft is extremely server-centric, like most IETF standards, but this
leaf is too server-centric to ignore.

Consider the possibility that the source of the file is NOT a NETCONF server.
This data may not be known so the default of "trim" may not be correct.

IMO this leaf is noise because any tool that knows the schema will also
know the YANG defaults.  The solution is incomplete anyway because
the presence of a leaf that has a YANG default 

Re: [netmod] Benjamin Kaduk's Discuss on draft-ietf-netmod-geo-location-08: (with DISCUSS and COMMENT)

[Rob Wilton (rwilton)]

Hi Ben, Chris,

I wanted to check whether this discussion has progressed at all.  This is the 
only remaining discuss after Roman has cleared his based on the IESG telechat 
discussion yesterday (thanks Roman).

Regards,
Rob


> -Original Message-
> From: netmod  On Behalf Of Christian Hopps
> Sent: 26 May 2021 23:05
> To: Benjamin Kaduk 
> Cc: netmod-cha...@ietf.org; The IESG ; netmod@ietf.org;
> draft-ietf-netmod-geo-locat...@ietf.org
> Subject: Re: [netmod] Benjamin Kaduk's Discuss on draft-ietf-netmod-geo-
> location-08: (with DISCUSS and COMMENT)
> 
> 
> Benjamin Kaduk via Datatracker  writes:
> 
> > Benjamin Kaduk has entered the following ballot position for
> > draft-ietf-netmod-geo-location-08: Discuss
> >
> > When responding, please keep the subject line intact and reply to all
> > email addresses included in the To and CC lines. (Feel free to cut this
> > introductory paragraph, however.)
> >
> >
> > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> > for more information about DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-netmod-geo-location/
> >
> >
> >
> > --
> > DISCUSS:
> > --
> >
> > I think we lack sufficient precision (forgive the pun) in how we talk
> > about "accuracy" and "precision".  Are the leafs that claim to specify
> > "accuracy" specifying a precision?  If so, the precision of a specific
> > measurement, the precision of the measurements that led to the creation
> > of the coordinate frame, or something else?  Are they doing so in
> > relative terms (e.g., percentage) or absolute terms (e.g., degrees and
> > meters)?  (There are "units" directives only for "height-accuracy" and
> > not the others.)  How can we we say that we'll have 16 fraction-digits of
> > precision for lat/long when the maximum accuracy we can say that a
> > geodetic-system has only gives us 6 fraction-digits for coord-accuracy?
> > When we say that the "precision of this measurement is indicated by the
> > reference-frame" is that the same thing as the relevant "-accuracy"
> > nodes, or something else?
> 
> Yes, the geodesic-datum is what defines the values and their accuracy. For
> the precision in the value we choose the fractional digits based on what
> might be needed, but not to prescribe anything. For decimal degrees e.g., we
> only need 100s values the rest can be left to the fractional portion.
> 
> > --
> > COMMENT:
> > --
> >
> > (I support Roman's Discuss.)
> >
> > Why do we only define velocity in terms of north/east/up, when we could
> > be in x/y/z coordinates where there is no clear "north" or "east"?
> >
> > It would have been helpful for the shepherd review to point to the
> > thread at
> >
> https://mailarchive.ietf.org/arch/msg/netmod/dA9olZfEVa3clGdfvNYEFXUE
> MJw/
> > that attempted to discuss the feedback from the yangdoctor review -- the
> > mail with the review itself got no direct replies.
> 
> This is a very edge case of this grouping meant really to handle something
> like continental drift with long stored values. One can keep drilling down on
> this particular velocity value seemingly forever, but then we aren't getting
> our work done. I think it's enough to say that if the usable values don't work
> for a use case at this point, then they don't work.
> 
> > Section 2.1
> >
> >In addition to the "geodetic-datum" value, we allow refining the
> >coordinate and height accuracy using "coord-accuracy" and "height-
> >
> > My understanding is that "refine" is a YANG keyword, and the current
> > module/tree structure does not seem consistent with this description
> > referring to use of the YANG keyword (since we can just set new values
> > directly without needing to "refine" the YANG structure itself).  A
> > different word here might be appropriate.
> 
> Ok changed to "overriding".
> 
> 
> >Finally, we define an optional feature which allows for changing the
> >system for which the above values are defined.  This optional feature
> >adds an "alternate-system" value to the reference frame.  This value
> >is normally not present which implies the natural universe is the
> >system.  The use of this value is intended to allow for creating
> >virtual realities or perhaps alternate coordinate systems.  The
> >definition of alternate systems is outside the scope of this
> >document.
> >
> > This paragraph doesn't really convince me that we need to include the
> > "alternate-system" capability in the proposed-standard version of this
> > YANG module at this time.
> 
> It doesn't hurt anything to include it and it was asked for by the 

Re: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format

[Rob Wilton (rwilton)]

Juergen,

Yes, I agree that is a better phrasing.

Thanks for suggesting it.
Rob


> -Original Message-
> From: Juergen Schoenwaelder 
> Sent: 09 July 2021 12:50
> To: Rob Wilton (rwilton) 
> Cc: Balázs Lengyel ; Andy Bierman
> ; netmod@ietf.org; Benoit Claise
> 
> Subject: Re: AD review of draft-ietf-netmod-yang-instance-file-format
> 
> On Fri, Jul 09, 2021 at 09:10:34AM +, Rob Wilton (rwilton) wrote:
> >
> > "YANG modules that are only required to satisfy import-only dependencies
> MAY be excluded from the leaf-list.  If they are excluded then the consumer
> of the instance data file can choose any versions of the YANG modules that
> satisfy the import dependency."
> >
> 
> Sorry, this wording is a bit wrong or possibly misleading. I assume
> your intention was this:
> 
> OLD:
> 
> If they are excluded then the consumer of the instance data file can
> choose any versions of the YANG modules that satisfy the import
> dependency.
> 
> NEW:
> 
> If they are excluded then the consumer of the instance data file has
> to apply the YANG language rules to resolve the imports.
> 
> /js
> 
> --
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 <https://www.jacobs-university.de/>

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

Re: [netmod] yang-instance-file include-defaults leaf

[Rob Wilton (rwilton)]

Andy,

Yes, when I suggested this, I was thinking that a boolean flag might be 
sufficient.  My point being that automatically filtering out default values 
isn’t always the right thing to do.

E.g., something along these lines:

leaf exclude-defaults {
  type boolean;
  default true;
  description
“Can be used to reduce the size of the content data file.

  When unset or set to true, data nodes that have a default defined and
  where the actual value is the default value are excluded from the content
  data.

  When set to false, data nodes with default value are not filtered, and
  may appear in the content data.”
}

Would this satisfy your concern?

Regards,
Rob


From: netmod  On Behalf Of Andy Bierman
Sent: 08 July 2021 18:16
To: NetMod WG 
Subject: [netmod] yang-instance-file include-defaults leaf

Hi,

The module has this object:


leaf includes-defaults {

   type enumeration {

 enum report-all {

   value 1;

   description

 "All data nodes SHOULD be included independent of

   any default values.";

 }

 enum trim {

   value 2;

   description

 "Data nodes that have a default defined and where

   the actual value is the default value SHOULD

   NOT be included.";

 }

 enum explicit {

   value 3;

   description

 "Data nodes that have a default defined and where

   the actual value is the default value SHOULD NOT be

   included. However, if the actual value was set by

   a NETCONF client or other management application

   by the way of an explicit management operation the

   data node SHOULD be included.";

 }

   }

   default trim;


The draft is extremely server-centric, like most IETF standards, but this
leaf is too server-centric to ignore.

Consider the possibility that the source of the file is NOT a NETCONF server.
This data may not be known so the default of "trim" may not be correct.

IMO this leaf is noise because any tool that knows the schema will also
know the YANG defaults.  The solution is incomplete anyway because
the presence of a leaf that has a YANG default is not enough.
The  "report-all-tagged" mode must be used to identify defaults.
IMO this leaf should be removed, but at least add an enum called "unknown".


Andy


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

Re: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format

[Rob Wilton (rwilton)]

Hi Andy,

Yes, the intention is that the YANG packages work covers exactly the use case 
that you describe below.

Regarding using JSON, my expectation is that the package would get consumed by 
tools as YANG instance data (i.e., similar to how yang library data is fetched 
from a running server).

I would think that extra metadata in the package definition could be expressed 
using regular YANG augmentations.

E.g., the simplified-inline schema for the instance data file containing the 
definition of a specific YANG package instance could be something like:
Ietf-yang-packages@...mailto:Ietf-yang-packages@...%3c/module>>
foo-yang-pkg-augmentations@...mailto:foo-yang-pkg-augmentations@...%3c/module>>

// Content data contains base package information and extra data that conforms 
to the additional schema elements defined by foo augmentations.


I’ve not thought about it, but perhaps YANG metadata annotations would also 
work (RFC 7952).

Regards,
Rob


From: Andy Bierman 
Sent: 08 July 2021 21:38
To: Rob Wilton (rwilton) 
Cc: Juergen Schoenwaelder ; Balázs 
Lengyel ; netmod@ietf.org; Benoit Claise 

Subject: Re: AD review of draft-ietf-netmod-yang-instance-file-format



On Thu, Jul 8, 2021 at 3:58 AM Rob Wilton (rwilton) 
mailto:rwil...@cisco.com>> wrote:
Hi Juergen,

I believe that having the simple form is worth the extra complexity.

I think that you are right to be concerned that it should not expand into a 
separate parallel format.  Overtime, I would like the simple form to be able to 
use revision labels instead of revision dates, but beyond this I think that it 
should just be a flat list of modules that defines the schema.  If a subset of 
features, or datastores, or import-only modules are needed then the YANG 
library version (or URIs) can and should be used.

Another example of where I expect it to be useful is in YANG packages.  Looking 
at the examples at the end of 
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-packages, then 
some of those files (which currently aren't defining any schema, but should) 
would almost double in size if they represented the schema inline using YANG 
library, which I think would make the files harder for humans to read/parse.  
Using URIs could help mitigate this, but then we would need to find a place to 
publish the file containing the YANG package schema (presumably somewhere in 
IANA), and it not obvious to me that adding the dependency on the URL is really 
as helpful.

https://datatracker.ietf.org/doc/html/draft-bierman-netmod-yang-conformance-00

An original use-case in my 2013 draft was to allow a vendor to define a package
that represented the entire server. Then the entire  and YANG library can
be replaced by one package-id in this case. This is reasonable for embedded 
devices
that have a fixed YANG library (expected for CORECONF).

BTW, the main reason I proposed the YANG syntax (your version has a JSON 
document)
is that these files are needed by automation tools, and YANG allows extensions
(and other things like augment). Automation tools cannot work without extensions
so not sure how JSON package files will be useful to them.


Regards,
Rob

Andy



> -Original Message-
> From: Juergen Schoenwaelder 
> mailto:j.schoenwael...@jacobs-university.de>>
> Sent: 08 July 2021 11:35
> To: Balázs Lengyel 
> mailto:balazs.leng...@ericsson.com>>
> Cc: Andy Bierman mailto:a...@yumaworks.com>>; Rob Wilton 
> (rwilton)
> mailto:rwil...@cisco.com>>; 
> netmod@ietf.org<mailto:netmod@ietf.org>; Benoit Claise
> mailto:benoit.cla...@huawei.com>>
> Subject: Re: AD review of draft-ietf-netmod-yang-instance-file-format
>
> The question I asked is "how much simpler is it and does that saving
> justify the introduction of a new rather limited format (that may risk
> to grow over time and become a second citizen)".
>
> So lets take your NACM example. ietf-netconf-acm@2018-02-14 imports
> from ietf-yang-types (at the time of publication that resolves to
> ietf-yang-types@2013-07-15. So the YANG Library instance data would
> roughly look this (please correct what I messed up, I am writing this
> by hand):
>
> 
>   
> m
> 
>   ietf-netconf-acm
>   2018-02-14
>   uri1
> 
> 
>   ietf-yang-types
>   uri2
>   
> 
>   
>   
> s
> m
>   
>   
> running
> s
>   
> 
>
> Yes, this is a bit longer, but it also conveys more information (note
> that your datastore leaf in the header would likely not be needed
> anymore).
>
> I am concerned that we start creating another format to define schemas
> that is very limited and people later come with extension proposals to
> address some of the limits and at the end we have multiple formats to
> maintain and deal with. So the questi

Re: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format

[Rob Wilton (rwilton)]

Hi Balazs,

Thanks.  That sounds fine.   Please can you add a sentence to the description 
of the simplified-inline in the YANG model to state this, which I think may be 
something like:

"YANG modules that are only required to satisfy import-only dependencies MAY be 
excluded from the leaf-list.  If they are excluded then the consumer of the 
instance data file can choose any versions of the YANG modules that satisfy the 
import dependency."

Regards,
Rob


> -Original Message-
> From: Balázs Lengyel 
> Sent: 09 July 2021 08:25
> To: Rob Wilton (rwilton) ; Juergen Schoenwaelder
> 
> Cc: Andy Bierman ; netmod@ietf.org; Benoit Claise
> 
> Subject: RE: AD review of draft-ietf-netmod-yang-instance-file-format
> 
> Hello,
> A single line is enough.
> As long as ietf-yang-types is change in a backward compatible way, I don't
> care which version of yang-types is imported. Also, we only use a single
> type 'yang:xpath1.0' from yang-types. The rules for this type  are described
> by W3C and not changing.
> Balazs
> 
> -Original Message-
> From: Rob Wilton (rwilton) 
> Sent: 2021. július 8., csütörtök 15:49
> To: Balázs Lengyel ; Juergen Schoenwaelder
> 
> Cc: Andy Bierman ; netmod@ietf.org; Benoit Claise
> 
> Subject: RE: AD review of draft-ietf-netmod-yang-instance-file-format
> 
> Hi Balazs,
> 
> Would your inline schema not also need to specify the ietf-yang-types
> dependency?
> 
> E.g., should it be:
> ietf-netconf-acm@2018-02-14
> ietf-yang-types@2013-07-15
> 
> Thanks,
> Rob
> 
> 
> > -Original Message-
> > From: Balázs Lengyel 
> > Sent: 08 July 2021 12:48
> > To: Rob Wilton (rwilton) ; Juergen Schoenwaelder
> > 
> > Cc: Andy Bierman ; netmod@ietf.org; Benoit
> Claise
> > 
> > Subject: RE: AD review of draft-ietf-netmod-yang-instance-file-format
> >
> > Hello,
> > I would like to keep simplified inline. If I ask my developers (not
> > experts) which one do they want? I am pretty sure they opt for the
> > shorter/simpler one.
> >
> > ietf-netconf-acm@2018-02-14
> >
> > OR
> >
> > 
> >   
> > m
> > 
> >   ietf-netconf-acm
> >       2018-02-14
> >   uri1
> > 
> > 
> >   ietf-yang-types
> >   uri2
> >   
> > 
> >   
> >   
> > s
> > m
> >   
> >   
> > running
> > s
> >   
> > 
> >
> > Regards Balazs
> >
> > -Original Message-
> > From: Rob Wilton (rwilton) 
> > Sent: 2021. július 8., csütörtök 12:59
> > To: Juergen Schoenwaelder ;
> > Balázs Lengyel 
> > Cc: Andy Bierman ; netmod@ietf.org; Benoit
> Claise
> > 
> > Subject: RE: AD review of draft-ietf-netmod-yang-instance-file-format
> >
> > Hi Juergen,
> >
> > I believe that having the simple form is worth the extra complexity.
> >
> > I think that you are right to be concerned that it should not expand
> > into a separate parallel format.  Overtime, I would like the simple
> > form to be able to use revision labels instead of revision dates, but
> > beyond this I think that it should just be a flat list of modules that
> > defines the schema.  If a subset of features, or datastores, or
> > import-only modules are needed then the YANG library version (or URIs)
> can
> and should be used.
> >
> > Another example of where I expect it to be useful is in YANG packages.
> > Looking at the examples at the end of
> > https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-packages,
> > then some of those files (which currently aren't defining any schema,
> > but should) would almost double in size if they represented the schema
> > inline using YANG library, which I think would make the files harder
> > for humans to read/parse.
> > Using URIs could help mitigate this, but then we would need to find a
> > place to publish the file containing the YANG package schema
> > (presumably somewhere in IANA), and it not obvious to me that adding
> > the dependency on the URL is really as helpful.
> >
> > Regards,
> > Rob
> >
> >
> > > -Original Message-
> > > From: Juergen Schoenwaelder 
> > > Sent: 08 July 2021 11:35
> > > To: Balázs Lengyel 
> > > Cc: Andy Bierman ; Rob Wilton (rwilton)
> > > ; netmod@ietf.org; Benoit Claise
> > > 
> > > Subject: Re: AD review of
> > > draft-ietf-netmod-yang-instance-file-format
> > >
> > > The question I asked is "how m

Re: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format

[Rob Wilton (rwilton)]

Hi Balazs,

Would your inline schema not also need to specify the ietf-yang-types 
dependency?

E.g., should it be:
ietf-netconf-acm@2018-02-14
ietf-yang-types@2013-07-15

Thanks,
Rob


> -Original Message-
> From: Balázs Lengyel 
> Sent: 08 July 2021 12:48
> To: Rob Wilton (rwilton) ; Juergen Schoenwaelder
> 
> Cc: Andy Bierman ; netmod@ietf.org; Benoit Claise
> 
> Subject: RE: AD review of draft-ietf-netmod-yang-instance-file-format
> 
> Hello,
> I would like to keep simplified inline. If I ask my developers (not experts)
> which one do they want? I am pretty sure they opt for the shorter/simpler
> one.
> 
> ietf-netconf-acm@2018-02-14
> 
> OR
> 
> 
>   
> m
> 
>   ietf-netconf-acm
>   2018-02-14
>   uri1
> 
> 
>   ietf-yang-types
>   uri2
>   
> 
>   
>   
> s
>     m
>   
>   
> running
> s
>   
> 
> 
> Regards Balazs
> 
> -Original Message-
> From: Rob Wilton (rwilton) 
> Sent: 2021. július 8., csütörtök 12:59
> To: Juergen Schoenwaelder ; Balázs
> Lengyel 
> Cc: Andy Bierman ; netmod@ietf.org; Benoit Claise
> 
> Subject: RE: AD review of draft-ietf-netmod-yang-instance-file-format
> 
> Hi Juergen,
> 
> I believe that having the simple form is worth the extra complexity.
> 
> I think that you are right to be concerned that it should not expand into a
> separate parallel format.  Overtime, I would like the simple form to be able
> to use revision labels instead of revision dates, but beyond this I think
> that it should just be a flat list of modules that defines the schema.  If a
> subset of features, or datastores, or import-only modules are needed then
> the YANG library version (or URIs) can and should be used.
> 
> Another example of where I expect it to be useful is in YANG packages.
> Looking at the examples at the end of
> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-packages, then
> some of those files (which currently aren't defining any schema, but should)
> would almost double in size if they represented the schema inline using
> YANG
> library, which I think would make the files harder for humans to read/parse.
> Using URIs could help mitigate this, but then we would need to find a place
> to publish the file containing the YANG package schema (presumably
> somewhere
> in IANA), and it not obvious to me that adding the dependency on the URL is
> really as helpful.
> 
> Regards,
> Rob
> 
> 
> > -Original Message-
> > From: Juergen Schoenwaelder 
> > Sent: 08 July 2021 11:35
> > To: Balázs Lengyel 
> > Cc: Andy Bierman ; Rob Wilton (rwilton)
> > ; netmod@ietf.org; Benoit Claise
> > 
> > Subject: Re: AD review of draft-ietf-netmod-yang-instance-file-format
> >
> > The question I asked is "how much simpler is it and does that saving
> > justify the introduction of a new rather limited format (that may risk
> > to grow over time and become a second citizen)".
> >
> > So lets take your NACM example. ietf-netconf-acm@2018-02-14 imports
> > from ietf-yang-types (at the time of publication that resolves to
> > ietf-yang-types@2013-07-15. So the YANG Library instance data would
> > roughly look this (please correct what I messed up, I am writing this
> > by hand):
> >
> > 
> >   
> > m
> > 
> >   ietf-netconf-acm
> >   2018-02-14
> >   uri1
> > 
> > 
> >   ietf-yang-types
> >   uri2
> >   
> > 
> >   
> >   
> > s
> > m
> >   
> >   
> > running
> > s
> >   
> > 
> >
> > Yes, this is a bit longer, but it also conveys more information (note
> > that your datastore leaf in the header would likely not be needed
> > anymore).
> >
> > I am concerned that we start creating another format to define schemas
> > that is very limited and people later come with extension proposals to
> > address some of the limits and at the end we have multiple formats to
> > maintain and deal with. So the question is whether people think this
> > is worth it. (Note that the felt overhead goes down with every
> > additional module used by your instance file, so the example above is
> > really the most extreme case. And if you have many modules defining
> > NACM rules, then you put the above into a separate file and use the
> > URI to point to the schema, no?
> >
> > /js
> >
> > On Thu, Jul 08, 2021 at 09:27:52AM +, Balázs Lengyel wrote:
> > > Hello Jurgen,

Re: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format

[Rob Wilton (rwilton)]

Hi Juergen,

I believe that having the simple form is worth the extra complexity.

I think that you are right to be concerned that it should not expand into a 
separate parallel format.  Overtime, I would like the simple form to be able to 
use revision labels instead of revision dates, but beyond this I think that it 
should just be a flat list of modules that defines the schema.  If a subset of 
features, or datastores, or import-only modules are needed then the YANG 
library version (or URIs) can and should be used.

Another example of where I expect it to be useful is in YANG packages.  Looking 
at the examples at the end of 
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-packages, then 
some of those files (which currently aren't defining any schema, but should) 
would almost double in size if they represented the schema inline using YANG 
library, which I think would make the files harder for humans to read/parse.  
Using URIs could help mitigate this, but then we would need to find a place to 
publish the file containing the YANG package schema (presumably somewhere in 
IANA), and it not obvious to me that adding the dependency on the URL is really 
as helpful.

Regards,
Rob


> -Original Message-
> From: Juergen Schoenwaelder 
> Sent: 08 July 2021 11:35
> To: Balázs Lengyel 
> Cc: Andy Bierman ; Rob Wilton (rwilton)
> ; netmod@ietf.org; Benoit Claise
> 
> Subject: Re: AD review of draft-ietf-netmod-yang-instance-file-format
> 
> The question I asked is "how much simpler is it and does that saving
> justify the introduction of a new rather limited format (that may risk
> to grow over time and become a second citizen)".
> 
> So lets take your NACM example. ietf-netconf-acm@2018-02-14 imports
> from ietf-yang-types (at the time of publication that resolves to
> ietf-yang-types@2013-07-15. So the YANG Library instance data would
> roughly look this (please correct what I messed up, I am writing this
> by hand):
> 
> 
>   
> m
> 
>   ietf-netconf-acm
>   2018-02-14
>   uri1
> 
> 
>   ietf-yang-types
>   uri2
>   
> 
>   
>   
> s
> m
>   
>   
> running
> s
>   
> 
> 
> Yes, this is a bit longer, but it also conveys more information (note
> that your datastore leaf in the header would likely not be needed
> anymore).
> 
> I am concerned that we start creating another format to define schemas
> that is very limited and people later come with extension proposals to
> address some of the limits and at the end we have multiple formats to
> maintain and deal with. So the question is whether people think this
> is worth it. (Note that the felt overhead goes down with every
> additional module used by your instance file, so the example above is
> really the most extreme case. And if you have many modules defining
> NACM rules, then you put the above into a separate file and use the
> URI to point to the schema, no?
> 
> /js
> 
> On Thu, Jul 08, 2021 at 09:27:52AM +, Balázs Lengyel wrote:
> > Hello Jurgen,
> > Inline:
> > This complex form of inline was requested and not objected earlier by
> other
> > reviewers.
> > Based on Rob's and others' proposal inline will be simplified to use only
> > ietf-yang-library@2019-01-04 as you suggest.
> >
> > Simplified inline:
> > In Ericsson we already use simplified inline a lot, it is the most common
> > format.
> > If you are providing data only for one or a few YANG modules and don't
> have,
> >
> > don't care about features/deviations it is the easiest, shortest method to
> > use.
> >  Our most common use-case is to provide preconfigured access control
> rules
> > for new nodes.
> > When a YANG modeler designs a new module, he immediately provides a
> set of
> > NACM rules
> > for the readOnly and the SystemAdmin roles/groups.
> > In this case you only need to specify "ietf-neconf-acm@2012-02-22" No
> > deviations, no features to indicate.
> > Regards Balazs
> >
> > Regards Balazs
> >
> > -Original Message-
> > From: Juergen Schoenwaelder 
> > Sent: 2021. július 7., szerda 21:26
> > To: Andy Bierman 
> > Cc: Balázs Lengyel ; Rob Wilton (rwilton)
> > ; netmod@ietf.org; Benoit Claise
> > 
> > Subject: Re: AD review of draft-ietf-netmod-yang-instance-file-format
> >
> > On Wed, Jul 07, 2021 at 11:12:06AM -0700, Andy Bierman wrote:
> > >
> > > > Inline method is needed, if you want to indicate that the file was
> > > > generated by someone who uses some YANG modules with deviations
> and
> > > > some features are no

Re: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format

[Rob Wilton (rwilton)]

Hi Balazs, Netmod WG,

Yes, broadly that would be acceptable to me. I would actually suggest keeping 
the "inline-module" leaf, since I think that makes it easier to extend the 
format in future and I think that it makes the file a bit more 
explicit/readable, but don't feel strongly on this latter point, so happy to 
leave this to the authors discretion.

I do understand Andy's point that having a single method of defining the schema 
makes interop easier, but I agree with your comment as for there being valid 
reasons why supporting these different formats is useful for the different use 
cases, and with the simplification of the inline schema method, I don't see 
supporting any of the defined schema options as being particularly hard to 
implement (i.e., beyond what is required to reading/understanding YANG library 
anyway).

As for the feature statement, I think that when it specified that it has to be 
communicated via "out-of-band documentation" then it doesn't seem to hold that 
much value.  E.g., it is probably just as easy for the out of band 
documentation to say that the provided file must use the simplified-inline 
schema definition, as it is to say the server doesn't support the 
inline-content-schema feature.

Given that there was WG consensus for defining 4 different schema encoding 
methods before, then does anyone in the WG strongly object to the changes that 
Balazs has proposed below?

Regards,
Rob


> -Original Message-
> From: Balázs Lengyel 
> Sent: 07 July 2021 08:49
> To: Rob Wilton (rwilton) ; 'netmod@ietf.org'
> ; a...@yumaworks.com; Juergen Schoenwaelder
> 
> Cc: Benoit Claise 
> Subject: RE: AD review of draft-ietf-netmod-yang-instance-file-format
> 
> Hello Rob,
> I would be happy to simplify the draft. Just we are restarting debates which
> were settled earlier. This can lead to a never-ending cycle.
> 
> So, I propose to:
> - remove all mention of the revision-label
> - remove the feature
> - for the inline method allow just ietf-yang-library@2019-01-04 as a
> _single_ file. This also means that I should remove the leaf inline-module
> as there is no need for it anymore. We know the single YANG module it
> would
> define.
> Is that acceptable?
> Regards Balazs
> 
> P.S. The feature was possible to use.
> It could be read from " out-of-band documentation" As indicated in the
> YANG
> module. For some use-cases (E.g. Use Case 2: Preloading Data) when the
> operator/designer is sending data to the server (not receiving it), it is
> useful to know whether the inline method is supported or not.
> 
> In case the file comes from the server the feature is less useful.
> 
> 
> -Original Message-
> From: Rob Wilton (rwilton) 
> Sent: 2021. július 6., kedd 17:15
> To: Balázs Lengyel ; 'netmod@ietf.org'
> ; a...@yumaworks.com; Juergen Schoenwaelder
> 
> Cc: Benoit Claise 
> Subject: RE: AD review of draft-ietf-netmod-yang-instance-file-format
> 
> Hi Balazs,
> 
> To follow up with our conversation earlier.  Andy and Juergen explicitly
> copied because they may have previously commented on these issues during
> WG
> LC.
> 
> I think that my comment regarding the "feature statement" and the
> flexibility of the inline-method are closely related.  I find the definition
> of the inline-content-schema to be so generic that it effectively allows
> anything.  E.g., the drafts would allow me to publish a file that has an
> inline-content-schema based on robs-random-schema-format@1.0.0, and it
> would
> be very difficult for consumers of the associated instance data file to
> understand the file schema.
> 
> Similarly, I find that allowing revision labels (as examples to avoid a
> normative reference to the module versioning draft), makes it hard for a
> generic implementation reader of a instance data file to know how to
> interpret an inline schema.  I suspect that this issue could cause problems
> in the IESG reviews.
> 
> Hence, my preference, for this RFC, that defines version 1 of the instance
> file format, would be to more heavily constrain how the schema is allowed to
> be specified in the inline-method.  Specifically, I think that it would be
> better to:
>  - restrict the inline schema to only be defined using
> ietf-yang-library@2019-01-04
>  - only allow revision-dates, not revision labels.
> 
> I would like to understand from Andy, whether he still thinks with these
> restrictions whether the inline-schema method should still be under a YANG
> feature statement?
> 
> If/when the revision labels draft gets standardized, and perhaps also after
> YANG packages, then we could do a bis version of this document to define a
> v2 of the instance file format that potentially allows YANG packages to

Re: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format

[Rob Wilton (rwilton)]

Hi Balazs,

To follow up with our conversation earlier.  Andy and Juergen explicitly copied 
because they may have previously commented on these issues during WG LC.

I think that my comment regarding the "feature statement" and the flexibility 
of the inline-method are closely related.  I find the definition of the 
inline-content-schema to be so generic that it effectively allows anything.  
E.g., the drafts would allow me to publish a file that has an 
inline-content-schema based on robs-random-schema-format@1.0.0, and it would be 
very difficult for consumers of the associated instance data file to understand 
the file schema.

Similarly, I find that allowing revision labels (as examples to avoid a 
normative reference to the module versioning draft), makes it hard for a 
generic implementation reader of a instance data file to know how to interpret 
an inline schema.  I suspect that this issue could cause problems in the IESG 
reviews.

Hence, my preference, for this RFC, that defines version 1 of the instance file 
format, would be to more heavily constrain how the schema is allowed to be 
specified in the inline-method.  Specifically, I think that it would be better 
to:
 - restrict the inline schema to only be defined using 
ietf-yang-library@2019-01-04
 - only allow revision-dates, not revision labels.

I would like to understand from Andy, whether he still thinks with these 
restrictions whether the inline-schema method should still be under a YANG 
feature statement?

If/when the revision labels draft gets standardized, and perhaps also after 
YANG packages, then we could do a bis version of this document to define a v2 
of the instance file format that potentially allows YANG packages to be used to 
define the schema, and potentially allows modules to be identified using 
revision labels as well as revision dates.

Balazs, I'm good with most of your proposed resolutions, but have answered one 
further question inline below.


> -Original Message-
> From: Balázs Lengyel 
> Sent: 05 July 2021 13:47
> To: 'netmod@ietf.org' ; Rob Wilton (rwilton)
> 
> Cc: Benoit Claise 
> Subject: FW: AD review of draft-ietf-netmod-yang-instance-file-format
> 
> Hello Rob,
> Thanks for the review.  Here are my answers below. I will also upload the
> new version asap.
> Regards Balazs
> ---
> Hi,
> 
> Here is my AD review of draft-ietf-netmod-yang-instance-file-format-13.
> 
> Thanks for this document, I think that it represents important useful work
> for advancing the YANG ecosystem.
> 
> This document is in good shape, and I mostly have minor comments but with
> a
> few more significant comments.
> 
> Main comments:
> 

> 
> 2.
> In the YANG Module:
>  feature inline-content-schema {
>description
>  "This feature indicates that inline content-schema
>   option is supported. Support for this feature might
>   be documented only via out-of-band documentation.";
>  }
> 
> What is the benefit of having 'inline-content-schema' as a feature?  It
> seems to potentially add complexity without any benefit, given that the
> device originating the instance data file would effectively choose whether
> to use the inline-content-schema, hence I suggest that it might be simpler
> just to remove the feature definition.
> BALAZS: This was explicitly requested earlier by a reviewer (Andy ?).
> The system can declare supported/not-supported in design documentation.
> In a use-case when a client or a design department is sending data to a
> server this is needed. E.g. in UC2, Preloading Default Configuration the
> designer preparing instance data, can decide to use or not use the
> inline-content-schema based on this.


> 
> 3.
> In the YANG Module:
> 
>   "case inline", description:
> The first item is either ietf-yang-library or
> some other YANG module that contains a list of
> YANG modules with their name, revision-date,
> supported-features, and deviations.
> The usage of revision '2019-01-04' of the
> 'ietf-yang-library' module MUST be supported.
> Using other modules, module versions MAY also
> be supported.
> 
> This seems to make interop for consumers of instance data files hard, since
> the schema can be defined by any arbitrary YANG module without updating
> this
> module.  I would suggest that it is safer to limit this to the two currently
> published versions of YANG library.
> BALAZS:  I fully agree, however this was explicitly requested by some
> reviewer earlier (Juergen ?) Shall I simplify this or not?
> 
> If

Re: [netmod] AD review of draft-ietf-netconf-notification-capabilities

[Rob Wilton (rwilton)]

Hi Benoit,

Thanks for accommodating my suggestions.  All resolutions look good to me.

I have a preference to hold shipping this document to IETF LC until the 
instance-data doc is also ready.  I think that it will help the IESG review if 
they have both documents available to review at the same time.  I assume that 
the updates to the instance-data doc are also in progress?

Thanks,
Rob


From: Benoit Claise 
Sent: 05 July 2021 11:53
To: Rob Wilton (rwilton) ; netmod@ietf.org; 
draft-ietf-netconf-notification-capabilit...@ietf.org
Cc: NetMod WG Chairs 
Subject: Re: AD review of draft-ietf-netconf-notification-capabilities

Hi Rob,

Thanks for your detailed review.
A new draft version has been posted.


URL:
https://www.ietf.org/archive/id/draft-ietf-netconf-notification-capabilities-17.txt

Status: 
https://datatracker.ietf.org/doc/draft-ietf-netconf-notification-capabilities/

Htmlized:   
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-notification-capabilities

Diff:   
https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-notification-capabilities-17

See the justifications below.
On 6/21/2021 10:45 AM, Rob Wilton (rwilton) wrote:

Hi,



Here is my AD review of draft-ietf-netconf-notification-capabiltiies-16



Thanks for this draft, sorry for the delay in reviewing.  It looks like it is 
in good shape.



I think that most of my comments are minor or cosmetic suggestions to 
potentially improve the phrasing of the text.





1.

Abstract:



   The module "ietf-system-capabilities" provides a placeholder

   structure that can be used to discover YANG related system

   capabilities for servers.  The module can be used to report

   capability information from the server at run-time or implementation-

   time, per the YANG Instance Data File Format.



Suggest "by making use of" rather than "per".
DONE.








2.

   1.  Introduction



   There is a need to publish this capability information as it is part

   of the contract between the server and client.



Suggest "contract" -> "API contract".
DONE








3.

   There is a need to publish this capability information as it is part

   of the contract between the server and client.  Examples include

   maximum size of data that can be stored or transferred, information

   about counters (whether a node supports "on-change" telemetry), etc.

   Such capabilities are often dependent on a vendor's implementation or

   the available resources at deployment.  Many such capabilities are

   specific to either the complete system, individual YANG datastores

   [RFC8342] or specific parts of the YANG schema, or even individual

   data nodes.  It is a goal of this document to provide a common way of

   representing such capabilities in a format that is:



Suggest: maximum -> the maximum

 "or specific" -> ", specific"
DONE








4.

   o  available in identical format both at implementation-time and run-

  time



Suggest: "in an identical", and a period at the end.
DONE








5.

   If the information is

   not documented in a way available to the NMS designer, but only as

   instance data from the network node once it is deployed, the NMS

   implementation will be delayed



Suggest: "way available" => "way that is readily available"
DONE








6.

   The network operator needs to plan his

   management practices and NMS implementation before he even decides to

   buy the specific network node type.



Suggest: "him" -> "their", "he even decides" -> "they decide"
DONE








7.

   Run-time information is needed:



Suggest: Run-time capability information is needed:
DONE.








8.

   o  to check that capability information provided earlier, at

  implementation-time is what the publisher has implemented.



Suggest: "at implementation-time, is"
DONE








9.

 To find a capability value for a specific data node in a

 specific datastore the user SHALL:



Please clarify that the capability value is selected by the relative path

to the datanode defining the capability.  i.e., the same name/path must be

used both under the system level and per datastore level capabilties.
NEW SENTENCE.


"When stating a specific capability, the relative path for any specific

capability must be the same under the system-capabilities container and

under the per-node-capabilities list: the same grouping for defining the

capabilities MUST be used. "

10.

2) If the datastore entry is found within that entry, process all

 per-node-capabilities entries in the order they appear in the list.

 The first entry that specifies the specific capability and has a

 node-selector selecting the specific data node defines the

 capability value.



I'm not sure this is required, but perha

Re: [netmod] [Anima] revising RFC8366 -- Re: BRSKI-AE enum issue -> empty, but what's he encoding ?

[Rob Wilton (rwilton)]

Hi Michael,

> -Original Message-
> From: Anima  On Behalf Of Michael Richardson
> Sent: 25 June 2021 21:41
> To: Toerless Eckert ; Fries, Steffen
> ; an...@ietf.org; netmod@ietf.org; Kent
> Watsen ; Rob Wilton (rwilton) 
> Subject: [Anima] revising RFC8366 -- Re: BRSKI-AE enum issue -> empty, but
> what's he encoding ?
> 
> 
> Toerless Eckert  wrote:
> tte> https://trac.ietf.org/trac/netmod/wiki/YANG_FAQ#when-use-empty
> tte> Is this the solution we are looking for ?
> 
> 
> here it the relevant text:
> 
> } The second situation is when you want to define an extensible
> enumeration,
> } as an alternative to the type "enumeration", which is not extensible by
> other
> } modules. For example if an enumeration is used:
> 
> } leaf protocol {
> }   type enumeration {
> } enum smtp;
> } enum pop3;
> }   }
> } }
> } and we want to add a new protocol 'imap4', it must be done by adding a
> new
> } enum in the module. But if we use a choice of type empty instead:
> 
> } container protocol {
> }   choice p {
> } case smtp { leaf smtp { type empty; } }
> } case pop3 { leaf pop3 { type empty; } }
> }   }
> } }
> } then another module can augment the first:
> }
> } augment /foo:protocol/p {
> }case imap4 { leaf imap4 { type empty; } }
> } }
> 
> Well, this seems to be exactly what we want.
> Do we get to put a description in there?
> can we put a value in so that our SID process works?
> (I imagine we'll have to hack pyang to make it cope, but...)
> 
> proceedural options:
> 
> 1) write this up as errata against 8366.  That seems a bit much for errata,
>but how much whisky does it cost to bribe an AD?

Depends how expensive the whisky is ;-)

More seriously though, this can't be done as an errata.

An RFC8366bis is the right option.  If the changes are minor then I may be able 
to ease the passage through the IESG, but I can't do much to affect the elapsed 
time.

Regards,
Rob


> 
> 2) write a formal "Updates" RFC8366 that just does the NEW/OLD version of
>updates, and that's it.
> 
> 3) do an entire RFC8366bis.
> 
> --
> Michael Richardson. o O ( IPv6 IøT consulting )
>Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
> 

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

[netmod] AD review of draft-ietf-netconf-notification-capabilities

[Rob Wilton (rwilton)]

Hi,

Here is my AD review of draft-ietf-netconf-notification-capabiltiies-16

Thanks for this draft, sorry for the delay in reviewing.  It looks like it is 
in good shape.

I think that most of my comments are minor or cosmetic suggestions to 
potentially improve the phrasing of the text.


1.
Abstract:

   The module "ietf-system-capabilities" provides a placeholder
   structure that can be used to discover YANG related system
   capabilities for servers.  The module can be used to report
   capability information from the server at run-time or implementation-
   time, per the YANG Instance Data File Format.

Suggest "by making use of" rather than "per".


2.
   1.  Introduction

   There is a need to publish this capability information as it is part
   of the contract between the server and client.

Suggest "contract" -> "API contract".


3.
   There is a need to publish this capability information as it is part
   of the contract between the server and client.  Examples include
   maximum size of data that can be stored or transferred, information
   about counters (whether a node supports "on-change" telemetry), etc.
   Such capabilities are often dependent on a vendor's implementation or
   the available resources at deployment.  Many such capabilities are
   specific to either the complete system, individual YANG datastores
   [RFC8342] or specific parts of the YANG schema, or even individual
   data nodes.  It is a goal of this document to provide a common way of
   representing such capabilities in a format that is:

Suggest: maximum -> the maximum
 "or specific" -> ", specific"


4.
   o  available in identical format both at implementation-time and run-
  time
  
Suggest: "in an identical", and a period at the end.


5.
   If the information is
   not documented in a way available to the NMS designer, but only as
   instance data from the network node once it is deployed, the NMS
   implementation will be delayed

Suggest: "way available" => "way that is readily available"


6.
   The network operator needs to plan his
   management practices and NMS implementation before he even decides to
   buy the specific network node type.

Suggest: "him" -> "their", "he even decides" -> "they decide"


7.
   Run-time information is needed:
   
Suggest: Run-time capability information is needed:


8.
   o  to check that capability information provided earlier, at
  implementation-time is what the publisher has implemented.

Suggest: "at implementation-time, is"


9.
 To find a capability value for a specific data node in a
 specific datastore the user SHALL:
 
Please clarify that the capability value is selected by the relative path
to the datanode defining the capability.  i.e., the same name/path must be
used both under the system level and per datastore level capabilties.


10.
 2) If the datastore entry is found within that entry, process all
 per-node-capabilities entries in the order they appear in the list.
 The first entry that specifies the specific capability and has a
 node-selector selecting the specific data node defines the
 capability value.

I'm not sure this is required, but perhaps consider adding text to make it clear
that longest path matching can be achieved by ordering more specific
matches before less specific matches.


11.
// augmentation point for system level capabilities
Suggest: "Augmentation ... capabilities."  I would also suggest using a block 
style
comment so this doesn't get lost.   


12. 
   Only one specific datastore can be specified
   e.g., ds:conventional is not allowed.";
   
Suggest changing to:

   Only specific datastores can be specified.
   E.g., ds:conventional, which represents a
   set of configuration datastores, must not be
   used";


13.
  description
"A method to select all or some nodes within a datastore.";

"some or all" would flow better.


14.
// augmentation point for datastore or data node level
// capabilities

Suggest: "Augmentation ... capabilities."  I would also suggest using a block 
style
comment so this doesn't get lost.


15.
5.2.  YANG Module (ietf-notification-capabilities)

  - capabilities related to the throughput of notification data
  the publisher can support. (Note that for a specific
  subscription the publisher MAY still allow only longer periods
  or smaller updates depending on e.g., actual load conditions.)
  
Suggest: "data that the publisher"
 "specific subscription, the"
 "still allow" -> "allow"
 "e.g., -> ", e.g., "


16.
   bit config-changes {
 description
   "The publisher is capable of sending
notifications for 'config false' nodes for the
relevant scope and subscription type.";
 

[netmod] AD review of draft-ietf-netmod-yang-instance-file-format

[Rob Wilton (rwilton)]

Hi,

Here is my AD review of draft-ietf-netmod-yang-instance-file-format-13.

Thanks for this document, I think that it represents important useful
work for advancing the YANG ecosystem.

This document is in good shape, and I mostly have minor comments but
with a few more significant comments.

Main comments:

1.
   An instance data set MAY contain data for any number of YANG modules;
   if needed it MAY carry the complete configuration and state data for
   a server.  Default values SHOULD NOT be included.

This document recommends that default values SHOULD NOT be included, but
there are cases where they are useful, and e.g., NMDA recommends that
"in-use" values (effectively including default values) are returned.
Further, there is no way for a consumer of the file to know whether
default values are included or not.

Hence, I would recommend that the instance-data-set defines an
"includes-defaults" leaf that indicates whether default values are
included in the dataset, the leaf can default to them not being included
in the dataset.

Further, I would suggest weakening "Default values SHOULD NOT be included" to
something like:
"Default values should be excluded where they do not provide additional
 useful data."


2.
In the YANG Module:
 feature inline-content-schema {
   description
 "This feature indicates that inline content-schema
  option is supported. Support for this feature might
  be documented only via out-of-band documentation.";
 }
 
What is the benefit of having 'inline-content-schema' as a feature?  It
seems to potentially add complexity without any benefit, given that the
device originating the instance data file would effectively choose whether
to use the inline-content-schema, hence I suggest that it might be simpler
just to remove the feature definition.
   
   
3.
In the YANG Module:

"case inline", description:
The first item is either ietf-yang-library or
some other YANG module that contains a list of
YANG modules with their name, revision-date,
supported-features, and deviations.
The usage of revision '2019-01-04' of the
'ietf-yang-library' module MUST be supported.
Using other modules, module versions MAY also
be supported.

This seems to make interop for consumers of instance data files hard, since
the schema can be defined by any arbitrary YANG module without updating this
module.  I would suggest that it is safer to limit this to the two currently
published versions of YANG library.

If additional modules are supported in future, then I think that it would be
safer to create a new version of this YANG module that documents what other
module formats can be used.


4.
In the YANG Module:
list "revision"

Is revision expected to be unique, if provided? If so, should this be
explicitly stated in the YANG module description?


5.
In the YANG Module:

Is an instance-data file allowed to contain both a revision and also a
timestamp?  If so, is there any constraints on the values.  If not, then would
it make sense to put them under a choice?


6.
References:
- RFC 6020 needs to be normative for the IANA YANG module registration.


Minor comments:

7. 
Abstract:

   There is a need to document data defined in YANG models when a live
   server is unavailable.  Data is often needed at design or
   implementation time or needed when a live running server is
   unavailable.  This document specifies a standard file format for YANG
   instance data, which follows the syntax and semantics of existing
   YANG models, and annotates it with metadata.
   
I suggest combining the first 2 sentences to:

There is a need to document data defined in YANG models at design,
implementation time or when a live server is unavailable.


8.
Sec 1. Introduction:
I suggest tweaking 2nd sentence to:
Data is often needed at design, implementation time, or when a live
running server is unavailable. 


9.   
Sec 2. Instance Data File Format:

   o  a default attribute as defined in [RFC6243] section 6. and in
  [RFC8040] section 4.8.9.
  
I would suggest putting default in quotes.  E.g., "a 'default' attribute, as 
defined ...".

For the two other bullets in the list, it might read better as
"metadata, as defined ..." and "origin metadata, as specified ..."


10.
Sec 2. Instance Data File Format:
instance-data-set-name ['@' ( revision-date / timestamp ) ]
(i) Possibly helpful to clarify that the revision-date and timestamp take the 
same format
 as they are encoded in the equivalent leaves in the YANG file. 
(ii) Would it be helpful to include an example without a revision-date?
(iii) I also note that no recommendation is made as to whether a date or 
timestamp is
   included (which I think is okay).


11.
Sec: 2.2 Examples
(i) Should the module name start with 

Re: [netmod] AD review of draft-ietf-netmod-nmda-diff-07

[Rob Wilton (rwilton)]

Hi Alex,

Thanks for the updates.

I missed that the IANA Considerations (sec 8), the reference should be to RFC 
6020 because that defines the YANG module registry, so please can you fix those 
two references from 7950 to 6020, and also add 6020 to the normative references.

A couple of minor nits on the latest version:

s/statistics/statistics./ (second paragraph in the intro)
s/incure/incur/

If you can please update these and ping me, I'll kick off the IETF LC.

Regards,
Rob


> -Original Message-
> From: Alexander L Clemm 
> Sent: 24 May 2021 20:09
> To: joel jaeggli ; Rob Wilton (rwilton)
> 
> Cc: NetMod WG Chairs ; draft-ietf-netmod-nmda-
> diff@ietf.org; netmod@ietf.org
> Subject: Re: AD review of draft-ietf-netmod-nmda-diff-07
> 
> Hi all,
> 
> Rob, thank you very much for your AD review!  We have just posted a new
> revision -08 taking your comments into account.  Please find attached
> and below my reponses to your comments (inline, delimited ;
> apologies for having taken so long).
> 
> Thanks
> 
> --- Alex
> 
> 
> 
> Hi,
> 
> Here is my AD review for draft-ietf-netmod-nmda-diff-07.  Apologies for
> the delay.
> 
> Thank you for writing this document, I think that it is useful, and
> looks like it is in good shape.
> 
> 
> Main comments:
> 
> 1. Should there be any text about how to find out what datastores are
> supported by a device?  E.g., pointing them to either YANG library, or
> protocol specific mechanisms in the case of RESTCONF.
> 
>  Reply: Note sure this is needed, and where we would even say it in
> the text.  Perhaps in the Introduction, where we introduce NMDA, a
> sentence of the sort: "To identify which datastores are supported by a
> given device, ...".
> If we wanted to this, one question is, how is this actually done? RFC
> 8342 makes no statement about this; it defines identities and typedefs
> but no capabilities or data model that would indicate the capabilities.
> 
> 
> 2. It might be helpful to add a comment about potential issues that
> could arise by comparing  to , i.e., additional
> differences could be reported due to inactive configuration and template
> processing between  and .
> 
>  Reply: I modified the last sentence in the fourth paragraph in the
> Introduction as follows:
> "This can be the case due to certain conditions not being met, certain
> parts of the configuration not propagating because considered inactive,
> resource dependencies not being resolved, or even implementation errors
> in corner conditions."
> I am not sure I understand the template processing issue; can you please
> elaborate?
> 
> 
> 3. I would prefer if 'exclude=origin' was in the reverse sense and
> perhaps called 'report-origin' instead.  With the reverse sense it seems
> to be safer if new datastores are defined, where otherwise the behaviour
> could end being under specified.
> 
>  Reply: Updated it per discussion in the mail thread.
> 
> 
> 
> 4. Should there be an option to filter on origin metadata?  E.g., only
> include values that come from intended.  Otherwise, things like IP
> addresses learned from DHCP may always turn up as differences.
> 
>  Reply: accepting proposed change per the email discussion
> Changed "exclude-origin" to "report-origin", with new description as
> follows:
>   leaf report-origin {
>     type empty;
>     description
>   "When this leaf is provided, origin metadata is
>    included as part of RPC output. When this leaf is
>    omitted, origin metadata in comparisons that involve
>     is by default omitted.";
>   }
> 
> Analogous change in the data model overview:
> "report-origin: When set, this parameter indicates that origin metadata
> should be included as part of RPC output. When this parameter is
> omitted, origin metadata in comparisons that involve  is by
> default omitted."
> 
> Updated also the output parameter description of "differences" accordingly:
> 
> Previous:
> When the target datastore is , "origin" metadata is
> included as part of the patch.
> New:
> When the target datastore is  and the input parameter
> "report-origin" is set, "origin" metadata is included as part of the patch.
> 
> Also updated the examples:
> 
> New RPC request (NETCONF):
> 
>      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
>      xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores">
>     ds:operational
>     ds:intended
>     
>          xmlns:if="urn:ietf:params:xml:ns:yang:ietf-interfaces">
>   /if:interfa

Re: [netmod] [Technical Errata Reported] RFC7950 (6570)

[Rob Wilton (rwilton)]

I agree.

I'll leave this a couple of days in case anyone else wants to express an 
opinion, but assuming that I hear no dissenting voices, I'll verify it.

Regards,
Rob


> -Original Message-
> From: Martin Björklund 
> Sent: 04 May 2021 12:59
> To: rfc-edi...@rfc-editor.org
> Cc: war...@kumari.net; Rob Wilton (rwilton) ;
> joe...@bogus.com; kent+i...@watsen.net; lber...@labn.net; netmod@ietf.org
> Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6570)
> 
> Hi,
> 
> This errata is correct and should be verified.
> 
> 
> /martin
> 
> 
> RFC Errata System  wrote:
> > The following errata report has been submitted for RFC7950,
> > "The YANG 1.1 Data Modeling Language".
> >
> > --
> > You may review the report below and at:
> > https://www.rfc-editor.org/errata/eid6570
> >
> > --
> > Type: Technical
> > Reported by: Jernej Tuljak 
> >
> > Section: 11
> >
> > Original Text
> > -
> >o  New typedefs, groupings, rpcs, notifications, extensions,
> >   features, and identities may be added.
> >
> > Corrected Text
> > --
> >o  New typedefs, groupings, rpcs, actions, notifications,
> >   extensions, features, and identities may be added.
> >
> > Notes
> > -
> > The original text unintentionally fails to mention actions. A definition
> in a published module may be revised by adding actions to this definition.
> >
> > Instructions:
> > -
> > This erratum is currently posted as "Reported". If necessary, please
> > use "Reply All" to discuss whether it should be verified or
> > rejected. When a decision is reached, the verifying party
> > can log in to change the status and edit the report, if necessary.
> >
> > --
> > RFC7950 (draft-ietf-netmod-rfc6020bis-14)
> > --
> > Title   : The YANG 1.1 Data Modeling Language
> > Publication Date: August 2016
> > Author(s)   : M. Bjorklund, Ed.
> > Category: PROPOSED STANDARD
> > Source  : Network Modeling
> > Area: Operations and Management
> > Stream  : IETF
> > Verifying Party : IESG
> >
> > ___
> > 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] Network Modeling (Concluded WG) ???

[Rob Wilton (rwilton)]

Hi Balazs,

I think that you can rest easy - Netmod has not been closed.

The link below looks fine now for me.  Are you still seeing the same page?

I presume that it was just a transient bug on the tools.ietf.org pages, and I 
would generally trust the datatracker pages over the "tools" ones.

Regards,
Rob


From: netmod  On Behalf Of Balázs Lengyel
Sent: 26 April 2021 07:47
To: 'netmod@ietf.org' 
Subject: [netmod] Network Modeling (Concluded WG) ???

Hello,
This is what I found today on the https://tools.ietf.org/wg/netmod/

Netmod Status Pages
Network Modeling (Concluded WG)

What? Why ?
Regards Balazs

--
Balazs LengyelSenior Specialist   
Ericsson Hungary Ltd.
Mobile: +36-70-330-7909  email: 
balazs.leng...@ericsson.com

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

Thank you and the WG for your work on this document.  I've requested IETF LC.

Regards,
Rob


From: Christian Hopps 
Sent: 16 April 2021 22:30
To: Rob Wilton (rwilton) 
Cc: netmod@ietf.org; draft-ietf-netmod-geo-location@ietf.org
Subject: Re: AD review of draft-ietf-netmod-geo-location-07

Just posted this new version.


On Apr 13, 2021, at 6:08 AM, Rob Wilton (rwilton) 
mailto:rwil...@cisco.com>> wrote:

Hi Chris,


-Original Message-
From: Christian Hopps mailto:cho...@chopps.org>>
Sent: 13 April 2021 03:38
To: Rob Wilton (rwilton) mailto:rwil...@cisco.com>>
Cc: Christian Hopps mailto:cho...@chopps.org>>; 
netmod@ietf.org<mailto:netmod@ietf.org>; draft-ietf-
netmod-geo-location@ietf.org<mailto: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) 
mailto:rwil...@cisco.com>>
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  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 

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 loc

[netmod] Client validation text [was RE: YANG Versioning Weekly Call Minutes - 2021-04-06]

[Rob Wilton (rwilton)]

// As a contributor

Hi Jason, all,

In yesterday's meeting there was a discussion on this text, and Joe pointed out 
that any sensible client must validate its input.

   While incoming configuration data is checked according to YANG
   constraints, constraints on state data sent by the server MAY or MAY
   NOT be enforced.  The following guidelines are provided for client
   application designers to allow a smooth interworking with servers.

   o  A client MUST tolerate any data received (or not received) without
  crashing.

   o  A client MUST be able to discard any data that is not part of the
  model but is sent by the server additionally (e.g.  XML elements
  or attributes, JSON properties).

   o  A client SHOULD be able to handle valid parts of a received data
  set even if it discards other parts as invalid.

   o  A client SHOULD be able to handle data that is outside the
  valuespace defined, as long as it is of the same basic type.

   o  A client SHOULD be prepared to handle more items for a list or
  leaf-list than what is defined by the model.

Based on Joe's comments, I suggest that this text could potentially be written 
as something like:




   Client applications are expected to perform sanity checking of data

   received from a server and to handle unexpected or missing data

   gracefully, e.g., this could include ignoring unexpected data, or

   logging unexpected values for further analysis.  Clients SHOULD NOT

   discard an entire response from a server because some data contained

   within the response is not expected.  Examples of well-encoded but

   unexpected data received from a server may include:



   o  Values that are outside the value space of a data node defined

  in the YANG schema, but that are within the value space of the

  underlying base type, e.g., if the value represents an unexpected

  error condition on the server.



   o  Additional data nodes, e.g., if the server implements a

  different, but compatible, version of a YANG module.



   o  A greater or lesser number of list or leaf-list items than the

  permitted range defined in the YANG module.



   o  Non mandatory data nodes that are sometimes missing from the

  response.  Noting that the server is expected to deviate any data

  nodes for which it will never return values for.



   o  Values that do not conform to the semantic constraints of the schema.



   o  Additional YANG meta data in the encoding (e.g., XML elements or

  attributes, JSON properties).



   NMDA [RFC 8342], section 5.3, provides additional constraints on the

   data that a server can return from the operational state datastore.


Thanks,
Rob



From: netmod  On Behalf Of Sterne, Jason (Nokia - 
CA/Ottawa)
Sent: 06 April 2021 15:10
To: netmod@ietf.org
Subject: [netmod] YANG Versioning Weekly Call Minutes - 2021-04-06

YANG Versioning Weekly Call Minutes - 2021-04-06

Focus for this meeting was going through Jason's review comments for section 
"3.1.2 Backwards-compatibility rules for config false and output data" of 
https://tools.ietf.org/html/draft-ietf-netmod-yang-module-versioning-02.

(A)
Valuespace:
- value space (with a space between the words): use 7950 meaning/definition 
(remove the definition in our draft)
- make "must" its own bullet
- don't particularly address "description"
- Balazs propose updated text

(B)
replace this:

"an additional state leaf can easily be discarded"

with this:

"the presence of an unexpected state leaf is not typically a problem and may be 
ignored by the client"

(C)
replace "config=false data" in the 1st paragraph with the following (and keep 
the quotes - that is how RFC8342 presents it):
"config false" data

(D)
Lots of debate about the "client" bullets in 3.1.2.  Didn't conclude.  Perhaps 
just summarize and say clients need to sanitize data (give examples of data 
they might get, values outside range)

ACTION: focus on reviewing section 3.1.2

--
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] AD review of draft-ietf-netmod-nmda-diff-07

[Rob Wilton (rwilton)]

Hi Andy,

FYI, this issue was discussed in the Netmod session on Friday.

My interpretation of the chairs position is 
(https://www.youtube.com/watch?v=glLcpQ9kpv0, starts at 6.10) is : As long as 
the WG is copied on my AD review comments and proposed changes (which they have 
been), then the WG has the opportunity to comment or object to the proposed 
changes if they wish, and lack of comment from the WG is taken as a tacit 
acceptance of the proposed changes.

Given this, I think that the authors can apply the mark ups based on the 
agreements below (and my original nits), republish, and then hopefully we 
should be ready to progress this to IETF LC.

Regards,
Rob


From: Andy Bierman 
Sent: 05 March 2021 18:46
To: Rob Wilton (rwilton) 
Cc: NetMod WG Chairs ; joel jaeggli ; 
draft-ietf-netmod-nmda-diff@ietf.org; netmod@ietf.org
Subject: Re: AD review of draft-ietf-netmod-nmda-diff-07



On Fri, Mar 5, 2021 at 10:18 AM Rob Wilton (rwilton) 
mailto:rwil...@cisco.com>> wrote:
Hi Andy,

I’m not sure which one you think is s a design change:  Do you mean issue 3 or 
issue 4 below?

I see that my response to issue 4 may not have been clear, so to clarify:

By “okay”, I meant, that I am okay with how it is written in the current draft. 
 My presumption is that this could be addressed as a future version of the 
module if this turns out be an issue, or vendors can define their own 
augmentation if needed.

If you think issue 3 is a design change that requires WG consensus that I will 
leave it to the WG chairs to decide if they wish to issue a consensus call for 
it.



The change:

   Current: default is to include origin attributes and client adds 
exclude-origin leaf to turn this off
   Proposed: default is to exclude origin attributes and client adds 
report-origin leaf to turn this on
Also, report-origin has an if-feature because origin support in NMDA is 
optional.

I have no objections to this proposal.
My point all along has been that this is not my decision to make, it is a WG 
decision.
It does not seem that there are any objections to making this change.


Regards,
Rob


Andy


From: Andy Bierman mailto:a...@yumaworks.com>>
Sent: 05 March 2021 16:36
To: Rob Wilton (rwilton) mailto:rwil...@cisco.com>>
Cc: joel jaeggli mailto:joe...@gmail.com>>; 
draft-ietf-netmod-nmda-diff@ietf.org<mailto:draft-ietf-netmod-nmda-diff@ietf.org>;
 netmod@ietf.org<mailto:netmod@ietf.org>
Subject: Re: AD review of draft-ietf-netmod-nmda-diff-07



On Fri, Mar 5, 2021 at 5:58 AM Rob Wilton (rwilton) 
mailto:rwil...@cisco.com>> wrote:
Hi Andy, authors,



I think you mean to address this to the WG since the redesign issues need WG 
approval.
I have no objections to any changes.


Andy

Sorry for the long delay in replying.

Please see [RW] inline below …


From: Andy Bierman mailto:a...@yumaworks.com>>
Sent: 30 October 2020 01:43
To: joel jaeggli mailto:joe...@gmail.com>>
Cc: Rob Wilton (rwilton) mailto:rwil...@cisco.com>>; 
draft-ietf-netmod-nmda-diff@ietf.org<mailto:draft-ietf-netmod-nmda-diff@ietf.org>;
 netmod@ietf.org<mailto:netmod@ietf.org>
Subject: Re: AD review of draft-ietf-netmod-nmda-diff-07



On Thu, Oct 29, 2020 at 6:09 PM joel jaeggli 
mailto:joe...@gmail.com>> wrote:
Rob,

These seem like reasonable suggestions.

Lets see what the authors say.

Thanks for this
joel

On Thu, Oct 29, 2020 at 6:47 AM Rob Wilton (rwilton) 
mailto:rwil...@cisco.com>> wrote:
Hi,

Here is my AD review for draft-ietf-netmod-nmda-diff-07.  Apologies for the 
delay.

Thank you for writing this document, I think that it is useful, and looks like 
it is in good shape.


Main comments:

1. Should there be any text about how to find out what datastores are supported 
by a device?  E.g., pointing them to either YANG library, or protocol specific 
mechanisms in the case of RESTCONF.

Do you have a section in mind and suggested text?
[RW]
Perhaps somewhere in section 4, either as part of the description of source, or 
perhaps before the parameters are described.

Proposed text:
“A client can discover which datastores a server supports by reading YANG 
library [RFC 8525] from the operational state datastore.”



2. It might be helpful to add a comment about potential issues that could arise 
by comparing  to , i.e., additional differences could be 
reported due to inactive configuration and template processing between 
 and .

Do you have a section in mind and suggested text?
You mean if there are differences between  and 
then a diff between  and  will not be the same
as a diff between  and .?

[RW]
My main concern is that if you have template expansion then comparing  
and  may not really give a meaningful comparison, since  
is pre-template expansion, and  (and ) are both post 
template expansion.

I would suggest putting some text in section 4 or perhaps the YANG module.

Perhaps some text, something like:

  “Clients shou

Re: [netmod] Question about validation of the running datastore

[Rob Wilton (rwilton)]

Hi Italo,

For NMDA:

  *   The device should accept the configuration if it is plausible that the 
configuration could be applied.  E.g., if you had the right linecards inserted, 
with the right optics, and the configuration won't exhaust the available 
resources.
  *   Once the device has accepted the configuration, then it should make its 
best effort to apply that configuration, but some of that configuration could 
fail to be applied for many reasons.  E.g., hardware missing or failed, process 
bugs/failures, out of resources.
  *   The operational datastore always reports exactly what the device is 
actually doing.   I.e., the operator is expected to monitor the operational 
state of the device to determine whether the device is working correctly (which 
includes whether the expected configuration has been successfully applied).  
Enhancements like NMDA-diff may help achieve this.

Conversely, the device can decide that the configuration is not valid and then 
reject the configuration change (with appropriate errors being reported).  Then 
the configuration and operational state of the device is left unchanged.

Regards,
Rob

// As a contributor.


From: netmod  On Behalf Of Italo Busi
Sent: 08 March 2021 20:24
To: 'netmod@ietf.org' 
Subject: [netmod] Question about validation of the running datastore

Hi all,

I have a doubt about how and when the configured data in the running datastore 
can be validated.

According to section 5.1.3 of RFC8342:

MUST always be a valid configuration data tree, as defined
   in Section 8.1 of [RFC7950].

In some cases, there are some complex semantic validation rules which cannot be 
encoded in the rules defined in Section 8.1 of [RFC7950].

In this case the configuration is, from a semantic perspective, invalid and 
cannot be applied, even if the configuration data tree is valid as defined in 
Section 8.1 of [RFC7950].

It is not clear to me what is the expected behavior of the system when the 
client provides such a configuration.

One possible option is that the system accepts that configuration but it does 
not apply it. In this case, the configuration is written in the  
datastore, but never applied in the  datastore.

Another possible option is that the system accepts that configuration, it does 
not apply it but returns to the client a warning message. Also in this case, 
the configuration is written in the  datastore, but never applied in 
the  datastore.

A third option is that the system rejects that configuration and returns to the 
client an error message. In this case, the configuration is not written in the 
 datastore and thus never applied in the  datastore.

I am wondering whether all these implementation options are allowed or whether 
there are some standard requirements/restrictions on some of them.

Thanks, Italo

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

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

[Rob Wilton (rwilton)]

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 '[ -@\[-~]*';

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

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.

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.


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


   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.


   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.


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


   At
   least two options are available to YANG models that wish to use this
   grouping with objects that are changing location frequently in non-
   simple ways, they can add additional motion data to their model
   directly, or if the application allows it can require more frequent
   queries to keep the location data current.
=>
   At
   least two options are available to YANG models that wish to use this
   grouping with objects that are changing location frequently in non-
   simple ways.  They can add additional motion data to their model
   directly.  Or, if the application allows, it can require more frequent
   queries to keep the location data current.


When coord-accuracy is specified it overrides the geodetic-datum implied
accuracy.
=>
When coord-accuracy is specified, it overrides the geodetic-datum implied
accuracy.


When specified it overrides the geodetic-datum implied default.
=>
When specified, it overrides the geodetic-datum implied default. 


indicated by the reference-frame value.
=>
indicated by the reference-frame.


For a formula to convert these values to speed and heading see
this modules defining document RFC .";
=>
For a formula to convert these values to speed and heading see
RFC .";


You have "truth-north" and "truth north" and "true-north".  Should
these all be "true north"?

   YANG grouping using decimal64 values rather than strings.  For the
   relative height cases the application doing the transformation is
   expected to have the data available to transform the relative height
   into an absolute height which can then be expressed using the YANG
   grouping.
=>
   YANG grouping using decimal64 values rather than strings.  For the
   relative height cases, the application doing the transformation is
   expected to have the data available to transform the relative height
   into an absolute height, which can then be expressed using the YANG
   grouping.


Grammar Warnings (generated by a tool):
Draft Text:
Indeed it is easy to imagine a network or 

Re: [netmod] AD review of draft-ietf-netmod-nmda-diff-07

[Rob Wilton (rwilton)]

Hi Andy,

I’m not sure which one you think is s a design change:  Do you mean issue 3 or 
issue 4 below?

I see that my response to issue 4 may not have been clear, so to clarify:

By “okay”, I meant, that I am okay with how it is written in the current draft. 
 My presumption is that this could be addressed as a future version of the 
module if this turns out be an issue, or vendors can define their own 
augmentation if needed.

If you think issue 3 is a design change that requires WG consensus that I will 
leave it to the WG chairs to decide if they wish to issue a consensus call for 
it.

Regards,
Rob


From: Andy Bierman 
Sent: 05 March 2021 16:36
To: Rob Wilton (rwilton) 
Cc: joel jaeggli ; draft-ietf-netmod-nmda-diff@ietf.org; 
netmod@ietf.org
Subject: Re: AD review of draft-ietf-netmod-nmda-diff-07



On Fri, Mar 5, 2021 at 5:58 AM Rob Wilton (rwilton) 
mailto:rwil...@cisco.com>> wrote:
Hi Andy, authors,



I think you mean to address this to the WG since the redesign issues need WG 
approval.
I have no objections to any changes.


Andy

Sorry for the long delay in replying.

Please see [RW] inline below …


From: Andy Bierman mailto:a...@yumaworks.com>>
Sent: 30 October 2020 01:43
To: joel jaeggli mailto:joe...@gmail.com>>
Cc: Rob Wilton (rwilton) mailto:rwil...@cisco.com>>; 
draft-ietf-netmod-nmda-diff@ietf.org<mailto:draft-ietf-netmod-nmda-diff@ietf.org>;
 netmod@ietf.org<mailto:netmod@ietf.org>
Subject: Re: AD review of draft-ietf-netmod-nmda-diff-07



On Thu, Oct 29, 2020 at 6:09 PM joel jaeggli 
mailto:joe...@gmail.com>> wrote:
Rob,

These seem like reasonable suggestions.

Lets see what the authors say.

Thanks for this
joel

On Thu, Oct 29, 2020 at 6:47 AM Rob Wilton (rwilton) 
mailto:rwil...@cisco.com>> wrote:
Hi,

Here is my AD review for draft-ietf-netmod-nmda-diff-07.  Apologies for the 
delay.

Thank you for writing this document, I think that it is useful, and looks like 
it is in good shape.


Main comments:

1. Should there be any text about how to find out what datastores are supported 
by a device?  E.g., pointing them to either YANG library, or protocol specific 
mechanisms in the case of RESTCONF.

Do you have a section in mind and suggested text?
[RW]
Perhaps somewhere in section 4, either as part of the description of source, or 
perhaps before the parameters are described.

Proposed text:
“A client can discover which datastores a server supports by reading YANG 
library [RFC 8525] from the operational state datastore.”



2. It might be helpful to add a comment about potential issues that could arise 
by comparing  to , i.e., additional differences could be 
reported due to inactive configuration and template processing between 
 and .

Do you have a section in mind and suggested text?
You mean if there are differences between  and 
then a diff between  and  will not be the same
as a diff between  and .?

[RW]
My main concern is that if you have template expansion then comparing  
and  may not really give a meaningful comparison, since  
is pre-template expansion, and  (and ) are both post 
template expansion.

I would suggest putting some text in section 4 or perhaps the YANG module.

Perhaps some text, something like:

  “Clients should to be aware that comparing  to  will 
report differences due to any configuration transformation (e.g., inactive 
configuration, or the expansion of templates) between the  and 
 datastores.  In these scenarios, clients may get a more useful 
result by comparing the  and  datastores instead.”




3. I would prefer if 'exclude=origin' was in the reverse sense and perhaps 
called 'report-origin' instead.  With the reverse sense it seems to be safer if 
new datastores are defined, where otherwise the behaviour could end being under 
specified.


IMO the WG already designed the features so if the functional requirements have 
changed
then the draft should go back to the WG for changes and new WG consensus calls.
[RW]

I don’t see this as really changing the functional requirements, but just 
changing the default sense and name of an API parameter.  Although, given my 
comments below “with-origin” might be better than “report-origin”.

In RFC 8526, the “with-origin” parameter is off by default, and origin metadata 
is only included when the parameter is included.  This keyword is also under a 
feature.

So, changing the parameter name to “with-origin” and putting it under 
”if-feature ietf-netconf-nmda:origin”, and making the default off, would make 
the definition more consistent with RFC 8526.



4. Should there be an option to filter on origin metadata?  E.g., only include 
values that come from intended.  Otherwise, things like IP addresses learned 
from DHCP may always turn up as differences.

IMO the WG already designed the features so if the functional requirements have 
changedthen the draft should go back to the WG for changes and new WG consensus 
calls.

[RW]

Okay.

Regar

Re: [netmod] AD review of draft-ietf-netmod-nmda-diff-07

[Rob Wilton (rwilton)]

Hi Andy, authors,

Sorry for the long delay in replying.

Please see [RW] inline below …


From: Andy Bierman mailto:a...@yumaworks.com>>
Sent: 30 October 2020 01:43
To: joel jaeggli mailto:joe...@gmail.com>>
Cc: Rob Wilton (rwilton) mailto:rwil...@cisco.com>>; 
draft-ietf-netmod-nmda-diff@ietf.org<mailto:draft-ietf-netmod-nmda-diff@ietf.org>;
 netmod@ietf.org<mailto:netmod@ietf.org>
Subject: Re: AD review of draft-ietf-netmod-nmda-diff-07



On Thu, Oct 29, 2020 at 6:09 PM joel jaeggli 
mailto:joe...@gmail.com>> wrote:
Rob,

These seem like reasonable suggestions.

Lets see what the authors say.

Thanks for this
joel

On Thu, Oct 29, 2020 at 6:47 AM Rob Wilton (rwilton) 
mailto:rwil...@cisco.com>> wrote:
Hi,

Here is my AD review for draft-ietf-netmod-nmda-diff-07.  Apologies for the 
delay.

Thank you for writing this document, I think that it is useful, and looks like 
it is in good shape.


Main comments:

1. Should there be any text about how to find out what datastores are supported 
by a device?  E.g., pointing them to either YANG library, or protocol specific 
mechanisms in the case of RESTCONF.

Do you have a section in mind and suggested text?
[RW]
Perhaps somewhere in section 4, either as part of the description of source, or 
perhaps before the parameters are described.

Proposed text:
“A client can discover which datastores a server supports by reading YANG 
library [RFC 8525] from the operational state datastore.”



2. It might be helpful to add a comment about potential issues that could arise 
by comparing  to , i.e., additional differences could be 
reported due to inactive configuration and template processing between 
 and .

Do you have a section in mind and suggested text?
You mean if there are differences between  and 
then a diff between  and  will not be the same
as a diff between  and .?

[RW]
My main concern is that if you have template expansion then comparing  
and  may not really give a meaningful comparison, since  
is pre-template expansion, and  (and ) are both post 
template expansion.

I would suggest putting some text in section 4 or perhaps the YANG module.

Perhaps some text, something like:

  “Clients should to be aware that comparing  to  will 
report differences due to any configuration transformation (e.g., inactive 
configuration, or the expansion of templates) between the  and 
 datastores.  In these scenarios, clients may get a more useful 
result by comparing the  and  datastores instead.”




3. I would prefer if 'exclude=origin' was in the reverse sense and perhaps 
called 'report-origin' instead.  With the reverse sense it seems to be safer if 
new datastores are defined, where otherwise the behaviour could end being under 
specified.


IMO the WG already designed the features so if the functional requirements have 
changed
then the draft should go back to the WG for changes and new WG consensus calls.
[RW]

I don’t see this as really changing the functional requirements, but just 
changing the default sense and name of an API parameter.  Although, given my 
comments below “with-origin” might be better than “report-origin”.

In RFC 8526, the “with-origin” parameter is off by default, and origin metadata 
is only included when the parameter is included.  This keyword is also under a 
feature.

So, changing the parameter name to “with-origin” and putting it under 
”if-feature ietf-netconf-nmda:origin”, and making the default off, would make 
the definition more consistent with RFC 8526.



4. Should there be an option to filter on origin metadata?  E.g., only include 
values that come from intended.  Otherwise, things like IP addresses learned 
from DHCP may always turn up as differences.

IMO the WG already designed the features so if the functional requirements have 
changedthen the draft should go back to the WG for changes and new WG consensus 
calls.

[RW]

Okay.

Regards,
Rob



5. I'm not that keen on the "Possible Future Extensions" section of an RFC.  
Personally, I would prefer that this section is deleted, but if you wish to 
retain it, then please can you move it to an appendix.

OK with me to remove it



Andy



I've also included some minor comments inline below, and some nits at the end:

Abstract

   This document defines an RPC operation to compare management
   datastores that comply with the NMDA architecture.

The abstract is perhaps somewhat terse.  Perhaps:

This document defines a YANG RPC operation to compare the
contents of network management datastores that comply with
the NMDA architecture and return the differences in the
YANG-Patch format.


1.  Introduction

   The revised Network Management Datastore Architecture (NMDA)
   [RFC8342] introduces a set of new datastores that each hold YANG-
   defined data [RFC7950] and represent a different "viewpoint" on the
   data that is maintained by a server.  New YANG 

Re: [netmod] Proposed IANA text for YANG Module Versioning and Semver Drafts

[Rob Wilton (rwilton)]

Hi Lada,

Thanks for the feedback.  I agree that we should think about this.

Looking at those slides, it also asks the question as to whether a YANG file 
derived from an IANA registry entry should ever differ.  I agree with the 
answer proposed in those slides: I.e., the two should always be kept in sync, 
even if that ends causing a non-backwards-compatible change to the YANG module.

But my question is whether we should add any text to the IANA section of this 
document to make this explicit?


Regarding your second issue:

I agree that unifying the definitions between IANA and YANG would be ideal, but 
I'm not sure whether that will be feasible in the short term.

draft-ietf-netmod-yang-module-versioning-02 tries to encourage stricter YANG 
definitions of deprecated and obsolete (both in the rules defining what is 
backwards compatible, and also new YANG library leaves to advertise that the 
server conforms to the stricter behaviour):

I.e., the behaviour that it is trying to encourage is:
 -  deprecated nodes must be implemented (just like status current nodes), or 
otherwise explicitly deviated if they are not supported.
 -  obsolete nodes must not be implemented.

The reason that stricter semantics are proposed is so that the client can know 
the exact schema supported by the server rather than having to guess whether or 
not deprecated or obsolete nodes are implemented.

I read the IANA definition of deprecated as being "SHOULD NOT implement", and 
YANG doesn't today have a status value that maps well to.  In particular, YANG 
doesn't currently have a way to express to a client that a deprecated node that 
"should not be implemented" actually is still implemented by a server.  E.g., 
the reverse semantics of "deviate not-supported".

Hence, I wonder YANG shouldn't end up with 4 levels of status (better name 
required for 'really-deprecated'):

 (1) "current":   Current.  Must implement or deviate not-supported
 (2) "deprecated":Going away. Should implement, but may deviate 
not-supported
 (3) "really-deprecated": Really going away.  Should not implement, but may 
deviate to indicate it is still supported.
 (4) "obsolete":  Dead.  Must not implement.  Cannot deviate.

Note, that a separate status "experimental" has been proposed previously as an 
addition for YANG Next, tracked by 
https://github.com/netmod-wg/yang-next/issues/59

The IANA version of "deprecated" would map to (3) "really-deprecated" in YANG, 
whilst the IANA definition of "obsolete" matches the YANG definition of 
"obsolete".

But this can't really be solved until we have a new revision of YANG.

Rob


> -----Original Message-
> From: netmod  On Behalf Of Ladislav Lhotka
> Sent: 03 March 2021 12:19
> To: Rob Wilton (rwilton) ;
> netmod@ietf.org
> Subject: Re: [netmod] Proposed IANA text for YANG Module Versioning and
> Semver Drafts
> 
> Hi Rob,
> 
> I don't know whether this has been discussed, but one issue that might
> need to be addressed is the difference between IANA and YANG in the
> definitions of "obsolete" and "deprecated" - the details are here (slide
> 5):
> 
> https://datatracker.ietf.org/meeting/104/materials/slides-104-dnsop-sessa-
> yang-types-for-dns-classes-and-resource-record-types-00
> 
> The best solution would be to unify the definitions. If this is not
> possible (in a short term), then it is IMO necessary to mark an entry that
> is made obsolete or deprecated in an IANA registry as "obsolete" in the
> YANG module.
> 
> Lada
> 
> "Rob Wilton \(rwilton\)"  writes:
> 
> > Hi,
> >
> > // As an individual contributor
> >
> > We discussed proposed IANA text at the last NETMOD interim on the YANG
> versioning work.  Tracked by issue https://github.com/netmod-wg/yang-ver-
> dt/issues/59
> >
> > I had the action of updating the text based on comments received in the
> interim meeting and then sending that text to the list.
> >
> > The proposed text is below (that is in the current published versions of
> both drafts).  If the WG has no objections to this text, then the planned
> next step is to ask IANA for an early review of this text.
> >
> >
> > IANA section in draft-ietf-netmod-yang-module-versioning-02:
> >
> > 11.2.  Guidance for versioning in IANA maintained YANG modules
> >
> >Note for IANA (to be removed by the RFC editor): Please check that
> >the registries and IANA YANG modules are referenced in the
> >appropriate way.
> >
> >IANA is responsible for maintaining and versioning YANG modules that
> >are derived from other IANA registries.  For example, "iana-if-
> >ty