Guidelines for Authors and Reviewers of Documents Containing YANG Data Models
draft-ietf-netmod-rfc8407bis-28

[Ballot comment]
Thanks to the authors and the WG for your work on this important document.

After discussing with the editor (Med) and looking at the WG inputs, I am changing my position from DISCUSS to NO OBJ. I understand that the WG has a specific scope in mind and there is hesitation in taking that one more step towards updating the text to truly enforce this BCP for all of the IETF Stream documents instead of just Standards Track. We will need to do with relying on the authors and reviewers best judgement.

Much has been gained and improved by this document and on balance I don't wish to stand in the way of taking this to RFC.

I appreciate the authors and the WG taking the time to discuss my DISCUSS.


==== Outstanding DISCUSS position changed to NO OBJ =====
I have one high-level point that I would like to discuss with the authors and the WG since is it not clear - this is regarding experimental and information track YANG module documents in IETF stream.

At a high-level, I would like to discuss and understand whether YANG model documents can be experimental or informational. I think the answer is YES? But this is not clear. A follow-on question: what is the guidance for YANG models specified in standards track document being augmented by modules in experimental or informational track document? Is there any restrictions? I think the answer is NO? But again, this is not clear.

Please also see in the comments sections for some concerns that are related to this topic - those are provided inline for better context.

UPDATE for v26: Thanks for the new text to help address my concerns. There are still some remnants in the text related to this point that I am listing in the comments below with specific suggestions.

=== Open Comments ====

Please find below some comments provided inline in the idnits output of v26 of this document.


234 1.1.  Changes Since RFC 8407

Since this is an exhaustive list of changes, can it be moved to the
appendix section? First time (new) readers don't need to be bothered by this in
the body of the RFC?

696 3.7.  Security Considerations Section

698   Each specification that defines one or more modules MUST contain a
699   section that discusses security considerations relevant to those
700   modules.

702   Unless the modules comply with [RFC8791] or define YANG extensions
703   (e.g., [RFC7952]), the security section MUST be modeled after the
704   latest approved template (available at
705   ).

I am not sure if a wiki pointer is appropriate here. If it is a BCP
level thing (beyond what is in 3.7.1 below) then please cover inline and
remove the URL. It does not seem appropriate to me to have a normative MUST
reference to a webpage that is not updated via IETF consensus.

959 3.10.  Validation Tools

961   All modules need to be validated before submission in an I-D.  The
962   'pyang' YANG compiler is freely available from GitHub:

964    

Should these GitHub links not be moved into the informative reference
section?

1042 4.  YANG Usage Guidelines

1044   Modules in IETF Standards Track specifications MUST comply with all
1045   syntactic and semantic requirements of YANG 1.1 [RFC7950].  See the

This is related to my DISCUSS. Suggest replace "IETF Standards Track
specifications" with "IETF Stream documents"


1060 4.1.  Module Naming Conventions

1062   Normative modules contained in Standards Track documents MUST be
1063   named according to the guidelines in the IANA Considerations section
1064   of [RFC6020].

The referenced RFC talks about "IETF stream documents" and not
Standards Track documents alone. This is related to my DISCUSS. Suggest
to replace "contained in Standards Track documents" with "contained in
IETF stream documents" or even better with "contained in documents".

1160   For convenience, prefix values of example modules SHOULD be prefixed
1161   with "ex" or similar patterns.  In doing so, readers of example
1162   modules or tree diagrams that mix both example and standard modules
1163   can easily identify example parts

This is kind of something that I caught when looking for "standard". In
this case, I believe it should have been ... s/standard/normative ? If you
look for "standard module" (case insensitive search) there are more such
occurrences to be found. I believe they should also be changed similarly.


1662   The "organization" statement MUST be present.  If the module is
1663   contained in a document intended for IETF Standards Track status,
1664   then the organization SHOULD be the IETF working group (WG) chartered
1665   to write the document.  Exceptions may be example modules, IANA-
1666   maintained modules, or modules contained in AD-sponsored documents.
1667   For other standards organizations, a similar approach is also
1668   suggested.

1670   The "contact" statement MUST be present.  If the module is contained
1671   in a document intended for Standards Track status, then the WG web
1672   and mailing information SHOULD be present, and the main document
1673   author or editor contact information SHOULD be present.  If
1674   additional authors or editors exist, their contact information MAY be
1675   present.  There is no need to include the contact information for WG
1676   Chairs.

This is another instance which talks only about standards track. This
is related to my DISCUSS.

SUGGEST:
The "organization" statement MUST be present. If the module is contained in an IETF Stream document, then the organization SHOULD be the IETF working group (WG) chartered to write the document. Exceptions may be example modules, IANA-maintained modules, or modules contained in AD-sponsored documents. For other standards organizations, a similar approach is also suggested.

The "contact" statement MUST be present. If the module is contained in an IETF Stream document, then the WG web and mailing information SHOULD be present, and the main document author or editor contact information SHOULD be present. If additional authors or editors exist, their contact information MAY be present. There is no need to include the contact information for WG Chairs. Exceptions may be example modules, IANA-maintained modules, or modules contained in AD-sponsored documents. For other standards organizations, a similar approach is also suggested.


1823   The following example URNs would be valid namespace statement values
1824   for Standards Track modules:

1826       urn:ietf:params:xml:ns:yang:ietf-netconf-partial-lock

1828       urn:ietf:params:xml:ns:yang:ietf-netconf-state

1830       urn:ietf:params:xml:ns:yang:ietf-netconf

1832   Note that a different URN prefix string SHOULD be used for modules
1833   that are not Standards Track.  The string SHOULD be selected
1834   according to the guidelines in Section 5.3 of [RFC7950].

1836   The following URIs exemplify what might be used by modules that are
1837   not Standards Track.

This is again limiting to standards track document and related to
my DISCUSS. Suggest replacing "Standards Track" with "IETF Stream document"



3205 4.30.3.  Guidance for Writing the IANA Considerations for RFCs Defining
3206         IANA-Maintained Modules

What is missing is guidance for future documents (i.e. not RFC IIII)
that allocate code points from a registry that is associated with an
IANA-maintained YANG module. I guess the instruction for such a document is to
not give any specific instruction related to such a module (e.g., don't try to
repeat the updated module in appendix or such?) - all of this should be taken
care of by IANA automatically based on instructions provided in RFC IIII ?

[Ballot comment]
I think Best Current Practice documents are particularly valuable and are best when they are accessible to a variety of readers. Hence my various comments below to improve the document and clarify what is actually required by contributors.

I am balloting 'no objection', but I do have comments that I expect to be considered by the editors and responsible AD. Please especially note comment 3

===

1. Thank you to Joe Touch for the transport review provided by the WIT ART.

I also share the comment that this draft normatively refers to the use of QUIC as a transport, but does reference (informatively) the work to develop that support. Please do add a reference to draft-ietf-netconf-over-quic.

Please also review the other text included in that review and update as needed.
===
2. In section 4.5:
I could not understand this as a requirement, please consider rewriting this in different words:
/From
  that perspective, it is RECOMMENDED to avoid defining constraints on
  state data that would hinder the detection by a management system of
  abnormal behaviors of a managed entity./
- If this is an RFC 2119 recommendation, what SHOULD be done?
- If this a SHOULD/RECOMMENDED please state when this requirement can be safely relaxed.
===
3. In section 4.9 (Namespace Assignments):
/  It is RECOMMENDED that only valid YANG modules be included in
  documents, whether or not the modules are published yet./
- I think the text needs to explain what is needed to satisfy the RFC 2119 recommendation. Does this apply to Internet draft revisions? (That would seem really a hard requirement, or submitted documents, or documents ready for review.)
- The current recommendation does not make me feel like I know what to do if the recommendation is not followed and what this refers to.
===
4. In section 4.2.3:
/It is RECOMMENDED to augment only the "/foo" hierarchy of the base model./
- Why does this use the keyword /RECOMMEND/ rather than the word /SHOULD/ here. To me this mix of terms obscures the actual requirement: In the previous and next text in the para uses SHOULD - and to me these have the same requirement level!
===
5. Sorry,I was not sure what was actually intended by "may be", is this (or something similar) clearer:
/Exceptions may be example modules, IANA-maintained modules, or modules contained in AD-sponsored documents.
/
Exceptions include: example modules, IANA-maintained modules, or modules contained in AD-sponsored documents.
/
===
6.
I could not work out what to take away from the text below in Section 4.30.1:
/Also, some YANG modules include parameters and values directly in a
module that is not maintained by IANA while these are populated in an
IANA registry.  Such a design is suboptimal as it creates another
source of information that may deviate from the IANA registry as new
values are assigned or some values are deprecated.
/
- I think this could be editorial: It would be useful to be clear if this an example of has happened, or what is needed, or it made some other statement.
===
7.
What does "encourage" mean in the next para, this is also unclear to me:
/For the sake of consistency and ability to support new values while
maintaining IANA registries as the unique authoritative source of
information, this document encourages the use of IANA-maintained
modules as the single source of information./
... but then I see Sect 4.30.2 provides guidelines, is /encourages/therefore provides guidance/ ... or maybe I still misunderstood?
===
8. In Sect 4.30:
/It is
  RECOMMENDED that the reasoning for the design choice is documented in
  the companion specification that registers an IANA-maintained module./
- I think this could simply be required (MUST)?
===
9.
/It is RECOMMENDED to include the URL from where to retrieve the
  recent version of the module. /
- I suggest you do not use the keyword /RECOMMEND/ here and replace the word by /SHOULD/. To me this mix of terms obscures the actual requirement. SHOULD is used in other parts of the same section!
===
10.
/Specifically, if the name begins with a number, it is
        RECOMMENDED to spell out the number when used as an identifier.
        IANA should be provided with instructions to perform such task./
- This confused me (sorry).
- Specifically please explain what /spell out/ means in this context.
- I was very puzzled why this BCP does not require a document to provide IANA with the instructions to perform their task. ... If there is sometimes a need for IANA to ask for this separately, could this be explained. AT first sight, it seems like a lot of extra flexibility for little benefit.
===
11.
/when creating a new "identity" statement name or a new "enum"
        statement, it is RECOMMENDED to mirror the name (if present) as
        recorded in the IANA registry./
- Please explain in the text why? And I am a little unsure what "mirror" means in this context, please use a different word.
- Why is this not a RFC 2119 "SHOULD:, as used in other parts of the same section?
===
12.
In section 4.30.3.1:
I read this text:
/  When the "iana-foo" YANG module is updated, a new "revision"
statement with a unique revision date must be added in front of the
existing revision statements. The "revision" statement MUST contain
both "description" and "reference" substatements as follows./
- Maybe I do not understand, but this seems to say you need (but are not required to provide a unique revision date in front of the existing revision statements, is that correct? (in this case I'd really like to see /MUST? or change to /needs/ ...
- I also think this would be better as a separate paragraph to avoid confusion with the MUST that follows.
===
13.
I am not sure if there is intentional variation in the requirements for the "description" sub statement in the various template in 4.30.3. Could the common requirements, if any, use identical text?
===

Finally, thank you for takin on the task of updating this Best Current Practice!

[Ballot discuss]
Thanks to the authors and the WG for your work on this important document.

I have one high-level point that I would like to discuss with the authors and the WG since is it not clear - this is regarding experimental and information track YANG module documents in IETF stream.

At a high-level, I would like to discuss and understand whether YANG model documents can be experimental or informational. I think the answer is YES? But this is not clear. A follow-on question: what is the guidance for YANG models specified in standards track document being augmented by modules in experimental or informational track document? Is there any restrictions? I think the answer is NO? But again, this is not clear.

Please also see in the comments sections for some concerns that are related to this topic - those are provided inline for better context.

UPDATE for v26: Thanks for the new text to help address my concerns. There are still some remnants in the text related to this point that I am listing in the comments below with specific suggestions.

[Ballot comment]
Please find below some comments provided inline in the idnits output of v26 of this document.


234 1.1.  Changes Since RFC 8407

Since this is an exhaustive list of changes, can it be moved to the
appendix section? First time (new) readers don't need to be bothered by this in
the body of the RFC?

696 3.7.  Security Considerations Section

698   Each specification that defines one or more modules MUST contain a
699   section that discusses security considerations relevant to those
700   modules.

702   Unless the modules comply with [RFC8791] or define YANG extensions
703   (e.g., [RFC7952]), the security section MUST be modeled after the
704   latest approved template (available at
705   ).

I am not sure if a wiki pointer is appropriate here. If it is a BCP
level thing (beyond what is in 3.7.1 below) then please cover inline and
remove the URL. It does not seem appropriate to me to have a normative MUST
reference to a webpage that is not updated via IETF consensus.

959 3.10.  Validation Tools

961   All modules need to be validated before submission in an I-D.  The
962   'pyang' YANG compiler is freely available from GitHub:

964    

Should these GitHub links not be moved into the informative reference
section?

1042 4.  YANG Usage Guidelines

1044   Modules in IETF Standards Track specifications MUST comply with all
1045   syntactic and semantic requirements of YANG 1.1 [RFC7950].  See the

This is related to my DISCUSS. Suggest replace "IETF Standards Track
specifications" with "IETF Stream documents"


1060 4.1.  Module Naming Conventions

1062   Normative modules contained in Standards Track documents MUST be
1063   named according to the guidelines in the IANA Considerations section
1064   of [RFC6020].

The referenced RFC talks about "IETF stream documents" and not
Standards Track documents alone. This is related to my DISCUSS. Suggest
to replace "contained in Standards Track documents" with "contained in
IETF stream documents" or even better with "contained in documents".

1160   For convenience, prefix values of example modules SHOULD be prefixed
1161   with "ex" or similar patterns.  In doing so, readers of example
1162   modules or tree diagrams that mix both example and standard modules
1163   can easily identify example parts

This is kind of something that I caught when looking for "standard". In
this case, I believe it should have been ... s/standard/normative ? If you
look for "standard module" (case insensitive search) there are more such
occurrences to be found. I believe they should also be changed similarly.


1662   The "organization" statement MUST be present.  If the module is
1663   contained in a document intended for IETF Standards Track status,
1664   then the organization SHOULD be the IETF working group (WG) chartered
1665   to write the document.  Exceptions may be example modules, IANA-
1666   maintained modules, or modules contained in AD-sponsored documents.
1667   For other standards organizations, a similar approach is also
1668   suggested.

1670   The "contact" statement MUST be present.  If the module is contained
1671   in a document intended for Standards Track status, then the WG web
1672   and mailing information SHOULD be present, and the main document
1673   author or editor contact information SHOULD be present.  If
1674   additional authors or editors exist, their contact information MAY be
1675   present.  There is no need to include the contact information for WG
1676   Chairs.

This is another instance which talks only about standards track. This
is related to my DISCUSS.

SUGGEST:
The "organization" statement MUST be present. If the module is contained in an IETF Stream document, then the organization SHOULD be the IETF working group (WG) chartered to write the document. Exceptions may be example modules, IANA-maintained modules, or modules contained in AD-sponsored documents. For other standards organizations, a similar approach is also suggested.

The "contact" statement MUST be present. If the module is contained in an IETF Stream document, then the WG web and mailing information SHOULD be present, and the main document author or editor contact information SHOULD be present. If additional authors or editors exist, their contact information MAY be present. There is no need to include the contact information for WG Chairs. Exceptions may be example modules, IANA-maintained modules, or modules contained in AD-sponsored documents. For other standards organizations, a similar approach is also suggested.


1823   The following example URNs would be valid namespace statement values
1824   for Standards Track modules:

1826       urn:ietf:params:xml:ns:yang:ietf-netconf-partial-lock

1828       urn:ietf:params:xml:ns:yang:ietf-netconf-state

1830       urn:ietf:params:xml:ns:yang:ietf-netconf

1832   Note that a different URN prefix string SHOULD be used for modules
1833   that are not Standards Track.  The string SHOULD be selected
1834   according to the guidelines in Section 5.3 of [RFC7950].

1836   The following URIs exemplify what might be used by modules that are
1837   not Standards Track.

This is again limiting to standards track document and related to
my DISCUSS. Suggest replacing "Standards Track" with "IETF Stream document"



3205 4.30.3.  Guidance for Writing the IANA Considerations for RFCs Defining
3206         IANA-Maintained Modules

What is missing is guidance for future documents (i.e. not RFC IIII)
that allocate code points from a registry that is associated with an
IANA-maintained YANG module. I guess the instruction for such a document is to
not give any specific instruction related to such a module (e.g., don't try to
repeat the updated module in appendix or such?) - all of this should be taken
care of by IANA automatically based on instructions provided in RFC IIII ?

[Ballot comment]
# Andy Newton, ART AD, comments for draft-ietf-netmod-rfc8407bis-25
CC @anewton1998

* line numbers:
  - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-netmod-rfc8407bis-25.txt&submitcheck=True

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

Thanks to the authors for all the hard work creating this document.
I have no objection to its publication as an RFC.

[Ballot comment]
I am balloting 'no objection', but I am serious about these comments.  It should always be a goal for an RFC (at whatever level) to be clear, concise, and understandable.  My comments below all reflect that goal:

Thank you to Yoav Nir for their secdir review.

Section 1.1:  This is long and incomprehensible unless one is intimately familiar with the original RFC.  Recommend moving it to either a later section or to an Appendix.

Section 3.7, general:  The word 'especially' is not defined.  What does 'especially disruptive' vs merely 'disruptive' mean?  What about 'especially sensitive information' vs merely 'sensitive information'?  Either remove these descriptors or define what they mean.

Section 3.7.1, para 3:  Why not 'MUST use' vs 'have to use' for both the requirement for secure transport and mutual authentication?

Section 3.7.1:  This comment applies to every place in this section that uses the word 'particularly'.  What makes data 'particularly sensitive'?  Is it defined somewhere?  Again, the descriptor (particularly) doesn't actually help to define what makes data more or less sensitive, or contain more or less vulnerabilities.  Is it merely up to the editors of the draft to decide?  What if I, as the editor, decide that the lifetime symmetric key variable, written into a Yang data module isn't 'particularly sensitive', would that be ok?  As it is my choice as the editor? [I will note that RFC8341 puts the word 'particular' in front of nearly every noun in the draft, also with no explanation of what makes any of those users, requests, protocols, etc special, or hmmm particular.]

Section 6, last sentence:  Are there new or increased security risks that don't need to be discussed?  Please remove the phrase 'that need to be discussed' as it just raises more questions about what isn't being said.

[Ballot discuss]
Thanks to the authors and the WG for your work on this important document.

I have one high-level point that I would like to discuss with the authors and the WG since is it not clear - this is regarding experimental and information track YANG module documents in IETF stream.

At a high-level, I would like to discuss and understand whether YANG model documents can be experimental or informational. I think the answer is YES? But this is not clear. A follow-on question: what is the guidance for YANG models specified in standards track document being augmented by modules in experimental or informational track
document? I think the answer is NO? But again, this is not clear.

Please also see in the comments sections for some concerns that are related to this topic - those are provided inline for better context.

[Ballot comment]
Please find below some comments provided inline in the idnits output of v25 of this document.

14 Abstract

16   This memo provides guidelines for authors and reviewers of

s/memo/document


232 1.1.  Changes Since RFC 8407

Since this is an exhaustive list of changes, can it be moved to the
appendix section? First time (new) readers don't need to be bothered by this in
the body of the RFC?

688   Unless the modules comply with [RFC8791] or define YANG extensions
689   (e.g., [RFC7952]), the security section MUST be modeled after the
690   latest approved template (available at
691   ).

I am not sure if a wiki pointer is appropriate here. If it is a BCP
level thing (beyond what is in 3.7.1 below) then please cover inline and
remove the URL.


847 3.8.  IANA Considerations Section

849   In order to comply with IESG policy as set forth in
850   , every I-D that is
851   submitted to the IESG for publication MUST contain an IANA
852   Considerations section.  The requirements for this section vary

The text gives an impression of referencing an IETF webpage (that is not updated via IETF consensus process) for a  normative (MUST) directive. More problematic is that it is not scoped to YANG documents alone. Given that the URL is already present in the template, would there be an issue if the text were to simply say "Every I-D specifying a YANG module that is submitted to the IESG for publication MUST contain an IANA Considerations section." ?


884 3.8.2.  Documents That Extend an Existing Namespace

886   It is possible to extend an existing namespace using a YANG submodule
887   that belongs to an existing module already administered by IANA.  In
888   this case, the document containing the main module MUST be updated to
889   use the latest revision of the submodule.

What is exactly meant by "the document containing the main module MUST
be updated"? That "document" has already been published as an RFC and that module
is now being maintained by IANA on its website. Is this something that IANA needs
to take care of by itself (I guess this is the case)? Or is it something that each
new document doing such updates need to ask IANA to do this? Please clarify.


954 3.10.  Validation Tools

956   All modules need to be validated before submission in an I-D.  The
957   'pyang' YANG compiler is freely available from GitHub:

959    

Should these GitHub links not be moved into the informative reference
section?


1053 4.1.  Module Naming Conventions

1055   Normative modules contained in Standards Track documents MUST be
1056   named according to the guidelines in the IANA Considerations section
1057   of [RFC6020].

The referenced RFC talks about "IETF stream documents" and not
Standards Track documents alone. Could you please review all occurrences of
reference to standards track document to review for correctness? They should
also cover experimental and informational?


1605 4.7.  YANG Definition Lifecycle Management

1607   The YANG status statement MUST be present within a definition if its
1608   value is "deprecated" or "obsolete".  The status SHOULD NOT be
1609   changed from "current" directly to "obsolete".  An object SHOULD be
1610   available for at least one year with a "deprecated" status before it
1611   is changed to "obsolete".

This at least one year limit - does it include time as an I-D or it is
so that it can be changed by another RFC that gets published one year after
the publication of the previous one. Can you please clarify?


1656   The "organization" statement MUST be present.  If the module is
1657   contained in a document intended for IETF Standards Track status,
1658   then the organization SHOULD be the IETF working group (WG) chartered
1659   to write the document.  For other standards organizations, a similar
1660   approach is also suggested.

This is another instance which talks only about standards track - what
about the others? Also, not all standards track need to come via WG - some may
be AD sponsored? Why not allow "IETF" alone for AD sponsored?


1824   Note that a different URN prefix string SHOULD be used for modules
1825   that are not Standards Track.  The string SHOULD be selected
1826   according to the guidelines in [RFC7950].

Which specific section of RFC7950 is being referenced here? And what
is the guideline for experimental and informational track documents with YANG
modules?

3154       The initial version of this YANG module is part of RFC IIII; see
3155       the RFC itself for full legal notices.

This RFC IIII is used here and other places in the context of the IANA
related aspects. The use is described in the following paragraph but can you
also please cover in Section 2?



3196 4.30.3.  Guidance for Writing the IANA Considerations for RFCs Defining
3197         IANA-Maintained Modules

What is missing is guidance for future documents (i.e. not RFC IIII)
that allocate code points from a registry that is associated with an
IANA-maintained YANG module. I guess the instruction for such a document is to
not give any specific instruction related to such a module (e.g., don't try to
repeat the updated module in appendix or such?) - all of this should be taken
care of by IANA automatically based on instructions provided in RFC IIII ?


3257   *  A note that unassigned or reserved values must not be present in
3258       the IANA-maintained module.

Is that a MUST NOT? There is a mix of lower and upper case normative
language. Some consistency would be good.

3623 7.1.  Normative References

3625   [ID-Guidelines]
3626               IETF, "Guidelines to Authors of Internet-Drafts", n.d.,
3627               .

Is it normal for this to be a normative reference to an IETF webpage
that is not updated via IETF consensus? Why not move it to informative references?

[Ballot comment]
# Orie Steele, ART AD, comments for draft-ietf-netmod-rfc8407bis-25
CC @OR13

* line numbers:
  - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-netmod-rfc8407bis-25.txt&submitcheck=True

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

### Why not MUST?

#### Tree Diagrams

```
561   YANG tree diagrams provide a concise representation of a YANG module
562   and SHOULD be included to help readers understand YANG module
563   structure.  Guidelines on tree diagrams can be found in Section 3 of
564   [RFC8340].  Tree diagrams longer than one page SHOULD be included in
565   an appendix, i.e., not in the main body of the document.
```

Under which cases should tree diagrams not be included?


#### Consistent indentation

```
597   Consistent indentation SHOULD be used for all examples, including
598   YANG fragments and protocol message instance data.  If line wrapping
```

```
677   Consistent indentation and formatting SHOULD be used in all YANG
678   statements within a module.
```

What is consistent formatting?
Why are these SHOULDs, when are exceptions expected or encouraged?

#### Module names

```
1059   A distinctive word or abbreviation (e.g., protocol name or working
1060   group abbreviation) SHOULD be used in the module name.  If new
```

### IESG as Contact for YANG Modules

```
900       URI:
901       Registrant Contact:  The IESG.
902       XML: N/A; the requested URI is an XML namespace.
```

I recognize this comes from the XML namespace registration process...
Is the IESG truly the best contact choice for these YANG registration templates now?

#### include prefix in YANG identity

```
1518   XPath expressions that contain a literal value representing a YANG
1519   identity SHOULD always include the declared prefix of the module
1520   where the identity is defined.
```

When is this not a good idea?

#### IETF WG as organization

```
1656   The "organization" statement MUST be present.  If the module is
1657   contained in a document intended for IETF Standards Track status,
1658   then the organization SHOULD be the IETF working group (WG) chartered
1659   to write the document.  For other standards organizations, a similar
1660   approach is also suggested.
```

When is a different organization name than the IETF WG recommended?


### define validated

```
1010   the YANG module(s).  Examples MUST be validated.  Refer to
```

This implies validation, but does not require tools to agree on outcome.
Not being a YANG expert, I'm not sure if there is more useful guidance to be provided here.


### Code markers and text

```
1034   In order to ease extraction and validation of examples, it is
1035   RECOMMENDED to use code markers.
```

Does this imply that consumers of yang should also prefer to use representations that support code markers?


### How to check for uniqueness

```
1065   All published module names MUST be unique.  For a YANG module
1066   published in an RFC, this uniqueness is guaranteed by IANA
1067   (Section 14 of [RFC6020]).  For unpublished modules, the authors need
1068   to check that no other work in progress is using the same module
1069   name.
```

How should authors perform this check? Is there a mailing list?


#### Why MAY?

```
1153   For convenience, prefix values of example modules MAY be prefixed
1154   with "ex" or similar patterns.  In doing so, readers of example
1155   modules or tree diagrams that mix both example and standard modules
1156   can easily identify example parts.
```

Seems like this would improve readability.



### SHOULD consider

```
1510   and the XPath value space.  The data types are not the same in both,
1511   and conversion between YANG and XPath data types SHOULD be considered
1512   carefully.
```

Consider making this SHOULD lower case.

## Nits


### moodules 🐄

```
1089   definition being referenced.  This allows the same name to be used in
1090   multiple moodules, even if the names are not unique.  In the example
```

### syntax error?

```
1642       leaf reserved {
1643         type string;
1644         description
1645           "This object has no purpose at this time, but a future
1646             revision of this module might define a purpose
1647             for this object.";
1648         }
1649       }
```

Missing `}` ?


### Trailing :

```
1806   A standard namespace statement value SHOULD have the following form:

1808       :

1810   The following URN prefix string SHOULD be used for published and
1811   unpublished YANG modules:

1813       urn:ietf:params:xml:ns:yang:
```

This reads like "urn:ietf:params:xml:ns:yang::ietf-netconf-partial-lock" would be expected.

[Ballot comment]
Thank you to Christer Holmberg for the GENART review.

** Section 3
  All guidelines for I-D authors [ID-Guidelines] MUST
  be followed.

Appreciating that this text was carried over from RFC8407:

-- Why are requirement set for all I-Ds being repeated here?  This would be true for any document, on a YANG topic or not.

-- Versioning: which exact version of each page is mandatory to implement?  Is it every future version?

-- Why is some other clarifying guidance about minting RFCs not include – e.g., https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/ or guidance to adhere to the internet architecture.

IMO, it is not appropriate to reference an educational wiki with a normative MUST.  I also don’t see value in repeating what is required of every I-D.

There are a few other places noted below where guidance about writing an I-D which isn’t specific to YANG is repeated.

** Section 3
  The following sections MUST be present in an I-D containing a YANG
  module:
  *  Narrative sections
  *  Definition sections
  *  Security Considerations section
  *  IANA Considerations section
  *  References section

Same comment as above.

Why are document elements already required by other guidance for ALL I-Ds listed here (e.g., Security Considerations, IANA considerations)?  Why are some required things omitted (e.g., an abstract per https://www.rfc-editor.org/rfc/rfc7322.html#section-4.3)?
I would recommend focusing on what is YANG specific.

** Section 3.4.
  If the document contains major Network Management Datastore
  Architecture (NMDA) exceptions or include a temporary non-NMDA module
  [RFC8342], then the Introduction section should mention this fact
  with the reasoning that motivated that design.  Refer to Section 4.23
  for more NMDA-related guidance.  Specifically, Section 4.23.2
  includes a recommendation for designers to describe and justify any
  NMDA exceptions in detail as part of the module itself.

What constitutes a “major” NMDA exception?  What’s the threshold between “major” (which requires documentation in the abstract)  and minor (which would not)?

** Section 3.8
  In order to comply with IESG policy as set forth in
  , every I-D that is
  submitted to the IESG for publication MUST contain an IANA
  Considerations section.  The requirements for this section vary
  depending on what actions are required of the IANA.  If there are no
  IANA considerations applicable to the document, then the IANA
  Considerations section will state that "This document has no IANA
  actions".  Refer to the guidelines in [RFC8126] for more details.

Why is this paragraph needed.  This is true for EVERY I-D, Yang related or not.

** Section 3.8
  Each normative YANG module MUST be registered in both …

What is a “normative YANG module”?  Is that one specified in the document?  Recommend being clearer.

** Section 4.30.2
  Designers of IANA-maintained modules MAY supply the full initial
  version of the module in a specification document that registers the
  module or only a script to be used (including by IANA) for generating
  the module (e.g., an XSLT stylesheet as in Appendix A of [RFC9108] or
  a Python script as in [RFC9645]).
…
    Note: [Style] provides XSLT 1.0 stylesheets and other tools for
    translating IANA registries to YANG modules.  The tools can be
    used to generate up-to-date revisions of an IANA-maintained module
    based upon the XML representation of an IANA registry.

-- What is the relationship between the guidance that code may be supplied in an I-D on transforming a registry and this Note? 

-- Is this a note for IANA?  Future I-D authors?

** Section 4.30.3
  In addition to the IANA considerations in Section 3.8, the IANA
  Considerations Section of an RFC that includes an IANA-maintained
  module MUST provide the required instructions for IANA to
  automatically perform the maintenance of that IANA module.

What is being directed by the phrase “automatically perform[ed]”?  How is this different that other IANA guidance?

[Ballot comment]
I also share Gunter's initial reaction.

While fine in this document, as it doesn't deal directly with the DNS, I would consider using a replacement token other than "AAAA" in future work, since this is a token that occurs somewhat frequently in IETF documents. (RFCAAAA is fine.)

I was surprised by the change in 4.1 from RFC7950 to RFC6020, since the latter is older than the reference it replaces. However, the content looks correct in 6020, so I'm guessing this is deliberate and a fix to an error in RFC8407. I didn't find anything in the list of changes to reflect this, however; was there an erratum filed for this?

In Section 5, the current practice is to list the IETF, rather than the IESG, as the change controller for our registrations. IANA isn't revisiting old registrations to make this change proactively, but while you're updating these, consider updating that field as well.

This may be excessive, but just for clarity, does Appendix B need a note to the RFC Editor clarifying that the notes to the RFC Editor in the template are part of the template and should not be acted upon during the processing of this document?

===NITS FOLLOW===

Section 2, "Some of the templates defined in the document uses" => "Some of the templates defined in the document use"

Section 3.5, "noted following [RFC8792]" could be parsed as placing the note after RFC8792; consider "indicated with a reference to [RFC8792]"

Section 3.7, "define exclusively modules following" => "exclusively define modules that follow"

Section 3.7.1, consider "have to use" => "require" x2

Section 3.7.1, "as normative references." => "as a normative reference."

[Ballot comment]
I also share Gunter's initial reaction.

While fine in this document, as it doesn't deal directly with the DNS, I would consider using a replacement token other than "AAAA" in future work, since this is a token that occurs somewhat frequently in IETF documents. (RFCAAAA is fine.)

I was surprised by the change in 4.1 from RFC7950 to RFC6020, since the latter is older than the reference it replaces. However, the content looks correct in 6020, so I'm guessing this is deliberate and a fix to an error in RFC8407. I didn't find anything in the list of changes to reflect this, however; was there an erratum filed for this?

In Section 5, the current practice is to list the IETF, rather than the IESG, as the change controller for our registrations. IANA isn't revisiting old registrations to make this change proactively, but while you're updating these, consider updating that field as well.

This may be excessive, but just for clarity, does Appendix B need a note to the RFC Editor clarifying that the notes to the RFC Editor in the template are part of the template and should not be acted upon during the processing of this document?

===NITS FOLLOW===
Section 2, "Some of the templates defined in the document uses" => "Some of the templates defined in the document use"
Section 3.5, "noted following [RFC8792]" could be parsed as placing the note after RFC8792; consider "indicated with a reference to [RFC8792]"
Section 3.7, "define exclusively modules following" => "exclusively define modules that follow"
Section 3.7.1, consider "have to use" => "require" x2
Section 3.7.1, "as normative references." => "as a normative reference."

[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-netmod-rfc8407bis-25
CC @evyncke

Thank you for the work put into this document, I share Gunter's comment on the usefulness and easy-to-read quality of this I-D.

I have reviewed the whole draft rather than the diffs with RFC 8407.

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

Special thanks to Qiufang Ma for the shepherd's detailed write-up including the WG consensus and the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric

## COMMENTS (non-blocking)

### Title vs. abstract

The title is about data models while the abstract is about modules. Let's avoid spreading the confusion in a BCP. As the document is more about data model, let's use this term in title/abstract.

### Section 1

`Only constructs that all servers are required to support can be used in IETF YANG modules` , it is really unclear to me how this can be verified.

### Section 2

s/and *which* is not maintained by IANA/and *that* is not maintained by IANA/ ?

### Section 2.5

I would go further than `Likewise, "YANG data module" should be avoided.`and use "Likewise, "YANG data module" is incorrect, has no meaning, and MUST be avoided."

### Section 3

s/The following sections MUST be present in an I-D containing a YANG module/The following sections MUST be present in an I-D *or RFC* containing a YANG module/

### Section 3.2

Any chance to use a more recent date than 2016 ? Or is it to borrow as much as possible from RFC 8407 ?

### Section 3.4

For large trees, I like to have a pruned version in the body part and not in the appendix, perhaps with subtrees.

### Section 3.5

Is this section about the data models or modules ? Modules are mainly for syntax while the data models are for semantics, i.e., I think that relationships are between data models and not modules.

s/the Introduction section *should* mention this fact/the Introduction section *SHOULD* mention this fact/ if only to be consistent with the use of uppercase BCP14 terms in this section.

The long line example seems to be for an instance of a module, should it rather be on the module itself ?

### Section 3.6

First time ever that I read about "YIN syntax", please provide a normative reference.

### Section 3.8

I fail to imagine a non-normative YANG module in a RFC; therefore, is 'normative' required in `Each normative YANG module`.

### Section 3.9

Suggest adding some template text to be used before the YANG module itself to add a normative reference (to avoid the 'unused reference' by id-nits).

### Section 3.10

It is disapointing not to see [yangcatalog.org](https://www.yangcatalog.org/yangvalidator) listed in the validation tools. Is it a hint by the authors that YCO use is not recommended ?

### Section 3.12

Big thank you for forcing either IPv6 or dual-stack examples, we are indeed in 2025!

Please add RFC 9637 as a reference for documentation prefix (I was about to ballot a DISCUSS on this one as it MUST be addressed).

### Section 4.2

s/moodules/modules/ ;-)

### Section 4.3

Should `character` be qualified as ASCII (I guess no UTF-8 encoding here).

### Section 4.7

What are the events (RFC publication date ? IESG approval date ?) for `An object SHOULD be available for at least one year with a "deprecated" status before it is changed to "obsolete".`?

### Section 4.8

The "contact" statement is required but can it be empty ? Should there be guidance for other SDOs ?

### Section 4.11.2

I was about to ballot a DISCUSS on this one :-( ... the `pattern '[0-9\.]*'` is clearly to lax for an IPv4 address even if RFC 6991 claims so.

### Section 4.12

There are many "SHOULD" where I would have preferred "MUST", at least explain why an existing type cannot be re-used.

Also suggest adding how can an author find a re-usable data type.

### Section 4.25

To be honest, I fail to understand the content of this section, especially what an `open system` is...

### Section 4.30.3

Unsure whether a 2025 I-D should still contain reference to `3des-cbc` and for sure to `6to4`. These terms were probably current when RFC 8407 was published, but let's avoid them in the -bis.

### Ack section

I think you mean 'Rich' rather than `Thanks to Rach Salz` ;-)

[Ballot comment]
I started the read this draft with a hint of horror to start reading a 94 page long text on yang guidelines. However i found the document well written and clear to understand and consider for usage.

Many thanks for this document. It is very useful and well written.

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

Shepherd:
This document has been discussed extensively on the mailing list. The WG consensus represents the strong concurrence of a small amount of individuals with the other folks giving comments and suggestions on the changes of the document. No objections for publication or other comments were raised for the WGLC. Here is a direct link to that WGLC process:
https://mailarchive.ietf.org/arch/msg/netmod/u5Vk7_DgeXAOuq4h02hROfTYQaU/ 

As such, the shepherd believes that this document has reached a broad agreement as this WG would be expected to reach.

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

Shepherd:
There was no controversy about particular points, and the shepherd doesn’t notice any decisions where the consensus was particularly 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.)

Shepherd:
No one threatened an appeal or indicated extreme discontent.

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

Shepherd:
This document is not a protocol document. Instead, it provides guidelines for authors and reviewers of documents that contain YANG data models. The shepherd does not believe that this document pertains to any implementations.

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

Shepherd:
The document was reviewed by IANA and their inputs adequately implemented. Also, the document was circulated in SAAG mailing list to solicit reviews for the security template. Here is a direct link to that security template discussion on SAAG list: https://mailarchive.ietf.org/arch/msg/saag/z338jOL6mpYIIzT0Xk8ioCvi6v4/.

Besides that, the shepherd doesn't think the contents of this document closely interact with
technologies in other fields, and therefore the shepherd doesn't believe this
document needs further review from other IETF working groups or external organizations.


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.

Shepherd:
The document went through a YANG doctor review as part of the Last Call process.
Here is a direct link to that review:
https://datatracker.ietf.org/doc/review-ietf-netmod-rfc8407bis-11-yangdoctors-lc-liu-2024-06-17/
And all the comments raised by the YANG doctor were resolved by authors providing suggested texts for the YANG doctor to review, here is the related discussion about the Yang doctor last call review on the NETMOD WG mailing list:
https://mailarchive.ietf.org/arch/msg/yang-doctors/QFNwJC99AtorujtQLPtsRQZDVP8/
In addition, the shepherd confirms that the follow-up comment raised by the YANG doctor was also fixed.

Specifically, the document also went through a TSVART review which was considered by the WG, but the rough consensus from the WG was not to adopt the changes as suggested.
Here is a direct link to that review:
https://mailarchive.ietf.org/arch/msg/netmod/QcAw9pagRaSHRvQpq8fGExRqtHE/
And here is a direct link to the related discussion within WG:
https://mailarchive.ietf.org/arch/msg/netmod/KJoBZCXsf-2YE2r2yw_WmcVrP6I/

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

Shepherd:
The document contains some example and template modules without any substantive definition and only for illustration purposes, YANG tools cannot validate them directly since some contents need to be replaced according to actual situations. The shepherd doesn’t think there is any syntax and formatting issues.

Note that DataTracker’s YANG validator reports 4 errors and 5 warnings which
are considered as false positives by the shepherd since they are about some fields that need to be replaced with real contents in the template modules.

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.

Shepherd:
The shepherd has reviewed the document, tested it against “idnits”. The document doesn’t contain any other parts that needs to be validated except for some YANG fragment, which have been checked by the shepherd.

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

Shepherd:
Yes. Based on the shepherd's review of the document, the shepherd believes that
this document is needed, clearly written, complete, correctly designed, and
ready to be handed off to the responsible Area Director.

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?


Shepherd:
The shepherd doesn’t see any common issues that need to be flagged. The shepherd believes that there is nothing that would merit specific attention from subsequent reviews.


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?

Shepherd:
This document is requested to be published as Best Current Practice. In this case, it is the correct state because this document defines some guidelines and obsoletes RFC 8407, which is also published as Best Current Practice.

The status is properly reflected on the Datatracker page, here is the direct link:
https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc8407bis/.

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.

Shepherd:
No IPR disclosure has been filed that references this document.

The WG chair has requested an IPR call on the list. All authors confirmed that
they are not aware of any IPR related to this document. All responses indicated
no IPR needs to be disclosed.

Here is the directed link to the IPR call request:
https://mailarchive.ietf.org/arch/msg/netmod/B9cnRJcAt-Gr1HnwQkM7RiWgHhY/
https://mailarchive.ietf.org/arch/msg/netmod/NDygxJmY6FEOwXS8ifGo08INR58/

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

Shepherd:
There are 3 authors (no greater than 5) for this document and no contributor being listed. Each author did not confirmed their willingness to be listed as such explicitly, but the shepherd assumes that all three of authors have been listed for some time and their silence implies consent. And all responded to the IPR polling during WGLC, which also implies that they are aware of their status on the document.

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

Shepherd:
I-D nits has been tested against -22, and it reports 1 error (**), 0 flaws (~~), 2 warnings (==), 5 comments (--), which are either innocuous or intentional. Note the normative reference to RFC 8792 is not an error as it is listed in the Downref registry (https://datatracker.ietf.org/doc/downref). Manual check of Guidelines to Authors of Internet-Drafts reveals no issues.

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

Shepherd:
The shepherd has reviewed that all references within this document have been
identified as either normative or informative, and all the informative and
normative references are classified correctly.


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

Shepherd:
None. All the normative references in the document are freely available to
anyone.


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.

Shepherd:
Yes, RFC 8792. However, that RFC is already listed in DOWNREF registry.

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?

Shepherd:
There are no normative references to documents that are not ready to be submitted to the IESG for publication or in an unclear state. All normative references are published.

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.

Shepherd:
The publication of this document will obsolete RFC8407, update RFCs 6020 and 8126. All of them are correctly reflected on the Datatracker metadata, document title page, in the abstract and discussed in the introduction.

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

Shepherd:
The shepherd has reviewed the IANA considerations section, this document registers two URIs and two YANG modules, it also requests IANA to update the reference for the “YANG module Names” registry. Besides that, this document also amends the guidance on names unicity of IANA considerations to register YANG module and submodule names and add extra notes for the creation and maintenance of an IANA-maintained module.

The shepherd confirms that all aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries. The shepherd also confirms that any referenced IANA registries have been clearly identified in the document, and it doesn’t contain any newly created IANA registry.

In addition, IANA was solicited for feedback since early versions of the document, e.g.,
1. Individual submission: [netmod] TR: [IANA #1291942] RE: Early review: draft-boucadair-netmod-rfc8407bis (IETF 117), direct link: https://mailarchive.ietf.org/arch/msg/netmod/GFYUpkX6TjIOwlo4qDxD1TuvKwo/ ;
2. [netmod] Re: [IANA #1289473] Revision statements in IANA-maintained YANG modules (ietf.org), direct link: https://mailarchive.ietf.org/arch/msg/netmod/YqNYf0oR3OrDbd4xLynYrmWJ2Cs/ ;
3. [netmod] [IANA #1373241] RE: Regarding draft-ietf-netmod-rfc8407bis, direct link: https://mailarchive.ietf.org/arch/msg/netmod/qie6Gc4VZEqfKaXtjBZXgAS5iMo/ 

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.

Shepherd:
This document does not have any new IANA registries that require Designated Expert Review for future allocations.

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

Shepherd:
This document has been discussed extensively on the mailing list. The WG consensus represents the strong concurrence of a small amount of individuals with the other folks giving comments and suggestions on the changes of the document. No objections for publication or other comments were raised for the WGLC. Here is a direct link to that WGLC process:
https://mailarchive.ietf.org/arch/msg/netmod/u5Vk7_DgeXAOuq4h02hROfTYQaU/ 

As such, the shepherd believes that this document has reached a broad agreement as this WG would be expected to reach.

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

Shepherd:
There was no controversy about particular points, and the shepherd doesn’t notice any decisions where the consensus was particularly 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.)

Shepherd:
No one threatened an appeal or indicated extreme discontent.

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

Shepherd:
This document is not a protocol document. Instead, it provides guidelines for authors and reviewers of documents that contain YANG data models. The shepherd does not believe that this document pertains to any implementations.

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

Shepherd:
The document was reviewed by IANA and their inputs adequately implemented. Also, the document was circulated in SAAG mailing list to solicit reviews for the security template. Here is a direct link to that security template discussion on SAAG list: https://mailarchive.ietf.org/arch/msg/saag/z338jOL6mpYIIzT0Xk8ioCvi6v4/.

Besides that, the shepherd doesn't think the contents of this document closely interact with
technologies in other fields, and therefore the shepherd doesn't believe this
document needs further review from other IETF working groups or external organizations.


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.

Shepherd:
The document went through a YANG doctor review as part of the Last Call process.
Here is a direct link to that review:
https://datatracker.ietf.org/doc/review-ietf-netmod-rfc8407bis-11-yangdoctors-lc-liu-2024-06-17/
And all the comments raised by the YANG doctor were resolved by authors providing suggested texts for the YANG doctor to review, here is the related discussion about the Yang doctor last call review on the NETMOD WG mailing list:
https://mailarchive.ietf.org/arch/msg/yang-doctors/QFNwJC99AtorujtQLPtsRQZDVP8/
In addition, the shepherd confirms that the follow-up comment raised by the YANG doctor was also fixed.

Specifically, the document also went through a TSVART review which was considered by the WG, but the rough consensus from the WG was not to adopt the changes as suggested. Here is a direct link to that review:
https://mailarchive.ietf.org/arch/msg/netmod/QcAw9pagRaSHRvQpq8fGExRqtHE/
And here is a direct link to the related discussion within WG:
https://mailarchive.ietf.org/arch/msg/netmod/KJoBZCXsf-2YE2r2yw_WmcVrP6I/

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

Shepherd:
The document contains some example and template modules without any substantive definition and only for illustration purposes, YANG tools cannot validate them directly since some contents need to be replaced according to actual situations. The shepherd doesn’t think there is any syntax and formatting issues.

Note that DataTracker’s YANG validator reports 4 errors and 5 warnings which
are considered as false positives by the shepherd since they are about some fields that need to be replaced with real contents in the template modules.

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.

Shepherd:
The shepherd has reviewed the document, tested it against “idnits”. The document doesn’t contain any other parts that needs to be validated except for some YANG fragment, which have been checked by the shepherd.

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

Shepherd:
Yes. Based on the shepherd's review of the document, the shepherd believes that
this document is needed, clearly written, complete, correctly designed, and
ready to be handed off to the responsible Area Director.

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?


Shepherd:
The shepherd doesn’t see any common issues that need to be flagged. The shepherd believes that there is nothing that would merit specific attention from subsequent reviews.


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?

Shepherd:
This document is requested to be published as Best Current Practice. In this case, it is the correct state because this document defines some guidelines and obsoletes RFC 8407, which is also published as Best Current Practice.

The status is properly reflected on the Datatracker page, here is the direct link:
https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc8407bis/.

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.

Shepherd:
No IPR disclosure has been filed that references this document.

The WG chair has requested an IPR call on the list. All authors confirmed that
they are not aware of any IPR related to this document. All responses indicated
no IPR needs to be disclosed.

Here is the directed link to the IPR call request:
https://mailarchive.ietf.org/arch/msg/netmod/B9cnRJcAt-Gr1HnwQkM7RiWgHhY/
https://mailarchive.ietf.org/arch/msg/netmod/NDygxJmY6FEOwXS8ifGo08INR58/

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

Shepherd:
There are 3 authors (no greater than 5) for this document and no contributor being listed. Each author did not confirmed their willingness to be listed as such explicitly, but the shepherd assumes that all three of authors have been listed for some time and their silence implies consent. And all responded to the IPR polling during WGLC, which also implies that they are aware of their status on the document.

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

Shepherd:
I-D nits has been tested against -22, and it reports 1 error (**), 0 flaws (~~), 2 warnings (==), 5 comments (--), which are either innocuous or intentional. Note the normative reference to RFC 8792 is not an error as it is listed in the Downref registry (https://datatracker.ietf.org/doc/downref). Manual check of Guidelines to Authors of Internet-Drafts reveals no issues.

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

Shepherd:
The shepherd has reviewed that all references within this document have been
identified as either normative or informative, and all the informative and
normative references are classified correctly.


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

Shepherd:
None. All the normative references in the document are freely available to
anyone.


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.

Shepherd:
Yes, RFC 8792. However, that RFC is already listed in DOWNREF registry.

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?

Shepherd:
There are no normative references to documents that are not ready to be submitted to the IESG for publication or in an unclear state. All normative references are published.

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.

Shepherd:
The publication of this document will obsolete RFC8407, update RFCs 6020 and 8126. All of them are correctly reflected on the Datatracker metadata, document title page, in the abstract and discussed in the introduction.

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

Shepherd:
The shepherd has reviewed the IANA considerations section, this document registers two URIs and two YANG modules, it also requests IANA to update the reference for the “YANG module Names” registry. Besides that, this document also amends the guidance on names unicity of IANA considerations to register YANG module and submodule names and add extra notes for the creation and maintenance of an IANA-maintained module.

The shepherd confirms that all aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries. The shepherd also confirms that any referenced IANA registries have been clearly identified in the document, and it doesn’t contain any newly created IANA registry.

In addition, IANA was solicited for feedback since early versions of the document, e.g.,
1. Individual submission: [netmod] TR: [IANA #1291942] RE: Early review: draft-boucadair-netmod-rfc8407bis (IETF 117), direct link: https://mailarchive.ietf.org/arch/msg/netmod/GFYUpkX6TjIOwlo4qDxD1TuvKwo/ ;
2. [netmod] Re: [IANA #1289473] Revision statements in IANA-maintained YANG modules (ietf.org), direct link: https://mailarchive.ietf.org/arch/msg/netmod/YqNYf0oR3OrDbd4xLynYrmWJ2Cs/ ;
3. [netmod] [IANA #1373241] RE: Regarding draft-ietf-netmod-rfc8407bis, direct link: https://mailarchive.ietf.org/arch/msg/netmod/qie6Gc4VZEqfKaXtjBZXgAS5iMo/ 

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.

Shepherd:
This document does not have any new IANA registries that require Designated Expert Review for future allocations.

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

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

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-netmod-rfc8407bis-24. If any part of this review is inaccurate, please let us know.

IANA has a question about the fourth action requested in the IANA Considerations section of this document.

IANA understands that, upon approval of this document, there are four 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/

one existing namespace will have its reference changed to [ RFC-to-be ] as follows:

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

Second, also in the ns registry on the IETF XML Registry group located at:

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

a new registration will be made as follows:

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

As this document requests a registration in an Expert Review or Specification Required (see RFC 8126) registry, we have completed the required Expert Review via a separate request.

Second, in the YANG Module Names registry on 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-template
File: [ TBD-at-Registration ]
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:ietf-template
Prefix: temp
Module:
Reference: [ RFC-to-be ]

Name: iana-template
File: [ TBD-at-Registration ]
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:iana-template
Prefix: iana-foo
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, in the YANG Module Names registry on the YANG Parameters registry group located at:

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

the reference for the registry will be changed from [RFC8407] to [ RFC-to-be ].

Fourth, Section 5.3 of the current draft appears to provide guidance on how to create "revision" statements and "identity" and "enum" substatements in IANA-maintained modules. IANA understands that this section requests no immediate action from IANA, but instead provides guidance for maintenance of the YANG Module Names registry in the YANG Parameters registry group located at:

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

IANA Question -> Is this understanding correct?

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

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

For definitions of IANA review states, please see:

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

Thank you,

David Dong
IANA Services Sr. Specialist

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

From: The IESG
To: IETF-Announce
CC: draft-ietf-netmod-rfc8407bis@ietf.org, kent+ietf@watsen.net, maqiufang1@huawei.com, mjethanandani@gmail.com, netmod-chairs@ietf.org, netmod@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Guidelines for Authors and Reviewers of Documents Containing YANG Data Models) to Best Current Practice


The IESG has received a request from the Network Modeling WG (netmod) to
consider the following document: - 'Guidelines for Authors and Reviewers of
Documents Containing YANG Data
  Models'
  as Best Current Practice

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2025-05-05. 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 memo provides guidelines for authors and reviewers of
  specifications containing YANG modules, including IANA-maintained
  modules.  Recommendations and procedures are defined, which are
  intended to increase interoperability and usability of Network
  Configuration Protocol (NETCONF) and RESTCONF Protocol
  implementations that utilize YANG modules.  This document obsoletes
  RFC 8407.

  Also, this document updates RFC 8126 by providing additional
  guidelines for writing the IANA considerations for RFCs that specify
  IANA-maintained modules.




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



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

Even though some of the *DIR reviews are still pending, I am hoping a parallel IETF LC will enable all the reviews and comments to converge about the same time.

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

Shepherd:
This document has been discussed extensively on the mailing list. The WG consensus represents the strong concurrence of a small amount of individuals with the other folks giving comments and suggestions on the changes of the document. No objections for publication or other comments were raised for the WGLC. Here is a direct link to that WGLC process:
https://mailarchive.ietf.org/arch/msg/netmod/u5Vk7_DgeXAOuq4h02hROfTYQaU/ 

As such, the shepherd believes that this document has reached a broad agreement as this WG would be expected to reach.

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

Shepherd:
There was no controversy about particular points, and the shepherd doesn’t notice any decisions where the consensus was particularly 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.)

Shepherd:
No one threatened an appeal or indicated extreme discontent.

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

Shepherd:
This document is not a protocol document. Instead, it provides guidelines for authors and reviewers of documents that contain YANG data models. The shepherd does not believe that this document pertains to any implementations.

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

Shepherd:
The document was reviewed by IANA and their inputs adequately implemented. Also, the document was circulated in SAAG mailing list to solicit reviews for the security template. Here is a direct link to that security template discussion on SAAG list: https://mailarchive.ietf.org/arch/msg/saag/z338jOL6mpYIIzT0Xk8ioCvi6v4/.

Besides that, the shepherd doesn't think the contents of this document closely interact with
technologies in other fields, and therefore the shepherd doesn't believe this
document needs further review from other IETF working groups or external organizations.


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.

Shepherd:
The document went through a YANG doctor review as part of the Last Call process.
Here is a direct link to that review:
https://datatracker.ietf.org/doc/review-ietf-netmod-rfc8407bis-11-yangdoctors-lc-liu-2024-06-17/
And all the comments raised by the YANG doctor were resolved by authors providing suggested texts for the YANG doctor to review, here is the related discussion about the Yang doctor last call review on the NETMOD WG mailing list:
https://mailarchive.ietf.org/arch/msg/yang-doctors/QFNwJC99AtorujtQLPtsRQZDVP8/
In addition, the shepherd confirms that the follow-up comment raised by the YANG doctor was also fixed.

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

Shepherd:
The document contains some example and template modules without any substantive definition and only for illustration purposes, YANG tools cannot validate them directly since some contents need to be replaced according to actual situations. The shepherd doesn’t think there is any syntax and formatting issues.

Note that DataTracker’s YANG validator reports 4 errors and 5 warnings which
are considered as false positives by the shepherd since they are about some fields that need to be replaced with real contents in the template modules.

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.

Shepherd:
The shepherd has reviewed the document, tested it against “idnits”. The document doesn’t contain any other parts that needs to be validated except for some YANG fragment, which have been checked by the shepherd.

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

Shepherd:
Yes. Based on the shepherd's review of the document, the shepherd believes that
this document is needed, clearly written, complete, correctly designed, and
ready to be handed off to the responsible Area Director.

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?


Shepherd:
The shepherd doesn’t see any common issues that need to be flagged. The shepherd believes that there is nothing that would merit specific attention from subsequent reviews.


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?

Shepherd:
This document is requested to be published as Best Current Practice. In this case, it is the correct state because this document defines some guidelines and obsoletes RFC 8407, which is also published as Best Current Practice.

The status is properly reflected on the Datatracker page, here is the direct link:
https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc8407bis/.

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.

Shepherd:
No IPR disclosure has been filed that references this document.

The WG chair has requested an IPR call on the list. All authors confirmed that
they are not aware of any IPR related to this document. All responses indicated
no IPR needs to be disclosed.

Here is the directed link to the IPR call request:
https://mailarchive.ietf.org/arch/msg/netmod/B9cnRJcAt-Gr1HnwQkM7RiWgHhY/
https://mailarchive.ietf.org/arch/msg/netmod/NDygxJmY6FEOwXS8ifGo08INR58/

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

Shepherd:
There are 3 authors (no greater than 5) for this document and no contributor being listed. Each author did not confirmed their willingness to be listed as such explicitly, but the shepherd assumes that all three of authors have been listed for some time and their silence implies consent. And all responded to the IPR polling during WGLC, which also implies that they are aware of their status on the document.

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

Shepherd:
I-D nits has been tested against -22, and it reports 1 error (**), 0 flaws (~~), 2 warnings (==), 5 comments (--), which are either innocuous or intentional. Note the normative reference to RFC 8792 is not an error as it is listed in the Downref registry (https://datatracker.ietf.org/doc/downref). Manual check of Guidelines to Authors of Internet-Drafts reveals no issues.

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

Shepherd:
The shepherd has reviewed that all references within this document have been
identified as either normative or informative, and all the informative and
normative references are classified correctly.


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

Shepherd:
None. All the normative references in the document are freely available to
anyone.


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.

Shepherd:
Yes, RFC 8792. However, that RFC is already listed in DOWNREF registry.

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?

Shepherd:
There are no normative references to documents that are not ready to be submitted to the IESG for publication or in an unclear state. All normative references are published.

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.

Shepherd:
The publication of this document will obsolete RFC8407, update RFCs 6020 and 8126. All of them are correctly reflected on the Datatracker metadata, document title page, in the abstract and discussed in the introduction.

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

Shepherd:
The shepherd has reviewed the IANA considerations section, this document registers two URIs and two YANG modules, it also requests IANA to update the reference for the “YANG module Names” registry. Besides that, this document also amends the guidance on names unicity of IANA considerations to register YANG module and submodule names and add extra notes for the creation and maintenance of an IANA-maintained module.

The shepherd confirms that all aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries. The shepherd also confirms that any referenced IANA registries have been clearly identified in the document, and it doesn’t contain any newly created IANA registry.

In addition, IANA was solicited for feedback since early versions of the document, e.g.,
1. Individual submission: [netmod] TR: [IANA #1291942] RE: Early review: draft-boucadair-netmod-rfc8407bis (IETF 117), direct link: https://mailarchive.ietf.org/arch/msg/netmod/GFYUpkX6TjIOwlo4qDxD1TuvKwo/ ;
2. [netmod] Re: [IANA #1289473] Revision statements in IANA-maintained YANG modules (ietf.org), direct link: https://mailarchive.ietf.org/arch/msg/netmod/YqNYf0oR3OrDbd4xLynYrmWJ2Cs/ ;
3. [netmod] [IANA #1373241] RE: Regarding draft-ietf-netmod-rfc8407bis, direct link: https://mailarchive.ietf.org/arch/msg/netmod/qie6Gc4VZEqfKaXtjBZXgAS5iMo/ 

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.

Shepherd:
This document does not have any new IANA registries that require Designated Expert Review for future allocations.

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

Shepherd:
This document has been discussed extensively on the mailing list. The WG consensus represents the strong concurrence of a small amount of individuals with the other folks giving comments and suggestions on the changes of the document. No objections for publication or other comments were raised for the WGLC. Here is a direct link to that WGLC process:
https://mailarchive.ietf.org/arch/msg/netmod/u5Vk7_DgeXAOuq4h02hROfTYQaU/ 

As such, the shepherd believes that this document has reached a broad agreement as this WG would be expected to reach.

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

Shepherd:
There was no controversy about particular points, and the shepherd doesn’t notice any decisions where the consensus was particularly 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.)

Shepherd:
No one threatened an appeal or indicated extreme discontent.

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

Shepherd:
This document is not a protocol document. Instead, it provides guidelines for authors and reviewers of documents that contain YANG data models. The shepherd does not believe that this document pertains to any implementations.

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

Shepherd:
The document was reviewed by IANA and their inputs adequately implemented. Also, the document was circulated in SAAG mailing list to solicit reviews for the security template. Here is a direct link to that security template discussion on SAAG list: https://mailarchive.ietf.org/arch/msg/saag/z338jOL6mpYIIzT0Xk8ioCvi6v4/.

Besides that, the shepherd doesn't think the contents of this document closely interact with
technologies in other fields, and therefore the shepherd doesn't believe this
document needs further review from other IETF working groups or external organizations.


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.

Shepherd:
The document went through a YANG doctor review as part of the Last Call process.
Here is a direct link to that review:
https://datatracker.ietf.org/doc/review-ietf-netmod-rfc8407bis-11-yangdoctors-lc-liu-2024-06-17/
And all the comments raised by the YANG doctor were resolved by authors providing suggested texts for the YANG doctor to review, here is the related discussion about the Yang doctor last call review on the NETMOD WG mailing list:
https://mailarchive.ietf.org/arch/msg/yang-doctors/QFNwJC99AtorujtQLPtsRQZDVP8/
In addition, the shepherd confirms that the follow-up comment raised by the YANG doctor was also fixed.

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

Shepherd:
The document contains some example and template modules without any substantive definition and only for illustration purposes, YANG tools cannot validate them directly since some contents need to be replaced according to actual situations. The shepherd doesn’t think there is any syntax and formatting issues.

Note that DataTracker’s YANG validator reports 4 errors and 5 warnings which
are considered as false positives by the shepherd since they are about some fields that need to be replaced with real contents in the template modules.

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.

Shepherd:
The shepherd has reviewed the document, tested it against “idnits”. The document doesn’t contain any other parts that needs to be validated except for some YANG fragment, which have been checked by the shepherd.

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

Shepherd:
Yes. Based on the shepherd's review of the document, the shepherd believes that
this document is needed, clearly written, complete, correctly designed, and
ready to be handed off to the responsible Area Director.

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?


Shepherd:
The shepherd doesn’t see any common issues that need to be flagged. The shepherd believes that there is nothing that would merit specific attention from subsequent reviews.


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?

Shepherd:
This document is requested to be published as Best Current Practice. In this case, it is the correct state because this document defines some guidelines and obsoletes RFC 8407, which is also published as Best Current Practice.

The status is properly reflected on the Datatracker page, here is the direct link:
https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc8407bis/.

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.

Shepherd:
No IPR disclosure has been filed that references this document.

The WG chair has requested an IPR call on the list. All authors confirmed that
they are not aware of any IPR related to this document. All responses indicated
no IPR needs to be disclosed.

Here is the directed link to the IPR call request:
https://mailarchive.ietf.org/arch/msg/netmod/B9cnRJcAt-Gr1HnwQkM7RiWgHhY/
https://mailarchive.ietf.org/arch/msg/netmod/NDygxJmY6FEOwXS8ifGo08INR58/

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

Shepherd:
There are 3 authors (no greater than 5) for this document and no contributor being listed. Each author did not confirmed their willingness to be listed as such explicitly, but the shepherd assumes that all three of authors have been listed for some time and their silence implies consent. And all responded to the IPR polling during WGLC, which also implies that they are aware of their status on the document.

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

Shepherd:
I-D nits has been tested against -22, and it reports 1 error (**), 0 flaws (~~), 2 warnings (==), 5 comments (--), which are either innocuous or intentional. Note the normative reference to RFC 8792 is not an error as it is listed in the Downref registry (https://datatracker.ietf.org/doc/downref). Manual check of Guidelines to Authors of Internet-Drafts reveals no issues.

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

Shepherd:
The shepherd has reviewed that all references within this document have been
identified as either normative or informative, and all the informative and
normative references are classified correctly.


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

Shepherd:
None. All the normative references in the document are freely available to
anyone.


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.

Shepherd:
Yes, RFC 8792. However, that RFC is already listed in DOWNREF registry.

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?

Shepherd:
There are no normative references to documents that are not ready to be submitted to the IESG for publication or in an unclear state. All normative references are published.

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.

Shepherd:
The publication of this document will obsolete RFC8407, update RFCs 6020 and 8126. All of them are correctly reflected on the Datatracker metadata, document title page, in the abstract and discussed in the introduction.

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

Shepherd:
The shepherd has reviewed the IANA considerations section, this document registers two URIs and two YANG modules, it also requests IANA to update the reference for the “YANG module Names” registry. Besides that, this document also amends the guidance on names unicity of IANA considerations to register YANG module and submodule names and add extra notes for the creation and maintenance of an IANA-maintained module.

The shepherd confirms that all aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries. The shepherd also confirms that any referenced IANA registries have been clearly identified in the document, and it doesn’t contain any newly created IANA registry.

In addition, IANA was solicited for feedback since early versions of the document, e.g.,
1. Individual submission: [netmod] TR: [IANA #1291942] RE: Early review: draft-boucadair-netmod-rfc8407bis (IETF 117), direct link: https://mailarchive.ietf.org/arch/msg/netmod/GFYUpkX6TjIOwlo4qDxD1TuvKwo/ ;
2. [netmod] Re: [IANA #1289473] Revision statements in IANA-maintained YANG modules (ietf.org), direct link: https://mailarchive.ietf.org/arch/msg/netmod/YqNYf0oR3OrDbd4xLynYrmWJ2Cs/ ;
3. [netmod] [IANA #1373241] RE: Regarding draft-ietf-netmod-rfc8407bis, direct link: https://mailarchive.ietf.org/arch/msg/netmod/qie6Gc4VZEqfKaXtjBZXgAS5iMo/ 

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.

Shepherd:
This document does not have any new IANA registries that require Designated Expert Review for future allocations.

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

Publication gated on this issue.

Previous paragraph referenced "European Union" in a clearly delineated example.  Current text is hard to parse (one very long paragraph) and hence unclear if intended as an example.

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

Shepherd:
This document has been discussed extensively on the mailing list. The WG consensus represents the strong concurrence of a small amount of individuals with the other folks giving comments and suggestions on the changes of the document. No objections for publication or other comments were raised for the WGLC. Here is a direct link to that WGLC process:
https://mailarchive.ietf.org/arch/msg/netmod/u5Vk7_DgeXAOuq4h02hROfTYQaU/ 

As such, the shepherd believes that this document has reached a broad agreement as this WG would be expected to reach.

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

Shepherd:
There was no controversy about particular points, and the shepherd doesn’t notice any decisions where the consensus was particularly 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.)

Shepherd:
No one threatened an appeal or indicated extreme discontent.

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

Shepherd:
This document is not a protocol document. Instead, it provides guidelines for authors and reviewers of documents that contain YANG data models. The shepherd does not believe that this document pertains to any implementations.

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

Shepherd:
The document was reviewed by IANA and their inputs adequately implemented. Also, the document was circulated in SAAG mailing list to solicit reviews for the security template. Here is a direct link to that security template discussion on SAAG list: https://mailarchive.ietf.org/arch/msg/saag/z338jOL6mpYIIzT0Xk8ioCvi6v4/.

Besides that, the shepherd doesn't think the contents of this document closely interact with
technologies in other fields, and therefore the shepherd doesn't believe this
document needs further review from other IETF working groups or external organizations.


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.

Shepherd:
The document went through a YANG doctor review as part of the Last Call process.
Here is a direct link to that review:
https://datatracker.ietf.org/doc/review-ietf-netmod-rfc8407bis-11-yangdoctors-lc-liu-2024-06-17/
And all the comments raised by the YANG doctor were resolved by authors providing suggested texts for the YANG doctor to review, here is the related discussion about the Yang doctor last call review on the NETMOD WG mailing list:
https://mailarchive.ietf.org/arch/msg/yang-doctors/QFNwJC99AtorujtQLPtsRQZDVP8/
In addition, the shepherd confirms that the follow-up comment raised by the YANG doctor was also fixed.

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

Shepherd:
The document contains some example and template modules without any substantive definition and only for illustration purposes, YANG tools cannot validate them directly since some contents need to be replaced according to actual situations. The shepherd doesn’t think there is any syntax and formatting issues.

Note that DataTracker’s YANG validator reports 4 errors and 5 warnings which
are considered as false positives by the shepherd since they are about some fields that need to be replaced with real contents in the template modules.

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.

Shepherd:
The shepherd has reviewed the document, tested it against “idnits”. The document doesn’t contain any other parts that needs to be validated except for some YANG fragment, which have been checked by the shepherd.

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

Shepherd:
Yes. Based on the shepherd's review of the document, the shepherd believes that
this document is needed, clearly written, complete, correctly designed, and
ready to be handed off to the responsible Area Director.

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?


Shepherd:
The shepherd doesn’t see any common issues that need to be flagged. The shepherd believes that there is nothing that would merit specific attention from subsequent reviews.


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?

Shepherd:
This document is requested to be published as Best Current Practice. In this case, it is the correct state because this document defines some guidelines and obsoletes RFC 8407, which is also published as Best Current Practice.

The status is properly reflected on the Datatracker page, here is the direct link:
https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc8407bis/.

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.

Shepherd:
No IPR disclosure has been filed that references this document.

The WG chair has requested an IPR call on the list. All authors confirmed that
they are not aware of any IPR related to this document. All responses indicated
no IPR needs to be disclosed.

Here is the directed link to the IPR call request:
https://mailarchive.ietf.org/arch/msg/netmod/B9cnRJcAt-Gr1HnwQkM7RiWgHhY/
https://mailarchive.ietf.org/arch/msg/netmod/NDygxJmY6FEOwXS8ifGo08INR58/

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

Shepherd:
There are 3 authors (no greater than 5) for this document and no contributor being listed. Each author did not confirmed their willingness to be listed as such explicitly, but the shepherd assumes that all three of authors have been listed for some time and their silence implies consent. And all responded to the IPR polling during WGLC, which also implies that they are aware of their status on the document.

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

Shepherd:
I-D nits has been tested against -17, and it reports 1 error (**), 0 flaws (~~), 3 warnings (==), 4 comments (--), which are innocuous. Manual check of Guidelines to Authors of Internet-Drafts reveals no issues.

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

Shepherd:
The shepherd has reviewed that all references within this document have been
identified as either normative or informative, and all the informative and
normative references are classified correctly.


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

Shepherd:
None. All the normative references in the document are freely available to
anyone.


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.

Shepherd:
Yes, RFC 8792. However, that RFC is already listed in DOWNREF registry.

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?

Shepherd:
There are no normative references to documents that are not ready to be submitted to the IESG for publication or in an unclear state. All normative references are published.

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.

Shepherd:
The publication of this document will obsolete RFC8407, update RFCs 6020 and 8126. All of them are correctly reflected on the Datatracker metadata, document title page, in the abstract and discussed in the introduction.

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

Shepherd:
The shepherd has reviewed the IANA considerations section, this document registers two URIs and two YANG modules, it also requests IANA to update the reference for the “YANG module Names” registry. Besides that, this document also amends the guidance on names unicity of IANA considerations to register YANG module and submodule names and add extra notes for the creation and maintenance of an IANA-maintained module.

The shepherd confirms that all aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries. The shepherd also confirms that any referenced IANA registries have been clearly identified in the document, and it doesn’t contain any newly created IANA registry.

In addition, IANA was solicited for feedback since early versions of the document, e.g.,
1. Individual submission: [netmod] TR: [IANA #1291942] RE: Early review: draft-boucadair-netmod-rfc8407bis (IETF 117), direct link: https://mailarchive.ietf.org/arch/msg/netmod/GFYUpkX6TjIOwlo4qDxD1TuvKwo/ ;
2. [netmod] Re: [IANA #1289473] Revision statements in IANA-maintained YANG modules (ietf.org), direct link: https://mailarchive.ietf.org/arch/msg/netmod/YqNYf0oR3OrDbd4xLynYrmWJ2Cs/ ;
3. [netmod] [IANA #1373241] RE: Regarding draft-ietf-netmod-rfc8407bis, direct link: https://mailarchive.ietf.org/arch/msg/netmod/qie6Gc4VZEqfKaXtjBZXgAS5iMo/ 

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.

Shepherd:
This document does not have any new IANA registries that require Designated Expert Review for future allocations.

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

Shepherd:
This document has been discussed extensively on the mailing list. The WG consensus represents the strong concurrence of a small amount of individuals with the other folks giving comments and suggestions on the changes of the document. No objections for publication or other comments were raised for the WGLC. Here is a direct link to that WGLC process:
https://mailarchive.ietf.org/arch/msg/netmod/u5Vk7_DgeXAOuq4h02hROfTYQaU/ 

As such, the shepherd believes that this document has reached a broad agreement as this WG would be expected to reach.

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

Shepherd:
There was no controversy about particular points, and the shepherd doesn’t notice any decisions where the consensus was particularly 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.)

Shepherd:
No one threatened an appeal or indicated extreme discontent.

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

Shepherd:
This document is not a protocol document. Instead, it provides guidelines for authors and reviewers of documents that contain YANG data models. The shepherd does not believe that this document pertains to any implementations.

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

Shepherd:
The document was reviewed by IANA and their inputs adequately implemented. Also, the document was circulated in SAAG mailing list to solicit reviews for the security template. Here is a direct link to that security template discussion on SAAG list: https://mailarchive.ietf.org/arch/msg/saag/z338jOL6mpYIIzT0Xk8ioCvi6v4/.

Besides that, the shepherd doesn't think the contents of this document closely interact with
technologies in other fields, and therefore the shepherd doesn't believe this
document needs further review from other IETF working groups or external organizations.


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.

Shepherd:
The document went through a YANG doctor review as part of the Last Call process.
Here is a direct link to that review:
https://datatracker.ietf.org/doc/review-ietf-netmod-rfc8407bis-11-yangdoctors-lc-liu-2024-06-17/
And all the comments raised by the YANG doctor were resolved by authors providing suggested texts for the YANG doctor to review, here is the related discussion about the Yang doctor last call review on the NETMOD WG mailing list:
https://mailarchive.ietf.org/arch/msg/yang-doctors/QFNwJC99AtorujtQLPtsRQZDVP8/
In addition, the shepherd confirms that the follow-up comment raised by the YANG doctor was also fixed.

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

Shepherd:
The document contains some example and template modules without any substantive definition and only for illustration purposes, YANG tools cannot validate them directly since some contents need to be replaced according to actual situations. The shepherd doesn’t think there is any syntax and formatting issues.

Note that DataTracker’s YANG validator reports 4 errors and 5 warnings which
are considered as false positives by the shepherd since they are about some fields that need to be replaced with real contents in the template modules.

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.

Shepherd:
The shepherd has reviewed the document, tested it against “idnits”. The document doesn’t contain any other parts that needs to be validated except for some YANG fragment, which have been checked by the shepherd.

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

Shepherd:
Yes. Based on the shepherd's review of the document, the shepherd believes that
this document is needed, clearly written, complete, correctly designed, and
ready to be handed off to the responsible Area Director.

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?


Shepherd:
The shepherd doesn’t see any common issues that need to be flagged. The shepherd believes that there is nothing that would merit specific attention from subsequent reviews.


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?

Shepherd:
This document is requested to be published as Best Current Practice. In this case, it is the correct state because this document defines some guidelines and obsoletes RFC 8407, which is also published as Best Current Practice.

The status is properly reflected on the Datatracker page, here is the direct link:
https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc8407bis/.

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.

Shepherd:
No IPR disclosure has been filed that references this document.

The WG chair has requested an IPR call on the list. All authors confirmed that
they are not aware of any IPR related to this document. All responses indicated
no IPR needs to be disclosed.

Here is the directed link to the IPR call request:
https://mailarchive.ietf.org/arch/msg/netmod/B9cnRJcAt-Gr1HnwQkM7RiWgHhY/
https://mailarchive.ietf.org/arch/msg/netmod/NDygxJmY6FEOwXS8ifGo08INR58/

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

Shepherd:
There are 3 authors (no greater than 5) for this document and no contributor being listed. Each author did not confirmed their willingness to be listed as such explicitly, but the shepherd assumes that all three of authors have been listed for some time and their silence implies consent. And all responded to the IPR polling during WGLC, which also implies that they are aware of their status on the document.

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

Shepherd:
I-D nits has been tested against -17, and it reports 1 error (**), 0 flaws (~~), 3 warnings (==), 4 comments (--), which are innocuous. Manual check of Guidelines to Authors of Internet-Drafts reveals no issues.

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

Shepherd:
The shepherd has reviewed that all references within this document have been
identified as either normative or informative, and all the informative and
normative references are classified correctly.


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

Shepherd:
None. All the normative references in the document are freely available to
anyone.


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.

Shepherd:
Yes, RFC 8792. However, that RFC is already listed in DOWNREF registry.

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?

Shepherd:
There are no normative references to documents that are not ready to be submitted to the IESG for publication or in an unclear state. All normative references are published.

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.

Shepherd:
The publication of this document will obsolete RFC8407, update RFCs 6020 and 8126. All of them are correctly reflected on the Datatracker metadata, document title page, in the abstract and discussed in the introduction.

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

Shepherd:
The shepherd has reviewed the IANA considerations section, this document registers two URIs and two YANG modules, it also requests IANA to update the reference for the “YANG module Names” registry. Besides that, this document also amends the guidance on names unicity of IANA considerations to register YANG module and submodule names and add extra notes for the creation and maintenance of an IANA-maintained module.

The shepherd confirms that all aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries. The shepherd also confirms that any referenced IANA registries have been clearly identified in the document, and it doesn’t contain any newly created IANA registry.

In addition, IANA was solicited for feedback since early versions of the document, e.g.,
• Individual submission: [netmod] TR: [IANA #1291942] RE: Early review: draft-boucadair-netmod-rfc8407bis (IETF 117), direct link: