Thanks to Marc Blanchet for the ARTART review.
Great to see this work finally making it to the finish line.

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.

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.

Thank you for the work that has been put into this document. I do not see any transport-protocol related concerns.
Gorry

Thanks to the authors and the WG for this important work to handle this very fundamental challenge in maintenance of YANG modules.

# IESG review of draft-ietf-netmod-yang-semver-26

CC @MikeBishop

## Comments

### Previous DISCUSS

Thank you for the discussion about the intended uses of this; my original DISCUSS was based on a few misunderstandings. Notably, I missed this restriction:

> There MUST NOT be multiple versions of a YANG artifact that have the same
> MAJOR, MINOR and PATCH version numbers, but different patch modifier strings.
> E.g., artifact version "1.2.3_non_compatible" MUST NOT be defined if artifact
> version "1.2.3" has already been defined.

...and its implication that all versions are minted by (or at least coordinated with) the same source.

While I still think that the inability to identify which version is the parent of another version will cause confusion, my preference for a different approach is not DISCUSS-worthy.

### Section 4.3, paragraph 4

"MUST only" is potentially ambiguous. Does it mean "MUST be present if COMPAT is
present and MUST NOT be present otherwise? If so, consider a single optional element
that MUST begin with the character '_' as a cleaner way to express this.

### Section 4.4, paragraph 12

What does one do with "can indicate" here? Either it indicates this, or
it indicates many things including this. If many things, what is the scope
of things it indicates?

### Section 4.4.3, paragraph 4
```
     software development.  It is recommended to avoid only incrementing
     the PATCH digit on the main branch of YANG modules.  See Appendix B
     Scenario 2 for an illustration and explanation.
```
This says that changes on the main branch should alter more than the PATCH
number, but your example seems to argue for the exact opposite. Should this
instead say "It is recommended that only the main branch of YANG modules
increment the PATCH number"? Or am I misunderstanding?

### Section 5.2, paragraph 15

For the reasons stated here, I'm slightly surprised there's not a
corresponding max-version, in case there's a breaking change which the current
module doesn't yet support.

### Section 6.1.2.1, paragraph 1
```
     For example, if a module or submodule started out in the pre-NMDA
     ([RFC8342] ) world, and then had NMDA support added without removing
     any legacy "state" branches -- and you are looking to add additional
     new features -- a sensible choice for the target YANG Semver would be
     1.2.0 (since 1.0.0 would have been the initial, pre-NMDA release, and
     1.1.0 would have been the NMDA revision).
```
This can probably be reworded to remove the "world" terminology and the use of
the second-person.

### Too many authors

The document has six authors, which exceeds the recommended author limit. Has
the sponsoring AD agreed that this is appropriate?

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Typos

#### Section 1, paragraph 1
```
-    [I-D.ietf-netmod-yang-module-versioning] puts forth new concepts
-                                                       -------------
-    relating to modified rules for updating YANG modules and submodules,
-   ------------
```

#### Section 1, paragraph 2
```
-    The goal being to add a human readable version identifier that
-      --------- ^^^^^            ^
+    This adds a human-readable version identifier that
+       ^    +        ^
```

### Outdated references

Document references `draft-clacla-netmod-yang-model-update-06`, but `-26` is
the latest available revision.

### Grammar/style

#### Section 4.4.1, paragraph 1
```
 the versions could look like, from oldest version to newest: 0.1.0 - first p
                                    ^^^^^^
```
A determiner may be missing.

#### Section 4.6.2, paragraph 2
```
s section and the IETF-specific sub-section below provide YANG Semver-specif
                                ^^^^^^^^^^^
```
This word is normally spelled as one.

Thank you to Gyan Mishra for the GENART review.

Thank you for addressing my DISCUSS and COMMENT ballot feedback.