Great to see this work finally making it to the finish line.

My understanding is that support been added to YANG validators (e.g., YANG Catalog, pyang, yanglint) to support the "rev:non-backwards-compatible" extension statement. Is that correct? I ask because I believe it is important that support exists, but in regard to implementation status, the shepherds writeup says, "This is YANG Module.  Implementation status is unknown."

Sorry for putting in the review for a different draft the first time round.

Thanks for the draft on a clearly tricky issue.  There's never a perfect answer when it comes to versioning and dependencies.

I support the comments from Mike, Roman, and Deb on this draft,

Section 3, para 2:  I think what the authors call 'non-linear development' 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 modules are actually used to tell.

Section 8.2:  draft-ietf-tls-8446bis is in AUTH48, it might make sense to use that vice RFC8446.

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

Since this has been already pointed out by some other ADs, I will avoid repeating, but would appreciate if the referenced documents that are published as RFCs are updated. Most importantly, please fix the following:

1.2. Editorial Note (To be removed by RFC Editor)
Note to the RFC Editor: This section is to be removed prior to publication.

This document updates [I-D.ietf-netmod-rfc8407bis]. The header metadata for this document should be updated to the new RFC number when [I-D.ietf-netmod-rfc8407bis] is published.

I hope this is all taken care of before the IESG approves this document.

## Previous DISCUSS

Thank you for following up over e-mail. I'm summarizing what I understand the resolution to be here:

## Discuss

### Section 5.1, paragraph 1
```
     The ietf-yang-library-status YANG module augments YANG library with
     two boolean leafs to allow a server to report how it implements
     status "deprecated" and status "obsolete" schema nodes.  The leafs
     are:
```
This text is intended to increase client certainty, rather than muddy the waters.
If servers indicate that deprecated nodes are supported in general, they will also
need to explicitly indicate (through deviations) nodes that it does not support.
Servers that indicate they do not generally support obsolete schema nodes could
still do so for certain nodes.

### Section 5.1, paragraph 4

Clients will need access to both module versions they're comparing, but don't
need to know anything about intervening versions to make this comparison.

### Section 6.2, paragraph 2
```
     *  Clients SHOULD be liberal when processing data received from a
        server.  For example, the server may have increased the range of
        an operational node causing the client to receive a value which is
        outside the range of the YANG model revision it was coded against.
```

I'm still very cautious about this text. The argument given is "eventual consistency,"
which is to say that there may be disagreement between data indicated in various nodes
or from various sources due to differences in perspective. However, that's a different
beast from tolerating values which are invalid per the schema of the module.

At a minimum, I'd like there to be some improved text focusing the scope of this. If
a server is using a schema which is not backwards-compatible to the version the client
is using, it might expect the possibility for changes in ranges, etc., etc. Clients
need to exercise particular caution about buffer overruns, etc.

## Comments

### Section 4.1, paragraph 7
```
        Adding, modifying or removing a "recommended-min-date" extension
        statement is a BC change.
```
Is this because compliance is optional? Otherwise, I'd think changing a minimum
version on a dependency would be a potentially-breaking change; a dependent
module which matched the old version would no longer match, and you don't know
whether there were breaking changes between those versions.

### Section 6.2, paragraph 3
```
     *  Clients SHOULD monitor changes to published YANG modules through
        their revision history, and use appropriate tooling to understand
        the specific changes between module revision.  In particular,
        clients SHOULD NOT migrate to NBC revisions of a module without
        understanding any potential impact of the specific NBC changes.

     *  Clients SHOULD plan to make changes to match published status
        changes.  When a node's status changes from "current" to
        "deprecated", clients SHOULD plan to stop using that node in a
        timely fashion.  When a node's status changes to "obsolete",
        clients MUST stop using that node.
```
This seems less about client behavior and more about developer behavior. The
required feature on clients is an update mechanism, because changes will be
necessary over time.

### Section 9.2, paragraph 5
```
     For published IANA maintained YANG modules that contain non-
     backwards-compatible changes between revisions, a new revision should
     be published with the "rev:non-backwards-compatible" substatement
     retrospectively added to any revisions containing non-backwards-
     compatible changes.
```
Has IANA confirmed it's capable of generating that list? This seems like a
potentially large order. Also, presumably this is suggesting a single new
revision wherein the document's revision history is modified, not making
retrospective changes to the older revisions themselves.

## 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 2
```
-    if they are impacted by changes between the revisions.  The
-                                                          -----
```

#### Section 1, paragraph 2
```
-    [I-D.ietf-netmod-yang-semver] document defines a YANG extension that
-                                   ---------
```

#### Section 1, paragraph 2
```
-    versioning.  YANG packages [I-D.ietf-netmod-yang-packages] provides a
-                                                                      -
```

#### Section 3, paragraph 6
```
-    packages [I-D.ietf-netmod-yang-packages], and YANG library [RFC8525],
-                                            -                           -
```

#### Section 6.1.1, paragraph 2
```
-        Section 4.7 of [I-D.ietf-netmod-rfc8407bis]), instead the status
-                                                    ^ ^
+        Section 4.7 of [I-D.ietf-netmod-rfc8407bis]). Instead, the status
+                                                    ^ ^      +
```

#### Section 6.1.1, paragraph 7
```
-    See Appendix B for examples on how NBC changes can be made.
-                                 ^
+    See Appendix B for examples of how NBC changes can be made.
+                                 ^
```

### Section 6.1, paragraph 9

Why introduce a bulleted list of one item? This could be "For example,
if a..."

### Outdated references

Document references `draft-ietf-netmod-RFC8407bis`, but that has been published
as `RFC9907`.

Reference `[I-D.ietf-netmod-rfc6991-bis]` to `RFC6991`, which was obsoleted by
`RFC9911` (this may be on purpose).

Document references `draft-ietf-netmod-RFC6991-bis`, but that has been
published as `RFC9911`.

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

### Grammar/style

#### "a/an" NBC

Is NBC pronounced "non-breaking change" or "enn-bee-cee"? This affects whether
a/an is the appropriate article. Pick one and check that you're consistent throughout.

#### Section 3.4, paragraph 4
```
he importing module, and hence section Section 6.1 suggests that authors do n
                               ^^^^^^^^^^^^^^^
```
Possible typo: you repeated a word.

#### Section 10.1, paragraph 8
```
nd the "description" updated. This is a NBC change. B.2. Changing the type o
                                      ^
```

#### Section 10.1, paragraph 6
```
remental approach described in section Section 6.1.1. The examples are all f
                               ^^^^^^^^^^^^^^^
```
Possible typo: you repeated a word.

#### "Appendix A.", paragraph 1
```
remental approach described in section Section 6.1.1 can not be followed. Th
                               ^^^^^^^^^^^^^^^
```
Possible typo: you repeated a word.

I support the Discuss ballots of both Mike and Roman. Otherwise, I believe this is a useful document with helpful levels of detail and examples for non-YANG experts that explain why we need this.