Hi Adrian, all,

What is the intended scope?

1) Is it just for examples of YANG requests/replies, or in future, instance data.  If so, then I think that the solution is useful for this.

2) Or should the WG consider allowing a longer line length for YANG modules?  Currently they are limited to something like 69 characters so that they can be inserted into the RFC, but possibly with line folding we could possibly consider increasing that, but perhaps that would make them harder to read/review.

3) I think that there are also cases where tree diagrams wrap and need to be constrained to 69 characters.  Although I don't think that applying the folding algorithm to tree diagrams directly is necessarily a great idea, it might be that tools like pyang could be modified with an option to generate output that is consistent with the definition of the folded output so that it can be unfolded if required.

To give an example of 3:

Rather than this:

   module: ietf-if-l3-vlan
     augment /if:interfaces/if:interface/if-cmn:encapsulation/
                                                    if-cmn:encaps-type:
       +--:(dot1q-vlan)
          +--rw dot1q-vlan
             +--rw outer-tag!
             |  +--rw tag-type    dot1q-tag-type
             |  +--rw vlan-id     ieee:vlanid
             +--rw second-tag!
                +--rw tag-type    dot1q-tag-type
                +--rw vlan-id     ieee:vlanid

the tooling could be modified to optionally generate this instead:

========== NOTE: '\\' line wrapping per BCP XX (RFC XXXX) ===========
module: ietf-if-l3-vlan
     augment /if:interfaces/if:interface/if-cmn:encapsulation/\
                                                   \if-cmn:encaps-type:
       +--:(dot1q-vlan)
          +--rw dot1q-vlan
             +--rw outer-tag!
             |  +--rw tag-type    dot1q-tag-type
             |  +--rw vlan-id     ieee:vlanid
             +--rw second-tag!
                +--rw tag-type    dot1q-tag-type
                +--rw vlan-id     ieee:vlanid

One other question:

How does the algorithm know it has reached the end of the artwork?  I.e. should there also be an end line marker?

Thanks,
Rob


On 19/10/2018 11:12, Adrian Farrel wrote:
Hey Lou,

As an author, I support adoption and would particularly welcome feedback from
the WG to know whether this approach addresses the needs of those writing drafts
for YANG models.

Thanks,
Adrian

-----Original Message-----
From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Lou Berger
Sent: 18 October 2018 14:04
To: NetMod WG
Cc: NetMod WG Chairs
Subject: [netmod] WG adoption poll draft-kwatsen-netmod-artwork-folding-08

All,

This is start of a two week poll on making
draft-kwatsen-netmod-artwork-folding-08 a working group
document. Please send email to the list indicating "yes/support" or
"no/do not support".  If indicating no, please state your reservations
with the document.  If yes, please also feel free to provide comments
you'd like to see addressed once the document is a WG document.

The poll ends Oct 1.

Thanks,

Lou (and co-chairs)
_______________________________________________
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

Reply via email to