Subject: [yang-doctors] YANG module & pyang -f yang & source of truth repository

From: Benoit Claise <[email-masked]>
Date: Thu, 4 Jan 2018 12:12:52 +0100

Dear all,

We can say that the RFC is the source of truth but devops people "play" 
about YANG modules.
I'm trying to have a single source of truth for the repository of 
RFC-produced YANG modules, while we have multiple ones now.

IMO, it should be IANA.  We've discussing this option with RFC editor 
and IANA: 
https://www.iana.org/assignments/yang-parameters/yang-parameters.xhtml 
is being transformed in that direction.
The end goal is that end users, wanted to be up-to-date with the latest 
RFC-produced YANG modules, would perform a cron job such as:
     rsync -avz --delete rsync.ietf.org::iana/yang-parameters .

Note: especially interested for IANA-maintained YANG modules such as 
iana-if-type

Now the follow-up question from IANA:

    We were working on the posting of the yang modules for
    _draft-ietf-rtgwg-routing-types
    <https://datatracker.ietf.org/idtracker/draft-ietf-rtgwg-routing-types/>_
    per our new process.  When requesting the final files from the
    RFC-Editor, the file they extracted using their tool and the yang
    modules appear to have a lot of blank space in them.  See attached

    Is this OK?  Do we post it as it is in the provided file from the
    RFC-Editor?  We know that there is some sensitivity to spacing in
    these files so we want to make sure the correct thing is being posted.

The solution should be: pyang -f yang ...
However, after some testing:

bclaise@bclaise-VirtualBox:/media/sf_ubuntu-share/toberemoved$ pyang -f 
yang [email-masked] > newfile.yang
bclaise@bclaise-VirtualBox:/media/sf_ubuntu-share/toberemoved$ diff 
[email-masked] newfile.yang
16d15
<
35,39c34,39
<    revision 2017-12-04 {
<      description "Initial revision.";
<      reference
<        "RFC 8294: Common YANG Data Types for the Routing Area.
<         Section 4.";
---
 >   revision 2017-12-04 {
 >     description
 >       "Initial revision.";
 >     reference
 >       "RFC 8294: Common YANG Data Types for the Routing Area.
 >        Section 4.";
42,47d41
<
<
<
<   /*** Collection of IANA types related to routing ***/
<   /*** IANA Address Family enumeration ***/
<
50c44
<       enum ipv4 {
---
 >       enum "ipv4" {
55,56c49
<
<       enum ipv6 {
---
 >       enum "ipv6" {
61,62c54
<
<       enum nsap {
---
 >       enum "nsap" {
67,68c59
<
<       enum hdlc {
---
 >       enum "hdlc" {
73,74c64
<
<       enum bbn1822 {
---
 >       enum "bbn1822" {
80,81c70
<
<       enum ieee802 {
---
 >       enum "ieee802" {
87,88c76
<
<       enum e163 {
---
 >       enum "e163" {
93c81
<       enum e164 {
---
 >       enum "e164" {
99,100c87
<
<       enum f69 {
---
 >       enum "f69" {
105,106c92
<
<       enum x121 {
---
 >       enum "x121" {
111,112c97
<
<       enum ipx {
---
 >       enum "ipx" {
118,119c103
<
<       enum appletalk {
---
 >       enum "appletalk" {
124,125c108
<
<       enum decnet-iv {
---
 >       enum "decnet-iv" {
130,131c113
<
<       enum vines {
---
 >       enum "vines" {
136,141c118
<
<
<
<
<
<       enum e164-nsap {
---
 >       enum "e164-nsap" {
146,147c123
<
<       enum dns {
---
 >       enum "dns" {
152,153c128
<
<       enum distinguished-name {
---
 >       enum "distinguished-name" {
158,159c133
<
<       enum as-num {
---
 >       enum "as-num" {
164,165c138
<
<       enum xtp-v4 {
---
 >       enum "xtp-v4" {
171,172c144
<
<       enum xtp-v6 {
---
 >       enum "xtp-v6" {
177,178c149
<
<       enum xtp-native {
---
 >       enum "xtp-native" {
183,184c154
<
<       enum fc-port {
---
 >       enum "fc-port" {
189c159
<       enum fc-node {
---
 >       enum "fc-node" {
194,195c164
<
<       enum gwid {
---
 >       enum "gwid" {
200,201c169
<
<       enum l2vpn {
---
 >       enum "l2vpn" {
206,207c174
<
<       enum mpls-tp-section-eid {
---
 >       enum "mpls-tp-section-eid" {
213,214c180
<
<       enum mpls-tp-lsp-eid {
---
 >       enum "mpls-tp-lsp-eid" {
220,221c186
<
<       enum mpls-tp-pwe-eid {
---
 >       enum "mpls-tp-pwe-eid" {
226,227c191
<
<       enum mt-v4 {
---
 >       enum "mt-v4" {
232,237c196
<
<
<
<
<
<       enum mt-v6 {
---
 >       enum "mt-v6" {
242,243c201
<
<       enum eigrp-common-sf {
---
 >       enum "eigrp-common-sf" {
249,250c207
<
<       enum eigrp-v4-sf {
---
 >       enum "eigrp-v4-sf" {
255,256c212
<
<       enum eigrp-v6-sf {
---
 >       enum "eigrp-v6-sf" {
261,262c217
<
<       enum lcaf {
---
 >       enum "lcaf" {
268,269c223
<
<       enum bgp-ls {
---
 >       enum "bgp-ls" {
275,276c229
<
<       enum mac-48 {
---
 >       enum "mac-48" {
281,285c234
<
<
<
<
<       enum mac-64 {
---
 >       enum "mac-64" {
290,291c239
<
<       enum trill-oui {
---
 >       enum "trill-oui" {
298,299c246
<
<       enum trill-mac-24 {
---
 >       enum "trill-mac-24" {
304,305c251
<
<       enum trill-mac-40 {
---
 >       enum "trill-mac-40" {
310,311c256
<
<       enum ipv6-64 {
---
 >       enum "ipv6-64" {
317,318c262
<
<       enum trill-rbridge-port-id {
---
 >       enum "trill-rbridge-port-id" {
323,324c267
<
<       enum trill-nickname {
---
 >       enum "trill-nickname" {
330,332d272
<
<
<
336d275
<
339,341d277
<   /*** Subsequent Address Family Identifiers (SAFIs) ***/
<   /*** for multiprotocol BGP enumeration ***/
<
344c280
<       enum unicast-safi {
---
 >       enum "unicast-safi" {
349,350c285
<
<       enum multicast-safi {
---
 >       enum "multicast-safi" {
355,356c290
<
<       enum labeled-unicast-safi {
---
 >       enum "labeled-unicast-safi" {
361,362c295
<
<       enum multicast-vpn-safi {
---
 >       enum "multicast-vpn-safi" {
367,368c300
<
<       enum pseudowire-safi {
---
 >       enum "pseudowire-safi" {
373,374c305
<
<       enum tunnel-encap-safi {
---
 >       enum "tunnel-encap-safi" {
379,381c310
<
<
<       enum mcast-vpls-safi {
---
 >       enum "mcast-vpls-safi" {
386,387c315
<
<       enum tunnel-safi {
---
 >       enum "tunnel-safi" {
392,393c320
<
<       enum vpls-safi {
---
 >       enum "vpls-safi" {
398,399c325
<
<       enum mdt-safi {
---
 >       enum "mdt-safi" {
404,405c330
<
<       enum v4-over-v6-safi {
---
 >       enum "v4-over-v6-safi" {
410,411c335
<
<       enum v6-over-v4-safi {
---
 >       enum "v6-over-v4-safi" {
416,417c340
<
<       enum l1-vpn-auto-discovery-safi {
---
 >       enum "l1-vpn-auto-discovery-safi" {
422,423c345
<
<       enum evpn-safi {
---
 >       enum "evpn-safi" {
428,429c350
<
<       enum bgp-ls-safi {
---
 >       enum "bgp-ls-safi" {
434,435c355
<
<       enum bgp-ls-vpn-safi {
---
 >       enum "bgp-ls-vpn-safi" {
440,441c360
<
<       enum sr-te-safi {
---
 >       enum "sr-te-safi" {
446,447c365
<
<       enum labeled-vpn-safi {
---
 >       enum "labeled-vpn-safi" {
452,453c370
<
<       enum multicast-mpls-vpn-safi {
---
 >       enum "multicast-mpls-vpn-safi" {
458,459c375
<
<       enum route-target-safi {
---
 >       enum "route-target-safi" {
464,465c380
<
<       enum ipv4-flow-spec-safi {
---
 >       enum "ipv4-flow-spec-safi" {
470,471c385
<
<       enum vpnv4-flow-spec-safi {
---
 >       enum "vpnv4-flow-spec-safi" {
476,477c390
<
<       enum vpn-auto-discovery-safi {
---
 >       enum "vpn-auto-discovery-safi" {
485,486c398
<     reference
<       "RFC 4760: Multiprotocol Extensions for BGP-4.";
---
 >     reference "RFC 4760: Multiprotocol Extensions for BGP-4.";
bclaise@bclaise-VirtualBox:/media/sf_ubuntu-share/toberemoved$

pyang -f yang does more than the formatting, it adds double quotes to 
enum, remove comments, and potentially does more (I don't know what I 
don't know).

So here is the question: do we agree that the IANA, as source of truth 
for YANG modules, should apply pyang -f format before posting a YANG module?

Bonus question: if the double quotes for enum is the best solution, 
should it be a warning in validators?

Regards, Benoit

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 4 Jan 2018 13:07:18 +0100

We never managed to get this working for MIB modules but perhaps
things are working out this time. If you go for it, make sure there is
proper version control behind the solution. You will have to deal with
erratas that need to be applied etc. and clearly IANA needs to update
their modules.

/js

On Thu, Jan 04, 2018 at 12:12:52PM +0100, Benoit Claise wrote:
> IMO, it should be IANA.  We've discussing this option with RFC editor and
> IANA: https://www.iana.org/assignments/yang-parameters/yang-parameters.xhtml
> bclaise@bclaise-VirtualBox:/media/sf_ubuntu-share/toberemoved$ pyang -f yang
> [email-masked] > newfile.yang
> pyang -f yang does more than the formatting, it adds double quotes to enum,
> remove comments, and potentially does more (I don't know what I don't know).
> 
> So here is the question: do we agree that the IANA, as source of truth for
> YANG modules, should apply pyang -f format before posting a YANG module?
> 
> Bonus question: if the double quotes for enum is the best solution, should
> it be a warning in validators?
> 
> Regards, Benoit
> 
> 
> 
> 
> 
> 
> 

> _______________________________________________
> yang-doctors mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/yang-doctors

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Benoit Claise <[email-masked]>
Date: Thu, 4 Jan 2018 13:53:42 +0100

Hi Jürgen,

There are multiple version control situations:
- IANA maintained YANG module, this is easy: there is a new revision. 
Ex: iana-routing-types
- YANG module bis + obsolete: the old YANG module should be hidden in 
IANA. Ex: ietf-l3vpn-svc
- YANG module bis + update: I don't believe faced the issue already.
- errata on the YANG module inside a RFC: this is looking for troubles 
IMO. To be decided on a case by case basis.

Regards, Benoit

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 4 Jan 2018 14:29:01 +0100

I know that the IETF/IANA is resisting to adopt proper version control
systems in their official processes but having maintained a large
collection of RFC MIB modules over many years, I know that it is damn
good to be able to go back in order to understand why and when a
change was made. Perhaps IANA is able to track all this using whatever
databases they are using. If not, there are well known solutions out
there these days...

/js

On Thu, Jan 04, 2018 at 01:53:42PM +0100, Benoit Claise wrote:
> - IANA maintained YANG module, this is easy: there is a new revision. Ex:
> iana-routing-types
> - YANG module bis + obsolete: the old YANG module should be hidden in IANA.
> Ex: ietf-l3vpn-svc
> - errata on the YANG module inside a RFC: this is looking for troubles IMO.
> To be decided on a case by case basis.
> 
> Regards, Benoit

---

From: Mahesh Jethanandani <[email-masked]>
Date: Thu, 4 Jan 2018 07:35:08 -0800

Benoit,

Agree that pyang -f should strip the whitespace and do pretty formatting. But none of the examples in RFC 7950 show enum with double-quotes.

> On Jan 4, 2018, at 3:12 AM, Benoit Claise <[email-masked]> wrote:
> 
> Dear all,
> 
> We can say that the RFC is the source of truth but devops people "play" about YANG modules.
> I'm trying to have a single source of truth for the repository of RFC-produced YANG modules, while we have multiple ones now.
> 
> IMO, it should be IANA.  We've discussing this option with RFC editor and IANA: https://www.iana.org/assignments/yang-parameters/yang-parameters.xhtml <https://www.iana.org/assignments/yang-parameters/yang-parameters.xhtml> is being transformed in that direction.
> The end goal is that end users, wanted to be up-to-date with the latest RFC-produced YANG modules, would perform a cron job such as:
> Note: especially interested for IANA-maintained YANG modules such as iana-if-type
> 
> We were working on the posting of the yang modules for draft-ietf-rtgwg-routing-types <https://datatracker.ietf.org/idtracker/draft-ietf-rtgwg-routing-types/> per our new process.  When requesting the final files from the RFC-Editor, the file they extracted using their tool and the yang modules appear to have a lot of blank space in them.  See attached
> 
> Is this OK?  Do we post it as it is in the provided file from the RFC-Editor?  We know that there is some sensitivity to spacing in these files so we want to make sure the correct thing is being posted.
> bclaise@bclaise-VirtualBox:/media/sf_ubuntu-share/toberemoved$ pyang -f yang [email-masked] <mailto:[email-masked]> > newfile.yang
> bclaise@bclaise-VirtualBox:/media/sf_ubuntu-share/toberemoved$ diff [email-masked] <mailto:[email-masked]> newfile.yang
> 16d15
> < 
> 35,39c34,39
> <    revision 2017-12-04 {
> pyang -f yang does more than the formatting, it adds double quotes to enum, remove comments, and potentially does more (I don't know what I don't know).
> 
> So here is the question: do we agree that the IANA, as source of truth for YANG modules, should apply pyang -f format before posting a YANG module?
> 
> Bonus question: if the double quotes for enum is the best solution, should it be a warning in validators?
> 
> Regards, Benoit
>     
> 
> 
> 
> 
> 
> 

Mahesh Jethanandani
[email-masked]

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 4 Jan 2018 16:54:11 +0000

Hi YANG Doctors,

Personally, I don’t like the double quoting of enums.

Thanks,
Acee

From: yang-doctors <[email-masked]<mailto:[email-masked]>> on behalf of Mahesh Jethanandani <[email-masked]<mailto:[email-masked]>>
Date: Thursday, January 4, 2018 at 10:35 AM
To: "Benoit Claise (bclaise)" <[email-masked]<mailto:[email-masked]>>
Cc: "Miroslav Kovac -X (mirkovac - PANTHEON TECHNOLOGIES at Cisco)" <[email-masked]<mailto:[email-masked]>>, "Joe Clarke (jclarke)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, YANG Doctors <[email-masked]<mailto:[email-masked]>>, Michelle Cotton <[email-masked]<mailto:[email-masked]>>
Subject: Re: [yang-doctors] YANG module & pyang -f yang & source of truth repository

Benoit,

On Jan 4, 2018, at 3:12 AM, Benoit Claise <[email-masked]<mailto:[email-masked]>> wrote:

Dear all,

IMO, it should be IANA.  We've discussing this option with RFC editor and IANA: https://www.iana.org/assignments/yang-parameters/yang-parameters.xhtml is being transformed in that direction.
The end goal is that end users, wanted to be up-to-date with the latest RFC-produced YANG modules, would perform a cron job such as:
    rsync -avz --delete rsync.ietf.org<http://rsync.ietf.org>::iana/yang-parameters .

We were working on the posting of the yang modules for draft-ietf-rtgwg-routing-types<https://datatracker.ietf.org/idtracker/draft-ietf-rtgwg-routing-types/> per our new process.  When requesting the final files from the RFC-Editor, the file they extracted using their tool and the yang modules appear to have a lot of blank space in them.  See attached

bclaise@bclaise-VirtualBox:/media/sf_ubuntu-share/toberemoved$ pyang -f yang [email-masked]<mailto:[email-masked]> > newfile.yang
bclaise@bclaise-VirtualBox:/media/sf_ubuntu-share/toberemoved$ diff [email-masked]<mailto:[email-masked]> newfile.yang
16d15
<
35,39c34,39
<    revision 2017-12-04 {
<      description "Initial revision.";
<      reference
<        "RFC 8294: Common YANG Data Types for the Routing Area.
<         Section 4.";
---
42,47d41
<
<
<
55,56c49
<
<       enum ipv6 {
---
61,62c54
<
<       enum nsap {
---
67,68c59
<
<       enum hdlc {
---
73,74c64
<
<       enum bbn1822 {
---
80,81c70
<
<       enum ieee802 {
---
87,88c76
<
<       enum e163 {
---
93c81
<       enum e164 {
---
99,100c87
<
<       enum f69 {
---
105,106c92
<
<       enum x121 {
---
111,112c97
<
<       enum ipx {
---
118,119c103
<
<       enum appletalk {
---
124,125c108
<
<       enum decnet-iv {
---
130,131c113
<
<       enum vines {
---
136,141c118
<
<
<
<
<
<       enum e164-nsap {
---
146,147c123
<
<       enum dns {
---
152,153c128
<
158,159c133
<
<       enum as-num {
---
164,165c138
<
<       enum xtp-v4 {
---
171,172c144
<
<       enum xtp-v6 {
---
177,178c149
<
<       enum xtp-native {
---
183,184c154
<
<       enum fc-port {
---
189c159
<       enum fc-node {
---
194,195c164
<
<       enum gwid {
---
200,201c169
<
<       enum l2vpn {
---
206,207c174
<
213,214c180
<
<       enum mpls-tp-lsp-eid {
---
220,221c186
<
<       enum mpls-tp-pwe-eid {
---
226,227c191
<
<       enum mt-v4 {
---
232,237c196
<
<
<
<
<
<       enum mt-v6 {
---
242,243c201
<
<       enum eigrp-common-sf {
---
249,250c207
<
<       enum eigrp-v4-sf {
---
255,256c212
<
<       enum eigrp-v6-sf {
---
261,262c217
<
<       enum lcaf {
---
268,269c223
<
<       enum bgp-ls {
---
275,276c229
<
<       enum mac-48 {
---
281,285c234
<
<
<
<
<       enum mac-64 {
---
290,291c239
<
<       enum trill-oui {
---
298,299c246
<
<       enum trill-mac-24 {
---
304,305c251
<
<       enum trill-mac-40 {
---
310,311c256
<
<       enum ipv6-64 {
---
317,318c262
<
323,324c267
<
<       enum trill-nickname {
---
330,332d272
<
<
<
336d275
<
339,341d277
349,350c285
<
<       enum multicast-safi {
---
355,356c290
<
361,362c295
<
367,368c300
<
<       enum pseudowire-safi {
---
373,374c305
<
379,381c310
<
<
<       enum mcast-vpls-safi {
---
386,387c315
<
<       enum tunnel-safi {
---
392,393c320
<
<       enum vpls-safi {
---
398,399c325
<
<       enum mdt-safi {
---
404,405c330
<
<       enum v4-over-v6-safi {
---
410,411c335
<
<       enum v6-over-v4-safi {
---
416,417c340
<
422,423c345
<
<       enum evpn-safi {
---
428,429c350
<
<       enum bgp-ls-safi {
---
434,435c355
<
<       enum bgp-ls-vpn-safi {
---
440,441c360
<
<       enum sr-te-safi {
---
446,447c365
<
452,453c370
<
458,459c375
<
464,465c380
<
470,471c385
<
476,477c390
<
485,486c398
<     reference

Regards, Benoit

_______________________________________________
yang-doctors mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/yang-doctors

Mahesh Jethanandani
[email-masked]<mailto:[email-masked]>

---

From: Radek Krejčí <[email-masked]>
Date: Fri, 5 Jan 2018 09:59:26 +0100

Hi,
not sure if it is the case of pyang, but with my experience with libyang, it is not a problem to print enums without quotes, but it is a problem to preserve what was in input file. enum can be written with or without quotes and in some cases some quotes are necessary. Therefore, at least libyang/yanglint, chooses consistency and always print double quotes around enums. And it is not only the case of enums, even one-word description is always quoted. On the other hand, I don't think that the author should be warned when there are no quotes. When the rules for the string content are not violated, the specs allows e.g. foo, "foo" and 'foo'.

Regards,
Radek

Dne 4.1.2018 v 17:54 Acee Lindem (acee) napsal(a):
> From: yang-doctors <[email-masked] <mailto:[email-masked]>> on behalf of Mahesh Jethanandani <[email-masked] <mailto:[email-masked]>>
> To: "Benoit Claise (bclaise)" <[email-masked] <mailto:[email-masked]>>
> Cc: "Miroslav Kovac -X (mirkovac - PANTHEON TECHNOLOGIES at Cisco)" <[email-masked] <mailto:[email-masked]>>, "Joe Clarke (jclarke)" <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, YANG Doctors <[email-masked] <mailto:[email-masked]>>, Michelle Cotton <[email-masked] <mailto:[email-masked]>>

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 05 Jan 2018 11:27:45 +0100 (CET)

Hi,

Benoit Claise <[email-masked]> wrote:
> The end goal is that end users, wanted to be up-to-date with the
> latest RFC-produced YANG modules, would perform a cron job such as:

Note that the IANA-maintained modules are already available there, e.g.:

  http://www.iana.org/assignments/yang-parameters/[email-masked]

>    these files so we want to make sure the correct thing is being posted.

I agree that the additional whitespace is an issue.  In the pyang
repo, I store all IETF/IANA modules, and I first extract the modules
then manually go through them to remove extra newlines.  Not ideal.

> The solution should be: pyang -f yang ...

You can do pyang -f yang --keep-comments ...  to keep comments.

But I'm not sure that this is the correct solution.  I think the
stored modules should look the same (not just be semantially
equivalent) as the modules in the RFC.

This said, we should encourage people to use consistent formatting,
and run pyang -f yang or equivalent *before* putting the module into
the RFC.

> bclaise@bclaise-VirtualBox:/media/sf_ubuntu-share/toberemoved$ pyang
> -f yang [email-masked] > newfile.yang

[...]

> enum, remove comments, and potentially does more (I don't know what I

It does a bunch of things considered "best practise" (use single
quotes for XPath expressions, if possible for example), and it
formats everything consistently wrt. whitespaces and quotes.

> for YANG modules, should apply pyang -f format before posting a YANG

I don't think so, as I wrote above.  Ideally the author should somehow
give the module to IANA, but then the problem is that the RFC editor
often makes changes to the module, so we have a sync problem.  Extract
and manually fix newlines is probably the best solution currently.

> should it be a warning in validators?

No.  The only reason pyang prints quotes around enums is that
sometimes the quotes are needed, and thus it always prints them, for
consistency.  I could certainly change this so that it prints q/o
quotes in the normal case, and w/ quotes only if it is needed.

/martin

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 5 Jan 2018 13:05:47 +0000

Hi Radek, 

On 1/5/18, 3:59 AM, "Radek Krejčí" <[email-masked]> wrote:

>Hi,
>not sure if it is the case of pyang, but with my experience with libyang,
>it is not a problem to print enums without quotes, but it is a problem to
>preserve what was in input file. enum can be written with or without
>quotes and in some cases some quotes are necessary.

While the enum name can be a string including embedded whitespace, I think
this should be discouraged and only values that satisfy the constraints
for a YANG identifier should be used.

Thanks,
Acee 

>Therefore, at least libyang/yanglint, chooses consistency and always
>print double quotes around enums. And it is not only the case of enums,
>even one-word description is always quoted. On the other hand, I don't
>think that the author should be warned when there are no quotes. When the
>rules for the string content are not violated, the specs allows e.g. foo,
>"foo" and 'foo'.
>
>Regards,
>Radek
>
>
>> From: yang-doctors <[email-masked]
>><mailto:[email-masked]>> on behalf of Mahesh Jethanandani
>><[email-masked] <mailto:[email-masked]>>
>> Cc: "Miroslav Kovac -X (mirkovac - PANTHEON TECHNOLOGIES at Cisco)"
>><[email-masked] <mailto:[email-masked]>>, "Joe Clarke (jclarke)"
>><[email-masked] <mailto:[email-masked]>>,
>>"[email-masked] <mailto:[email-masked]>"
>><[email-masked] <mailto:[email-masked]>>,
>>"[email-masked] <mailto:[email-masked]>"
>><[email-masked] <mailto:[email-masked]>>, YANG Doctors
>><[email-masked] <mailto:[email-masked]>>, Michelle Cotton
>><[email-masked] <mailto:[email-masked]>>
>>     Agree that pyang -f should strip the whitespace and do pretty
>>formatting. But none of the examples in RFC 7950 show enum with
>>double-quotes.
>>
>
>

---

From: Radek Krejčí <[email-masked]>
Date: Fri, 5 Jan 2018 16:38:35 +0100

Hi Acee,

> for a YANG identifier should be used.

this can be said in guidelines (RFC6087bis), but from the YANG parsers and validators perspective, these names (with whitespaces) are completely valid and parsers have to accept them since they are allowed by the specification. libyang and pyang just decided to print all these names the same way to be consistent.

Radek

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 05 Jan 2018 17:04:03 +0100

> You can do pyang -f yang --keep-comments ...  to keep comments.

This fails for some legal comments:

$ cat triva.yang
module triva {
  namespace "http://example.com/ll/triva";
  prefix ta;

  leaf "foo" /* comment */ + "bar" {
    type string;
  }
}
$ pyang -f yang --keep-comments triva.yang
triva.yang:5: error: unterminated statement definition for keyword "leaf", looking at /

> and run pyang -f yang or equivalent *before* putting the module into

We should agree on some rules and make sure our tools follow them. It
should be like

1. Statements are split into three categories: with unquoted,
double-quoted and single-quoted arguments.

2. Quoting is added where needed, and unquoted args are then transformed
preferably into double-quoted if possible.

BTW, another benefit of writing modules in the YIN syntax is that
one needn't care at all about quoting, breaking long arguments etc. My
XSLT stylesheet then I think does a very decent job in transforming it
to the YANG syntax:

https://github.com/CZ-NIC/yangson/blob/master/tools/xslt/yin2yang.xsl

And when I am at it, it would IMO be hugely beneficial to be able to
include YIN modules in the xml2rfc XML source (if the xml2rfc tool
supported it). We wouldn't then need <artwork>, <CODE BEGINS> lines
could be autogenerated so that they are never out of sync with the
module, and in HTML-rendered RFCs we could have pretty-printed modules
with cross-references appearing as active links.

Oh well ...

Lada

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

---

From: Benoit Claise <[email-masked]>
Date: Tue, 9 Jan 2018 18:00:20 +0100

>    http://www.iana.org/assignments/yang-parameters/[email-masked]
Sure. The point is that, in a local toolchain, if you don't get the most 
up-to-date IANA maintained YANG module, a YANG module that augment the 
latest assignment will produce an error. Been there, done that. So a 
rsync-like cronjob is required.
> and run pyang -f yang or equivalent *before* putting the module into
Ideally, yes, but I have no way to enforce that.
> and manually fix newlines is probably the best solution currently.
Well...
This doesn't work from a RFC editor process point of view. We need a 
clear procedure.
YANG doctors should not have to do that, but it could be recommended.
I will not fix line manually.
Educating all authors to do it will most likely not work, even if a 
RFC6087bis recommendation makes sense.

See next.

> quotes in the normal case, and w/ quotes only if it is needed.
I believe the only option is around tooling, i.e. pyang that would only 
take care of the formatting.

	pyang -f yang --keep-comments --only-change-quotes-when-it-s-necessary

Or the reverse option: only-take-care-of-formatting

Regards, Benoit

> .

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 9 Jan 2018 18:09:52 +0100

On Tue, Jan 09, 2018 at 06:00:20PM +0100, Benoit Claise wrote:
> This doesn't work from a RFC editor process point of view. We need a clear
> procedure.

Look at RFC 6557 (BCP 175). They introduce the role of a TZ
Coordinator.  And then they post a versioned tar archive. (I am sure
the TZ maintainers have a version controlled repository somewhere but
this at the end does not matter.)

So the key is to find a volunteer "YANG Module Coordinator" and money
to invite him/her for a few beers or dinner.

/js

---

From: Benoit Claise <[email-masked]>
Date: Wed, 10 Jan 2018 14:10:12 +0100

> to invite him/her for a few beers or dinner.
Do I feel (a start of) a sense of potential ownership on your side, 
assuming I would provide the beers or dinner? :-)

Regards, Benoit