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

[Don Fedyk <[e-mail]>]

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 <[e-mail]> 
Sent: Thursday, January 6, 2022 2:01 PM
To: tom petch <[e-mail]>
Cc: [e-mail]; [e-mail]
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 <[e-mail]>
Sent: Thursday, January 6, 2022 11:38 AM
To: Don Fedyk <[e-mail]>
Cc: [e-mail]; [e-mail]
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 <[e-mail]>
> 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