Subject: [netmod] too long lines from IANA module inclusion

From: Michael Richardson <[email-masked]>
Date: Sun, 12 Dec 2021 16:17:02 -0500

I'm working on draft-richardson-anima-rfc8366bis, trying to make it RFC8791.
I'm getting many too long line found.  I sure wish for description, that
pyang had a wrap option, but I can cope with doing that manually.

What I don't know how to deal with:

.../draft-richardson-anima-rfc8366bis.xml(397): Warning: Too long line found (L382), 1 characters longer than 72 characters:
     namespace "urn:ietf:params:xml:ns:yang:iana-voucher-assertion-type";

okay, I could contract the name, but that seems wrong.

(I also could use a FAQ/Tutorial/screencast on adapting to RFC8791)

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 12 Dec 2021 23:00:24 +0100

> I'm working on draft-richardson-anima-rfc8366bis, trying to make it RFC8791.
[…]
> What I don't know how to deal with:

RFC 8792?
(ducks)

Grüße, Carsten

---

From: Jürgen Schönwälder <[email-masked]>
Date: Sun, 12 Dec 2021 23:10:30 +0100

> okay, I could contract the name, but that seems wrong.

YANG allows you to split quoted string like this:

     namespace "urn:ietf:params:xml:ns:yang:"
               + "iana-voucher-assertion-type";

/js

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

---

From: Michael Richardson <[email-masked]>
Date: Sun, 12 Dec 2021 17:11:33 -0500

> RFC 8792?

If I put \ into the original .yang file, then it won't process.
So if RFC8792 is the solution, then I think that I probably prefer to have
::include do it.  Otherwise, I have to add another step to the workflow.

I'd also want assurance that the YANG module extractor knows about 8792.
Maybe given that Kent is a leader author on that... it's already taken care of.

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 13 Dec 2021 08:31:03 +0100

On 12. Dec 2021, at 23:11, Michael Richardson <[email-masked]> wrote:
> ::include do it.

Try {::include-fold …} in 1.5.22.
The fold flag will do nothing if not needed, and RFC-8792-fold1 otherwise.
(I have only implemented ‘\’-folding.  If you really need more than 60-something blank spaces in a line, I can add ‘\\’-folding later…)

Grüße, Carsten

---

From: Kent Watsen <[email-masked]>
Date: Tue, 14 Dec 2021 01:49:06 +0000

> On Dec 12, 2021, at 5:11 PM, Michael Richardson <[email-masked]> wrote:
> 
> 

`pyang` and I think `yanglint` also know how to extract folded <artwork> and <sourcecode> elements.

That said, I have never needed to fold a YANG module in an I-D.  As Juergen mentioned, YANG’s built-in mechanisms have always enabled me to fit within 69-columns.

Unsure about module-extractor.  My guess is that it will barf   ;)

K.

---

From: Martin Björklund <[email-masked]>
Date: Tue, 14 Dec 2021 08:33:24 +0100 (CET)

> <artwork> and <sourcecode> elements.

Just a correction; pyang doesn't extract anything, but rfcstrip does,
and it supports folded artwork, and in the latest greatest 1.3 release
it even reconizes the proper RFC8792-defined magic strings ;-)

/martin

> 
> That said, I have never needed to fold a YANG module in an I-D.  As
> Juergen mentioned, YANG’s built-in mechanisms have always enabled me
> to fit within 69-columns.
> 
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 14 Dec 2021 08:42:25 +0100

> That said, I have never needed to fold a YANG module in an I-D.  As Juergen mentioned, YANG’s built-in mechanisms have always enabled me to fit within 69-columns.

Indeed. In this case, one can simple break the offending line like this:

    namespace
      "urn:ietf:params:xml:ns:yang:iana-voucher-assertion-type";

The conventions of RFC 8792 should be used only where it is absolutely necessary.

Lada

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

---

From: Benoit Claise <[email-masked]>
Date: Tue, 14 Dec 2021 09:17:55 +0100

Dear all,
> it even reconizes the proper RFC8792-defined magic strings ;-)
Do we have a couple of IETF drafts with long too long lines, next to 
https://datatracker.ietf.org/doc/draft-richardson-anima-rfc8366bis/ ?
I would like to make sure that the yangcatalog.org extracts the YANG 
module(s) correctly.
Note: the yangcatalog.org uses xym.

Regards, Benoit

---

From: tom petch <[email-masked]>
Date: Fri, 17 Dec 2021 12:31:13 +0000

Trimming the cc:

From: netmod <[email-masked]> on behalf of Benoit Claise <benoit.claise=[email-masked]>
Sent: 14 December 2021 08:17

Dear all,

<tp>

Benoit

I find I2NSF a fruitful source of problems 

draft-ietf-i2nsf-monitoring-data-model-07.txt
has a line of 104ch and somewhere, there or in the early TEAS modules I saw a 130ch line.

Tom Petch

Regards, Benoit

---

From: Kent Watsen <[email-masked]>
Date: Fri, 17 Dec 2021 14:52:07 +0000

Hi Benoit,

> Do we have a couple of IETF drafts with long too long lines, next to https://datatracker.ietf.org/doc/draft-richardson-anima-rfc8366bis/ ?
> I would like to make sure that the yangcatalog.org extracts the YANG module(s) correctly.

Firstly, I need to echo Martin’s correction, it’s `rfcstrip` (not `pyang`) that has the support for RFC 8792.  I knew it was one of Martin’s projects, and `pyang` came to mind first...

Answering your question, RFC 8792 itself has some examples, as does draft-ietf-netconf-sztp-csr (which is about to exit IESG review).  That said, in both cases, the YANG modules themselves are not subjected to wrapping, just the examples are.

Kent

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 17 Dec 2021 16:38:07 +0100

Now you made me curious.
No RFCs use RFC 8792 encoding yet (except for RFC 8792 itself), as you said.

I-Ds:

  "Grant Negotiation and Authorization Protocol", Justin Richer, Aaron
  Parecki, Fabien Imbault, 2021-10-25, <draft-ietf-gnap-core-protocol-08.txt>

(Using this for JSON text.)

  "Problem Details for HTTP APIs", Mark Nottingham, Erik Wilde, Sanjay Dalal,
  2021-10-13, <draft-ietf-httpapi-rfc7807bis-01.txt>

(Using this for JSON text containing a json-schema.org description.)

  "HTTP Message Signatures", Annabelle Backman, Justin Richer, Manu Sporny,
  2021-08-13, <draft-ietf-httpbis-message-signatures-06.txt>

(Using this for examples of Signature-Input, Signature.)

  draft-ietf-netconf-crypto-types-21.txt, draft-ietf-netconf-http-client-server-08.txt, draft-ietf-netconf-https-notif-09.txt, draft-ietf-netconf-keystore-23.txt, draft-ietf-netconf-netconf-client-server-24.txt, draft-ietf-netconf-notification-capabilities-21.txt, draft-ietf-netconf-restconf-client-server-24.txt, draft-ietf-netconf-ssh-client-server-26.txt, draft-ietf-netconf-tls-client-server-26.txt, draft-ietf-netconf-trust-anchors-16.txt, draft-ietf-netmod-yang-instance-file-format-21.txt)

(Tons of netconf drafts, apparently using this mainly for XML examples — I didn’t check all of those.)

  "Conveying a Certificate Signing Request (CSR) in a Secure Zero Touch
  Provisioning (SZTP) Bootstrapping Request", Kent Watsen, Russ Housley, Sean
  Turner, 2021-12-03, <draft-ietf-netconf-sztp-csr-12.txt>

(As mentioned, for a YANG tree, HTTP requests, JSON text.)

  "A Layer 2 VPN Network YANG Model", samier barguil, Oscar de Dios, Mohamed
  Boucadair, Luis Munoz, 2021-11-22, <draft-ietf-opsawg-l2nm-12.txt>

(YANG JSON instances, again.)

  "A Layer 3 VPN Network YANG Model", samier barguil, Oscar de Dios, Mohamed
  Boucadair, Luis Munoz, Alejandro Aguado, 2021-10-08,
  <draft-ietf-opsawg-l3sm-l3nm-18.txt>

(Overly long HTTP requests.)

  "Structured Data for Filtered DNS", Dan Wing, Tirumaleswar Reddy.K, Neil
  Cook, Mohamed Boucadair, 2021-10-13,
  <draft-wing-dnsop-structured-dns-error-page-01.txt>

(JSON.)

  "List Pagination for YANG-driven Protocols", Kent Watsen, Qin WU, Olof
  Hagsand, Hongwei Li, Per Andersson, 2021-10-25,
  <draft-wwlh-netconf-list-pagination-00.txt>

  "NETCONF Extensions to Support List Pagination", Kent Watsen, Qin WU, Olof
  Hagsand, Hongwei Li, Per Andersson, 2021-10-25,
  <draft-wwlh-netconf-list-pagination-nc-02.txt>

  "RESTCONF Extensions to Support List Pagination", Kent Watsen, Qin WU, Olof
  Hagsand, Hongwei Li, Per Andersson, 2021-10-25,
  <draft-wwlh-netconf-list-pagination-rc-02.txt>

(HTTP requests, some XML.)

And, crucially for an implementer, no ‘\\’ wrapping, except (unnecessarily!) in draft-ietf-netconf-ssh-client-server-21.txt (apparently fixed in later versions.)

The form

   =============== NOTE: '\' line wrapping per RFC 8792 ================

(15 equals signs left, 16 equals signs right) seems to be the favorite lead-in; however, draft-wing-dnsop-structured-dns-error-page-01.txt had a version indented by 2 characters that has 14+15 accordingly.  About 5 % 10+11, apparently before RFC 8792 was published so there was less space.)

Examples from the HTTP ecosystem (GNAP, HTTPAPI, HTTPBIS) didn’t have any “===“ decoration, though.  (Why the heck was this left open as a choice for the author?  I like “%%%” decoration instead, should I use that as a personal fashion statement?)

Grüße, Carsten

---

From: Kent Watsen <[email-masked]>
Date: Fri, 17 Dec 2021 16:31:24 +0000

> (15 equals signs left, 16 equals signs right) seems to be the favorite lead-in; however, draft-wing-dnsop-structured-dns-error-page-01.txt had a version indented by 2 characters that has 14+15 acco…

Undoubtedly because it is the rfcfold (https://github.com/ietf-tools/rfcfold) default.  The goal is to hit column-69 so as to provide a visual scanning aid.

> Examples from the HTTP ecosystem (GNAP, HTTPAPI, HTTPBIS) didn’t have any “===“ decoration, though.  (Why the heck was this left open as a choice for the author?  I like “%%%” decoration instead, s…

Because sometimes it is desirable for the bracketing to match the native file commenting syntax (e.g., “#“ for shell/Python, “//“ for C++, “;” for ABNF, etc.)

K.

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 17 Dec 2021 18:12:43 +0100

> Because sometimes it is desirable for the bracketing to match the native file commenting syntax (e.g., “#“ for shell/Python, “//“ for C++, “;” for ABNF, etc.)

But those tools never see that header.
(Or are there examples where you can safely feed a folded block to a tool?)

Grüße, Carsten

---

From: Kent Watsen <[email-masked]>
Date: Fri, 17 Dec 2021 17:21:26 +0000

Hi Carsten,

> (Or are there examples where you can safely feed a folded block to a tool?)

Not always.  The draft specifically allows for manual/smart folding to give better results than simple automation:  See https://datatracker.ietf.org/doc/html/rfc8792#section-9.3 for more examples.

K.