Hello Joe, Thanks for your reply. I have looked at the proposed changes, but I am afraid that I still have issues with the I-D.
See below for EV> for more details. Regards -éric From: Joe Clarke (jclarke) <[email protected]> Date: Wednesday, 24 June 2026 at 12:16 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) Thanks for the review, Éric. We’ve created a proposed revision, and I’m hosting the side-by-side diff at https://www.marcuscom.com/draft-ietf-netmod-yang-semver.diff.html as well as attaching it here. ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- # Éric Vyncke INT AD comments for draft-ietf-netmod-yang-semver-26 CC @evyncke Thank you for the work put into this document. Please find below some blocking DISCUSS points (easy to address), some non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education). Special thanks to Lou Berger for the shepherd's detailed write-up including the WG consensus and the justification of the intended status and the large number of authors. I hope that this review helps to improve the document, Regards, -éric Note: this ballot comments follow the Markdown syntax of https://github.com/mnot/ietf-comments/tree/main, i.e., they can be processed by a tool to create github issues. ## DISCUSS (blocking) As noted in https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/, a DISCUSS ballot is a request to have a discussion on the points below; I really think that the document would be improved with a change here, but can be convinced otherwise. ### 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). ### 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" ? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- EV> thanks for addressing them ## COMMENTS (non-blocking) ### Section 4.5 `The following four rules specify` is actually followed by 5 rules ;-) [JMC] Fixed with some added clarity as well. ### Section 4.6 Suggest to add a graphical representation (e.g., the trees used in the beginning of this I-D). [JMC] Added! Joe
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
