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

[Martin Björklund <[e-mail]>]

"Rob Wilton (rwilton)" <[e-mail]> wrote:
> Hi Martin,
> 
> > -----Original Message-----
> > From: netmod <[e-mail]> On Behalf Of Martin Björklund
> > Sent: 07 June 2023 08:22
> > To: rwilton=[e-mail]
> > Cc: [e-mail]
> > Subject: Re: [netmod] Joint WGLC on "semver" and "module-versioning"
> > drafts
> > 
> > Hi,
> > 
> > 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.
> 
> 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.

I'm not sure that I have changed my mind on this topic (but if I have
I view that as a good thing; it means I'm open to new technical
arguments ;-)

I don't think I have ever said that this is important work.  I can
live with optional extension statements that indicate nbc changes, and
even that another optional revision label scheme is used, but I do
think it adds unnecessary complexity.  I do not like "modified
semver", and I see no reason why the current revision-date based
scheme doesn't work for IETF modules.



/martin



>   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