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

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

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.

# É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` ;-)

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!

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.

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

<minor> 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	   <https://wiki.ietf.org/group/ops/yang-security-guidelines>).

<major> 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	     <https://github.com/mbj4668/pyang>

<minor> 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

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

<major> 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

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

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

<major> 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

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


<EoRv26>

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

# 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	       <URN prefix string>:<module-name>

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.

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
   <https://www.ietf.org/id-info/checklist.html>, 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?