Hi Joe, authors, and NETMOD WG, Thanks for your patience and for -27 revised I-D.
What is "IPv6", I only like IPv[^46] of course 😉 (The above is a joke replying to Joe's joke -- if this was not obvious to the reader). See below for EV2> In short, as a non-English reader, I still find the rules in section 4.5 *very hard* to read even if they are sensible. I do not have alternative text though except rather than using a sequence of rules, using a set of rules based on the changes (e.g., non-compatible breaking changes, feature addition changes either compatible or not, ...) In short, I will blame my lack of English mastering and change my position to ABSTAIN (as I find this section too hard to read to ballot a NoObjection). Regards -éric From: Joe Clarke (jclarke) <[email protected]> Date: Saturday, 27 June 2026 at 12:31 To: Eric Vyncke (evyncke) <[email protected]>; The IESG <[email protected]> Cc: [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]> Subject: Re: Éric Vyncke's Discuss on draft-ietf-netmod-yang-semver-26: (with DISCUSS and COMMENT) That’s it Éric. No IPv6 for you in Vienna! 😃 Thanks for the follow-up. I tend to agree with one of your points, but I want to explain some other things. See below. ### Section 4.5 In rule #1, the first "SHOULD" has a "unless", but why is the 2nd one not a "MUST" in `in which case the artifact version "X.Y.Z+1_non_compatible" SHOULD be used instead` ? I am unable to fully understand the rule #2.i `unless that version has already been used for this artifact but with different content, when the artifact version SHOULD be updated ` (which also has a SHOULD without the required IESG guidance per https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/ ) The part that I do not understand is the use of "when" in the sentence. EV> 2.i text is easier to understand, so, this part is addressed. There are also too many "SHOULD" without any guidance, i.e., why not using "MUST" then ? [JMC] We made a clarification to one of the SHOULDs with a change to MUST in another place. We also added a normative sentence on when to use MAJOR or the _COMPAT modifier. Does this help? EV> the I-D is improved with the changes but not completely though EV> the added sentence `An artifact author MAY choose a more significant MAJOR...` would work *IF* it started with "Otherwise, an artefact... MUST choose .... described in section XYZ` EV> (it is unclear where the description is). [JMC2] Good catch, and I agree the current wording leaves that sentence a bit squishy. We will tie it to the OPTIONAL rules that already appear later in the same section, and promote the collision-case fallback to a MUST so it matches rule 2. What about: OLD: 1. If an artifact is being updated in a non-backwards-compatible way, then the artifact version "X.Y.Z[_compatible|_non_compatible]" SHOULD be updated to "X+1.0.0". If "X+1.0.0" has already been used for this artifact but with different content, the artifact version "X.Y.Z+1_non_compatible" SHOULD be used instead. An artifact author MAY choose a more significant MAJOR component update, as described later in this section. NEW: 1. If an artifact is being updated in a non-backwards-compatible way, then the artifact version "X.Y.Z[_compatible|_non_compatible]" SHOULD be updated to "X+1.0.0". If "X+1.0.0" has already been used for this artifact but with different content, then the artifact version "X.Y.Z+1_non_compatible" MUST be used instead. An artifact author MAY instead choose a more significant update than the minimum described here, following the OPTIONAL rules later in this section. [JMC2] The "OPTIONAL rules later in this section" is the existing block that begins "Although artifacts SHOULD be updated according to the rules above ... the following rules MAY be applied when choosing a new version identifier". That is where the more-significant-update options are described, so this makes the pointer concrete. That clear the DISCUSS? EV2> much better text EV2> the last sentence of rule #1 could be removed to simplify the text. EV2> I find the mix of REQUIRED/OPTIONAL in the text *very* confusing.... ### Section 6 Why not a "MUST" in `SHOULD begin with a 0` ? [JMC] Mainly because we didn’t want to be overly aggressive to YANG-producing organizations outside of the IETF. We offer the alternate form of pre-release versioning as a MAY to be generally compatible with vendor or other SDOs proclivities. EV> While I now better understand the concept, I must say that the text is overly complex. EV> Also, should there be a "MUST NOT start with a value > 1” ? [JMC2] We would prefer not to add that constraint, and I don't think it is needed. For new IETF modules, Section 6.1.1 already mandates starting with a 0 MAJOR component, so the IETF case is fully constrained. For modules developed outside the IETF (think OpenConfig and our own as examples), the choice of initial MAJOR version carries no interoperability consequence. A vendor or another SDO that wants to start a brand new module at 1.0.0-PRE-RELEASE (or even 1+X.0.0-PRE-RELEASE) is free to do so, and nothing downstream breaks, because the import and comparison rules in Sections 4.5 and 5.2 operate on the relative ordering of versions and not on any assumption about a starting value. Prohibiting this here with a normative MUST NOT would restrict authors we intentionally chose to leave flexible, without buying any technical value in return. [JMC2] As for the “overly complex” text, yeah. Maybe. This section has to cover both the 0 MAJOR scheme and the pre-release alternative, which is inherently a bit involved, and the WG has iterated on this wording over a long period. If you have a specific sentence or paragraph that you think can untangle this some, I am happy to take a targeted pass at that one spot. I would prefer not to restructure the whole section this late, since the substance has WG consensus, but I don't want to leave it harder to read than it needs to be. EV2> we indeed agree that the text is overly complex... EV2> I won't DISCUSS this point anymore, but suggest replacing the `This allows the module... during its initial development` by "Else the module won't be able to disregard...", which would better explain the consequences of not using 0 for the MAJOR component. Joe
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
