Subject: Re: [Detnet] Comments on detnet-yang-15 Re: [Last-Call] Yangdoctors last call review of draft-ietf-detnet-yang-14

From: tom petch <[email-masked]>
Date: Wed, 16 Feb 2022 13:07:15 +0000

On 12/01/2022 14:07, Don Fedyk wrote:

Don

I am not sure where this is in processing terms - I see no Telechat date 
yet.

I have (finally) looked at the examples having been put off by the size 
previously.

I see that they reference iana-if-type but
- there is no I-D reference for this IANA-maintained YANG module and I 
think that there should be
- the wrong prefix is used - the module declares a prefix of ianaft so 
that is what an IETF document should use.

I am still looking at the examples.

Tom Petch

> FYI
>
> After Tom pointed this out, I did find the new site under author tools that generates all formats correctly including SVG from the latest version 3 xml.
> https://author-tools.ietf.org/
>
>
> Cheers
> Don
>
> -----Original Message-----
> From: Don Fedyk <[email-masked]>
> Sent: Thursday, January 6, 2022 2:01 PM
> To: tom petch <[email-masked]>
> Cc: [email-masked]; [email-masked]
> Subject: RE: Comments on detnet-yang-15 Re: [Last-Call] Yangdoctors last call review of draft-ietf-detnet-yang-14
>
> Hi Tom
>
> Ok got it, I needed to update pyang to version 2.5.2 - pyang --ietf checks the copyright boiler plate and substituting Revised for Simplified created an error in version 2.5.0. Now it is correctly processed.
>
> Interesting the Trust and legal Provisions (TLP) comes from an XML tag ipr="trust200902" for the document which locally for me uses the older boiler plate text with Simplified, etc., in the draft copywrite (the YANG copywrite is pure text so I corrected that). My tools for xml2rfc v3 are ~8 month old which is the environment for processing SVG.
> However, the same tag on IETF submission substitutes the newly revised text so version 15 txt and html is corrected. But, the PDF version gets the older text since I submit my rendered PDF along with the xml because the IETF does not process XML to pdf quite the same way and the only way to get the SVG diagrams in PDF was for me to submit it.
>
> Thanks
> Don
>
>
> -----Original Message-----
> From: tom petch <[email-masked]>
> Sent: Thursday, January 6, 2022 11:38 AM
> To: Don Fedyk <[email-masked]>
> Cc: [email-masked]; [email-masked]
> Subject: Re: Comments on detnet-yang-15 Re: [Last-Call] Yangdoctors last call review of draft-ietf-detnet-yang-14
>
> On 05/01/2022 20:04, Don Fedyk wrote:
>> Hi Tom
>>
>> Comments Inline [Don]
>> Also incorporated, https://github.com/detnet-wg/draft-ietf-detnet-yang
>
> One follow-up in line
>
> Tom Petch
>
>> Thanks
>> Don
>>
>> -----Original Message-----
>> From: tom petch <[email-masked]>
>> Sent: Thursday, December 23, 2021 6:40 AM
>>
>> Borrowing a useful cc: with a related topic
>>
>> two documents in the YANG module need adding to the I-D References
>> RFC8938
>> [Don] OK on this one
>> IEEE 802.1Qcx-2020
>> [Don] I see. Yes
>>
>> contact URL
>> insecure, obsolete - https://datatracker ...
>> [Don] Fixed
>>
>> Editor: Mach Chen
>> not in the authors of the I-D
>> [Don] Fixed
>>
>> TLP out of date
>> [Don] TLP?  I changed the date reference in the XML header.  It should line up with the module date.
>
> Look in the YANG module and the TLP refer to Simplified BSD License [sic].
>
> This changed in 2020 - I cannot recall an announcement thereof - and the new one is Revised BSD License as in
> draft-ietf-lsr-isis-yang-augmentation-v1
>
> Tom Petch
>
>
>> Reference: this ID when published
>> Reference: "RFC XXXX: Deterministic Networking (DetNet) YANG Model
>> [Don] I think the RFC editor correct this on publication.
>>
>>
>> Tom Petch
>>
>>
>> On 09/11/2021 20:06, Xufeng Liu via Datatracker wrote:
>>> Reviewer: Xufeng Liu
>>> Review result: Ready with Nits
>>>
>>> Thanks to authors for addressing the previous review comments.
>>>
>>> The updates look good. The followings are a few additional nits:
>>>
>>> 1) In the model, “container flow-spec” has been changed to “container
>>> traffic-spec”, but the description has not been updated, shown as below:
>>>
>>>             container traffic-spec {
>>>               description
>>>                 "Flow-specification specifies how the Source transmits
>>>                  packets for the flow.  This is the promise/request of the
>>>                  Source to the network.  The network uses this flow
>>>                  specification to allocate resources and adjust queue
>>>                  parameters in network nodes.";
>>>
>>> 2) Most names of list and leaf-list have been fixes. The following
>>> three were
>>> missed: “leaf-list member-apps” should be “leaf-list member-app”
>>> “leaf-list member-services” should be “leaf-list member-service”
>>> “leaf-list member-fwd-sublayers” should be “leaf-list member-fwd-sublayer”
>>>
>>> 3) Section 10.  Security Considerations would need to include a list
>>> of “sensitive or vulnerable” nodes.  RFC 8349 shows an example.
>>>
>>> Thanks,
>>> - Xufeng

---

From: tom petch <[email-masked]>
Date: Thu, 17 Feb 2022 12:24:29 +0000

Don

I have finished looking at the example albeit not in much detail and 
nothing else caught my eye,

Tom Petch

> Tom Petch
>
>> FYI
>>
>> After Tom pointed this out, I did find the new site under author tools
>> that generates all formats correctly including SVG from the latest
>> version 3 xml.
>> Subject: RE: Comments on detnet-yang-15 Re: [Last-Call] Yangdoctors
>> last call review of draft-ietf-detnet-yang-14
>>
>> Hi Tom
>>
>> Ok got it, I needed to update pyang to version 2.5.2 - pyang --ietf
>> checks the copyright boiler plate and substituting Revised for
>> Simplified created an error in version 2.5.0. Now it is correctly
>> processed.
>>
>> Interesting the Trust and legal Provisions (TLP) comes from an XML tag
>> ipr="trust200902" for the document which locally for me uses the older
>> boiler plate text with Simplified, etc., in the draft copywrite (the
>> YANG copywrite is pure text so I corrected that). My tools for xml2rfc
>> v3 are ~8 month old which is the environment for processing SVG.
>> However, the same tag on IETF submission substitutes the newly revised
>> text so version 15 txt and html is corrected. But, the PDF version
>> gets the older text since I submit my rendered PDF along with the xml
>> because the IETF does not process XML to pdf quite the same way and
>> the only way to get the SVG diagrams in PDF was for me to submit it.
>>
>> Thanks
>> Don
>>
>>
>> Subject: Re: Comments on detnet-yang-15 Re: [Last-Call] Yangdoctors
>> last call review of draft-ietf-detnet-yang-14
>>

---

From: Don Fedyk <[email-masked]>
Date: Fri, 18 Feb 2022 15:57:31 +0000

Hi Tom

Looked into this and found RFC 7224 iana-if-type.yang uses this: 

module iana-if-type {
  namespace "urn:ietf:params:xml:ns:yang:iana-if-type";
  prefix ianaift;

In the examples the string "iana-if-type" comes from the XML namespace not the prefix declared. Detnet YANG does not import iana-if-type.yang but it imports ietf-interface.yang module that imports iana-if-type.yang. When validating with Yanglint I have no control of the display "iana-if-yang" in examples - I use short form prefixes for those on input that do not show up in the Yanglint output. Yanglint expands the prefix used in the XML test files to the namespace. 
While we can add a reference RFC 7224, it is a namespace not a prefix that shows up in the output. Every object in the examples has its specified namespace. You pointed to a part of an example using ietf-interfaces namespace which prepends the iana-if-type namespace just for the typedef object. 

Cheers,

Don   

-----Original Message-----
From: tom petch <[email-masked]> 
Sent: Wednesday, February 16, 2022 8:07 AM
To: Don Fedyk <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: Comments on detnet-yang-15 Re: [Last-Call] Yangdoctors last call review of draft-ietf-detnet-yang-14

Don

I am not sure where this is in processing terms - I see no Telechat date yet.

I have (finally) looked at the examples having been put off by the size previously.

I see that they reference iana-if-type but
- there is no I-D reference for this IANA-maintained YANG module and I think that there should be
- the wrong prefix is used - the module declares a prefix of ianaft so that is what an IETF document should use.

Tom Petch

>> Also incorporated, 
>> https://github.com/detnet-wg/draft-ietf-detnet-yang
>
> One follow-up in line
>
> Tom Petch
>
>> Thanks
>> Don
>>
>>> 1) In the model, “container flow-spec” has been changed to 
>>> “container traffic-spec”, but the description has not been updated, shown as below:
>>>
>>>             container traffic-spec {
>>>               description

---

From: tom petch <[email-masked]>
Date: Sat, 19 Feb 2022 12:23:29 +0000

> While we can add a reference RFC 7224, it is a namespace not a prefix that shows up in the output. Every object in the examples has its specified namespace. You pointed to a part of an example usin…

Two thoughts.  First, the IETF advice is strongly that when an IETF 
module is referenced, then the prefix used should be that that module 
itself declares.  Since this is the common practice, then using any 
other is likely to cause confusion.  Yes, tools have to cope with 
deviations such as 'xmlns:ia=...' but that does not make them right.

Second, iana-if-type is an IANA maintained module so RFC7224 is no 
longer relevant.  Any reference should be to 
www.iana.org/assignments/iana-if-type/ .... (where the prefix is 'ianaift').

Since I see 'xmlns: ...' in the text of the RFC-to-be, in the examples, 
then my take is that understanding the RFC will to some extent depend on 
being familiar with iana-if-type.  I think you need a statement at the 
start of the examples that the examples include references to YANG 
module 'iana-if-type ' [Informative reference to IANA website]

Tom Petch
>> Sent: Thursday, January 6, 2022 2:01 PM
<snip>

---

From: Don Fedyk <[email-masked]>
Date: Mon, 21 Feb 2022 14:28:54 +0000

Hi Tom

I realized I was mainly looking at the JSON output which uses only name spaces. I find them easier to read. Most of our output files were JSON for that reason but we put a few XML examples in. Yanglint can produce XML output as well. 
Here is the actual XML format of the output test cases generated by the Yanglint. 

  <type xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type">ianaift:ethernetCsmacd</type>

Our input file for XML uses some short form local prefixes due to an initial practice where I was prefixing every element - it was less readable so we dropped it, but we didn't update the prefixes. The input test data is not what we should have in the XML examples - it should be the Yanglint output (Which is should identical and has the full prefixes as above I missed that). I have been meaning to update the script to ensure that XML output from Yanglint is equal to the XML input as a test that data is not being missed.  I will update the XML examples which I believe satisfies your point. 

Inline [Don] 

Thanks.
-----Original Message-----
From: tom petch <[email-masked]> 
Sent: Saturday, February 19, 2022 7:23 AM
To: Don Fedyk <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: Comments on detnet-yang-15 Re: [Last-Call] Yangdoctors last call review of draft-ietf-detnet-yang-14

> While we can add a reference RFC 7224, it is a namespace not a prefix that shows up in the output. Every object in the examples has its specified namespace. You pointed to a part of an example usin…

Two thoughts.  First, the IETF advice is strongly that when an IETF module is referenced, then the prefix used should be that that module itself declares.  Since this is the common practice, then using any other is likely to cause confusion.  Yes, tools have to cope with deviations such as 'xmlns:ia=...' but that does not make them right.

Second, iana-if-type is an IANA maintained module so RFC7224 is no longer relevant.  Any reference should be to www.iana.org/assignments/iana-if-type/ .... (where the prefix is 'ianaift').

Since I see 'xmlns: ...' in the text of the RFC-to-be, in the examples, then my take is that understanding the RFC will to some extent depend on being familiar with iana-if-type.  I think you need a statement at the start of the examples that the examples include references to YANG module 'iana-if-type ' [Informative reference to IANA website]
[Don] Noted. 

Tom Petch
<snip>