Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts

[tom petch <[e-mail]>]

From: netmod <[e-mail]> on behalf of Rob Wilton (rwilton) <rwilton=[e-mail]>
Sent: 13 June 2023 17:25

Hi Martin,

> -----Original Message-----
> From: netmod <[e-mail]> On Behalf Of Martin Björklund
> Sent: 07 June 2023 08:22
>
> But the two drafts go way beyond fixing the problem your three
> examples illustrate.
[Rob Wilton (rwilton)]

The actual goals of this work (i.e., the set of drafts) is aiming to address the requirements stated here: https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-versioning-reqs-07.  Although never taken to RFC, I believe was effectively last called and achieved WG consensus for the NETMOD WG.  Hopefully the chairs can chime in and keep me honest if I'm wrong on this point.

<tp>
May be or may be not but there is no such I-D in the datatracker for NETMOD nor can it be downloaded from the FTP site so effectively there are no requirements to justify this substantial change.  Based on what I can access, the module versioning I-D does not look like a good idea.

Tom Petch

The shape/structure/content of the drafts is very similar to when these documents were adopted in March 2020:

Your comments on these document at adoption time are here (https://mailarchive.ietf.org/arch/msg/netmod/r5TD0NDNgUbtX9EHZfB5hJJctN8/).  From that email, it is clear that you didn't support the YANG Semver scheme, but my reading is that you were broadly supportive of the YANG module versioning draft.

Here are your review comments of the YANG module versioning draft at adoption time:
https://mailarchive.ietf.org/arch/msg/netmod/MTGomxcdyNOmB7mgsFhItLKNJgk/

Here is a thread where you are discussing supporting different revision label schemes:
https://mailarchive.ietf.org/arch/msg/netmod/cEBiZKUSk0n7BeFwdiyaejc_Tsg/

I appreciate that everyone has the right to change their mind at any point, but as stated previously, I don't think that the shape of the solution has really changed substantially since they were adopted.


  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).

That is one goal.  Another is to acknowledge that non-backwards-compatible changes will occur, potentially even on branches.  Another is to align with the versioning scheme that is being broadly used by the industry (but with extensions to support a branched history).


>
> Apart from the updates to RFC 7950 section 11, I am mostly concerned
> about the additional complexity the "pluggable" revision-label scheme
> brings.
[Rob Wilton (rwilton)]

It feels like we are somewhat going in circles:

1.The original proposal was to embed regular Semver 2.0.0 for the version numbers.

2. That scheme was extended to what is being labelled as "Yang Semver" because regular Semver didn't support some level of branching that the vendors require to support customers on older releases over a much longer time period.  Semver 2.0.0 works best when the updates are always committed to the head of a linear sequence of versions, and if a bug needs to be fixed in an older version then the user is forced to migrate to the latest version.

3. If I recall correctly, you didn't like YANG Semver (and possibly not even Semver), and if I also recall correctly from a conversation then I think that it is because you envisaged more advanced branching schemes and perhaps a version number scheme that follows branch history (and hence cannot also contain semantic meaning).  Based on that feedback, and an in-person side meeting, we moved to a revision label scheme, an nbc-marker, and standardizing a versioning scheme to fit into the revision-label scheme separately.  This was all in place when these documents were adopted.

Based on those who are or have participated in the weekly calls, I also believe that the solution has reasonable industry support:
 - Representatives from Cisco, Ericsson, Huawei, Juniper, Nokia have all participated in the calls at various stages.
 - Other SDOs (3GPP at least, and ITU?) are waiting for this work.
 - OpenConfig is using Semver and has been for years.  I don't know if they will adopt IETF's particular solution, but I do think that we would at least be fairly aligned.

I want to find a way that we can just get this work finished and published so that the authors and WG can move on to other, hopefully more interesting, stuff.

Is the solution perfect?  No, but engineering solutions never are.

Is the solution good enough?  I believe so, yes.

Regards,
Rob

// As an author and participant in this work for 5+ years.


>
>
>
>
> /martin
>
>
>
>
> "Rob Wilton \(rwilton\)" <rwilton=[e-mail]> 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 <[e-mail]> On Behalf Of Jürgen
> Schönwälder
> > > Sent: 06 June 2023 06:07
> > > To: Martin Björklund <[e-mail]>
> > > Cc: [e-mail]
> > > 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: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> > > Fax:   [phone]         <https://constructor.university/>
> > >
> > > _______________________________________________
> > > netmod mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/netmod
> > _______________________________________________
> > netmod mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/netmod
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/netmod