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-boun...@ietf.org> On Behalf Of Jürgen Schönwälder > Sent: 06 June 2023 06:07 > To: Martin Björklund <mbj+i...@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
