Re: [netmod] YANG Versioning: Key Issue #1 - Allow NBC changes in YANG 1.0 & YANG 1.1 or not?
Andy Bierman <andy@yumaworks.com> Mon, 24 July 2023 00:45 UTC
Return-Path: <andy@yumaworks.com>
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 4A8B4C151093 for <netmod@ietfa.amsl.com>; Sun, 23 Jul 2023 17:45:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 OTUxbrQYBDRk for <netmod@ietfa.amsl.com>; Sun, 23 Jul 2023 17:45:35 -0700 (PDT)
Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (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 EA7E6C15108E for <netmod@ietf.org>; Sun, 23 Jul 2023 17:45:34 -0700 (PDT)
Received: by mail-lf1-x12e.google.com with SMTP id 2adb3069b0e04-4fb863edcb6so5513016e87.0 for <netmod@ietf.org>; Sun, 23 Jul 2023 17:45:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks.com; s=google; t=1690159533; x=1690764333; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=JMV4NK0d7DDzpTt0eOP/lRb2y1HBH3Z1MzKFMhqbQE0=; b=fs0dmehrbNzTGQ9cCoxxB82xuWJQstA9M8IcJjB9/dGRA0yds2OH96wkIw41I+0tgL 2Jd7oCHXSx7KBpaONl26sqEsLRCSVADz+5cvs1TAjJodwQWDJLCbP/ME0aN1XYGG+ih4 QO2rE8dnoOWjEOwtqdjQApASpVDzQdP+m2n047Adk+Kst6Ak7VTFE+ansiNIuuOKf9Oa 2hp7ekAcYbQ8aE4GOeirqFtUqxzGV1DIxLPw8GuwL6nsfi5IhWZn4Mvbyo4xzSHWn3a0 r0WNan42IFHLra+e7Hebb27W5L3YKHVCQdKNhLUiZA7bEKscnWsouCyjxk9e8svqe1tw ybtQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690159533; x=1690764333; h=cc: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=JMV4NK0d7DDzpTt0eOP/lRb2y1HBH3Z1MzKFMhqbQE0=; b=PTl/Nf4OgptPGrETm2HMEGypSSiH6INxPtc4LXiPKan2oaMH6P+bC8COx8GzF9kiTP A3rk4KtNiTh1wj74IB6wDVnGXTwyMhvinD2io5v7BRTlwQUbqdSdso9939TbZIeRHa8H DkIokVChjvgFMfSOEqeZd9wIxvSzqRNEJYLL/lJ6vjmQoZFB4BlEbYJYKDzOUmCUM8fZ tu6S7vWdUFbaAbnm1Iy08q6fJLlbjkdkxpQs0lb8fRJosMmMpoiUhPeI1oYiXlPUcdOU LAfOqesJ61YTL/PP2EFUCT2So9SEHFIsScOmdVEQE9QIeh2ix3cvRUWxN18kmPox/rtb Nsew==
X-Gm-Message-State: ABy/qLZ3yreDeRBF6D9ncIkqYLMWhe0bJ/p1DCB280RJ6bFaBgmfJ676 ByEmwWUM+eToTT30CzMTzVRYUeIITY3Y2ppqjYNpSg==
X-Google-Smtp-Source: APBJJlEu5m69XYDMg6nV6rVkLNADtpWK6Go9D7D2HRPk4mJ/ASf7xNx7iBPyC4+s2l2VWiKoZfLUkW0y3UwgRbGSRLM=
X-Received: by 2002:a05:6512:74a:b0:4f8:418e:1e49 with SMTP id c10-20020a056512074a00b004f8418e1e49mr4215079lfs.16.1690159532593; Sun, 23 Jul 2023 17:45:32 -0700 (PDT)
MIME-Version: 1.0
References: <DM6PR08MB5084CA2A7EAF55F67D8851D19B3BA@DM6PR08MB5084.namprd08.prod.outlook.com> <20230718.134758.2206037224145407934.id@4668.se> <CABCOCHSRbTfwTHHK3q3U-8GSBvK9x0epjyKWphtmO3cR+xFefQ@mail.gmail.com> <DM6PR08MB5084BEA071F353F785F4CEF19B39A@DM6PR08MB5084.namprd08.prod.outlook.com> <CABCOCHTUP7AtZADb9=MqkxNofJzA9cfoQt0JtifwjFxpu7FkJw@mail.gmail.com> <PAWPR07MB927493670E8F9158D8638736F002A@PAWPR07MB9274.eurprd07.prod.outlook.com>
In-Reply-To: <PAWPR07MB927493670E8F9158D8638736F002A@PAWPR07MB9274.eurprd07.prod.outlook.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Sun, 23 Jul 2023 17:45:21 -0700
Message-ID: <CABCOCHSjuX55FRYCv9Jo8EhA7hP1+cm5S1bcdgkrYtrLa6UW5A@mail.gmail.com>
To: Balázs Lengyel <balazs.lengyel@ericsson.com>
Cc: "Jason Sterne (Nokia)" <jason.sterne@nokia.com>, "netmod@ietf.org" <netmod@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000008deca8060130ee78"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/HzsM9HmPdhsG2jUubYv7Vkchf_o>
Subject: Re: [netmod] YANG Versioning: Key Issue #1 - Allow NBC changes in YANG 1.0 & YANG 1.1 or not?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Jul 2023 00:45:39 -0000
Hi, OLD: A new module revision MAY contain NBC changes, e.g., the semantics of an existing data-node definition MAY be changed in an NBC manner without requiring a new data-node definition with a new identifier. NEW: A new module revision SHOULD NOT contain NBC changes, e.g., the semantics of an existing data-node definition SHOULD NOT be changed in an NBC manner without requiring a new data-node definition with a new identifier. This allows Option 4 since SHOULD NOT will require an exception review to get an RFC published. Andy On Sun, Jul 23, 2023 at 5:11 PM Balázs Lengyel <balazs.lengyel@ericsson.com> wrote: > Hello, > > I am writing this as > > - Balazs Lengyel one of the authors, but also as > > - an Ericsson guy and also as > > - a delegate of 3GPP, which requested a better versioning scheme in a > reasonably > > fast timeline. 3GPP represents both vendors and operators, so in this > last > > role I am sitting on both side of the fence. > > I strongly support option 1 - modifying 7950 to allow NBC changes and > > introducing something like Semver. > > - We need this soon and the other alternatives will take a longer time. > > - we need it for the current YANG models too, not just for YANG 1.2 or 2 > models > > - We are already today doing backwards incompatible updates. We would like > to have > > that aligned with IETF. > > - as one of the authors I believe the work is ready and reasonably good > > - I believe adapting the tooling for a few new extensions is much less > work > > than adapting to a new YANG version > > Option 2 will take a long time to specify, implement and roll out. During > this time > > other non-standard solutions will proliferate; messy solutions, like just > > ignoring the current RFC7950 rules, will be used more and more. > > Option 3 just ignores the real world. > > NBC changes are happening. There are SDOs that value speed over final > quality > > and role out a new version of the modules every few months. These can not > > live without some NBC changes. > > A more fine grained versioning system is required. > > > > Regards Balazs > > > > *From:* netmod <netmod-bounces@ietf.org> *On Behalf Of *Andy Bierman > *Sent:* Thursday, 20 July, 2023 18:52 > *To:* Jason Sterne (Nokia) <jason.sterne@nokia.com> > *Cc:* netmod@ietf.org > *Subject:* Re: [netmod] YANG Versioning: Key Issue #1 - Allow NBC changes > in YANG 1.0 & YANG 1.1 or not? > > > > > > > > On Wed, Jul 19, 2023 at 1:13 PM Jason Sterne (Nokia) < > jason.sterne@nokia.com> wrote: > > We considered this approach as well in the weekly calls but in the end > felt that was just dodging the problem. We have a set of “MUST” rules that > we know need to occasionally be broken. Shouldn’t we officialize this so > our behavior and documents match? (i.e. SHOULD NOT instead of MUST)? > > > > It isn’t just an IETF issue. These same exceptions occur in vendor models, > 3GPP, etc. There are times when making the NBC change is the reasonable way > to go. > > > > > > > https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-module-versioning#name-updating-a-yang-module-with > > > > I do not support these changes in any version of YANG. > > The advice to the community is non-specific and obviously not backward > compatible with RFC 7950. > > The new advice is that any change at all in a YANG module is now allowed. > > Instead of normative rules, RFC 7950 simply advises whether the optional > 'non-backwards-compatible' extension could be applied or not. > > This is not a good change, especially on top of YANG 1.1. > > > > I could see if specific MUST NOT rules were changed to SHOULD NOT instead. > > A blank check using the current "MAY" (3.1, para 2) is not a good idea. > > > > > > Jason > > > > Andy > > > > > > *From:* Andy Bierman <andy@yumaworks.com> > *Sent:* Wednesday, July 19, 2023 1:13 PM > *To:* Martin Björklund <mbj+ietf@4668.se> > *Cc:* Jason Sterne (Nokia) <jason.sterne@nokia.com>; netmod@ietf.org > *Subject:* Re: [netmod] YANG Versioning: Key Issue #1 - Allow NBC changes > in YANG 1.0 & YANG 1.1 or not? > > > > > > *CAUTION:* This is an external email. Please be very careful when > clicking links or opening attachments. See the URL nok.it/ext > <https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-688efc90f7cb3f03&q=1&e=d73d3aee-48a4-4fe9-b81b-56650cfeb8c6&u=http%3A%2F%2Fnok.it%2Fext> > for additional information. > > > > > > > > On Tue, Jul 18, 2023 at 4:48 AM Martin Björklund <mbj+ietf@4668.se> wrote: > > What about Option 4 - Pragmatic Adherence to Current RFC7950 Rules > > > > > > This is the approach I also suggested on the mailing list. > > > > - As it works today; the IETF *has* published bugfixed modules that break > the > rules. (and many vendors do this as well) > - (Possibly) Introduce rev:non-backwards-compatible > > This would allow 6991bis to update date-and-time to follow the updated > semantics for RFC3339 timestamps (which imo is the only reasonable > thing to do - the consuequences of this change is handled by SEDATE). > > > > > > The important thing in each case is to consider > > the expected impact on the real world and real deployments. > > > > IMO a bugfix should be OK, even if the rules in RFC 7950 say it is an NBC > change. > > But this is not the same thing as changing the rules in a new document to > shift the > > implementation burden to the client. > > > > This is only an IETF issue and the burden should be on a WG to convince > the IESG and IETF > > that making the NBC change is a bugfix and should be allowed as a special > case. > > > > > > > /martin > > > > Andy > > > > > "Jason Sterne (Nokia)" <jason.sterne@nokia.com> wrote: > > Hi all, > > > > At the request of the NETMOD chairs, and on behalf of the YANG > Versioning weekly call group, here's a summary of Key Issue #1 for the > versioning work (i.e. for the Module Versioning and YANG Semver WGLC). > > > > We'd like to suggest that the WG has a strong focus on deciding on this > specific issue first. Then we'll move on to tackle other key issues. The > idea is to try and avoid getting tangled in a web of multiple intertwined > issues. > > > > Key Issue #1 is the following: Allow NBC changes in YANG 1.0 & YANG 1.1 > or not? > > > > For now please avoid debating other issues in this thread (e.g. multiple > vs single label schemes, whether YANG semver is a good scheme, etc). Let's > focus on K1 and work towards a WG decision. > > > > ################################### > > K1) Allow NBC changes in YANG 1.0 & YANG 1.1 or not? > > > > Option 1 - Update RFC7950 to Allow NBC Changes > > ----------------------------------------------------------------------- > > - Module Versioning modifies 7950 to allow NBC changes > > - guidance that NBC changes SHOULD NOT be done (impact to user base) > > - rev:non-backwards-compatible is a YANG extension > > - introduction in published YANG does not impact current tooling > (ignored until recognized) > > PROS: > > - address fundamental requirement of this versioning work (requirements > doc) > > - allows gradual adoption in the industry. YANG authors can immeditately > start publishing with the new extensions. > > - move faster to produce modules in the IETF (accept some > errors/iteration) > > - address the liaison from external standards bodies in a reasonable > timeframe > > - authors believe work is ready > > - broad vendor support > > - rough alignment with OpenConfig (use YANG 1.0 + OC Semver) > > CONS: > > - perception that we're "cheating" by not bumping our own spec's version > > - Not fundamentally mandatory for clients or servers using YANG > (mandatory for YANG claiming conformance to Module Versioning). > > > > Option 2 - RFC7950-bis: Publish a new version of the YANG language to > allow NBC changes > > ----------------------------------------------------------------------- > > - NBC changes only allowed in a new (future) version of YANG > > - TBD: YANG 1.2 vs 2.0 (note YANG 1.1 isn't BC with YANG 1.0) > > - Content = Module Versioning + YANG Semver + very limited YANG NEXT > items > > - rev:non-backwards-compatible tag is a language keyword > > - consequence: any use of it breaks all YANG 1.0/1.1 tooling that > hasn't been updated > > - TBD how to handle small NBC changes in IETF in the short term (i.e. > non conformance to 7950)? > > - RFC6991 bis - change the use/meaning of ip-address (or change > datetime) > > - YANG date-and-time (because of SEDATE date string > changes) > > > > PROS: > > - address fundamental requirement of this versioning work (requirements > doc) > > - clear delineation of changes in the YANG language > > - consistent with philosophy that version number changes for significant > changes in a spec (avoids concern that YANG is changing without bumping the > version of YANG) > > - can do this with mandatory YANG keywords which helps increase > conformance to the new rules > > CONS: > > - difficult to roll out in the industry. Tools need upgrading before > they won't error on a YANG 1.2 module. > > - Authors can't publish YANG 1.2 until their users have upgraded their > tools. Everyone has to move at once. > > - likely large delay in producing the work (unclear what would go into > YANG 1.2, may not reach concensus easily on N items) > > - delay in follow up work (Packages, Schema Comparison, Version > Selection) > > - continue dominating WG effort for longer (opportunity cost) > > > > Option 3 - Strict Adherence to Current RFC7950 Rules > > ----------------------------------------------------------------------- > > - IESG will be unable to approve any RFCs that make any changes to IETF > YANG modules that don't strictly conform to those rules > > - RFC6991 bis would not be allowed to change the use/meaning of > ip-address (or change datetime) > > - YANG date-and-time couldn't change (related to SEDATE > date string changes) > > PROS: > > - clear rules for entire industry including IETF > > CONS: > > - doesn't address agreed/adopted requirements of YANG versioning work > > - incorrect assumption in tool chains, etc that NBC changes don't > happen. Silent failures. > > > > Jason (he/him) > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > >
- [netmod] YANG Versioning: Key Issue #1 - Allow NB… Jason Sterne (Nokia)
- Re: [netmod] YANG Versioning: Key Issue #1 - Allo… Jürgen Schönwälder
- Re: [netmod] YANG Versioning: Key Issue #1 - Allo… Jason Sterne (Nokia)
- Re: [netmod] YANG Versioning: Key Issue #1 - Allo… Lou Berger
- Re: [netmod] YANG Versioning: Key Issue #1 - Allo… Italo Busi
- Re: [netmod] YANG Versioning: Key Issue #1 - Allo… Martin Björklund
- Re: [netmod] YANG Versioning: Key Issue #1 - Allo… Rob Wilton (rwilton)
- Re: [netmod] YANG Versioning: Key Issue #1 - Allo… Rob Wilton (rwilton)
- Re: [netmod] YANG Versioning: Key Issue #1 - Allo… Andy Bierman
- Re: [netmod] YANG Versioning: Key Issue #1 - Allo… Jason Sterne (Nokia)
- Re: [netmod] YANG Versioning: Key Issue #1 - Allo… Andy Bierman
- Re: [netmod] YANG Versioning: Key Issue #1 - Allo… Balázs Lengyel
- Re: [netmod] YANG Versioning: Key Issue #1 - Allo… Balázs Lengyel
- Re: [netmod] YANG Versioning: Key Issue #1 - Allo… Andy Bierman
- Re: [netmod] YANG Versioning: Key Issue #1 - Allo… Andy Bierman
- Re: [netmod] YANG Versioning: Key Issue #1 - Allo… Balázs Lengyel
- Re: [netmod] YANG Versioning: Key Issue #1 - Allo… Christian Hopps
- Re: [netmod] YANG Versioning: Key Issue #1 - Allo… Andy Bierman
- Re: [netmod] YANG Versioning: Key Issue #1 - Allo… Scott Mansfield