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

[Andy Bierman <[e-mail]>]

On Wed, Jun 7, 2023 at 12:22 AM Martin Björklund <[e-mail]> wrote:

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

We started out with the "grouping drift" problem.
That led to "import-by-revision" in YANG 1.1.
These drafts attempt to fix that.
The "min-revision" for an import is an improvement over "exact revision".

Problem 2)

Sometimes, after considering all options, breaking YANG Update rules is
the least bad option. The versioning draft attempts to fix that problem,

Problem with Problem 1)

Attempting to solve the "max revision" problem is much harder than
"min-version".
A revision-label for every identifier in every module would be impossible
to manage or use.
A single revision-label for the entire module is usually way too simple and
not useful.
Importing the latest release without incrementing the major-release number
sounds like it helps, but most of the time, using the real 'latest' will
work even better.

IMO complex lifecycle issues require resource-level support (like HTTP has)
built into the protocol. For starters, NETCONF needs to support warnings.
This would allow the server to send deprecation (and other) warnings
and other metadata at the resource level.


Problem with Problem 2)

RFC 7950 is quite clear that extensions MAY be ignored
and the yang-version field determines which specification is used for the
module.
Any tool that supports YANG 1.1 is not expected
to handle module changes that the RFC says MUST NOT be done.

Updating the rules to say that the MUST NOT is replaced with MAY means
that all YANG 1.1 tools MUST support NBC changes.  This is a big change
that should require a new yang-version.

IMO changing the official module update rules is not really needed.
It should be OK for a WG to make an NBC change to a published module,
if the consensus is that this is the least bad solution and better than
starting over with a new identifier, then just document that and allow the
NBC change.

This would be an interim solution until YANG 1.2 is done in the future.



Apart from the updates to RFC 7950 section 11, I am mostly concerned
> about the additional complexity the "pluggable" revision-label scheme
> brings.
>


Agreed.  Why isn't YANG Semver good enough for now?



>
>
>
>
> /martin
>


Andy


>
>
>
>
> "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
>