YANG Semantic Versioning
draft-ietf-netmod-yang-semver-29

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


Thanks for the updates, I'm clearing my discuss.  I think a little more could be done with regards to backwards compatible statements; but this is sufficient and materially better in my opinion.

(My apologies to all in that I put this review in on the wrong versioning draft originally.  yikes.  8-o )

#### 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 comment]
Thanks for the work done in this document and for the discussion while trying to address my previous DISCUSS ballot: https://mailarchive.ietf.org/arch/msg/netmod/Ht5hC1-lp_rjPKE8YNXyPUhPWNM/

Alas, I still find the whole section 4.5 overly complex (see the above email thread) even if sensible... Hence my ABSTAIN ballot.

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

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

(My apologies to all in that I put this review in on the wrong versioning draft originally.  yikes.  8-o )

#### 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 12.2
  In addition to following the rules specified in the IANA
  Considerations section of [I-D.ietf-netmod-yang-module-versioning],
  IANA maintained YANG modules and submodules MUST also include a YANG
  Semver version identifier for all new revisions, as defined in
  Section 4.

  The YANG Semver version associated with the new revision MUST follow
  the rules defined in Section 4.5.
  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.

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/

[Ballot comment]
Thank you to Gyan Mishra for the GENART review.

** Section 6.1
  As IETF modules are not
  expected to require branching in their revision history, the
  '_COMPAT' modifier SHOULD NOT be used in IETF published modules.

Unqualified “SHOULD NOT”.  When is it acceptable to use ‘_COMPAT’ modifier?

[Ballot discuss]

# Éric Vyncke INT AD comments for draft-ietf-netmod-yang-semver-26
CC @evyncke

Thank you for the work put into this document.

Please find below some blocking DISCUSS points (easy to address), some non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education).

Special thanks to Lou Berger for the shepherd's detailed write-up including the WG consensus and the justification of the intended status and the large number of authors.

I hope that this review helps to improve the document,

Regards,

-éric

Note: this ballot comments follow the Markdown syntax of https://github.com/mnot/ietf-comments/tree/main, i.e., they can be processed by a tool to create github issues.

## DISCUSS (blocking)

As noted in https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/, a DISCUSS ballot is a request to have a discussion on the points below; I really think that the document would be improved with a change here, but can be convinced otherwise.

### Section 4.5

In rule #1, the first "SHOULD" has a "unless", but why is the 2nd one not a "MUST" in `in which case the artifact version "X.Y.Z+1_non_compatible" SHOULD be used instead` ?

I am unable to fully understand the rule #2.i `unless that version has already been used for this artifact but with different content, when the artifact version SHOULD be updated ` (which also has a SHOULD without the required IESG guidance per https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/ ) The part that I do not understand is the use of "when" in the sentence.

There are also too many "SHOULD" without any guidance, i.e., why not using "MUST" then ?

### Section 6

Why not a "MUST" in `SHOULD begin with a 0` ?

[Ballot comment]

## COMMENTS (non-blocking)

### Section 4.5

`The following four rules specify` is actually followed by 5 rules ;-)

### Section 4.6

Suggest to add a graphical representation (e.g., the trees used in the beginning of this I-D).

[Ballot discuss]
# IESG review of draft-ietf-netmod-yang-semver-26

CC @MikeBishop

## Discuss

### Section 4.5, paragraph 9
```
        ii  "X.Y.Z_compatible" - the artifact version SHOULD be updated
              to "X.Y.Z+1_compatible".
```
If I'm reading this correctly, this suggests that, from a base of 3.2.0,
versions 3.2.1 (on the main branch) and 3.2.1_compatible (child of
3.2.0_compatible) might contain different changes relative to their parent
versions? This seems guaranteed to confuse users. The natural assumption is that
anything labeled 3.2.1 contains the main branch's 3.2.1 _plus_ whatever changes
are indicated by the suffix.

This seems particularly problematic given the matching rules in 5.2.

[Ballot comment]
## Comments

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

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

Currently waiting on a response to the OPSDIR review.

It was agreed (between the authors and the AD) to send the cluster of three documents, draft-ietf-netmod-yang-filename, draft-ietf-netmod-yang-versioning, and this draft together for IESG review. This is the only document that is left to clear its last hurdle.

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-netmod-yang-semver-24. 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-semver
URI: urn:ietf:params:xml:ns:yang:ietf-yang-semver
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

ID: yang:ietf-yang-library-semver
URI: urn:ietf:params:xml:ns:yang:ietf-yang-library-semver
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-semver
File: [ TBD-at-Registration ]
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:ietf-yang-semver
Prefix: ys
Module:
Reference: [ RFC-to-be ]

Name: ietf-etc
File: [ TBD-at-Registration ]
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:ietf-yang-library-semver
Prefix: yl-semver
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.

Third, section 12.2 of the current draft provides guidance to IANA regarding future registrations of YANG module and submodules. IANA understands that the guidance will also apply to the Expert Review process as defined in [RFC8126]. IANA further understands that the requirement of section 12.2 will apply when new YANG modules are registered and when revisions to existing modules are created.

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 2026-03-03):

From: The IESG
To: IETF-Announce
CC: draft-ietf-netmod-yang-semver@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:  (YANG Semantic Versioning) to Proposed Standard


The IESG has received a request from the Network Modeling WG (netmod) to
consider the following document: - 'YANG Semantic Versioning'
  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 2026-03-03. 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 specifies a YANG extension along with guidelines for
  applying an extended set of semantic versioning rules to revisions of
  YANG artifacts (e.g., modules and packages).  Additionally, this
  document defines a YANG extension for controlling module imports
  based on these modified semantic versioning rules.

  This document updates RFCs 7950, 8407bis, and 8525.




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



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?

It represents somewhat rough consensus of the WG.  With strong support from
some, general support from others and a few objections from those that, have
strong history with the WG, have only periodically been involved with the
development of the overall versioning solution (which this document is part of).

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

See https://mailarchive.ietf.org/arch/msg/netmod/UES0rDg6K12zbqCNhgns8GT3V_0/
for a sense of the objections.  The overall consensus of WG is to proceed,
noting that there are some in the rough.

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

No.

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 ID represents a change in YANG module naming for future versions.

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

This document could impact any future YANG module, but is not technology
specific, and it was felt that the general area reviews would be sufficient.

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.

An earlier version of the document.  A rereview has been requested, but is not expected to yield results that haven't already been discussed in the earlier review and on list.

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?

The listed warning is from an included YANG module.

  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.

A general reread of the module by the shepherd as well as checks via datatracker listed yang validation..


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

Yes.

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?

[6] was reviewed no specific issues identified.

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?

Standards Track as it updates a Standards track document.

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?

yes, see
https://mailarchive.ietf.org/arch/msg/netmod/EMpkuW_Rwmgg2nAZ-GP1RPen5s8/

    If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

NA

13. Has each author, editor, and contributor shown their willingness to be
    listed as such?
Yes

  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 current authors 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.)

There is one warning 'MUST not --> MUST NOT' that should be fixed in the next revision or by the RFC editor.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

I don't think 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?
No

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

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?

No

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

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

The IANA consideration are appropriate and consistent with the document and existing RFCs.

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.

None

[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/

Waiting on shepherd's report to be updated to change the response to question #13 in the report, and add a justification for why there are more than five authors in the draft.

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

It represents somewhat rough consensus of the WG.  With strong support from
some, general support from others and a few objections from those that, have
strong history with the WG, have only periodically been involved with the
development of the overall versioning solution (which this document is part of).

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

See https://mailarchive.ietf.org/arch/msg/netmod/UES0rDg6K12zbqCNhgns8GT3V_0/
for a sense of the objections.  The overall consensus of WG is to proceed,
noting that there are some in the rough.

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

No.

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 ID represents a change in YANG module naming for future versions.

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

This document could impact any future YANG module, but is not technology
specific, and it was felt that the general area reviews would be sufficient.

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.

An earlier version of the document.  A rereview has been requested, but is not expected to yield results that haven't already been discussed in the earlier review and on list.

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?

The listed warning is from an included YANG module.

  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.

A general reread of the module by the shepherd as well as checks via datatracker listed yang validation..


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

Yes.

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?

[6] was reviewed no specific issues identified.

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?

Standards Track as it updates a Standards track document.

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?

yes, see
https://mailarchive.ietf.org/arch/msg/netmod/EMpkuW_Rwmgg2nAZ-GP1RPen5s8/

    If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

NA

13. Has each author, editor, and contributor shown their willingness to be
    listed as such?
Yes

  If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

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

There is one warning 'MUST not --> MUST NOT' that should be fixed in the next revision or by the RFC editor.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

I don't think 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?
No

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

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?

No

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

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

The IANA consideration are appropriate and consistent with the document and existing RFCs.

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.

None

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

It represents somewhat rough consensus of the WG.  With strong support from
some, general support from others and a few objections from those that, have
strong history with the WG, have only periodically been involved with the
development of the overall versioning solution (which this document is part of).

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

See https://mailarchive.ietf.org/arch/msg/netmod/UES0rDg6K12zbqCNhgns8GT3V_0/
for a sense of the objections.  The overall consensus of WG is to proceed,
noting that there are some in the rough.

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

No.

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 ID represents a change in YANG module naming for future versions.

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

This document could impact any future YANG module, but is not technology
specific, and it was felt that the general area reviews would be sufficient.

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.

An earlier version of the document.  A rereview has been requested, but is not expected to yield results that haven't already been discussed in the earlier review and on list.

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?

The listed warning is from an included YANG module.

  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.

A general reread of the module by the shepherd as well as checks via datatracker listed yang validation..


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

Yes.

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?

[6] was reviewed no specific issues identified.

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?

Standards Track as it updates a Standards track document.

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?

yes, see
https://mailarchive.ietf.org/arch/msg/netmod/EMpkuW_Rwmgg2nAZ-GP1RPen5s8/

    If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

NA

13. Has each author, editor, and contributor shown their willingness to be
    listed as such?
Yes

  If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

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

There is one warning 'MUST not --> MUST NOT' that should be fixed in the next revision or by the RFC editor.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

I don't think 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?
No

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

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?

No

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

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

The IANA consideration are appropriate and consistent with the document and existing RFCs.

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.

None

[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/

IPR Call update:
waiting on
        Author:  Balazs Lengyel

responded:
        Author:  Joe Clarke
https://mailarchive.ietf.org/arch/msg/netmod/R0ewHUcGB0E0hxD-d-8tJzU9hVw/
        Author:  Robert Wilton
https://mailarchive.ietf.org/arch/msg/netmod/9Vrj6ZorAp1q-Qpj-8NQgP5zFm8/
        Author:  Reshad Rahman
https://mailarchive.ietf.org/arch/msg/netmod/oV59ZjKJmNyh1chq9WkkCxGeZX4/
        Author:  Jason Sterne
https://mailarchive.ietf.org/arch/msg/netmod/G189nnrBs4prcFhe4T5c_6otkFo/
        Author:  Benoit Claise
https://mailarchive.ietf.org/arch/msg/netmod/WMc05UH2PRQazNLna1T0ZiNp98g/

IPR Call Started:

        Author:  Joe Clarke
        Author:  Robert Wilton
        Author:  Reshad Rahman
        Author:  Balazs Lengyel
        Author:  Jason Sterne
        Author:  Benoit Claise

https://mailarchive.ietf.org/arch/msg/netmod/ItJnvFxvHV6jJYZS5jjh1NB73Fo/

Request for posting confirmation emailed to previous authors: Balazs Lengyel , Benoit Claise , Jason Sterne , Joe Clarke , Kevin D'Souza , Reshad Rahman , Robert Wilton