Updated YANG Module Revision Handling
draft-ietf-netmod-yang-module-versioning-17

[Ballot comment]
## 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.

[Ballot comment]
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.

[Ballot comment]
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,

[Ballot discuss]
Thank you to the editors/authors for the very interesting versioning document.  It exposes, yet again, how hard versioning is.

(Just a quick note on the comments themselves, the `####` indicate the section of the document for the comment(s); it makes a lot more sense in my markdown tool that I use to write the notes during review.)

#### 4.4

In section 4.4 that `_COMPAT` tag, once applied cannot be removed.  But there is not clause refining that statement; I believe this is the pertinent line in the draft text:
```
The modifier can change from "_compatible" to "_non_compatible" in a subsequent version, but the modifier MUST NOT change from "_non_compatible" to "_compatible" and MUST NOT be removed.
```
Does this mean that if I have version `2.3.2_compatible` that I release 3.0, that it has to be `3.0.0_compatible`?  Does that make sense?  Or by virtue of understanding the major release number in SemVer (and YANG Semver) that 3.0 is incompatible, and therefore it must be `3.0.0_non_compatible`?  I’m not sure if that is what is intended.  (this could possibly be related to defining the different components of the version number as “Major Version”, for example, but talking about compatible/non-compatible in terms of “revision”.

This text, which I believe isn’t sufficiently clear, doesn’t align with the example given in 4.4.2.

#### 4.4.2

* why doesn’t version ‘0.2.0’ have a `_non_compatible` suffix attached?  Does that not violate 4.4?
* Also, I see no reason the rule as stated in 4.4 with regards to ‘_COMPAT’ would not compel ‘1.0.0’ to have ‘_non_compatible’ attached; even though I expect this is not what is intended.

#### 4.5

* Rule 2: Can you clarify what the “backward-compatible” means and against what it should be measured for this rule?  (Major revison?  This means you have taken away a functionality present in X.0.0? (renamed, removed, etc.))
* Rule 4: This conflicts with the `MUST` in 4.4 - please resolve.
* I don’t know what this statement means, but it includes a ‘MUST’:
  ```
  If a revision entry in a module's revision history includes the "rev:non-backwards-compatible" statement then that MUST be reflected in any YANG semantic version associated with that revision.
  ```
  reflected how?  With a ‘_COMPAT’ statement? But only for changes that aren’t MAJOR Version?

#### 6.1.2.1

Who is the target of the “MUST” to retroactively apply YANG Semver to existing modules?  That’s not a process or protocol MUST, but an IANA MUST?

[Ballot comment]
Thanks to Joel H. for the GENART review.  Thanks to Lou B. for the shepherd write up, it was insightful for the WG discussions.

#### 4.4.2

* I will note that in 4.4.2 you use `NBC` and `BC`.  NBC *is* defined in the Introduction as “non-backwards-compatible (NBC)”; there is no such definition of BC, which I would presume is “backwards-compatible”.  Might be good if the the reader didn’t have to presume.
* This example produces a good example of a question that I’ve been having: what information does `_compatible` convey?  It patch version is assumed to be compatible unless marked `_non_compatible` right?  I don’t believe it conveys any additional information in the naming of a release.

#### 4.4.3

* This section should get mentioned in the definition of ‘_COMPAT’ in 4.4. e.g.
``` The _COMPAT modifier applies to versions within a MAJOR Version and indicates that a release in X.Y.Z marked with ‘_non_compatible’ indicates that the release is incompatible with first release of X, notionaly X.0.0.  At every MAJOR release, the '_COMPAT' modifier MUST be removed.```
* Is my understanding of what this section indicates as the following correct?
```
Because of branching and its limitations to express compatibility, fundamentally, any release in X.?.? will have all capabilities and interfaces from X.0.0; but incompatibilities may still exist between available compatibilities in X.a.? and X.b.? where 'a' and 'b' may have different functional *additions* to X.0.0.
```

#### 4.5

* What are the exceptions to the ‘SHOULD’ in rule 1?
* Why are there *5* rules in a section desribing the *four* rules?  Maybe rule 5 should be a statement before the 4 rules?

#### 4.6

* I don’t entirely know how to read the example (also, not a YANG expert) but I will note that it appears to me to document the future.  It is version 1.1, but knows that 1.2.2 will be incompatible.

#### 5.2

Rules 1 & 2 aren’t needed are they?  Also, specifying X.Y.Z with Z being anything other than ‘0’ is also pointless because of rule 3, right?  Unless those rules rules, as listed, are in priority order.

[Ballot discuss]
** Section 9.2
  In all cases, IANA MUST follow the versioning guidance specified in
  Section 3.1, and MUST include a "rev:non-backwards-compatible"
  substatement to the latest revision statement whenever an IANA
  maintained module is updated in a non-backwards-compatible way, as
  described in Section 3.2.

Please do not use BCP14 keywords in IANA considerations text.  See https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/

IANA note: we understand that the language concerning IANA-maintained modules will be updated to make underlying registry updates the trigger for versioning, as in the yang-semver document (although versioning can be applied earlier).

IANA update: we missed an IANA Considerations issue. The yang-semver document gives us the following instructions in Section 12.2:

"Note: For IANA maintained YANG modules and submodules that have already been published, versions MUST be retroactively applied to all existing revisions when the next new revision is created, starting at version "1.0.0" for the initial published revision, and then incrementing according to the YANG Semver rules specified in Section 4.5."

However, this document's Section 9.2 appears to state that we should do this for all IANA-maintained YANG modules immediately, leaving out the "when the next new revision is created" clause:

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

I should add that we believe we'll need to hold off on any versioning-related updates to IANA-maintained modules until the IESG can approve the yang-guidance document, but once that's approved, we'll still need the versioning and semver documents to provide the same timing requirements.

Practically speaking, for SLA reasons, we have a strong preference for being permitted to implement versioning gradually, with a requirement that no new revisions be published without it. We understand that this would mean that we would still be able to introduce versioning before a registry update required it, but we wouldn't have to update all of the IANA-maintained modules within two weeks.

[Ballot comment]
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."

[Ballot discuss]
# IESG review of draft-ietf-netmod-yang-module-versioning-16

CC @MikeBishop

## 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 does not seem sustainable. This leaves servers with a binary choice --
either support all deprecated nodes indefinitely or don't disclose the
implementation state of any deprecated node. Similarly, remove all obsolete
nodes or don't disclose the state of any obsolete nodes.

The use of deviations gives an escape hatch, but it seems like this is really
not a binary at all; a server would like to indicate that it supports/doesn't
support individual nodes.

### Section 5.1, paragraph 4
```
    If a server does not set the "deprecated-nodes-implemented" leaf to
    "true", then clients MUST NOT rely solely on the "rev:non-backwards-
    compatible" statements to determine whether two module revisions are
    backwards-compatible, and MUST also consider whether the status of
    any nodes have changed to "deprecated" and whether those nodes are
    implemented by the server.  An implementation may choose to add
```
This suggests that clients must inspect the contents of all versions, in
addition to the revision history and its tags. Or minimally, the old and new
versions. Are clients guaranteed to have access to all arbitrary revisions?

### 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.
```
This seems like a dangerous SHOULD. Clients SHOULD accept invalid data, because
it might have been valid from the server's perspective? Arguably that's always true
of any invalid input. How can the client treat anything as invalid in that world?

[Ballot comment]
## 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.

[Ballot comment]
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.

[Ballot comment]

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.

[Ballot discuss]
Hi Rob, Reshad, Balázs, Joe, and Jason,

Thank you for the effort put into this important piece. I will be definitely balloting YES.

I have some few points to discuss. Comments are listed following the order in the document, not their importance.

# Augmentation and Update

CURRENT:
  This document updates [RFC8525] with augmentations to include two
  boolean leafs to indicate whether status deprecated and status
  obsolete schema nodes are implemented by the server.

We don’t usually update specs with augmented module. Please consider adding some text to explain what is special here.

# Authors Guidelines vs Specification

Section 3 is more about refinement of rules in [RFC7950] and [RFC6020], however there are parts that are move guidance to authors, which fall under 9907 updates. An example of such text is the following:

CURENT:
  Removing revision statements is allowed, but can cause
  issues and SHOULD NOT be done without careful analysis of the
  potential impact to users of the module or submodule since it may
  cause loss of visibility of when non-backwards-compatible changes
  were introduced.

## Wouldn’t be cleaner to move such parts to be under the section with 9907 updates?

## The text is more about what can be considered, but there is no guidance/reco on how/whether the outcome of that analysis is recorded in the module/document itself. Can we add some guidance?

## BTW, does this cover published modules or any flavor?

# Multiple versions of the same module

CURRENT:
  If a "recommended-min-date" extension statement is ignored by a YANG
  parser, the import statement is processed according to the rules
  documented in Section 7.1.5 of [RFC7950].

Per 7950, “Multiple revisions of the same module can be imported, provided that different prefixes are used”.

This would allow in theory authors to pick from revisions of the same modules but with distinct deprecation status. Do we need to say anything about mixing versions that deprecate vs. not deprecate a given data node?

# Missing Rationale

CURRENT:
  Servers SHOULD set both the "deprecated-nodes-implemented" and
  "obsolete-nodes-absent" leafs to "true", which allows clients to
  determine the exact schema used by the server.

## I don’t understand what is the reasoning of this reco? Why are we asking an implem to still support data nodes?

## How setting these Boolean helps know “the exact schema used by the server”.  A server may have partial support of those. These nodes are not helpful for that.

# Incomplete Guidance

CURRENT:
  A module that includes submodules SHOULD use the "revision-date"
  statement to include specific submodule revisions.  The revision of
  the including module MUST be updated when any included submodule has
  changed.

## Who is the target of the last part of this guidance?

## How that update is supposed to work?

# I would strengthen the guidance to MUST for this part:

CURRENT:
      If there is a replacement data node, rpc, action or
      notification for the deprecated node, this SHOULD be stated in
      the "description". 

# IANA-maintained modules

CURRENT:
  In all cases, IANA MUST follow the versioning guidance specified in
  Section 3.1, and MUST include a "rev:non-backwards-compatible"
  substatement to the latest revision statement whenever an IANA
  maintained module is updated in a non-backwards-compatible way, as
  described in Section 3.2.

## I don’t see how these MUSTs can be done by IANA without expert assistance. This guidance smells like adding Expert Review to all registries that are represented with a YANG module.

## I guess some of the answers are in:

CURRENT:
  See [I-D.ietf-netmod-iana-yang-guidance] for complete guidance on how
  to handle versioning for IANA maintained YANG modules.

However, I-D.ietf-netmod-iana-yang-guidance is only listed as Informative.

If the full guidance is what is recorded in that draft, then I-D.ietf-netmod-iana-yang-guidance has to be normative.

## The normative language in the IANA section can be avoided per the IESG statement on the matter.

[Ballot comment]
# Applicability

I suggest to add a statement early in the document about the target modules (is it published, unpublished, IETF modules, IANA-maintained, etc.).

# The lifecycle model in 4.7 of 9907 (also updated here) can also be relaxed when there are no known implem/deploymnents. Can we include a
I have seen bis doc fixing those. Relax rule is needed.

# RFC 8407

CURRENT:

Network Working Group                                    R. Wilton, Ed.
Internet-Draft                                      Cisco Systems, Inc.
Updates: 6020, 7950, 8407, 8525 (if approved)            R. Rahman, Ed.
Intended status: Standards Track                                Equinix
Expires: 23 October 2026                                B. Lengyel, Ed.

…

  This document updates RFC 7950, RFC 6020,
  RFC 8407 and RFC 8525.


Please update to RFC9907.

# Ambiguous “suggestion”

CURRENT:
  It extends the YANG import statement with a minimum
  revision suggestion to help document inter-module dependencies. 
  ^^^^^^^^^^^^^^^^^^^^

I don’t know how to interpret the highlighted text.

# Won’t age well

OLD:
  The current YANG [RFC7950] module update rules require that updates
  of YANG modules preserve strict backwards compatibility. 

NEW:
  The YANG module update rules per [RFC7950] require that updates
  of YANG modules preserve strict backwards compatibility. 

# (nit) YANG 1.0

OLD: Refinements to the YANG 1 and YANG 1.1 module revision update

NEW: Refinements to the YANG 1.0 and YANG 1.1 module revision update

# Stale text:

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

Please delete.

# Terminology

Consider add to the list RFC 9907 as we are using terms “IANA-maintained YANG module”, “published”, etc. that are defined there.

# Helps readers

CURRENT:
  or if revision A would have been listed had it
  not been removed (see Section 3.3). 

Can you please consider rewording as I had difficulty to parse this. Thanks.

# nit

OLD: A module's name and revision date identifies a specific

NEW: A module's name and revision date identify a specific

# Section 3.1.1

CURRENT:
  *  A "status" "deprecated" statement MAY be added, or changed from
      "current" to "deprecated", but adding or changing "status" to
      "obsolete" is a non-backwards-compatible change.

As there other rules in 9907 for such status transition, especially this part:

“The status SHOULD NOT be changed from "current" directly to "obsolete". An object SHOULD be available for at least one year after the publication date with a "deprecated" status before it is changed to "obsolete".”

I suggest to update the above bullet to emphasis that such status changes should also be done per the guidance in 9907 and update behavior in Section 6.

# Section 4

CURRENT:
  Instead, for conformance purposes (section 5.6 of [RFC7950]), the
  recommended approach for defining the relationship between specific
  YANG module revisions is to specify the relationships outside of the
  YANG modules,

Should s/recommended/RECOMMENDED to better highlight the guidance?

# Section 4.1

CURRENT:
  This module introduces, primarily for modules with a linear revision
  history that are versioned using revision dates,

Not sure what we meant by “This module” here. Please reword to make that explicit.


# RFC 9907 Guidance and template

## Example prefix

CURRENT:
prefix "prefix-name";

GUIDANCE:
  For convenience, prefix values of example modules SHOULD be prefixed
  with "ex" or similar patterns.

## Update TLP to 2026 for all modules

## Module template

OLD:
        This version of this YANG module is part of RFC XXXX; see
        the RFC itself for full legal notices.

NEW:
        All revisions of IETF and IANA published modules can be found
        at the YANG Parameters registry group
        (https://www.iana.org/assignments/yang-parameters).

        This version of this YANG module is part of RFC XXXX; see
        the RFC itself for full legal notices.";

## Sec cons

OLD:
  This section uses the template described in Section 3.7 of
  [I-D.ietf-netmod-rfc8407bis].

NEW:
  This section uses the template described in Section 3.7.1 of
  [RFC9907].

## IANA Registrations

Please add for both registrations:

      Maintained by IANA?  N

# RFC 9911

CURRENT:

      The argument to the "recommended-min-date" extension statement is
      a revision date which uses the "date-no-zone" type defined in
      [I-D.ietf-netmod-rfc6991-bis].

And

        "RFC YYYY-draft-ietf-netmod-rfc6991-bis: Common YANG Data Types";
    }


# Default values

Shouldn’t a default false statement be better here rather than having this in the description or by normative text?

CURRENT:

  deprecated-nodes-implemented:  If set to "true", this leaf indicates
      that all schema nodes with a status "deprecated" are implemented
      equivalently as if they had status "current"; otherwise deviations
      MUST be used by the server to explicitly remove "deprecated" nodes
      from the schema.  If this leaf is set to "false" or absent, then
      the behavior is unspecified.

  obsolete-nodes-absent:  If set to "true", this leaf indicates that
      the server does not implement any status "obsolete" schema nodes.
      If this leaf is set to "false" or absent, then the behaviour is
      unspecified.

…
        type boolean;
        description
          "If set to true, this leaf indicates that all schema nodes
            with a status 'deprecated' are implemented equivalently as
            if they had status 'current'; otherwise deviations MUST be
            used to explicitly remove deprecated nodes from the schema.
            If this leaf is absent or set to false, then the behavior is
            unspecified.";
..

      leaf obsolete-nodes-absent {
        type boolean;
        description
          "If set to true, this leaf indicates that the server does not
            implement any status 'obsolete' schema nodes.  If this leaf
            is absent or set to false, then the behaviour is
            unspecified.";

# Please add an Operational Considerations Section

I suggest to add at least some text to basically encourage authors to details the OPS impacts of changes.

# References

Please move the following entries from Normative to Informative

  [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
              and A. Bierman, Ed., "Network Configuration Protocol
              (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
              .

  [RFC8040]  Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
              Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
              .

  [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              .

# nits

* s/and hence section Section 6.1/and hence Section 6.1

* s/consumers of YANG models/ consumers of YANG data models

* s/The author/Authors

* s/an author/Authors

* s/New ietf-yang-library-status YANG module/The “ietf-yang-library-status” YANG module

Cheers,
Med

[Ballot comment]
Thanks for the work done in this document, a long due change to YANG.

# Idnits

There are several issues flagged by the idNits:
https://author-tools.ietf.org/idnits3/results?url=https://www.ietf.org/archive/id/draft-ietf-netmod-yang-module-versioning-16.txt

# Section 1.1

Probably linked to the idnits issue, `This document updates [I-D.ietf-netmod-rfc8407bis] section 4.7.` but if it was still a draft, then this would be easier to fix the draft (I know that it is published now).

# Use of SHOULD

Thanks for providing guidance when using the BCP14 "SHOULD", except in sections 6.1.1 and 6.2 :-(

> # Document Shepherd Write-Up for Group Documents
>
> *This version is dated 4 July 2022.*
>
> Thank you for your service as a document shepherd. Among the responsibilities is
> answering the questions in this write-up to give helpful context to Last Call
> and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
> diligence in completing it is appreciated. The full role of the shepherd is
> further described in [RFC 4858][2]. You will need the cooperation of the authors
> and editors to complete these checks.
>
> Note that some numbered items contain multiple related questions; please be sure
> to answer all of them.
>
> ## Document History
>
> 1. Does the working group (WG) consensus represent the strong concurrence of a
>    few individuals, with others being silent, or did it reach broad agreement?
>

This document is part of the long running module versioning work within the WG.  The work has been driven by a strong core group with general support across the WG.

> 2. Was there controversy about particular points, or were there decisions where
>    the consensus was particularly rough?

Some long term, but now less frequent, contributors to the WG have expressed reservation/concerns with some of the choices made in the revision documents. This said, there has been extensive discussions, and a number of modification, to address their concerns -- and the current documents represent WG consensus.

>
> 3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
>    so, please summarize the areas of conflict in separate email messages to the
>    responsible Area Director. (It should be in a separate email because this
>    questionnaire is publicly available.)

I don't think so, but there are two long term contributors have indicated what I interpret as reluctant acceptance of the WG consensus.

>
> 4. For protocol documents, are there existing implementations of the contents of
>    the document? Have a significant number of potential implementers indicated
>    plans to implement? Are any existing implementations reported somewhere,
>    either in the document itself (as [RFC 7942][3] recommends) or elsewhere
>    (where)?

This is YANG Module.  Implementation status is unknown.

>
> ## Additional Reviews
>
> 5. Do the contents of this document closely interact with technologies in other
>    IETF working groups or external organizations, and would it therefore benefit
>    from their review? Have those reviews occurred? If yes, describe which
>    reviews took place.
>

N/A


> 6. Describe how the document meets any required formal expert review criteria,
>    such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
>

A YANG Dr review was conducted.

> 7. If the document contains a YANG module, has the final version of the module
>    been checked with any of the [recommended validation tools][4] for syntax and
>    formatting validation?

Yes.

> If there are any resulting errors or warnings, what is
>    the justification for not fixing them at this time?

There is 1 warning, that is not due to this model but rather use of old tooling that figs issues on imported modules.
> Does the YANG module
>    comply with the Network Management Datastore Architecture (NMDA) as specified
>    in [RFC 8342][5]?
>

yes.

> 8. Describe reviews and automated checks performed to validate sections of the
>    final version of the document written in a formal language, such as XML code,
>    BNF rules, MIB definitions, CBOR's CDDL, etc.

The YANG validation tool was run: see https://datatracker.ietf.org/doc/draft-ietf-netmod-intf-ext-yang/#

>
> ## Document Shepherd Checks
>
> 9. Based on the shepherd's review of the document, is it their opinion that this
>    document is needed, clearly written, complete, correctly designed, and ready
>    to be handed off to the responsible Area Director?
>

I consider it ready.

> 10. Several IETF Areas have assembled [lists of common issues that their
>    reviewers encounter][6]. For which areas have such issues been identified
>    and addressed? For which does this still need to happen in subsequent
>    reviews?
>

Nothing additional.

> 11. What type of RFC publication is being requested on the IETF stream ([Best
>    Current Practice][12], [Proposed Standard, Internet Standard][13],
>    [Informational, Experimental or Historic][14])? Why is this the proper type
>    of RFC? Do all Datatracker state attributes correctly reflect this intent?
>

Proposed standard.  This is appropriate as it documents a YANG Model.

> 12. Have reasonable efforts been made to remind all authors of the intellectual
>    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
>    the best of your knowledge, have all required disclosures been filed? If
>    not, explain why. If yes, summarize any relevant discussion, including links
>    to publicly-available messages when applicable.
>
yes, see https://mailarchive.ietf.org/arch/msg/netmod/EMpkuW_Rwmgg2nAZ-GP1RPen5s8/#

> 13. Has each author, editor, and contributor shown their willingness to be
>    listed as such? If the total number of authors and editors on the front page
>    is greater than five, please provide a justification.
yes, NA


>
> 14. Document any remaining I-D nits in this document. Simply running the [idnits
>    tool][8] is not enough; please review the ["Content Guidelines" on
>    authors.ietf.org][15]. (Also note that the current idnits tool generates
>    some incorrect warnings; a rewrite is underway.)
>
no meaningful idnits .

> 15. Should any informative references be normative or vice-versa? See the [IESG
>    Statement on Normative and Informative References][16].
>
I don't thing so.

> 16. List any normative references that are not freely available to anyone. Did
>    the community have sufficient access to review any such normative
>    references?
>

None.

> 17. Are there any normative downward references (see [RFC 3967][9] and [BCP
>    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
>    list them.
>

None.

> 18. Are there normative references to documents that are not ready to be
>    submitted to the IESG for publication or are otherwise in an unclear state?
>    If so, what is the plan for their completion?
None.

>
> 19. Will publication of this document change the status of any existing RFCs? If
>    so, does the Datatracker metadata correctly reflect this and are those RFCs
>    listed on the title page, in the abstract, and discussed in the
>    introduction? If not, explain why and point to the part of the document
>    where the relationship of this document to these other RFCs is discussed.
No changes

>
> 20. Describe the document shepherd's review of the IANA considerations section,
>    especially with regard to its consistency with the body of the document.
>    Confirm that all aspects of the document requiring IANA assignments are
>    associated with the appropriate reservations in IANA registries. Confirm
>    that any referenced IANA registries have been clearly identified. Confirm
>    that each newly created IANA registry specifies its initial contents,
>    allocations procedures, and a reasonable name (see [RFC 8126][11]).
>

I have reviewed the section an believe it appropriate/correct.

> 21. List any new IANA registries that require Designated Expert Review for
>    future allocations. Are the instructions to the Designated Expert clear?
>    Please include suggestions of designated experts, if appropriate.
>

No experts needed.

> [1]: https://www.ietf.org/about/groups/iesg/
> [2]: https://www.rfc-editor.org/rfc/rfc4858.html
> [3]: https://www.rfc-editor.org/rfc/rfc7942.html
> [4]: https://wiki.ietf.org/group/ops/yang-review-tools
> [5]: https://www.rfc-editor.org/rfc/rfc8342.html
> [6]: https://wiki.ietf.org/group/iesg/ExpertTopics
> [7]: https://www.rfc-editor.org/info/bcp79
> [8]: https://www.ietf.org/tools/idnits/
> [9]: https://www.rfc-editor.org/rfc/rfc3967.html
> [10]: https://www.rfc-editor.org/info/bcp97
> [11]: https://www.rfc-editor.org/rfc/rfc8126.html
> [12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
> [13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
> [14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
> [15]: https://authors.ietf.org/en/content-guidelines-overview
> [16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
> [17]: https://datatracker.ietf.org/doc/downref/
>
>

> # Document Shepherd Write-Up for Group Documents
>
> *This version is dated 4 July 2022.*
>
> Thank you for your service as a document shepherd. Among the responsibilities is
> answering the questions in this write-up to give helpful context to Last Call
> and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
> diligence in completing it is appreciated. The full role of the shepherd is
> further described in [RFC 4858][2]. You will need the cooperation of the authors
> and editors to complete these checks.
>
> Note that some numbered items contain multiple related questions; please be sure
> to answer all of them.
>
> ## Document History
>
> 1. Does the working group (WG) consensus represent the strong concurrence of a
>    few individuals, with others being silent, or did it reach broad agreement?
>

This document is part of the long running module versioning work within the WG.  The work has been driven by a strong core group with general support across the WG.

> 2. Was there controversy about particular points, or were there decisions where
>    the consensus was particularly rough?

Some long term, but now less frequent, contributors to the WG have expressed reservation/concerns with some of the choices made in the revision documents. This said, there has been extensive discussions, and a number of modification, to address their concerns -- and the current documents represent WG consensus.

>
> 3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
>    so, please summarize the areas of conflict in separate email messages to the
>    responsible Area Director. (It should be in a separate email because this
>    questionnaire is publicly available.)

I don't think so, but there are two long term contributors have indicated what I interpret as reluctant acceptance of the WG consensus.

>
> 4. For protocol documents, are there existing implementations of the contents of
>    the document? Have a significant number of potential implementers indicated
>    plans to implement? Are any existing implementations reported somewhere,
>    either in the document itself (as [RFC 7942][3] recommends) or elsewhere
>    (where)?

This is YANG Module.  Implementation status is unknown.

>
> ## Additional Reviews
>
> 5. Do the contents of this document closely interact with technologies in other
>    IETF working groups or external organizations, and would it therefore benefit
>    from their review? Have those reviews occurred? If yes, describe which
>    reviews took place.
>

N/A


> 6. Describe how the document meets any required formal expert review criteria,
>    such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
>

A YANG Dr review was conducted.

> 7. If the document contains a YANG module, has the final version of the module
>    been checked with any of the [recommended validation tools][4] for syntax and
>    formatting validation?

Yes.

> If there are any resulting errors or warnings, what is
>    the justification for not fixing them at this time?

There is 1 warning, that is not due to this model but rather use of old tooling that figs issues on imported modules.
> Does the YANG module
>    comply with the Network Management Datastore Architecture (NMDA) as specified
>    in [RFC 8342][5]?
>

yes.

> 8. Describe reviews and automated checks performed to validate sections of the
>    final version of the document written in a formal language, such as XML code,
>    BNF rules, MIB definitions, CBOR's CDDL, etc.

The YANG validation tool was run: see https://datatracker.ietf.org/doc/draft-ietf-netmod-intf-ext-yang/#

>
> ## Document Shepherd Checks
>
> 9. Based on the shepherd's review of the document, is it their opinion that this
>    document is needed, clearly written, complete, correctly designed, and ready
>    to be handed off to the responsible Area Director?
>

I consider it ready.

> 10. Several IETF Areas have assembled [lists of common issues that their
>    reviewers encounter][6]. For which areas have such issues been identified
>    and addressed? For which does this still need to happen in subsequent
>    reviews?
>

Nothing additional.

> 11. What type of RFC publication is being requested on the IETF stream ([Best
>    Current Practice][12], [Proposed Standard, Internet Standard][13],
>    [Informational, Experimental or Historic][14])? Why is this the proper type
>    of RFC? Do all Datatracker state attributes correctly reflect this intent?
>

Proposed standard.  This is appropriate as it documents a YANG Model.

> 12. Have reasonable efforts been made to remind all authors of the intellectual
>    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
>    the best of your knowledge, have all required disclosures been filed? If
>    not, explain why. If yes, summarize any relevant discussion, including links
>    to publicly-available messages when applicable.
>
yes, see https://mailarchive.ietf.org/arch/msg/netmod/EMpkuW_Rwmgg2nAZ-GP1RPen5s8/#

> 13. Has each author, editor, and contributor shown their willingness to be
>    listed as such? If the total number of authors and editors on the front page
>    is greater than five, please provide a justification.

Yes, this document has more than five authors. This document represents a large amount of work over years. Each of the listed authors has contributed individually and significantly to the work product. The list of authors has been reduced and limited to those who materially contributed to the document in its current form. All of whom remain active in related work and will be responsive to the RFC editor process.

>
> 14. Document any remaining I-D nits in this document. Simply running the [idnits
>    tool][8] is not enough; please review the ["Content Guidelines" on
>    authors.ietf.org][15]. (Also note that the current idnits tool generates
>    some incorrect warnings; a rewrite is underway.)
>
no meaningful idnits .

> 15. Should any informative references be normative or vice-versa? See the [IESG
>    Statement on Normative and Informative References][16].
>
I don't thing so.

> 16. List any normative references that are not freely available to anyone. Did
>    the community have sufficient access to review any such normative
>    references?
>

None.

> 17. Are there any normative downward references (see [RFC 3967][9] and [BCP
>    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
>    list them.
>

None.

> 18. Are there normative references to documents that are not ready to be
>    submitted to the IESG for publication or are otherwise in an unclear state?
>    If so, what is the plan for their completion?
None.

>
> 19. Will publication of this document change the status of any existing RFCs? If
>    so, does the Datatracker metadata correctly reflect this and are those RFCs
>    listed on the title page, in the abstract, and discussed in the
>    introduction? If not, explain why and point to the part of the document
>    where the relationship of this document to these other RFCs is discussed.
No changes

>
> 20. Describe the document shepherd's review of the IANA considerations section,
>    especially with regard to its consistency with the body of the document.
>    Confirm that all aspects of the document requiring IANA assignments are
>    associated with the appropriate reservations in IANA registries. Confirm
>    that any referenced IANA registries have been clearly identified. Confirm
>    that each newly created IANA registry specifies its initial contents,
>    allocations procedures, and a reasonable name (see [RFC 8126][11]).
>

I have reviewed the section an believe it appropriate/correct.

> 21. List any new IANA registries that require Designated Expert Review for
>    future allocations. Are the instructions to the Designated Expert clear?
>    Please include suggestions of designated experts, if appropriate.
>

No experts needed.

> [1]: https://www.ietf.org/about/groups/iesg/
> [2]: https://www.rfc-editor.org/rfc/rfc4858.html
> [3]: https://www.rfc-editor.org/rfc/rfc7942.html
> [4]: https://wiki.ietf.org/group/ops/yang-review-tools
> [5]: https://www.rfc-editor.org/rfc/rfc8342.html
> [6]: https://wiki.ietf.org/group/iesg/ExpertTopics
> [7]: https://www.rfc-editor.org/info/bcp79
> [8]: https://www.ietf.org/tools/idnits/
> [9]: https://www.rfc-editor.org/rfc/rfc3967.html
> [10]: https://www.rfc-editor.org/info/bcp97
> [11]: https://www.rfc-editor.org/rfc/rfc8126.html
> [12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
> [13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
> [14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
> [15]: https://authors.ietf.org/en/content-guidelines-overview
> [16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
> [17]: https://datatracker.ietf.org/doc/downref/
>
>

Holding this document in its current state waiting for its companion documents to clear its hurdles, so all three documents can go into IESG evaluation at the same time.

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-netmod-yang-module-versioning-15. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there are two actions which we must complete.

First, in the ns registry in the IETF XML Registry group located at:

https://www.iana.org/assignments/xml-registry/

two new namespaces will be registered as follows:

ID: yang:ietf-yang-revisions
URI: urn:ietf:params:xml:ns:yang:ietf-yang-revisions
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

ID: yang:ietf-yang-library-status
URI: urn:ietf:params:xml:ns:yang:ietf-yang-library-status
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Second, in the YANG Module Names registry in the YANG Parameters registry group located at:

https://www.iana.org/assignments/yang-parameters/

two new YANG modules will be registered as follows:

Name: ietf-yang-revisions
File: [ TBD-at-Registration ]
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:ietf-yang-revisions
Prefix: rev
Module:
Reference: [ RFC-to-be ]

Name: ietf-yang-library-status
File: [ TBD-at-Registration ]
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:ietf-yang-library-status
Prefix: yls
Module:
Reference: [ RFC-to-be ]

While the YANG module name will be registered after the IESG approves the document, the YANG module file will be posted after the RFC Editor notifies us that the document has been published.

Second, IANA also notes the guidance in Section 9.2 of the current draft. IANA also has been reviewing some of the actual content of the RFC as far as versioning is concerned and have been in discussions with the YANG doctors about this and related documents. IANA notes that this document's actions will not be completed until the other two related documents have also been approved:

draft-ietf-netmod-yang-semver
draft-ietf-netmod-yang-module-filename
draft-ietf-netmod-yang-module-versioning

We understand that these are the only actions required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2025-11-12):

From: The IESG
To: IETF-Announce
CC: draft-ietf-netmod-yang-module-versioning@ietf.org, lberger@labn.net, mjethanandani@gmail.com, netmod-chairs@ietf.org, netmod@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Updated YANG Module Revision Handling) to Proposed Standard


The IESG has received a request from the Network Modeling WG (netmod) to
consider the following document: - 'Updated YANG Module Revision Handling'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2025-11-12. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document refines the RFC 7950 module update rules.  It specifies
  a new YANG module update procedure that can document when non-
  backwards-compatible changes have occurred during the evolution of a
  YANG module.  It extends the YANG import statement with a minimum
  revision suggestion to help document inter-module dependencies.  It
  provides guidelines for managing the lifecycle of YANG modules and
  individual schema nodes.  This document updates RFC 7950, RFC 6020,
  RFC 8407 and RFC 8525.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-module-versioning/



No IPR declarations have been submitted directly on this I-D.

> # Document Shepherd Write-Up for Group Documents
>
> *This version is dated 4 July 2022.*
>
> Thank you for your service as a document shepherd. Among the responsibilities is
> answering the questions in this write-up to give helpful context to Last Call
> and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
> diligence in completing it is appreciated. The full role of the shepherd is
> further described in [RFC 4858][2]. You will need the cooperation of the authors
> and editors to complete these checks.
>
> Note that some numbered items contain multiple related questions; please be sure
> to answer all of them.
>
> ## Document History
>
> 1. Does the working group (WG) consensus represent the strong concurrence of a
>    few individuals, with others being silent, or did it reach broad agreement?
>

This document is part of the long running module versioning work within the WG.  The work has been driven by a strong core group with general support across the WG.

> 2. Was there controversy about particular points, or were there decisions where
>    the consensus was particularly rough?

Some long term, but now less frequent, contributors to the WG have expressed reservation/concerns with some of the choices made in the revision documents. This said, there has been extensive discussions, and a number of modification, to address their concerns -- and the current documents represent WG consensus.

>
> 3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
>    so, please summarize the areas of conflict in separate email messages to the
>    responsible Area Director. (It should be in a separate email because this
>    questionnaire is publicly available.)

I don't think so, but there are two long term contributors have indicated what I interpret as reluctant acceptance of the WG consensus.

>
> 4. For protocol documents, are there existing implementations of the contents of
>    the document? Have a significant number of potential implementers indicated
>    plans to implement? Are any existing implementations reported somewhere,
>    either in the document itself (as [RFC 7942][3] recommends) or elsewhere
>    (where)?

This is YANG Module.  Implementation status is unknown.

>
> ## Additional Reviews
>
> 5. Do the contents of this document closely interact with technologies in other
>    IETF working groups or external organizations, and would it therefore benefit
>    from their review? Have those reviews occurred? If yes, describe which
>    reviews took place.
>

N/A


> 6. Describe how the document meets any required formal expert review criteria,
>    such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
>

A YANG Dr review was conducted.

> 7. If the document contains a YANG module, has the final version of the module
>    been checked with any of the [recommended validation tools][4] for syntax and
>    formatting validation?

Yes.

> If there are any resulting errors or warnings, what is
>    the justification for not fixing them at this time?

There is 1 warning, that is not due to this model but rather use of old tooling that figs issues on imported modules.
> Does the YANG module
>    comply with the Network Management Datastore Architecture (NMDA) as specified
>    in [RFC 8342][5]?
>

yes.

> 8. Describe reviews and automated checks performed to validate sections of the
>    final version of the document written in a formal language, such as XML code,
>    BNF rules, MIB definitions, CBOR's CDDL, etc.

The YANG validation tool was run: see https://datatracker.ietf.org/doc/draft-ietf-netmod-intf-ext-yang/#

>
> ## Document Shepherd Checks
>
> 9. Based on the shepherd's review of the document, is it their opinion that this
>    document is needed, clearly written, complete, correctly designed, and ready
>    to be handed off to the responsible Area Director?
>

I consider it ready.

> 10. Several IETF Areas have assembled [lists of common issues that their
>    reviewers encounter][6]. For which areas have such issues been identified
>    and addressed? For which does this still need to happen in subsequent
>    reviews?
>

Nothing additional.

> 11. What type of RFC publication is being requested on the IETF stream ([Best
>    Current Practice][12], [Proposed Standard, Internet Standard][13],
>    [Informational, Experimental or Historic][14])? Why is this the proper type
>    of RFC? Do all Datatracker state attributes correctly reflect this intent?
>

Proposed standard.  This is appropriate as it documents a YANG Model.

> 12. Have reasonable efforts been made to remind all authors of the intellectual
>    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
>    the best of your knowledge, have all required disclosures been filed? If
>    not, explain why. If yes, summarize any relevant discussion, including links
>    to publicly-available messages when applicable.
>
yes, see https://mailarchive.ietf.org/arch/msg/netmod/EMpkuW_Rwmgg2nAZ-GP1RPen5s8/#

> 13. Has each author, editor, and contributor shown their willingness to be
>    listed as such? If the total number of authors and editors on the front page
>    is greater than five, please provide a justification.

Yes, less than 5 authors.
>
> 14. Document any remaining I-D nits in this document. Simply running the [idnits
>    tool][8] is not enough; please review the ["Content Guidelines" on
>    authors.ietf.org][15]. (Also note that the current idnits tool generates
>    some incorrect warnings; a rewrite is underway.)
>
no meaningful idnits .

> 15. Should any informative references be normative or vice-versa? See the [IESG
>    Statement on Normative and Informative References][16].
>
I don't thing so.

> 16. List any normative references that are not freely available to anyone. Did
>    the community have sufficient access to review any such normative
>    references?
>

None.

> 17. Are there any normative downward references (see [RFC 3967][9] and [BCP
>    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
>    list them.
>

None.

> 18. Are there normative references to documents that are not ready to be
>    submitted to the IESG for publication or are otherwise in an unclear state?
>    If so, what is the plan for their completion?
None.

>
> 19. Will publication of this document change the status of any existing RFCs? If
>    so, does the Datatracker metadata correctly reflect this and are those RFCs
>    listed on the title page, in the abstract, and discussed in the
>    introduction? If not, explain why and point to the part of the document
>    where the relationship of this document to these other RFCs is discussed.
No changes

>
> 20. Describe the document shepherd's review of the IANA considerations section,
>    especially with regard to its consistency with the body of the document.
>    Confirm that all aspects of the document requiring IANA assignments are
>    associated with the appropriate reservations in IANA registries. Confirm
>    that any referenced IANA registries have been clearly identified. Confirm
>    that each newly created IANA registry specifies its initial contents,
>    allocations procedures, and a reasonable name (see [RFC 8126][11]).
>

I have reviewed the section an believe it appropriate/correct.

> 21. List any new IANA registries that require Designated Expert Review for
>    future allocations. Are the instructions to the Designated Expert clear?
>    Please include suggestions of designated experts, if appropriate.
>

No experts needed.

> [1]: https://www.ietf.org/about/groups/iesg/
> [2]: https://www.rfc-editor.org/rfc/rfc4858.html
> [3]: https://www.rfc-editor.org/rfc/rfc7942.html
> [4]: https://wiki.ietf.org/group/ops/yang-review-tools
> [5]: https://www.rfc-editor.org/rfc/rfc8342.html
> [6]: https://wiki.ietf.org/group/iesg/ExpertTopics
> [7]: https://www.rfc-editor.org/info/bcp79
> [8]: https://www.ietf.org/tools/idnits/
> [9]: https://www.rfc-editor.org/rfc/rfc3967.html
> [10]: https://www.rfc-editor.org/info/bcp97
> [11]: https://www.rfc-editor.org/rfc/rfc8126.html
> [12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
> [13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
> [14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
> [15]: https://authors.ietf.org/en/content-guidelines-overview
> [16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
> [17]: https://datatracker.ietf.org/doc/downref/
>
>

> # Document Shepherd Write-Up for Group Documents
>
> *This version is dated 4 July 2022.*
>
> Thank you for your service as a document shepherd. Among the responsibilities is
> answering the questions in this write-up to give helpful context to Last Call
> and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
> diligence in completing it is appreciated. The full role of the shepherd is
> further described in [RFC 4858][2]. You will need the cooperation of the authors
> and editors to complete these checks.
>
> Note that some numbered items contain multiple related questions; please be sure
> to answer all of them.
>
> ## Document History
>
> 1. Does the working group (WG) consensus represent the strong concurrence of a
>    few individuals, with others being silent, or did it reach broad agreement?
>

This document is part of the long running module versioning work within the WG.  The work has been driven by a strong core group with general support across the WG.

> 2. Was there controversy about particular points, or were there decisions where
>    the consensus was particularly rough?

Some long term, but now less frequent, contributors to the WG have expressed reservation/concerns with some of the choices made in the revision documents. This said, there has been extensive discussions, and a number of modification, to address their concerns -- and the current documents represent WG consensus.

>
> 3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
>    so, please summarize the areas of conflict in separate email messages to the
>    responsible Area Director. (It should be in a separate email because this
>    questionnaire is publicly available.)

I don't think so, but there are two long term contributors have indicated what I interpret as reluctant acceptance of the WG consensus.

>
> 4. For protocol documents, are there existing implementations of the contents of
>    the document? Have a significant number of potential implementers indicated
>    plans to implement? Are any existing implementations reported somewhere,
>    either in the document itself (as [RFC 7942][3] recommends) or elsewhere
>    (where)?

This is YANG Module.  Implementation status is unknown.

>
> ## Additional Reviews
>
> 5. Do the contents of this document closely interact with technologies in other
>    IETF working groups or external organizations, and would it therefore benefit
>    from their review? Have those reviews occurred? If yes, describe which
>    reviews took place.
>

N/A


> 6. Describe how the document meets any required formal expert review criteria,
>    such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
>

A YANG Dr review was conducted.

> 7. If the document contains a YANG module, has the final version of the module
>    been checked with any of the [recommended validation tools][4] for syntax and
>    formatting validation?

Yes.

> If there are any resulting errors or warnings, what is
>    the justification for not fixing them at this time?

There is 1 warning, that is not due to this model but rather use of old tooling that figs issues on imported modules.
> Does the YANG module
>    comply with the Network Management Datastore Architecture (NMDA) as specified
>    in [RFC 8342][5]?
>

yes.

> 8. Describe reviews and automated checks performed to validate sections of the
>    final version of the document written in a formal language, such as XML code,
>    BNF rules, MIB definitions, CBOR's CDDL, etc.

The YANG validation tool was run: see https://datatracker.ietf.org/doc/draft-ietf-netmod-intf-ext-yang/#

>
> ## Document Shepherd Checks
>
> 9. Based on the shepherd's review of the document, is it their opinion that this
>    document is needed, clearly written, complete, correctly designed, and ready
>    to be handed off to the responsible Area Director?
>

I consider it ready.

> 10. Several IETF Areas have assembled [lists of common issues that their
>    reviewers encounter][6]. For which areas have such issues been identified
>    and addressed? For which does this still need to happen in subsequent
>    reviews?
>

Nothing additional.

> 11. What type of RFC publication is being requested on the IETF stream ([Best
>    Current Practice][12], [Proposed Standard, Internet Standard][13],
>    [Informational, Experimental or Historic][14])? Why is this the proper type
>    of RFC? Do all Datatracker state attributes correctly reflect this intent?
>

Proposed standard.  This is appropriate as it documents a YANG Model.

> 12. Have reasonable efforts been made to remind all authors of the intellectual
>    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
>    the best of your knowledge, have all required disclosures been filed? If
>    not, explain why. If yes, summarize any relevant discussion, including links
>    to publicly-available messages when applicable.
>
yes, see https://mailarchive.ietf.org/arch/msg/netmod/EMpkuW_Rwmgg2nAZ-GP1RPen5s8/#

> 13. Has each author, editor, and contributor shown their willingness to be
>    listed as such? If the total number of authors and editors on the front page
>    is greater than five, please provide a justification.

Yes, less than 5 authors.
>
> 14. Document any remaining I-D nits in this document. Simply running the [idnits
>    tool][8] is not enough; please review the ["Content Guidelines" on
>    authors.ietf.org][15]. (Also note that the current idnits tool generates
>    some incorrect warnings; a rewrite is underway.)
>
no meaningful idnits .

> 15. Should any informative references be normative or vice-versa? See the [IESG
>    Statement on Normative and Informative References][16].
>
I don't thing so.

> 16. List any normative references that are not freely available to anyone. Did
>    the community have sufficient access to review any such normative
>    references?
>

None.

> 17. Are there any normative downward references (see [RFC 3967][9] and [BCP
>    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
>    list them.
>

None.

> 18. Are there normative references to documents that are not ready to be
>    submitted to the IESG for publication or are otherwise in an unclear state?
>    If so, what is the plan for their completion?
None.

>
> 19. Will publication of this document change the status of any existing RFCs? If
>    so, does the Datatracker metadata correctly reflect this and are those RFCs
>    listed on the title page, in the abstract, and discussed in the
>    introduction? If not, explain why and point to the part of the document
>    where the relationship of this document to these other RFCs is discussed.
No changes

>
> 20. Describe the document shepherd's review of the IANA considerations section,
>    especially with regard to its consistency with the body of the document.
>    Confirm that all aspects of the document requiring IANA assignments are
>    associated with the appropriate reservations in IANA registries. Confirm
>    that any referenced IANA registries have been clearly identified. Confirm
>    that each newly created IANA registry specifies its initial contents,
>    allocations procedures, and a reasonable name (see [RFC 8126][11]).
>

I have reviewed the section an believe it appropriate/correct.

> 21. List any new IANA registries that require Designated Expert Review for
>    future allocations. Are the instructions to the Designated Expert clear?
>    Please include suggestions of designated experts, if appropriate.
>

No experts needed.

> [1]: https://www.ietf.org/about/groups/iesg/
> [2]: https://www.rfc-editor.org/rfc/rfc4858.html
> [3]: https://www.rfc-editor.org/rfc/rfc7942.html
> [4]: https://wiki.ietf.org/group/ops/yang-review-tools
> [5]: https://www.rfc-editor.org/rfc/rfc8342.html
> [6]: https://wiki.ietf.org/group/iesg/ExpertTopics
> [7]: https://www.rfc-editor.org/info/bcp79
> [8]: https://www.ietf.org/tools/idnits/
> [9]: https://www.rfc-editor.org/rfc/rfc3967.html
> [10]: https://www.rfc-editor.org/info/bcp97
> [11]: https://www.rfc-editor.org/rfc/rfc8126.html
> [12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
> [13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
> [14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
> [15]: https://authors.ietf.org/en/content-guidelines-overview
> [16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
> [17]: https://datatracker.ietf.org/doc/downref/
>
>

new IPR call - prep for 2nd LC https://mailarchive.ietf.org/arch/msg/netmod/TFRRZ__e6y-8UwLQv-IyE4piB80/
Pending response:
    Ebben Aries
    Juergen Schoenwaelder
    Mahesh Jethanandani
    Michael (Wangzitao)
    Jason Sterne

Completed Responses:
    Benoit Claise https://mailarchive.ietf.org/arch/msg/netmod/bKBIX8rKORHBjs0lzV34kDyx63I/
    Bo Wu https://mailarchive.ietf.org/arch/msg/netmod/GYsYv15Yfcrl4wgHobzzC-M38pA/
    Jan Lindblad https://mailarchive.ietf.org/arch/msg/netmod/mwnKmB9fHTu_v_kE4leKNiBpwIU/
    Per Andersson https://mailarchive.ietf.org/arch/msg/netmod/hSdpkJ2RAUQUDjxRH81kwSonI9c/
    Qin Wu https://mailarchive.ietf.org/arch/msg/netmod/zygIqC72xxmKjNNUD4Hd4Xb9tMg/
  Robert Wilton (editor) https://mailarchive.ietf.org/arch/msg/netmod/x0gs6itd46932VAp9CGWuP3gmbc/
  Reshad Rahman (editor) https://mailarchive.ietf.org/arch/msg/netmod/IuT4nooR4ZI_2MUAwwZFJjYlse8/
  Balazs Lengyel (editor) https://mailarchive.ietf.org/arch/msg/netmod/_Aa1Q1pqckpg-yQsV-TdplUYuDk/
  Joe Clarke https://mailarchive.ietf.org/arch/msg/netmod/pQfcoOgyKg5CQdoOVpD-kr9_k2c/

new IPR call - prep for 2nd LC https://mailarchive.ietf.org/arch/msg/netmod/TFRRZ__e6y-8UwLQv-IyE4piB80/
Pending response:

    Benoit Claise
    Bo Wu
    Ebben Aries
    Jan Lindblad
    Juergen Schoenwaelder
    Mahesh Jethanandani
    Michael (Wangzitao)
    Per Andersson
    Qin Wu
  Robert Wilton (editor)
  Reshad Rahman (editor)
  Balazs Lengyel (editor)
  Joe Clarke
  Jason Sterne

IPR Call update - waiting on
    Author:  Balazs Lengyel

responses:
    Author:  Joe Clarke
https://mailarchive.ietf.org/arch/msg/netmod/O9QouDRVDrs-kmMUVXvAQW0NzVw/
    Author:  Reshad Rahman
https://mailarchive.ietf.org/arch/msg/netmod/iV2bi-Yk20yi61WgByAchilc1bs/
    Author:  Robert Wilton
https://mailarchive.ietf.org/arch/msg/netmod/SOARfXr-A9_6nwrQH2_w_XUojew/
    Author:  Jason Sterne
https://mailarchive.ietf.org/arch/msg/netmod/u_mS5fg9HHnSJlZO4l1hsAANmNA/

https://mailarchive.ietf.org/arch/msg/netmod/P-VgnhUypcN-Od8yFDnCoSOxCkQ/

IPR Call Started
    Author:  Joe Clarke
    Author:  Reshad Rahman
    Author:  Robert Wilton
    Author:  Balazs Lengyel
    Author:  Jason Sterne

https://mailarchive.ietf.org/arch/msg/netmod/P-VgnhUypcN-Od8yFDnCoSOxCkQ/

Request for posting confirmation emailed to previous authors: Balazs Lengyel , Benoit Claise , Jason Sterne , Joe Clarke , Kevin D'Souza , Reshad Rahman , Robert Wilton , netmod-chairs@ietf.org