Re: [netmod] Agenda for Virtual NETMOD Meeting

[Updated agenda, now including CORECONF] Also posted here: https://datatracker.ietf.org/doc/agenda-interim-2020-netmod-01-netmod-01/ Agenda for the NETMOD WG Session in IETF 107 Session: Thursday April 2nd PDT: 04:00-06:00 EDT: 07:00-09:0

Re: [netmod] All IETF YANG modules MUST include revision-label statements

On Tue, Mar 31, 2020 at 9:48 AM Sterne, Jason (Nokia - CA/Ottawa) < jason.ste...@nokia.com> wrote: > Darn - poor choice of my first example. I meant this: > > > > 1.0.0 -> 1.1.0 -> 2.0.0 -> 3.0.0 -> 1.2.0 > This is the use-case I want to support. Using revision-date alone, a tool and administrat

Re: [netmod] rfcstrip does not work on https://tools.ietf.org/html/draft-ietf-netmod-artwork-folding-12

Hi, Kent Watsen wrote: > Hi Martin, > > > Version 1.2 of rfcstrip (https://github.com/mbj4668/rfcstrip > > ) can > > extract from the "artwork" element, and performs artwork unfolding, if > > needed. > > Thanks for this update to rfcstrip! > > If it’s not

Re: [netmod] All IETF YANG modules MUST include revision-label statements

Hi Andy, I wasn't so much worried about people filling in the revision statements as they go along. But after a while (especially for vendor models) the list of revision statements could get very large and there may be a desire to remove some of them, or somehow "compress" the information for t

Re: [netmod] All IETF YANG modules MUST include revision-label statements

Darn - poor choice of my first example. I meant this: 1.0.0 -> 1.1.0 -> 2.0.0 -> 3.0.0 -> 1.2.0 would be confusing comparing 1.0.0 and 1.2.0. (I wasn't trying to illustrate a "loop", or coming back to a file that was the same content as previously) From: Sterne, Jason (Nokia - CA/Ottawa) Sent

Re: [netmod] All IETF YANG modules MUST include revision-label statements

The idea is that following down a chain of YANG versions of a module results in a semver that is "cumulative". Just like you can't do this: 1.0.0 -> 1.1.0 -> 2.0.0 -> 3.0.0 -> 1.1.0 That would be confusing when comparing 1.0.0 and 1.1.0. The numbers would imply they are BC. Once you mark an "

[netmod] Presenters!

Presenters, 1) Please SEND your slides by EOB (EDT) today! (i.e., in about 8 hours from now). This is so they can be uploaded to material manager with sufficient time before the meeting so that them may be reviewed by participants before the meeting (this is especially importa

Re: [netmod] All IETF YANG modules MUST include revision-label statements

On Tue, Mar 31, 2020 at 8:37 AM Kent Watsen wrote: > [replying to Reshad as well] > > Hi Rob, > > My impression is that Semver 2.0.0 works fine if you can always force > clients to move to the latest version of the API whenever any bugfixes are > made to the API (whether they are BC or NBC). Thi

Re: [netmod] All IETF YANG modules MUST include revision-label statements

Hi, Thanks for the suggestion. This was discussed, I think the reason we didn’t go with that solution is that (as you mentioned) you need the module contents with all the previous version labels. Does anyone from the design team recall any other details? Regards, Reshad. From: "Ivory, William

Re: [netmod] rfcstrip does not work on https://tools.ietf.org/html/draft-ietf-netmod-artwork-folding-12

Hi Martin, > Version 1.2 of rfcstrip (https://github.com/mbj4668/rfcstrip > ) can > extract from the "artwork" element, and performs artwork unfolding, if > needed. Thanks for this update to rfcstrip! If it’s not too late, may I suggest changing “-a” to “-x”

Re: [netmod] Agenda for Virtual NETMOD Meeting

All, There’s been some confusion regarding *when* the virtual meeting begins. The reason for the confusion is twofold: 1) WebEx only sent an email when the meeting was initially scheduled, but not when the meeting time was changed. 2) The chairs used EDT for the source timezone and sent incor

Re: [netmod] All IETF YANG modules MUST include revision-label statements

[replying to Reshad as well] Hi Rob, > My impression is that Semver 2.0.0 works fine if you can always force clients > to move to the latest version of the API whenever any bugfixes are made to > the API (whether they are BC or NBC). This is a natural fit for open source > projects, but not s

Re: [netmod] rfcstrip does not work on https://tools.ietf.org/html/draft-ietf-netmod-artwork-folding-12

Hi, Version 1.2 of rfcstrip (https://github.com/mbj4668/rfcstrip) can extract from the "artwork" element, and performs artwork unfolding, if needed. See below for some details. Erik Auerswald wrote: > Hi all, > > On 31.03.20 09:36, Carsten Bormann wrote: > > On 2020-03-31, at 09:22, Carsten B

Re: [netmod] [core] 🔔 WG Last Call of CORECONF drafts: draft-ietf-core-yang-cbor-12, -sid-11, -comi-09, -yang-library-01

Dear all, I have reread draft-ietf-core-yang-sid. I am quite happy that this document enters its final processing stage. The document satisfies our wishes expressed earlier. One small point: In section 6.2.2 the size seems superfluous as all ranges have the same size. Greetings, Peter_

Re: [netmod] All IETF YANG modules MUST include revision-label statements

[As an individual contributor] My impression is that Semver 2.0.0 works fine if you can always force clients to move to the latest version of the API whenever any bugfixes are made to the API (whether they are BC or NBC). This is a natural fit for open source projects, but not so great for lon

Re: [netmod] rfcstrip does not work on https://tools.ietf.org/html/draft-ietf-netmod-artwork-folding-12

Hi all, On 31.03.20 09:36, Carsten Bormann wrote: On 2020-03-31, at 09:22, Carsten Bormann wrote: On 2020-03-31, at 01:47, Kent Watsen wrote: I thought someone said that `xml2rfc` was going to support a “markers” attribute for the element, but I don’t see that here yet: https://github.c

Re: [netmod] No descendent statements to input/output can be reordered

"Rob Wilton (rwilton)" wrote: > [As an individual contributor] > > Hi, > > > -Original Message- > > From: netmod On Behalf Of Martin Björklund > > Sent: 28 March 2020 08:43 > > To: Reshad Rahman (rrahman) > > Cc: netmod@ietf.org > > Subject: Re: [netmod] No descendent statements to inp

Re: [netmod] No descendent statements to input/output can be reordered

[As an individual contributor] Hi, > -Original Message- > From: netmod On Behalf Of Martin Björklund > Sent: 28 March 2020 08:43 > To: Reshad Rahman (rrahman) > Cc: netmod@ietf.org > Subject: Re: [netmod] No descendent statements to input/output can be > reordered > > "Reshad Rahman (r

[netmod] js review of draft-ietf-core-yang-cbor-12

Hi, here is my review of draft-ietf-core-yang-cbor-12. I have not checked the examples in detail, I assume (hope?) the authors have used tools to generate them or to validate them. - Nit: There is no need to capitalize Action in the abstract (and elsewhere). - You should perhaps write 'yang-da

Re: [netmod] rfcstrip does not work on https://tools.ietf.org/html/draft-ietf-netmod-artwork-folding-12

As I understand that works if you use Xml2Rfc v3 only. Balazs -Original Message- From: Carsten Bormann Sent: 2020. március 31., kedd 9:36 To: Kent Watsen Cc: Erik Auerswald ; Balázs Lengyel ; netmod@ietf.org Subject: Re: [netmod] rfcstrip does not work on https://tools.ietf.org/html/

Re: [netmod] Where can I use ? - rfcstrip

Hi, On 30.03.20 18:10, Balázs Lengyel wrote: > From: Kent Watsen > > [...] > > All The extracted files (including the two that are NOT folded) > > contain a ‘^@‘ character at the EOF. This must be something > > introduced by `rfcstrip` because `rfcfold` does a simple file-level > > copy when u

Re: [netmod] All IETF YANG modules MUST include revision-label statements

Apologies if this has already been suggested and deemed unworkable, but if you have access to all previous version labels for a branch then you can add 'M' only to the versions that are NBC with the previous version, and subsequent versions could drop the M until the next NBC change, ie: 1.0.0

Re: [netmod] rfcstrip does not work on https://tools.ietf.org/html/draft-ietf-netmod-artwork-folding-12

Oh, and you can find examples for markers=“true” in the published RFCs rfc8650.xml rfc8652.xml rfc8675.xml rfc8676.xml rfc8681.xml rfc8682.xml rfc8695.xml rfc8696.xml rfc8748.xml So this is no longer just a proposal, as the below draft seems to suggest. Grüße, Carsten > On 2020-03-31, at 09:22,

Re: [netmod] rfcstrip does not work on https://tools.ietf.org/html/draft-ietf-netmod-artwork-folding-12

On 2020-03-31, at 01:47, Kent Watsen wrote: > > I thought someone said that `xml2rfc` was going to support a “markers” > attribute for the element, but I don’t see that here yet: > https://github.com/rfc-format/draft-iab-xml2rfc-v3-bis/blob/master/draft-iab-rfc7991bis.xml#L8514. https://tools