Thanks for the review, Tony. After discussion with the authors and Mahesh (and a delay due to IETF 125 and some time off), we’ve published revision -25 to address some of your comments. See below.
The intent of this document is sound. However, the solution presented here is not, IMHO, operationally tractable. The amount of complexity introduced with _COMPAT when combined with SemVer semantics is extremely high and will cause mass confusion in the field. Operators do not aspire to be semanticists. They need a simple and straightforward mechism that even the most junior operator can comprehend. [JMC] The need for this limited branching is part of the YANG versioning requirements (https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-versioning-reqs/). While this branching is not needed for IETF work, vendors and groups like OpenConfig will need it, and this branching is not supported by basic SemVer. Over the years, we’ve considered other options, but this was the least complex. That said, we agree that the instructions for IETF development wasn’t as clear, so we added some clarity to revision -25. ## Major Issues > Section 1 contains a reference to [SemVer] which is a link to a github document. I have a concern about the long term stability of this reference. Github is only stable as long as its parent company deems it to be worthwhile and profitable. While that seems reliable in the near term, that does not seem guaranteed in perpetuity. We need an archival quality source. I would feel much more comfortable if this reference was an RFC. Given that it is key semantics (pun intended) for this document, it should also be a Proposed Standard and a normative reference. [JMC] We have raised this ti Mahesh, and we’ll work with the RFC Editor to see if the best place for this reference is another appendix in the document itself or on the IETF wiki. Given that it is informational (since this document explains the rules of YANG Semver), we do not see the need for SemVer to be its own RFC. > Section 2 illustrates a branched version history. Operational experience with software release versioning that has followed a similar pattern is mixed, at best. Operations are greatly simplified when we avoid branching. Yes, it is sometimes inevitable, but it deserves to be avoided, whenever possible. We need to remind them that branching is considered harmful. [JMC] We do recommend thinking about branching (to avoid it) and how one can do that. We agree that branching is to ideal, and that the IETF should generally avoid this. > Section 4.3: The entire COMPAT field seems redundant. The whole purpose of the versioning in [SemVer] is to define what is and is not compatible. This is therefore very confusing. [JMC] SemVer alone does not address the limited branching requirement (and we’ve stated this more clearly in -25). > Section 6.1.2.1: The rules in this section seem somewhat unclear. As stated, versioning MUST be applied retroactively to all previous versions. The initial version is 1.0.0, and then things should follow the SemVer rules. This implies that someone must go along and make compatibility assessments of all previous versions and assign major, minor, and patch numbers to all previous versions. This seems like it is fraught with potential error and not particularly productive. Could we adopt a simpler scheme where the new revision is always version 1.0.0? Even arbitrary version numbering to previous versions would, if properly documented, be a simpler approach. [JMC] We have a separate document with added tooling enhancements to help IANA properly apply this versioning: https://datatracker.ietf.org/doc/draft-ietf-netmod-iana-yang-guidance/ --- ## Minor Issues > Section 4.3: Why are we using signed integers? Are we planning on negative versions? [JMC] The text states that each version component MUST be non-negative. Moreover, these are not used by themselves. They are part of a YANG Semver string, which is guaranteed to be non-negative overall. We chose signed because some languages that may parse these strings prefer signed by default (e.g., Java). > Section 6.1.3: Given the pre-release naming, why does the first draft get special privileges? Why not require that all drafts append the draft name? [JMC] We wanted to keep things as simple as possible while still having versions be unique. In many cases there will not be competing drafts, and thus the metadata can be simplified. There isn’t normative language that prevents the full draft name from being included, but if it is not needed, it can be left off for brevity. Joe ---
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
