From andy@yumaworks.com Wed Oct 25 13:28:40 2023 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0848C180DDD for ; Wed, 25 Oct 2023 13:28:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.104 X-Spam-Level: X-Spam-Status: No, score=-2.104 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks.com Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y02JzstWf-v8 for ; Wed, 25 Oct 2023 13:28:36 -0700 (PDT) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4488DC180DD9 for ; Wed, 25 Oct 2023 13:28:36 -0700 (PDT) Received: by mail-lj1-x22e.google.com with SMTP id 38308e7fff4ca-2c515527310so1916011fa.2 for ; Wed, 25 Oct 2023 13:28:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks.com; s=google; t=1698265714; x=1698870514; darn=ietf.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=hLrsjGsvcoPpcu0oqycXh8uK4czsIZuwUg9/7ZNmGvo=; b=dw9pFX6R4P/nIAuz07fyOfKKxApHHlDOJ8exU3oZnpy1t6SbvQfMLcNsRi/BEWsfQ+ SON1yGNrF4DZzIA0Xd3/gcoDxR40JZ3CYnWcePjtSBQ9IkToXhBoQGH35ts9soJlLe+Y DtDSrT3xtS+pRerenkAnQ5S74gnZAMUxbbBFgMKfsQMd0c90vauTZlzDTM6tyW9dfTvv CQRzOVj1+lXPpQENe8m5Rc0ZBkBwkRhSVpo10jDIkwEL5VfFC98+1BpxpHysSoFGnMZ1 kdbtgHomm5E9zdAII21nKMXpZZejX8X1KTTvWqwrIG3csgC+/n+VKVnb8khnEUqSSfSa NnUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698265714; x=1698870514; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=hLrsjGsvcoPpcu0oqycXh8uK4czsIZuwUg9/7ZNmGvo=; b=oSHXUUEK8LSvbgw86dPwDvgoqKG8F2rjby8G/7nSHilfxhbmLwIAPJdIxozYWs9euc D4YsFtwO6zZ8poPY7m+RNs04IxKFgdZat1pRGvDGTAkdKpQ2+Itv2VFkAntrPPjU+EWK vf2s/Vi4Ia+gJ9Gzbg+rxDXV0VJm++oPpVTg1eueZJk9gUjxsPuVp/PgqxUjSNP/ttVD CAtHpV/7Wu5L/ojJFS5a8uzgqOnaU8EKygbuJo/OdtppaY7c9/yuEramYNRn2/Z1NZ3a SEsZhzBggQAvUsOTJL7g4FxZSDkmfPXzukP2BZD1i7IzInmLJfb2YmqrdKyZI1PLpIRd 8TbA== X-Gm-Message-State: AOJu0Yx8qBcVVpEpES5gFIOp+6cW5Y/y0TL8OdtO5LIlnWHjL1Uo+IVm TOC6VHOxc1pRHGm6zKDJ0nf9Drhq9utu1G1hweCovQ== X-Google-Smtp-Source: AGHT+IFA7MRZrusxlu6rFamHbDR3E8J8t9PJsCUssS0Po/XTFO3ozPpLZGxAGMJ5s5eRXXzpUNsoYrcVXps3LQRrdjs= X-Received: by 2002:a2e:9b06:0:b0:2bc:c4af:36b9 with SMTP id u6-20020a2e9b06000000b002bcc4af36b9mr11957220lji.52.1698265713511; Wed, 25 Oct 2023 13:28:33 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Andy Bierman Date: Wed, 25 Oct 2023 13:28:22 -0700 Message-ID: To: =?UTF-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= , "Jason Sterne (Nokia)" , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="00000000000096aa7b0608904c67" Archived-At: Subject: Re: [netmod] Updated Content of Module Versioning - T7 (Filename changes) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Oct 2023 20:28:40 -0000 --00000000000096aa7b0608904c67 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Oct 25, 2023 at 11:49=E2=80=AFAM J=C3=BCrgen Sch=C3=B6nw=C3=A4lder wrote: > I strongly disagree. You can add additional file names, you can't > soften the existing SHOULD to a conditional SHOULD. > > +1 Getting tools to handle the file naming patterns defined in RFC 7950 took a long time. It would be disruptive to introduce yet another file-naming pattern. It would also be another NBC change forced on YANG 1.1 tools. > /js > > Andy > On Wed, Oct 25, 2023 at 06:45:31PM +0000, Jason Sterne (Nokia) wrote: > > Sure - I'd be OK with adding some wording here that makes it clear the > 7950 recommendation remains. > > > > i.e. you SHOULD use my-module@2023-01-06 as per 7950, but if you elect > to not use that format, and want to use a label in the filename, then thi= s > format is RECOMMENDED: my-module#3.0.2.yang. > > > > I can see that 'primary identifier' isn't great. Maybe something more > like "to uniquely identify the version of the module" or similar. > > > > Jason > > > > > -----Original Message----- > > > From: J=C3=BCrgen Sch=C3=B6nw=C3=A4lder > > > Sent: Wednesday, October 25, 2023 2:32 PM > > > To: Jason Sterne (Nokia) > > > Cc: netmod@ietf.org > > > Subject: Re: [netmod] Updated Content of Module Versioning - T7 > > > (Filename changes) > > > > > > > > > CAUTION: This is an external email. Please be very careful when > clicking > > > links or opening attachments. See the URL nok.it/ext for additional > > > information. > > > > > > > > > > > > It needs to be clear that the existing text in section 5.2 remains > > > untouched. > > > > > > YANG modules and submodules are typically stored in files, one > > > "module" or "submodule" statement per file. The name of the file > > > SHOULD be of the form: > > > > > > module-or-submodule-name ['@' revision-date] ( '.yang' / '.yin' = ) > > > > > > "module-or-submodule-name" is the name of the module or submodule, > > > and the optional "revision-date" is the latest revision of the > module > > > or submodule, as defined by the "revision" statement (Section > 7.1.9). > > > > > > Words like 'primary identifier' confuse me. > > > > > > /js > > > > > > On Wed, Oct 25, 2023 at 06:22:57PM +0000, Jason Sterne (Nokia) wrote: > > > > Hi all, > > > > > > > > Starting a dedicated thread for T7 Filename changes. > > > > > > > > These are my own personal opinions (not those of the > > > authors/contributors). > > > > > > > > RFC7950 says that the filename format SHOULD be my-module@2023-01- > > > 06.yang > > > > > > > > Module versioning currently says the following format is RECOMMENDE= D > > > (if the file has a revision label): my-module#3.1.2.yang > > > > > > > > I'd recommend we remove that from Module Versioning, but add it to > the > > > YANG Semver draft (where all revision label text will be located - it > is all > > > being removed from Module Versioning). > > > > > > > > We could potentially say it more like this: > > > > > > > > If a revision has an associated yang-semver-label, and if the > publisher > > > > wishes to use the label in the filename as the primary identifier > for the > > > > version of the module instead of the revision date, then it is > > > > RECOMMENDED to put the yang-semver-label into the filename as > > > follows: > > > > > > > > module-or-submodule-name ['#' yang-semver-label] ( '.yang' / > '.yin' ) > > > > > > > > E.g., acme-router-module#2.0.3.yang > > > > > > > > YANG module (or submodule) files may be identified using either t= he > > > > revision-date (as per [RFC8407] section 3.2) or the revision labe= l. > > > > > > > > If we don't at least have a recommendation (*if* people really want > to put > > > the label in the filename), then we might have different organization= s > using > > > different formats: > > > > > > > > * org #1: my-module@2.0.3.yang > > > > * org#2: my-module#2.0.3@2023-01-06.yang > > module#2.0.3@2023-01-06.yang> > > > > * org#3: my-module%2.0.3.yang > > > > * org#4: my-module(2.0.3).yang > > > > > > > > I'm trying to find wording that doesn't strongly mandate the my- > > > module#2.0.3.yang filename format, but does highly recommend it *if* > > > someone is going to put a label in the filename somewhere. > > > > > > > > Jason > > > > > > > > > > > > From: netmod On Behalf Of Jason Sterne > > > (Nokia) > > > > Sent: Tuesday, October 24, 2023 9:58 AM > > > > To: netmod@ietf.org > > > > Subject: [netmod] Updated Content of Module Versioning > > > > > > > > Hello NETMOD WG, > > > > > > > > The YANG versioning authors and weekly call group members have been > > > discussing the next steps for the versioning drafts. > > > > > > > > We'd propose that the first step is to converge on what aspects of > the > > > current Module Versioning draft should be retained, and which parts > should > > > be removed. We can then work towards a final call on an updated versi= on > > > with this revised scope. > > > > > > > > Below is a summary of the main topics in the Module Versioning draf= t. > > > We've divided the items T1-T10 into 2 groups: > > > > A) Baseline content of Module Versioning > > > > B) Items which need more WG discussion > > > > > > > > In addition to whatever discussions happen on this email list, we > have also > > > created a hedgedoc where you can register your preference for items T= 7- > > > T10. It would be much appreciated if you can put your opinion in the > > > hedgedoc here: > > > > https://notes.ietf.org/CdKrT5kVSF6qbnRSY4KeSA?both > > > > > > > > > > > > GROUP A (Baseline content of Module Vesioning) > > > > ----------------------------------------------------------------- > > > > Based on resolution of WG LC comments and subsequent discussions, a= nd > > > some feedback to reduce complexity and content in the Module Versioni= ng > > > draft, here is a summary of items that will and won't be part of the > next > > > update of the Module Versioning draft (also referred to as "this draf= t" > > > below). > > > > > > > > T1. The "ver:non-backwards-compatible" annotation (Sec 3.2): > > > > Retained. This top level (module level) extension (which can be > ignored by > > > tools that don't understand it) is critical to include so that module > readers > > > and tools can know when NBC changes have occurred. > > > > > > > > T2. Updated rules of what is NBC: (Sect 3.1.1, 3.1.2) > > > > Retained. These are updates/clarifications (i.e., changes) to the > RFC 7950 > > > rules that are appropriate and helpful: > > > > (i) "status obsolete" > > > > - This draft changes RFC 7950 so that marking a data node as > obsolete is > > > an NBC change because it can break clients. > > > > (ii) "extensions" > > > > - This draft changes the RFC 7950 rules to allow extensions to > define the > > > backwards compatibility considerations for the extension itself. The > existing > > > RFC 7950 rules only allow extensions to be added, not changed or > removed. > > > > (iii) "import by revision-date" > > > > - This draft changes the RFC 7950 rules to allow the revision dat= e > of an > > > import-statement to be changed/added/removed. The imported module > > > must be versioned separately (i.e., by a YANG package/library definin= g > the > > > schema). > > > > (iv) "whitespace": > > > > - This draft clarifies the existing RFC 7950 behaviour that > changing > > > insignificant whitespace is classified as a backwards compatible chan= ge > > > > > > > > T3. revision-label-scheme extension (Sec 3.4.2) > > > > Removed. Based on WG LC discussions we will go back to a single > > > versioning scheme for YANG modules, and hence the revision-label-sche= me > > > extension will be removed from this draft. > > > > > > > > T4. revision-label extension (Sec 3.4) > > > > Removed. Related to T3 above, given that a single versioning scheme > is > > > sufficient, the revision-label extension will be moved to the YANG > Semver > > > draft, and removed from Module Versioning. > > > > > > > > T5. Resolving ambiguous imports in YANG library (Sec 5.1) > > > > Removed. This will be removed from Module Versioning (could be > > > considered in YANG Next, although that is many years away). Note, RF= C > > > 7950, section 5.6.5, paragraph 5 does consistently define how to buil= d > the > > > schema. The change in the draft was to always prioritise an > implemented > > > module over the most recent implemented *or* import-only revision. Bu= t > > > this will be removed. > > > > > > > > T6. Advertisement for how deprecated & obsolete nodes are handled > (Sec > > > 5.2.2) > > > > Retained. This information is important for clients to be able to > accurately > > > construct the schema and hence it is retained in Module Versioning. > > > > > > > > GROUP B (Needs WG discussion) > > > > ------------------------------------------- > > > > For these items we don't have consensus within the WG - they need > more > > > discussion and input. > > > > > > > > It is recommended to go back and look at the NETMOD emails on these > > > topics (from the WG LC discussions). > > > > > > > > Please add your name beside your preferred option in the poll: > > > https://notes.ietf.org/CdKrT5kVSF6qbnRSY4KeSA?both > > > > > > > > T7. filename changes (Sec 3.4.1) > > > > The authors/contributors are leaning towards suggesting that this > moved > > > change be moved to YANG Next consideration. However, there isn't > > > complete consensus, with concerns that the vendors will each define > their > > > own incompatible file naming schemes for YANG modules that use versio= n > > > numbers. If we retain this work then this would likely move to the > YANG > > > Semver draft. > > > > [See hedgedoc poll T7] > > > > > > > > T8. recommended-min for imports (Sec 4) > > > > The WG seems to be somewhat split on how urgent this is, and there > isn't > > > consensus amongst authors/contributors for retaining this work or > > > deferring it. One option is to keep it, but renamed as recommended-mi= n- > > > date. > > > > [See hedgedoc poll T8] > > > > > > > > T9. Versioning of YANG instance data (Sec 6) > > > > There wasn't any consensus among the authors/contributors as to > > > whether this should be retained or deferred to a new version of the > YANG > > > instance data document. > > > > [See hedgedoc poll T9] > > > > > > > > T10. Do *all* whitespace changes (including whitespace between > > > statements) require a new revision to be published? Sec 3.1, last > paragraph. > > > > The authors/contributors are somewhat split on whether to retain > this. > > > The advantage of keeping this is that it makes it very easy to check > (i.e., via a > > > simple text diff tool) whether two modules pertaining to be the same > > > version are in fact the same. It should also mean that it is easy to > generate > > > a hash-based fingerprint of a module revision. The alternative gives > more > > > flexibility to users to reformat modules (e.g., for different > line-lengths), but > > > complicates the check to ensure that a YANG module revision hasn't be= en > > > changed or makes it slightly more expensive to generate a hash since > the > > > module formatting would need to be normalized first. > > > > [See hedgedoc poll T10] > > > > > > > > Jason (he/him) > > > > > > > > > > > _______________________________________________ > > > > netmod mailing list > > > > netmod@ietf.org > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > > > -- > > > J=C3=BCrgen Sch=C3=B6nw=C3=A4lder Constructor University= Bremen gGmbH > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | German= y > > > Fax: +49 421 200 3103 > > -- > J=C3=BCrgen Sch=C3=B6nw=C3=A4lder Constructor University Bre= men 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 > --00000000000096aa7b0608904c67 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Oct 25, 2023 at 11:49=E2=80= =AFAM J=C3=BCrgen Sch=C3=B6nw=C3=A4lder <jschoenwaelder@constructor.univ= ersity> wrote:
/js


Andy
=C2=A0
On Wed, Oct 25, 2023 at 06:45:31PM +0000, Jason Sterne (Nokia) wrote:
> Sure - I'd be OK with adding some wording here that makes it clear= the 7950 recommendation remains.
>
> i.e. you SHOULD use my-module@2023-01-06 as per 7950, but if you elect= to not use that format, and want to use a label in the filename, then this= format is RECOMMENDED:=C2=A0 my-module#3.0.2.yang.
>
> I can see that 'primary identifier' isn't great. Maybe som= ething more like "to uniquely identify the version of the module"= or similar.
>
> Jason
>
> > -----Original Message-----
> > From: J=C3=BCrgen Sch=C3=B6nw=C3=A4lder <jschoenwaelder@constr= uctor.university>
> > Sent: Wednesday, October 25, 2023 2:32 PM
> > To: Jason Sterne (Nokia) <jason.sterne@nokia.com>
> > Cc: netmod@i= etf.org
> > Subject: Re: [netmod] Updated Content of Module Versioning - T7 > > (Filename changes)
> >
> >
> > CAUTION: This is an external email. Please be very careful when c= licking
> > links or opening attachments. See the URL nok.it/ext for additional > > information.
> >
> >
> >
> > It needs to be clear that the existing text in section 5.2 remain= s
> > untouched.
> >
> >=C2=A0 =C2=A0 YANG modules and submodules are typically stored in = files, one
> >=C2=A0 =C2=A0 "module" or "submodule" statemen= t per file.=C2=A0 The name of the file
> >=C2=A0 =C2=A0 SHOULD be of the form:
> >
> >=C2=A0 =C2=A0 =C2=A0 module-or-submodule-name ['@' revisio= n-date] ( '.yang' / '.yin' )
> >
> >=C2=A0 =C2=A0 "module-or-submodule-name" is the name of = the module or submodule,
> >=C2=A0 =C2=A0 and the optional "revision-date" is the la= test revision of the module
> >=C2=A0 =C2=A0 or submodule, as defined by the "revision"= statement (Section 7.1.9).
> >
> > Words like 'primary identifier' confuse me.
> >
> > /js
> >
> > On Wed, Oct 25, 2023 at 06:22:57PM +0000, Jason Sterne (Nokia) wr= ote:
> > > Hi all,
> > >
> > > Starting a dedicated thread for T7 Filename changes.
> > >
> > > These are my own personal opinions (not those of the
> > authors/contributors).
> > >
> > > RFC7950 says that the filename format SHOULD be my-module@20= 23-01-
> > 06.yang<mailto:my-module@2023-01-06.yang>
> > >
> > > Module versioning currently says the following format is REC= OMMENDED
> > (if the file has a revision label):=C2=A0 my-module#3.1.2.yang > > >
> > > I'd recommend we remove that from Module Versioning, but= add it to the
> > YANG Semver draft (where all revision label text will be located = - it is all
> > being removed from Module Versioning).
> > >
> > > We could potentially say it more like this:
> > >
> > >=C2=A0 =C2=A0If a revision has an associated yang-semver-labe= l, and if the publisher
> > >=C2=A0 wishes to use the label in the filename as the primary= identifier for the
> > >=C2=A0 version of the module instead of the revision date, th= en it is
> > >=C2=A0 =C2=A0RECOMMENDED to put the yang-semver-label into th= e filename as
> > follows:
> > >
> > >=C2=A0 =C2=A0 =C2=A0 module-or-submodule-name ['#' ya= ng-semver-label] ( '.yang' / '.yin' )
> > >
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 E.g., acme-router-module#2.0.3.ya= ng
> > >
> > >=C2=A0 =C2=A0YANG module (or submodule) files may be identifi= ed using either the
> > >=C2=A0 =C2=A0revision-date (as per [RFC8407] section 3.2) or = the revision label.
> > >
> > > If we don't at least have a recommendation (*if* people = really want to put
> > the label in the filename), then we might have different organiza= tions using
> > different formats:
> > >
> > >=C2=A0 =C2=A0*=C2=A0 =C2=A0org #1:=C2=A0 =C2=A0my-module@2.0.= 3.yang<mailto:= my-module@2.0.3.yang>
> > >=C2=A0 =C2=A0*=C2=A0 =C2=A0org#2:=C2=A0 =C2=A0 my-module#2.0.= 3@2023-01-06.yang<mailto:my-
> > module#2.0.3@2023-01-06.yang>
> > >=C2=A0 =C2=A0*=C2=A0 =C2=A0org#3:=C2=A0 =C2=A0 my-module%2.0.= 3.yang
> > >=C2=A0 =C2=A0*=C2=A0 =C2=A0org#4:=C2=A0 =C2=A0 my-module(2.0.= 3).yang
> > >
> > > I'm trying to find wording that doesn't strongly man= date the my-
> > module#2.0.3.yang filename format, but does highly recommend it *= if*
> > someone is going to put a label in the filename somewhere.
> > >
> > > Jason
> > >
> > >
> > > From: netmod <netmod-bounces@ietf.org> On Behalf Of Jason Sterne=
> > (Nokia)
> > > Sent: Tuesday, October 24, 2023 9:58 AM
> > > To: net= mod@ietf.org
> > > Subject: [netmod] Updated Content of Module Versioning
> > >
> > > Hello NETMOD WG,
> > >
> > > The YANG versioning authors and weekly call group members ha= ve been
> > discussing the next steps for the versioning drafts.
> > >
> > > We'd propose that the first step is to converge on what = aspects of the
> > current Module Versioning draft should be retained, and which par= ts should
> > be removed. We can then work towards a final call on an updated v= ersion
> > with this revised scope.
> > >
> > > Below is a summary of the main topics in the Module Versioni= ng draft.
> > We've divided the items T1-T10 into 2 groups:
> > > A) Baseline content of Module Versioning
> > > B) Items which need more WG discussion
> > >
> > > In addition to whatever discussions happen on this email lis= t, we have also
> > created a hedgedoc where you can register your preference for ite= ms T7-
> > T10. It would be much appreciated if you can put your opinion in = the
> > hedgedoc here:
> > > https://notes.ietf.org/CdKrT5kVSF6q= bnRSY4KeSA?both
> > >
> > >
> > > GROUP A (Baseline content of Module Vesioning)
> > > ------------------------------------------------------------= -----
> > > Based on resolution of WG LC comments and subsequent discuss= ions, and
> > some feedback to reduce complexity and content in the Module Vers= ioning
> > draft, here is a summary of items that will and won't be part= of the next
> > update of the Module Versioning draft (also referred to as "= this draft"
> > below).
> > >
> > > T1. The "ver:non-backwards-compatible" annotation = (Sec 3.2):
> > > Retained. This top level (module level) extension (which can= be ignored by
> > tools that don't understand it) is critical to include so tha= t module readers
> > and tools can know when NBC changes have occurred.
> > >
> > > T2. Updated rules of what is NBC: (Sect 3.1.1, 3.1.2)
> > > Retained. These are updates/clarifications (i.e., changes) t= o the RFC 7950
> > rules that are appropriate and helpful:
> > > (i) "status obsolete"
> > >=C2=A0 =C2=A0- This draft changes RFC 7950 so that marking a = data node as obsolete is
> > an NBC change because it can break clients.
> > > (ii) "extensions"
> > >=C2=A0 =C2=A0- This draft changes the RFC 7950 rules to allow= extensions to define the
> > backwards compatibility considerations for the extension itself.= =C2=A0 The existing
> > RFC 7950 rules only allow extensions to be added, not changed or = removed.
> > > (iii) "import by revision-date"
> > >=C2=A0 =C2=A0- This draft changes the RFC 7950 rules to allow= the revision date of an
> > import-statement to be changed/added/removed.=C2=A0 The imported = module
> > must be versioned separately (i.e., by a YANG package/library def= ining the
> > schema).
> > > (iv)=C2=A0 "whitespace":
> > >=C2=A0 =C2=A0- This draft clarifies the existing RFC 7950 beh= aviour that changing
> > insignificant whitespace is classified as a backwards compatible = change
> > >
> > > T3. revision-label-scheme extension (Sec 3.4.2)
> > > Removed. Based on WG LC discussions we will go back to a sin= gle
> > versioning scheme for YANG modules, and hence the revision-label-= scheme
> > extension will be removed from this draft.
> > >
> > > T4. revision-label extension (Sec 3.4)
> > > Removed. Related to T3 above, given that a single versioning= scheme is
> > sufficient, the revision-label extension will be moved to the YAN= G Semver
> > draft, and removed from Module Versioning.
> > >
> > > T5. Resolving ambiguous imports in YANG library (Sec 5.1) > > > Removed. This will be removed from Module Versioning (could = be
> > considered in YANG Next, although that is many years away).=C2=A0= Note, RFC
> > 7950, section 5.6.5, paragraph 5 does consistently define how to = build the
> > schema.=C2=A0 The change in the draft was to always prioritise an= implemented
> > module over the most recent implemented *or* import-only revision= . But
> > this will be removed.
> > >
> > > T6. Advertisement for how deprecated & obsolete nodes ar= e handled (Sec
> > 5.2.2)
> > > Retained. This information is important for clients to be ab= le to accurately
> > construct the schema and hence it is retained in Module Versionin= g.
> > >
> > > GROUP B (Needs WG discussion)
> > > -------------------------------------------
> > > For these items we don't have consensus within the WG - = they need more
> > discussion and input.
> > >
> > > It is recommended to go back and look at the NETMOD emails o= n these
> > topics (from the WG LC discussions).
> > >
> > > Please add your name beside your preferred option in the pol= l:
> > https://notes.ietf.org/CdKrT5kVSF6qbnRSY= 4KeSA?both
> > >
> > > T7. filename changes (Sec 3.4.1)
> > > The authors/contributors are leaning towards suggesting that= this moved
> > change be moved to YANG Next consideration.=C2=A0 However, there = isn't
> > complete consensus, with concerns that the vendors will each defi= ne their
> > own incompatible file naming schemes for YANG modules that use ve= rsion
> > numbers.=C2=A0 If we retain this work then this would likely move= to the YANG
> > Semver draft.
> > > [See hedgedoc poll T7]
> > >
> > > T8. recommended-min for imports (Sec 4)
> > > The WG seems to be somewhat split on how urgent this is, and= there isn't
> > consensus amongst authors/contributors for retaining this work or=
> > deferring it. One option is to keep it, but renamed as recommende= d-min-
> > date.
> > > [See hedgedoc poll T8]
> > >
> > > T9. Versioning of YANG instance data (Sec 6)
> > > There wasn't any consensus among the authors/contributor= s as to
> > whether this should be retained or deferred to a new version of t= he YANG
> > instance data document.
> > > [See hedgedoc poll T9]
> > >
> > > T10. Do *all* whitespace changes (including whitespace betwe= en
> > statements) require a new revision to be published? Sec 3.1, last= paragraph.
> > > The authors/contributors are somewhat split on whether to re= tain this.
> > The advantage of keeping this is that it makes it very easy to ch= eck (i.e., via a
> > simple text diff tool) whether two modules pertaining to be the s= ame
> > version are in fact the same.=C2=A0 It should also mean that it i= s easy to generate
> > a hash-based fingerprint of a module revision.=C2=A0 The alternat= ive gives more
> > flexibility to users to reformat modules (e.g., for different lin= e-lengths), but
> > complicates the check to ensure that a YANG module revision hasn&= #39;t been
> > changed or makes it slightly more expensive to generate a hash si= nce the
> > module formatting would need to be normalized first.
> > > [See hedgedoc poll T10]
> > >
> > > Jason (he/him)
> > >
> >
> > > _______________________________________________
> > > netmod mailing list
> > > netmod@= ietf.org
> > > https://www.ietf.org/mailman/listinfo/net= mod
> >
> >
> > --
> > J=C3=BCrgen Sch=C3=B6nw=C3=A4lder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Constructor University Bremen gGmbH
> > Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus R= ing 1 | 28759 Bremen | Germany
> > Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0<https://constructor.university/>

--
J=C3=BCrgen Sch=C3=B6nw=C3=A4lder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 Constructor University Bremen gGmbH
Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28= 759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://constructor.university/>

_______________________________________________
netmod mailing list
netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
--00000000000096aa7b0608904c67--