Re: [netmod] Follow-up: impact of changing an import statement

[Reshad Rahman (rrahman)]

Inline.

On 2020-08-01, 2:47 PM, "Reshad Rahman (rrahman)"  wrote:

On 2020-08-01, 1:39 AM, "Juergen Schoenwaelder" 
 wrote:

On Sat, Aug 01, 2020 at 02:51:54AM +0000, Reshad Rahman (rrahman) wrote:
> WG,
> 
> Following up from the discussions during NETMOD meeting on Thursday. 
One of the main open topics is what to do when an import stmt is changed, for 
example
> 
>   1.  Module A (1.0.0) imports module B using “2.0.0 or derived”. 
There is no version 3+ for module B so module A uses 2.Y.Z
>   2.  A new revision 3.0.0 of module B is created AND there is a 
change in module A to import module B using “3.0.0 or derived”.

What does "2.0.0 or derived" mean? Does it mean (i) any module >=
2.0.0 or does it mean (ii) any (module >= 2.0.0 && < 3.0.0)?
It currently means (i). Kent asked about this on slide 12 during the 
meeting stating he believes it should be (ii). My response was that this has 
been discussed among the authors and there's no  agreement among us right now. 
I think Rob W has an AI from the WG meeting on this.
 This is the email from Rob on this topic:
https://mailarchive.ietf.org/arch/msg/netmod/dGQX4jeQWjPT1TqPjk8_yjVJhFM/

Regards,
Reshad.

> Authors/contributors have discussed 2 options and right now we don’t 
have unanimity:
> 
>   1.  Option A: depending on the impact on the importing module A, 
the import-stmt is deemed BC or NBC. E.g. if the only NBC change in the  
imported module is  to a type which the importing module does NOT use, that’s a 
BC change for the importing module.
>   2.  Option B: consider the import-stmt change as a BC change and 
resolve this elsewhere e.g. YANG-Packages or YANG-Library.

Whether a change is BC or not always depends on which definitions have
changed, how they have changed, and how these definitions are used. So
the answer very likely must be option 1. Option 2 also seems to push
the problem elsewhere (packages, library) without providing the
details.
I agree.

We have discussed a bit how this would be done but that was right before 
the IETF. With YANG-Packages, the package version would be modified accordingly 
and a client would need to do schema comparison. 

Thanks for the input,
Reshad.

/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] Follow-up: impact of changing an import statement

[Reshad Rahman (rrahman)]

Inline.

On 2020-08-01, 2:47 PM, "Reshad Rahman (rrahman)"  wrote:

On 2020-08-01, 1:39 AM, "Juergen Schoenwaelder" 
 wrote:

On Sat, Aug 01, 2020 at 02:51:54AM +0000, Reshad Rahman (rrahman) wrote:
> WG,
> 
> Following up from the discussions during NETMOD meeting on Thursday. 
One of the main open topics is what to do when an import stmt is changed, for 
example
> 
>   1.  Module A (1.0.0) imports module B using “2.0.0 or derived”. 
There is no version 3+ for module B so module A uses 2.Y.Z
>   2.  A new revision 3.0.0 of module B is created AND there is a 
change in module A to import module B using “3.0.0 or derived”.

What does "2.0.0 or derived" mean? Does it mean (i) any module >=
2.0.0 or does it mean (ii) any (module >= 2.0.0 && < 3.0.0)?
It currently means (i). Kent asked about this on slide 12 during the 
meeting stating he believes it should be (ii). My response was that this has 
been discussed among the authors and there's no  agreement among us right now. 
I think Rob W has an AI from the WG meeting on this.
This is the email from Rob on this topic.

Regards,
Reshad.

> Authors/contributors have discussed 2 options and right now we don’t 
have unanimity:
> 
>   1.  Option A: depending on the impact on the importing module A, 
the import-stmt is deemed BC or NBC. E.g. if the only NBC change in the  
imported module is  to a type which the importing module does NOT use, that’s a 
BC change for the importing module.
>   2.  Option B: consider the import-stmt change as a BC change and 
resolve this elsewhere e.g. YANG-Packages or YANG-Library.

Whether a change is BC or not always depends on which definitions have
changed, how they have changed, and how these definitions are used. So
the answer very likely must be option 1. Option 2 also seems to push
the problem elsewhere (packages, library) without providing the
details.
I agree.

We have discussed a bit how this would be done but that was right before 
the IETF. With YANG-Packages, the package version would be modified accordingly 
and a client would need to do schema comparison. 

Thanks for the input,
Reshad.

/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-doctors] Yangdoctors last call review of draft-ietf-netmod-nmda-diff-04

[Reshad Rahman (rrahman)]

Looks good, no new issues.

Regards,
Reshad.

From: Yingzhen Qu 
Date: Friday, September 25, 2020 at 11:49 AM
To: "Reshad Rahman (rrahman)" , Alexander L Clemm 
, "yang-doct...@ietf.org" 
Cc: "last-c...@ietf.org" , "netmod@ietf.org" 
, "draft-ietf-netmod-nmda-diff@ietf.org" 

Subject: Re: [yang-doctors] [netmod] Yangdoctors last call review of 
draft-ietf-netmod-nmda-diff-04

Hi Reshad,

Thanks for the link to verify JSON, it’s very helpful.

I’ve uploaded version -07. Please let me know if you have any comments.

Thanks,
Yingzhen

From: "Reshad Rahman (rrahman)" 
Date: Friday, September 25, 2020 at 8:34 AM
To: Yingzhen Qu , Alexander L Clemm 
, "yang-doct...@ietf.org" 
Cc: "last-c...@ietf.org" , "netmod@ietf.org" 
, "draft-ietf-netmod-nmda-diff@ietf.org" 

Subject: Re: [yang-doctors] [netmod] Yangdoctors last call review of 
draft-ietf-netmod-nmda-diff-04

Hi Yingzhen,

The JSON example doesn’t seem ok because it only contains 1 edit entry. To 
confirm I went to 
https://jsonlint.com/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjsonlint.com%2F=02%7C01%7Cyingzhen.qu%40futurewei.com%7Ce9baa6c2aeee43ef078d08d8616872b9%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637366448544225811=1MfsJLUqKllzfkYO6xAYy%2FZlOq5Prq6MHVXi1sa6VW4%3D=0>
 and it 1st complained about missing comma after the } for source-value and 
when I fixed that it complained about Duplicate key ‘edit-id’.

FYI, the JSON block below passed the lint check.

Regards,
Reshad.

  {
  "ietf-nmda-compare:output": {
"differences": {
  "ietf-yang-patch:yang-patch": {
"patch-id": "interface status",
"comment": "diff between intended (source) and 
operational",
"edit": [
 {
"edit-id": "1",
"operation": "replace",
"target": 
"/ietf-interfaces:interface=eth0/enabled",
"value": {
  "ietf-interfaces:interface/enabled": 
"false"
},
"source-value": {
  "ietf-interfaces:interface/enabled": 
"true",
  "@ietf-interfaces:interface/enabled": 
{
"ietf-origin:origin": 
"ietf-origin:learned"
  }
}
  },
  {
"edit-id": "2",
"operation": "create",
"target": 
"/ietf-interfaces:interface=eth0/description",
"value": {
  
"ietf-interface:interface/description": "ip interface"
}
  }
]
  }
}
  }
  }

From: Yingzhen Qu 
Date: Friday, September 25, 2020 at 10:47 AM
To: "Reshad Rahman (rrahman)" , Alexander L Clemm 
, "yang-doct...@ietf.org" 
Cc: "last-c...@ietf.org" , "netmod@ietf.org" 
, "draft-ietf-netmod-nmda-diff@ietf.org" 

Subject: Re: [yang-doctors] [netmod] Yangdoctors last call review of 
draft-ietf-netmod-nmda-diff-04

Hi Reshad,

Thank you for the example. I modified the XML example as you suggested. The 
JSON example looks ok to me. Also fixed the nit to reference RFC 6991.

New generated txt file attached, please let me know if you see more issues.

Thanks,
Yingzhen

From: "Reshad Rahman (rrahman)" 
Date: Friday, September 25, 2020 at 4:58 AM
To: Yingzhen Qu , Alexander L Clemm 
, "yang-doct...@ietf.org" 
Cc: "last-c...@ietf.org" , "netmod@ietf.org" 
, "draft-ietf-netmod-nmda-diff@ietf.org" 

Subject: Re: [yang-doctors] [netmod] Yangdoctors last call review of 
draft-ietf-netmod-nmda-diff-04

Hi Yingzhen,

Yes I believe this part is broken, since you have multiple edit-id elements for 
1 edit element, below is the YANG snippet from RFC8072.

 list edit {
       key edit-id;
   ordered-by user;

   leaf edit-id {
 type string;
 description
   "Arbitrary string index for the edit.
Error messages

Re: [netmod] [yang-doctors] Yangdoctors last call review of draft-ietf-netmod-nmda-diff-04

[Reshad Rahman (rrahman)]

Hi Yingzhen,

The JSON example doesn’t seem ok because it only contains 1 edit entry. To 
confirm I went to https://jsonlint.com/ and it 1st complained about missing 
comma after the } for source-value and when I fixed that it complained about 
Duplicate key ‘edit-id’.

FYI, the JSON block below passed the lint check.

Regards,
Reshad.

  {
  "ietf-nmda-compare:output": {
"differences": {
  "ietf-yang-patch:yang-patch": {
"patch-id": "interface status",
"comment": "diff between intended (source) and 
operational",
"edit": [
 {
"edit-id": "1",
"operation": "replace",
"target": 
"/ietf-interfaces:interface=eth0/enabled",
"value": {
  "ietf-interfaces:interface/enabled": 
"false"
},
"source-value": {
  "ietf-interfaces:interface/enabled": 
"true",
  "@ietf-interfaces:interface/enabled": 
{
"ietf-origin:origin": 
"ietf-origin:learned"
  }
}
  },
  {
"edit-id": "2",
"operation": "create",
"target": 
"/ietf-interfaces:interface=eth0/description",
"value": {
              
"ietf-interface:interface/description": "ip interface"
}
  }
]
  }
}
  }
  }

From: Yingzhen Qu 
Date: Friday, September 25, 2020 at 10:47 AM
To: "Reshad Rahman (rrahman)" , Alexander L Clemm 
, "yang-doct...@ietf.org" 
Cc: "last-c...@ietf.org" , "netmod@ietf.org" 
, "draft-ietf-netmod-nmda-diff@ietf.org" 

Subject: Re: [yang-doctors] [netmod] Yangdoctors last call review of 
draft-ietf-netmod-nmda-diff-04

Hi Reshad,

Thank you for the example. I modified the XML example as you suggested. The 
JSON example looks ok to me. Also fixed the nit to reference RFC 6991.

New generated txt file attached, please let me know if you see more issues.

Thanks,
Yingzhen

From: "Reshad Rahman (rrahman)" 
Date: Friday, September 25, 2020 at 4:58 AM
To: Yingzhen Qu , Alexander L Clemm 
, "yang-doct...@ietf.org" 
Cc: "last-c...@ietf.org" , "netmod@ietf.org" 
, "draft-ietf-netmod-nmda-diff@ietf.org" 

Subject: Re: [yang-doctors] [netmod] Yangdoctors last call review of 
draft-ietf-netmod-nmda-diff-04

Hi Yingzhen,

Yes I believe this part is broken, since you have multiple edit-id elements for 
1 edit element, below is the YANG snippet from RFC8072.

 list edit {
   key edit-id;
   ordered-by user;

   leaf edit-id {
 type string;
         description
   "Arbitrary string index for the edit.
Error messages returned by the server that pertain
to a specific edit will be identified by this value.";
   }


If you take a look at A.1.1 of RFC8072, there is an example with multiple edit 
elements.

Regards,
Reshad.

From: Yingzhen Qu 
Date: Friday, September 25, 2020 at 1:07 AM
To: "Reshad Rahman (rrahman)" , Alexander L Clemm 
, "yang-doct...@ietf.org" 
Cc: "last-c...@ietf.org" , "netmod@ietf.org" 
, "draft-ietf-netmod-nmda-diff@ietf.org" 

Subject: Re: [yang-doctors] [netmod] Yangdoctors last call review of 
draft-ietf-netmod-nmda-diff-04

Hi Reshad,

Thank you for your review.

About the example, in RFC 8072, in the list “edit”, each edit is identified by 
“edit-id”. So the example looks like:

   1
   …..
   2
  ….

Do you mean this part is broken?

Thanks,
Yingzhen

From: "Reshad Rahman (rrahman)" 
Date: Tuesday, September 22, 2020 at 6:07 AM
To: Alexander L Clemm , "yang-doct...@ietf.org" 

Cc: "last-c...@ietf.org" , "netmod@ietf.org" 
, "draft-ietf-netmod-nmda-diff@ietf.org" 

Subject: Re: [yang-doctors] [netmod] Yangdoctors last call review of 
draft-ietf-netmod-nmda-diff-04
Resent-From: 
Resent-To:

Re: [netmod] [yang-doctors] Yangdoctors last call review of draft-ietf-netmod-nmda-diff-04

[Reshad Rahman (rrahman)]

Hi Yingzhen,

Yes I believe this part is broken, since you have multiple edit-id elements for 
1 edit element, below is the YANG snippet from RFC8072.

 list edit {
   key edit-id;
   ordered-by user;

   leaf edit-id {
 type string;
 description
   "Arbitrary string index for the edit.
Error messages returned by the server that pertain
to a specific edit will be identified by this value.";
   }


If you take a look at A.1.1 of RFC8072, there is an example with multiple edit 
elements.

Regards,
Reshad.

From: Yingzhen Qu 
Date: Friday, September 25, 2020 at 1:07 AM
To: "Reshad Rahman (rrahman)" , Alexander L Clemm 
, "yang-doct...@ietf.org" 
Cc: "last-c...@ietf.org" , "netmod@ietf.org" 
, "draft-ietf-netmod-nmda-diff@ietf.org" 

Subject: Re: [yang-doctors] [netmod] Yangdoctors last call review of 
draft-ietf-netmod-nmda-diff-04

Hi Reshad,

Thank you for your review.

About the example, in RFC 8072, in the list “edit”, each edit is identified by 
“edit-id”. So the example looks like:

   1
   …..
   2
  ….

Do you mean this part is broken?

Thanks,
Yingzhen

From: "Reshad Rahman (rrahman)" 
Date: Tuesday, September 22, 2020 at 6:07 AM
To: Alexander L Clemm , "yang-doct...@ietf.org" 

Cc: "last-c...@ietf.org" , "netmod@ietf.org" 
, "draft-ietf-netmod-nmda-diff@ietf.org" 

Subject: Re: [yang-doctors] [netmod] Yangdoctors last call review of 
draft-ietf-netmod-nmda-diff-04
Resent-From: 
Resent-To: , , , 
, , , 
, , , Joel Jaeggli 
, 
Resent-Date: Tuesday, September 22, 2020 at 6:07 AM

Hi Alex,

Thank you for addressing my comments.

I checked rev-06, and I believe the XML and JSON output in the example is 
broken: there is a single “edit” element with multiple “edit-id” elements. I 
believe there should be multiple “edit” elements.

The only “nit” is that leaf-xpath-filter references 6021 instead of 6991 (as 
you correctly pointed out in your response).
   leaf xpath-filter {
 if-feature nc:xpath;
 type yang:xpath1.0;
 description
   "This parameter contains an XPath expression
identifying the portions of the target
datastore to retrieve.";
 reference "RFC 6021: Common YANG Data Types";
   }

> Issues
> 1.YANG model P8, for “leaf xpath-filter”, add 
> reference to RFC6021. There should also be a normative reference to RFC6021 
> (as per RFC8407)
 Thanks.  Adding reference to 6991 (as 6021 is obsoleted). 

Regards,
Reshad.

From: Alexander L Clemm 
Date: Friday, September 18, 2020 at 3:48 PM
To: "Reshad Rahman (rrahman)" , "yang-doct...@ietf.org" 

Cc: "last-c...@ietf.org" , "netmod@ietf.org" 
, "draft-ietf-netmod-nmda-diff....@ietf.org" 

Subject: Re: [yang-doctors] [netmod] Yangdoctors last call review of 
draft-ietf-netmod-nmda-diff-04


Thank you!

I just uploaded rev -06.

--- Alex
On 9/18/2020 12:47 PM, Reshad Rahman (rrahman) wrote:
Hi Alex,

This addresses my comment/concern.

Regards,
Reshad.

From: Alexander L Clemm <mailto:lud...@clemm.org>
Date: Friday, September 18, 2020 at 3:43 PM
To: "Reshad Rahman (rrahman)" <mailto:rrah...@cisco.com>, 
"yang-doct...@ietf.org"<mailto:yang-doct...@ietf.org> 
<mailto:yang-doct...@ietf.org>
Cc: "last-c...@ietf.org"<mailto:last-c...@ietf.org> 
<mailto:last-c...@ietf.org>, 
"netmod@ietf.org"<mailto:netmod@ietf.org> 
<mailto:netmod@ietf.org>, 
"draft-ietf-netmod-nmda-diff@ietf.org"<mailto:draft-ietf-netmod-nmda-diff@ietf.org>
 
<mailto:draft-ietf-netmod-nmda-diff@ietf.org>
Subject: Re: [yang-doctors] [netmod] Yangdoctors last call review of 
draft-ietf-netmod-nmda-diff-04


Hi Reshad,

okay, so let's add the following then to section 4, in the explanation of the 
"differences" output parameter:

"When a datastore node in the source of the comparison is not present in the 
target of the comparison, this can be indicated either as a "delete" or as a 
"remove" in the patch as there is no differentiation between those operations 
for the purposes of the comparison.  "

And update the description as follows:

 container differences {
  description
   "The list of differences, encoded per RFC8072 with an
 augmentation to include source values where
 applicable.  When a datastore node in the source is
 not present in the target, this can be indicated either
 as a 'delete' or as a 'remove' as there is no difference
 between them for the purposes of the comparison.";
...

I will post thi

Re: [netmod] [yang-doctors] Yangdoctors last call review of draft-ietf-netmod-nmda-diff-04

[Reshad Rahman (rrahman)]

Hi Alex,

Thank you for addressing my comments.

I checked rev-06, and I believe the XML and JSON output in the example is 
broken: there is a single “edit” element with multiple “edit-id” elements. I 
believe there should be multiple “edit” elements.

The only “nit” is that leaf-xpath-filter references 6021 instead of 6991 (as 
you correctly pointed out in your response).
   leaf xpath-filter {
 if-feature nc:xpath;
 type yang:xpath1.0;
 description
   "This parameter contains an XPath expression
identifying the portions of the target
datastore to retrieve.";
 reference "RFC 6021: Common YANG Data Types";
   }

> Issues
> 1.YANG model P8, for “leaf xpath-filter”, add 
> reference to RFC6021. There should also be a normative reference to RFC6021 
> (as per RFC8407)
 Thanks.  Adding reference to 6991 (as 6021 is obsoleted). 

Regards,
Reshad.

From: Alexander L Clemm 
Date: Friday, September 18, 2020 at 3:48 PM
To: "Reshad Rahman (rrahman)" , "yang-doct...@ietf.org" 

Cc: "last-c...@ietf.org" , "netmod@ietf.org" 
, "draft-ietf-netmod-nmda-diff@ietf.org" 

Subject: Re: [yang-doctors] [netmod] Yangdoctors last call review of 
draft-ietf-netmod-nmda-diff-04


Thank you!

I just uploaded rev -06.

--- Alex
On 9/18/2020 12:47 PM, Reshad Rahman (rrahman) wrote:
Hi Alex,

This addresses my comment/concern.

Regards,
Reshad.

From: Alexander L Clemm <mailto:lud...@clemm.org>
Date: Friday, September 18, 2020 at 3:43 PM
To: "Reshad Rahman (rrahman)" <mailto:rrah...@cisco.com>, 
"yang-doct...@ietf.org"<mailto:yang-doct...@ietf.org> 
<mailto:yang-doct...@ietf.org>
Cc: "last-c...@ietf.org"<mailto:last-c...@ietf.org> 
<mailto:last-c...@ietf.org>, 
"netmod@ietf.org"<mailto:netmod@ietf.org> 
<mailto:netmod@ietf.org>, 
"draft-ietf-netmod-nmda-diff@ietf.org"<mailto:draft-ietf-netmod-nmda-diff@ietf.org>
 
<mailto:draft-ietf-netmod-nmda-diff@ietf.org>
Subject: Re: [yang-doctors] [netmod] Yangdoctors last call review of 
draft-ietf-netmod-nmda-diff-04


Hi Reshad,

okay, so let's add the following then to section 4, in the explanation of the 
"differences" output parameter:

"When a datastore node in the source of the comparison is not present in the 
target of the comparison, this can be indicated either as a "delete" or as a 
"remove" in the patch as there is no differentiation between those operations 
for the purposes of the comparison.  "

And update the description as follows:

 container differences {
  description
   "The list of differences, encoded per RFC8072 with an
 augmentation to include source values where
 applicable.  When a datastore node in the source is
 not present in the target, this can be indicated either
 as a 'delete' or as a 'remove' as there is no difference
     between them for the purposes of the comparison.";
...

I will post this in a -06 shortly.  Please let us know if this addresses your 
concerns or if there is anything else.

Thanks!

--- Alex


On 9/18/2020 5:57 AM, Reshad Rahman (rrahman) wrote:
Hi Alex,

I think the only “problem” with using both “remove” and “delete” is that it 
could be confusing (when should one be used and not the other). Adding some 
text to say they’re the same for the diff operation is good enough for me.

Regards,
Reshad.

From: Alexander L Clemm <mailto:lud...@clemm.org>
Date: Tuesday, September 15, 2020 at 7:31 PM
To: "Reshad Rahman (rrahman)" <mailto:rrah...@cisco.com>, 
"yang-doct...@ietf.org"<mailto:yang-doct...@ietf.org> 
<mailto:yang-doct...@ietf.org>
Cc: "last-c...@ietf.org"<mailto:last-c...@ietf.org> 
<mailto:last-c...@ietf.org>, 
"netmod@ietf.org"<mailto:netmod@ietf.org> 
<mailto:netmod@ietf.org>, 
"draft-ietf-netmod-nmda-diff@ietf.org"<mailto:draft-ietf-netmod-nmda-diff@ietf.org>
 
<mailto:draft-ietf-netmod-nmda-diff@ietf.org>
Subject: Re: [yang-doctors] [netmod] Yangdoctors last call review of 
draft-ietf-netmod-nmda-diff-04


Hi Reshad,

re: question 1: As you indicate, there may be no distinction between indicating 
a "remove" or a "delete" in the patch.  Right now it would be acceptable to 
return either.  If we want to eliminate this freedom, which one would you 
prefer be used?  Shall we remove the possibility for "delete" and just cover it 
using "remove"?

Note that the place where this is specified in the model is as part of a 
condition that specifies when the source value should be included.   If we want 

Re: [netmod] [yang-doctors] Yangdoctors last call review of draft-ietf-netmod-nmda-diff-04

[Reshad Rahman (rrahman)]

Hi Alex,

This addresses my comment/concern.

Regards,
Reshad.

From: Alexander L Clemm 
Date: Friday, September 18, 2020 at 3:43 PM
To: "Reshad Rahman (rrahman)" , "yang-doct...@ietf.org" 

Cc: "last-c...@ietf.org" , "netmod@ietf.org" 
, "draft-ietf-netmod-nmda-diff@ietf.org" 

Subject: Re: [yang-doctors] [netmod] Yangdoctors last call review of 
draft-ietf-netmod-nmda-diff-04


Hi Reshad,

okay, so let's add the following then to section 4, in the explanation of the 
"differences" output parameter:

"When a datastore node in the source of the comparison is not present in the 
target of the comparison, this can be indicated either as a "delete" or as a 
"remove" in the patch as there is no differentiation between those operations 
for the purposes of the comparison.  "

And update the description as follows:

 container differences {
  description
   "The list of differences, encoded per RFC8072 with an
 augmentation to include source values where
 applicable.  When a datastore node in the source is
 not present in the target, this can be indicated either
 as a 'delete' or as a 'remove' as there is no difference
 between them for the purposes of the comparison.";
...

I will post this in a -06 shortly.  Please let us know if this addresses your 
concerns or if there is anything else.

Thanks!

--- Alex


On 9/18/2020 5:57 AM, Reshad Rahman (rrahman) wrote:
Hi Alex,

I think the only “problem” with using both “remove” and “delete” is that it 
could be confusing (when should one be used and not the other). Adding some 
text to say they’re the same for the diff operation is good enough for me.

Regards,
Reshad.

From: Alexander L Clemm <mailto:lud...@clemm.org>
Date: Tuesday, September 15, 2020 at 7:31 PM
To: "Reshad Rahman (rrahman)" <mailto:rrah...@cisco.com>, 
"yang-doct...@ietf.org"<mailto:yang-doct...@ietf.org> 
<mailto:yang-doct...@ietf.org>
Cc: "last-c...@ietf.org"<mailto:last-c...@ietf.org> 
<mailto:last-c...@ietf.org>, 
"netmod@ietf.org"<mailto:netmod@ietf.org> 
<mailto:netmod@ietf.org>, 
"draft-ietf-netmod-nmda-diff@ietf.org"<mailto:draft-ietf-netmod-nmda-diff@ietf.org>
 
<mailto:draft-ietf-netmod-nmda-diff@ietf.org>
Subject: Re: [yang-doctors] [netmod] Yangdoctors last call review of 
draft-ietf-netmod-nmda-diff-04


Hi Reshad,

re: question 1: As you indicate, there may be no distinction between indicating 
a "remove" or a "delete" in the patch.  Right now it would be acceptable to 
return either.  If we want to eliminate this freedom, which one would you 
prefer be used?  Shall we remove the possibility for "delete" and just cover it 
using "remove"?

Note that the place where this is specified in the model is as part of a 
condition that specifies when the source value should be included.   If we want 
to rule out that diff can return either "remove" or "delete" (indeed they are 
synonymous), we would need to add text to the container description that when a 
data object is present in the target of the comparison but not the source, that 
"remove" should be used to indicate that.

The model would be changed follows.  Please confirm if this looks good to you & 
we'll incorporate it.

OLD

   container differences {

 description

   "The list of differences, encoded per 
RFC8072<https://tools.ietf.org/html/rfc8072> with an

augmentation to include source values where

applicable.";

 uses ypatch:yang-patch {

   augment "yang-patch/edit" {

 description

   "Provide the value of the source of the patch,

respectively of the comparison, in addition to

the target value, where applicable.";

 anydata source-value {

   when "../operation = 'delete'"

 + "or ../operation = 'merge'"

 + "or ../operation = 'move'"

 + "or ../operation = 'replace'"

 + "or ../operation = 'remove'";

   description

 "The anydata 'value' is only used for 'delete',

  'move', 'merge', 'replace', and 'remove'

  operations.";

 }

 reference "RFC 8072<https://tools.ietf.org/html/rfc8072>: YANG 
Patch Media Type";

   }

 }

   }




NEW:

   container differences {

 description

   "

Re: [netmod] [yang-doctors] Yangdoctors last call review of draft-ietf-netmod-nmda-diff-04

[Reshad Rahman (rrahman)]

Hi Alex,

I think the only “problem” with using both “remove” and “delete” is that it 
could be confusing (when should one be used and not the other). Adding some 
text to say they’re the same for the diff operation is good enough for me.

Regards,
Reshad.

From: Alexander L Clemm 
Date: Tuesday, September 15, 2020 at 7:31 PM
To: "Reshad Rahman (rrahman)" , "yang-doct...@ietf.org" 

Cc: "last-c...@ietf.org" , "netmod@ietf.org" 
, "draft-ietf-netmod-nmda-diff@ietf.org" 

Subject: Re: [yang-doctors] [netmod] Yangdoctors last call review of 
draft-ietf-netmod-nmda-diff-04


Hi Reshad,

re: question 1: As you indicate, there may be no distinction between indicating 
a "remove" or a "delete" in the patch.  Right now it would be acceptable to 
return either.  If we want to eliminate this freedom, which one would you 
prefer be used?  Shall we remove the possibility for "delete" and just cover it 
using "remove"?

Note that the place where this is specified in the model is as part of a 
condition that specifies when the source value should be included.   If we want 
to rule out that diff can return either "remove" or "delete" (indeed they are 
synonymous), we would need to add text to the container description that when a 
data object is present in the target of the comparison but not the source, that 
"remove" should be used to indicate that.

The model would be changed follows.  Please confirm if this looks good to you & 
we'll incorporate it.

OLD

   container differences {

 description

   "The list of differences, encoded per 
RFC8072<https://tools.ietf.org/html/rfc8072> with an

augmentation to include source values where

applicable.";

 uses ypatch:yang-patch {

   augment "yang-patch/edit" {

 description

   "Provide the value of the source of the patch,

respectively of the comparison, in addition to

the target value, where applicable.";

 anydata source-value {

   when "../operation = 'delete'"

 + "or ../operation = 'merge'"

 + "or ../operation = 'move'"

 + "or ../operation = 'replace'"

 + "or ../operation = 'remove'";

   description

 "The anydata 'value' is only used for 'delete',

  'move', 'merge', 'replace', and 'remove'

  operations.";

 }

 reference "RFC 8072<https://tools.ietf.org/html/rfc8072>: YANG 
Patch Media Type";

   }

 }

   }




NEW:

   container differences {

 description

   "The list of differences, encoded per 
RFC8072<https://tools.ietf.org/html/rfc8072> with an

augmentation to include source values where

applicable.  Where a difference include a data object

in the target that is not present in the source,

this shall be indicated as a 'remove' operation

in the patch, not as a 'delete' operation.";

 uses ypatch:yang-patch {

   augment "yang-patch/edit" {

 description

   "Provide the value of the source of the patch,

respectively of the comparison, in addition to

the target value, where applicable.";

 anydata source-value {

   when "../operation = 'merge'"

 + "or ../operation = 'move'"

 + "or ../operation = 'replace'"

 + "or ../operation = 'remove'";

   description

 "The anydata 'value' is only used for 'merge',

  'move','replace', and 'remove' operations.";

 }

 reference "RFC 8072<https://tools.ietf.org/html/rfc8072>: YANG 
Patch Media Type";

   }

 }

   }

Thanks
--- Alex

On 9/15/2020 4:04 PM, Reshad Rahman (rrahman) wrote:

Hi Alex,



I will review the latest version.



See below for questions/responses.



On 2020-09-15, 5:19 PM, "yang-doctors on behalf of Alexander L Clemm" 
<mailto:yang-doctors-bounces@ietf.orgonbehalfoflud...@clemm.org>
 wrote:



Hello Reshad, hello YANG Doctors,



thank you for your review!  Please find my replies inline, .  We

have also just posted -05 (thanks, Yingzhen, for doublechecking my

updates).



--- Alex on beh

Re: [netmod] [yang-doctors] Yangdoctors last call review of draft-ietf-netmod-nmda-diff-04

[Reshad Rahman (rrahman)]

Hi Alex,

I will review the latest version.

See below for questions/responses.

On 2020-09-15, 5:19 PM, "yang-doctors on behalf of Alexander L Clemm" 
 wrote:

Hello Reshad, hello YANG Doctors,

thank you for your review!  Please find my replies inline, .  We
have also just posted -05 (thanks, Yingzhen, for doublechecking my
updates).   

--- Alex on behalf of coauthors

On 9/7/2020 7:06 AM, Reshad Rahman (rrahman) wrote:
> 
>
> Review of rev -04 by Reshad Rahman
>
> The document is clear and well-written. While some issues have been 
identified, they can be resolved quickly.
>


> Questions
>   1.  YANG model: does the operation “delete” make sense for a diff 
operation? If it is kept, it’d be good to have some text explaining that for a 
diff operation, “delete” and “replace” are the same? If they’re not the same, 
please also add some text….
 I actually meant "delete" and "remove".
 Here we are simply referring to the basic YANG-patch edit
operations per https://tools.ietf.org/html/rfc8072#page-11.  Those are
in turn derived from  operations per
https://tools.ietf.org/html/rfc6241#page-37.  I am not sure we need add
to explain those, as we are directly referring to YANG-patch. 


 The operations are indeed well defined in RFC8072 (copied below), but they 
are defined from the perspective of YANG-Patch. So for YANG-Patch "delete" and 
"remove" are different operations, but from a diff comparison I believe they 
are the same (the resource must exist since it's being returned in a diff)

   
+---+-+
   | delete| delete a data resource if it already exists; if it|
   || does not exist, return an error   
|
   ||   
   |
   | remove | remove a data resource if it already exists   |
   
+---+-+

>   3.  YANG model P9, for the “uses path:yang-patch”, why not have a  
reference to RFC8072 (is it because the description above mentions RFC8072)?
 We are clearly referencing RFC 8072; are you suggesting to put a
reference substatement below the uses statement?   It looks a little
strange to me but sure, we will add it.   
 Not needed. 

>   4.  Section 7 mentions rate limiting requests per client. Should 
there be a “global” rate-limiting too, i.e not client-specific?

 I am not sure this is really needed as I think the number of
management clients will in general be fairly limited to begin with, but
we can certainly add it.  How about the following text:

OLD:

One possibility for an implementation to mitigate against such a
possibility is to limit the number of requests that is served to a
client in any one time interval, rejecting requests made at a higher
frequency than the implementation can reasonably sustain.

NEW:

One possibility for an implementation to mitigate against such a
possibility is to limit the number of requests that is served to a
client, or to any number of clients, in any one time interval, rejecting
requests made at a higher frequency than the implementation can
reasonably sustain.
 Good with me.



>   5.  Wondering if section 8 should be in an Appendix (or even 
removed)? Also, the method suggested doesn’t seem to guarantee that the 
difference persisted for the “dampening” time.

 Personally, I do think it makes sense to include a brief
discussion of possible further extensions.  I suggest to keep the
section if it's okay with you, or perhaps leave it to the chair whether
they have a preference to remove it.  


Whatever the WG/chairs decide is fine with me.

Regards,
Reshad.


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

Re: [netmod] Choice for filtering YANG imports

[Reshad Rahman (rrahman)]

Hi Rob, all,

My concern with "rev:revision-or-derived" is that an NBC change to an imported 
module can "break" the importing module without any action on the part of the 
owner of the importing module.

So yes I would want to use "rev:revision-or-compatible-derived", despite the 
coupling described below.

Regards,
Reshad.

On 2020-09-02, 7:25 AM, "netmod on behalf of Rob Wilton (rwilton)" 
 wrote:

Hi,

My second email on imports ...

RFC 7950 supports two variants of import: The default choice is import any 
revision of a module, but the revision-date substatement may be used to 
restrict the import to a single specific revision.  The "import specific 
revision" has been found to be less useful than expected and potentially 
harmful by creating tight coupling between modules and hence 
draft-ietf-netmod-yang-module-versioning-01 states that the "revision-date" 
substatement SHOULD NOT be used.


Instead, draft-ietf-netmod-yang-module-versioning-01 introduces the 
extension statement "rev:revision-or-derived -BB-CC" that specifies an 
earliest revision that may be imported.  Any module revision that included 
revision -BB-CC in the module's revision history would satisfy the import, 
regardless of whether the revision history includes non-backwards-compatible 
changes.

There have also been discussions between the authors whether to also 
introduce a separate (perhaps rev:revision-or-compatible-derived -BB-CC) 
statement that would only allow a revision to be imported if it was 
backwards-compatible with the selected earliest revision.  Specifically, during 
the import, the module would check the imported modules history to ensure that 
the "rev:nbc-changes" extension statement isn't present in the history between 
the latest revision of the module and revision -BB-CC.

Abstractly, you can consider these 4 revision options are gradually more 
restrictive subsets of revisions that could satisfy an import:
 (i) default import allows any published revision of an imported module,
 (ii) "revision-or-derived -BB-CC" reduces set (i) to only those that 
include -BB-CC in their revision history,
 (iii) "rev:revision-or-compatible-derived -BB-CC" reduces set (ii) to 
only include those that are backwards-compatible with -BB-CC,
 (iv) revision-date reduces (iii) to the set containing only the specified 
revision.

The question to the WG is whether we should also define 
"rev:revision-or-compatible-derived" now, or initially just go with 
"rev:revision-or-derived"?

The authors seem to be somewhat split on this issue.

My personal concern regarding rev:revision-or-compatible-derived is that it 
may appear to have desirable properties for module authors but still result in 
too tight coupling between modules in practice, making it harder to release NBC 
fixes, although that could presumably be mitigated by having some guideline 
text warning of the potential risks.  This extension could be defined in future 
if it turns out to be useful.

Conversely, some authors believe that this statement would be useful now to 
help more tightly constrain import dependencies, and arguably defining it now 
doesn't seem to do any real harm, and means it is available if required.

Input from the WG on this issue is welcome and desired.

Regards,
Rob

[As an individual contributor]

___
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-doctors] Yangdoctors last call review of draft-ietf-netmod-nmda-diff-04

[Reshad Rahman (rrahman)]

Review of rev -04 by Reshad Rahman

The document is clear and well-written. While some issues have been identified, 
they can be resolved quickly.

Issues
1.  YANG model P8, for “leaf xpath-filter”, add reference to 
RFC6021. There should also be a normative reference to RFC6021 (as per RFC8407)
2.  Example P10, 
3.  Example P10, last paragraph talks about preference and 
explicit-router-id. This seems to be leftover from when the example was based 
on OSPF model.
4.  Example P12 and P13. The RPC operation has “operational” as 
source (enabled is true)  and “intended” as target (enabled is false). The 
differences shown (in RPC output) have “value true” and “source-value false”. 
But I thought value came from target datastore and source-value from source 
datastore, so the values are reversed, i.e.. it should be “value false” and 
“source-value true” instead? Looking at the origin in the output I am wondering 
if the intent is to have “intended” as source and ”operational” as target. Or 
am I misunderstanding this?

Questions
1.  YANG model: does the operation “delete” make sense for a diff 
operation? If it is kept, it’d be good to have some text explaining that for a 
diff operation, “delete” and “replace” are the same? If they’re not the same, 
please also add some text….
2.  YANG model: prefix “cp” doesn’t seem to be a great choice since 
cp is associated with copying. I realize that there is some preference for 
2-letter prefixes, but to me “cp” is not a great choice. What about “cmp”? 
WG/chairs should have a word to say about this.
3.  YANG model P9, for the “uses path:yang-patch”, why not have a  
reference to RFC8072 (is it because the description above mentions RFC8072)?
4.  Section 7 mentions rate limiting requests per client. Should 
there be a “global” rate-limiting too, i.e not client-specific?
5.  Wondering if section 8 should be in an Appendix (or even 
removed)? Also, the method suggested doesn’t seem to guarantee that the 
difference persisted for the “dampening” time.

Nits:
1.  P11 replace 

On 2020-09-06, 4:42 PM, "yang-doctors on behalf of Reshad Rahman via 
Datatracker"  
wrote:

Reviewer: Reshad Rahman
Review result: Ready with Issues

Review of rev -04 by Reshad Rahman

The document is clear and well-written. While some issues have been 
identified,
they can be resolved quickly.

Issues
1.  YANG model P8, for “leaf xpath-filter”, add reference to
RFC6021. There should also be a normative reference to RFC6021 (as 
per
RFC8407) 2.  Example P10,  3.  
   
Example P10, last paragraph talks about preference and
explicit-router-id. This seems to be leftover from when the example 
was
based on OSPF model. 4.  Example P12 and P13. The RPC operation 
has
“operational” as source (enabled is true)  and “intended” as target
(enabled is false). The differences shown (in RPC output) have 
“value
true” and “source-value false”. But I thought value came from target
datastore and source-value from source datastore, so the values are
reversed, i.e.. it should be “value false” and “source-value true”
instead? Looking at the origin in the output I am wondering if the
intent is to have “intended” as source and ”operational” as target. 
Or
am I misunderstanding this?

Questions
1.  YANG model: does the operation “delete” make sense for a 
diff
operation? If it is kept, it’d be good to have some text explaining
that for a diff operation, “delete” and “replace” are the same? If
they’re not the same, please also add some text…. 2.  YANG 
model:
prefix “cp” doesn’t seem to be a great choice since cp is associated
with copying. I realize that there is some preference for 2-letter
prefixes, but to me “cp” is not a great choice. What about “cmp”?
WG/chairs should have a word to say about this. 3.  YANG model 
P9,
for the “uses path:yang-patch”, why not have a  reference to RFC8072
(is it because the description above mentions RFC8072)? 4.  
Section
7 mentions rate limiting requests per client. Should there be a
“global” rate-limiting too, i.e not client-specific? 5.  
Wondering
if section 8 should be in an Appendix (or even removed)? Also, the
method suggested doesn’t seem to guarantee that the difference
persisted for the “dampening” time.

Nits:
1.  P11 replace 



___
yang-doctors mailing list
yang-doct...@ietf.org
https://www.ietf.org/mailman/listinfo/yang-doctors

Re: [netmod] submodules the hidden benefits

[Reshad Rahman (rrahman)]

Indeed
https://github.com/netmod-wg/yang-next/issues/26

On 2020-08-05, 5:22 PM, "netmod on behalf of Vladimir Vassilev" 
 wrote:

On 05/08/2020 18.48, Juergen Schoenwaelder wrote:

> I personally meanwhile believe that sub-modules add complexity with
> little extra value but this view surely is not shared by others.

+1. IMO removing sub-modules from YANG 2.0 should be on the list of 
proposed changes.

/Vladimir

___
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] Follow-up: impact of changing an import statement

[Reshad Rahman (rrahman)]

On 2020-08-01, 1:39 AM, "Juergen Schoenwaelder" 
 wrote:

On Sat, Aug 01, 2020 at 02:51:54AM +0000, Reshad Rahman (rrahman) wrote:
> WG,
> 
> Following up from the discussions during NETMOD meeting on Thursday. One 
of the main open topics is what to do when an import stmt is changed, for 
example
> 
>   1.  Module A (1.0.0) imports module B using “2.0.0 or derived”. There 
is no version 3+ for module B so module A uses 2.Y.Z
>   2.  A new revision 3.0.0 of module B is created AND there is a change 
in module A to import module B using “3.0.0 or derived”.

What does "2.0.0 or derived" mean? Does it mean (i) any module >=
2.0.0 or does it mean (ii) any (module >= 2.0.0 && < 3.0.0)?
It currently means (i). Kent asked about this on slide 12 during the meeting 
stating he believes it should be (ii). My response was that this has been 
discussed among the authors and there's no  agreement among us right now. I 
think Rob W has an AI from the WG meeting on this.
 
> Authors/contributors have discussed 2 options and right now we don’t have 
unanimity:
> 
>   1.  Option A: depending on the impact on the importing module A, the 
import-stmt is deemed BC or NBC. E.g. if the only NBC change in the  imported 
module is  to a type which the importing module does NOT use, that’s a BC 
change for the importing module.
>   2.  Option B: consider the import-stmt change as a BC change and 
resolve this elsewhere e.g. YANG-Packages or YANG-Library.

Whether a change is BC or not always depends on which definitions have
changed, how they have changed, and how these definitions are used. So
the answer very likely must be option 1. Option 2 also seems to push
the problem elsewhere (packages, library) without providing the
details.
I agree.

We have discussed a bit how this would be done but that was right before the 
IETF. With YANG-Packages, the package version would be modified accordingly and 
a client would need to do schema comparison. 

Thanks for the input,
Reshad.

/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

[netmod] Follow-up: impact of changing an import statement

[Reshad Rahman (rrahman)]

WG,

Following up from the discussions during NETMOD meeting on Thursday. One of the 
main open topics is what to do when an import stmt is changed, for example

  1.  Module A (1.0.0) imports module B using “2.0.0 or derived”. There is no 
version 3+ for module B so module A uses 2.Y.Z
  2.  A new revision 3.0.0 of module B is created AND there is a change in 
module A to import module B using “3.0.0 or derived”.

Authors/contributors have discussed 2 options and right now we don’t have 
unanimity:

  1.  Option A: depending on the impact on the importing module A, the 
import-stmt is deemed BC or NBC. E.g. if the only NBC change in the  imported 
module is  to a type which the importing module does NOT use, that’s a BC 
change for the importing module.
  2.  Option B: consider the import-stmt change as a BC change and resolve this 
elsewhere e.g. YANG-Packages or YANG-Library.

This was in slides 13-14 of the presentation.

Fire away….

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

Re: [netmod] rfc6991bis: yang:longitude, yang:latitude, yang:postal-code, yang:country-code

[Reshad Rahman (rrahman)]

+1



On 2020-07-30, 10:04 AM, "netmod on behalf of Juergen Schoenwaelder" 
 
wrote:

But then perhaps draft-ietf-netmod-geo-location-05 needs to be updated
or you need to use a grouping. I think we should not have overlapping
work in different documents.

/js

On Thu, Jul 30, 2020 at 01:54:43PM +, Qin Wu wrote:
> That is a good option, but draft-ietf-netmod-geo-location-05 only define 
grouping, there is typedef for longitude and latitude, altitude. 
> 
> -Qin
> -邮件原件-
> 发件人: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de] 
> 发送时间: 2020年7月30日 21:32
> 收件人: Qin Wu 
> 抄送: netmod@ietf.org
> 主题: Re: [netmod] rfc6991bis: yang:longitude, yang:latitude, 
yang:postal-code, yang:country-code
> 
> But there is draft-ietf-netmod-geo-location-05... What about using the 
types defined in there?
> 
> /js
> 
> On Thu, Jul 30, 2020 at 01:28:17PM +, Qin Wu wrote:
> > See geolocation definition in draft-ietf-teas-yang-te-topo-22 which 
defines longitude and latitude, altitude.
> > I know it is beneficial for future document to import these types from 
rfc6991bis instead of from te topo model.
> > 
> > -Qin
> > -邮件原件-
> > 发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Juergen Schoenwaelder
> > 发送时间: 2020年7月18日 3:16
> > 收件人: netmod@ietf.org
> > 主题: [netmod] rfc6991bis: yang:longitude, yang:latitude, 
> > yang:postal-code, yang:country-code
> > 
> >   - It was suggested to add types for longitude, latitude, postal
> > code, country-code. Do we go there or do we leave these for other
> > modules to define? It seems such definitions should go into
> > draft-ietf-netmod-geo-location.
> > 
> >   - Geo location is covered by draft-ietf-netmod-geo-location
> > (so do nothing).
> > 
> >   - For country codes, there is ISO 3166, which defines two-letter,
> > three-letter, and numeric country codes. I assume people wanted
> > two-letter codes (as used in the DNS), i.e. they want DE and not
> > DEU. But note that it is GB and not UK, i.e., what we commonly
> > use in the DNS may not be exactly ISO 3166. (The devil is always
> > in the details.)
> > 
> >   - For postal codes, it is unclear what the requirements are or what
> > a proper definition for postal codes is. It is not entirely clear
> > what the authoritative definition of the format of postal codes
> > is, perhaps the Universal Postal Union.
> > 
> >   - Options: (i) do nothing or (ii) add a country code definition
> > only or (iii) add both a country code definition and a postal
> > code definition (which might be to some extend vague)
> > 
> >   - Proposal: do nothing
> >   
> > -- 
> > 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
> 
> -- 
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 

-- 
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] rfc6991bis: loopback addresses

[Reshad Rahman (rrahman)]

Hi,

I think what you're referring to is the use of "loopback interfaces". The 
loopback addresses Juergen was referring to do not belong to loopback 
interfaces. 

Regards,
Reshad.


On 2020-07-20, 11:30 AM, "tom petch"  wrote:

    From: Reshad Rahman (rrahman) 
Sent: 20 July 2020 14:39

I don't understand the comment "...implementation choice of one 
manufacturer."


Go back to the early specifications of IPv4 routers and routing protocols, 
which are still the ones we use today, and loopback was a state into which an 
interface could be put, with a loop back in hardware or software, often used 
for testing.  A router had a router id, a 32 bit number with no syntax.  One 
major manufacturer conflated parts of this and created a virtual address  or 
addresses which could be used to send and receive packets for the router, as 
opposed to an interface on the router, which had no physical manifestation; 
fine until they called it the loopback address(es) which, sadly, caught on and 
many people, included those writing IETF I-D think that the router id can only 
be such a routable address.  Some even think that there can only be one such 
address on a box, as opposed to one for network management, one for the control 
plane and so on.  Not so.

Tom Petch.

As for the details, see 
https://tools.ietf.org/html/draft-nainar-mpls-lsp-ping-yang-00

Regards,
Reshad.


On 2020-07-20, 4:47 AM, "netmod on behalf of tom petch" 
 wrote:

I am not a fan of loopback seeing it as the implementation choice of 
one manufacturer.  On the other hand, the IETF has defined documentation 
addresses which many if not most writers of examples for YANG modules seem 
unaware of so if we add anything, I would add those.

Tom Petch

From: netmod  on behalf of Juergen 
Schoenwaelder 
Sent: 17 July 2020 20:25

  - There was a request to add types for loopback addresses
(127.0.0.0/8 and ::1/128).

  - This is related to an effort to define a YANG module for MPLS LSP
Ping (RFC 8029) but the details are unclear, i.e., what is exactly
needed and how such a type will be used and whether there is a
common need for types for loopback addresses.

  - Proposal: do not add such types at this point in time

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

___
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] rfc6991bis: loopback addresses

[Reshad Rahman (rrahman)]

Hi Erik,

You are correct, for IPV6 RFC8029 mentions 0:0:0:0:0::7F00:0/104.

Regards,
Reshad.

On 2020-07-20, 10:30 AM, "Erik Auerswald"  wrote:

Hello Reshad,

while the I-D draft-nainar-mpls-lsp-ping-yang-00 only specifies ::1/128
as IPv6 loopback address, RFC 8029 sections 2.1., 3.4.1.1.1., and 4.3.
specify to use the IPv4 loopback range as IP4-mapped IPv6 addresses for
IPv6 MPLS echo request UDP packets, not the IPv6 loopback address ::1/128.

This seems to be inconsistent to me.

Best regards,
Erik

On Mon, Jul 20, 2020 at 01:39:02PM +0000, Reshad Rahman (rrahman) wrote:
> I don't understand the comment "...implementation choice of one 
manufacturer."
> 
> As for the details, see 
https://tools.ietf.org/html/draft-nainar-mpls-lsp-ping-yang-00
> 
> Regards,
> Reshad.
> 
> 
> On 2020-07-20, 4:47 AM, "netmod on behalf of tom petch" 
 wrote:
> 
> I am not a fan of loopback seeing it as the implementation choice of 
one manufacturer.  On the other hand, the IETF has defined documentation 
addresses which many if not most writers of examples for YANG modules seem 
unaware of so if we add anything, I would add those.
> 
> Tom Petch
> 
> From: netmod  on behalf of Juergen 
Schoenwaelder 
> Sent: 17 July 2020 20:25
> 
>   - There was a request to add types for loopback addresses
> (127.0.0.0/8 and ::1/128).
> 
>   - This is related to an effort to define a YANG module for MPLS LSP
> Ping (RFC 8029) but the details are unclear, i.e., what is exactly
> needed and how such a type will be used and whether there is a
> common need for types for loopback addresses.
> 
>   - Proposal: do not add such types at this point in time
> 
> --
> 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] rfc6991bis: loopback addresses

[Reshad Rahman (rrahman)]

I don't understand the comment "...implementation choice of one manufacturer."

As for the details, see 
https://tools.ietf.org/html/draft-nainar-mpls-lsp-ping-yang-00

Regards,
Reshad.


On 2020-07-20, 4:47 AM, "netmod on behalf of tom petch" 
 wrote:

I am not a fan of loopback seeing it as the implementation choice of one 
manufacturer.  On the other hand, the IETF has defined documentation addresses 
which many if not most writers of examples for YANG modules seem unaware of so 
if we add anything, I would add those.

Tom Petch

From: netmod  on behalf of Juergen Schoenwaelder 

Sent: 17 July 2020 20:25

  - There was a request to add types for loopback addresses
(127.0.0.0/8 and ::1/128).

  - This is related to an effort to define a YANG module for MPLS LSP
Ping (RFC 8029) but the details are unclear, i.e., what is exactly
needed and how such a type will be used and whether there is a
common need for types for loopback addresses.

  - Proposal: do not add such types at this point in time

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

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

Re: [netmod] I-D Action: draft-ietf-netmod-yang-module-versioning-01.txt

[Reshad Rahman (rrahman)]

WG,

This revision addesses many of the comments which were provided at WG adoption. 
Of note:
- Including sub-modules by revision-date is now a SHOULD
- Clarifications on use of revision-label by submodules
- Added a revision-label-scheme extension
- Use of # in filenames with revision-label (@ for dates as currently used)
- status-description has been removed

Regards,
Reshad.

On 2020-07-10, 4:06 PM, "netmod on behalf of internet-dra...@ietf.org" 
 wrote:


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

Title   : Updated YANG Module Revision Handling
Authors : Robert Wilton
  Reshad Rahman
  Balazs Lengyel
  Joe Clarke
  Jason Sterne
  Benoit Claise
  Kevin D'Souza
Filename: draft-ietf-netmod-yang-module-versioning-01.txt
Pages   : 35
Date: 2020-07-10

Abstract:
   This document specifies a new YANG module update procedure that can
   document when non-backwards-compatible changes have occurred during
   the evolution of a YANG module.  It extends the YANG import statement
   with an earliest revision filter to better represent inter-module
   dependencies.  It provides help and guidelines for managing the
   lifecycle of YANG modules and individual schema nodes.  It provides a
   mechanism, via the revision-label YANG extension, to specify a
   revision identifier for YANG modules.  This document updates RFC
   7950, RFC 8407 and RFC 8525.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-module-versioning/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netmod-yang-module-versioning-01

https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-module-versioning-01

A diff from the previous version is available at:

https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-yang-module-versioning-01


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

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


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

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

[netmod] Impact of changing an import statement on YANG versioning (https://github.com/netmod-wg/yang-ver-dt/issues/4)

[Reshad Rahman (rrahman)]

Hi,

We’ve been having discussions on the impact of changing an import statement and 
would like to get thoughts from the WG.

Consider module A which imports module B.

  1.  Module A revision 1.0.0 has “revision-or-derived 1.0.0” for import of 
module B.
import moduleB {
  rev:revision-or-derived 1.0.0;
}
  2.  An update to module A so that it needs to import at least 2.0.0 of module 
B
import moduleB {
  rev:revision-or-derived 2.0.0;
}

When module’s A import is updated in step b, we’ve discussed 3 options:

  1.  Always consider the change as BC (new revision 1.1.0 for module A) and 
let the client figure out the impact on its use of module A
  2.  Always consider the change as NBC (new revision 2.0.0 for module A, tag 
the import as NBC using nbc-change extension) and let the client figure out the 
impact on its use of module A
  3.  Handle this conditionally. So if the impact on module A is NBC (depending 
on whether module A’s namespace has been impacted in NBC way),  do as in 2 
(this can have ripple effect on importing module hierarchy, e.g. module C uses 
module A, module D uses module C etc). If the impact on module A is BC, do as 
in 1

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

Re: [netmod] Revision labels for submodules

[Reshad Rahman (rrahman)]

WG, we're in the process of updating the various drafts. So comments/ack/nack 
sooner rather than later would be very appreciated.

Regards,
Reshad.


On 2020-06-05, 3:06 PM, "Reshad Rahman (rrahman)"  wrote:

We (authors/contributors) have discussed this issue in the last couple of 
weekly meetings and come up with the following. We'd like to hear back from the 
WG before updating the draft.

For sub-modules:
1) No revision-label is OK
2) Same revision-label scheme as including module is OK, but different 
revision-label space for submodules
3) Sub-modules can use different scheme as including module. By default (no 
revision-label scheme extension statement), submodules use same scheme as 
including module. Different submodules could use different schemes.

3)  is not unanimous. Why would submodules use a different scheme as 
including module? But since allowing this seems to have a small cost, it 
doesn't seem to do any harm.

Here's the proposed text:

i) Replace MUST by SHOULD for include of submodules by revision-date.


https://tools.ietf.org/html/draft-ietf-netmod-yang-module-versioning-00#section-3,
 replaced MUST by SHOULD below and added some text:
   A module's name and revision date identifies a specific immutable
   definition of that module within its revision history.  Hence, if a
   module includes submodules then the module's "include" statements
   SHOULD use "revision-date" substatements to specify the exact revision
   date of each included submodule.

ADDED TEXT:
When a module does not include its submodules by revision-date,  the 
revision of submodules used cannot be derived from the including module. If the 
revision of submodules is needed, mechanisms such as YANG packages and YANG 
library can be used.


https://tools.ietf.org/html/draft-ietf-netmod-yang-module-versioning-00#section-7.1,
 replaced MUST by SHOULD and modified existing text as suggested in email 
discussion.
OLD TEXT:
   A module that includes submodules MUST use the "revision-date"
   substatement to include specific submodule revisions.  Changing a
   module's include statements to include different submodule revisions
   requires a new revision of the module.
NEW TEXT:
   A module that includes submodules SHOULD use the "revision-date"
   substatement to include specific submodule revisions.  The revision of 
the including
   module MUST be updated when any included submodule has changed. The
   revision-label substatement used in the new module revision MUST 
indicate the nature
   of the change, i.e. NBC, BC or editorial, to the module's schema tree.

ii) Change text which talks about revision-labels for submodules, 
https://tools.ietf.org/html/draft-ietf-netmod-yang-module-versioning-00#section-3.3:
OLD TEXT:
   The revision date and revision label within a submodule's revision
   history have no effect on the including module's revision.
   Submodules MUST NOT use revision label schemes that could be confused
   with the including module's revision label scheme.
NEW TEXT:
  Submodules MAY use a revision label scheme. When they use a revision
  label scheme, submodules MAY use a revision label scheme that is 
different from
  the one used in the including module.
  The revision label space of submodules is separate from the revision 
label space of the including module.
  A change in one submodule MUST result in a new revision label of that 
submodule and the including module,
  but the actual values of the revision labels in the module and submodule  
could be completely different. A
  change in one submodule does not result in a new revision label in 
another submodule. A change in a module
  revision label does not necessarily mean a change to the revision label 
in all included submodules.

Regards,
Reshad (on behalf of the group).

On 2020-05-13, 5:25 PM, "Sterne, Jason (Nokia - CA/Ottawa)" 
 wrote:

The example we've been using to discuss this is an editorial type 
change in 2 submodules (moving a leaf between them with no changes to their 
definition or the schema). 

But if we consider an example where schema actually changes (in a part 
that is defined in a submodule), then it does seem reasonable that the module 
version should also change.

So (A) is probably the right answer here.  But it does have a 
potentially confusing consequence: two YANG files could be identical except for 
an extra revision statement. It may appear that someone incorrectly bumped a 
version when there was no change, until you notice that "oh, this module 
includes submodules - one of those must have changed".

    Jason

    > -Original Message-
> From: Reshad Rahman (rrahman) 
> Sent: Wednesday

Re: [netmod] YANG versioning issue #48 (interpreting revision labels)

[Reshad Rahman (rrahman)]

From: "Sterne, Jason (Nokia - CA/Ottawa)" 
Date: Monday, June 22, 2020 at 2:04 PM
To: "Reshad Rahman (rrahman)" , "Joe Clarke (jclarke)" 
, "netmod@ietf.org" 
Subject: RE: YANG versioning issue #48 (interpreting revision labels)

forgot to add NETMOD…

From: Sterne, Jason (Nokia - CA/Ottawa)
Sent: Monday, June 22, 2020 2:03 PM
To: Reshad Rahman (rrahman) ; Joe Clarke (jclarke) 

Subject: YANG versioning issue #48 (interpreting revision labels)

Hi all (and particularly Reshad and Joe),

wrt github issue #48:
https://github.com/netmod-wg/yang-ver-dt/issues/48

module-versioning says this:

   All revision labels that match the pattern for the "version"
   typedef in the ietf-yang-semver YANG module MUST be interpreted as
   YANG semantic version numbers.

 Yes we had agreed to remove the above.

yang-semver says this:

   Other version schemes MUST NOT use version strings that match this
   same pattern.  For example, they may choose to use leading characters
   to distinguish themselves from YANG semver.

I'd propose we remove that text from both documents. We've decided to use an 
extension to identify the revision-label scheme in use by a module.

But we should probably add this to module-versioning:

Although an extension is used to identify which revision-label scheme is in use 
by a YANG module, any new YANG revision-label schemes being proposed SHOULD try 
to avoid patterns that are very similar to other previously existing 
standardized schemes. Being able to identify a YANG revision-label scheme by 
looking at the revision-label value is a useful property.
 Let’s discuss in tomorrow’s weekly meeting. Not sure yet this is the right 
recommendation.

Regards,
Reshad.

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

Re: [netmod] optional char in yang-semver

[Reshad Rahman (rrahman)]

I'm fine with either J1 or J2.

Regards,
Reshad.

On 2020-06-10, 5:36 PM, "netmod on behalf of Joe Clarke (jclarke)" 
 wrote:


>> 
>> ###
>> Option J1
>> ###
>> use the following suffixes:
>> _non_compatible  (instead of the old "M", for an NBC change)
>> _compatible (instead of the old "m", for a BC change)
>> 
>> e.g. for NBC:
>> 1.1.0 -> 1.1.1_non_compatible
>> e.g. for BC:
>> 1.1.0 -> 1.1.1_compatible
> 
> I like this.  It clearly shows what is meant.  No special context or
> knowledge is needed to understand the meaning, or at least to understand
> that trouble might lie ahead.

I like this, too, but I like J2 a bit better as I don’t like the double 
‘_’.  That said, I see your point about what the eye distinguishes.

Still, I can live with both, but I prefer J2.

> 
>> ###
>> Option J2
>> ###
>> - same as J1, just one fewer underscore
>> 
>> e.g. for NBC:
>> 1.1.0 -> 1.1.1_noncompatible
>> e.g. for BC:
>> 1.1.0 -> 1.1.1_compatible
> 
> I like this a little bit less than J1, because it is a little bit less
> easy to distinguish between the two words.

Joe

___
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] Revision label in filename

[Reshad Rahman (rrahman)]

On 2020-06-11, 4:21 AM, "netmod on behalf of Jan Lindblad" 
 wrote:

Hi,

> I understand the requirement to not break what's currently working for 
date in the filename. However we do need something similar to work for 
revision-label. Having another file with the revision-label embedded in the 
filename should work. 
> 
> We discussed this issue in yesterday's weekly meeting and a proposal was 
made to use '@@' as delimiter for revision-label. # was turned down because of 
its impact on bash.

I did a quick check, and # is only treated as a comment character by bash 
when preceded by whitespace, i.e. not when used in the middle of a filename => 
I think we can drop the comment above.
Glad # works as delimiter.
If we want a filename to include multiple kinds of revision markings while 
keeping the existing tools afloat, implementing the @ notation, that might be 
achievable by picking some delimiter that is treated as a filename character by 
existing tools and placing the version label before the @. I.e. with # as the 
delimiter:

module-or-submodule-name['#'revision-label]['@'date].yang
When we discussed this on Tuesday, there was concern that some tools would 
interpret the module/submodule name as 
"module-or-submodule-name['#'revision-label]". 
My preference right now is to have 2 filenames (I realize this could also 
impact some tools), but I'll be content with any workable solution.

Regards,
Reshad.

Many other (combinations of) symbols could work, but they all run the risk 
of interfering with some tool or vendor internal CI/CD convention. A few 
examples: double underscore __, tripple dots ..., _ver_, ~, :

/jan


> So:
> module-or-submodule-name['@'date].yang (unchanged)
> module-or-submodule-name['@@'revision-label].yang
> 
> A symlink could be used, or we could have duplicate file contents.
> 
> Regards,
> Reshad.

___
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] Revision label in filename

[Reshad Rahman (rrahman)]

Hi,

I understand the requirement to not break what's currently working for date in 
the filename. However we do need something similar to work for revision-label. 
Having another file with the revision-label embedded in the filename should 
work. 

We discussed this issue in yesterday's weekly meeting and a proposal was made 
to use '@@' as delimiter for revision-label. # was turned down because of its 
impact on bash.
So:
module-or-submodule-name['@'date].yang (unchanged)
module-or-submodule-name['@@'revision-label].yang

A symlink could be used, or we could have duplicate file contents.

Regards,
Reshad.

On 2020-05-09, 7:06 AM, "tom petch"  wrote:

From: netmod  on behalf of Reshad Rahman (rrahman) 

Sent: 08 May 2020 15:13

Hi,

We discussed using something along the lines of 
module-or-submodule-name['@'date]['#'revision-label].yang. Questions to the WG:
1) Is there a need for both date and revision-label or is one of them 
enough?


One of them is quite enough and since the date is embedded in many systems 
it would be wrong to change it.  The module name is the primary identifier of 
this bundle of definitions but it was decided that as and when there was a 
change therein then the date would provide a unique identifier for a particular 
version; nothing more is needed.  Arguably the date is more complex than is 
warranted but it has worked.  Indeed that format is now used and understood by 
such as IANA and the RFC Editor.

If you want to record more detailed semantics of the relationships between 
different versions, then put it somewhere else and leave the identifier alone, 
let the identifier be an identifier and not be overloaded with semantics.

Tom Petch








2) If we have both, what's the impact of having "#revision-label" on 
implementations which search by date?

Regards,
Reshad.

On 2020-03-27, 5:44 PM, "netmod on behalf of Reshad Rahman (rrahman)" 
 wrote:

Hi,

https://github.com/netmod-wg/yang-ver-dt/issues/50

o  3.3

  In the filename of a YANG module, where it takes the 
form: module-
  or-submodule-name ['@' revision-label] ( '.yang' / '.yin' 
)

  Should this section update 5.2 of RFC 7950?  I know that 5.2 
just
  says "SHOULD".  But existing tools implement this SHOULD, and 
they
  need to be updated to handle this new convention.

  But I wonder if this a good idea.  It means that a tool that 
looks
  for a module with a certain revision date cannot simply check 
the
  filenames, but need to parse all available modules (wijust to 
find the

We agree that there is an impact on searching by date. We put this in 
to have the ability to search by revision-label, otherwise we can search just 
by date for a module which uses revision-label.
We had also discussed using different limiter for the label and have 
something along the lines of: 
module-or-submodule-name['@'date]['#'revision-label].yang
It'd seem that updating 7950 would be a good idea whichever way we go.

Regards,
Reshad.


On 2020-03-20, 5:08 PM, "netmod on behalf of Reshad Rahman (rrahman)" 
 wrote:

Hi Martin,

We've opened issues to track your review comments (see below). Will 
kick off separate therads for each issue.


https://github.com/netmod-wg/yang-ver-dt/issues?q=is%3Aissue+is%3Aopen+label%3Aupdated-mod-rev-handling

Regards,
Reshad.

On 2020-03-10, 3:31 PM, "netmod on behalf of Martin Björklund" 
 wrote:

Hi,

Here are my review comments of
draft-verdt-netmod-yang-module-versioning-01.



o  3.1.1

o  In statements that have any data definition statements as
   substatements, those data definition substatements MAY be
   reordered, as long as they do not change the ordering or 
any "rpc"
   "input" substatements.

  I think this needs to capture that no descendant statements to
  "input" can be reordered.  Same for "output" (note, "input" 
and
  "output" in both "rpc" and "action").


o  3.3

All revision labels that match the pattern for the "version"
typedef in the ietf-yang-semver YANG module MUST be 
interpreted as
YANG semantic version numbers.

  I don't think this is a good idea.  Seems like a layer 
violation.
  What if my project use another dialect of semver, that 
wouldn't be
  possible with

Re: [netmod] Revision labels for submodules

[Reshad Rahman (rrahman)]

We (authors/contributors) have discussed this issue in the last couple of 
weekly meetings and come up with the following. We'd like to hear back from the 
WG before updating the draft.

For sub-modules:
1) No revision-label is OK
2) Same revision-label scheme as including module is OK, but different 
revision-label space for submodules
3) Sub-modules can use different scheme as including module. By default (no 
revision-label scheme extension statement), submodules use same scheme as 
including module. Different submodules could use different schemes.

3)  is not unanimous. Why would submodules use a different scheme as including 
module? But since allowing this seems to have a small cost, it doesn't seem to 
do any harm.

Here's the proposed text:

i) Replace MUST by SHOULD for include of submodules by revision-date.

https://tools.ietf.org/html/draft-ietf-netmod-yang-module-versioning-00#section-3,
 replaced MUST by SHOULD below and added some text:
   A module's name and revision date identifies a specific immutable
   definition of that module within its revision history.  Hence, if a
   module includes submodules then the module's "include" statements
   SHOULD use "revision-date" substatements to specify the exact revision
   date of each included submodule.

ADDED TEXT:
When a module does not include its submodules by revision-date,  the revision 
of submodules used cannot be derived from the including module. If the revision 
of submodules is needed, mechanisms such as YANG packages and YANG library can 
be used.

https://tools.ietf.org/html/draft-ietf-netmod-yang-module-versioning-00#section-7.1,
 replaced MUST by SHOULD and modified existing text as suggested in email 
discussion.
OLD TEXT:
   A module that includes submodules MUST use the "revision-date"
   substatement to include specific submodule revisions.  Changing a
   module's include statements to include different submodule revisions
   requires a new revision of the module.
NEW TEXT:
   A module that includes submodules SHOULD use the "revision-date"
   substatement to include specific submodule revisions.  The revision of the 
including
   module MUST be updated when any included submodule has changed. The
   revision-label substatement used in the new module revision MUST indicate 
the nature
   of the change, i.e. NBC, BC or editorial, to the module's schema tree.

ii) Change text which talks about revision-labels for submodules, 
https://tools.ietf.org/html/draft-ietf-netmod-yang-module-versioning-00#section-3.3:
OLD TEXT:
   The revision date and revision label within a submodule's revision
   history have no effect on the including module's revision.
   Submodules MUST NOT use revision label schemes that could be confused
   with the including module's revision label scheme.
NEW TEXT:
  Submodules MAY use a revision label scheme. When they use a revision
  label scheme, submodules MAY use a revision label scheme that is different 
from
  the one used in the including module.
  The revision label space of submodules is separate from the revision label 
space of the including module.
  A change in one submodule MUST result in a new revision label of that 
submodule and the including module,
  but the actual values of the revision labels in the module and submodule  
could be completely different. A
  change in one submodule does not result in a new revision label in another 
submodule. A change in a module
  revision label does not necessarily mean a change to the revision label in 
all included submodules.

Regards,
Reshad (on behalf of the group).

On 2020-05-13, 5:25 PM, "Sterne, Jason (Nokia - CA/Ottawa)" 
 wrote:

The example we've been using to discuss this is an editorial type change in 
2 submodules (moving a leaf between them with no changes to their definition or 
the schema). 

But if we consider an example where schema actually changes (in a part that 
is defined in a submodule), then it does seem reasonable that the module 
version should also change.

So (A) is probably the right answer here.  But it does have a potentially 
confusing consequence: two YANG files could be identical except for an extra 
revision statement. It may appear that someone incorrectly bumped a version 
when there was no change, until you notice that "oh, this module includes 
submodules - one of those must have changed".

    Jason

> -Original Message-
> From: Reshad Rahman (rrahman) 
> Sent: Wednesday, May 13, 2020 4:52 PM
> To: Sterne, Jason (Nokia - CA/Ottawa) ; Martin
> Björklund 
> Cc: netmod@ietf.org
> Subject: Re: [netmod] Revision labels for submodules
> 
> Hi Jason,
> 
> Is your question of option A v/s B just for the case where the schema
> represented by the module does not change?
> 
> If the schema changes, even if the module didn't change, the 
re

Re: [netmod] Revision labels for submodules

[Reshad Rahman (rrahman)]

Hi Jason,

Is your question of option A v/s B just for the case where the schema 
represented by the module does not change?

If the schema changes, even if the module didn't change, the revision-label has 
to be updated to indicate the change.
If the schema didn't change, I'd go with editorial revision-label update as (I 
think) Martin suggested.

Regards,
Reshad.

On 2020-05-13, 1:30 PM, "Sterne, Jason (Nokia - CA/Ottawa)" 
 wrote:

So that's the part I'm not sure of.

If a leaf moves between submodules, and the module file doesn't change in 
any way (as we've said is possible and should be allowed), do we mandate that 
the module version changes?  This is up to us to define IMO

(A) the module version has a scope that includes the module and all 
submodules
(B) the module version has a scope that is just the module file contents

I'm on the fence between those two. (A) could make sense but it does mean 
that someone comparing two versions of the just the module file itself may see 
no difference whatsoever between them except the addition of a new version 
statement.

Jason

> -Original Message-
> From: Reshad Rahman (rrahman) 
> Sent: Wednesday, May 13, 2020 12:46 PM
> To: Sterne, Jason (Nokia - CA/Ottawa) ; Martin
> Björklund 
> Cc: netmod@ietf.org
> Subject: Re: [netmod] Revision labels for submodules
> 
> Hi Jason,
> 
> 
> On 2020-05-13, 11:50 AM, "Sterne, Jason (Nokia - CA/Ottawa)"
>  wrote:
> 
> Hi guys,
> 
> As someone who is heavily involved in the development of an extensive
> YANG model comprised of submodules, I'm not a fan of mandating that
> include by revision is mandatory for submodules. It may indeed be a good
> idea (so perhaps SHOULD is fine) but I can see it causing problems on the
> implementation side.
> 
> The primary development of a data model may be distributed out to
> submodules and the main module may only be a top level container for the
> submodules (and rarely touched). This would suddenly create an ordering
> dependency in the release process that requires the main module file to
> systematically be updated after all development of the submodules is 
halted.
> Then the results of the submodules has to be used to then go update the
> module. Solvable - yes, but folks who work on large scale projects will 
know
> that suddenly requiring that type of development process change isn't as
> easy as it may sound on paper.
>  I can see why you wouldn't want to modify all your include 
by-revision
> statements. But you would still need to update the module revision-label
> based on changes done in the included submodules.
> 
> Regards,
> Reshad.
> 
> It is possible to manage the "packaging" of submodules and modules out
> of band or other mechanisms.
> 
> OpenConfig, for example, uses submodules but does not currently 
include
> by version. I'm not proposing this is ideal. But I think we should leave 
it as
> acceptable.
> 
> Rgds,
> Jason
> 
> > -Original Message-
> > From: Reshad Rahman (rrahman) 
> > Sent: Tuesday, May 12, 2020 9:46 AM
> > To: Sterne, Jason (Nokia - CA/Ottawa) ;
> Martin
> > Björklund 
> > Cc: netmod@ietf.org
> > Subject: Re: [netmod] Revision labels for submodules
> >
> > Hi Jason,
> >
> > On 2020-05-09, 12:52 PM, "Sterne, Jason (Nokia - CA/Ottawa)"
> >  wrote:
> >
> > Hi Martin,
> >
> > Your approach sounds good to me. I was forgetting about the
> "editorial"
> > level of change (e.g. the 3rd part of SemVer).  So I agree that 
moving a
> leaf
> > would be an editorial change in both submodules.
> >
> > But what if a module is not doing include by revision? It may 
indeed
> make
> > sense to include by revision but it isn't mandated. For sake of 
argument
> here
> > what if the module itself didn't change at all in this case?
> > It is now mandated in section 3 of draft-ietf-netmod-yang-module-
> > versioning-00.
> >
> >
> > It *feels* like the right thing to do here is to consider the 
module
> overall
> > to have an editorial change.
> >
> > The revision statement of sub-modules has a scope of the file 
(the
> s

Re: [netmod] Revision labels for submodules

[Reshad Rahman (rrahman)]

Hi Jason,


On 2020-05-13, 11:50 AM, "Sterne, Jason (Nokia - CA/Ottawa)" 
 wrote:

Hi guys,

As someone who is heavily involved in the development of an extensive YANG 
model comprised of submodules, I'm not a fan of mandating that include by 
revision is mandatory for submodules. It may indeed be a good idea (so perhaps 
SHOULD is fine) but I can see it causing problems on the implementation side. 

The primary development of a data model may be distributed out to 
submodules and the main module may only be a top level container for the 
submodules (and rarely touched). This would suddenly create an ordering 
dependency in the release process that requires the main module file to 
systematically be updated after all development of the submodules is halted. 
Then the results of the submodules has to be used to then go update the module. 
Solvable - yes, but folks who work on large scale projects will know that 
suddenly requiring that type of development process change isn't as easy as it 
may sound on paper.
 I can see why you wouldn't want to modify all your include by-revision 
statements. But you would still need to update the module revision-label based 
on changes done in the included submodules.

Regards,
Reshad.

It is possible to manage the "packaging" of submodules and modules out of 
band or other mechanisms.

OpenConfig, for example, uses submodules but does not currently include by 
version. I'm not proposing this is ideal. But I think we should leave it as 
acceptable.

Rgds,
Jason

> -Original Message-----
    > From: Reshad Rahman (rrahman) 
> Sent: Tuesday, May 12, 2020 9:46 AM
> To: Sterne, Jason (Nokia - CA/Ottawa) ; Martin
> Björklund 
> Cc: netmod@ietf.org
> Subject: Re: [netmod] Revision labels for submodules
> 
> Hi Jason,
> 
> On 2020-05-09, 12:52 PM, "Sterne, Jason (Nokia - CA/Ottawa)"
>  wrote:
> 
> Hi Martin,
> 
> Your approach sounds good to me. I was forgetting about the 
"editorial"
> level of change (e.g. the 3rd part of SemVer).  So I agree that moving a 
leaf
> would be an editorial change in both submodules.
> 
> But what if a module is not doing include by revision? It may indeed 
make
> sense to include by revision but it isn't mandated. For sake of argument 
here
> what if the module itself didn't change at all in this case?
> It is now mandated in section 3 of draft-ietf-netmod-yang-module-
> versioning-00.
> 
> 
> It *feels* like the right thing to do here is to consider the module 
overall
> to have an editorial change.
> 
> The revision statement of sub-modules has a scope of the file (the 
sub-
> module). It isn't clear to me whether the revision of a *module* has a 
scope
> that includes all sub-modules or if it is just a scope of the module 
file. But we
> could clarify that as part of this work.
> Because of include by revision, the module would have to change to include
> a different revision of a sub-module.
> 
> Regards,
> Reshad.
> 
> Jason
> 
> > -Original Message-
> > From: Martin Björklund 
> > Sent: Saturday, May 9, 2020 11:54 AM
> > To: rrah...@cisco.com
> > Cc: netmod@ietf.org; Sterne, Jason (Nokia - CA/Ottawa)
> > 
> > Subject: Re: [netmod] Revision labels for submodules
> >
> > "Reshad Rahman (rrahman)"  wrote:
> > > Hi,
> > >
> > > On 2020-05-08, 5:12 PM, "Martin Björklund" 
> wrote:
> > >
> > > Hi,
> > >
> > > "Reshad Rahman (rrahman)"  wrote:
> > > > Hi,
> > > >
> > > > This came up during this week's meeting. We briefly 
discussed
> whether
> > > > there's a need to version sub-modules or can we restrict 
versioning
> to
> > > > modules only. We would like to hear from the WG on this,
> especially
> > > > those with experience managing sub-modules.
> > >
> > > Yes I think this is needed.  At tail-f, there are several 
modules with
> > > many submodules.  These modules always use include by 
revision,
> and
> > > always the main module is always uddated when any submodule is
> > > updated.  It doens't make much sense IMO to not use include by
> > > revision.
>

Re: [netmod] Proposed YANG semver revision-label guidelines (draft-ietf-netmod-yang-semver)

[Reshad Rahman (rrahman)]

Jan, do you have an issue with the choice of the letter or its semantics? It 
has been mentioned that it's confusing to have 'm' and 'M'.

Regards,
Reshad.


On 2020-05-13, 10:45 AM, "netmod on behalf of Joe Clarke (jclarke)" 
 wrote:



> On May 13, 2020, at 10:04, Jan Lindblad  wrote:
> 
> Joe,
> 
> Thanks for sending this out to a wider audience. Sorry I missed the 
meeting yesterday. That particular time of week is very popular.
> 
> I think the text you propose below is good; I have no issues. For the 
record, I do have some issue relating to other pieces, especially around the 
use of the letter 'm'.

Thanks, Jan.  I missed the call yesterday, too, but I understand m|M is 
still being debated and there isn’t strong support of those letters 
specifically.

Joe

> 
> /jan
> 
> 
> 
>> On 12 May 2020, at 21:55, Joe Clarke (jclarke) 
 wrote:
>> 
>> There has been recent discussion about how to handle applying versions 
to new modules, modules in development, and revisions to modules that 
previously did not have a revision-label.  Below is proposed text to offer both 
general and IETF-specific guidelines for this.  The intent is to place this 
text in draft-ietf-netmod-yang-semver either as a new section 5 or a 
sub-section under section 3.  Before folding it in to the document, I wanted to 
get more WG eyes on this.
>> 
>> ===
>> 
>> X. Guidelines for Module Development
>> 
>> When developing a brand new module using YANG semver as its 
revision-label scheme SHOULD begin using a 0 for the MAJOR version component.  
This allows the module to disregard strict semver rules with respect to 
non-backwards-compatible changes during its initial development.  However, 
module developers MAY choose to use the semver pre-release syntax instead with 
a 1 for the MAJOR version component.  For example, an initial module 
revision-label might be 1.0.0-dev1.  If the authors choose to use the 0 MAJOR 
version component scheme, they MAY switch to the pre-release scheme with a 
MAJOR version component of 1 when the module is nearing initial release (e.g., 
a module's revision label may transition from 0.3.0 to 1.0.0-beta1 to indicate 
it is more mature and ready for testing).
>> 
>> When developing a new revision of an existing module using the YANG 
semver revision-label scheme, the intended target semver version MUST be used 
along with pre-release notation.  For example, if a released module which has a 
current revision-label of 1.0.0 is being modified and the intent is to make 
non-backwards-compatible changes, the first development MAJOR version component 
must be 2 with some pre-release notation such as -dev1, making the version 
2.0.0-dev1.  That said, every publicly available release of a module MUST have 
a unique YANG semver revision-label.  Therefore, it may be prudent to include 
the year or year and month development began (e.g., 2.0.0-201907-dev1).  As a 
module undegoes development, it is possible that the original intent changes.  
For example, a 1.0.0 version of a module that was destined to become 2.0.0 
after a development cycle may have had a scope change such that the final 
version has no non-backwards-compatible changes and becomes 1.1.0 instead.  Th
>> is change is acceptable to make during the development phase so long as 
pre-release notation is present in both versions (e.g., 2.0.0-dev3 becomes 
1.1.0-alpha1).  However, on the next development cycle, if again the new target 
release is 2.0.0, new pre-release components must be used such that every 
revision-label for a given module MUST be unique throughout its entire 
lifecycle (e.g., the first pre-release version might be 2.0.0-202005-dev1 if 
keeping the same year and month notation mentioned above).
>> 
>> When an existing IETF module is being revised, it MUST use the target 
version for the revision-label with a pre-release string that includes the 
current RFC number plus the string "bis".  For example, if the module defined 
in RFC at version 1.0.0 is being revised to include 
non-backwards-compatible changes, its development revision-labels MUST include 
2.0.0-bis.  Since they MUST also be unique, additional alphanumeric 
identifiers MUST be used (e.g., 2.0.0-bis-dev1).  Since each new bis will 
work off a new RFC number, this nomenclature ensures uniqueness for the module 
throughout its lifecycle.
>> 
>> If a module is being revised and the original module never had a 
revision-label (i.e., you wish to start using YANG semver in future module 
revisions), choose a semver value that makes the most sense based on the 
module's history.  For example, if a module started out in the pre-NMDA world 
and then had NMDA support added without removing any legacy "state" branches, 
and you are looking to add additional new features, a sensible choice for the 
target YANG semver would be 1.2.0 

Re: [netmod] Revision labels for submodules

[Reshad Rahman (rrahman)]

Hi,

On 2020-05-09, 11:57 AM, "Martin Björklund"  wrote:

Martin Björklund  wrote:
    > "Reshad Rahman (rrahman)"  wrote:
> > Hi,
> > 
> > On 2020-05-08, 5:12 PM, "Martin Björklund"  wrote:
> > 
> > Hi,
> > 
> > "Reshad Rahman (rrahman)"  wrote:
> > > Hi,
> > > 
> > > This came up during this week's meeting. We briefly discussed 
whether
> > > there's a need to version sub-modules or can we restrict 
versioning to
> > > modules only. We would like to hear from the WG on this, 
especially
> > > those with experience managing sub-modules.
> > 
> > Yes I think this is needed.  At tail-f, there are several modules 
with
> > many submodules.  These modules always use include by revision, and
> > always the main module is always uddated when any submodule is
> > updated.  It doens't make much sense IMO to not use include by
> > revision.
> > 
> > > For completeness, below is an update from Jason in github:
> > > My initial reaction is that we should not preclude the use of 
revision
> > > label with a submodule. Submodules have their own version today. 
The
> > > trick is to define (or explicitly say it is out of scope) whether 
a
> > > module version must change if any underlying submodule versions
> > > change. That gets difficult if you consider simply moving a leaf 
from
> > > one sub-module to another (without changing anything else about 
it -
> > > its context, etc).
> > 
> > Why would this be difficult?  The revision date is updated on any
> > editorial change (see 7.1.9 of RFC 7950).  So if a leaf gets moved
> > from submodule A to submodule B, then their revisions are udpated, 
and
> > hence the module's include-by revision is udpated, and hence the
> > module's revision ois updated.
> > 
> > I think what Jason meant is that by moving a leaf between submodules,
> > it's possible the module's schema didn't change.
> > So yes revision date is updated, but you can't blindly update the
> > revision-label.
> 
> Why not?

Aha, I think I understand what you mean.  And in light of Tom's
comment in the other thread, I think that using 'revision-label' in
the module and not in sub-modules makes sense.  sub-modules can still
use the date, and be included by revision (date).

That works and simplifies things.

Regards,
Reshad.

    /martin



> 
> 
> /martin
> 
> 
> > 
> > Regards,
> > Reshad.
> > 
> > /martin
> > 
> > 
> > 
> > > 
> > > Regards,
> > > Reshad.
> > > 
> > > On 2020-03-27, 5:44 PM, "netmod on behalf of Reshad Rahman 
(rrahman)"
> > >  > > rrahman=40cisco@dmarc.ietf.org> wrote:
> > > 
> > > Hi,
> > > 
> > > https://github.com/netmod-wg/yang-ver-dt/issues/49
> > > 
> > > o  3.3
> > > 
> > > Submodules MUST NOT use revision label schemes 
that could
> > > be
> > > confused
> > > with the including module's revision label scheme.
> > > 
> > >   Hmm, how do I ensure that this MUST NOT is handled
> > >   correctly?
> >     >   What
> > >   exactly does "could be confused with" mean?
> > > 
> > > Good point. What was meant by that the label space for 
modules and
> > > sub-modules are orthogonal.  e.g. the sub-module and module 
both have
> > > the same label, it shouldn't be inferred that the 2 are 
related.
> > > We'll change/clarify the text.
> > > 
> > > Regards,
> > > Reshad.
> > > 
> > > On 2020-03-20, 5:08 PM, "netmod on behalf of Reshad Rahman 
(rrahman)"
> > >  >   

Re: [netmod] Revision labels for submodules

[Reshad Rahman (rrahman)]

Hi Jason,

On 2020-05-09, 12:52 PM, "Sterne, Jason (Nokia - CA/Ottawa)" 
 wrote:

Hi Martin,

Your approach sounds good to me. I was forgetting about the "editorial" 
level of change (e.g. the 3rd part of SemVer).  So I agree that moving a leaf 
would be an editorial change in both submodules.

But what if a module is not doing include by revision? It may indeed make 
sense to include by revision but it isn't mandated. For sake of argument here 
what if the module itself didn't change at all in this case?
It is now mandated in section 3 of draft-ietf-netmod-yang-module-versioning-00.


It *feels* like the right thing to do here is to consider the module 
overall to have an editorial change.

The revision statement of sub-modules has a scope of the file (the 
sub-module). It isn't clear to me whether the revision of a *module* has a 
scope that includes all sub-modules or if it is just a scope of the module 
file. But we could clarify that as part of this work.
Because of include by revision, the module would have to change to include a 
different revision of a sub-module.

Regards,
Reshad.

Jason

> -Original Message-
> From: Martin Björklund 
> Sent: Saturday, May 9, 2020 11:54 AM
> To: rrah...@cisco.com
> Cc: netmod@ietf.org; Sterne, Jason (Nokia - CA/Ottawa)
> 
> Subject: Re: [netmod] Revision labels for submodules
> 
> "Reshad Rahman (rrahman)"  wrote:
> > Hi,
> >
> > On 2020-05-08, 5:12 PM, "Martin Björklund"  wrote:
> >
> > Hi,
> >
> > "Reshad Rahman (rrahman)"  wrote:
> > > Hi,
> > >
> > > This came up during this week's meeting. We briefly discussed 
whether
> > > there's a need to version sub-modules or can we restrict 
versioning to
> > > modules only. We would like to hear from the WG on this, 
especially
> > > those with experience managing sub-modules.
> >
> > Yes I think this is needed.  At tail-f, there are several modules 
with
> > many submodules.  These modules always use include by revision, and
> > always the main module is always uddated when any submodule is
> > updated.  It doens't make much sense IMO to not use include by
> > revision.
> >
> > > For completeness, below is an update from Jason in github:
> > > My initial reaction is that we should not preclude the use of 
revision
> > > label with a submodule. Submodules have their own version today. 
The
> > > trick is to define (or explicitly say it is out of scope) whether 
a
> > > module version must change if any underlying submodule versions
> > > change. That gets difficult if you consider simply moving a leaf 
from
> > > one sub-module to another (without changing anything else about 
it -
> > > its context, etc).
> >
> > Why would this be difficult?  The revision date is updated on any
> > editorial change (see 7.1.9 of RFC 7950).  So if a leaf gets moved
> > from submodule A to submodule B, then their revisions are udpated, 
and
> > hence the module's include-by revision is udpated, and hence the
> > module's revision ois updated.
> >
> > I think what Jason meant is that by moving a leaf between submodules,
> > it's possible the module's schema didn't change.
> > So yes revision date is updated, but you can't blindly update the
> > revision-label.
> 
> Why not?
> 
> 
> /martin
> 
> 
> >
> > Regards,
> > Reshad.
> >
> > /martin
> >
> >
> >
> > >
> > > Regards,
> > > Reshad.
> > >
> > > On 2020-03-27, 5:44 PM, "netmod on behalf of Reshad Rahman
> (rrahman)"
> > >  > > rrahman=40cisco@dmarc.ietf.org> wrote:
> > >
> > > Hi,
> > >
> > > https://github.com/netmod-wg/yang-ver-dt/issues/49
> > >
> > > o  3.3
> > >
> > > Submodules MUST NOT use revision label schemes 
that could
> > > be
> > > confused
> > > with the including module's revision label scheme.
> > >
> &

Re: [netmod] Revision labels for submodules

[Reshad Rahman (rrahman)]

Hi,

On 2020-05-08, 5:12 PM, "Martin Björklund"  wrote:

Hi,

    "Reshad Rahman (rrahman)"  wrote:
> Hi,
> 
> This came up during this week's meeting. We briefly discussed whether
> there's a need to version sub-modules or can we restrict versioning to
> modules only. We would like to hear from the WG on this, especially
> those with experience managing sub-modules.

Yes I think this is needed.  At tail-f, there are several modules with
many submodules.  These modules always use include by revision, and
always the main module is always uddated when any submodule is
updated.  It doens't make much sense IMO to not use include by
revision.

> For completeness, below is an update from Jason in github:
> My initial reaction is that we should not preclude the use of revision
> label with a submodule. Submodules have their own version today. The
> trick is to define (or explicitly say it is out of scope) whether a
> module version must change if any underlying submodule versions
> change. That gets difficult if you consider simply moving a leaf from
> one sub-module to another (without changing anything else about it -
> its context, etc).

Why would this be difficult?  The revision date is updated on any
editorial change (see 7.1.9 of RFC 7950).  So if a leaf gets moved
from submodule A to submodule B, then their revisions are udpated, and
hence the module's include-by revision is udpated, and hence the
module's revision ois updated.

I think what Jason meant is that by moving a leaf between submodules, it's 
possible the module's schema didn't change.
So yes revision date is updated, but you can't blindly update the 
revision-label.

Regards,
Reshad.

/martin



> 
> Regards,
> Reshad.
    > 
> On 2020-03-27, 5:44 PM, "netmod on behalf of Reshad Rahman (rrahman)"
>  rrahman=40cisco@dmarc.ietf.org> wrote:
> 
> Hi,
> 
> https://github.com/netmod-wg/yang-ver-dt/issues/49
> 
> o  3.3
> 
> Submodules MUST NOT use revision label schemes that could 
be
> confused
> with the including module's revision label scheme.
> 
>   Hmm, how do I ensure that this MUST NOT is handled 
correctly?
>   What
>   exactly does "could be confused with" mean?
> 
> Good point. What was meant by that the label space for modules and
> sub-modules are orthogonal.  e.g. the sub-module and module both have
> the same label, it shouldn't be inferred that the 2 are related.
>     We'll change/clarify the text.
> 
> Regards,
> Reshad.
> 
> On 2020-03-20, 5:08 PM, "netmod on behalf of Reshad Rahman (rrahman)"
>  rrahman=40cisco@dmarc.ietf.org> wrote:
> 
> Hi Martin,
> 
> We've opened issues to track your review comments (see below). 
Will
> kick off separate therads for each issue.
> 
> 
https://github.com/netmod-wg/yang-ver-dt/issues?q=is%3Aissue+is%3Aopen+label%3Aupdated-mod-rev-handling
> 
> Regards,
> Reshad.
> 
> On 2020-03-10, 3:31 PM, "netmod on behalf of Martin Björklund"
>  wrote:
> 
> Hi,
> 
> Here are my review comments of
> draft-verdt-netmod-yang-module-versioning-01.
> 
> 
> 
> o  3.1.1
> 
> o  In statements that have any data definition statements 
as
>substatements, those data definition substatements MAY 
be
>reordered, as long as they do not change the ordering 
or
>any "rpc"
>"input" substatements.
> 
>   I think this needs to capture that no descendant statements 
to
>   "input" can be reordered.  Same for "output" (note, "input" 
and
>   "output" in both "rpc" and "action").
> 
> 
> o  3.3
> 
> All revision labels that match the pattern for the 
"version"
> typedef in the ietf-yang-semver YANG module MUST

Re: [netmod] Revision label in filename

[Reshad Rahman (rrahman)]

Hi,

We discussed using something along the lines of 
module-or-submodule-name['@'date]['#'revision-label].yang. Questions to the WG:
1) Is there a need for both date and revision-label or is one of them enough?
2) If we have both, what's the impact of having "#revision-label" on 
implementations which search by date?

Regards,
Reshad.

On 2020-03-27, 5:44 PM, "netmod on behalf of Reshad Rahman (rrahman)" 
 wrote:

Hi,

https://github.com/netmod-wg/yang-ver-dt/issues/50

o  3.3

  In the filename of a YANG module, where it takes the form: 
module-
  or-submodule-name ['@' revision-label] ( '.yang' / '.yin' )

  Should this section update 5.2 of RFC 7950?  I know that 5.2 just
  says "SHOULD".  But existing tools implement this SHOULD, and they
  need to be updated to handle this new convention.

  But I wonder if this a good idea.  It means that a tool that looks
  for a module with a certain revision date cannot simply check the
  filenames, but need to parse all available modules (wijust to 
find the

We agree that there is an impact on searching by date. We put this in to 
have the ability to search by revision-label, otherwise we can search just by 
date for a module which uses revision-label.
We had also discussed using different limiter for the label and have 
something along the lines of: 
module-or-submodule-name['@'date]['#'revision-label].yang
It'd seem that updating 7950 would be a good idea whichever way we go.

Regards,
Reshad.


On 2020-03-20, 5:08 PM, "netmod on behalf of Reshad Rahman (rrahman)" 
 wrote:

Hi Martin,

We've opened issues to track your review comments (see below). Will 
kick off separate therads for each issue.


https://github.com/netmod-wg/yang-ver-dt/issues?q=is%3Aissue+is%3Aopen+label%3Aupdated-mod-rev-handling

Regards,
Reshad.

On 2020-03-10, 3:31 PM, "netmod on behalf of Martin Björklund" 
 wrote:

Hi,

Here are my review comments of
draft-verdt-netmod-yang-module-versioning-01.



o  3.1.1

o  In statements that have any data definition statements as
   substatements, those data definition substatements MAY be
   reordered, as long as they do not change the ordering or any 
"rpc"
   "input" substatements.

  I think this needs to capture that no descendant statements to
  "input" can be reordered.  Same for "output" (note, "input" and
  "output" in both "rpc" and "action").


o  3.3

All revision labels that match the pattern for the "version"
typedef in the ietf-yang-semver YANG module MUST be interpreted 
as
YANG semantic version numbers.

  I don't think this is a good idea.  Seems like a layer violation.
  What if my project use another dialect of semver, that wouldn't be
  possible with this rule.  I think this needs to be removed.


o  3.3

Submodules MUST NOT use revision label schemes that could be 
confused
with the including module's revision label scheme.

  Hmm, how do I ensure that this MUST NOT is handled correctly?  
What
  exactly does "could be confused with" mean?


o  3.3

  In the filename of a YANG module, where it takes the form: 
module-
  or-submodule-name ['@' revision-label] ( '.yang' / '.yin' )

  Should this section update 5.2 of RFC 7950?  I know that 5.2 just
  says "SHOULD".  But existing tools implement this SHOULD, and they
  need to be updated to handle this new convention.

  But I wonder if this a good idea.  It means that a tool that looks
  for a module with a certain revision date cannot simply check the
  filenames, but need to parse all available modules (wijust to 
find the 



o  3.4

 leaf imperial-temperature {
   type int64;
   units "degrees Fahrenheit";
   status deprecated {
 rev:status-description
   "Imperial measurements are being phased o

Re: [netmod] Revision labels for submodules

[Reshad Rahman (rrahman)]

Hi,

This came up during this week's meeting. We briefly discussed whether there's a 
need to version sub-modules or can we restrict versioning to modules only. We 
would like to hear from the WG on this, especially those with experience 
managing sub-modules.

For completeness, below is an update from Jason in github:
My initial reaction is that we should not preclude the use of revision label 
with a submodule. Submodules have their own version today. The trick is to 
define (or explicitly say it is out of scope) whether a module version must 
change if any underlying submodule versions change. That gets difficult if you 
consider simply moving a leaf from one sub-module to another (without changing 
anything else about it - its context, etc).

Regards,
Reshad.

On 2020-03-27, 5:44 PM, "netmod on behalf of Reshad Rahman (rrahman)" 
 wrote:

Hi,

https://github.com/netmod-wg/yang-ver-dt/issues/49

o  3.3

Submodules MUST NOT use revision label schemes that could be 
confused
with the including module's revision label scheme.

  Hmm, how do I ensure that this MUST NOT is handled correctly?  
What
  exactly does "could be confused with" mean?

Good point. What was meant by that the label space for modules and 
sub-modules are orthogonal.  e.g. the sub-module and module both have the same 
label, it shouldn't be inferred that the 2 are related. 
We'll change/clarify the text.

Regards,
Reshad.

On 2020-03-20, 5:08 PM, "netmod on behalf of Reshad Rahman (rrahman)" 
 wrote:

Hi Martin,

We've opened issues to track your review comments (see below). Will 
kick off separate therads for each issue.


https://github.com/netmod-wg/yang-ver-dt/issues?q=is%3Aissue+is%3Aopen+label%3Aupdated-mod-rev-handling

Regards,
Reshad.

On 2020-03-10, 3:31 PM, "netmod on behalf of Martin Björklund" 
 wrote:

Hi,

Here are my review comments of
draft-verdt-netmod-yang-module-versioning-01.



o  3.1.1

o  In statements that have any data definition statements as
   substatements, those data definition substatements MAY be
   reordered, as long as they do not change the ordering or any 
"rpc"
   "input" substatements.

  I think this needs to capture that no descendant statements to
  "input" can be reordered.  Same for "output" (note, "input" and
  "output" in both "rpc" and "action").


o  3.3

All revision labels that match the pattern for the "version"
typedef in the ietf-yang-semver YANG module MUST be interpreted 
as
YANG semantic version numbers.

  I don't think this is a good idea.  Seems like a layer violation.
  What if my project use another dialect of semver, that wouldn't be
  possible with this rule.  I think this needs to be removed.


o  3.3

Submodules MUST NOT use revision label schemes that could be 
confused
with the including module's revision label scheme.

  Hmm, how do I ensure that this MUST NOT is handled correctly?  
What
  exactly does "could be confused with" mean?


o  3.3

  In the filename of a YANG module, where it takes the form: 
module-
  or-submodule-name ['@' revision-label] ( '.yang' / '.yin' )

  Should this section update 5.2 of RFC 7950?  I know that 5.2 just
  says "SHOULD".  But existing tools implement this SHOULD, and they
  need to be updated to handle this new convention.

  But I wonder if this a good idea.  It means that a tool that looks
  for a module with a certain revision date cannot simply check the
  filenames, but need to parse all available modules (wijust to 
find the 



o  3.4

 leaf imperial-temperature {
   type int64;
   units "degrees Fahrenheit";
   status deprecated {
 rev:status-description
   "Imperial measurements are being phased out in favor
of their metric equivalents.  Use metric-temperature
instead.";

Re: [netmod] status-description

[Reshad Rahman (rrahman)]

What are your thoughts on having description statement under status in 
yang-next? Is it the same as what you’ve stated on status-description extension?

I believe the extension is useful, although I do see the point made that an 
extra statement leads to extra complexity. But using description statement in 
yang-next should not be an issue?

Regards,
Reshad.

From: 'Andy Bierman' 
Date: Monday, May 4, 2020 at 1:32 PM
To: Martin Björklund 
Cc: Balazs Lengyel , "Reshad Rahman (rrahman)" 
, NetMod WG 
Subject: Re: [netmod] status-description



On Mon, May 4, 2020 at 9:38 AM Martin Björklund 
mailto:mbj%2bi...@4668.se>> wrote:
Hi,

Balázs Lengyel 
mailto:balazs.leng...@ericsson.com>> wrote:
> Hello,
> While status-description is not a critical part of this work, it is
> still useful, does not harm and is such a small addition, I do not
> understand why Martin objects.

Every additional statement adds to the overall complexity.  As Jason
explained, this particular statement doesn't really help much.


+1

We should not start down the path of specialized description statements.

I was part of a design team many years ago that was trying to
figure out why engineers were having so much trouble writing MIB modules.
One significant finding: people disliked working on MIBs because there were so
many special little rules (CLRs) for every little detail in the module.

IMO we are starting to make the same mistake with YANG.


/martin

Andy


>
> So why is status-description good:
> Sometimes additional information is needed about deprecation,
> obsolescence:
> - is the item still fully functional?
> - when will its functionality be removed?
> - when will the schema node itself be removed?
> - is there a replacement or workaround that could/should be used instead
> - of deprecated/obsolete item?
> The text can be used by tools. Using a separate statement to provide
> this
> information is a method to separate the main description from this
> status specific description.
> In most cases both in the CLI and on NMS GUIs only the description is
> displayed.
> However there is a possibility  to display the status information too.
>
> In a way it is similar why we have separate description, contact,
> reference, organization statements under module.
> All these are just text, they could all be pushed under a single
> description statement. Tools can't act on these automatically, still
> it is good to separate them.
>
> Regards Balazs
>
> -Original Message-
> From: netmod mailto:netmod-boun...@ietf.org>> On 
> Behalf Of Sterne, Jason
> (Nokia - CA/Ottawa)
> Sent: 2020. április 29., szerda 23:38
> To: Reshad Rahman (rrahman) 
> mailto:40cisco@dmarc.ietf.org>>;
> Martin Björklund mailto:mbj%2bi...@4668.se>>; 
> netmod@ietf.org<mailto:netmod@ietf.org>
> Subject: Re: [netmod] status-description (WAS Re: mbj review of
> draft-verdt-netmod-yang-module-versioning-01)
>
> I think we could wait until YANG 2.0 to add a description to the
> status.
>
> Without a status description, an intelligent "YANG diff" of the models
> would produce this:
> a) new status deprecated statement
> b) change to a description
>
> With a status description we'd identify this:
> a) new status deprecated statement
> b) new status description
>
> In both cases it is (a) that identifies the most clear information.
>
> In both cases (b) provides no additional information that can be acted
> upon in an automated fashion. The tool could only flag that (b)
> occurred in both cases and a human would then have to go look at it.
>
> If the only change between two versions of a module was a status
> description change, then again a human would have to take a look. If
> we add some sort of "nbc" tag to the leaf for tooling, then it also
> doesn't matter which description changed.
>
> Jason
>
>
> > -Original Message-
> > From: netmod mailto:netmod-boun...@ietf.org>> On 
> > Behalf Of Reshad Rahman
> > (rrahman)
> > Sent: Friday, March 27, 2020 5:43 PM
> > To: Martin Björklund mailto:mbj%2bi...@4668.se>>; 
> > netmod@ietf.org<mailto:netmod@ietf.org>
> > Subject: [netmod] rev:status-description (WAS Re: mbj review of
> > draft-verdt-
> > netmod-yang-module-versioning-01)
> >
> > Hi,
> >
> > https://github.com/netmod-wg/yang-ver-dt/issues/51
> >
> > o  3.4
> >
> >  leaf imperial-temperature {
> >type int64;
> >units "degrees Fahrenheit";
> >status deprecated {
> >  rev:status-description
> >"Imperial measurement

Re: [netmod] YANG action not allowed at root?

[Reshad Rahman (rrahman)]

I don’t know the history on this but the intent is to have action tied to a 
data node.

https://tools.ietf.org/html/rfc7950#section-7.15
   The difference between an action and an rpc is that an action is tied
   to a node in the datastore, whereas an rpc is not.  When an action is
   invoked, the node in the datastore is specified along with the name
   of the action and the input parameters.

Regards,
Reshad.

From: netmod  on behalf of "Sterne, Jason (Nokia - 
CA/Ottawa)" 
Date: Thursday, April 30, 2020 at 11:08 AM
To: "netmod@ietf.org" 
Subject: [netmod] YANG action not allowed at root?

Hi all,

I was a bit surprised to find this in section 7.15 of 7950 recently:

   Since an action cannot be defined at the top level of a module or in
   a "case" statement, it is an error if a grouping that contains an
   action at the top of its node hierarchy is used at the top level of a
   module or in a case definition.

I realize that actions can be placed down in a schema tree (i.e. sit in the 
context of a container or list), but why is it phrased that they *must* be in a 
container?

RPCs are limited to being at the root. I would have thought actions could be 
anywhere (root or down in the tree).

Jason


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

Re: [netmod] yang-module-versioning: revision-label scheme

[Reshad Rahman (rrahman)]

The reason we're allowing for different versioning schemes is that no single 
versioning scheme has been unanimous.  The proposal is for IETF to use 
yang-semver. Some vendors and other publishers of YANG artifacts may use 
yang-semver, while some may define their own scheme.

While this in theory allows for an open ended number of versioning schemes, I 
don't believe this will be the case. No, I'm not taking over-under bets (

Regards,
Reshad.

On 2020-04-28, 12:02 PM, "Juergen Schoenwaelder" 
 wrote:

I may be naive and not understand things correctly but an open ended
set of versioning schemes scares me. I do not see how this leads to
interoperability.

Perhaps all the versioning work should be experimental until we know
what the winning solution is?

First semver was the solution, then we got semver plus extensions,
and now we move full speed ahead to support an open ended number of
versioning schemes?

/js (who probably should have kept silent)

On Mon, Apr 27, 2020 at 03:42:04PM +0000, Reshad Rahman (rrahman) wrote:
> Hi,
> 
> There was a 
discussion<https://mailarchive.ietf.org/arch/browse/netmod/?q=%22Interpreting%20revision%20labels%20as%20YANG%20semantic%20version%20numbers%22>
 on the need to have an extension which specifies which versioning scheme a 
module is using.
> 
> The authors have identified 2 options:
> 
>   1.  One extension statement with a parameter which specifies the scheme 
being used. E.g. revision-label-schema(ietf-yang-semver), 
revision-label-schema(sdoX-yang). We’d need the parameter to be registered with 
IANA.
>   2.  One extension statement per revision-scheme. E.g. 
revision-label-scheme-ietf-yang-semver, revision-label-scheme-sdoX-yang.
> 
> The authors have  a preference for option 1, we believe it makes things 
simpler. We would like to hear from the WG if there’s any concerns, suggestions 
etc.
> 
> Regards,
> Reshad.

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


-- 
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-module-versioning: revision-label scheme

[Reshad Rahman (rrahman)]

Hi,

On 2020-04-28, 11:25 AM, "netmod on behalf of Martin Björklund" 
 wrote:

Hi,

    "Reshad Rahman \(rrahman\)"  wrote:
> Hi,
> 
> There was a
> 
discussion<https://mailarchive.ietf.org/arch/browse/netmod/?q=%22Interpreting%20revision%20labels%20as%20YANG%20semantic%20version%20numbers%22>
> on the need to have an extension which specifies which versioning
> scheme a module is using.
> 
> The authors have identified 2 options:
> 
>   1.  One extension statement with a parameter which specifies the
>   scheme being used.

Ok, I understand what this means...

>   E.g. revision-label-schema(ietf-yang-semver),
>   revision-label-schema(sdoX-yang).

... but I don't understand these examples.   I expected something
like:

rev:revision-label-schema yang-semver;

rev:revision-label-schema semver-2.0;
You are correct. I was just using free-form, not the correct syntax.

>   We’d need the parameter to be
>   registered with IANA.

An alternative could be to use identities:

rev:revision-label-schema ysmever:yang-semver;

rev:revision-label-schema ex:semver-2.0;
Ack, identities also came up during our discussions also. I can't think of any 
reason not to use identities in this case.

>   2.  One extension statement per
>   revision-scheme. E.g. revision-label-scheme-ietf-yang-semver,
>   revision-label-scheme-sdoX-yang.

I prefer a single statement.
Good.

Regards,
Reshad.

> The authors have a preference for option 1, we believe it makes things
> simpler. We would like to hear from the WG if there’s any concerns,
> suggestions etc.


/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

[netmod] yang-module-versioning: revision-label scheme

[Reshad Rahman (rrahman)]

Hi,

There was a 
discussion
 on the need to have an extension which specifies which versioning scheme a 
module is using.

The authors have identified 2 options:

  1.  One extension statement with a parameter which specifies the scheme being 
used. E.g. revision-label-schema(ietf-yang-semver), 
revision-label-schema(sdoX-yang). We’d need the parameter to be registered with 
IANA.
  2.  One extension statement per revision-scheme. E.g. 
revision-label-scheme-ietf-yang-semver, revision-label-scheme-sdoX-yang.

The authors have  a preference for option 1, we believe it makes things 
simpler. We would like to hear from the WG if there’s any concerns, suggestions 
etc.

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

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

[Reshad Rahman (rrahman)]

Makes sense, it’s good with me.

Regards,
Reshad.

From: netmod  on behalf of "Rob Wilton (rwilton)" 

Date: Friday, April 24, 2020 at 3:34 PM
To: Kent Watsen , "netmod@ietf.org" 
Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6031)

Hi Kent,

Thanks for creating the issue.

I think that errata falls under section 7 of 
https://www.ietf.org/about/groups/iesg/statements/processing-rfc-errata/, and 
could be classified as “Hold for Document Update”.  I.e. “Changes that modify 
the working of a protocol to something that might be different from the 
intended consensus when the document was approved should be either Hold for 
Document Update or Rejected. Deciding between these two depends on judgment. 
Changes that are clearly modifications to the intended consensus, or involve 
large textual changes, should be Rejected. In unclear situations, small changes 
can be Hold for Document Update.”

I think that the consensus of the long term fix (e.g. in YANG 1.2) is that 
“require-instance” should be allowed under typedefs that refined types that 
allow it.

Pragmatically, I think that we can mark this errata is a “Hold for Document 
Update”, with the accompanying errata notes (derived from Radek’s comments) 
changed to:

“The document does not specify whether the “require-instance” keyword is 
allowed in typedef refinements derived from the “leafref” or 
“instance-identifier” base types, but it is anticipated that a future revision 
of YANG would allow this.   It is suggested that modules using YANG language 
versions 1 [RFC 6020] and 1.1 [RFC 7950] avoid using this construct, YANG 
module validation tools flag a warning if this construct is used, but 
implementations allow this if possible.”

Does anyone object to this course of action (or wishes to refine my errata 
notes)?

Regards,
Rob


From: Kent Watsen 
Sent: 23 April 2020 17:59
To: Andy Bierman 
Cc: Radek Krejci ; Juergen Schoenwaelder 
; Martin Björklund ; 
netmod@ietf.org; Rob Wilton (rwilton) 
Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6031)

The consensus seems to be that:
  - the errata should be rejected
- Rob, do you agree?
  - YANG-next should fix it later
- I created https://github.com/netmod-wg/yang-next/issues/104
  - implementations should try to do the right thing now
- Radek’s suggestion below LGTM!


Tallies:
   - for reject: Andy, Martin, Juergen, and Kent
   - for accept: Radek, and Balazs
   - unclear: Lada, Rob, and Jason


Kent // as co-chair


On Apr 14, 2020, at 10:35 AM, Andy Bierman 
mailto:a...@yumaworks.com>> wrote:

Hi,

I agree with Juergen that this errata should be rejected and the issue resolved 
in yang-next.
No IETF module should use this construct. It is easy to convert to an 
equivalent form that is not under dispute.


Andy


On Tue, Apr 14, 2020 at 6:40 AM Radek Krejci 
mailto:rkre...@cesnet.cz>> wrote:
Hi,
Dne 09. 04. 20 v 17:26 Kent Watsen napsal(a):


On Apr 6, 2020, at 3:42 AM, Juergen Schoenwaelder 
mailto:j.schoenwael...@jacobs-university.de>>
 wrote:

The definition I found in RFC 8639 is this:

   leaf stream {
 type stream-ref {
   require-instance false;
 }
 mandatory true;
 description
   "Indicates the event stream to be considered for
this subscription.";
   }

This could be changed to:

   leaf stream {
 type leafref {
path "/sn:streams/sn:stream/sn:name";
   require-instance false;
 }
 mandatory true;
 description
   "Indicates the event stream to be considered for
this subscription.";
   }

I can confirm that `yanglint` validates the module cleanly after this change.



On Apr 6, 2020, at 7:38 AM, Martin Björklund 
mailto:mbj+i...@4668.se>> wrote:

I think the correct fix is to change the text so that
"require-instance" is not classified as a restriction and keep the
default.

Agreed.


Also, I think that it would be easiest (for backwards
compatibility w/ existing models) to allow "require-inetance" to be
changed in derived types.

However, this cannot imo be done in an errata.

While I appreciate Radek and Michal’s perspective, I also think that is would 
be best for the community for `yanglint` to support this, as they are published 
modules doing it.


I don't feel as an expert for IETF processes, so I don't know if this issue can 
be solved in errata or not (and I'm not sure there is a consensus on this in 
mailing list). For the implementation, I would appreciate at least a consensus 
on a solution. So far I saw opinions to allow it, to disallow and also to make 
it implementation-specific (which means in fact to disallow from the authors 
perspective, since there can be a tool disallowing it and we are saying that 
such a tool is ok). So, there is no clear way for implementors, which means 
problems for interoperability - there will be always someone unhappy and so far 
I don't know what is the major opinion 

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

[Reshad Rahman (rrahman)]

I finally caught up to this thread. I agree with concerns raised by Radek and 
Balazs, but as others have mentioned an errata doesn’t seem to be the right 
medium for this. OTOH, yang-next might be too far away…. Could we do an update 
to RF7950 just for this? I realize it’s lots of work/overhead for “just” this 
issue.

Regards,
Reshad.

From: netmod  on behalf of Kent Watsen 

Date: Thursday, April 23, 2020 at 12:59 PM
To: 'Andy Bierman' 
Cc: "netmod@ietf.org" , "Rob Wilton (rwilton)" 

Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6031)

The consensus seems to be that:
  - the errata should be rejected
- Rob, do you agree?
  - YANG-next should fix it later
- I created https://github.com/netmod-wg/yang-next/issues/104
  - implementations should try to do the right thing now
- Radek’s suggestion below LGTM!


Tallies:
   - for reject: Andy, Martin, Juergen, and Kent
   - for accept: Radek, and Balazs
   - unclear: Lada, Rob, and Jason


Kent // as co-chair



On Apr 14, 2020, at 10:35 AM, Andy Bierman 
mailto:a...@yumaworks.com>> wrote:

Hi,

I agree with Juergen that this errata should be rejected and the issue resolved 
in yang-next.
No IETF module should use this construct. It is easy to convert to an 
equivalent form that is not under dispute.


Andy


On Tue, Apr 14, 2020 at 6:40 AM Radek Krejci 
mailto:rkre...@cesnet.cz>> wrote:
Hi,
Dne 09. 04. 20 v 17:26 Kent Watsen napsal(a):



On Apr 6, 2020, at 3:42 AM, Juergen Schoenwaelder 
mailto:j.schoenwael...@jacobs-university.de>>
 wrote:

The definition I found in RFC 8639 is this:

   leaf stream {
 type stream-ref {
   require-instance false;
 }
 mandatory true;
 description
   "Indicates the event stream to be considered for
this subscription.";
   }

This could be changed to:

   leaf stream {
 type leafref {
path "/sn:streams/sn:stream/sn:name";
   require-instance false;
 }
 mandatory true;
 description
   "Indicates the event stream to be considered for
this subscription.";
   }


I can confirm that `yanglint` validates the module cleanly after this change.



On Apr 6, 2020, at 7:38 AM, Martin Björklund 
mailto:mbj+i...@4668.se>> wrote:

I think the correct fix is to change the text so that
"require-instance" is not classified as a restriction and keep the
default.

Agreed.



Also, I think that it would be easiest (for backwards
compatibility w/ existing models) to allow "require-inetance" to be
changed in derived types.

However, this cannot imo be done in an errata.

While I appreciate Radek and Michal’s perspective, I also think that is would 
be best for the community for `yanglint` to support this, as they are published 
modules doing it.


I don't feel as an expert for IETF processes, so I don't know if this issue can 
be solved in errata or not (and I'm not sure there is a consensus on this in 
mailing list). For the implementation, I would appreciate at least a consensus 
on a solution. So far I saw opinions to allow it, to disallow and also to make 
it implementation-specific (which means in fact to disallow from the authors 
perspective, since there can be a tool disallowing it and we are saying that 
such a tool is ok). So, there is no clear way for implementors, which means 
problems for interoperability - there will be always someone unhappy and so far 
I don't know what is the major opinion to go.

So far, I tend to allow it (accept by libyang), but print warning to warn 
authors about possible problems (some tool can refuse such a module). Is it ok?

Radek



As an aside, I feel that all modules should be tested against all available 
validation tools during the publication process, but to find issues in the 
modules and well as possibly improve the tools.

Sadly, I only have `yanglint` and `yangson` available to me.  I just checked 
for the “yang validator” project, but both 
www.yangvalidator.com and 
https://www.yangcatalog.org/yangvalidator seem to be down.


Kent // contributor


___
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] versioning procedures (RFC vs. I-D)

[Reshad Rahman (rrahman)]

This is being tracked via https://github.com/netmod-wg/yang-ver-dt/issues/56

Regarding this:
The BC vs. NBC distinction is not relevant for a work-in-progress.
We have seen many times in this WG where a NBC change was made
and then later undone.  There is no value in tracking the module during 
development.

It might not be relevant/important during the multiple initial revisions. But 
when we reach (WG)LC, I think it’s an important piece of information.

Regards,
Reshad.

From: 'Andy Bierman' 
Date: Thursday, April 2, 2020 at 12:02 PM
To: "Reshad Rahman (rrahman)" 
Cc: Italo Busi , "Joe Clarke (jclarke)" 
, NetMod WG 
Subject: Re: [netmod] versioning procedures (RFC vs. I-D)

Hi,

I agree that a revision-label could be useful in an I-D but not to indicate NBC 
changes (because it doesn't).
The rules need to be clear and simple with no exceptions.

 1) Special version 0.x.y contains NO NBC information
 Major version = 0 means the module has no published version

 2) First published version is 1.0.0

 3) The revision-label in an unpublished module has a special form which simply 
identifies
  the source of the development and the iteration of the work-in-progress.
  You can't really pick the next published label until the module is ready.

From my example:

draft-00:   0.1.0
draft-01:   0.2.0
draft-02:   0.3.0
RFC-1:1.0.0
bis-draft-00:   1.0.0+1
bis-draft-01:   1.0.0+2
bis-draft-02:   1.0.0+3
[repeat NBC step bis-draft-02 10 times]  1.0.0+4 .. 1.0.0+13
RFC-2:  2.0.0   (in general: 1.0.1 or 1.1.0 or 2.0.0)

The BC vs. NBC distinction is not relevant for a work-in-progress.
We have seen many times in this WG where a NBC change was made
and then later undone.  There is no value in tracking the module during 
development.


Andy


On Thu, Apr 2, 2020 at 7:46 AM Reshad Rahman (rrahman) 
mailto:rrah...@cisco.com>> wrote:


From: 'Andy Bierman' mailto:a...@yumaworks.com>>
Date: Thursday, April 2, 2020 at 10:26 AM
To: "Reshad Rahman (rrahman)" mailto:rrah...@cisco.com>>
Cc: Italo Busi mailto:italo.b...@huawei.com>>, "Joe 
Clarke (jclarke)" mailto:jcla...@cisco.com>>, NetMod WG 
mailto:netmod@ietf.org>>
Subject: Re: [netmod] versioning procedures (RFC vs. I-D)



On Thu, Apr 2, 2020 at 4:11 AM Reshad Rahman (rrahman) 
mailto:rrah...@cisco.com>> wrote:
Hi,

From: Italo Busi mailto:italo.b...@huawei.com>>
Date: Thursday, April 2, 2020 at 5:06 AM
To: "Reshad Rahman (rrahman)" mailto:rrah...@cisco.com>>, 
'Andy Bierman' mailto:a...@yumaworks.com>>, "Joe Clarke 
(jclarke)" mailto:jcla...@cisco.com>>
Cc: NetMod WG mailto:netmod@ietf.org>>
Subject: RE: [netmod] versioning procedures (RFC vs. I-D)

Reshad,

My doubt and, if I understand well also Andy’s question, is about the fact that 
before publishing an RFC-bis with e.g., 1.1.0, we will have a set of 
Internet-Drafts updating the RFC with 1.0.0

What versions should be used in the YANG modules published in these 
Internet-Drafts?

Think about the following scenario: -00 version provide BC changes to the RFC 
module but the -01 version provide NBC changes to what has been added in the 
-00 module (thus the -01 version is BC with the RFC 1.0.0 module but NBC with 
the -00 version module)
 So bis 00 would be 1.1.0 (BC with RFC module).
Bis 01 should be updated according to its relationship to the RFC module (bis 
00 doesn’t matter anymore), when RFC bis is published it won’t have the full 
history.

Hope I correctly understood your question.


This semver plan is not very intuitive and not sure it works.

draft-00

   container the-container; version 0.1.0  OK

draft-01:
   container my-container; version 0.2.0;   rules violated; NBC 
should force 1.0.0

draft-02:

container my-container {   version 0.3.0; should be 1.1.0
leaf my-leaf { type int32; }
}

RFC-1:

container my-container {   version 1.0.0;  should be 2.0.0 
according to NBC rules
leaf my-leaf { type uint32; }
}

bis-draft-00:

   container my-container {   version 1.1.0; OK
leaf my-leaf { type uint32; }
leaf another-leaf { type int32; }
}

bis-draft-01:

  container my-container {  diff against RFC-1:  version 1.1.0 
but already used; use 1.2.0?
leaf my-leaf { type uint32; }
leaf another-leaf { type uint32; }
}

bis-draft-02:

  container example-my-container {  diff against RFC-1:  
version 2.0.0 but use 1.3.0 instead?
leaf my-leaf { type uint32; }
leaf another-leaf { type uint32; }
}

[repeat NBC step bis-draft-02 10 times now up to version 12.0.0 or is it 
1.13.0? something else?

RFC-2:   publish draft-12 as RFC-2: now change the label from 1.13.0 to 2.0.0? 
or leave it 12.0.0?

IMO it is very confusing that the stated rules are so inconsistent and are 
violated so many ways.
There 

Re: [netmod] versioning procedures (RFC vs. I-D)

[Reshad Rahman (rrahman)]

From: 'Andy Bierman' 
Date: Thursday, April 2, 2020 at 10:26 AM
To: "Reshad Rahman (rrahman)" 
Cc: Italo Busi , "Joe Clarke (jclarke)" 
, NetMod WG 
Subject: Re: [netmod] versioning procedures (RFC vs. I-D)



On Thu, Apr 2, 2020 at 4:11 AM Reshad Rahman (rrahman) 
mailto:rrah...@cisco.com>> wrote:
Hi,

From: Italo Busi mailto:italo.b...@huawei.com>>
Date: Thursday, April 2, 2020 at 5:06 AM
To: "Reshad Rahman (rrahman)" mailto:rrah...@cisco.com>>, 
'Andy Bierman' mailto:a...@yumaworks.com>>, "Joe Clarke 
(jclarke)" mailto:jcla...@cisco.com>>
Cc: NetMod WG mailto:netmod@ietf.org>>
Subject: RE: [netmod] versioning procedures (RFC vs. I-D)

Reshad,

My doubt and, if I understand well also Andy’s question, is about the fact that 
before publishing an RFC-bis with e.g., 1.1.0, we will have a set of 
Internet-Drafts updating the RFC with 1.0.0

What versions should be used in the YANG modules published in these 
Internet-Drafts?

Think about the following scenario: -00 version provide BC changes to the RFC 
module but the -01 version provide NBC changes to what has been added in the 
-00 module (thus the -01 version is BC with the RFC 1.0.0 module but NBC with 
the -00 version module)
 So bis 00 would be 1.1.0 (BC with RFC module).
Bis 01 should be updated according to its relationship to the RFC module (bis 
00 doesn’t matter anymore), when RFC bis is published it won’t have the full 
history.

Hope I correctly understood your question.


This semver plan is not very intuitive and not sure it works.

draft-00

   container the-container; version 0.1.0  OK

draft-01:
   container my-container; version 0.2.0;   rules violated; NBC 
should force 1.0.0

draft-02:

container my-container {   version 0.3.0; should be 1.1.0
leaf my-leaf { type int32; }
}

RFC-1:

container my-container {   version 1.0.0;  should be 2.0.0 
according to NBC rules
leaf my-leaf { type uint32; }
}

bis-draft-00:

   container my-container {   version 1.1.0; OK
leaf my-leaf { type uint32; }
leaf another-leaf { type int32; }
}

bis-draft-01:

  container my-container {  diff against RFC-1:  version 1.1.0 
but already used; use 1.2.0?
leaf my-leaf { type uint32; }
leaf another-leaf { type uint32; }
}

bis-draft-02:

  container example-my-container {  diff against RFC-1:  
version 2.0.0 but use 1.3.0 instead?
leaf my-leaf { type uint32; }
leaf another-leaf { type uint32; }
}

[repeat NBC step bis-draft-02 10 times now up to version 12.0.0 or is it 
1.13.0? something else?

RFC-2:   publish draft-12 as RFC-2: now change the label from 1.13.0 to 2.0.0? 
or leave it 12.0.0?

IMO it is very confusing that the stated rules are so inconsistent and are 
violated so many ways.
There should be no revision-label at all in Internet Drafts because these 
documents are unpublished.
They should only be added to the RFC version.

The semver procedures are not intended to work for unpublished modules that are 
only
meant for review, not for implementation. The revision-label provides only 
noise in Internet Drafts.
 I think it’s useful to have a revision label in a draft because it 
indicates nature of changes (BC v/s NBC) compared to the previous published 
revision (RFC).
But you are absolutely right that setting the version based on changes with the 
previous draft revision is useless and confusing.

Regards,
Reshad.


Regards,
Reshad.

Thanks, Italo


Andy


Italo Busi
Principal Optical Transport Network Research Engineer
Huawei Technologies Co., Ltd.
Tel : +39 345 4721946
Email : italo.b...@huawei.com<mailto:italo.b...@huawei.com>
[cid:image001.png@01D608DB.F2E089F0]

This e-mail and its attachments contain confidential information from HUAWEI, 
which is intended only for the person or entity whose address is listed above. 
Any use of the information contained herein in any way (including, but not 
limited to, total or partial disclosure, reproduction, or dissemination) by 
persons other than the intended recipient(s) is prohibited. If you receive this 
e-mail in error, please notify the sender by phone or email immediately and 
delete it!

From: Reshad Rahman (rrahman) 
[mailto:rrah...@cisco.com<mailto:rrah...@cisco.com>]
Sent: mercoledì 1 aprile 2020 20:13
To: Andy Bierman mailto:a...@yumaworks.com>>; Joe Clarke 
(jclarke) mailto:jcla...@cisco.com>>
Cc: NetMod WG mailto:netmod@ietf.org>>
Subject: Re: [netmod] versioning procedures (RFC vs. I-D)


From: netmod mailto:netmod-boun...@ietf.org>> on 
behalf of 'Andy Bierman' mailto:a...@yumaworks.com>>
Date: Wednesday, April 1, 2020 at 2:07 PM
To: "Joe Clarke (jclarke)" mailto:jcla...@cisco.com>>
Cc: NetMod WG mailto:netmod@ietf.org>>
Subject: Re: [netmod] versioning procedures (RFC vs

Re: [netmod] versioning procedures (RFC vs. I-D)

[Reshad Rahman (rrahman)]

Hi,

From: Italo Busi 
Date: Thursday, April 2, 2020 at 5:06 AM
To: "Reshad Rahman (rrahman)" , 'Andy Bierman' 
, "Joe Clarke (jclarke)" 
Cc: NetMod WG 
Subject: RE: [netmod] versioning procedures (RFC vs. I-D)

Reshad,

My doubt and, if I understand well also Andy’s question, is about the fact that 
before publishing an RFC-bis with e.g., 1.1.0, we will have a set of 
Internet-Drafts updating the RFC with 1.0.0

What versions should be used in the YANG modules published in these 
Internet-Drafts?

Think about the following scenario: -00 version provide BC changes to the RFC 
module but the -01 version provide NBC changes to what has been added in the 
-00 module (thus the -01 version is BC with the RFC 1.0.0 module but NBC with 
the -00 version module)
 So bis 00 would be 1.1.0 (BC with RFC module).
Bis 01 should be updated according to its relationship to the RFC module (bis 
00 doesn’t matter anymore), when RFC bis is published it won’t have the full 
history.

Hope I correctly understood your question.

Regards,
Reshad.

Thanks, Italo

Italo Busi
Principal Optical Transport Network Research Engineer
Huawei Technologies Co., Ltd.
Tel : +39 345 4721946
Email : italo.b...@huawei.com
[cid:image001.png@01D608BD.F401D410]

This e-mail and its attachments contain confidential information from HUAWEI, 
which is intended only for the person or entity whose address is listed above. 
Any use of the information contained herein in any way (including, but not 
limited to, total or partial disclosure, reproduction, or dissemination) by 
persons other than the intended recipient(s) is prohibited. If you receive this 
e-mail in error, please notify the sender by phone or email immediately and 
delete it!

From: Reshad Rahman (rrahman) [mailto:rrah...@cisco.com]
Sent: mercoledì 1 aprile 2020 20:13
To: Andy Bierman ; Joe Clarke (jclarke) 
Cc: NetMod WG 
Subject: Re: [netmod] versioning procedures (RFC vs. I-D)


From: netmod mailto:netmod-boun...@ietf.org>> on 
behalf of 'Andy Bierman' mailto:a...@yumaworks.com>>
Date: Wednesday, April 1, 2020 at 2:07 PM
To: "Joe Clarke (jclarke)" mailto:jcla...@cisco.com>>
Cc: NetMod WG mailto:netmod@ietf.org>>
Subject: Re: [netmod] versioning procedures (RFC vs. I-D)



On Wed, Apr 1, 2020 at 10:39 AM Joe Clarke (jclarke) 
mailto:jcla...@cisco.com>> wrote:


> On Apr 1, 2020, at 13:28, Andy Bierman 
> mailto:a...@yumaworks.com>> wrote:
>
> Hi,
>
> I just want to confirm that all the proposed documentation procedures
> using new extensions are limited in scope to published modules only,
> and not applied to unpublished modules (terms defined in RFC 8407).
>
> IMO it would be harmful to module usability to assign revision-labels or
> include revision-related extensions in unpublished modules (e.g., Internet 
> Drafts).
> Consider how cluttered and confusing the client-server modules would be
> if the 50+ NBC changes and versions were tracked through all the I-Ds.
>
> For IETF modules, the first usage of the revision-label
> should be in the initial RFC, and be set to 1.0.0.
>
> If the RFC is ever republished then one can expect to find an updated
> revision-label and possibly extensions tracking NBC changes.

The semver scheme allocates a major version of 0 for pre-releases where the 
BC/NBC rules do not apply.  I agree that a first official RFC release should be 
1.0.0 (from a semver revision-label standpoint).  From a design team 
standpoint, I know we mentioned the 0 versioning early on, but I don’t think we 
spent much time talking about modules under development overall.


IMO it is confusing to ignore the semver rules for the special 0.x.y releases.
There are many NBC changes made at this point which are treated as minor or 
patch changes.
The procedure is really broken once you consider a WG developing any RFC-bis 
module.
Now the major version is not 0 and all updates look like real releases.
 I don’t think that’s needed. Initial module in RFC has 1.0.0, module in 
(released) RFC-bis can go to 1.0.1, 1.1.0 or 2.0.0 depending on the change.

Regards,
Reshad.

My take would align to yours that we wouldn’t clutter a module with development 
NBC tracking.

Joe

Andy

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

Re: [netmod] versioning procedures (RFC vs. I-D)

[Reshad Rahman (rrahman)]

From: netmod  on behalf of 'Andy Bierman' 

Date: Wednesday, April 1, 2020 at 2:07 PM
To: "Joe Clarke (jclarke)" 
Cc: NetMod WG 
Subject: Re: [netmod] versioning procedures (RFC vs. I-D)



On Wed, Apr 1, 2020 at 10:39 AM Joe Clarke (jclarke) 
mailto:jcla...@cisco.com>> wrote:


> On Apr 1, 2020, at 13:28, Andy Bierman 
> mailto:a...@yumaworks.com>> wrote:
>
> Hi,
>
> I just want to confirm that all the proposed documentation procedures
> using new extensions are limited in scope to published modules only,
> and not applied to unpublished modules (terms defined in RFC 8407).
>
> IMO it would be harmful to module usability to assign revision-labels or
> include revision-related extensions in unpublished modules (e.g., Internet 
> Drafts).
> Consider how cluttered and confusing the client-server modules would be
> if the 50+ NBC changes and versions were tracked through all the I-Ds.
>
> For IETF modules, the first usage of the revision-label
> should be in the initial RFC, and be set to 1.0.0.
>
> If the RFC is ever republished then one can expect to find an updated
> revision-label and possibly extensions tracking NBC changes.

The semver scheme allocates a major version of 0 for pre-releases where the 
BC/NBC rules do not apply.  I agree that a first official RFC release should be 
1.0.0 (from a semver revision-label standpoint).  From a design team 
standpoint, I know we mentioned the 0 versioning early on, but I don’t think we 
spent much time talking about modules under development overall.


IMO it is confusing to ignore the semver rules for the special 0.x.y releases.
There are many NBC changes made at this point which are treated as minor or 
patch changes.
The procedure is really broken once you consider a WG developing any RFC-bis 
module.
Now the major version is not 0 and all updates look like real releases.
 I don’t think that’s needed. Initial module in RFC has 1.0.0, module in 
(released) RFC-bis can go to 1.0.1, 1.1.0 or 2.0.0 depending on the change.

Regards,
Reshad.

My take would align to yours that we wouldn’t clutter a module with development 
NBC tracking.

Joe

Andy

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

Re: [netmod] All IETF YANG modules MUST include revision-label statements

[Reshad Rahman (rrahman)]

Hi,

Thanks for the suggestion.

This was discussed, I think the reason we didn’t go with that solution is that 
(as you mentioned) you need the module contents with all the previous version 
labels. Does anyone from the design team recall any other details?

Regards,
Reshad.

From: "Ivory, William" 
Date: Tuesday, March 31, 2020 at 3:40 AM
To: "mbj+i...@4668.se" , "jason.ste...@nokia.com" 
, "Reshad Rahman (rrahman)" 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] All IETF YANG modules MUST include revision-label 
statements

Apologies if this has already been suggested and deemed unworkable, but if you 
have access to all previous version labels for a branch then you can add 'M' 
only to the versions that are NBC with the previous version, and subsequent 
versions could drop the M until the next NBC change, ie:

1.0.0 -> 1.0.1 -> 1.0.2 > 1.0.3M -> 1.0.4 -> 1.0.5M ...

Here 1.04 is BC with 1.03 but not 1.0.0 - 1.0.2; 1.0.5 is NBC with 1.0.4 and 
previous versions etc.

The revision statements contain the revision-labels so you should have all the 
previous revision-labels present in the file, and you have all the data you 
need. Now you don't have the problem of the branch being poisoned as soon as 
the first M is added.

William

On Mon, 2020-03-30 at 22:11 +, Reshad Rahman (rrahman) wrote:

On 2020-03-30, 5:51 PM, "Martin Björklund" 
mailto:mbj+i...@4668.se>> wrote:



"Sterne, Jason (Nokia - CA/Ottawa)" 
mailto:jason.ste...@nokia.com>> wrote:

> > But it is not true.  What happened between 1.0.2M and 1.0.3M?

>

> It tells you there is an NBC change between 1.0.2M and 1.0.3M.



No.  As you note below it says that all bets are off.  The change

between these two could be a spelling error fix.  Hence, Reshad's

statement that "The revision label allows a user to easily figure out

whether 2 revisions are (N)BC." is not correct.

You are correct that once a branch is poisoned with an 'M', the information 
provided is not as rich.

Even though you don't know whether 1.0.3M is BC/NBC with 1.0.2M, you still know 
that

- 1.0.2M is NBC with 1.0.1 and 1.0.0

- 1.0.3M is NBC with 1.0.1 and 1.0.0

- 1.0.1 is BC with 1.0.0



Still useful IMO.



Regards,

Reshad.



> The M gives an indication that a branch has been "poisoned" by an

> NBC change and that all bets are off from that point onwards in that

> branch.





/martin





>

> > -Original Message-

> > From: netmod mailto:netmod-boun...@ietf.org>> 
On Behalf Of Martin Björklund

> > Sent: Monday, March 30, 2020 4:40 PM

> > To: rrah...@cisco.com<mailto:rrah...@cisco.com>

    > > Cc: netmod@ietf.org<mailto:netmod@ietf.org>

> > Subject: Re: [netmod] All IETF YANG modules MUST include revision-label

> > statements

    > >

    > > "Reshad Rahman (rrahman)" mailto:rrah...@cisco.com>> 
wrote:

> > >

> > > On 2020-03-30, 2:20 PM, "Martin Björklund" 
mailto:mbj+i...@4668.se>> wrote:

> > >

> > > "Reshad Rahman (rrahman)" 
mailto:rrah...@cisco.com>> wrote:

> > > > On 2020-03-28, 4:41 AM, "Martin Björklund" 
mailto:mbj+i...@4668.se>> wrote:

> > > >

> > > > "Reshad Rahman (rrahman)" 
mailto:rrah...@cisco.com>> wrote:

> > > > > Hi,

> > > > >

> > > > > 
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_netmod-2Dwg_yang-2Dver-2Ddt_issues_45=DwIGaQ=LFYZ-o9_HUMeMTSQicvjIg=p8kyeK3u4ZYiaQ2ZPGqwkyXmQgBH6r5jpYiYWzhqJ48=ffH268c0xOd0DSFLQzZ2JHAmCHjVzPJVJtGPNxiiJcs=nyxzbv7ZWMgcXuMEW8MqjeT3oVxla6qFiF96M8SaMUY=

> > > > >

> > > > > o  7.1

> > > > >

> > > > >   The text says:

> > > > >

> > > > > All IETF YANG modules MUST include 
revision-label statements

> > for

> > > > > all

> > > > > newly published YANG modules, and all newly 
published

> > revisions of

> > > > > existing YANG modules.  The revision-label 
MUST take the form

> > of a

> > > > > YANG semantic version number 
[I-D.verdt-netmod-yang-

> > semver].

> > > > >

> > > > >   I strongly disagree with this new rule.  IETF 
m

Re: [netmod] All IETF YANG modules MUST include revision-label statements

[Reshad Rahman (rrahman)]

On 2020-03-30, 7:22 PM, "Kent Watsen"  wrote:
> Even though we are debating/discussing whether iETF moduels should use 
YANG semver (aka modified semver), please note that there is interest from 
other publishers of YANG modules to use semver or YANG semver.

Details?

I was referring to vendors, not SDOs.

Regards,
Reshad.

> Regarding your comment below, is it specific to IETF modules or more 
general?
>  
> "I don’t think the “semver" label has been fully justified relative to 
the disruption I perceive it may cause.”

I was thinking in general.  YMMV.


Kent // contributor



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

Re: [netmod] All IETF YANG modules MUST include revision-label statements

[Reshad Rahman (rrahman)]

Hi Kent,

Even though we are debating/discussing whether iETF moduels should use YANG 
semver (aka modified semver), please note that there is interest from other 
publishers of YANG modules to use semver or YANG semver.

Regarding your comment below, is it specific to IETF modules or more general?
I don’t think the “semver" label has been fully justified relative to the 
disruption I perceive it may cause.

Regards,
Reshad.

From: Kent Watsen 
Date: Monday, March 30, 2020 at 6:49 PM
To: Martin Björklund 
Cc: "Reshad Rahman (rrahman)" , "netmod@ietf.org" 

Subject: Re: [netmod] All IETF YANG modules MUST include revision-label 
statements

[I’ve scanned the entire thread before circling back to respond to this message]



Martin writes:
I can reluctantly accept that modified smever is published as
Experimental.  But that doesn't mean that IETF modules should use it.

I assume Martin’s reference to Experimental follows my adoption-call comment 
here: https://mailarchive.ietf.org/arch/msg/netmod/uZZqBs1yK0EpbXgRJRFQihHWo5s/

Changing the "Intended Status” for an adopted document is easily done at any 
time before publication.

PS: Andy didn’t participate in the call, though he appears to be coming in 
strong now...

Kent

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

Re: [netmod] All IETF YANG modules MUST include revision-label statements

[Reshad Rahman (rrahman)]

On 2020-03-30, 5:51 PM, "Martin Björklund"  wrote:

"Sterne, Jason (Nokia - CA/Ottawa)"  wrote:
> > But it is not true.  What happened between 1.0.2M and 1.0.3M?
> 
> It tells you there is an NBC change between 1.0.2M and 1.0.3M.

No.  As you note below it says that all bets are off.  The change
between these two could be a spelling error fix.  Hence, Reshad's
statement that "The revision label allows a user to easily figure out
whether 2 revisions are (N)BC." is not correct.
You are correct that once a branch is poisoned with an 'M', the information 
provided is not as rich.
Even though you don't know whether 1.0.3M is BC/NBC with 1.0.2M, you still know 
that
- 1.0.2M is NBC with 1.0.1 and 1.0.0
- 1.0.3M is NBC with 1.0.1 and 1.0.0
- 1.0.1 is BC with 1.0.0

Still useful IMO.

Regards,
Reshad.

> The M gives an indication that a branch has been "poisoned" by an
> NBC change and that all bets are off from that point onwards in that
> branch.


/martin


> 
> > -Original Message-
> > From: netmod  On Behalf Of Martin Björklund
> > Sent: Monday, March 30, 2020 4:40 PM
> > To: rrah...@cisco.com
> > Cc: netmod@ietf.org
> > Subject: Re: [netmod] All IETF YANG modules MUST include revision-label
> > statements
> > 
> > "Reshad Rahman (rrahman)"  wrote:
> > >
> > > On 2020-03-30, 2:20 PM, "Martin Björklund"  wrote:
> > >
    > > > "Reshad Rahman (rrahman)"  wrote:
> > > > On 2020-03-28, 4:41 AM, "Martin Björklund"  
wrote:
> > > >
> > > > "Reshad Rahman (rrahman)"  wrote:
> > > > > Hi,
> > > > >
> > > > > https://github.com/netmod-wg/yang-ver-dt/issues/45
> > > > >
> > > > > o  7.1
> > > > >
> > > > >   The text says:
> > > > >
> > > > > All IETF YANG modules MUST include 
revision-label statements
> > for
> > > > > all
> > > > > newly published YANG modules, and all newly 
published
> > revisions of
> > > > > existing YANG modules.  The revision-label 
MUST take the form
> > of a
> > > > > YANG semantic version number 
[I-D.verdt-netmod-yang-
> > semver].
> > > > >
> > > > >   I strongly disagree with this new rule.  IETF 
modules use a linear
> > > > >   history, so there are no reasons to use 
"modified semver".
> > > > >
> > > > >   It is ok to use rev:nbc-changes if needed, 
though.
> > > > >
> > > > > We believe some IETF models may not follow linear 
history, this was
> > > > > brought up (I think) for IDR. Modified semver allows for 
non-linear
> > > > > history and also doesn't preclude linear history. So even 
if we end up
> > > > > having no IETF modules using branching, modified semver 
still works.
> > > >
> > > > With the clarifiactions and updates in
> > > > draft-verdt-netmod-yang-module-versioning, non-linear 
versioning
> > > > works without modified semver.  So there is no technical 
reason to use
> > > > modified semver in IETF modules.
> > > >
> > > > So are you proposing we use some other revision-label scheme 
(e.g.
> > semver 2.0.0) for IETF modules?
> > > >
> > > > Or that IETF modules shouldn't use revision-labels?
> > >
> > > That IETF shouldn't use revision labels.
> > >
> > > The revision label allows a user to easily figure out whether 2
> > > revisions are (N)BC.
> > 
> > I think you meant "modified semver as revision label allows ..."
> > 
> > But it is not true.  What happened between 1.0.2M and 1.0.3M?
> > 
> > 
> > /martin
> > 
> > 
> > > Without the label, you always have to use tooling.
> > >
> > > Regards,
 

Re: [netmod] All IETF YANG modules MUST include revision-label statements

[Reshad Rahman (rrahman)]

From: 'Andy Bierman' 
Date: Monday, March 30, 2020 at 2:51 PM
To: Martin Björklund 
Cc: "Reshad Rahman (rrahman)" , NetMod WG 
Subject: Re: [netmod] All IETF YANG modules MUST include revision-label 
statements



On Mon, Mar 30, 2020 at 11:20 AM Martin Björklund 
mailto:mbj%2bi...@4668.se>> wrote:
"Reshad Rahman (rrahman)" mailto:rrah...@cisco.com>> wrote:
> On 2020-03-28, 4:41 AM, "Martin Björklund" 
> mailto:mbj%2bi...@4668.se>> wrote:
>
> "Reshad Rahman (rrahman)" mailto:rrah...@cisco.com>> 
> wrote:
> > Hi,
> >
> > https://github.com/netmod-wg/yang-ver-dt/issues/45
> >
> > o  7.1
> >
> >   The text says:
> >
> > All IETF YANG modules MUST include revision-label 
> statements for
> > all
> > newly published YANG modules, and all newly published 
> revisions of
> > existing YANG modules.  The revision-label MUST take the 
> form of a
> > YANG semantic version number [I-D.verdt-netmod-yang-semver].
> >
> >   I strongly disagree with this new rule.  IETF modules use a 
> linear
> >   history, so there are no reasons to use "modified semver".
> >
> >   It is ok to use rev:nbc-changes if needed, though.
> >
> > We believe some IETF models may not follow linear history, this was
> > brought up (I think) for IDR. Modified semver allows for non-linear
> > history and also doesn't preclude linear history. So even if we end up
> > having no IETF modules using branching, modified semver still works.
>
> With the clarifiactions and updates in
> draft-verdt-netmod-yang-module-versioning, non-linear versioning
> works without modified semver.  So there is no technical reason to use
> modified semver in IETF modules.
>
> So are you proposing we use some other revision-label scheme (e.g. semver 
> 2.0.0) for IETF modules?
>
> Or that IETF modules shouldn't use revision-labels?

That IETF shouldn't use revision labels.

I do not like modified semver because it will cause confusion with the real 
semver
introduced by OpenConfig.

Sometimes multiple release trains are needed, and the revision label (in 
addition to revision-date)
can help distinguish revisions from each release train, so plain semver that is 
introduced over time
would be OK.

It is possible to introduce only BC changes on each release train.
The BC vs. NBC issue has nothing to do with multiple release trains.



I am all for using rev:nbc-changes or rev:editorial-changes (which I
think should be added) in IETF modules.

I agree that this is sufficient and modified semver provides no added value, 
only confusion.
 There are 2 questions here:

  1.  Is revision-label useful? We believe it is useful since it allows a user 
to easily figure out whether 2 revisions are (N)BC
  2.  If it is useful, what’s the best scheme to use? Semver, modified semver, 
…?

You’re not keen on modified semver just because of the name, or are there other 
reasons?

Regards,
Reshad.

Regards,
Reshad.



/martin


Andy


>
> Or do you have something else in mind?
>
> Regards,
> Reshad.
>
> I can reluctantly accept that modified smever is published as
> Experimental.  But that doesn't mean that IETF modules should use it.
>
>
> /martin
>
>
> >
> > Regards,
> > Reshad.
> >
> >
> > On 2020-03-20, 5:08 PM, "netmod on behalf of Reshad Rahman (rrahman)"
> > mailto:netmod-boun...@ietf.org> on behalf of
> > rrahman=40cisco@dmarc.ietf.org<mailto:40cisco@dmarc.ietf.org>> 
> wrote:
> >
> > Hi Martin,
> >
> > We've opened issues to track your review comments (see below). Will
> > kick off separate therads for each issue.
> >
> > 
> https://github.com/netmod-wg/yang-ver-dt/issues?q=is%3Aissue+is%3Aopen+label%3Aupdated-mod-rev-handling
> >
> > Regards,
> > Reshad.
> >
> > On 2020-03-10, 3:31 PM, "netmod on behalf of Martin Björklund"
> > mailto:netmod-boun...@ietf.org> on behalf 
> of mbj+i...@4668.se<mailto:mbj%2bi...@4668.se>> wrote:
> >
> > Hi,
> >
> > Here are my review comments of
> > draft-verdt-netmod-yang-module-versioning-01.
> >
> >
> >
> > o  3.1.1
> >
> > o  In statements that have any data definition stat

Re: [netmod] All IETF YANG modules MUST include revision-label statements

[Reshad Rahman (rrahman)]

On 2020-03-30, 2:20 PM, "Martin Björklund"  wrote:

    "Reshad Rahman (rrahman)"  wrote:
> On 2020-03-28, 4:41 AM, "Martin Björklund"  wrote:
> 
> "Reshad Rahman (rrahman)"  wrote:
> > Hi,
> > 
> > https://github.com/netmod-wg/yang-ver-dt/issues/45
> > 
> > o  7.1
> > 
> >   The text says:
> > 
> > All IETF YANG modules MUST include revision-label 
statements for
> > all
> > newly published YANG modules, and all newly published 
revisions of
> > existing YANG modules.  The revision-label MUST take 
the form of a
> > YANG semantic version number 
[I-D.verdt-netmod-yang-semver].
> > 
> >   I strongly disagree with this new rule.  IETF modules use 
a linear
> >   history, so there are no reasons to use "modified semver".
> > 
> >   It is ok to use rev:nbc-changes if needed, though.
> > 
> > We believe some IETF models may not follow linear history, this was
> > brought up (I think) for IDR. Modified semver allows for non-linear
> > history and also doesn't preclude linear history. So even if we end 
up
> > having no IETF modules using branching, modified semver still works.
> 
> With the clarifiactions and updates in
> draft-verdt-netmod-yang-module-versioning, non-linear versioning
> works without modified semver.  So there is no technical reason to use
> modified semver in IETF modules.
> 
> So are you proposing we use some other revision-label scheme (e.g. semver 
2.0.0) for IETF modules?
> 
> Or that IETF modules shouldn't use revision-labels?

That IETF shouldn't use revision labels.

The revision label allows a user to easily figure out whether 2 revisions are 
(N)BC. Without the label, you always have to use tooling.

Regards,
Reshad.

I am all for using rev:nbc-changes or rev:editorial-changes (which I
think should be added) in IETF modules.


/martin


> 
> Or do you have something else in mind?
> 
> Regards,
> Reshad.
> 
> I can reluctantly accept that modified smever is published as
> Experimental.  But that doesn't mean that IETF modules should use it.
> 
> 
> /martin
> 
> 
> > 
> > Regards,
> > Reshad.
> > 
> > 
> > On 2020-03-20, 5:08 PM, "netmod on behalf of Reshad Rahman 
(rrahman)"
> >  > rrahman=40cisco@dmarc.ietf.org> wrote:
> > 
> > Hi Martin,
> > 
> > We've opened issues to track your review comments (see below). 
Will
> > kick off separate therads for each issue.
> > 
> > 
https://github.com/netmod-wg/yang-ver-dt/issues?q=is%3Aissue+is%3Aopen+label%3Aupdated-mod-rev-handling
> > 
> > Regards,
> > Reshad.
> > 
> > On 2020-03-10, 3:31 PM, "netmod on behalf of Martin Björklund"
> >  wrote:
> > 
> > Hi,
> > 
> > Here are my review comments of
> > draft-verdt-netmod-yang-module-versioning-01.
> > 
> > 
> > 
> > o  3.1.1
> > 
> > o  In statements that have any data definition 
statements as
> >substatements, those data definition substatements 
MAY be
> >reordered, as long as they do not change the 
ordering or any
> >"rpc"
> >"input" substatements.
> > 
> >   I think this needs to capture that no descendant 
statements to
> >   "input" can be reordered.  Same for "output" (note, 
"input" and
> >   "output" in both "rpc" and "action").
> > 
> > 
> > o  3.3
> > 
> > All revision labels that match the pattern for the 
"version&q

Re: [netmod] All IETF YANG modules MUST include revision-label statements

[Reshad Rahman (rrahman)]

On 2020-03-28, 4:41 AM, "Martin Björklund"  wrote:

    "Reshad Rahman (rrahman)"  wrote:
> Hi,
> 
> https://github.com/netmod-wg/yang-ver-dt/issues/45
> 
> o  7.1
> 
>   The text says:
> 
> All IETF YANG modules MUST include revision-label statements 
for
> all
> newly published YANG modules, and all newly published 
revisions of
> existing YANG modules.  The revision-label MUST take the form 
of a
> YANG semantic version number [I-D.verdt-netmod-yang-semver].
> 
>   I strongly disagree with this new rule.  IETF modules use a 
linear
>   history, so there are no reasons to use "modified semver".
> 
>   It is ok to use rev:nbc-changes if needed, though.
> 
> We believe some IETF models may not follow linear history, this was
> brought up (I think) for IDR. Modified semver allows for non-linear
> history and also doesn't preclude linear history. So even if we end up
> having no IETF modules using branching, modified semver still works.

With the clarifiactions and updates in
draft-verdt-netmod-yang-module-versioning, non-linear versioning
works without modified semver.  So there is no technical reason to use
modified semver in IETF modules.

So are you proposing we use some other revision-label scheme (e.g. semver 
2.0.0) for IETF modules?

Or that IETF modules shouldn't use revision-labels?

Or do you have something else in mind?

Regards,
Reshad.

I can reluctantly accept that modified smever is published as
Experimental.  But that doesn't mean that IETF modules should use it.


/martin


    > 
> Regards,
> Reshad.
> 
> 
> On 2020-03-20, 5:08 PM, "netmod on behalf of Reshad Rahman (rrahman)"
>  rrahman=40cisco@dmarc.ietf.org> wrote:
> 
> Hi Martin,
> 
> We've opened issues to track your review comments (see below). Will
> kick off separate therads for each issue.
> 
> 
https://github.com/netmod-wg/yang-ver-dt/issues?q=is%3Aissue+is%3Aopen+label%3Aupdated-mod-rev-handling
> 
> Regards,
> Reshad.
> 
> On 2020-03-10, 3:31 PM, "netmod on behalf of Martin Björklund"
>  wrote:
> 
> Hi,
> 
> Here are my review comments of
> draft-verdt-netmod-yang-module-versioning-01.
> 
> 
> 
> o  3.1.1
> 
> o  In statements that have any data definition statements as
>substatements, those data definition substatements MAY be
>reordered, as long as they do not change the ordering or 
any
>"rpc"
>"input" substatements.
> 
>   I think this needs to capture that no descendant statements to
>   "input" can be reordered.  Same for "output" (note, "input" and
>   "output" in both "rpc" and "action").
> 
> 
> o  3.3
> 
> All revision labels that match the pattern for the "version"
> typedef in the ietf-yang-semver YANG module MUST be 
interpreted as
> YANG semantic version numbers.
> 
>   I don't think this is a good idea.  Seems like a layer 
violation.
>   What if my project use another dialect of semver, that wouldn't 
be
>   possible with this rule.  I think this needs to be removed.
> 
> 
> o  3.3
> 
> Submodules MUST NOT use revision label schemes that could be
> confused
> with the including module's revision label scheme.
> 
>   Hmm, how do I ensure that this MUST NOT is handled correctly?  
What
>   exactly does "could be confused with" mean?
> 
> 
> o  3.3
> 
>   In the filename of a YANG module, where it takes the form:
>   module-
>   or-submodule-name ['@' revision-label] ( '.yang' / '.yin' )
> 
>   Should this section update 5.2 of RFC 7950?  I know that 5.2 
just
>   says "SHOULD".  But existing tools implemen

[netmod] Grammar for new extensions (WAS Re: mbj review of draft-verdt-netmod-yang-module-versioning-01)

[Reshad Rahman (rrahman)]

Hi,

https://github.com/netmod-wg/yang-ver-dt/issues/54

o Both YANG modules

  All extensions should specify the grammar; i.e., in which statements
  they can be present and which substatements they can have.

Ack.

1st part (statements) is clear.

For substatements, isn't this specified in 
https://tools.ietf.org/html/rfc7950#section-7.19.1? Can you clarify if that's 
not what you're looking for?

Regards,
Reshad.


On 2020-03-20, 5:08 PM, "netmod on behalf of Reshad Rahman (rrahman)" 
 wrote:

Hi Martin,

We've opened issues to track your review comments (see below). Will kick 
off separate therads for each issue.


https://github.com/netmod-wg/yang-ver-dt/issues?q=is%3Aissue+is%3Aopen+label%3Aupdated-mod-rev-handling

Regards,
Reshad.

On 2020-03-10, 3:31 PM, "netmod on behalf of Martin Björklund" 
 wrote:

Hi,

Here are my review comments of
draft-verdt-netmod-yang-module-versioning-01.



o  3.1.1

o  In statements that have any data definition statements as
   substatements, those data definition substatements MAY be
   reordered, as long as they do not change the ordering or any 
"rpc"
   "input" substatements.

  I think this needs to capture that no descendant statements to
  "input" can be reordered.  Same for "output" (note, "input" and
  "output" in both "rpc" and "action").


o  3.3

All revision labels that match the pattern for the "version"
typedef in the ietf-yang-semver YANG module MUST be interpreted as
YANG semantic version numbers.

  I don't think this is a good idea.  Seems like a layer violation.
  What if my project use another dialect of semver, that wouldn't be
  possible with this rule.  I think this needs to be removed.


o  3.3

Submodules MUST NOT use revision label schemes that could be 
confused
with the including module's revision label scheme.

  Hmm, how do I ensure that this MUST NOT is handled correctly?  What
  exactly does "could be confused with" mean?


o  3.3

  In the filename of a YANG module, where it takes the form: module-
  or-submodule-name ['@' revision-label] ( '.yang' / '.yin' )

  Should this section update 5.2 of RFC 7950?  I know that 5.2 just
  says "SHOULD".  But existing tools implement this SHOULD, and they
  need to be updated to handle this new convention.

  But I wonder if this a good idea.  It means that a tool that looks
  for a module with a certain revision date cannot simply check the
  filenames, but need to parse all available modules (wijust to find 
the 



o  3.4

 leaf imperial-temperature {
   type int64;
   units "degrees Fahrenheit";
   status deprecated {
 rev:status-description
   "Imperial measurements are being phased out in favor
of their metric equivalents.  Use metric-temperature
instead.";
   }
   description
 "Temperature in degrees Fahrenheit.";
 }

  I don't think rev:status-description is necessary / worth it.  This
  can easily be written with the normal description statement instead:

 leaf imperial-temperature {
   type int64;
   units "degrees Fahrenheit";
   status deprecated;
   description
   "Imperial measurements are being phased out in favor
of their metric equivalents.  Use metric-temperature
instead.

Temperature in degrees Fahrenheit.";
 }


o  3.5

  The example modules should be legal YANG modules.  Use e.g. 
  "urn:example:module" as namespace.

  Also, the modules are missing the last "}", which confuses the
  "rfcstrip" tool.


o 4.1.1

Alternatively, the first example could have used the revision label
"1.0.0" instead, which selects the same set of revisions/versions.

import example-module {
  rev:revision-or-derived 1.0.0;
}

  Shouldn't this be s/1.0.0/2.0.0/g ?
  

[netmod] Typos and smaller issues (WAS Re: mbj review of draft-verdt-netmod-yang-module-versioning-01)

[Reshad Rahman (rrahman)]

Hi,

https://github.com/netmod-wg/yang-ver-dt/issues/53

We'll make changes/fixes as per the comments below. All good.

o  3.5

  The example modules should be legal YANG modules.  Use e.g. 
  "urn:example:module" as namespace.

  Also, the modules are missing the last "}", which confuses the
  "rfcstrip" tool.


o 4.1.1

Alternatively, the first example could have used the revision label
"1.0.0" instead, which selects the same set of revisions/versions.

import example-module {
  rev:revision-or-derived 1.0.0;
}

  Shouldn't this be s/1.0.0/2.0.0/g ?


o  5

  I think the module name "ietf-yl-revisions" should be changed to
  "ietf-yang-library-revisions".   "yl" is not a well-known acronym.

o 7.1.1

  There is a missing " in:

   4.  For status "obsolete", it is RECOMMENDED to keep the "status-
   description" information, from when the node had status
   "deprecated, which is still relevant.
 HERE  ---^


o  8
    
      s/CODE ENDS>//

Regards,
Reshad.



On 2020-03-20, 5:08 PM, "netmod on behalf of Reshad Rahman (rrahman)" 
 wrote:

Hi Martin,

We've opened issues to track your review comments (see below). Will kick 
off separate therads for each issue.


https://github.com/netmod-wg/yang-ver-dt/issues?q=is%3Aissue+is%3Aopen+label%3Aupdated-mod-rev-handling

Regards,
Reshad.

On 2020-03-10, 3:31 PM, "netmod on behalf of Martin Björklund" 
 wrote:

Hi,

Here are my review comments of
draft-verdt-netmod-yang-module-versioning-01.



o  3.1.1

o  In statements that have any data definition statements as
   substatements, those data definition substatements MAY be
   reordered, as long as they do not change the ordering or any 
"rpc"
   "input" substatements.

  I think this needs to capture that no descendant statements to
  "input" can be reordered.  Same for "output" (note, "input" and
  "output" in both "rpc" and "action").


o  3.3

All revision labels that match the pattern for the "version"
typedef in the ietf-yang-semver YANG module MUST be interpreted as
YANG semantic version numbers.

  I don't think this is a good idea.  Seems like a layer violation.
  What if my project use another dialect of semver, that wouldn't be
  possible with this rule.  I think this needs to be removed.


o  3.3

Submodules MUST NOT use revision label schemes that could be 
confused
with the including module's revision label scheme.

  Hmm, how do I ensure that this MUST NOT is handled correctly?  What
  exactly does "could be confused with" mean?


o  3.3

  In the filename of a YANG module, where it takes the form: module-
  or-submodule-name ['@' revision-label] ( '.yang' / '.yin' )

  Should this section update 5.2 of RFC 7950?  I know that 5.2 just
  says "SHOULD".  But existing tools implement this SHOULD, and they
  need to be updated to handle this new convention.

  But I wonder if this a good idea.  It means that a tool that looks
  for a module with a certain revision date cannot simply check the
  filenames, but need to parse all available modules (wijust to find 
the 



o  3.4

 leaf imperial-temperature {
   type int64;
   units "degrees Fahrenheit";
   status deprecated {
 rev:status-description
   "Imperial measurements are being phased out in favor
of their metric equivalents.  Use metric-temperature
instead.";
   }
   description
 "Temperature in degrees Fahrenheit.";
 }

  I don't think rev:status-description is necessary / worth it.  This
  can easily be written with the normal description statement instead:

 leaf imperial-temperature {
   type int64;
   units "degrees Fahrenheit";
   status de

[netmod] bool v/s empty for new leafs deprecated-nodes and obsolete-nodes (WAS Re: mbj review of draft-verdt-netmod-yang-module-versioning-01)

[Reshad Rahman (rrahman)]

Hi,

https://github.com/netmod-wg/yang-ver-dt/issues/52

o  5.2.2

  Wouldn't it be better if the leaf "deprecated-nodes-implemented" and
  "obsolete-nodes-absent" were of type "boolean" rather than type
  "empty"?

The bool v/s empty philosophical battle. I'm ok with boolean, I don't know if 
others have strong opinions on this.
If we go with boolean, if the leaf nodes are absent then the behaviour would be 
unspecified.

Regards,
Reshad.


On 2020-03-20, 5:08 PM, "netmod on behalf of Reshad Rahman (rrahman)" 
 wrote:

Hi Martin,

We've opened issues to track your review comments (see below). Will kick 
off separate therads for each issue.


https://github.com/netmod-wg/yang-ver-dt/issues?q=is%3Aissue+is%3Aopen+label%3Aupdated-mod-rev-handling

Regards,
Reshad.

On 2020-03-10, 3:31 PM, "netmod on behalf of Martin Björklund" 
 wrote:

Hi,

Here are my review comments of
draft-verdt-netmod-yang-module-versioning-01.



o  3.1.1

o  In statements that have any data definition statements as
   substatements, those data definition substatements MAY be
   reordered, as long as they do not change the ordering or any 
"rpc"
   "input" substatements.

  I think this needs to capture that no descendant statements to
  "input" can be reordered.  Same for "output" (note, "input" and
  "output" in both "rpc" and "action").


o  3.3

All revision labels that match the pattern for the "version"
typedef in the ietf-yang-semver YANG module MUST be interpreted as
YANG semantic version numbers.

  I don't think this is a good idea.  Seems like a layer violation.
  What if my project use another dialect of semver, that wouldn't be
  possible with this rule.  I think this needs to be removed.


o  3.3

Submodules MUST NOT use revision label schemes that could be 
confused
with the including module's revision label scheme.

  Hmm, how do I ensure that this MUST NOT is handled correctly?  What
  exactly does "could be confused with" mean?


o  3.3

  In the filename of a YANG module, where it takes the form: module-
  or-submodule-name ['@' revision-label] ( '.yang' / '.yin' )

  Should this section update 5.2 of RFC 7950?  I know that 5.2 just
  says "SHOULD".  But existing tools implement this SHOULD, and they
  need to be updated to handle this new convention.

  But I wonder if this a good idea.  It means that a tool that looks
  for a module with a certain revision date cannot simply check the
  filenames, but need to parse all available modules (wijust to find 
the 



o  3.4

 leaf imperial-temperature {
   type int64;
   units "degrees Fahrenheit";
   status deprecated {
 rev:status-description
   "Imperial measurements are being phased out in favor
of their metric equivalents.  Use metric-temperature
instead.";
   }
   description
 "Temperature in degrees Fahrenheit.";
 }

  I don't think rev:status-description is necessary / worth it.  This
  can easily be written with the normal description statement instead:

 leaf imperial-temperature {
   type int64;
   units "degrees Fahrenheit";
   status deprecated;
   description
   "Imperial measurements are being phased out in favor
of their metric equivalents.  Use metric-temperature
instead.

Temperature in degrees Fahrenheit.";
 }


o  3.5

  The example modules should be legal YANG modules.  Use e.g. 
  "urn:example:module" as namespace.

  Also, the modules are missing the last "}", which confuses the
  "rfcstrip" tool.


o 4.1.1

Alternatively, the first example could have used the revision label
"1.0.0" instead, which selects the same set of revisions/versions.

import example-module {
  rev:revision-or-derived 1.0.0;

[netmod] Revision label in filename (WAS Re: mbj review of draft-verdt-netmod-yang-module-versioning-01)

[Reshad Rahman (rrahman)]

Hi,

https://github.com/netmod-wg/yang-ver-dt/issues/50

o  3.3

  In the filename of a YANG module, where it takes the form: module-
  or-submodule-name ['@' revision-label] ( '.yang' / '.yin' )

  Should this section update 5.2 of RFC 7950?  I know that 5.2 just
  says "SHOULD".  But existing tools implement this SHOULD, and they
  need to be updated to handle this new convention.

  But I wonder if this a good idea.  It means that a tool that looks
  for a module with a certain revision date cannot simply check the
  filenames, but need to parse all available modules (wijust to find the

We agree that there is an impact on searching by date. We put this in to have 
the ability to search by revision-label, otherwise we can search just by date 
for a module which uses revision-label.
We had also discussed using different limiter for the label and have something 
along the lines of: module-or-submodule-name['@'date]['#'revision-label].yang
It'd seem that updating 7950 would be a good idea whichever way we go.

Regards,
Reshad.


On 2020-03-20, 5:08 PM, "netmod on behalf of Reshad Rahman (rrahman)" 
 wrote:

Hi Martin,

We've opened issues to track your review comments (see below). Will kick 
off separate therads for each issue.


https://github.com/netmod-wg/yang-ver-dt/issues?q=is%3Aissue+is%3Aopen+label%3Aupdated-mod-rev-handling

Regards,
Reshad.

On 2020-03-10, 3:31 PM, "netmod on behalf of Martin Björklund" 
 wrote:

Hi,

Here are my review comments of
draft-verdt-netmod-yang-module-versioning-01.



o  3.1.1

o  In statements that have any data definition statements as
   substatements, those data definition substatements MAY be
   reordered, as long as they do not change the ordering or any 
"rpc"
   "input" substatements.

  I think this needs to capture that no descendant statements to
  "input" can be reordered.  Same for "output" (note, "input" and
  "output" in both "rpc" and "action").


o  3.3

All revision labels that match the pattern for the "version"
typedef in the ietf-yang-semver YANG module MUST be interpreted as
YANG semantic version numbers.

  I don't think this is a good idea.  Seems like a layer violation.
  What if my project use another dialect of semver, that wouldn't be
  possible with this rule.  I think this needs to be removed.


o  3.3

Submodules MUST NOT use revision label schemes that could be 
confused
with the including module's revision label scheme.

  Hmm, how do I ensure that this MUST NOT is handled correctly?  What
  exactly does "could be confused with" mean?


o  3.3

  In the filename of a YANG module, where it takes the form: module-
  or-submodule-name ['@' revision-label] ( '.yang' / '.yin' )

  Should this section update 5.2 of RFC 7950?  I know that 5.2 just
  says "SHOULD".  But existing tools implement this SHOULD, and they
  need to be updated to handle this new convention.

  But I wonder if this a good idea.  It means that a tool that looks
  for a module with a certain revision date cannot simply check the
  filenames, but need to parse all available modules (wijust to find 
the 



o  3.4

 leaf imperial-temperature {
   type int64;
   units "degrees Fahrenheit";
   status deprecated {
 rev:status-description
   "Imperial measurements are being phased out in favor
of their metric equivalents.  Use metric-temperature
instead.";
   }
   description
 "Temperature in degrees Fahrenheit.";
 }

  I don't think rev:status-description is necessary / worth it.  This
  can easily be written with the normal description statement instead:

 leaf imperial-temperature {
   type int64;
   units "degrees Fahrenheit";
   status deprecated;
   description
   "Imperial measurements are being phased out in favor
of their metric equivalents.  Use metric-temperature
instead.

Temperature in degrees 

[netmod] rev:status-description (WAS Re: mbj review of draft-verdt-netmod-yang-module-versioning-01)

[Reshad Rahman (rrahman)]

Hi,

https://github.com/netmod-wg/yang-ver-dt/issues/51

o  3.4

 leaf imperial-temperature {
   type int64;
   units "degrees Fahrenheit";
   status deprecated {
 rev:status-description
   "Imperial measurements are being phased out in favor
of their metric equivalents.  Use metric-temperature
instead.";
   }
   description
 "Temperature in degrees Fahrenheit.";
 }

  I don't think rev:status-description is necessary / worth it.  This
  can easily be written with the normal description statement instead:

 leaf imperial-temperature {
   type int64;
   units "degrees Fahrenheit";
   status deprecated;
   description
   "Imperial measurements are being phased out in favor
of their metric equivalents.  Use metric-temperature
instead.

Temperature in degrees Fahrenheit.";
 }

While rev:status-description isn't strictly necessary, without it we'd have to 
modify the node's description as you pointed out. That'd make tooling more 
difficult: is the description change BC or NBC? Also, a user looking at a diff 
would need to go through the description change. Use of  rev:status-description 
makes this easier to handle.

Regards,
Reshad.



On 2020-03-20, 5:08 PM, "netmod on behalf of Reshad Rahman (rrahman)" 
 wrote:

Hi Martin,

We've opened issues to track your review comments (see below). Will kick 
off separate therads for each issue.


https://github.com/netmod-wg/yang-ver-dt/issues?q=is%3Aissue+is%3Aopen+label%3Aupdated-mod-rev-handling

Regards,
Reshad.

On 2020-03-10, 3:31 PM, "netmod on behalf of Martin Björklund" 
 wrote:

Hi,

Here are my review comments of
draft-verdt-netmod-yang-module-versioning-01.



o  3.1.1

o  In statements that have any data definition statements as
   substatements, those data definition substatements MAY be
   reordered, as long as they do not change the ordering or any 
"rpc"
   "input" substatements.

  I think this needs to capture that no descendant statements to
  "input" can be reordered.  Same for "output" (note, "input" and
  "output" in both "rpc" and "action").


o  3.3

All revision labels that match the pattern for the "version"
typedef in the ietf-yang-semver YANG module MUST be interpreted as
YANG semantic version numbers.

  I don't think this is a good idea.  Seems like a layer violation.
  What if my project use another dialect of semver, that wouldn't be
  possible with this rule.  I think this needs to be removed.


o  3.3

Submodules MUST NOT use revision label schemes that could be 
confused
with the including module's revision label scheme.

  Hmm, how do I ensure that this MUST NOT is handled correctly?  What
  exactly does "could be confused with" mean?


o  3.3

  In the filename of a YANG module, where it takes the form: module-
  or-submodule-name ['@' revision-label] ( '.yang' / '.yin' )

  Should this section update 5.2 of RFC 7950?  I know that 5.2 just
  says "SHOULD".  But existing tools implement this SHOULD, and they
  need to be updated to handle this new convention.

  But I wonder if this a good idea.  It means that a tool that looks
  for a module with a certain revision date cannot simply check the
  filenames, but need to parse all available modules (wijust to find 
the 



o  3.4

 leaf imperial-temperature {
   type int64;
   units "degrees Fahrenheit";
   status deprecated {
 rev:status-description
   "Imperial measurements are being phased out in favor
of their metric equivalents.  Use metric-temperature
instead.";
   }
   description
 "Temperature in degrees Fahrenheit.";
 }

  I don't think rev:status-description is necessary / worth it.  This
  can easily be written with the normal description statement instead:

 

[netmod] Interpreting revision labels as YANG semantic version numbers (WAS Re: mbj review of draft-verdt-netmod-yang-module-versioning-01)

[Reshad Rahman (rrahman)]

Hi,

https://github.com/netmod-wg/yang-ver-dt/issues/48

o  3.3

All revision labels that match the pattern for the "version"
typedef in the ietf-yang-semver YANG module MUST be interpreted as
YANG semantic version numbers.

  I don't think this is a good idea.  Seems like a layer violation.
  What if my project use another dialect of semver, that wouldn't be
  possible with this rule.  I think this needs to be removed.

Without this, applications cannot know what versioning scheme is being used, or 
they have to guess, or the module would need another statement to declare what 
versioning scheme is being used. Maybe we should go with the latter.

Regards,
Reshad.

On 2020-03-20, 5:08 PM, "netmod on behalf of Reshad Rahman (rrahman)" 
 wrote:

Hi Martin,

We've opened issues to track your review comments (see below). Will kick 
off separate therads for each issue.


https://github.com/netmod-wg/yang-ver-dt/issues?q=is%3Aissue+is%3Aopen+label%3Aupdated-mod-rev-handling

Regards,
Reshad.

On 2020-03-10, 3:31 PM, "netmod on behalf of Martin Björklund" 
 wrote:

Hi,

Here are my review comments of
draft-verdt-netmod-yang-module-versioning-01.



o  3.1.1

o  In statements that have any data definition statements as
   substatements, those data definition substatements MAY be
   reordered, as long as they do not change the ordering or any 
"rpc"
   "input" substatements.

  I think this needs to capture that no descendant statements to
  "input" can be reordered.  Same for "output" (note, "input" and
  "output" in both "rpc" and "action").


o  3.3

All revision labels that match the pattern for the "version"
typedef in the ietf-yang-semver YANG module MUST be interpreted as
YANG semantic version numbers.

  I don't think this is a good idea.  Seems like a layer violation.
  What if my project use another dialect of semver, that wouldn't be
  possible with this rule.  I think this needs to be removed.


o  3.3

Submodules MUST NOT use revision label schemes that could be 
confused
with the including module's revision label scheme.

  Hmm, how do I ensure that this MUST NOT is handled correctly?  What
  exactly does "could be confused with" mean?


o  3.3

  In the filename of a YANG module, where it takes the form: module-
  or-submodule-name ['@' revision-label] ( '.yang' / '.yin' )

  Should this section update 5.2 of RFC 7950?  I know that 5.2 just
  says "SHOULD".  But existing tools implement this SHOULD, and they
  need to be updated to handle this new convention.

  But I wonder if this a good idea.  It means that a tool that looks
  for a module with a certain revision date cannot simply check the
  filenames, but need to parse all available modules (wijust to find 
the 



o  3.4

 leaf imperial-temperature {
   type int64;
   units "degrees Fahrenheit";
   status deprecated {
 rev:status-description
   "Imperial measurements are being phased out in favor
of their metric equivalents.  Use metric-temperature
instead.";
   }
   description
 "Temperature in degrees Fahrenheit.";
 }

  I don't think rev:status-description is necessary / worth it.  This
  can easily be written with the normal description statement instead:

 leaf imperial-temperature {
   type int64;
   units "degrees Fahrenheit";
   status deprecated;
   description
   "Imperial measurements are being phased out in favor
of their metric equivalents.  Use metric-temperature
instead.

Temperature in degrees Fahrenheit.";
 }


o  3.5

  The example modules should be legal YANG modules.  Use e.g. 
  "urn:example:module" as namespace.

  Also, the modules are missing the last "}", which confuses the
  "rfcstrip" tool.


o 4.1.1

Alternatively, 

[netmod] No descendent statements to input/output can be reordered (WAS Re: mbj review of draft-verdt-netmod-yang-module-versioning-01)

[Reshad Rahman (rrahman)]

Hi,

https://github.com/netmod-wg/yang-ver-dt/issues/47

o  3.1.1

o  In statements that have any data definition statements as
   substatements, those data definition substatements MAY be
   reordered, as long as they do not change the ordering or any 
"rpc"
   "input" substatements.

  I think this needs to capture that no descendant statements to
  "input" can be reordered.  Same for "output" (note, "input" and
  "output" in both "rpc" and "action").


Sounds good. JTBC, by descendent you're referring to data nodes (children, 
grandchildren etc) and not to statements like type and description?

Also, could you refresh our memory why the decision was made to preserve order 
of input/output data nodes?

Regards,
Reshad.

On 2020-03-20, 5:08 PM, "netmod on behalf of Reshad Rahman (rrahman)" 
 wrote:

Hi Martin,

We've opened issues to track your review comments (see below). Will kick 
off separate therads for each issue.


https://github.com/netmod-wg/yang-ver-dt/issues?q=is%3Aissue+is%3Aopen+label%3Aupdated-mod-rev-handling

Regards,
Reshad.

On 2020-03-10, 3:31 PM, "netmod on behalf of Martin Björklund" 
 wrote:

Hi,

Here are my review comments of
draft-verdt-netmod-yang-module-versioning-01.



o  3.1.1

o  In statements that have any data definition statements as
   substatements, those data definition substatements MAY be
   reordered, as long as they do not change the ordering or any 
"rpc"
   "input" substatements.

  I think this needs to capture that no descendant statements to
  "input" can be reordered.  Same for "output" (note, "input" and
  "output" in both "rpc" and "action").


o  3.3

All revision labels that match the pattern for the "version"
typedef in the ietf-yang-semver YANG module MUST be interpreted as
YANG semantic version numbers.

  I don't think this is a good idea.  Seems like a layer violation.
  What if my project use another dialect of semver, that wouldn't be
  possible with this rule.  I think this needs to be removed.


o  3.3

Submodules MUST NOT use revision label schemes that could be 
confused
with the including module's revision label scheme.

  Hmm, how do I ensure that this MUST NOT is handled correctly?  What
  exactly does "could be confused with" mean?


o  3.3

  In the filename of a YANG module, where it takes the form: module-
  or-submodule-name ['@' revision-label] ( '.yang' / '.yin' )

  Should this section update 5.2 of RFC 7950?  I know that 5.2 just
  says "SHOULD".  But existing tools implement this SHOULD, and they
  need to be updated to handle this new convention.

  But I wonder if this a good idea.  It means that a tool that looks
  for a module with a certain revision date cannot simply check the
  filenames, but need to parse all available modules (wijust to find 
the 



o  3.4

 leaf imperial-temperature {
   type int64;
   units "degrees Fahrenheit";
   status deprecated {
 rev:status-description
   "Imperial measurements are being phased out in favor
of their metric equivalents.  Use metric-temperature
instead.";
   }
   description
 "Temperature in degrees Fahrenheit.";
 }

  I don't think rev:status-description is necessary / worth it.  This
  can easily be written with the normal description statement instead:

 leaf imperial-temperature {
   type int64;
   units "degrees Fahrenheit";
   status deprecated;
   description
   "Imperial measurements are being phased out in favor
of their metric equivalents.  Use metric-temperature
instead.

Temperature in degrees Fahrenheit.";
 }


o  3.5

  The example modules should be legal YANG modules.  Use e.g. 
  "urn:example:module" as namespace.

  Also, the modules ar

[netmod] Revision labels for submodules (WAS Re: mbj review of draft-verdt-netmod-yang-module-versioning-01)

[Reshad Rahman (rrahman)]

Hi,

https://github.com/netmod-wg/yang-ver-dt/issues/49

o  3.3

Submodules MUST NOT use revision label schemes that could be 
confused
with the including module's revision label scheme.

  Hmm, how do I ensure that this MUST NOT is handled correctly?  What
  exactly does "could be confused with" mean?

Good point. What was meant by that the label space for modules and sub-modules 
are orthogonal.  e.g. the sub-module and module both have the same label, it 
shouldn't be inferred that the 2 are related. 
We'll change/clarify the text.

Regards,
Reshad.

On 2020-03-20, 5:08 PM, "netmod on behalf of Reshad Rahman (rrahman)" 
 wrote:

Hi Martin,

We've opened issues to track your review comments (see below). Will kick 
off separate therads for each issue.


https://github.com/netmod-wg/yang-ver-dt/issues?q=is%3Aissue+is%3Aopen+label%3Aupdated-mod-rev-handling

Regards,
Reshad.

On 2020-03-10, 3:31 PM, "netmod on behalf of Martin Björklund" 
 wrote:

Hi,

Here are my review comments of
draft-verdt-netmod-yang-module-versioning-01.



o  3.1.1

o  In statements that have any data definition statements as
   substatements, those data definition substatements MAY be
   reordered, as long as they do not change the ordering or any 
"rpc"
   "input" substatements.

  I think this needs to capture that no descendant statements to
  "input" can be reordered.  Same for "output" (note, "input" and
  "output" in both "rpc" and "action").


o  3.3

All revision labels that match the pattern for the "version"
typedef in the ietf-yang-semver YANG module MUST be interpreted as
YANG semantic version numbers.

  I don't think this is a good idea.  Seems like a layer violation.
  What if my project use another dialect of semver, that wouldn't be
  possible with this rule.  I think this needs to be removed.


o  3.3

Submodules MUST NOT use revision label schemes that could be 
confused
with the including module's revision label scheme.

  Hmm, how do I ensure that this MUST NOT is handled correctly?  What
  exactly does "could be confused with" mean?


o  3.3

  In the filename of a YANG module, where it takes the form: module-
  or-submodule-name ['@' revision-label] ( '.yang' / '.yin' )

  Should this section update 5.2 of RFC 7950?  I know that 5.2 just
  says "SHOULD".  But existing tools implement this SHOULD, and they
  need to be updated to handle this new convention.

  But I wonder if this a good idea.  It means that a tool that looks
  for a module with a certain revision date cannot simply check the
  filenames, but need to parse all available modules (wijust to find 
the 



o  3.4

 leaf imperial-temperature {
   type int64;
   units "degrees Fahrenheit";
   status deprecated {
 rev:status-description
   "Imperial measurements are being phased out in favor
of their metric equivalents.  Use metric-temperature
instead.";
   }
   description
 "Temperature in degrees Fahrenheit.";
 }

  I don't think rev:status-description is necessary / worth it.  This
  can easily be written with the normal description statement instead:

 leaf imperial-temperature {
   type int64;
   units "degrees Fahrenheit";
   status deprecated;
   description
   "Imperial measurements are being phased out in favor
of their metric equivalents.  Use metric-temperature
instead.

Temperature in degrees Fahrenheit.";
 }


o  3.5

  The example modules should be legal YANG modules.  Use e.g. 
  "urn:example:module" as namespace.

  Also, the modules are missing the last "}", which confuses the
  "rfcstrip" tool.


o 4.1.1

Alternatively, the first example could have used the revision label
"1.0.0" instead, which selects the same set of revisions/version

[netmod] All IETF YANG modules MUST include revision-label statements (WAS Re: mbj review of draft-verdt-netmod-yang-module-versioning-01)

[Reshad Rahman (rrahman)]

Hi,

https://github.com/netmod-wg/yang-ver-dt/issues/45

o  7.1

  The text says:

All IETF YANG modules MUST include revision-label statements for all
newly published YANG modules, and all newly published revisions of
existing YANG modules.  The revision-label MUST take the form of a
YANG semantic version number [I-D.verdt-netmod-yang-semver].

  I strongly disagree with this new rule.  IETF modules use a linear
  history, so there are no reasons to use "modified semver".

  It is ok to use rev:nbc-changes if needed, though.

We believe some IETF models may not follow linear history, this was brought up 
(I think) for IDR. Modified semver allows for non-linear history and also 
doesn't preclude linear history. So even if we end up having no IETF modules 
using branching, modified semver still works.

Regards,
Reshad.


On 2020-03-20, 5:08 PM, "netmod on behalf of Reshad Rahman (rrahman)" 
 wrote:

Hi Martin,

We've opened issues to track your review comments (see below). Will kick 
off separate therads for each issue.


https://github.com/netmod-wg/yang-ver-dt/issues?q=is%3Aissue+is%3Aopen+label%3Aupdated-mod-rev-handling

Regards,
Reshad.

On 2020-03-10, 3:31 PM, "netmod on behalf of Martin Björklund" 
 wrote:

Hi,

Here are my review comments of
draft-verdt-netmod-yang-module-versioning-01.



o  3.1.1

o  In statements that have any data definition statements as
   substatements, those data definition substatements MAY be
   reordered, as long as they do not change the ordering or any 
"rpc"
   "input" substatements.

  I think this needs to capture that no descendant statements to
  "input" can be reordered.  Same for "output" (note, "input" and
  "output" in both "rpc" and "action").


o  3.3

All revision labels that match the pattern for the "version"
typedef in the ietf-yang-semver YANG module MUST be interpreted as
YANG semantic version numbers.

  I don't think this is a good idea.  Seems like a layer violation.
  What if my project use another dialect of semver, that wouldn't be
  possible with this rule.  I think this needs to be removed.


o  3.3

Submodules MUST NOT use revision label schemes that could be 
confused
with the including module's revision label scheme.

  Hmm, how do I ensure that this MUST NOT is handled correctly?  What
  exactly does "could be confused with" mean?


o  3.3

  In the filename of a YANG module, where it takes the form: module-
  or-submodule-name ['@' revision-label] ( '.yang' / '.yin' )

  Should this section update 5.2 of RFC 7950?  I know that 5.2 just
  says "SHOULD".  But existing tools implement this SHOULD, and they
  need to be updated to handle this new convention.

  But I wonder if this a good idea.  It means that a tool that looks
  for a module with a certain revision date cannot simply check the
  filenames, but need to parse all available modules (wijust to find 
the 



o  3.4

 leaf imperial-temperature {
   type int64;
   units "degrees Fahrenheit";
   status deprecated {
 rev:status-description
   "Imperial measurements are being phased out in favor
of their metric equivalents.  Use metric-temperature
instead.";
   }
   description
 "Temperature in degrees Fahrenheit.";
 }

  I don't think rev:status-description is necessary / worth it.  This
  can easily be written with the normal description statement instead:

 leaf imperial-temperature {
   type int64;
   units "degrees Fahrenheit";
   status deprecated;
   description
   "Imperial measurements are being phased out in favor
of their metric equivalents.  Use metric-temperature
instead.

Temperature in degrees Fahrenheit.";
 }


o  3.5

  The example modules should be legal YANG modules.  Use e.g. 
  "urn:example:module" as namespace.

   

Re: [netmod] mbj review of draft-verdt-netmod-yang-module-versioning-01

[Reshad Rahman (rrahman)]

Hi Martin,

We've opened issues to track your review comments (see below). Will kick off 
separate therads for each issue.

https://github.com/netmod-wg/yang-ver-dt/issues?q=is%3Aissue+is%3Aopen+label%3Aupdated-mod-rev-handling

Regards,
Reshad.

On 2020-03-10, 3:31 PM, "netmod on behalf of Martin Björklund" 
 wrote:

Hi,

Here are my review comments of
draft-verdt-netmod-yang-module-versioning-01.



o  3.1.1

o  In statements that have any data definition statements as
   substatements, those data definition substatements MAY be
   reordered, as long as they do not change the ordering or any "rpc"
   "input" substatements.

  I think this needs to capture that no descendant statements to
  "input" can be reordered.  Same for "output" (note, "input" and
  "output" in both "rpc" and "action").


o  3.3

All revision labels that match the pattern for the "version"
typedef in the ietf-yang-semver YANG module MUST be interpreted as
YANG semantic version numbers.

  I don't think this is a good idea.  Seems like a layer violation.
  What if my project use another dialect of semver, that wouldn't be
  possible with this rule.  I think this needs to be removed.


o  3.3

Submodules MUST NOT use revision label schemes that could be confused
with the including module's revision label scheme.

  Hmm, how do I ensure that this MUST NOT is handled correctly?  What
  exactly does "could be confused with" mean?


o  3.3

  In the filename of a YANG module, where it takes the form: module-
  or-submodule-name ['@' revision-label] ( '.yang' / '.yin' )

  Should this section update 5.2 of RFC 7950?  I know that 5.2 just
  says "SHOULD".  But existing tools implement this SHOULD, and they
  need to be updated to handle this new convention.

  But I wonder if this a good idea.  It means that a tool that looks
  for a module with a certain revision date cannot simply check the
  filenames, but need to parse all available modules (wijust to find the 



o  3.4

 leaf imperial-temperature {
   type int64;
   units "degrees Fahrenheit";
   status deprecated {
 rev:status-description
   "Imperial measurements are being phased out in favor
of their metric equivalents.  Use metric-temperature
instead.";
   }
   description
 "Temperature in degrees Fahrenheit.";
 }

  I don't think rev:status-description is necessary / worth it.  This
  can easily be written with the normal description statement instead:

 leaf imperial-temperature {
   type int64;
   units "degrees Fahrenheit";
   status deprecated;
   description
   "Imperial measurements are being phased out in favor
of their metric equivalents.  Use metric-temperature
instead.

Temperature in degrees Fahrenheit.";
 }


o  3.5

  The example modules should be legal YANG modules.  Use e.g. 
  "urn:example:module" as namespace.

  Also, the modules are missing the last "}", which confuses the
  "rfcstrip" tool.


o 4.1.1

Alternatively, the first example could have used the revision label
"1.0.0" instead, which selects the same set of revisions/versions.

import example-module {
  rev:revision-or-derived 1.0.0;
}

  Shouldn't this be s/1.0.0/2.0.0/g ?


o  5

  I think the module name "ietf-yl-revisions" should be changed to
  "ietf-yang-library-revisions".   "yl" is not a well-known acronym.


o  5.2.2

  Wouldn't it be better if the leaf "deprecated-nodes-implemented" and
  "obsolete-nodes-absent" were of type "boolean" rather than type
  "empty"?


o  7.1

  The text says:

All IETF YANG modules MUST include revision-label statements for all
newly published YANG modules, and all newly published revisions of
existing YANG modules.  The revision-label MUST take the form of a
YANG semantic version number [I-D.verdt-netmod-yang-semver].

  I strongly disagree with this new rule.  IETF modules use a linear
  history, so there are no reasons to use "modified semver".

  It is ok to use rev:nbc-changes if needed, though.


o 7.1.1

  There is a missing " in:

   4.  For status "obsolete", it is RECOMMENDED to keep the "status-
   description" information, from when the node had status
   "deprecated, which is still relevant.
 HERE  ---^


o  8

  s/CODE ENDS>//

Re: [netmod] Adoption of versioning design team docs

[Reshad Rahman (rrahman)]

As author/DT member, I support adoption.

From: netmod  on behalf of Lou Berger 

Date: Monday, March 2, 2020 at 5:30 PM
To: NETMOD Group 
Cc: "netmod-cha...@ietf.org" 
Subject: [netmod] Adoption of versioning design team docs


Hi,

We'd like to start a two week adoption call for the set of documents described 
below by Rob.  To be specific, this includes

1) draft-verdt-netmod-yang-solutions-03

2) draft-verdt-netmod-yang-module-versioning-01

3) draft-verdt-netmod-yang-semver-01

4) draft-rwilton-netmod-yang-packages-03

5) draft-wilton-netmod-yang-ver-selection-02

6) draft-verdt-netmod-yang-schema-comparison-00



The adoption call ends in two weeks, on March 16.



Please voice your support or objections on list.  While we prefer to adopt as a 
set, objections on specific documents are acceptable.



Netmod Chairs



On 2/29/2020 2:21 AM, Rob Wilton (rwilton) wrote:

Netmod chairs,



The version selection draft draft-wilton-netmod-yang-ver-selection-02 is now 
posted.  With that, the YANG versioning design team would like to please 
request you make an WG adoption call for these documents.



The updated full list is:



1) draft-verdt-netmod-yang-solutions-03

  - Solution overview, updated since 106 to cover updates to version selection 
and schema comparison drafts.



2) draft-verdt-netmod-yang-module-versioning-01

  - Base module versioning solution, unchanged from the version presented at 
106.



3) draft-verdt-netmod-yang-semver-01

  - YANG Semantic version numbers, unchanged from the version presented at 106.



4) draft-rwilton-netmod-yang-packages-03

  - YANG packages draft, updated since 106



5) draft-wilton-netmod-yang-ver-selection-02

  - Version selection, updated since 106, as per notes below



6) draft-verdt-netmod-yang-schema-comparison-00

  - Schema comparison tooling, unchanged from the version presented at 106.



The main changes to the version selection draft are:

  - We have tried to simplify the model, but at the same time give servers more 
flexibility about how they implement version selection and what it can be used 
for.  E.g. if the server wants to allow a client to choose between different 
schema versions, but require that all clients use the same schema version, that 
is now possible

  - The draft explicitly disallows schema-selection happening mid-session

  - The solution allows the server to require clients to configure schema-sets 
before they are used

  - The solution provides more information about which schema-sets are 
compatible with each other



Regards,

Rob




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

Re: [netmod] Regarding IPR on draft-rwilton-netmod-yang-packages-03

[Reshad Rahman (rrahman)]

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

On 2020-03-02, 5:14 PM, "Lou Berger"  wrote:


Authors, Contributors, WG,

As part of preparation for WG Adoption:

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.

We note that all DT members are listed as contributors.  If you 
contributed to the document please respond.  Alternatively, please feel 
free to state that you didn't materially contribute to the draft and 
would like your name removed from the contribution section (and moved to 
acknowledgments after WG adoption).

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,
NetMod WG Chairs

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-wilton-netmod-yang-ver-selection-02

[Reshad Rahman (rrahman)]

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

On 2020-03-02, 5:13 PM, "Lou Berger"  wrote:


Authors, Contributors, WG,

As part of preparation for WG Adoption:

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.

We note that all DT members are listed as contributors.  If you 
contributed to the document please respond.  Alternatively, please feel 
free to state that you didn't materially contribute to the draft and 
would like your name removed from the contribution section (and moved to 
acknowledgments after WG adoption).

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,
NetMod WG Chairs

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-verdt-netmod-yang-module-versioning-01

[Reshad Rahman (rrahman)]

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

On 2020-03-02, 5:13 PM, "Lou Berger"  wrote:


Authors, Contributors, WG,

As part of preparation for WG Adoption:

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.

We note that all DT members are listed as contributors.  If you 
contributed to the document please respond.  Alternatively, please feel 
free to state that you didn't materially contribute to the draft and 
would like your name removed from the contribution section (and moved to 
acknowledgments after WG adoption).

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,
NetMod WG Chairs

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] [Netmod-ver-dt] Regarding IPR on draft-verdt-netmod-yang-schema-comparison-00

[Reshad Rahman (rrahman)]

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

On 2020-03-02, 5:14 PM, "Netmod-ver-dt on behalf of Lou Berger" 
 wrote:


Authors, Contributors, WG,

As part of preparation for WG Adoption:

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.

We note that all DT members are listed as contributors.  If you 
contributed to the document please respond.  Alternatively, please feel 
free to state that you didn't materially contribute to the draft and 
would like your name removed from the contribution section (and moved to 
acknowledgments after WG adoption).

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,
NetMod WG Chairs

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



___
Netmod-ver-dt mailing list
netmod-ver...@ietf.org
https://www.ietf.org/mailman/listinfo/netmod-ver-dt


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

Re: [netmod] Regarding IPR on draft-verdt-netmod-yang-semver-01

[Reshad Rahman (rrahman)]

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

On 2020-03-02, 5:13 PM, "Lou Berger"  wrote:


Authors, Contributors, WG,

As part of preparation for WG Adoption:

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.

We note that all DT members are listed as contributors.  If you 
contributed to the document please respond.  Alternatively, please feel 
free to state that you didn't materially contribute to the draft and 
would like your name removed from the contribution section (and moved to 
acknowledgments after WG adoption).

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,
NetMod WG Chairs

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] Problems with lint validation

[Reshad Rahman (rrahman)]

Balazs, we ran into the same issue last year. If you look at the ticket in the 
attached email, yanglint has a fix for the non-config leaf issue but OpenSUSE 
doesn’t have a version of libyang with the fix.

Regards,
Reshad.

From: netmod  on behalf of Balázs Lengyel 

Date: Tuesday, August 13, 2019 at 11:33 AM
To: "netc...@ietf.org" , "'netmod@ietf.org'" 
Subject: [netmod] Problems with lint validation

Hello,
I validated my model 
ietf-notification-capabilit...@2019-08-13.yang
 with yangvalidator.com. My model seems fine, but I got a lot of errors from 
lint:

yanglint Validation
err : The leafref leaf is config but refers to a non-config leaf. 
(/ietf-subscribed-notifications:subscriptions/subscription/target/stream/stream)
err : The leafref leaf is config but refers to a non-config leaf. 
(/ietf-subscribed-notifications:subscriptions/subscription/target/stream/stream)
err : Invalid value "subscription-policy" of "uses". 
(/ietf-subscribed-notifications:subscriptions/subscription/subscription-policy)
err : Copying data from grouping failed. 
(/ietf-subscribed-notifications:subscriptions/subscription/subscription-policy)
err : Module "ietf-subscribed-notifications" parsing failed.
err : Importing "ietf-subscribed-notifications" module into "ietf-yang-push" 
failed.
err : Module "ietf-yang-push" parsing failed.
err : Importing "ietf-yang-push" module into "ietf-notification-capabilities" 
failed.
err : Module "ietf-notification-capabilities" parsing failed.

At least some of these are not really errors. (pyang, confdc accepts them)
E.g.  the first error is not true because the leafref has require-instance 
false.

It would be nice if this could be corrected. I got the same messages from the 
draft submission tool too.

Regards Balazs
--- Begin Message ---
#2667: Newer version of yanglint needed for YANG validation

 So datatracker still has yanglint showing these errors for
 https://datatracker.ietf.org/doc/draft-ietf-netconf-subscribed-
 notifications:
 yanglint 0.14.80: yanglint --verbose -p {rfclib} -p {draftlib} -p {tmplib}
 {model} -i:
 err : The leafref leaf is config but refers to a non-config leaf. (/ietf-
 subscribed-notifications:subscriptions/subscription/target/stream/stream)

 This is due to issue below which was fixed in yanglint in 0.16.59
 https://github.com/CESNET/libyang/issues/644

 So we need datatracker to use a more recent version of yanglint.

 Regards,
 Reshad.

-- 
---+
 Reporter:  rrah...@cisco.com  |  Owner:
 Type:  enhancement| Status:  new
 Priority:  major  |  Milestone:  (None)
Component:  Datatracker: Yang  |Version:
 Keywords:  sprint |
---+

Ticket URL: 
ietfdb 


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

Re: [netmod] can a leaf of type "empty" have a "default" value?

[Reshad Rahman (rrahman)]

Hi Kent,

From https://tools.ietf.org/html/rfc7950#section-9.11
An empty type cannot have a default value.

Regards,
Reshad.

From: netmod  on behalf of Kent Watsen 

Date: Friday, May 17, 2019 at 3:53 PM
To: "netmod@ietf.org" 
Subject: [netmod] can a leaf of type "empty" have a "default" value?


A leaf with type "empty" is often times used to represent a boolean: present == 
set, not present == not set.  Is there a way in YANG to specify that the 
"empty" type leaf is "set" by default?  Perhaps like this:

leaf flag {
type empty;
default "";
}

Kent // contributor

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

[netmod] draft-wwx-netmod-event-yang

[Reshad Rahman (rrahman)]

Hi,

Took a look at the draft, some comments/questions:

  1.  Use of instance-identifier, so we need to list all instances individually?
  2.  Is the only possible action a set operation? In some cases an action such 
as reset would be desirable, have you considered RPC?
  3.  There are errors in the example, e.g. name should be 
interface-state-exception (not interface-exception)?
  4.  The example has 3 interfaces [eth1, eth2, eth3] in the event target, 2 
interfaces [eth1, eth2] in the trigger test and 1 interface [eth1] in the 
action. I don’t understand why.

Regards,
Reshad.

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

Re: [netmod] Adoption poll for draft-chopps-netmod-geo-location-01

[Reshad Rahman (rrahman)]

I support adoption of this draft as a WG document.

From: netmod  on behalf of Kent Watsen 

Date: Monday, March 25, 2019 at 9:33 PM
To: "netmod@ietf.org" 
Subject: [netmod] Adoption poll for draft-chopps-netmod-geo-location-01

This email begins a 2-week adoption poll for:


https://tools.ietf.org/html/draft-chopps-netmod-geo-location-01


Please voice your support or objections before April 8.


Kent // as co-chair



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

Re: [netmod] Adoption poll for draft-wu-netmod-factory-default-02

[Reshad Rahman (rrahman)]

I support adoption of this draft as a WG document.

+1 to what various people said with regards to simplifications needed in the 
document.

From: netmod  on behalf of Kent Watsen 

Date: Monday, March 25, 2019 at 9:35 PM
To: "netmod@ietf.org" 
Subject: [netmod] Adoption poll for draft-wu-netmod-factory-default-02

This email begins a 2-week adoption poll for:


https://tools.ietf.org/html/draft-wu-netmod-factory-default-02


Please voice your support or objections before April 
8.


Kent (and Lou)
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Adoption poll for draft-schoenw-netmod-rfc6991-bis-00

[Reshad Rahman (rrahman)]

I support adoption of this draft as a WG document.

From: netmod  on behalf of Kent Watsen 

Date: Monday, March 25, 2019 at 9:31 PM
To: "netmod@ietf.org" 
Subject: [netmod] Adoption poll for draft-schoenw-netmod-rfc6991-bis-00

This email begins a 2-week adoption poll for:


https://tools.ietf.org/html/draft-schoenw-netmod-rfc6991-bis-00


Please voice your support or objections before April 8.


Kent (and Lou and Joel)

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

Re: [netmod] adoption poll for yang-versioning-reqs-02

[Reshad Rahman (rrahman)]

From: netmod  on behalf of 'Andy Bierman' 

Date: Sunday, March 24, 2019 at 9:59 PM
To: Kent Watsen 
Cc: NetMod WG 
Subject: Re: [netmod] adoption poll for yang-versioning-reqs-02



On Sun, Mar 24, 2019 at 1:45 PM Kent Watsen 
mailto:kent%2bi...@watsen.net>> wrote:

Hi Andy,

> Andy Bierman wrote:
>
> BTW, I do not support adoption of the requirements document at all.

Can you say why?   Is it a blanket statement about adopting requirements drafts 
in general, or something specific to this draft.

Because they just waste time.
They are mostly reverse engineered from the desired solution (by the authors).

 I don’t think we’re tied to the solution of semver or modified semver 
(speaking for myself at least). The main question on the requirements is 
whether NBC changes should be accepted. Many people seem to think so, if you 
don’t agree that’s fine, but I disagree with the claim that the requirements 
are reverse engineered from the solution, I believe the design team has strived 
to separate the 2.

Reshad.

We end up having the same debates twice.

It is usually worse then that, since you end up debating the wording in the 
requirements
instead of the merits of the solution-in-progress (considering all factors and 
readjusted requirements).


Kent

Andy

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

Re: [netmod] adoption poll for yang-versioning-reqs-02

[Reshad Rahman (rrahman)]

Hi,

On 2019-03-20, 2:12 PM, "netmod on behalf of Rob Wilton (rwilton)" 
 wrote:

Hi Martin,


> 
> >  I.e. you don't think that we should be using semantic  versioning at
> > all
> 
> My objection is that I don't agree with the problem statement and I don't 
think
> that we should allow NBC in published modules.

But on a practical level this seems to be the same as stating:

"Published YANG modules MUST never have any bugs in any config true nodes."

Thanks,
Rob

+1
My recollection/understanding of how this work started is that some members of 
the WG felt that there are and will be cases where published YANG modules (SDOs 
or native) have bugs and have to be updated in an NBC way.

Regards,
Reshad.
 

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

Re: [netmod] adoption poll for yang-versioning-reqs-02

[Reshad Rahman (rrahman)]

As contributor, I support adoption of this document by the WG.

Regards,
Reshad.

From: netmod  on behalf of Kent Watsen 

Date: Wednesday, March 13, 2019 at 4:22 PM
To: "netmod@ietf.org" 
Subject: [netmod] adoption poll for yang-versioning-reqs-02

Seeing as how we all need to read this draft anyways, in preparation for our 
meeting in Prague, it seems like a good time for this poll.  Thusly, this email 
begins a 1-week adoption poll for:

https://tools.ietf.org/html/draft-verdt-netmod-yang-versioning-reqs-02

Please voice your support or objections before March 20.

Note that this draft defines *requirements* and its intended status is 
"Informational."   I believe that it is good for WGs to formalize requirements, 
even taking such drafts thru Last Call, in order to ensure consensus on the 
requirements.  This is the "adoption" call, to ascertain if the WG agrees with 
that statement; if adopted, a separate "last call" will be issued to ensure to 
correctness of the draft's content.

Kent (and Lou and Joel)


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

Re: [netmod] yang-next meeting at IETF 104?

[Reshad Rahman (rrahman)]

I am interested in attending the virtual meeting(s) and the in-person meeting 
in Prague (Monday-Thursday preferably).

On 2019-01-14, 5:27 PM, "netmod on behalf of Kent Watsen" 
 wrote:

>> PS: I've been too busy to setup a virtual meeting for us to finish the
>> review of the YANG-next items in the GitHub tracker.  But things are
>> just beginning to free up a little for me now.  Would folks like to
>> have a meeting before 104 to finish that review?
>
> I think that's what the side meeting would do - review the current
> items to see what makes sense.

Sure, but perhaps the in-person time would be better spent analyzing the 
results of the reviews?  Recall that we're trying to score each item on three 
axis: importance, complexity, backward-compatibility.

Current results here:  
https://github.com/netmod-wg/yang-next/issues?q=is%3Aissue+is%3Aopen+sort%3Acreated-asc.

At the rate we were going (about 40% done), I imagine it taking 2-4 hours 
to score the remaining issues.  This may not be an issue if we can meet 
multiple times during the week but, if time is tight, I'd rather have this part 
done before we meet.

Kent // contributor


___
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] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt

[Reshad Rahman (rrahman)]

On 2018-11-09, 8:51 PM, "Martin Bjorklund"  wrote:

    "Reshad Rahman (rrahman)"  wrote:
> 
> 
> On 2018-11-09, 8:37 PM, "netmod on behalf of Martin Bjorklund"
>  wrote:
> 
> Juergen Schoenwaelder  wrote:
> > On Thu, Nov 08, 2018 at 10:42:20PM +0100, Martin Bjorklund wrote:
> > > Juergen Schoenwaelder  
wrote:
> > > > On Sat, Oct 27, 2018 at 06:50:58AM -0700, Andy Bierman wrote:
> > > > > 
> > > > > This is what we have today only if modules are updated in 
legal
> > > > > ways.
> > > > > The 3.1 requirement says this backward compatibility is 
maintained
> > > > > even
> > > > > if the module is updated in violation of the module update 
rules.
> > > > >
> > > > 
> > > > It is stating a requirement. How solutions meet the requirement 
is
> > > > for
> > > > the solutions to figure out.
> > > > 
> > > > > How would 3.1 be met if the WG decided to just add a new
> > > > > 'datastore'
> > > > > key leaf to the /modules-state/module list?
> > > > 
> > > > Depends on the solution I guess.
> > > >  
> > > > > IMO the current "deprecate and start over" is actually the 
easiest
> > > > > and most robust solution path, and it requires no changes to 
YANG
> > > > > or
> > > > > the protocols.
> > > > 
> > > > Yep. But there are people who think that other solutions can do
> > > > better. The challenge is to find out whether they actually do 
better
> > > > or for whom they do better (and if someone has to pay a price 
for
> > > > it).
> > > > For having this discussions, it is good to write down 
requirements.
> > > > 
> > > > > >3.2 The solution MUST provide a mechanism to allow 
servers
> > > > > >to
> > > > > > simultaneously support clients using different
> > > > > > revisions of
> > > > > > modules.  A client's choice of particular 
revision of
> > > > > > one or
> > > > > > more modules may restrict the particular 
revision of
> > > > > > other
> > > > > > modules that may be used in the same request or
> > > > > > session.
> > > > > >
> > > > > > Today, the version number is effectively an (implicit) part 
of
> > > > > > the
> > > > > > module name (plus the revision date for backwards compatible
> > > > > > changes).
> > > > > > Hence, my understanding is that today's model does satisfy 
3.2 as
> > > > > > well.
> > > > > 
> > > > > This is not what we have at all. RFC 7950 says a server can 
only
> > > > > implement
> > > > > one revision of a module.
> > > > >
> > > > 
> > > > A new version today essentially means a new module name and I 
do not
> > > > see a conflict with what I wrote.
> > > 
> > > Then I think this requirement needs clarification.  It says 
"different
> > > revision of modules", which can be interpreted as different 
revisions
> > > of *the same* module.
> > > 
> > > Also the second part of the paragraph seems to indicate multiple
> > > revisions of the same module in the server.
> > > 
> > > I do not agree with this requirement.
> > 
> > Today, you need to create a new module if you make NBC changes to
> > existing changes (e.g., you change Bool to Int {0..1} and you are 
not
> > creating a new leaf). Since there are now two modules, you _can_
> > implement both modules if that makes sense.
> 
> Yes.
> 
> > If we allow to make such changes as 

Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt

[Reshad Rahman (rrahman)]

From: netmod  on behalf of 'Andy Bierman' 

Date: Friday, November 9, 2018 at 6:38 PM
To: Juergen Schoenwaelder , Martin 
Bjorklund , 'Andy Bierman' , NetMod WG 

Subject: Re: [netmod] New Version Notification for 
draft-verdt-netmod-yang-versioning-reqs-01.txt



On Fri, Nov 9, 2018 at 12:15 AM, Juergen Schoenwaelder 
mailto:j.schoenwael...@jacobs-university.de>>
 wrote:
On Thu, Nov 08, 2018 at 10:42:20PM +0100, Martin Bjorklund wrote:
> Juergen Schoenwaelder 
> mailto:j.schoenwael...@jacobs-university.de>>
>  wrote:
> > On Sat, Oct 27, 2018 at 06:50:58AM -0700, Andy Bierman wrote:
> > >
> > > This is what we have today only if modules are updated in legal ways.
> > > The 3.1 requirement says this backward compatibility is maintained even
> > > if the module is updated in violation of the module update rules.
> > >
> >
> > It is stating a requirement. How solutions meet the requirement is for
> > the solutions to figure out.
> >
> > > How would 3.1 be met if the WG decided to just add a new 'datastore'
> > > key leaf to the /modules-state/module list?
> >
> > Depends on the solution I guess.
> >
> > > IMO the current "deprecate and start over" is actually the easiest
> > > and most robust solution path, and it requires no changes to YANG or
> > > the protocols.
> >
> > Yep. But there are people who think that other solutions can do
> > better. The challenge is to find out whether they actually do better
> > or for whom they do better (and if someone has to pay a price for it).
> > For having this discussions, it is good to write down requirements.
> >
> > > >3.2  The solution MUST provide a mechanism to allow servers to
> > > > simultaneously support clients using different revisions of
> > > > modules.  A client's choice of particular revision of one or
> > > > more modules may restrict the particular revision of other
> > > > modules that may be used in the same request or session.
> > > >
> > > > Today, the version number is effectively an (implicit) part of the
> > > > module name (plus the revision date for backwards compatible changes).
> > > > Hence, my understanding is that today's model does satisfy 3.2 as
> > > > well.
> > >
> > > This is not what we have at all. RFC 7950 says a server can only implement
> > > one revision of a module.
> > >
> >
> > A new version today essentially means a new module name and I do not
> > see a conflict with what I wrote.
>
> Then I think this requirement needs clarification.  It says "different
> revision of modules", which can be interpreted as different revisions
> of *the same* module.
>
> Also the second part of the paragraph seems to indicate multiple
> revisions of the same module in the server.
>
> I do not agree with this requirement.

Today, you need to create a new module if you make NBC changes to
existing changes (e.g., you change Bool to Int {0..1} and you are not
creating a new leaf). Since there are now two modules, you _can_
implement both modules if that makes sense.


This does not make sense because a node in YANG is identified by a QName,
not just a local-name.   The node oldmod:foo is not the same as newmod:foo.
It never has been and never will be the same node.
 I disagree, per https://tools.ietf.org/html/rfc7950#section-4.2.1
   A server may implement a number of modules, allowing multiple views
   of the same data or multiple views of disjoint subsections of the
   server's data.  Alternatively, the server may implement only one
   module that defines all available data.


If we allow to make such changes as part of a module revision, i.e.,
without creating a new module, I think we should not loose the ability
to implement both the old version and the new version.

As Balazs asked, how can the data node be a boolean and an integer at the same 
time?
There seem to be plenty of scenarios that cannot be implemented simultaneously 
by a server.
 Correct, but some scenarios can be implemented. IMO we should document the 
type of changes where this would or would not work.

Regards,
Reshad.


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

Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt

[Reshad Rahman (rrahman)]

On 2018-11-09, 8:37 PM, "netmod on behalf of Martin Bjorklund" 
 wrote:

Juergen Schoenwaelder  wrote:
> On Thu, Nov 08, 2018 at 10:42:20PM +0100, Martin Bjorklund wrote:
> > Juergen Schoenwaelder  wrote:
> > > On Sat, Oct 27, 2018 at 06:50:58AM -0700, Andy Bierman wrote:
> > > > 
> > > > This is what we have today only if modules are updated in legal 
ways.
> > > > The 3.1 requirement says this backward compatibility is maintained 
even
> > > > if the module is updated in violation of the module update rules.
> > > >
> > > 
> > > It is stating a requirement. How solutions meet the requirement is for
> > > the solutions to figure out.
> > > 
> > > > How would 3.1 be met if the WG decided to just add a new 'datastore'
> > > > key leaf to the /modules-state/module list?
> > > 
> > > Depends on the solution I guess.
> > >  
> > > > IMO the current "deprecate and start over" is actually the easiest
> > > > and most robust solution path, and it requires no changes to YANG or
> > > > the protocols.
> > > 
> > > Yep. But there are people who think that other solutions can do
> > > better. The challenge is to find out whether they actually do better
> > > or for whom they do better (and if someone has to pay a price for it).
> > > For having this discussions, it is good to write down requirements.
> > > 
> > > > >3.2  The solution MUST provide a mechanism to allow 
servers to
> > > > > simultaneously support clients using different 
revisions of
> > > > > modules.  A client's choice of particular revision of 
one or
> > > > > more modules may restrict the particular revision of 
other
> > > > > modules that may be used in the same request or 
session.
> > > > >
> > > > > Today, the version number is effectively an (implicit) part of the
> > > > > module name (plus the revision date for backwards compatible 
changes).
> > > > > Hence, my understanding is that today's model does satisfy 3.2 as
> > > > > well.
> > > > 
> > > > This is not what we have at all. RFC 7950 says a server can only 
implement
> > > > one revision of a module.
> > > >
> > > 
> > > A new version today essentially means a new module name and I do not
> > > see a conflict with what I wrote.
> > 
> > Then I think this requirement needs clarification.  It says "different
> > revision of modules", which can be interpreted as different revisions
> > of *the same* module.
> > 
> > Also the second part of the paragraph seems to indicate multiple
> > revisions of the same module in the server.
> > 
> > I do not agree with this requirement.
> 
> Today, you need to create a new module if you make NBC changes to
> existing changes (e.g., you change Bool to Int {0..1} and you are not
> creating a new leaf). Since there are now two modules, you _can_
> implement both modules if that makes sense.

Yes.

> If we allow to make such changes as part of a module revision, i.e.,
> without creating a new module, I think we should not loose the ability
> to implement both the old version and the new version.

I don't think we should allow such changes, and if we did, I don't
think that both revisions should be implemented at the same time.  I
think the overall solution would just be too complex.

> I think we need to distinguish between the agreement on the
> requirement, namely that a server should be able to provide support
> for an old and a new definition, and agreement on the solution.
> 
> Do you disagree with the requirement? Or do you disagree with the
> consequences of implementing multiple versions of the same module
> for some of the proposed new versioning schemes? Or both?

I do not agree with the requirement that a server MUST be able to
support multiple revisions of the same module, which is how I
interpret 3.2.  If this is not the intention of 3.2, maybe it can be
clarified.

 It says "The solution MUST provide...", so the solution draft MUST provide 
a solution on how to do this. Whether a server implements the solution or not 
is a different matter. We realize this is a pain for most servers but some 
servers may be able to do it.

Regards,
Reshad.

/martin





> 
> /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] Comments on draft-ietf-netmod-yang-data-ext

[Reshad Rahman (rrahman)]

Hi,


  *   In section 2.2 1st paragraph the text says “…moved to this document and 
updated”. It would be clearer if there was a list/description of what’s been 
updated in 2.2 or a reference to another section where the update to RC 
yang-data is described.
  *   In example in A.2, should “yd:augment-yang-data /address-book/address” 
contain the module prefix? P8 has yd:augment-yang-data /foo:foo-con and the 
description mentions absolute-schema-nodeid

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

Re: [netmod] xpath expressions in JSON

[Reshad Rahman (rrahman)]

We can't time travel and as you mentioned option A has consistency within each 
encoding, so I'm also for option A. 

Regards,
Reshad.

On 2018-10-18, 6:30 AM, "netmod on behalf of Martin Bjorklund" 
 wrote:

Hi,

Going back to the most urgent issue, what is this WG's recommendation
for the subscribed-notifications draft in NETCONF wrt/ their usage of
yang:xpath1.0 in filters?

To summarize:

We already have

  o  instance-identifier in XML uses prefixes from the XML document
  o  instance-identifier in JSON uses module names as prefixes
  o  XPath in NETCONF filter uses prefixes from the XML document
  o  XPath in JSON query filter uses module names as prefixes


Alternative A:
--

Use different encodings for "stream-xpath-filter" as well, depending
on if it is XML or JSON.

We would do in SN:

o  If the node is encoded in XML, the set of namespace
   declarations are those in scope on the
   'stream-xpath-filter' leaf element.

o  If the node is encoded in JSON, the set of namespace
   declarations is the set of prefix and namespace pairs
   for all supported YANG modules, where the prefix is
   the YANG module name and the namespace is as defined
   by the "namespace" statement in the YANG module.

Pro: the format is consistent within each encoding.

Con: unclear how to handle other encodings.
Con: we keep using context-depending encodings.

We could probably add that CBOR uses the same representation as JSON.

Example in XML:

  
/if:interfaces/if:interface/ip:ipv4
  

Example in JSON:

  "stream-xpath-filter":
"/ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4"



Alternative B:
--

Use a non-context depending encoding, with the module name as prefix.

We would do in SN:

o  The set of namespace
   declarations is the set of prefix and namespace pairs
   for all supported YANG modules, where the prefix is
   the YANG module name and the namespace is as defined
   by the "namespace" statement in the YANG module.

Pro: the format is independent from the protocol encoding

Con: in XML, this leaf is treated differently from other XPath
 expressions, such as get-config filter and nacm rules.

Example in XML:

  
/ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4
  

Example in JSON:

  "stream-xpath-filter":
"/ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4"


My proposal is A.  I think it is more important with consistency
within each encoding than across encodings.

(This said, I would like to have a context-independent encoding of all
YANG types in the future.  But not now.)




/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] xpath expressions in JSON

[Reshad Rahman (rrahman)]

On 2018-10-12, 4:37 AM, "netmod on behalf of Martin Bjorklund" 
 wrote:

Robert Wilton  wrote:
> 
> 
> On 11/10/2018 17:11, Martin Bjorklund wrote:
> > Robert Wilton  wrote:
> >>
> >> On 11/10/2018 11:50, Martin Bjorklund wrote:
> >>> Robert Wilton  wrote:
> >>>> On 11/10/2018 11:21, Martin Bjorklund wrote:
> >>>>> Andy Bierman  wrote:
> >>>>>> On Wed, Oct 10, 2018 at 11:39 PM, Martin Bjorklund 

> >>>>>> wrote:
> >>>>>>
> >>>>>>> Andy Bierman  wrote:
> >>>>>>>> On Wed, Oct 10, 2018 at 6:59 PM, Reshad Rahman (rrahman) <
> >>>>>>> rrah...@cisco.com>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> On 2018-10-10, 9:59 AM, "netmod on behalf of Martin Bjorklund" <
> >>>>>>>>> netmod-boun...@ietf.org on behalf of m...@tail-f.com> wrote:
> >>>>>>>>>
> >>>>>>>>>Ladislav Lhotka  wrote:
> >>>>>>>>>> Martin Bjorklund  writes:
> >>>>>>>>>>
> >>>>>>>>>> > Hi,
> >>>>>>>>>> >
> >>>>>>>>>> > While reviewing restconf-notif, I saw this example:
> >>>>>>>>>> >
> >>>>>>>>>> >{
> >>>>>>>>>> >   "ietf-subscribed-notifications:input": {
> >>>>>>>>>> >  "stream": "NETCONF",
> >>>>>>>>>> >  "stream-xpath-filter": "/ds:foo/",
> >>>>>>>>>> >  "dscp": "10"
> >>>>>>>>>> >   }
> >>>>>>>>>> >}
> >>>>>>>>>> >
> >>>>>>>>>> > Note the "stream-xpath-filter".  It has a prefix in 
the
> >>>>>>>>>> > XPath
> >>>>>>>>> string.
> >>>>>>>>>> > How are prefixes declared when JSON is used?
> >>>>>>>>>> >
> >>>>>>>>>> > The leaf "stream-xpath-filter" says:
> >>>>>>>>>> >
> >>>>>>>>>> >   o The set of namespace declarations are
> >>>>>>>>>> >   those
> >>>>>>>>>> >   in
> >>>>>>>>> scope on
> >>>>>>>>>> >  the 'stream-xpath-filter' leaf 
element.
> >>>>>>>>>> >
> >>>>>>>>>> > (I think I provided that text...)
> >>>>>>>>>> >
> >>>>>>>>>> > This assumes that the encoding is XML, or at leas 
that the
> >>>>>>> encoding
> >>>>>>>>>> > can somehow transfer namespace declarations.
> >>>>>>>>>>
> >>>>>>>>>> It can't. There are two options:
> >>>>>>>>>>
> >>>>>>>>>> 1. have different representations of this value in XML 
and
> >>>>>>>>>> JSON,
> >>>>>>>>>>analogically to instance indentifiers (sec. 6.11 in 
RFC
> >>>>>>>>>>7951).
> >>>>>>>>>>
> >>>>>>>>>> 2. use a module name rather than a prefix in XML, too.
> >>>>>>>>>>
> >>>>>>>>>> I would suggest #2.
> >>>>>>>>>  But that means mak

Re: [netmod] xpath expressions in JSON

[Reshad Rahman (rrahman)]

Hi Rob,


From: "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" 
Date: Thursday, October 11, 2018 at 11:56 AM
To: "Reshad Rahman (rrahman)" 
Cc: Martin Bjorklund , "netmod@ietf.org" 
Subject: Re: [netmod] xpath expressions in JSON




Yet the examples in section 8.3.6 don't seem to use namespace prefixes in very 
many places, e.g. why is it "/example-mod:event1/name='joe'" and not 
"/example-mod:event1/example-mod:name='joe'"?  Is the example wrong, or 
otherwise what am I missing? :-)


 Section 8.3.6 of which document?
RFC 8040.

 B.3.6, got it. Was looking for 8.3.6, that’s why didn’t find it.

Regards,
Reshad.


Thanks,
Rob



Regards,
Reshad.

Thanks,
Rob











/martin







Thanks,

Rob





There is no standard XPath implementation that can just take an XML

instance document + YANG module and figure out what to do.  Custom

code is needed to connect things together.  This proposal doesn't

change this.





/martin





A normal XPath implementation will not find any namespace mapping for

the

prefixes.



An XPath expression has no concept of the "current module" inherited

from

the parent

like the JSON encoding. This is problematic for predicates



/ietf-interfaces:interfaces/interface[name='eth0']



XPath says the missing prefixes for 'interface' and 'name' are simply

missing (no namespace).

The JSON encoding says "ietf-interfaces" is used for 'interfaces'. and

'interface'.

There is no specification for the 'name' node inside a predicate.



So you must mean the full module name will be used at every node:



  
/ietf-interfaces:interfaces/ietf-interfaces:interface[ietf-interfaces:name='eth0']







/martin





Andy





 Hmm, so you mean change the leaf "stream-xpath-filter" to say:



  o  The set of namespace declarations has one member for

each

 YANG module supported by the server.  This member maps

 from the YANG module name to the YANG module namespace.



 This means that in the XPath expression, the module

name

 serves as the prefix.



  and then also give an example of this.



 This is probably what we need to do in all places where

yang:xpath1.0

 is used, going forward.  Maybe even define a new type

 yang:xpath1.0-2 (name?) with the set of namespace declarations

 built-in.



We should avoid making off-the-shelf implementations of standards like

XPath unusable.

At the very least this should be only available if the server supports

it

(with a capability URI)







 So we need an update to RFC7951?



Regards,

Reshad.





Andy





 /martin











 >

 > Lada

 >

 > >

 > > How is this supposed to work with JSON?

 > >

 > >

 > > /martin

 > >

 > > ___

 > > netmod mailing list

 > > netmod@ietf.org<mailto:netmod@ietf.org>

 > > https://www.ietf.org/mailman/listinfo/netmod

 >

 > --

 > Ladislav Lhotka

 > Head, CZ.NIC Labs

 > PGP Key ID: 0xB8F92B08A9F76C67

 >



 ___

 netmod mailing list

 netmod@ietf.org<mailto:netmod@ietf.org>

 https://www.ietf.org/mailman/listinfo/netmod





___

netmod mailing list

netmod@ietf.org<mailto:netmod@ietf.org>

https://www.ietf.org/mailman/listinfo/netmod



___

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] xpath expressions in JSON

[Reshad Rahman (rrahman)]

Hi Rob,

From: netmod  on behalf of "Robert Wilton -X (rwilton 
- ENSOFT LIMITED at Cisco)" 
Date: Thursday, October 11, 2018 at 7:17 AM
To: Martin Bjorklund 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] xpath expressions in JSON




On 11/10/2018 11:50, Martin Bjorklund wrote:

Robert Wilton <mailto:rwil...@cisco.com> wrote:



On 11/10/2018 11:21, Martin Bjorklund wrote:

Andy Bierman <mailto:a...@yumaworks.com> wrote:

On Wed, Oct 10, 2018 at 11:39 PM, Martin Bjorklund 
<mailto:m...@tail-f.com>

wrote:



Andy Bierman <mailto:a...@yumaworks.com> wrote:

On Wed, Oct 10, 2018 at 6:59 PM, Reshad Rahman (rrahman) <

rrah...@cisco.com<mailto:rrah...@cisco.com>>

wrote:



On 2018-10-10, 9:59 AM, "netmod on behalf of Martin Bjorklund" <

netmod-boun...@ietf.org<mailto:netmod-boun...@ietf.org> on behalf of 
m...@tail-f.com<mailto:m...@tail-f.com>> wrote:



 Ladislav Lhotka <mailto:lho...@nic.cz> wrote:

 > Martin Bjorklund <mailto:m...@tail-f.com> writes:

 >

 > > Hi,

 > >

 > > While reviewing restconf-notif, I saw this example:

 > >

 > >{

 > >   "ietf-subscribed-notifications:input": {

 > >  "stream": "NETCONF",

 > >  "stream-xpath-filter": "/ds:foo/",

 > >  "dscp": "10"

 > >   }

 > >}

 > >

 > > Note the "stream-xpath-filter".  It has a prefix in the XPath

string.

 > > How are prefixes declared when JSON is used?

 > >

 > > The leaf "stream-xpath-filter" says:

 > >

 > >   o  The set of namespace declarations are those in

scope on

 > >  the 'stream-xpath-filter' leaf element.

 > >

 > > (I think I provided that text...)

 > >

 > > This assumes that the encoding is XML, or at leas that the

encoding

 > > can somehow transfer namespace declarations.

 >

 > It can't. There are two options:

 >

 > 1. have different representations of this value in XML and JSON,

 >analogically to instance indentifiers (sec. 6.11 in RFC 7951).

 >

 > 2. use a module name rather than a prefix in XML, too.

 >

 > I would suggest #2.

 But that means making non-backwards compatible change to the XML

representation?



Not really. It means NETMOD WG would be creating its own special

variant

of

XPath.

Not at all.  What I propose is perfectly fine, legal XPath 1.0.



XPath 1.0 says that an XPath expression is evaluated in a context.

One item in the context is a set of mappings from  to ,

where  is used to lookup prefixes used in the XPath

expression, e.g. in "/foo:interfaces" "foo" is the prefix.



It is perfectly fine to say that the prefix mapping set is this:



"ietf-interfaces" -> "urn:ietf:params:xml:ns:yang:ietf-interfaces"

"ietf-ip" -> "urn:ietf:params:xml:ns:yang:ietf-ip"



and use that to evaluate the expression



   /ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip/ipv4







The XPath expression is normally parsed within an XML instance

document.

There are "xmlns" attributes present that map the prefix to a

namespace URI.

These mappings will not be present in the JSON at all.



A custom XPath implementation is required to magically identify the

prefix

as a module name and magically find the namespace URI for the module

name.

I disagree.  You need an XPath implementation + custom code to set up

the environment.

This is OK, but can we just use the JSON encoding instance identifier

format exactly?  I.e .RFC 7951 section 6.11.



So "/ietf-interfaces:interfaces/interface/ietf-ip:ipv4/enabled"



can trivially be expanded to:



"/ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4/ietf-ip:enabled",



and then interpreted with the context:

 "ietf-interfaces" -> "urn:ietf:params:xml:ns:yang:ietf-interfaces"

   "ietf-ip" -> "urn:ietf:params:xml:ns:yang:ietf-ip"

*this* would require a custom XPath implementation.
Why?  I.e. how is this different from stating "Custom code is needed to connect 
things together"?





and it is not obvious what the rules for the "auto-assignment" of

prefixes would be.  For example:



  /ietf-interfaces//ietf-ip:address[../foo]



what is the prefix for "foo"?
OK, so here the module for "../foo" would need to be specified.

Perhaps the rule that I'm looking for is the module name may be omitted when it 
matches the parent node module, and

Re: [netmod] xpath expressions in JSON

[Reshad Rahman (rrahman)]

On 2018-10-10, 9:59 AM, "netmod on behalf of Martin Bjorklund" 
 wrote:

Ladislav Lhotka  wrote:
> Martin Bjorklund  writes:
> 
> > Hi,
> >
> > While reviewing restconf-notif, I saw this example:
> >
> >{
> >   "ietf-subscribed-notifications:input": {
> >  "stream": "NETCONF",
> >  "stream-xpath-filter": "/ds:foo/",
> >  "dscp": "10"
> >   }
> >}
> >
> > Note the "stream-xpath-filter".  It has a prefix in the XPath string.
> > How are prefixes declared when JSON is used?
> >
> > The leaf "stream-xpath-filter" says:
> >
> >   o  The set of namespace declarations are those in scope on
> >  the 'stream-xpath-filter' leaf element.
> >
> > (I think I provided that text...)
> >
> > This assumes that the encoding is XML, or at leas that the encoding
> > can somehow transfer namespace declarations.
> 
> It can't. There are two options:
> 
> 1. have different representations of this value in XML and JSON,
>analogically to instance indentifiers (sec. 6.11 in RFC 7951).
> 
> 2. use a module name rather than a prefix in XML, too.
> 
> I would suggest #2.
 But that means making non-backwards compatible change to the XML 
representation?

Hmm, so you mean change the leaf "stream-xpath-filter" to say:

 o  The set of namespace declarations has one member for each
YANG module supported by the server.  This member maps
from the YANG module name to the YANG module namespace.

This means that in the XPath expression, the module name
serves as the prefix.

 and then also give an example of this.

This is probably what we need to do in all places where yang:xpath1.0
is used, going forward.  Maybe even define a new type
yang:xpath1.0-2 (name?) with the set of namespace declarations
built-in.
 So we need an update to RFC7951?

Regards,
Reshad.


/martin





> 
> Lada
> 
> >
> > How is this supposed to work with JSON?
> >
> >
> > /martin
> >
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> -- 
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
> 

___
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] WG adoption poll

[Reshad Rahman (rrahman)]

Support.

On 2018-10-08, 7:39 AM, "netmod on behalf of Lou Berger" 
 wrote:

All,

This is start of a two week poll on making
draft-lengyel-netmod-yang-instance-data-04 a working group
document. Please send email to the list indicating "yes/support" or
"no/do not support".  If indicating no, please state your reservations
with the document.  If yes, please also feel free to provide comments
you'd like to see addressed once the document is a WG document.

The poll ends Oct 22.

Thanks,

Lou (and co-chairs)

___
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] WG adoption poll for draft-clemm-netmod-nmda-diff-00

[Reshad Rahman (rrahman)]

On 2018-10-04, 4:22 PM, "netmod on behalf of Juergen Schoenwaelder" 
 
wrote:

On Thu, Oct 04, 2018 at 08:09:55PM +, Kent Watsen wrote:
> Sure, one mandatory to implement format, others nice to have.
> Interoperability good.  Agreed.
> 
> But why YANG-patch and not something built for the purpose
> (e.g., YANG-diff) that, in particular, provides an actual diff as
> opposed to a data-tree operation that only shows one of the
> two values?

Because this is yet a third format. There is a certain benefit if a
diff format can also be used to patch. If we create a new diff format,
guess what will come up next...
 And there are ways to get the missing values (from source datastore).

/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] [yang-doctors] Quirky YANG

[Reshad Rahman (rrahman)]

Thanks Mahesh. So the IESG is supposed to ask for YD review at this point for 
draft-ietf-softwire-yang?

From: Mahesh Jethanandani 
Date: Wednesday, October 3, 2018 at 7:38 PM
To: "Reshad Rahman (rrahman)" 
Cc: tom petch , "netmod@ietf.org" , YANG 
Doctors 
Subject: Re: [yang-doctors] [netmod] Quirky YANG




On Oct 3, 2018, at 2:41 PM, Reshad Rahman (rrahman) 
mailto:rrah...@cisco.com>> wrote:

Are YD reviews optional for IETF YANG modules? I assumed it was mandatory.

Here is what it says on the YD page:

All YANG documents will be passed by a YANG doctor reviewer before they will be 
approved by the IESG. The YANG doctor review must be done after the Working 
Group Last Call and before the IETF Last Call. ADs and WG chairs responsible on 
I-Ds that include YANG documents should ask the OPS ADs for a review as soon as 
the document completed WGLC. Failing that request, the review will be conducted 
during the IETF Last Call.

Mahesh Jethanandani
mjethanand...@gmail.com<mailto:mjethanand...@gmail.com>




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

Re: [netmod] Quirky YANG

[Reshad Rahman (rrahman)]

Are YD reviews optional for IETF YANG modules? I assumed it was mandatory.

On 2018-10-03, 12:11 PM, "netmod on behalf of tom petch" 
 wrote:

I wonder if anyone else on this list has looked at
 https://datatracker.ietf.org/doc/draft-ietf-softwire-yang/
currently in IETF Last Call.

It provides management for three tunnel types, Lw4o6, MAP-E and MAP-T
betweeen CPE and Border Relay.  It defines a CPE module, a BR module and
a module of common definitions.

It does not provide identities for the three tunnel types; rather, where
it augments "/if:interfaces/if:interface" it specifies
when "if:type = 'ianaift:tunnel'";
which to me says that a MAP-E (e.g.) specific object will get added to
each and every tunnel of whatever type, which seems excessive.

Second, it defines four features, softwire-ce:algorithm (i.e.
MAP-E/MAP-T) and softwire-ce:binding (i.e. Lw4o6) in the CPE module and
then again softwire-br:algorithm and softwire-br:binding in the BR
module.  It is unclear to me, from the I-D, whether support is for MAP-T
and MAP-E; or either MAP-T or MAP-E - I find the I-D ambiguous on that
point - but I would have expected there to be either two - Lw4o6 and
MAP-ET - or three - Lw4o6, MAP-E and MAP-T features, not four; and for
the features to be defined, along with tunnel identities, in the common
module.

Odd, IMHO.

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] WG adoption poll for draft-clemm-netmod-nmda-diff-00

[Reshad Rahman (rrahman)]

No objection, I support adoption of this document.

Regards,
Reshad.


On 2018-10-02, 9:52 AM, "Kent Watsen"  wrote:

Hi Reshad, thanks for asking.

It's a grey area.  It could go either way.  Both charters support the work. 
 The chairs are all 50/50 as for best fit.  Squinting, it seems more an 
NMDA-thing than a transport-thing (i.e., not NC or RC specific), and NETMOD is 
more the "NMDA group" than NETCONF, at least the first-order of it seems to be 
that way.

That said, NETCONF is overloaded and NETMOD is not (14 vs 4 drafts).  Of 
course, similar people are in both working groups, but it would be good to 
offload some discussion from the NETCONF list and give this WG something more 
to work on.  I hope this is okay with everyone.

With respect to the adoption poll.  The important thing here is if anyone 
objects.  Do you or anyone else object?

Kent // chair


-Original Message-----
From: "Reshad Rahman (rrahman)" 
Date: Tuesday, October 2, 2018 at 8:21 AM
To: Kent Watsen , "netmod@ietf.org" 
Subject: Re: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00

Kent, I may have asked this question in Montreal but I don't remember the 
answer: why is this document in NETMOD and not in NETCONF?

Regards,
Reshad.

On 2018-10-01, 2:48 PM, "netmod on behalf of Kent Watsen" 
 wrote:

The IETF 102 in-room poll should really good support to adopt
this draft, and no objections.

This email starts an adoption poll for:

  
https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dclemm-2Dnetmod-2Dnmda-2Ddiff-2D00=DwIGaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=cMA9GOjXbEWKsL9ICiakKStMZSuPfNOrlbLOOkIrdqU=BKA6fI-QY2tt_NTOva9I61482LGGZdzDMFBqVF1O_0s=

Please indicate your support or objection to the adoption poll. 
If objecting, please state your reasons on this thread.

Kent (and Lou and Joel)

___
netmod mailing list
netmod@ietf.org

https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod=DwIGaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=cMA9GOjXbEWKsL9ICiakKStMZSuPfNOrlbLOOkIrdqU=VClQL9M7t-fz3-dJqMGi8tK-_iyPfbyizqPA_x8VMHo=





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

Re: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00

[Reshad Rahman (rrahman)]

Kent, I may have asked this question in Montreal but I don't remember the 
answer: why is this document in NETMOD and not in NETCONF?

Regards,
Reshad.

On 2018-10-01, 2:48 PM, "netmod on behalf of Kent Watsen" 
 wrote:

The IETF 102 in-room poll should really good support to adopt
this draft, and no objections.

This email starts an adoption poll for:

  https://tools.ietf.org/html/draft-clemm-netmod-nmda-diff-00

Please indicate your support or objection to the adoption poll. 
If objecting, please state your reasons on this thread.

Kent (and Lou and Joel)

___
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] NMDA - different valid keys for config vs state

[Reshad Rahman (rrahman)]

I thought this had been discussed previously but couldn’t find the email.

IMO  option 1) makes more sense, the key range should be a superset of config 
and oper since the model applies to both. Don’t know if there’s any mechanism 
which allows for different range per datastore.

Regards,
Reshad.

From: netmod  on behalf of "Sterne, Jason (Nokia - 
CA/Ottawa)" 
Date: Thursday, May 10, 2018 at 1:07 PM
To: "netmod@ietf.org" 
Subject: [netmod] NMDA - different valid keys for config vs state

Hi all,

In the NMDA approach we're trying to combine config & state into the same 
common tree structure.   i.e. For a given list, model a single list that 
contains both config & state, vs separate lists for each of config & state.

But what happens when the valid value space for config vs state is different ?  
 For example -> what if an implementation has internally created interfaces 
with names that start with '_internal_' and doesn't allow configuration of 
those interfaces ?

If there were separate config vs state lists then the config list may have a 
pattern associated with the key that disallows names that start with 
'_internal_'.

To keep the spirit of NMDA it would be a shame to split into separate config & 
state lists for this case.  Any recommendations ?

1) make the 'pattern' for the key be a superset (i.e. allow _internal_) and 
then just reject config requests for _internal_ interfaces (e.g. at commit 
time) ?

2) make the 'pattern' more strict to match config, and then return _internal_ 
interfaces for state queries (that in theory break the pattern for the key) ?

3) other suggestions ?

Another example could be an integer key that has a larger range for state than 
it does for config (i.e. IDs >1000 are for internal entries only, not 
configurable).

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

Re: [netmod] WG Last Call: draft-ietf-netmod-rfc6087bis-14

[Reshad Rahman (rrahman)]

Regarding validation, section 3.10 refers to pyang tool. Since the set of tools 
might change in the future, shouldn't the reference be to the yangvalidator url 
or something along those lines (instead of an exhaustive list which may change)?

I think there is a nit in section 2.4, the '.' after 
[I-D.ietf-netmod-revised-datastores] should be removed or replaced by a comma.

Regards,
Reshad.

From: netmod  on behalf of Eric Voit (evoit)
Sent: Tuesday, October 17, 2017 7:06 PM
To: draft-ietf-netmod-rfc6087...@ietf.org
Cc: netmod-cha...@ietf.org; netmod@ietf.org
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-rfc6087bis-14

I was also encouraged to provide comments.  A couple (new?) minor ones...

Section 3.4:
- If a tree diagram is included for an augmented model, it SHOULD contain the 
integrated of the augmented model.  I.e., use the pyang -f command to generate 
the tree so that you can explicitly see the schema elements imported

Side comment: if a YANG module contains extension structures (like YANG-Data) 
these should also be shown in the tree, but I understand why you might not want 
to make that a requirement of this document.

Section 3.10: There should be a normative set of YANG validation tools which 
are run on upload of an Internet draft.   Errors and warnings found later (and 
perhaps through tools a user doesn't have) should not result in a module being 
given an error designation.

Thanks,
Eric


___
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