YANG module file name convention
draft-ietf-netmod-yang-module-filename-14

[Ballot comment]
Thanks for partly (see below) my [previous blocking DISCUSS issues](https://mailarchive.ietf.org/arch/msg/netmod/TVyQNiUVRQX6cZllF_j6vCpd3Ok/)

I am now balloting a non-blocking ABSTAIN as I find the use of potentially 3 filenames for the same content quite confusing...

The text:
```
The ysv:version in the file name MUST match the ysv:version in the most recent revision of the YANG module.

Even though the ysv:version and the file name must match, the authorative source for the ysv:version is the contents in the YANG module, not the file name.
```
also does not specify what to do when the above "MUST" are violated.

[Ballot comment]
Thank you to Joel Halpern for the GENART review.

Thank you for addressing my DISCUSS feedback.

** Section 2.
  In short, the YANG semantic version file name scheme is RECOMMENDED,
  as its use will convey compatibility status at a glance without the
  need to read the module.  If a system or tooling can't handle the
  YANG module file name convention, it is acceptable to not support or
  use the convention defined in this document.

If I am the developer of a YANG module who do I know that "a system or tooling can't handle this new file name convention" whereby allowing me to ignore the recommendation?

[Ballot discuss]
** Section 2.  What does “update” mean? How should implementers take this guidance?

2.  YANG Module File Names
  This section updates Section 5.2 of [RFC7950], Section 5.2 of
  [RFC6020], and Section 3.2 of [RFC9907].

-- On RFC7950 and RFC6020, it appears like the text in this Section 2 should replace all of Section 5.2.  Is that accurate, if so, please be explicit.  Otherwise, it isn't clear how both blocks of text should be concurrently evaluated by an implementer.

-- On RFC7950 and RFC6020, assuming this section is a replacement, how should this guidance be internalized.  Both of these RFCs are defining the “YANG language” applicable if it is used in the IETF context or not.  What does it mean to recommend to someone who isn’t in the IETF ecosystem to “If a revision has an associated YANG semantic version (ysv:version) then a YANG file SHOULD be created that uses the YANG semantic version in the file name.  Additionally, YANG files with or without the revision-date MAY be created”?  The text seemed to be saying “make two files”.  This guidance only seems meaningful in the IANA version control approach being defined here.

-- On RFC9907, how should the text in this Section 2 be merged with Section 3.2 (for RFC9907)?  It looks like the text is different and the subsequent section of this document (Section 2.1) is a more natural swap.

** Section 2.1.  What does “update” mean?

2.1.  Code Components
  This section updates Section 3.2 of [RFC9907].

Please be explicit to say (I believe) this section replaces Section 3.2 of RFC9907.

[Ballot comment]
Thank you to Joel Halpern for the GENART review.

** Section 2.
  In short, the YANG semantic version file name scheme is RECOMMENDED,
  as its use will convey compatibility status at a glance without the
  need to read the module.  If a system or tooling can't handle the
  YANG module file name convention, it is acceptable to not support or
  use the convention defined in this document.

If I am the developer of a YANG module who do I know that "a system or tooling can't handle this new file name convention" whereby allowing me to ignore the recommendation?

[Ballot comment]
Thank you for the short and concise draft.

Thanks to Barry L., and Joel H. for their reviews.  (Both caught the ABNF notation issues about semver / date.)

I would like to echo Éric's comments about if this draft intends to recommend making two copies of the same YANG module?

>If the YANG module (or submodule) has an associated YANG semantic version (ysv:version), then a file name that use the YANG semantic version MUST be created. In addition, a file with the revision date in the file name MAY be created as well.

That is what that paragraph says unless I'm really mistaken.

I don't know what to make of Section 2.1.  The SemVer will indicate some amount of compatibility, but then everything else is caveat emptor?  How would this file naming standard help when there are multiple competing versions?

The working group absolutely wants IANA to create 2 entries for each YANG module that has a SemVer version attached AND wants IANA to ensure that the contents of the modules are identical?  What does identical mean in this case?  Byte-by-byte equivalence?

[Ballot comment]
# IESG review of draft-ietf-netmod-yang-module-filename-11

CC @MikeBishop

## Comments

### Section 2, paragraphs 2 and 6
```
  If a revision has an associated YANG semantic version (ysv:version)
  then a YANG file MUST be created that use the YANG semantic version
  in the file name.  Additionally, a YANG file with the revision-date
  MAY be created.  The name of the files SHOULD be of the form:
```
```
    If the YANG module (or submodule) has an associated YANG semantic
    version (ysv:version), then a file name that use the YANG semantic
    version MUST be created.  In addition, a file with the revision date
    in the file name MAY be created as well.
```
Are these paragraphs duplicative?  They seem to be saying the same thing.

### DOWNREFs

DOWNREF `[I-D.ietf-netmod-iana-yang-guidance]` from this Proposed Standard to
Informational `draft-ietf-netmod-iana-yang-guidance`. (For IESG
discussion. It seems this DOWNREF was not mentioned in the Last Call and also
seems to not appear in the DOWNREF registry.)

## 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.2, paragraph 1
```
-    it possible to quickly identify the module revision; compared to
-                                                      - ^ ^^^^^^^ -
+    it possible to quickly identify the module revision without
+                                                        ^^^^ ^
```

#### Section 2, paragraph 5
```
-    as its use will convey compatibility status at a glance withouth the
-                                                                  -
```

### Grammar/style

### Section 1.2, paragraph 1
```
    The motivation for using YANG semantic version instead of revision
    date is that it conveys additional information to the user.  A
```
Lots of extra words here. "Using ... date conveys...."

#### Section 1.2, paragraph 1
```
-    available as early as possible, i.e. in the module file name, makes
-            ---------------------------                        -
```

#### Section 2.1, paragraph 1
```
-    As can be seen above, all valid identifiers for YANG semantic version
-    ----------------------
```

#### Section 2.1, paragraph 3
```
-    One consequence of this is that there might exist two modules derived
+    There might exist two modules derived
```

[Ballot discuss]
Thanks for the work done in the document. Nevertheless some non-blocking comments:

### Section 2

In `The name of the files SHOULD be of the form` the SHOULD has no guidance required per https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/

This also contradicts (apparently) the later sentence `then a file name that use the YANG semantic version MUST be created`.

It is also unclear whether TWO files are to be created?

[Ballot comment]

### Abstract

s/This document presents/This document *defines*/ as it is a PS I-D.

### Section 2

Should the ASCII code for '@' be specified as well ?

[Ballot discuss]
Hi Per,

Thank you for the effort put into this document.

Also, thanks to Aihua Guo for the OPSDIR and Per for engaging and addressing that review.

Please find below some points for DISCUSSion:

# Guidance

The name convention defined so far in various RFCs are as follows:

RFC 6020

  YANG modules and submodules are typically stored in files, one module
  or submodule per file.  The name of the file SHOULD be of the form:

    module-or-submodule-name ['@' revision-date] ( '.yang' / '.yin' )

RFC 7950

  YANG modules and submodules are typically stored in files, one
  "module" or "submodule" statement per file.  The name of the file
  SHOULD be of the form:

    module-or-submodule-name ['@' revision-date] ( '.yang' / '.yin' )

RFC 9907:

  The "" tag MUST be followed by a string identifying the
  file name specified in Section 5.2 of [RFC7950].  The name string
  form that includes the revision date SHOULD be used.  The revision
  date MUST match the date used in the most recent revision of the
  module.

The convention is drawn with a clear guidance on what a name file name layout may look like.

This document adopts a formulation that I think is ambiguous.

CURRENT:
  If a revision has an associated YANG semantic version (ysv:version)
  then a YANG file MUST be created that use the YANG semantic version
  in the file name.  Additionally, a YANG file with the revision-date
  MAY be created.  The name of the files SHOULD be of the form:

## I don’t understand “created” part as that semver is already recorded in an existing file.

## Why isn’t sufficient to follow the same pattern in 6020/7950/9907 and focus mainly on the name pattern?

## Because of tooling and other deployment constraints, do we really need to have that MUST? Shouldn’t that be a SHOULD?

# Doesn’t CURRENT 2 cover the behavior in CURRENT 1?

CURRENT 1:
  If a revision has an associated YANG semantic version (ysv:version)
  then a YANG file MUST be created that use the YANG semantic version
  in the file name.  Additionally, a YANG file with the revision-date
  MAY be created.  The name of the files SHOULD be of the form:

CURRENT 2

  If the YANG module (or submodule) has an associated YANG semantic
  version (ysv:version), then a file name that use the YANG semantic
  version MUST be created.  In addition, a file with the revision date
  in the file name MAY be created as well.

# Sanity Check

Existing guidance has a MUST to make sure the name mirrors what is in the file. I think that something similar is needed for this convention as well.

RFC 9907:
  The revision
  date MUST match the date used in the most recent revision of the
  module.

# IANA Actions vs. Authors Actions

CURRENT:
  The registry MUST create a file with a YANG semantic version if the
  YANG module (or submodule) has an associated YANG semantic version
  (ysv:version).  The registry MUST also create a file with the YANG
  module using a file name with the revision date.  It MUST be ensured
  that the files' contents are identical.


## The IANA action is to update the registry to support both conventional and new layout.

## Except IANA-maintained modules, IANA does not “create” files. Shouldn’t that part of the guidance be for authors?

## Please avoid normative language in IANA Section per the IESG statement on the matter.

[Ballot comment]
# Authoritative source

CURRENT:
  in the module file name, makes
  it possible to quickly identify the module revision;

As there may be deviation between a filename and its content, inferring the ver from the filename may be misleading.

I think that we need a caution that the authoritative source is still what is in the file itself, not the filename.

# The promise below is true when a check is in place (see my comment about Sanity Check)

CURRENT:
  Having
  the YANG semantic version visible in the file name will make it
  easier to handle large sets of YANG modules.

# More Operational Considerations

I suggest to cover the following items as well:

* A statement that the convention does not impact modules already in use.
* A brief text about tooling impact, including migration in deployment


# Nits

##

OLD: This document presents YANG module file name convention

NEW: This document presents a YANG module file name convention

## won't age well

OLD: the current YANG module file name using

NEW: the YANG module file name using

##

OLD: This document defines the YANG module file name convention. 

NEW: This document defines a YANG module file name convention. 

##

s/a glance withouth the/ a glance without the

Cheers,
Med

[Ballot comment]
Please consider these comments when preparing the next revision of this document:

I think the abstract ought to explain this defines the method, not describes it, e.g.g:
/This document presents YANG module file name convention/This document defines the YANG module file name convention/

I couldn't decide if this ought to be lower case or upper case 'RECOMMENDED', please rephrase to avoid this comment:
/In short, the YANG semantic version file name scheme is recommended/

I don't understand the requirement in section 4 that states:
/It MUST be ensured that the files' contents are identical./

NiTs:
/withouth/without/
/that use/that uses/
/MAY be created as well/MAY be created./

Best wishes,
Gorry

The change to use @ in the filename for semver from # is a significant change, and has come after WGLC. As such, I am requesting that the chairs run a short WGLC, just on that change, of maybe a week, to make sure there are no objections.

I see a couple of reviews have been performed as part of the IETF LC on the document. The reviews have come back with questions and comments. Authors, can you take a look at the reviews and respond, please?

IESG/Authors/WG Chairs:

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

IANA understands that, upon approval of this document, there is a single action which we must complete.

In Section 3 of the current draft, the authors state:

"The "YANG Module Names" Registry need to support YANG modules with both the existing file name convention and the file name convention defined in this document."

IANA Question --> We understand these changes are outlined in another guidance document, draft-ietf-netmod-iana-yang-guidance. We have some questions still pending in a separate thread about the guidance document, but could a reference to this document be added to this IC?

Also, would any changes also be needed to the IETF namespace registry located at:

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

Section 3 continues with the text:

"The registry MUST create a file with a YANG semantic version if the YANG module (or submodule) has an associated YANG semantic version (ysv:version). The registry MUST also create a file with the YANG module using a file name with the revision date. It MUST be ensured that the files' contents are identical."

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 3 will apply when new YANG modules are registered and when revisions to existing modules are created.

IANA also has a concern about the proper encoding of an URI associated with the file name; for the example in the document, "example-module#2.3.1_non_compatible+build2237refM443ss.yang", the # character would be interpreted as an URL fragment identifier and not as part of the file name, so we would need to encode this properly in the relevant URL (https://www.iana.org/assignments/yang-parameters/example-module%232.3.1_non_compatible+build2237refM443ss.yang).

We understand that this is the only action required to be completed upon approval of this document.

NOTE: The action 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 action 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

Request for IETF Last Call review by GENART Completed: Ready with Nits. Reviewer: Joel Halpern. Sent review to list. Submission of review completed at an earlier date.

The following Last Call announcement was sent out (ends 2026-03-03):

From: The IESG
To: IETF-Announce
CC: draft-ietf-netmod-yang-module-filename@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 module file name convention) to Proposed Standard


The IESG has received a request from the Network Modeling WG (netmod) to
consider the following document: - 'YANG module file name convention'
  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 presents YANG module file name convention.  The
  convention extends the current YANG module file name using
  revision-date, with the YANG semantic version extension.  The YANG
  semantic version extension allows for an informative version to be
  associated with a particular YANG module revision.

  This documents updates RFCs 6020, 7950, and draft-ietf-netmod-
  rfc8407bis.




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



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

As indicated on the mike in 124, I am waiting on the author to update the draft to change the MAY to a MUST in the draft as it relates to whether the file with the semver in the name would be created.

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

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

The need for (another) YANG doctor review was discussed with the AD. The AD decided to progress as is.

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? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

It does not contain a YANG module.

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.

NA

## 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.  BCP was also considered, but it was felt that this was the right track since 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/BEQppMN_cWRSN1xHlmfs3mknvqE/

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


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

All substantive issues have been corrected.

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

[update after next rev of document published]

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.

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

The need for (another) YANG doctor review was discussed with the AD. The AD decided to progress as is.

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? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

It does not contain a YANG module.

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.

NA

## 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.  BCP was also considered, but it was felt that this was the right track since 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/BEQppMN_cWRSN1xHlmfs3mknvqE/

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


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

All substantive issues have been corrected.

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

[update after next rev of document published]

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.

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

The need for (another) YANG doctor review was discussed with the AD. The AD decided to progress as is.

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? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

It does not contain a YANG module.

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.

NA

## 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.  BCP was also considered, but it was felt that this was the right track since 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/BEQppMN_cWRSN1xHlmfs3mknvqE/

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


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

All substantive issues have been corrected.

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

Yes.

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

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

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

The need for (another) YANG doctor review was discussed with the AD. The AD decided to progress as is.

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? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

It does not contain a YANG module.

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.

NA

## 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.  BCP was also considered, but it was felt that this was the right track since 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/BEQppMN_cWRSN1xHlmfs3mknvqE/

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


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

Yes. There are some warnings.

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

Yes.

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

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

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

The need for (another) YANG doctor review was discussed with the AD. The AD decided to progress as is.

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? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

It does not contain a YANG module.

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.

NA

## 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.  BCP was also considered, but it was felt that this was the right track since 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? 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/browse/netmod/?q=draft-ietf-netmod-yang-module-filename

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

Yes. There are some warnings.

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

Yes.

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

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

Closed request for Early review by YANGDOCTORS with state 'Team Will not Review Document': Closed after confirmation of the AD Mahesh Jethanandani. Draft does not include a YANG module.