Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts
Martin Björklund <mbj+ietf@4668.se> Wed, 07 June 2023 07:22 UTC
Return-Path: <mbj+ietf@4668.se>
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 99825C15107F for <netmod@ietfa.amsl.com>; Wed, 7 Jun 2023 00:22:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.796
X-Spam-Level:
X-Spam-Status: No, score=-2.796 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=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=4668.se header.b="Lh09meu8"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="wuGKoABx"
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 LdbemkSMOSd7 for <netmod@ietfa.amsl.com>; Wed, 7 Jun 2023 00:22:07 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 62E87C15106D for <netmod@ietf.org>; Wed, 7 Jun 2023 00:22:05 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id E8FC95C0124; Wed, 7 Jun 2023 03:22:04 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Wed, 07 Jun 2023 03:22:04 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=4668.se; h=cc:cc :content-transfer-encoding:content-type:content-type:date:date :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm2; t= 1686122524; x=1686208924; bh=JU1wB34nKq/n3doGQeFt3E64SsYq0kQfkFY znyRyYtQ=; b=Lh09meu8nGkMyTrYtE7EeGLa1CXhi4WaLP5bK2bslFgPL3yKRQX FZskg7sdYPib3DKn6ewDSExntxb57HGISFWV2twWRcWhmJBLz1lrd0TqRa2iXxMA vjkDyxJdstNEfPLc6eFQSuWHUzbyEBrnykWfTOxAYSjw2Cgk1VVglOgclfKeRKfk 6qnxU/ZQo6l6yKTn/bMrUpgXIRuM0LQvgSU4Pnr4Bspddb4HkSagqZO4qOZSQEB3 PYC6RZIu6J8iFqokPUEpoAmWBlmfvDSgKsejTKmjHZCg4mP03T+ULfobW8Wl23/0 ubGM2hvDmRRSgCRseOISheKTHo5ZaGlwhIg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1686122524; x=1686208924; bh=JU1wB34nKq/n3doGQeFt3E64SsYq0kQfkFY znyRyYtQ=; b=wuGKoABxwlaZDn6MWf3X/VNeuiC2oylG5P3x2zUr+xHXk0FcuGG 3hUWouZSUcorjTxPpJI8idSH09J+OAuvAz8q8n0z5EsSUx62c1kegKwI0PBKC3f7 691Jbtq+c9ozhbtI3m/2M+5eXG+yEPCAsayABZO3zHLP6LFOPBxPACvPwsAyvGoB /NEBeHW84HlPt5tDXo7VvKcjZNEQXFyooKPsQSGmRRfBQh/39xMn5q3Ub2DRekwj lPLB6JxCo1+uCpaS8nCrXX4i8EjPtMh0EZLE9W9FHCjbkD1Z/T/SfHRAziKzJBql +KNfeX6xTNodpoF9J0YGB466fvLL20dqUKA==
X-ME-Sender: <xms:HDCAZKA9snkj8sTUalnmvgoR2pXcVeAD501UrTfcUFsQ2zHf0qmXhA> <xme:HDCAZEgZuMt3j2Shwb_o5cnXFRBErNr9RwGubStzTyHXAUnLpjLMcOhn0QtsW2Vwj WOYNuhbgGCj_umMH_g>
X-ME-Received: <xmr:HDCAZNnL2dmgOgChc2eJwmJSuONLiAHnbBMSOgoN9BsM9L1c-U3mxm3L75PqFOvc25K0X83jRXFbTMkoUATBExPedkLF1QGxzA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrgedtfedgkeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffkffvvefuhfgjfhfogggtgfesth gsredtredtjeenucfhrhhomhepofgrrhhtihhnuceujhpnrhhklhhunhguuceomhgsjhdo ihgvthhfseegieeikedrshgvqeenucggtffrrghtthgvrhhnpefhfedvtdeifeffheduje dvieffheelgefggeeukedufffgkeegtdffleelgfetveenucffohhmrghinhepihgvthhf rdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomh epmhgsjhdoihgvthhfseegieeikedrshgv
X-ME-Proxy: <xmx:HDCAZIwt0M2pDlEQfyMvosyx7DAkMH8xlFOYYBiP19511uGR5qCUdA> <xmx:HDCAZPTw4ku6ZFv4pkLF_zRIL5o_5iy9AjLjucW_IknwgY6C7IPO9A> <xmx:HDCAZDZs8m2qhpPaFioAlnbpRPChPmNYZMDLtcqLX6uVy9UDts6H8g> <xmx:HDCAZA4rWcCWcs6wsrrKjoeSV7SpIFSs97nWd2MH9yOuXp60Rz8HIQ>
Feedback-ID: icc614784:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 7 Jun 2023 03:22:04 -0400 (EDT)
Date: Wed, 07 Jun 2023 09:22:01 +0200
Message-Id: <20230607.092201.152004661869529702.id@4668.se>
To: rwilton=40cisco.com@dmarc.ietf.org
Cc: netmod@ietf.org
From: Martin Björklund <mbj+ietf@4668.se>
In-Reply-To: <BY5PR11MB41966AE860E22466F8037B6DB552A@BY5PR11MB4196.namprd11.prod.outlook.com>
References: <20230605.223251.336974778999487126.id@4668.se> <ykghe2tzoe2rqzh3brfbsuvvhswi7fzul5ygfnokuyih4t4emo@kpnvucchbed5> <BY5PR11MB41966AE860E22466F8037B6DB552A@BY5PR11MB4196.namprd11.prod.outlook.com>
X-Mailer: Mew version 6.8 on Emacs 26.3
Mime-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/X3ZekNm9EHB1DRwo3kSwYfj0Z4U>
Subject: Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts
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: Wed, 07 Jun 2023 07:22:12 -0000
Hi, But the two drafts go way beyond fixing the problem your three examples illustrate. If the goal is to indicate that non-backwards compatible changes have occured, a single new extension statement could solve that. (As I probably have stated before, personally I don't think this is necessary). Apart from the updates to RFC 7950 section 11, I am mostly concerned about the additional complexity the "pluggable" revision-label scheme brings. /martin "Rob Wilton \(rwilton\)" <rwilton=40cisco.com@dmarc.ietf.org> wrote: > I'm wondering whether we are in the realm of missing the bigger > picture here, or perfection being the enemy of good enough. > > My first example: > > The sedate WG (https://datatracker.ietf.org/wg/sedate/about/) has > recently been rechartered to respecify the meaning of the date string > in a non-backwards compatible way. Yes, this same date string format > that is very widely implemented and deployed. I originally had a > block on the new charter until it was pointed out that the IETF > specification was being updated because it was inconsistent with the > ISO time specification and inconsistent with how the date string was > actually being used by implementations. I.e., the specification is > being updated to reflect reality. I.e., fixing the specification in a > non-backwards compatible way ends up being pragmatically the right > thing to do (and this is entirely allowed by the IETF process). > > Ideally, the date-and-time typedef in YANG would also be updated to > match the update to the definition in RFC 3339 by SEDATE. But this is > clearly not compliant with section 11 of RFC 7950 (because the value > space of allowed values is being narrowed). The only available choice > would be to define a new date-and-time-2 typedef which modules could > then update to. Of course, you cannot update the existing leaves to > use the new date-and-time-2 typedef because that also violates section > 11. So, you end up with two datetime leaves everywhere the > date-and-time typedef is used, hopefully with one deprecated (and at > some point, obsoleted). Of course, defining the new datetime version > leaves could also break any loosely related modules that may have > xpath expressions dependent on that date-time leaf (that the updating > module author may not even know about) which would need to be updated > to depend on either of the leaves. I also don't think that RFC 7950 > is clear about whether deprecated leaves must be implemented by all > implementations or not, so realistically clients will need to handle > setting either (or perhaps in some cases, both) of the datetime > leaves, depending on implementation, probably with a different mix > across modules (in vast stages of being updated). What happens if > some instances of those datetime leaves are mandatory configuration > and become obsolete? Is a client required to set it or not, the > pragmatic answer being that again RFC 7950 is unclear and again this > will likely be implementation dependent. What about if some of those > datetime leaves are list keys? I believe that the only solution that > RFC 7950 allows for would be to duplicate the list, deprecating the > old one, again requiring updates to all augmenting modules, and > corresponding impact and churn on clients and servers. > > I suspect that OpenConfig may also have a date-and-time typedef. I > can be certain about how they would handle this same issue - they will > just update the definition. Some clients/servers may have minor > impacts when they update to a new version of the model, but the impact > and effort required is minimal, and I think several orders of > magnitude less then the potential resultant churn than would happen by > strictly following the RFC 7950 section 11 rules. > > Some may argue that I'm not being pragmatic, and that this could just > be handled as a bugfix, changing the existing type. This is one of > the key things that the YANG versioning is trying to accomplish and > allow. It isn't aiming to say that module designers have carte blanch > to change modules in non-backwards compatible ways. Instead, it is > saying that in some cases, the pragmatic solution is to knowingly > break the RFC 7950 rules and make a breaking change because that > causes less impact. Further, a key aim of the versioning work is that > it is much better to be explicit that a breaking change has occurred > such that a client can easily be warned of that change and take any > mitigation necessary - which in the datetime instance above, is quite > possibly that no mitigation is required at all. > > Finally, I will note that rfc-6691-bis contains a change to the > datetime definition that is not backwards compatible with the existing > definition because the semantics of the leaf are being redefined. > > > A somewhat similar second example: > > The YANGs IP address type handling of zone information is very similar > to my first issue, where OpenConfig came to the pragmatic conclusion > that (in their models) 100% of the use cases of IP addresses only use > the numeric form without zone identifiers, and hence when someone sees > the typedef ip_address, this is what they are thinking of, so they > just pragmatically updated their definition of ip_address type. > > Somewhat related to this, I will note that rfc-6691-bis contains a > change to the ipv4-address and ipv6-address regex definition that is > not backwards compatible with the existing definition (it narrows the > valuespace for zone-ids restricting it to ASCII letters and digits > whereas previously it allowed for any language letters or digit > characters). I believe that this change is not strictly compatible > with RFC 7950 section 11, but I still think that this is the > pragmatically right change to make without introducing a new set of IP > address types, despite the fact that it could hypothetically break > some clients/servers, and we have no way of knowing in advance if that > will happen. > > > A third consideration: > > Yesterday, Jeff and Mahesh presented in a NETMOD interim on their > learnings from trying to write the IETF BGP model. One of their > outcomes is that they think that some of the other models recently > standardized by the IETF don’t interoperate well with the BGP model > and will need to be revised. I've no idea whether those changes can > all be made cleanly in a backwards compatible way, but I suspect not. > Hence, my concern here is that the IETF doesn't really have a great > path to getting a viable set of YANG models that work together, > because just publishing modules working in isolation doesn't solve the > industry problems. > > Because lots of the IETF YANG models have been written without a lot > of implementation experience (chicken and egg problem), often my > people who know the protocols but are not experts on YANG, means that > we can be sure that there are likely to be many bugs and flaws in the > YANG module RFCs that will need to be fixed or improved. I would > expect that some of these cannot be pragmatically fixed in a backwards > compatible way. > > --- > > My interpretation of the recent last call review comments is the > suggestion that we pivot to find a fundamentally different solution or > approach to solving this problem as an RFC7950bis. I believe that > would be a mistake. > > In summary, a group of participants have been diligently working on > this problem space for 5+ years. > > We have had a design team working on this area, and that solution was > then adopted by the WG. The authors and interested individuals > working on this area has presented updated drafts and updates to the > work at every IETF meeting for the last, 4+ years. Feedback at the > various stages/reviews/etc has always been considered, the authors > meetings have always been open, and I don't believe that the solution > drafts being taken to WG LC are architecturally significantly > different from the direction agreed during WG adoption of the > documents, although I do think that the documents are much improved > based on the feedback received. > > I also appreciate that Juergen has always publicly stated that this > work should be done as an update to the YANG language, but my > recollection was that he was in the rough on this issue, i.e., during > WG adoption, and since, at least until this IETF WG LC review. > > Hence, my concern, as an AD, is that if, after 5 years, the WG now > wants to take a fundamentally different path to standardizing this > work then I have concerns that the NETMOD WG isn't really functioning > properly and cohesively as a WG, and I'm very concerned that we won't > find any viable way forward for this work. I doubt that it will be > possible to get any quick consensus by opening up RFC 7950. We may > also find that the individuals who have invested a significant amount > of time and effort on this work don't have the desire or energy to > start from scratch again, when they have a solution that is good > enough for their needs. > > If I understand correctly, the fundamental objection to the module > versioning draft is around the updates to section 11 of RFC 7950, > which effectively state that changes MUST be backwards compatible, > whereas this draft states SHOULD be backwards compatible, without a > change to the YANG version number. Is that correct? > > If the existing deployment and evolution of YANG modules among > vendors, OpenConfig, IETF, and other SDOs strictly followed the rules > in RFC 7950 then I would probably agree that an update from YANG 1.1 > to YANG 1.2 is needed. But I think that the reality is that tools > must handle non-backwards compatible changes frequently happening in > YANG 1.0 (OpenConfig) and YANG 1.1 YANG modules anyway. I.e., I don't > believe that the "YANG 1.1 no breaking change contract" is being > widely honoured anyway, and instead is being treated as a goal or > aspiration. What these documents attempt to do is to move YANG module > evolution from what we currently have now where clients don't have any > way of really knowing how a module has evolved and whether they are > impacted to one that they do, and as part of that process they are > aiming to update the YANG versioning rules to better reflect how is it > being deployed and used. > > Hence, as am author, I still of the opinion that the best pragmatic > path forward is to try and get these documents to a shape where they > achieve rough consensus and are acceptable to the WG to be published > now, in the short term, as a good enough solution. After that point, > then I think that it would be great for some folks to form an idea on > a what YANG 1.2/2.0 could look like, but I think that coupling these > goals together would be a mistake. > > Regards, > Rob > > // Who doesn't really know which hat he is wearing for this comment, > but is only trying to do the right thing for the wider industry ... > > > > -----Original Message----- > > From: netmod <netmod-bounces@ietf.org> On Behalf Of Jürgen Schönwälder > > Sent: 06 June 2023 06:07 > > To: Martin Björklund <mbj+ietf@4668.se> > > Cc: netmod@ietf.org > > Subject: Re: [netmod] Joint WGLC on "semver" and "module-versioning" > > drafts > > > > On Mon, Jun 05, 2023 at 10:32:51PM +0200, Martin Björklund wrote: > > > > > > > > If the goal is to produce YANG 1.2 which (i) integrates semantic > > > > versioning into YANG and (ii) fixes known bugs in YANG 1.1 and (iii) > > > > does not add any other new features, then having agreement on such a > > > > statement will help to steer the process. > > > > > > I hope that (i) doesn't happen. I think it is the proposed changes in > > > draft-ietf-netmod-yang-module-versioning that require a new YANG > > > version. If this new YANG version allows for other versioning schemes > > > than revision-date, then we can keep the modified semver scheme > > > outside the core document. > > > > > > > I consider the module update rules a part of a versioning model. The > > current update rules were written to support the current versioning > > model. If we want to support multiple versioning models, then we have > > to refactor the update rules out of the YANG language specification > > into separate versioning specifications, i.e., traditional YANG > > versioning and the new semver versioning. There are some language > > mechanisms (like the import statement), that have to be flexible > > enough to support multiple versioning schemes. > > > > Is it worth factoring the versioning model out of the language? I > > guess the opinions vary widely on this, depending on the dynamics of > > the software environment people are working in. > > > > /js > > > > -- > > Jürgen Schönwälder Constructor University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 <https://constructor.university/> > > > > _______________________________________________ > > 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
- [netmod] Joint WGLC on "semver" and "module-versi… Kent Watsen
- Re: [netmod] Joint WGLC on "semver" and "module-v… Robert Varga
- Re: [netmod] Joint WGLC on "semver" and "module-v… Alex Huang Feng
- Re: [netmod] Joint WGLC on "semver" and "module-v… Kent Watsen
- Re: [netmod] Joint WGLC on "semver" and "module-v… Andy Bierman
- [netmod] 答复: Joint WGLC on "semver" and "module-v… Fengchong (frank)
- [netmod] YANG filenames in module versioning Jason Sterne (Nokia)
- Re: [netmod] Joint WGLC on "semver" and "module-v… Joe Clarke (jclarke)
- Re: [netmod] Joint WGLC on "semver" and "module-v… Jürgen Schönwälder
- Re: [netmod] YANG filenames in module versioning Robert Varga
- Re: [netmod] Joint WGLC on "semver" and "module-v… Robert Varga
- Re: [netmod] Joint WGLC on "semver" and "module-v… Andy Bierman
- Re: [netmod] Joint WGLC on "semver" and "module-v… Jürgen Schönwälder
- Re: [netmod] Joint WGLC on "semver" and "module-v… Andy Bierman
- Re: [netmod] Joint WGLC on "semver" and "module-v… Andy Bierman
- Re: [netmod] Joint WGLC on "semver" and "module-v… Robert Varga
- Re: [netmod] Joint WGLC on "semver" and "module-v… Robert Varga
- Re: [netmod] Joint WGLC on "semver" and "module-v… Jürgen Schönwälder
- Re: [netmod] Joint WGLC on "semver" and "module-v… Kent Watsen
- Re: [netmod] Joint WGLC on "semver" and "module-v… Andy Bierman
- Re: [netmod] Joint WGLC on "semver" and "module-v… Carsten Bormann
- Re: [netmod] Joint WGLC on "semver" and "module-v… Jürgen Schönwälder
- Re: [netmod] Joint WGLC on "semver" and "module-v… tom petch
- Re: [netmod] Joint WGLC on "semver" and "module-v… Carsten Bormann
- Re: [netmod] Joint WGLC on "semver" and "module-v… Martin Björklund
- Re: [netmod] Joint WGLC on "semver" and "module-v… Kent Watsen
- Re: [netmod] Joint WGLC on "semver" and "module-v… Jürgen Schönwälder
- Re: [netmod] Joint WGLC on "semver" and "module-v… Andy Bierman
- Re: [netmod] Joint WGLC on "semver" and "module-v… Martin Björklund
- Re: [netmod] Joint WGLC on "semver" and "module-v… Jürgen Schönwälder
- Re: [netmod] Joint WGLC on "semver" and "module-v… Rob Wilton (rwilton)
- Re: [netmod] Joint WGLC on "semver" and "module-v… Martin Björklund
- Re: [netmod] Joint WGLC on "semver" and "module-v… tom petch
- Re: [netmod] Joint WGLC on "semver" and "module-v… Andy Bierman
- Re: [netmod] Joint WGLC on "semver" and "module-v… Joe Clarke (jclarke)
- Re: [netmod] Joint WGLC on "semver" and "module-v… Jürgen Schönwälder
- Re: [netmod] Joint WGLC on "semver" and "module-v… Robert Varga
- Re: [netmod] Joint WGLC on "semver" and "module-v… Ladislav Lhotka
- Re: [netmod] Joint WGLC on "semver" and "module-v… Jason Sterne (Nokia)
- Re: [netmod] Joint WGLC on "semver" and "module-v… Rob Wilton (rwilton)
- Re: [netmod] Joint WGLC on "semver" and "module-v… Andy Bierman
- Re: [netmod] Joint WGLC on "semver" and "module-v… Jason Sterne (Nokia)
- Re: [netmod] Joint WGLC on "semver" and "module-v… Andy Bierman
- Re: [netmod] Joint WGLC on "semver" and "module-v… Joe Clarke (jclarke)
- Re: [netmod] Joint WGLC on "semver" and "module-v… Jürgen Schönwälder
- Re: [netmod] Joint WGLC on "semver" and "module-v… Jürgen Schönwälder
- Re: [netmod] Joint WGLC on "semver" and "module-v… Martin Björklund
- Re: [netmod] Joint WGLC on "semver" and "module-v… Andy Bierman
- Re: [netmod] Joint WGLC on "semver" and "module-v… tom petch
- Re: [netmod] Joint WGLC on "semver" and "module-v… Rob Wilton (rwilton)
- Re: [netmod] Joint WGLC on "semver" and "module-v… tom petch
- Re: [netmod] Joint WGLC on "semver" and "module-v… Rob Wilton (rwilton)
- Re: [netmod] Joint WGLC on "semver" and "module-v… Robert Varga
- Re: [netmod] Joint WGLC on "semver" and "module-v… Kent Watsen