Re: [netmod] New Version Notification for draft-tao-netmod-yang-node-tags-04.txt

[王 巍]

Hi Qin,

Thanks for updating, I think telemetry data tagging and classification is a 
good idea, it captures different
KPI data from various different data source and correlate them together and 
provide
comprehensive view of the network quality, also provide consistent 
representation and reporting.
I want to see this work being adopted, I am willing to review and contribute to 
this draft.
A few quick comments on v-03 based on our offline discussion:
1. It is not clear metric group should be part of opm tags, if my understanding 
is correct, the metric group is used to
correlate different type network performance metrics together and serve as 
context information, suggest to split metric group
from opm tags.
2. Can you provide a NETCONF example on data object tag management?
3. Data Node Tags and Data object Tags are used in many places, I believe they 
are interchangeable, for consistency,
please use one or another.
4. Section 7.2, suggest to split Metric group from data node tag, I also 
believe data node tag should be changed into OPM tag
based on the context provided.

Best Regards,
Wei Wang
China Telecom


-邮件原件-
发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Qin Wu
发送时间: 2020年8月10日 21:04
收件人: NETMOD Group 
主题: Re: [netmod] New Version Notification for 
draft-tao-netmod-yang-node-tags-04.txt

Hi,
v-04 is posted, to address comments received from Jurgen and a few offline 
discussion.
https://datatracker.ietf.org/doc/html/draft-tao-netmod-yang-node-tags
The main changes include:
1. Add one NETCONF example in the appendix 2. Add Non-NMDA State Module in the 
appendix 3. Module structure alignment with module tag module.
4. Split Metric group from opm tag and define it as context info tag.
5. A few changes to Self Explanation Tags Use Cases.

-Qin
-邮件原件-
发件人: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
发送时间: 2020年8月10日 20:56
收件人: Qin Wu ; Qin Wu ; Benoit Claise 
; Liang Geng ; Zongpeng Du 

主题: New Version Notification for draft-tao-netmod-yang-node-tags-04.txt


A new version of I-D, draft-tao-netmod-yang-node-tags-04.txt
has been successfully submitted by Qin Wu and posted to the IETF repository.

Name:draft-tao-netmod-yang-node-tags
Revision:04
Title:Self Explanation Data Object Tags
Document date:2020-08-10
Group:netmod
Pages:40
URL:
https://www.ietf.org/internet-drafts/draft-tao-netmod-yang-node-tags-04.txt
Status: 
https://datatracker.ietf.org/doc/draft-tao-netmod-yang-node-tags/
Htmlized:   https://tools.ietf.org/html/draft-tao-netmod-yang-node-tags-04
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-tao-netmod-yang-node-tags
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-tao-netmod-yang-node-tags-04

Abstract:
   This document defines a method to tag data objects associated with
   operation and management data in YANG Modules.  This YANG data object
   tagging method can be used to identify characteristics data and
   correlate data objects from different data sources and provide input,
   instruction, indication to selection filter and filter queries of
   operational state on a server during a "pub/sub" service for YANG
   datastore updates.  When the state of all subscriptions of a
   particular Subscriber to be fetched is huge, the amount of data to be
   streamed out to the destination can be greatly reduced and only
   targeted to the characteristics data.

   An extension statement to be used to indicate YANG data node self
   explanation tags that SHOULD be added by the module implementation
   automatically (i.e., outside of configuration).

   A YANG module [RFC7950] is defined, which augments Module tag model
   and provides a list of data node entries to allow for adding or
   removing of data node self explanation tags as well as viewing the
   set of self explanation tags associated with a YANG module.




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.

The IETF Secretariat


___
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] IETF 108: Summary of insignificant whitespace changes and versioning

[Joe Clarke (jclarke)]

> On Aug 11, 2020, at 10:52, Ladislav Lhotka  wrote:
> 
> 
> 
> On 11. 08. 20 15:41, Joe Clarke (jclarke) wrote:
>> At the IETF 108 virtual meeting, Lada asked about what would happen if he 
>> converted a YANG module to YIN syntax (or vice versa, or to some other 
>> format).  This was during the discussion of the issue of what should happen 
>> if a module changes and the only changes are insignificant whitespaces 
>> (e.g., strip trailing spaces, change line length of descriptions, etc.).
>> 
>> The authors/contributors discussed on this on our weekly calls, and we 
>> propose:
>> 
>> If a module changes and those changes are only insignificant whitespace 
>> changes and the syntax of the module remains the same (i.e., YANG to YANG, 
>> YIN, YIN, etc.), a new revision of the module MUST be created.  If you are 
>> using YANG semver as your revision scheme, you MUST apply a PATCH version 
>> bump to that new module revision to indicate an editorial change.
>> 
>> The reasoning behind this decision is that it makes it very clear and 
>> unambiguous to consumers that this module has been consciously changed, and 
>> those changes are only editorial.  This way one won’t be concerned if they 
>> note that a module of a given syntax with the same version but different 
>> checksums and diffs wasn’t otherwise manipulated.
>> 
>> That said, if a module changes format from one syntax to another but 
>> maintains semantic equivalency, then the revision and YANG semver MUST be 
>> the same.  In that case, one will use the extension to realize that this 
>> module file cannot be directly compared to one of another syntax without 
>> looking at compiled or semantic representation.
> 
> The last paragraph means that after a round trip YANG -> YIN -> YANG the
> initial and final YANG modules MUST have the same revision. However,
> depending on the conversion tools used, they may easily differ in
> whitespace, so their byte-oriented checksums won't be equal.

I shared comments from our discussion today in my response to Martin.

> 
> I think there are in fact three cases:

Yeah.  We also discussed if this notion of “insignificant” white space was 
documented.  We weren’t sure that all of these cases were properly spelled out 
anywhere.

> 
> 1. Whitespace outside statement arguments - I believe this should never
> be significant.
> 
> 2. Whitespace in the argument of "contact", "description",
> "error-message" and "organization" - this is tricky because tools may
> format such arguments differently. I am leaning towards making
> whitespace insignificant in this case as well.
> 
> 3. Whitespace in other arguments has to be significant and lead to a
> revision bump.
> 
> And one more corner case for both 2 a 3: what if "\t" is replaced with
> the tab character in a double-quoted string? For YANG, these two strings
> are absolutely equivalent.

The consensus on the call would be to bump revision and YANG semver (if used) 
for all of these when republishing.  For 2 and your corner case, I would 
definitely see these as editorial.  For #3, that could be more of a MAJOR 
version bump (think changing a pattern).  For #1, we thought the explicitness 
of bumping the PATCH version when republishing made the most sense since the 
consumer clearly knows the module was intended to change, and the revision can 
document the reason for the change.

Joe

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

Re: [netmod] IETF 108: Summary of insignificant whitespace changes and versioning

[Joe Clarke (jclarke)]

> On Aug 11, 2020, at 10:45, Martin Björklund  wrote:
> 
> Hi,
> 
> "Joe Clarke \(jclarke\)"  wrote:
>> At the IETF 108 virtual meeting, Lada asked about what would happen if
>> he converted a YANG module to YIN syntax (or vice versa, or to some
>> other format).  This was during the discussion of the issue of what
>> should happen if a module changes and the only changes are
>> insignificant whitespaces (e.g., strip trailing spaces, change line
>> length of descriptions, etc.).
>> 
>> The authors/contributors discussed on this on our weekly calls, and we
>> propose:
>> 
>> If a module changes and those changes are only insignificant
>> whitespace changes and the syntax of the module remains the same
>> (i.e., YANG to YANG, YIN, YIN, etc.), a new revision of the module
>> MUST be created.  If you are using YANG semver as your revision
>> scheme, you MUST apply a PATCH version bump to that new module
>> revision to indicate an editorial change.
>> 
>> The reasoning behind this decision is that it makes it very clear and
>> unambiguous to consumers that this module has been consciously
>> changed, and those changes are only editorial.  This way one won’t be
>> concerned if they note that a module of a given syntax with the same
>> version but different checksums and diffs wasn’t otherwise
>> manipulated.
> 
> I think this is the wrong way to go.  I clean up formatting issues all
> the time, including IETF modules.  I am pretty sure that if you
> retrieve modules like "ietf-interfaces" or "ietf-yang-types" from
> different vendors' products, you will get modules with differences in
> whitespace - and this is not a problem AFAIK.
> 
> I think it is ok that a simple "diff" show whitespace changes in this
> case.  I don't think it leads to any real problems.

We discussed this on the call.  The thinking was that a long diff output would 
essentially be unwieldy for some modules and important changes might be lost.  
If the versions were the same, it would be ambiguous to the consume as to 
whether or not the module was only changed in trivial (i.e., 
less-than-editorial) or if more substantive changes happened.  If you trust the 
producer, maybe you assume they regenerated the module without trailing 
whitespace (or the like).  We felt there should be a more explicit signal.

> 
>> That said, if a module changes format from one syntax to another but
>> maintains semantic equivalency, then the revision and YANG semver MUST
>> be the same.  In that case, one will use the extension to realize that
>> this module file cannot be directly compared to one of another syntax
>> without looking at compiled or semantic representation.
> 
> This seems a bit inconsistent.  Suppose I round-trip from YANG to YIN
> to YANG, and the result is different whitespace in the two YANG
> modules.  The revision is the same, as explained above.  How is this
> different from changing the whitespace in YANG directly?

We didn’t discuss this directly, but we did discuss auto-generators that could 
do this type of round-tripping.  The general consensus was that you would use 
the same post-processing tool (e.g., pyang -f yang) on the result to ensure 
consistency.  And a consumer would look to a canonical source (like IANA, the 
IETF document, or the vendor) to ensure a consistent module.

In terms of alternate sources, I would think that if one wanted to trust an 
IETF module downloaded from some other site, they could.  If that site did some 
additional formatting, that would be up to the consumer to resolve compared to 
what might be required by a package.  But if the publisher (IETF in this case) 
were to republish a module with these stripped whitespace line endings, then 
that would be a different revision.

Joe

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

Re: [netmod] IETF 108: Summary of insignificant whitespace changes and versioning

[Juergen Schoenwaelder]

On Tue, Aug 11, 2020 at 05:06:13PM +0200, Martin Björklund wrote:
> 
> I think that any change in an argument string is an editorial change.
> 
> For example, compare these two changes:
> 
>A1.  description "a server.";
>A2.  description "A server.";
> 
>B1.  description "A  server.";
>B2.  description "A server.";
> 
> These are editorial changes, and thus the revision should be changed.
> 
> Note however that the following change might look like an editorial
> whitespace change in the argument, but in fact it is not:
> 
>   C1.
>   description
>   "A server and
>its data.";
> 
>   C2.
>   description
> "A server and
>  its data.";

+1

I agree since whitespace outside YANG strings is insignificant.

Lets raise this to the next level. What about the following?

   D1. description "A server.";
   D2. description "A server.";  // not very descriptive

   E1. description "A server.";  // not very descriptive
   E2. // not very descriptive
   description "A server.";

/js

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

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

Re: [netmod] [Technical Errata Reported] RFC8349 (6251)

[Acee Lindem (acee)]

Hi Tom, Draft Authors, 

The draft could easily be fixed. You just need to:

  1. Expand on the single sentence in section 2.1 on the need for non-IP MPLS 
routes. Given that the draft wasn't modeled correctly, this wasn't apparent to 
most of the reviewers. 
  2. Add an MPLS AF only augmentation (enforced via a when statement) to each 
route for the MPLS AF specific destination-prefix or destination-address. 
  3. Limit the current local-label augmentation to non-MPLS AFs. 
  4. Limit the active-route augmentation to AF MPLS and change the input to 
destination-address. 

Thanks,
Acee

On 8/11/20, 6:10 AM, "tom petch"  wrote:

From: Acee Lindem (acee) 
Sent: 11 August 2020 10:47

Hi Tom,
I fully understood your original comment. There are other problems with 
this model. See inline.

On 8/11/20, 4:59 AM, "tom petch"  wrote:

Tarek

Picking up on an earlier point,


From: Tarek Saad 
Sent: 10 August 2020 21:23

Hi Acee,

The existing RPC is used to query (defined AFIs=IPv4/IPv6) RIB to 
return the matching active route identified by a "destination address".
The MPLS module is trying to reuse this RPC so to query the MPLS RIB to 
return the matching active route identified by a "local label".
The RPC defined in RFC 8349 readily accepts MPLS AFI in it 
(/rt:routing/rt:ribs/rt:rib/rt:active-route) - unless we augment and suppress 
it with a "when check".
IMO, it is reusable as-is but the text below is limiting the leaf name 
that identifies an entry in RIB to "destination-address" only - in MPLS RIB the 
entry leaf name that identifies an entry is "local-label".

It is not reusable as is since the augmentation RPC augmentation must have 
a when statement restricting it to AF MPLS. Also, local-label is a leaf which 
is applicable to all address families. It cannot be the AF MPLS 
destination-prefix. This augmentation is missing.


I am probably getting out of my depth here,  On 1may20 I raised the issue 
of why the 'MUST' in the description in RFC8349 was not enforced in the YANG 
and 5may20 Martin explained that there is a rule in the YANG ABNF of input-stmt 
that makes the obvious impossible:-(  You are raising more profound issues 
about the RIB that I had not perceived when I reviewed mpls-base-yang for which 
I, and I hope everyone else, will be grateful.

If this mpls I-D is to proceed in the immediate future, it looks like the 
action may have to be deferred for future study.

More generally, I think that the interaction of forward by address and 
forward by label is challenging.  When first I looked at the MPLS I-D I was 
surprised at the way RFC8349 was augmented.  I had not seen MPLS as an 
alternative to IPv4 or IPv6 or ... in the way in which the RFC is used although 
the RFC does state that it can be; rather, to me, labels are a different 
animal, but I assumed that everyone knew what they were doing.

Tom Petch 


Thanks,
Acee



There should be a 'when' check to enforce the 'MUST' but the rules of 
YANG do not allow it in this structure.  I raised this on the NETMOD list at 
the time of WGLC and Martin pointed me to a rule in the ABNF which prohibits 
such a check.  He also said that the rule was not needed and would be a 
candidate to remove when YANG is revised.

Hence I have always thought of this MUST in the documentation as a 
constraint that must be enforced in the YANG

Tom Petch
>action active-route {
>  description
>"Return the active RIB route that is used for 
the
> destination address.
>
> Address-family-specific modules MUST augment 
input
> parameters with a leaf named 
'destination-address'.";

Regards,
Tarek

On 8/10/20, 3:27 PM, "Acee Lindem (acee)"  wrote:

[External Email. Be cautious of content]


All (Speaking as an author of RFC 8349),
I just looked at this in more detail and I don't think the 
ietf-mpls.yang model should be augmenting the 
/rt:routing/rt:ribs/rt:rib/rt:active-route RPC. The intent of the RPC is to 
return the address-family specific active-route corresponding to the 
destination-address. This model attempts to overload this RPC with a different 
action all together - returning a route that has the local-label as an optional 
attribute. I'd reject the Errata and believe the augmentation should be removed 
from ietf-mpl.yang. Whether it is replaced with a different one is up to the 
co-authors of ietf-mpls.yang.
Thanks,
Acee

On 8/10/20, 2:29 PM, "Rob Wilton (rwilton)"  
wrote:

[Resend to hopefully pass recipient limit filter]

Hi 

Re: [netmod] IETF 108: Summary of insignificant whitespace changes and versioning

[Martin Björklund]

Hi,


Ladislav Lhotka  wrote:
> 
> 
> On 11. 08. 20 15:41, Joe Clarke (jclarke) wrote:
> > At the IETF 108 virtual meeting, Lada asked about what would happen if he 
> > converted a YANG module to YIN syntax (or vice versa, or to some other 
> > format).  This was during the discussion of the issue of what should happen 
> > if a module changes and the only changes are insignificant whitespaces 
> > (e.g., strip trailing spaces, change line length of descriptions, etc.).
> > 
> > The authors/contributors discussed on this on our weekly calls, and we 
> > propose:
> > 
> > If a module changes and those changes are only insignificant whitespace 
> > changes and the syntax of the module remains the same (i.e., YANG to YANG, 
> > YIN, YIN, etc.), a new revision of the module MUST be created.  If you are 
> > using YANG semver as your revision scheme, you MUST apply a PATCH version 
> > bump to that new module revision to indicate an editorial change.
> > 
> > The reasoning behind this decision is that it makes it very clear and 
> > unambiguous to consumers that this module has been consciously changed, and 
> > those changes are only editorial.  This way one won’t be concerned if they 
> > note that a module of a given syntax with the same version but different 
> > checksums and diffs wasn’t otherwise manipulated.
> > 
> > That said, if a module changes format from one syntax to another but 
> > maintains semantic equivalency, then the revision and YANG semver MUST be 
> > the same.  In that case, one will use the extension to realize that this 
> > module file cannot be directly compared to one of another syntax without 
> > looking at compiled or semantic representation.
> 
> The last paragraph means that after a round trip YANG -> YIN -> YANG the
> initial and final YANG modules MUST have the same revision. However,
> depending on the conversion tools used, they may easily differ in
> whitespace, so their byte-oriented checksums won't be equal.
> 
> I think there are in fact three cases:
> 
> 1. Whitespace outside statement arguments - I believe this should never
> be significant.

Agreed.

> 2. Whitespace in the argument of "contact", "description",
> "error-message" and "organization" - this is tricky because tools may
> format such arguments differently. I am leaning towards making
> whitespace insignificant in this case as well.
> 
> 3. Whitespace in other arguments has to be significant and lead to a
> revision bump.

I think that any change in an argument string is an editorial change.

For example, compare these two changes:

   A1.  description "a server.";
   A2.  description "A server.";

   B1.  description "A  server.";
   B2.  description "A server.";

These are editorial changes, and thus the revision should be changed.

Note however that the following change might look like an editorial
whitespace change in the argument, but in fact it is not:

  C1.
  description
  "A server and
   its data.";

  C2.
  description
"A server and
 its data.";


/martin


> 
> And one more corner case for both 2 a 3: what if "\t" is replaced with
> the tab character in a double-quoted string? For YANG, these two strings
> are absolutely equivalent.
> 
> Lada
> 
> > 
> > Thoughts?
> > 
> > Joe
> > ___
> > 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] IETF 108: Summary of insignificant whitespace changes and versioning

[Ladislav Lhotka]

On 11. 08. 20 15:41, Joe Clarke (jclarke) wrote:
> At the IETF 108 virtual meeting, Lada asked about what would happen if he 
> converted a YANG module to YIN syntax (or vice versa, or to some other 
> format).  This was during the discussion of the issue of what should happen 
> if a module changes and the only changes are insignificant whitespaces (e.g., 
> strip trailing spaces, change line length of descriptions, etc.).
> 
> The authors/contributors discussed on this on our weekly calls, and we 
> propose:
> 
> If a module changes and those changes are only insignificant whitespace 
> changes and the syntax of the module remains the same (i.e., YANG to YANG, 
> YIN, YIN, etc.), a new revision of the module MUST be created.  If you are 
> using YANG semver as your revision scheme, you MUST apply a PATCH version 
> bump to that new module revision to indicate an editorial change.
> 
> The reasoning behind this decision is that it makes it very clear and 
> unambiguous to consumers that this module has been consciously changed, and 
> those changes are only editorial.  This way one won’t be concerned if they 
> note that a module of a given syntax with the same version but different 
> checksums and diffs wasn’t otherwise manipulated.
> 
> That said, if a module changes format from one syntax to another but 
> maintains semantic equivalency, then the revision and YANG semver MUST be the 
> same.  In that case, one will use the extension to realize that this module 
> file cannot be directly compared to one of another syntax without looking at 
> compiled or semantic representation.

The last paragraph means that after a round trip YANG -> YIN -> YANG the
initial and final YANG modules MUST have the same revision. However,
depending on the conversion tools used, they may easily differ in
whitespace, so their byte-oriented checksums won't be equal.

I think there are in fact three cases:

1. Whitespace outside statement arguments - I believe this should never
be significant.

2. Whitespace in the argument of "contact", "description",
"error-message" and "organization" - this is tricky because tools may
format such arguments differently. I am leaning towards making
whitespace insignificant in this case as well.

3. Whitespace in other arguments has to be significant and lead to a
revision bump.

And one more corner case for both 2 a 3: what if "\t" is replaced with
the tab character in a double-quoted string? For YANG, these two strings
are absolutely equivalent.

Lada

> 
> Thoughts?
> 
> Joe
> ___
> 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

Re: [netmod] IETF 108: Summary of insignificant whitespace changes and versioning

[Martin Björklund]

Hi,

"Joe Clarke \(jclarke\)"  wrote:
> At the IETF 108 virtual meeting, Lada asked about what would happen if
> he converted a YANG module to YIN syntax (or vice versa, or to some
> other format).  This was during the discussion of the issue of what
> should happen if a module changes and the only changes are
> insignificant whitespaces (e.g., strip trailing spaces, change line
> length of descriptions, etc.).
> 
> The authors/contributors discussed on this on our weekly calls, and we
> propose:
> 
> If a module changes and those changes are only insignificant
> whitespace changes and the syntax of the module remains the same
> (i.e., YANG to YANG, YIN, YIN, etc.), a new revision of the module
> MUST be created.  If you are using YANG semver as your revision
> scheme, you MUST apply a PATCH version bump to that new module
> revision to indicate an editorial change.
>
> The reasoning behind this decision is that it makes it very clear and
> unambiguous to consumers that this module has been consciously
> changed, and those changes are only editorial.  This way one won’t be
> concerned if they note that a module of a given syntax with the same
> version but different checksums and diffs wasn’t otherwise
> manipulated.

I think this is the wrong way to go.  I clean up formatting issues all
the time, including IETF modules.  I am pretty sure that if you
retrieve modules like "ietf-interfaces" or "ietf-yang-types" from
different vendors' products, you will get modules with differences in
whitespace - and this is not a problem AFAIK.

I think it is ok that a simple "diff" show whitespace changes in this
case.  I don't think it leads to any real problems.

> That said, if a module changes format from one syntax to another but
> maintains semantic equivalency, then the revision and YANG semver MUST
> be the same.  In that case, one will use the extension to realize that
> this module file cannot be directly compared to one of another syntax
> without looking at compiled or semantic representation.

This seems a bit inconsistent.  Suppose I round-trip from YANG to YIN
to YANG, and the result is different whitespace in the two YANG
modules.  The revision is the same, as explained above.  How is this
different from changing the whitespace in YANG directly?


/martin


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

[netmod] IETF 108: Summary of insignificant whitespace changes and versioning

[Joe Clarke (jclarke)]

At the IETF 108 virtual meeting, Lada asked about what would happen if he 
converted a YANG module to YIN syntax (or vice versa, or to some other format). 
 This was during the discussion of the issue of what should happen if a module 
changes and the only changes are insignificant whitespaces (e.g., strip 
trailing spaces, change line length of descriptions, etc.).

The authors/contributors discussed on this on our weekly calls, and we propose:

If a module changes and those changes are only insignificant whitespace changes 
and the syntax of the module remains the same (i.e., YANG to YANG, YIN, YIN, 
etc.), a new revision of the module MUST be created.  If you are using YANG 
semver as your revision scheme, you MUST apply a PATCH version bump to that new 
module revision to indicate an editorial change.

The reasoning behind this decision is that it makes it very clear and 
unambiguous to consumers that this module has been consciously changed, and 
those changes are only editorial.  This way one won’t be concerned if they note 
that a module of a given syntax with the same version but different checksums 
and diffs wasn’t otherwise manipulated.

That said, if a module changes format from one syntax to another but maintains 
semantic equivalency, then the revision and YANG semver MUST be the same.  In 
that case, one will use the extension to realize that this module file cannot 
be directly compared to one of another syntax without looking at compiled or 
semantic representation.

Thoughts?

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

Re: [netmod] New Version Notification for draft-tao-netmod-yang-node-tags-04.txt

[Qin Wu]

发件人: 刘 鹏 [mailto:liupeng...@outlook.com]
发送时间: 2020年8月11日 18:58
收件人: Qin Wu ; NETMOD Group 
主题: 回复: New Version Notification for draft-tao-netmod-yang-node-tags-04.txt

In addition，

3. You mentioned that “Split Metric group from opm tag and define it as context 
info tag”, but I didn’t see context info tag to be defined, are you saying opm 
tag is one example of context info tag or not?

[Qin]: No, Metric Group tag and service tag are two examples of context 
information tags, this has been briefly mentioned in section 1.1. OPM tag is 
not part of context information tag. OPM tag classify the O data into object 
type, property and metric, three category.

发件人: netmod mailto:netmod-boun...@ietf.org>> 代表 刘 鹏 
mailto:liupeng...@outlook.com>>
发送时间: 2020年8月11日 18:53
收件人: Qin Wu mailto:bill...@huawei.com>>; NETMOD Group 
mailto:netmod@ietf.org>>
主题: [netmod] 回复: New Version Notification for 
draft-tao-netmod-yang-node-tags-04.txt


Hi Qin,



I think it’s better and more mature than the last version. Here are some 
comments:

1. What is the difference between “data node” and “data object”? If they are 
the same, it is better to be consistent.

2. Whether the IANA should include all the functions before?



Regards,

Peng(CMCC)


发件人: netmod mailto:netmod-boun...@ietf.org>> 代表 Qin Wu 
mailto:bill...@huawei.com>>
发送时间: 2020年8月10日 21:04
收件人: NETMOD Group mailto:netmod@ietf.org>>
主题: Re: [netmod] New Version Notification for 
draft-tao-netmod-yang-node-tags-04.txt

Hi,
v-04 is posted, to address comments received from Jurgen and a few offline 
discussion.
https://datatracker.ietf.org/doc/html/draft-tao-netmod-yang-node-tags
The main changes include:
1. Add one NETCONF example in the appendix
2. Add Non-NMDA State Module in the appendix
3. Module structure alignment with module tag module.
4. Split Metric group from opm tag and define it as context info tag.
5. A few changes to Self Explanation Tags Use Cases.

-Qin
-邮件原件-
发件人: internet-dra...@ietf.org 
[mailto:internet-dra...@ietf.org]
发送时间: 2020年8月10日 20:56
收件人: Qin Wu mailto:bill...@huawei.com>>; Qin Wu 
mailto:bill...@huawei.com>>; Benoit Claise 
mailto:bcla...@cisco.com>>; Liang Geng 
mailto:gengli...@chinamobile.com>>; Zongpeng Du 
mailto:duzongp...@chinamobile.com>>
主题: New Version Notification for draft-tao-netmod-yang-node-tags-04.txt


A new version of I-D, draft-tao-netmod-yang-node-tags-04.txt
has been successfully submitted by Qin Wu and posted to the IETF repository..

Name:   draft-tao-netmod-yang-node-tags
Revision:   04
Title:  Self Explanation Data Object Tags
Document date:  2020-08-10
Group:  netmod
Pages:  40
URL:
https://www.ietf.org/internet-drafts/draft-tao-netmod-yang-node-tags-04.txt
Status: 
https://datatracker.ietf.org/doc/draft-tao-netmod-yang-node-tags/
Htmlized:   
https://tools.ietf.org/html/draft-tao-netmod-yang-node-tags-04
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-tao-netmod-yang-node-tags
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-tao-netmod-yang-node-tags-04

Abstract:
   This document defines a method to tag data objects associated with
   operation and management data in YANG Modules.  This YANG data object
   tagging method can be used to identify characteristics data and
   correlate data objects from different data sources and provide input,
   instruction, indication to selection filter and filter queries of
   operational state on a server during a "pub/sub" service for YANG
   datastore updates.  When the state of all subscriptions of a
   particular Subscriber to be fetched is huge, the amount of data to be
   streamed out to the destination can be greatly reduced and only
   targeted to the characteristics data.

   An extension statement to be used to indicate YANG data node self
   explanation tags that SHOULD be added by the module implementation
   automatically (i.e., outside of configuration).

   A YANG module [RFC7950] is defined, which augments Module tag model
   and provides a list of data node entries to allow for adding or
   removing of data node self explanation tags as well as viewing the
   set of self explanation tags associated with a YANG module.




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.

The IETF Secretariat


___
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-tao-netmod-yang-node-tags-04.txt

[Qin Wu]

Thanks Peng for a quick review on v-04.
There is no difference between data node and data object, two terms are 
interchangeable.
We could have another version to make the term consistent.
Regarding IANA section, yes, there are some inconsistency issue as well, e.g., 
the number of registries
are not consistent with the number of registries defined in the tables.
We will fix this in v-05. Thanks a lot.

-Qin
发件人: 刘 鹏 [mailto:liupeng...@outlook.com]
发送时间: 2020年8月11日 18:54
收件人: Qin Wu ; NETMOD Group 
主题: 回复: New Version Notification for draft-tao-netmod-yang-node-tags-04.txt


Hi Qin,



I think it’s better and more mature than the last version. Here are some 
comments:

1. What is the difference between “data node” and “data object”? If they are 
the same, it is better to be consistent.

2. Whether the IANA should include all the functions before?



Regards,

Peng(CMCC)


发件人: netmod mailto:netmod-boun...@ietf.org>> 代表 Qin Wu 
mailto:bill...@huawei.com>>
发送时间: 2020年8月10日 21:04
收件人: NETMOD Group mailto:netmod@ietf.org>>
主题: Re: [netmod] New Version Notification for 
draft-tao-netmod-yang-node-tags-04.txt

Hi,
v-04 is posted, to address comments received from Jurgen and a few offline 
discussion.
https://datatracker.ietf.org/doc/html/draft-tao-netmod-yang-node-tags
The main changes include:
1. Add one NETCONF example in the appendix
2. Add Non-NMDA State Module in the appendix
3. Module structure alignment with module tag module.
4. Split Metric group from opm tag and define it as context info tag.
5. A few changes to Self Explanation Tags Use Cases.

-Qin
-邮件原件-
发件人: internet-dra...@ietf.org 
[mailto:internet-dra...@ietf.org]
发送时间: 2020年8月10日 20:56
收件人: Qin Wu mailto:bill...@huawei.com>>; Qin Wu 
mailto:bill...@huawei.com>>; Benoit Claise 
mailto:bcla...@cisco.com>>; Liang Geng 
mailto:gengli...@chinamobile.com>>; Zongpeng Du 
mailto:duzongp...@chinamobile.com>>
主题: New Version Notification for draft-tao-netmod-yang-node-tags-04.txt


A new version of I-D, draft-tao-netmod-yang-node-tags-04.txt
has been successfully submitted by Qin Wu and posted to the IETF repository.

Name:   draft-tao-netmod-yang-node-tags
Revision:   04
Title:  Self Explanation Data Object Tags
Document date:  2020-08-10
Group:  netmod
Pages:  40
URL:
https://www.ietf.org/internet-drafts/draft-tao-netmod-yang-node-tags-04.txt
Status: 
https://datatracker.ietf.org/doc/draft-tao-netmod-yang-node-tags/
Htmlized:   https://tools.ietf.org/html/draft-tao-netmod-yang-node-tags-04
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-tao-netmod-yang-node-tags
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-tao-netmod-yang-node-tags-04

Abstract:
   This document defines a method to tag data objects associated with
   operation and management data in YANG Modules.  This YANG data object
   tagging method can be used to identify characteristics data and
   correlate data objects from different data sources and provide input,
   instruction, indication to selection filter and filter queries of
   operational state on a server during a "pub/sub" service for YANG
   datastore updates.  When the state of all subscriptions of a
   particular Subscriber to be fetched is huge, the amount of data to be
   streamed out to the destination can be greatly reduced and only
   targeted to the characteristics data.

   An extension statement to be used to indicate YANG data node self
   explanation tags that SHOULD be added by the module implementation
   automatically (i.e., outside of configuration).

   A YANG module [RFC7950] is defined, which augments Module tag model
   and provides a list of data node entries to allow for adding or
   removing of data node self explanation tags as well as viewing the
   set of self explanation tags associated with a YANG module.




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.

The IETF Secretariat


___
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] 回复: New Version Notification for draft-tao-netmod-yang-node-tags-04.txt

[刘 鹏]

In addition，

3. You mentioned that “Split Metric group from opm tag and define it as context 
info tag”, but I didn’t see context info tag to be defined, are you saying opm 
tag is one example of context info tag or not?

发件人: netmod  代表 刘 鹏 
发送时间: 2020年8月11日 18:53
收件人: Qin Wu ; NETMOD Group 
主题: [netmod] 回复: New Version Notification for 
draft-tao-netmod-yang-node-tags-04.txt


Hi Qin,



I think it’s better and more mature than the last version. Here are some 
comments:

1. What is the difference between “data node” and “data object”? If they are 
the same, it is better to be consistent.

2. Whether the IANA should include all the functions before?


Regards,

Peng(CMCC)


发件人: netmod  代表 Qin Wu 
发送时间: 2020年8月10日 21:04
收件人: NETMOD Group 
主题: Re: [netmod] New Version Notification for 
draft-tao-netmod-yang-node-tags-04.txt

Hi,
v-04 is posted, to address comments received from Jurgen and a few offline 
discussion.
https://datatracker.ietf.org/doc/html/draft-tao-netmod-yang-node-tags
The main changes include:
1. Add one NETCONF example in the appendix
2. Add Non-NMDA State Module in the appendix
3. Module structure alignment with module tag module.
4. Split Metric group from opm tag and define it as context info tag.
5. A few changes to Self Explanation Tags Use Cases.

-Qin
-邮件原件-
发件人: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
发送时间: 2020年8月10日 20:56
收件人: Qin Wu ; Qin Wu ; Benoit Claise 
; Liang Geng ; Zongpeng Du 

主题: New Version Notification for draft-tao-netmod-yang-node-tags-04.txt


A new version of I-D, draft-tao-netmod-yang-node-tags-04.txt
has been successfully submitted by Qin Wu and posted to the IETF repository..

Name:   draft-tao-netmod-yang-node-tags
Revision:   04
Title:  Self Explanation Data Object Tags
Document date:  2020-08-10
Group:  netmod
Pages:  40
URL:
https://www.ietf.org/internet-drafts/draft-tao-netmod-yang-node-tags-04.txt
Status: 
https://datatracker.ietf.org/doc/draft-tao-netmod-yang-node-tags/
Htmlized:   
https://tools.ietf.org/html/draft-tao-netmod-yang-node-tags-04
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-tao-netmod-yang-node-tags
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-tao-netmod-yang-node-tags-04

Abstract:
   This document defines a method to tag data objects associated with
   operation and management data in YANG Modules.  This YANG data object
   tagging method can be used to identify characteristics data and
   correlate data objects from different data sources and provide input,
   instruction, indication to selection filter and filter queries of
   operational state on a server during a "pub/sub" service for YANG
   datastore updates.  When the state of all subscriptions of a
   particular Subscriber to be fetched is huge, the amount of data to be
   streamed out to the destination can be greatly reduced and only
   targeted to the characteristics data.

   An extension statement to be used to indicate YANG data node self
   explanation tags that SHOULD be added by the module implementation
   automatically (i.e., outside of configuration).

   A YANG module [RFC7950] is defined, which augments Module tag model
   and provides a list of data node entries to allow for adding or
   removing of data node self explanation tags as well as viewing the
   set of self explanation tags associated with a YANG module.




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.

The IETF Secretariat


___
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] 回复: New Version Notification for draft-tao-netmod-yang-node-tags-04.txt

[刘 鹏]

Hi Qin,



I think it’s better and more mature than the last version. Here are some 
comments:

1. What is the difference between “data node” and “data object”? If they are 
the same, it is better to be consistent.

2. Whether the IANA should include all the functions before?


Regards,

Peng(CMCC)


发件人: netmod  代表 Qin Wu 
发送时间: 2020年8月10日 21:04
收件人: NETMOD Group 
主题: Re: [netmod] New Version Notification for 
draft-tao-netmod-yang-node-tags-04.txt

Hi,
v-04 is posted, to address comments received from Jurgen and a few offline 
discussion.
https://datatracker.ietf.org/doc/html/draft-tao-netmod-yang-node-tags
The main changes include:
1. Add one NETCONF example in the appendix
2. Add Non-NMDA State Module in the appendix
3. Module structure alignment with module tag module.
4. Split Metric group from opm tag and define it as context info tag.
5. A few changes to Self Explanation Tags Use Cases.

-Qin
-邮件原件-
发件人: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
发送时间: 2020年8月10日 20:56
收件人: Qin Wu ; Qin Wu ; Benoit Claise 
; Liang Geng ; Zongpeng Du 

主题: New Version Notification for draft-tao-netmod-yang-node-tags-04.txt


A new version of I-D, draft-tao-netmod-yang-node-tags-04.txt
has been successfully submitted by Qin Wu and posted to the IETF repository.

Name:   draft-tao-netmod-yang-node-tags
Revision:   04
Title:  Self Explanation Data Object Tags
Document date:  2020-08-10
Group:  netmod
Pages:  40
URL:
https://www.ietf.org/internet-drafts/draft-tao-netmod-yang-node-tags-04.txt
Status: 
https://datatracker.ietf.org/doc/draft-tao-netmod-yang-node-tags/
Htmlized:   https://tools.ietf.org/html/draft-tao-netmod-yang-node-tags-04
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-tao-netmod-yang-node-tags
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-tao-netmod-yang-node-tags-04

Abstract:
   This document defines a method to tag data objects associated with
   operation and management data in YANG Modules.  This YANG data object
   tagging method can be used to identify characteristics data and
   correlate data objects from different data sources and provide input,
   instruction, indication to selection filter and filter queries of
   operational state on a server during a "pub/sub" service for YANG
   datastore updates.  When the state of all subscriptions of a
   particular Subscriber to be fetched is huge, the amount of data to be
   streamed out to the destination can be greatly reduced and only
   targeted to the characteristics data.

   An extension statement to be used to indicate YANG data node self
   explanation tags that SHOULD be added by the module implementation
   automatically (i.e., outside of configuration).

   A YANG module [RFC7950] is defined, which augments Module tag model
   and provides a list of data node entries to allow for adding or
   removing of data node self explanation tags as well as viewing the
   set of self explanation tags associated with a YANG module.




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.

The IETF Secretariat


___
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] [Technical Errata Reported] RFC8349 (6251)

[tom petch]

From: Acee Lindem (acee) 
Sent: 11 August 2020 10:47

Hi Tom,
I fully understood your original comment. There are other problems with this 
model. See inline.

On 8/11/20, 4:59 AM, "tom petch"  wrote:

Tarek

Picking up on an earlier point,


From: Tarek Saad 
Sent: 10 August 2020 21:23

Hi Acee,

The existing RPC is used to query (defined AFIs=IPv4/IPv6) RIB to return 
the matching active route identified by a "destination address".
The MPLS module is trying to reuse this RPC so to query the MPLS RIB to 
return the matching active route identified by a "local label".
The RPC defined in RFC 8349 readily accepts MPLS AFI in it 
(/rt:routing/rt:ribs/rt:rib/rt:active-route) - unless we augment and suppress 
it with a "when check".
IMO, it is reusable as-is but the text below is limiting the leaf name that 
identifies an entry in RIB to "destination-address" only - in MPLS RIB the 
entry leaf name that identifies an entry is "local-label".

It is not reusable as is since the augmentation RPC augmentation must have a 
when statement restricting it to AF MPLS. Also, local-label is a leaf which is 
applicable to all address families. It cannot be the AF MPLS 
destination-prefix. This augmentation is missing.


I am probably getting out of my depth here,  On 1may20 I raised the issue of 
why the 'MUST' in the description in RFC8349 was not enforced in the YANG and 
5may20 Martin explained that there is a rule in the YANG ABNF of input-stmt 
that makes the obvious impossible:-(  You are raising more profound issues 
about the RIB that I had not perceived when I reviewed mpls-base-yang for which 
I, and I hope everyone else, will be grateful.

If this mpls I-D is to proceed in the immediate future, it looks like the 
action may have to be deferred for future study.

More generally, I think that the interaction of forward by address and forward 
by label is challenging.  When first I looked at the MPLS I-D I was surprised 
at the way RFC8349 was augmented.  I had not seen MPLS as an alternative to 
IPv4 or IPv6 or ... in the way in which the RFC is used although the RFC does 
state that it can be; rather, to me, labels are a different animal, but I 
assumed that everyone knew what they were doing.

Tom Petch 


Thanks,
Acee



There should be a 'when' check to enforce the 'MUST' but the rules of YANG 
do not allow it in this structure.  I raised this on the NETMOD list at the 
time of WGLC and Martin pointed me to a rule in the ABNF which prohibits such a 
check.  He also said that the rule was not needed and would be a candidate to 
remove when YANG is revised.

Hence I have always thought of this MUST in the documentation as a 
constraint that must be enforced in the YANG

Tom Petch
>action active-route {
>  description
>"Return the active RIB route that is used for the
> destination address.
>
> Address-family-specific modules MUST augment input
> parameters with a leaf named 
'destination-address'.";

Regards,
Tarek

On 8/10/20, 3:27 PM, "Acee Lindem (acee)"  wrote:

[External Email. Be cautious of content]


All (Speaking as an author of RFC 8349),
I just looked at this in more detail and I don't think the 
ietf-mpls.yang model should be augmenting the 
/rt:routing/rt:ribs/rt:rib/rt:active-route RPC. The intent of the RPC is to 
return the address-family specific active-route corresponding to the 
destination-address. This model attempts to overload this RPC with a different 
action all together - returning a route that has the local-label as an optional 
attribute. I'd reject the Errata and believe the augmentation should be removed 
from ietf-mpl.yang. Whether it is replaced with a different one is up to the 
co-authors of ietf-mpls.yang.
Thanks,
Acee

On 8/10/20, 2:29 PM, "Rob Wilton (rwilton)"  wrote:

[Resend to hopefully pass recipient limit filter]

Hi Tom,

I would be interested to hear from the original authors.

My impression is that this is a technically reasonable change, but 
I don't think that an erratum can create a new revision of a YANG module.

If this erratum was processed as "Hold for document update" then 
would that be sufficient to do the right thing in the MPLS YANG module?

Regards,
Rob


> -Original Message-
> From: tom petch 
> Sent: 10 August 2020 17:32
> To: RFC Errata System ; lho...@nic.cz; 
Acee
> Lindem (acee) ; yingzhen...@huawei.com; 
war...@kumari.net;
> Rob Wilton (rwilton) ; joe...@bogus.com;
> kent+i...@watsen.net; lber...@labn.net
> Cc: ts...@juniper.net; 

Re: [netmod] RFC 8349 action input augment

[Rob Wilton (rwilton)]

I've raised https://github.com/netmod-wg/yang-next/issues/106 to track this.

Regards,
Rob


> -Original Message-
> From: netmod  On Behalf Of tom petch
> Sent: 05 May 2020 16:44
> To: Martin Björklund 
> Cc: lho...@nic.cz; netmod@ietf.org
> Subject: Re: [netmod] RFC 8349 action input augment
> 
> From: Martin Björklund 
> Sent: 05 May 2020 12:39
> Cc: lho...@nic.cz; netmod@ietf.org
> 
> tom petch  wrote:
> > RFC8349 specifies an action with no input and says that modules that
> > use this MUST augment the input with a leaf and that the leaf must
> > be named destination-address.
> >
> > Is there any way that YANG can enforce either constraint?
> 
> This may look correct:
> 
>   action activate-route {
> input {
>   must '*[local-name(.) = "destination-address"]';
> }
> ...
>   }
> 
> 
>  but unfortunatly we have a CLR in the definition of "input":
> 
>input-stmt  = input-keyword optsep
>  "{" stmtsep
>  ;; these stmts can appear in any order
>  *must-stmt
>  *(typedef-stmt / grouping-stmt)
>  HERE--->1*data-def-stmt
>  "}" stmtsep
> 
> 
> We require "input" to have at least one data-def-stmt, which doens't
> make any sense, since we allow an action/rpc to not define "input" at
> all.
> 
> 
> Thanks for that.  I thought there was a reason but did not think to look
> there.
> 
> As you may have guessed, I just looked at a YANG module which broke the
> rules, added  a leaf but of the wrong name.
> 
> Tom Petch
> 
> 
> 
> /martin
> 
> 
> >
> > 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

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

Re: [netmod] [Technical Errata Reported] RFC8349 (6251)

[Acee Lindem (acee)]

Hi Tom, 
I fully understood your original comment. There are other problems with this 
model. See inline.

On 8/11/20, 4:59 AM, "tom petch"  wrote:

Tarek

Picking up on an earlier point,


From: Tarek Saad 
Sent: 10 August 2020 21:23

Hi Acee,

The existing RPC is used to query (defined AFIs=IPv4/IPv6) RIB to return 
the matching active route identified by a "destination address".
The MPLS module is trying to reuse this RPC so to query the MPLS RIB to 
return the matching active route identified by a "local label".
The RPC defined in RFC 8349 readily accepts MPLS AFI in it 
(/rt:routing/rt:ribs/rt:rib/rt:active-route) - unless we augment and suppress 
it with a "when check".
IMO, it is reusable as-is but the text below is limiting the leaf name that 
identifies an entry in RIB to "destination-address" only - in MPLS RIB the 
entry leaf name that identifies an entry is "local-label".

It is not reusable as is since the augmentation RPC augmentation must have a 
when statement restricting it to AF MPLS. Also, local-label is a leaf which is 
applicable to all address families. It cannot be the AF MPLS 
destination-prefix. This augmentation is missing. 

Thanks,
Acee



There should be a 'when' check to enforce the 'MUST' but the rules of YANG 
do not allow it in this structure.  I raised this on the NETMOD list at the 
time of WGLC and Martin pointed me to a rule in the ABNF which prohibits such a 
check.  He also said that the rule was not needed and would be a candidate to 
remove when YANG is revised.

Hence I have always thought of this MUST in the documentation as a 
constraint that must be enforced in the YANG

Tom Petch
>action active-route {
>  description
>"Return the active RIB route that is used for the
> destination address.
>
> Address-family-specific modules MUST augment input
> parameters with a leaf named 
'destination-address'.";

Regards,
Tarek

On 8/10/20, 3:27 PM, "Acee Lindem (acee)"  wrote:

[External Email. Be cautious of content]


All (Speaking as an author of RFC 8349),
I just looked at this in more detail and I don't think the 
ietf-mpls.yang model should be augmenting the 
/rt:routing/rt:ribs/rt:rib/rt:active-route RPC. The intent of the RPC is to 
return the address-family specific active-route corresponding to the 
destination-address. This model attempts to overload this RPC with a different 
action all together - returning a route that has the local-label as an optional 
attribute. I'd reject the Errata and believe the augmentation should be removed 
from ietf-mpl.yang. Whether it is replaced with a different one is up to the 
co-authors of ietf-mpls.yang.
Thanks,
Acee

On 8/10/20, 2:29 PM, "Rob Wilton (rwilton)"  wrote:

[Resend to hopefully pass recipient limit filter]

Hi Tom,

I would be interested to hear from the original authors.

My impression is that this is a technically reasonable change, but 
I don't think that an erratum can create a new revision of a YANG module.

If this erratum was processed as "Hold for document update" then 
would that be sufficient to do the right thing in the MPLS YANG module?

Regards,
Rob


> -Original Message-
> From: tom petch 
> Sent: 10 August 2020 17:32
> To: RFC Errata System ; lho...@nic.cz; 
Acee
> Lindem (acee) ; yingzhen...@huawei.com; 
war...@kumari.net;
> Rob Wilton (rwilton) ; joe...@bogus.com;
> kent+i...@watsen.net; lber...@labn.net
> Cc: ts...@juniper.net; netmod@ietf.org
> Subject: Re: [netmod] [Technical Errata Reported] RFC8349 (6251)
>
> From: netmod  on behalf of RFC Errata 
System
> 
> Sent: 07 August 2020 16:45
>
> 
> This is the erratum of whose arrival I speculated on this list on 
June
> 16th.
>
> There is a degree of urgency about it.  The I-D in question is 
mpls-base-
> yang, currently in IETF Last Call, which is a Normative 
dependency of bfd-
> yang which is a Normative dependency for a small mountain of I-D 
which
> have been waiting a year or so (e.g.  ospf-yang).
>
> I suspect that the technically perfect solution would involve a 
YANG
> union, choice or some such structure but as I said in my Last 
Call comment
> I can live with a label that contains such as 'address' 
encompassing such
> as 'label' in the context of forwarding.  I take labels to mean 
what
> 

Re: [netmod] [Technical Errata Reported] RFC8349 (6251)

[tom petch]

Tarek

Picking up on an earlier point,


From: Tarek Saad 
Sent: 10 August 2020 21:23

Hi Acee,

The existing RPC is used to query (defined AFIs=IPv4/IPv6) RIB to return the 
matching active route identified by a "destination address".
The MPLS module is trying to reuse this RPC so to query the MPLS RIB to return 
the matching active route identified by a "local label".
The RPC defined in RFC 8349 readily accepts MPLS AFI in it 
(/rt:routing/rt:ribs/rt:rib/rt:active-route) - unless we augment and suppress 
it with a "when check".
IMO, it is reusable as-is but the text below is limiting the leaf name that 
identifies an entry in RIB to "destination-address" only - in MPLS RIB the 
entry leaf name that identifies an entry is "local-label".


There should be a 'when' check to enforce the 'MUST' but the rules of YANG do 
not allow it in this structure.  I raised this on the NETMOD list at the time 
of WGLC and Martin pointed me to a rule in the ABNF which prohibits such a 
check.  He also said that the rule was not needed and would be a candidate to 
remove when YANG is revised.

Hence I have always thought of this MUST in the documentation as a constraint 
that must be enforced in the YANG

Tom Petch
>action active-route {
>  description
>"Return the active RIB route that is used for the
> destination address.
>
> Address-family-specific modules MUST augment input
> parameters with a leaf named 'destination-address'.";

Regards,
Tarek

On 8/10/20, 3:27 PM, "Acee Lindem (acee)"  wrote:

[External Email. Be cautious of content]


All (Speaking as an author of RFC 8349),
I just looked at this in more detail and I don't think the ietf-mpls.yang 
model should be augmenting the /rt:routing/rt:ribs/rt:rib/rt:active-route RPC. 
The intent of the RPC is to return the address-family specific active-route 
corresponding to the destination-address. This model attempts to overload this 
RPC with a different action all together - returning a route that has the 
local-label as an optional attribute. I'd reject the Errata and believe the 
augmentation should be removed from ietf-mpl.yang. Whether it is replaced with 
a different one is up to the co-authors of ietf-mpls.yang.
Thanks,
Acee

On 8/10/20, 2:29 PM, "Rob Wilton (rwilton)"  wrote:

[Resend to hopefully pass recipient limit filter]

Hi Tom,

I would be interested to hear from the original authors.

My impression is that this is a technically reasonable change, but I 
don't think that an erratum can create a new revision of a YANG module.

If this erratum was processed as "Hold for document update" then would 
that be sufficient to do the right thing in the MPLS YANG module?

Regards,
Rob


> -Original Message-
> From: tom petch 
> Sent: 10 August 2020 17:32
> To: RFC Errata System ; lho...@nic.cz; Acee
> Lindem (acee) ; yingzhen...@huawei.com; 
war...@kumari.net;
> Rob Wilton (rwilton) ; joe...@bogus.com;
> kent+i...@watsen.net; lber...@labn.net
> Cc: ts...@juniper.net; netmod@ietf.org
> Subject: Re: [netmod] [Technical Errata Reported] RFC8349 (6251)
>
> From: netmod  on behalf of RFC Errata System
> 
> Sent: 07 August 2020 16:45
>
> 
> This is the erratum of whose arrival I speculated on this list on June
> 16th.
>
> There is a degree of urgency about it.  The I-D in question is 
mpls-base-
> yang, currently in IETF Last Call, which is a Normative dependency of 
bfd-
> yang which is a Normative dependency for a small mountain of I-D which
> have been waiting a year or so (e.g.  ospf-yang).
>
> I suspect that the technically perfect solution would involve a YANG
> union, choice or some such structure but as I said in my Last Call 
comment
> I can live with a label that contains such as 'address' encompassing 
such
> as 'label' in the context of forwarding.  I take labels to mean what
> labels mean rather than what I might find in a work of reference.
>
> Tom Petch
>
> The following errata report has been submitted for RFC8349,
> "A YANG Data Model for Routing Management (NMDA Version)".
>
> --
> You may review the report below and at:
> 
https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid6251__;!!NEt6yMaO-gk!URK5WVsqD5g7WpzCU1VuzKJA0AUiawXBFLB_gENlsYMrpiMqDtyFoxw8DnSr2A$
>
> --
> Type: Technical
> Reported by: Tarek Saad 
>
> Section: 7
>
> Original Text