Hi Deb, A couple of quick comments, one of which also applies to the module versioning draft, inline ...
On 2 Jun 2026, at 14:52, Deb Cooley via Datatracker <[email protected]> wrote: Deb Cooley has entered the following ballot position for draft-ietf-netmod-yang-semver-26: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-semver/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks to David Mandelberg for their secdir review. Also thanks to Tony Li for their opsdir review. Section 2: I think what the authors call 'branched revision history' of Yang modules, is what I would refer to a fork in code/s/w development. It doesn't often go well for s/w development, but maybe Yang modules are different. I certainly don't know enough about how Yang is actually used to tell. RW: At the end of day, vendors ship software for networking devices and in some deployments (e.g., particularly ISPs) those software versions may expect to be running on devices for many years. Sometimes there will be functional bugs that need fixing (or even minor feature enhancements), and those bug fixes occasionally require new forked versions of YANG modules for those releases. Semver, which is the solution that the market wants, is ideal for open source software projects when you can always force the clients to move to the latest version of the software if there is an API change, but cannot reliably express that branched history. So the industry really has four choices: 1. Inform the customer that you can't (or won't) fix the issue due to the Semver versioning rules. 2. Inform the customer that they must upgrade to the latest version of the software to fix the issue, which may also require them to buy new hardware, if the software version isn't supported on the older harder. 3. Lie/cheat with the Semver versioning numbers. I.e., use a version number that classifies it as an editorial change when in fact it is actually an API breaking change that may break client automation and tools. 4. Introduce the additional complexity of the _COMPAT modifier but try to limit its use as much as possible. I think that (1) and (2) are not realistic options. (3) is probably what is most likely to happen today but means that the versioning numbers end up being meaningless if you don't stick to the rules. Hence why we introduced (4) but also expect to lean heavily on tooling to help clients really understand the impacts of the changes to these APIs. It isn't the prettiest solution, but it was the only solution that we could come up with that met the requirements. It is also worth noting that as a vendor one always have the option of doing one of the other choices and avoiding the _COMPAT modifier. But really I think that the root of the issue is with the Semver concept itself - it pretends to make versioning very clean and simple - but I'm not convinced that the industry is always willing to accept the hard constraints that it requires to implement it properly/strictly. Kind regards, Rob Section 4.3: The addition of the _COMPAT to the end of the version number seems to make this super complicated, especially when you add what is documented in draft-ietf-netmod-yang-module-versioning with its NBC and BC terminology. Section 11, para 2: draft-ietf-tls-8446bis is in AUTH 48, it might make sense to use that vice RFC8446.
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
