[netmod] YANG Versioning weekly calls cancelled Dec 21 and 28

Hi all, The YANG Versioning weekly calls are cancelled Tues Dec 21 and 28. We'll resume on Tues Jan 4. As always, everyone is welcome. Jason -- Weekly webex call details: Meeting number (access code): 161 096 5630 Meeting password: semver? Occurs

[netmod] YANG Versioning Weekly Call Minutes - 2021-12-14

YANG Versioning Weekly Call Minutes - 2021-12-14 Jason: announce Dec 21 and 28 weekly calls are cancelled The primary discussions were around issues #67/#69 - relationship between Packages and yang-library (two options compared: p-02 and J1). Some notes from the discussion: - unclear exactly

Re: [netmod] Must offline-validation of alone be valid?

On Fri, Dec 17, 2021 at 7:11 AM Kent Watsen wrote: > Andy, et. al., > > > I cannot find any RFC text that says has only nodes created by a >> client. >> >> >> Really? Interesting. Still, I know it’s a mantra we’ve held closely >> for many year, right? >> > > No. Quite the opposite. > > >

Re: [netmod] Must offline-validation of alone be valid?

I cannot find any RFC text that says has only nodes created by a client. >>> >>> Really? Interesting. Still, I know it’s a mantra we’ve held closely >>> for many year, right? >>> >>> No. Quite the opposite. >> >> There was a brouhaha back when I proposed the "keystore” draft

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

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

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

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

Re: [netmod] Must offline-validation of alone be valid?

Hi, Kent Watsen wrote: > Andy, et. al., > > > >> I cannot find any RFC text that says has only nodes created > >> by a client. > > > > Really? Interesting. Still, I know it’s a mantra we’ve held closely > > for many year, right? > > > > No. Quite the opposite. > > There was a brouhaha

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

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

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

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

Re: [netmod] Must offline-validation of alone be valid?

Andy, et. al., >> I cannot find any RFC text that says has only nodes created by a >> client. > > Really? Interesting. Still, I know it’s a mantra we’ve held closely for > many year, right? > > No. Quite the opposite. There was a brouhaha back when I proposed the "keystore” draft

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

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

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

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