date:20200812

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

2020-08-12 Thread Tarek Saad

Hi Acee and Tom,

Thanks for your feedback and suggestions. Please see further response inline..

On 8/11/20, 9:08 AM, "Acee Lindem (acee)"  wrote:

[External Email. Be cautious of content]


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.
[TS]: sure, we can add more text to this section. However,
  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.
[TS]: you are asking to overload "destination-prefix" to carry the MPLS label 
for the MPLS RIB only -  and to continue to use local-label to carry the label 
for IP RIBs - this is a bit awkward. To illustrate:

Currently, ID:draft-ietf-mpls-base-yang models as:
=
IP RIB route:
Route {
   Destination-prefix = 192.168.0.0/24
   Next-hop-address = 10.0.0.2
   Local-label = 16000 (draft-ietf-mpls-base-yang adds this as augmentation)
}
MPLS RIB route:
Route {
   Local-label = 18000
   Next-hop-address = 10.0.0.2
}

Acee is suggesting:
===
IP RIB route (same as in ID:draft-ietf-mpls-base-yang)
Route {
   Destination-prefix = 192.168.0.0/24
   Next-hop-address = 10.0.0.2
   Local-label = 16000
}
MPLS RIB route:
Route {
   Destination-prefix = 18000
   Next-hop-address = 10.0.0.2
}
IMO, it is awkward that MPLS label is carried in local-label for IP RIBs 
routes, while it is carried in destination-prefix for MPLS AF routes.

  4. Limit the active-route augmentation to AF MPLS and change the input to 
destination-address.
[TS]: I'm summarizing intention of ID:draft-ietf-mpls-base-yang in the example 
below to illustrate:
1) RFC 8349 defines RPC (equivalent to "show route 192.168.0.1":
Input:
  destination-address (IP=192.168.0.1, RIB AF=IPv4)
Output:
  Active-route

2) ID:draft-ietf-mpls-base-yang wants to reuse this RPC (equivalent to "show 
route mpls-label 16000")
Input:
   Local-label (label=18000, RIB AF=MPLS)
Output:
  Active-route

Regards,
Tarek

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

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

2020-08-12 Thread Acee Lindem (acee)

Hi Tarek,

On 8/11/20, 1:36 PM, "Tarek Saad"  wrote:

Hi Acee and Tom,

Thanks for your feedback and suggestions. Please see further response 
inline..

On 8/11/20, 9:08 AM, "Acee Lindem (acee)"  wrote:

[External Email. Be cautious of content]


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.
[TS]: sure, we can add more text to this section. However,
  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.
[TS]: you are asking to overload "destination-prefix" to carry the MPLS 
label for the MPLS RIB only 

The AF specific type for the destination-prefix would be rt-types:mpls-label. 
RFC 8349 was designed to support AF agnostic RIBs and if you are going to 
augment it, you have to fix into the framework. If you don't, you don't, you 
should add a separate table for MPLS. It seems a bit strange to consider raw 
MPLS its own AF when it isn't considered an AF in other IETF documents.  

Thanks,
Acee




-  and to continue to use local-label to carry the label for IP RIBs - this is 
a bit awkward. To illustrate:

Currently, ID:draft-ietf-mpls-base-yang models as:
=
IP RIB route:
Route {
   Destination-prefix = 192.168.0.0/24
   Next-hop-address = 10.0.0.2
   Local-label = 16000 (draft-ietf-mpls-base-yang adds this as augmentation)
}
MPLS RIB route:
Route {
   Local-label = 18000
   Next-hop-address = 10.0.0.2
}

Acee is suggesting:
===
IP RIB route (same as in ID:draft-ietf-mpls-base-yang)
Route {
   Destination-prefix = 192.168.0.0/24
   Next-hop-address = 10.0.0.2
   Local-label = 16000
}
MPLS RIB route:
Route {
   Destination-prefix = 18000
   Next-hop-address = 10.0.0.2
}
IMO, it is awkward that MPLS label is carried in local-label for IP RIBs 
routes, while it is carried in destination-prefix for MPLS AF routes.

  4. Limit the active-route augmentation to AF MPLS and change the 
input to destination-address.
[TS]: I'm summarizing intention of ID:draft-ietf-mpls-base-yang in the 
example below to illustrate:
1) RFC 8349 defines RPC (equivalent to "show route 192.168.0.1":
Input:
  destination-address (IP=192.168.0.1, RIB AF=IPv4)
Output:
  Active-route

2) ID:draft-ietf-mpls-base-yang wants to reuse this RPC (equivalent to 
"show route mpls-label 16000")
Input:
   Local-label (label=18000, RIB AF=MPLS)
Output:
  Active-route

Regards,
Tarek

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

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

2020-08-12 Thread Randy Presuhn


Hi -

On 8/12/2020 1:34 AM, Martin Björklund wrote:
...

I think that comments should be treated as insignificant whitespace.

Comments in YANG are not tied to a specific statement, so it is
difficult to e.g. translate them to YIN properly.  For example to
which statement does the comment below belong?

   container foo {
  container bar; /* beware */ container baz;
   }


For some reason this whole discussion of errorless round-trip conversions
generated by flawless tools and inconsequential editorial changes made
by infallible editors reminds me of an episode at a company long ago
in which a programmer received a "commendation" for "most bugs
introduced by fixing a comment."  (I won't name names.)   From a
configuration management perspective, what's the point of introducing
a revision identification scheme if it is not used?

Randy

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

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

2020-08-12 Thread Ladislav Lhotka



On 12. 08. 20 11:02, Martin Björklund wrote:
> "Rob Wilton (rwilton)"  wrote:
>>
>>
>>> -Original Message-
>>> From: netmod  On Behalf Of Ladislav Lhotka
>>> Sent: 12 August 2020 08:43
>>> To: Martin Björklund 
>>> Cc: jclarke=40cisco@dmarc.ietf.org; netmod@ietf.org
>>> Subject: Re: [netmod] IETF 108: Summary of insignificant whitespace
>>> changes and versioning
>>>
>>> Martin Björklund  writes:
>>>
 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.
>>>
>>> But consider
>>>
>>>description
>>>"A server and
>>> its data.";
>>>
>>> versus
>>>
>>>description
>>>"A server and
>>>its data.";
>>>
>>> Here the difference is only in presentation - a YANG parser gives the
>>> same
>>> string in both cases. Another awkward case is whitespace before a line
>>> break.
>> [RW] 
>>
>> [As an individual contributor]
>>
>> What about:
>>
>> description
>> "A server and
>>  its data.";
>>  
>> versus
>>  
>> description
>> "A server and its data.";
> 
> I wrote:
> 
 I think that any change in an argument string is an editorial change.
> 
> Your example changes the argument string; hence this is a significant
> (editorial) change, and requires a new revision.

Perhaps formally, but given the role that the description statement
plays reflowing really means no change.

Lada

> 
>> Or any cases where description statements might be reflowed by tooling
>> to fit different line width limits?
> 
> See above.
> 
> 
> 
> /martin
> 
> 
>>
>> Regards,
>> Rob
>>
>>
>>>
>>> Lada
>>>

 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

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

2020-08-12 Thread Qin Wu

Hi, Wei Wang:
发件人: 王 巍 [mailto:w13070197...@outlook.com]
发送时间: 2020年8月12日 10:33
收件人: netmod@ietf.org; Qin Wu 
主题: 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.
[Qin]: Thanks, appreciated.

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.
[Qin]:Good point, I have separated the metric group from opm tags in v-04. In 
addition,  I update the use case in section 1.1.1 to
Describe metric group usage as context information.

2. Can you provide a NETCONF example on data object tag management?
[Qin]:Good suggestion, I have added NETCONF example in the appendix.

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.
[Qin]: I got the similar comments from Peng, I will fix this terminology 
inconsistency issue in v-05.

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.
 [Qin]: Agree,  I have introduced another registry for metric group tag and 
define initial values for it. Thanks for your good suggestion.
Best Regards,
Wei Wang
China Telecom


-邮件原件-
发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Qin Wu
发送时间: 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

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

2020-08-12 Thread Martin Björklund

"Rob Wilton (rwilton)"  wrote:
> 
> 
> > -Original Message-
> > From: netmod  On Behalf Of Ladislav Lhotka
> > Sent: 12 August 2020 08:43
> > To: Martin Björklund 
> > Cc: jclarke=40cisco@dmarc.ietf.org; netmod@ietf.org
> > Subject: Re: [netmod] IETF 108: Summary of insignificant whitespace
> > changes and versioning
> > 
> > Martin Björklund  writes:
> > 
> > > 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.
> > 
> > But consider
> > 
> >description
> >"A server and
> > its data.";
> > 
> > versus
> > 
> >description
> >"A server and
> >its data.";
> > 
> > Here the difference is only in presentation - a YANG parser gives the
> > same
> > string in both cases. Another awkward case is whitespace before a line
> > break.
> [RW] 
> 
> [As an individual contributor]
> 
> What about:
> 
> description
> "A server and
>  its data.";
>  
> versus
>  
> description
> "A server and its data.";

I wrote:

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

Your example changes the argument string; hence this is a significant
(editorial) change, and requires a new revision.

> Or any cases where description statements might be reflowed by tooling
> to fit different line width limits?

See above.



/martin


> 
> Regards,
> Rob
> 
> 
> > 
> > Lada
> > 
> > >
> > > 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
> > >>
> > >> >
> >

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

2020-08-12 Thread Rob Wilton (rwilton)



> -Original Message-
> From: netmod  On Behalf Of Ladislav Lhotka
> Sent: 12 August 2020 08:43
> To: Martin Björklund 
> Cc: jclarke=40cisco@dmarc.ietf.org; netmod@ietf.org
> Subject: Re: [netmod] IETF 108: Summary of insignificant whitespace
> changes and versioning
> 
> Martin Björklund  writes:
> 
> > 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.
> 
> But consider
> 
>description
>"A server and
> its data.";
> 
> versus
> 
>description
>"A server and
>its data.";
> 
> Here the difference is only in presentation - a YANG parser gives the same
> string in both cases. Another awkward case is whitespace before a line
> break.
[RW] 

[As an individual contributor]

What about:

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

Or any cases where description statements might be reflowed by tooling to fit 
different line width limits?

Regards,
Rob


> 
> Lada
> 
> >
> > 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
> 
> --
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
> 
> ___
> netmod mailing list
>

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

2020-08-12 Thread Martin Björklund

Juergen Schoenwaelder  wrote:
> 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.";

I think that comments should be treated as insignificant whitespace.

Comments in YANG are not tied to a specific statement, so it is
difficult to e.g. translate them to YIN properly.  For example to
which statement does the comment below belong?

  container foo {
 container bar; /* beware */ container baz;
  }


/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

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

2020-08-12 Thread Ladislav Lhotka

"Joe Clarke \(jclarke\)"  writes:

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

I think it would be better to define "canonical YANG". One relatively 
straightforward way might be to convert to YIN first and then apply XML 
canonicalization:

https://www.w3.org/TR/2001/REC-xml-c14n-20010315

As an additional benefit, this would also enable digital signatures of YANG 
modules.

Lada

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

2020-08-12 Thread Ladislav Lhotka

Martin Björklund  writes:

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

But consider

   description
   "A server and
its data.";

versus

   description
   "A server and
   its data.";

Here the difference is only in presentation - a YANG parser gives the same 
string in both cases. Another awkward case is whitespace before a line break.

Lada

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

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

2020-08-12 Thread Martin Björklund

Hi,

"Joe Clarke (jclarke)"  wrote:
> 
> 
> > 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.

But if you don't trust the producer, perhaps they didn't update the
revision according to the rules anyway?  I think we should have sound
rules and if people don't follow the rules then it's up to them.

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

I don't think we can or should have a solution that works only if
people are using a (specific version of a) specific tool.

> And a consumer would look to a
> canonical source (like IANA, the IETF document, or the vendor) to
> ensure a consistent module.

It is quite common that clients download the modules from the servers,
rather than from a "canonical source".

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

I think they (IETF/IANA) should be able to change insignificant
whitespace w/o changing the revision.


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

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

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

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

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

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

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

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

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

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

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

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

11 matches

Site Navigation

Mail list logo

Footer information