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

[Kent Watsen]

Hi Carsten,

>>> 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?)
>> 
>> 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?)

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.



___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Carsten Bormann]

On 2021-12-17, at 17:31, Kent Watsen  wrote:
> 
>> 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?)
> 
> 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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Kent Watsen]

> (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.)

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, should I use that as a personal 
> fashion statement?)

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.

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Carsten Bormann]

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, 

(Using this for JSON text.)

  "Problem Details for HTTP APIs", Mark Nottingham, Erik Wilde, Sanjay Dalal,
  2021-10-13, 

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

  "HTTP Message Signatures", Annabelle Backman, Justin Richer, Manu Sporny,
  2021-08-13, 

(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, 

(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, 

(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,
  

(Overly long HTTP requests.)

  "Structured Data for Filtered DNS", Dan Wing, Tirumaleswar Reddy.K, Neil
  Cook, Mohamed Boucadair, 2021-10-13,
  

(JSON.)

  "List Pagination for YANG-driven Protocols", Kent Watsen, Qin WU, Olof
  Hagsand, Hongwei Li, Per Andersson, 2021-10-25,
  

  "NETCONF Extensions to Support List Pagination", Kent Watsen, Qin WU, Olof
  Hagsand, Hongwei Li, Per Andersson, 2021-10-25,
  

  "RESTCONF Extensions to Support List Pagination", Kent Watsen, Qin WU, Olof
  Hagsand, Hongwei Li, Per Andersson, 2021-10-25,
  

(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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Kent Watsen]

Hi Benoit,

>>> `pyang` and I think `yanglint` also know how to extract folded
>>>  and  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 ;-)
> 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.

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


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[tom petch]

Trimming the cc:

From: netmod  on behalf of Benoit Claise 

Sent: 14 December 2021 08:17

Dear all,
>> `pyang` and I think `yanglint` also know how to extract folded
>>  and  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 ;-)
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.



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

___
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

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

[Benoit Claise]

Dear all,

`pyang` and I think `yanglint` also know how to extract folded
 and  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 ;-)
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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Ladislav Lhotka]

Kent Watsen  writes:

>> On Dec 12, 2021, at 5:11 PM, Michael Richardson  
>> wrote:
>> 
>> 
>> Carsten Bormann  wrote:
>>> On 2021-12-12, at 22:17, Michael Richardson  wrote:
>> 
 I'm working on draft-richardson-anima-rfc8366bis, trying to make it 
 RFC8791.
>>> […]
 What I don't know how to deal with:
>> 
>>> 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.
>
> `pyang` and I think `yanglint` also know how to extract folded  and 
>  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.

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

>
> Unsure about module-extractor.  My guess is that it will barf   ;)
>
> K.
>
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Martin Björklund]

Kent Watsen  wrote:
> 
> 
> > On Dec 12, 2021, at 5:11 PM, Michael Richardson
> >  wrote:
> > 
> > 
> > Carsten Bormann  wrote:
> >> On 2021-12-12, at 22:17, Michael Richardson 
> >> wrote:
> > 
> >>> I'm working on draft-richardson-anima-rfc8366bis, trying to make it
> >>> RFC8791.
> >> […]
> >>> What I don't know how to deal with:
> > 
> >> 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.
> 
> `pyang` and I think `yanglint` also know how to extract folded
>  and  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.
> 
> Unsure about module-extractor.  My guess is that it will barf   ;)
> 
> K.
> 
> 
> ___
> 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

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

[Kent Watsen]

> On Dec 12, 2021, at 5:11 PM, Michael Richardson  wrote:
> 
> 
> Carsten Bormann  wrote:
>> On 2021-12-12, at 22:17, Michael Richardson  wrote:
> 
>>> I'm working on draft-richardson-anima-rfc8366bis, trying to make it RFC8791.
>> […]
>>> What I don't know how to deal with:
> 
>> 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.

`pyang` and I think `yanglint` also know how to extract folded  and 
 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.


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Carsten Bormann]

On 12. Dec 2021, at 23:11, Michael Richardson  wrote:
> 
> So if RFC8792 is the solution, then I think that I probably prefer to have
> ::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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Michael Richardson]

Carsten Bormann  wrote:
> On 2021-12-12, at 22:17, Michael Richardson  wrote:

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

> 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.



--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide






signature.asc
Description: PGP signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Jürgen Schönwälder]

On Sun, Dec 12, 2021 at 04:17:02PM -0500, Michael Richardson wrote:
> 
> 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.
>

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 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Carsten Bormann]

On 2021-12-12, at 22:17, Michael Richardson  wrote:

> 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

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod