Hi,

I have been selected as the Operational Directorate (opsdir) reviewer
for this Internet-Draft.

The Operational Directorate reviews all operational and
management-related Internet-Drafts to ensure alignment with
operational best practices and that adequate operational
considerations are covered.

A complete set of _"Guidelines for Considering Operations and
Management in IETF Specifications"_ can be found at
https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5706bis/.

While these comments are primarily for the Operations and Management
Area Directors (Ops ADs), the authors should consider them alongside
other feedback received.


- Document: draft-ietf-netmod-yang-semver-24

- Reviewer: Tony Li

- Review Date: Feb. 27, 2026

- Intended Status: Proposed Standard

 
---

## Summary 

- Has Major Issues: I have significant concerns about this document and recommend that the OPS ADs discuss these issues further with the authors.

## General Operational Comments Alignment with RFC 5706bis 

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. 

## 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.

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

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

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

---

## Minor Issues 

> Section 4.3: Why are we using signed integers?  Are we planning on
  negative versions?

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

 
---