Hi, Sorry, looks like I switched a couple of words around in Section 5.3.2. This should be changed:
OLD: The "reference" statement in an "identity" or "enum" substatement NEW: The "reference" substatement in an "identity" or "enum" statement thanks, Amanda On Mon Jan 26 20:13:10 2026, [email protected] wrote: > Hi Med, *Mahesh, (and IANA), > > Thanks for your careful reviews and replies. > > This message addresses mail from Mahesh, Med, and IANA (the changes > requested by Amanda on 22 January). For your convenience, we have > included links to the current versions of files in multiple places in > this mail (but all point to the same files). > > Please review all updates carefully and let us know if further changes > are necessary. We will await approvals from all parties (and of all > actions) listed at the AUTH48 status page (https://www.rfc- > editor.org/auth48/rfc9907) prior to moving this document forward in > the publication process. > > > > Addressing Mahesh’s reply (and necessary actions): > ------------------------------------------------- > *Mahesh - the addition of text to Section 3.9 can be viewed in the > diff files here: > https://www.rfc-editor.org/authors/rfc9907-auth48diff.html (AUTH48 > changes only) > https://www.rfc-editor.org/authors/rfc9907-auth48rfcdiff.html > (AUTH48 side by side) > > We have also attached a screenshot of the piece in question for your > convenience. > > > > With regard to the possible updates to the wiki page at > https://wiki.ietf.org/group/ops/yang-security-guidelines?, we have > also posted a diff file to highlight the current differences between > the document (template) and the wiki at: > > https://www.rfc-editor.org/authors/rfc9907-wiki-diff.html > > Some of the differences highlighted are expected and will likely > remain (e.g., having an RFC number in brackets or marking with a > double dash in the RFC itself vs. colored boxes), but there are some > textual differences remaining that we believe should be resolved. > > > Regarding this comment from Mahesh: > >>> OLD: > >>> "WG Web: <http://datatracker.ietf.org/wg/your-wg-name/> > >>> WG List: <mailto:[email protected]> > >>> > >>> NEW: > >>> "WG Web: http://datatracker.ietf.org/wg/your-wg-name > >>> WG List: YOUR-WG-NAME <mailto:[email protected]> > > > > Shouldn’t http be changed to https above? > > > [rfced] We have updated as suggested. Calling out here for author > awareness. > > > For the update to the instructions below: > > > NEW1: > > > > // RFC Ed: replace 'date-revision' with the module publication date > > <— Moved “RFC Ed: here > > // the format is (YYYY-MM-DD) > > > > // replace XXXX with actual RFC number and remove > > // this note > > > > revision date-revision { > > description > > "What changed in this revision."; > > reference > > "RFC XXXX: <Replace With Document Title>"; > > } > > > > // Authors: Replace RFC IIIII with the RFC number and title. <— Made > > the text similar to the note to the RFC Editor. > > // of the RFC that defined the initial version of > > // the module and remove this note > > > > revision date-initial { > > description > > "Initial version"; version."; > > reference > > "RFC IIII: <Replace With Document Title>"; > > } > > > > Please review our update to this text and let us know if any further > changes are necessary. > > *Mahesh - please also review and approve the following updates we have > received in the meantime: > > -the addition of text to the end of the Introduction > > -the updates captured in the "Addressing the mail exchange with IANA” > part of this email below (the updates suggested by IANA as well as our > updates to it) - this includes changes to Sections 4.30.3 (added > text), 4.30.3.1 (added and changed text), 4.30.3.2 (added and changed > text), 5.3 (and the reorganization/addition of Sections 5.3.1 and > 5.3.1). > > The above are reviewable in the files below: > > The files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9907.txt > https://www.rfc-editor.org/authors/rfc9907.pdf > https://www.rfc-editor.org/authors/rfc9907.html > https://www.rfc-editor.org/authors/rfc9907.xml > > The related diff files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9907-diff.html (comprehensive) > https://www.rfc-editor.org/authors/rfc9907-rfcdiff.html > (comprehensive side by side) > https://www.rfc-editor.org/authors/rfc9907-auth48diff.html (AUTH48 > changes to date) > https://www.rfc-editor.org/authors/rfc9907-auth48rfcdiff.html (AUTH48 > changes side by side) > https://www.rfc-editor.org/authors/rfc9907-lastdiff.html (last > version to this) > https://www.rfc-editor.org/authors/rfc9907-lastrfcdiff.html (last > version side by side) > > > Addressing Med’s mail (all resolved issues snipped): > --------------------------------------------------- > > > On Jan 16, 2026, at 12:43 AM, [email protected] wrote: > > > > > > >> > >> 4) For 28d: > >> > >>>> d) Please review the use of module/model when it appears > >> without YANG > >>>> and confirm that these instances appear as intended. > >>> > >>> [Med] Will review that separately. > >> > >> Please let us know if any further changes are necessary once you > >> complete your review. > > > > [Med] We can update all "model" occurrences in the bullet list of > > 4.23.3 to "module". > > > > Also, make a similar change in 4.23.3.1 for two occurrences. > [rfced] Please note that we also updated an instance before the > bulleted list in Section 4.23.3. Please review and let us know if > this change should be reverted. > > > >> > >> 5) 28(e) and 28(f) ask about quotation around terms: > >> > >>>> e) We note that there may be some inconsistency in the double > >> quotes > >>>> around statement names. For example, these terms are not > >> quoted at > >>>> places in the text: > >>>> > >>>> import statement > >>>> include statement > >>>> normative reference statement > >>>> XPath statement > >>>> extension statement > >>>> YANG statement > >>>> YANG extension statement > >>>> YANG conditional statement > >>>> reference statement > >>>> length statement > >>>> module tag extension statement > >>> > >>> [Med] Please follow the same convention as in RFC8407 for these. > >> > >> Unfortunately, RFC 8407 has some inconsistencies here. A number > >> of the items in the list above appear in both quotes and unquoted, > >> with the latter being more prevalent. Other statement names like > >> "description" and "revision" statement are majority quoted. > >> Please let us know if one of the following options should be > >> implemented: > >> a) double quote all statement (and substatement?) names > > > > [Med] We can double quote all statements for internal consistency > > then and also with RFC7950. > > > > Here is my proposal: > > > > "import" statement > > "include" statement > > normative "reference" statement > > "XPath" statement > > "extension" statement > > YANG statement > > YANG "extension" statement > > YANG conditional statement > > "reference" statement > > "length" statement > > module-tag "extension" statement > > [rfced] In implementing these suggestions, we had these follow up > queries: > > -Should anydata be quoted here? > “Added anydata to the list of statements with mandatory”. > > -Should any quotes be added here? > "YANG module namespace statement" (see also namespace statement > without YANG module before). > > -Should “definition” be double-quoted in the following or other > instances of “data definition statement"? > “...all top-level data definition statements…" > > -We see this use of “extensions statement”; should double quotes be > used? > “…or a “nacm:default-deny-all” extensions statement, then those…" > > -We assume these should not be single-quoted in the YANG example, > please confirm. > "Several description and pattern statements have been improved.”;" > Pattern statements; range statement; max-elements statement; list > statement; YANG constraint statments, and YANG deviation statement? > > -Please advise on how quoting should appear in the following titles > (i.e., should any of these be double quoted as well?): > 4.8. Module Header, Meta, and Revision Statement (quotes only on > Revision, correct?) > 4.19.1. Conditional Augment Statements > 4.19.2. Conditionally Mandatory Data Definition Statements > 4.20. Deviation Statements > 4.21. Extension Statements > > -We added quotes to “extension” statement, but that makes for back-to- > back quotes as seen in this example (see Section 4.29 for more > examples): > “...the use of the "structure" “extension” statement...” > > > >>> > >>>> > >>>> f) Further, there are some similar terms that may benefit from > >>>> quotation review. We see: > >>>> > >>>> when expression vs. "when" expression must expression vs. > >> "must" > >>>> expression > >> > >> [rfced] Note also that we see "when" statement and "must" > >> statement. Should these be updated to expression? > > > > [Med] statement is actually more compliant with RFC7950. > > [rfced] We have updated from “expression” to “statement” per this > guidance. Please review and let us know if this is in error. > > > > > > > >> > > > >> > >>>> "deprecated" vs. "status deprecated" > >> > >> [rfced] We have added quotation marks where these appears to be a > >> setting. Please advise if any changes from simply "deprecated" to > >> instead say "status deprecated" are desired. > > > > [Med] The 2 uses in the doc are OK. However, when re-reading: > > > > CURRENT: > > The "/interfaces-state" hierarchy has > > been marked "status deprecated". Models that mark their > > "/foo- > > state" hierarchy with "status deprecated" will allow NMDA- > > > > I wonder whether: > > > > OLD: been marked "status deprecated". > > > > NEW: been marked with "status deprecated”. > [rfced] We have made this update as requested. As this was marked “I > wonder”, please confirm this appears as desired. > > > >>> > >> > >> 6) We did not see a reply to questions 29(b) and 29(c). Please > >> let us know if any action is necessary on these items: > >> > >>>> b) Please review the use of quotation marks (both single quotes > >> and > >>>> double quotes) with these terms; specifically, should they be > >> moved > >>>> to outside the <tt> tag? > >>>> > >>>> For example, we see both: > >>>> > >>>> <tt>"<CODE BEGINS>"</tt> tag > >>>> > >>>> and > >>>> > >>>> <tt><CODE BEGINS></tt> convention > >>>> > >>>> c) Please review to ensure the usage of <tt> is consistent. It > >>>> appears that there may be varying treatment of these terms. > >> > > > > [Med] Please use a consistent approach for all similar matters. > [rfced] We have updated to include double quotes outside the <tt> tags > for CODE BEGINS and CODE ENDS throughout. We have added <tt> tags and > quotation marks around BEGIN TEMPLATE TEXT and END TEMPLATE TEXT as > well. Please let us know any objections. > > The above updates (and all the updates related Med’s mail are > reviewable in the most recent postings, again, those are viewable at: > > The files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9907.txt > https://www.rfc-editor.org/authors/rfc9907.pdf > https://www.rfc-editor.org/authors/rfc9907.html > https://www.rfc-editor.org/authors/rfc9907.xml > > The related diff files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9907-diff.html (comprehensive) > https://www.rfc-editor.org/authors/rfc9907-rfcdiff.html > (comprehensive side by side) > https://www.rfc-editor.org/authors/rfc9907-auth48diff.html (AUTH48 > changes to date) > https://www.rfc-editor.org/authors/rfc9907-auth48rfcdiff.html (AUTH48 > changes side by side) > https://www.rfc-editor.org/authors/rfc9907-lastdiff.html (last > version to this) > https://www.rfc-editor.org/authors/rfc9907-lastrfcdiff.html (last > version side by side) > > Addressing the mail exchange with IANA: > --------------------------------------- > > > RFC Editor: > > > > Hi! Med has asked us to coordinate four sets of changes to draft- > > ietf-netmod-rfc8407bis with you. He approved the proposed text for > > 4.30.3.1, 4.30.3.2, and 5.3 this morning, with a change that's been > > applied below (s/5.3/5.3.2/), and he provided the updated 4.30.3 text > > in a message from January 17th. > > > > thanks, > > Amanda > > > > ========================================== > > > > 1) Make this change to 4.30.3: > > > > OLD: > > > > * A note that unassigned or reserved values must not be present in > > the IANA-maintained module. > > > > * An instruction whether experimental values should be included in > > the IANA-maintained module. If no instruction is provided, > > experimental values MUST NOT be listed in the IANA-maintained module. > > > > * An instruction about how to generate the "revision" statement. > > > > NEW: > > > > The IANA Considerations Section MAY also provide the following > > information > > if a default action is expected: > > > > * A note whether unassigned or reserved values should be present in > > the IANA-maintained module. If no instruction is provided, > > unassigned or reserved values must not be present in > > the IANA-maintained module. > > > > * An instruction whether experimental values should be included in > > the IANA-maintained module. If no instruction is provided, > > experimental values MUST NOT be listed in the IANA-maintained > > module. > > > > * An instruction about how to generate the "revision" statement. > > If not present, default actions provided in Section 5.3 will be > > followed. > > [rfced] Note that we updated the last bullet point to read as “If no > instruction is provided” instead of “If not present” to be consistent > with the two previous points. Please let us know any objections. > > > > ========================================== > > > > 2) Update Section 4.30.3.1 to read as follows: > > > > 4.30.3.1. Template for IANA-Maintained Modules with Identities > > > > This template ends with a section labeled "OPTIONAL." Any text in > > this section that needs to be customized should be included in the > > template. Text that does not require customization should be omitted. > > > > <CODE BEGINS> > > > > This document defines the initial version of the IANA-maintained > > "iana-foo" YANG module. The most recent version of the YANG module > > is available from the "YANG Parameters" registry group > > [IANA-YANG-PARAMETERS]. > > > > IANA is requested to add this note to the registry: > > > > New values must not be directly added to the "iana-foo" YANG > > module. They must instead be added to the "foo" registry. > > > > IANA is requested to add this note to [reference-to-the-iana-foo- > > registry]: > > > > When this registry is modified, the YANG module "iana-foo" > > [IANA_FOO_URL] must be updated as defined in RFC IIII. > > > > When a value is added to the "foo" registry, a new "identity" > > statement needs to be added to the "iana-foo" YANG module. The name > > of the "identity" MUST be the name as provided in the registry. > > The "identity" statement should have the following > > sub-statements defined: > > > > "base": Contains 'name-base-identity-defined-in-foo'. > > > > "status": Include only if a registration has been deprecated or > > obsoleted. IANA "deprecated" maps to YANG status > > "deprecated", and IANA "obsolete" maps to YANG status > > "obsolete". > > > > "description": Replicates the description from the registry. > > > > "reference": Replicates the reference(s) from the registry. > > References to documents should also include titles. > > > > -- OPTIONAL: > > > > -- Include only text that needs to be customized for the module. > > -- Text that does not require customization should be > > -- omitted. > > > > -- Notes tagged with "--" include instructions for authors. These > > notes > > -- must not be copied. > > > > Unassigned and Reserved Values: > > > > -- To be completed only if unassigned and/or reserved values > > -- (which may include experimental values) should be included > > -- in the module. These values are typically not included. > > > > Description Substatements: > > > > -- To be completed only if the default actions described in > > -- Section 5.3.2 are to be overridden. > > -- Specify whether instructions apply to "revision" statements, > > "identity" statements, or both. > > > > Reference Substatements: > > > > -- To be completed only if the default actions described in > > -- Section 5.3.2 are to be overridden. > > -- Specify whether instructions apply to "revision" statements, > > "identity" statements, or both. > > > > Naming Considerations: > > > > -- If a name in the IANA registry does not comply with the > > -- YANG naming conventions, add details how IANA can generate > > -- legal identifiers. For example, if the name begins with > > -- a number, indicate a preference to spell out the number when > > -- used as an identifier. > > > > <CODE ENDS> > > [rfced] We made a slight further update to use “Section 5.3.2 of RFC > 9907” in the text under both “Description Substatements” and > “Reference Substatements”. We also updated the introductory text to > more closely match the text proposed for Section 4.30.3.2 (below). > Please review and let us know any concerns. > > > > ========================================== > > > > 3) Update Section 4.30.3.2 to read as follows (same text as above, > > aside from references to enums instead of identities): > > > > 4.30.3.2. Template for IANA-Maintained Modules with Enumerations > > > > This template ends with a section labeled "OPTIONAL." Any text in > > this section that needs to be customized should be included in the > > template. Text that does not require customization should be omitted > > from the IANA Considerations. > > > > <CODE BEGINS> > > > > This document defines the initial version of the IANA-maintained > > "iana-foo" YANG module. The most recent version of the YANG module > > is available from the "YANG Parameters" registry group > > [IANA-YANG-PARAMETERS]. > > > > IANA is requested to add this note to the registry: > > > > New values must not be directly added to the "iana-foo" YANG > > module. They must instead be added to the "foo" registry. > > > > IANA is requested to add this note to [reference-to-the-iana-foo- > > registry]: > > > > When this registry is modified, the YANG module "iana-foo" > > [IANA_FOO_URL] must be updated as defined in RFC IIII. > > > > When a value is added to the "foo" registry, a new "enum" statement > > must be added to the "iana-foo" YANG module. The "enum" statement, > > and sub-statements thereof, should be defined: > > > > "enum": Replicates a name from the registry. > > > > "value": Contains the decimal value of the IANA-assigned > > value. > > > > "status": Is included only if a registration has been > > deprecated or obsoleted. IANA "deprecated" maps > > to YANG status "deprecated", and IANA "obsolete" > > maps to YANG status "obsolete". > > > > "description": Replicates the description from the registry. > > > > "reference": Replicates the reference(s) from the registry. > > References to documents should also include titles. > > > > -- OPTIONAL: > > > > -- Include only text that needs to be customized for the module. > > -- Text that does not require customization should be > > -- omitted. > > > > -- Notes tagged with "--" include instructions for authors. These > > notes > > -- must not be copied. > > > > Unassigned and Reserved Values: > > > > -- To be completed only if unassigned and/or reserved values > > -- (which may include experimental values) should be included > > -- in the module. These values are typically not included. > > > > Description Substatements: > > > > -- To be completed only if the default actions described in > > -- Section 5.3.2 are to be overridden. > > -- Specify whether instructions apply to "revision" statements, > > "enum" statements, or both. > > > > Reference Substatements: > > > > -- To be completed only if the default actions described in > > -- Section 5.3.2 are to be overridden. > > -- Specify whether instructions apply to "revision" statements, > > "enum" statements, or both. > > > > Naming Considerations: > > > > -- If a name in the IANA registry does not comply with the > > -- YANG naming conventions, add details how IANA can generate > > -- legal identifiers. For example, if the name begins with > > -- a number, indicate a preference to spell out the number when > > -- used as an identifier. > > > > <CODE ENDS> > [rfced] We have made similar updates as mentioned above (added RFC > 9907 to section mentions). > > > > ========================================== > > > > 4) Replace Section 5.3 with the following: > > > > 5.3. IANA-Maintained Modules > > > > IANA should refer to Section 4.30.3 for information necessary to > > populate "revision" statements and "identity" and "enum" > > substatements in IANA-maintained modules. > > > > These considerations cover both the creation and maintenance of an > > IANA-maintained module, and they include both instructions applicable > > to all IANA-maintained modules and instructions that can be > > customized by module creators. > > > > 5.3.1. Requirements for All Modules > > > > In particular, the following instructions should apply to all > > modules: > > > > * When an underlying registration is deprecated or obsoleted, a > > corresponding "status" substatement should be added to the identity > > or enumeration statement. > > > > * The "reference" substatement in the revision statement should point > > specifically to the published module (i.e., IANA_FOO_URL_With_REV). > > When the registration is triggered by an RFC, that RFC must also be > > included in the "reference" substatement. It may also point to an > > authoritative event triggering the update to the YANG module. In all > > cases, the event is cited from the underlying IANA registry. > > > > * References to documents should include titles. > > > > In addition, when the module is published, IANA must add the > > following notes to: > > > > The YANG Module Names registry: > > New values must not be directly added to the "iana-foo" YANG module. > > They must instead be added to the "foo" registry. > > > > The underlying registry: > > When this registry is modified, the YANG module "iana-foo" > > [IANA_FOO_URL] must be updated as defined in RFC IIII. > > > > 5.3.2. Requirements Subject to Customization > > > > Unless the creators of an IANA-maintained module specify otherwise in > > their document's IANA Considerations section, the following > > instructions will apply: > > > > * Unassigned and reserved values (including experimental values) will > > be omitted from the module. > > > > * The "reference" statement in an "identity" or "enum" substatement > > should mirror the underlying registry. It may point to contact names > > as well as documents. > > > > * In a revision statement, the "description" substatement captures > > what changed in the > > revised version. Typically, the description enumerates changes > > such as updates to existing entries (e.g., update a description or > > a reference) or notes which identities were added or had their status > > changed (e.g., deprecated, discouraged, or obsoleted). > > > > When such a description is not feasible, the description varies in > > accordance with the trigger for the update. > > > > If the update is triggered by an RFC, the "description" substatement > > should include or consist of this text: > > "Applied updates as specified by RFC XXXX." > > > > If the registration policy for the registry does not require RFC > > publication (Section 4 of [RFC8126]), insert this text: > > > > "Applied updates as specified by the registration policy > > <Some_IANA_policy>". > > [rfced] A few points: > > 1) Please review the following text: > > > * When an underlying registration is deprecated or obsoleted, a > > corresponding "status" substatement should be added to the identity > > or enumeration statement. > > > Should double quotes be added to make this “identity” or “enumeration” > statements (double quotes and plural statement)? We also note that > “identity” and “enum” substatements used in the text preceding this. > Please confirm that these should not match (i.e., the lead in text is > about substatements and the text above is about statements). > > 2) We have updated to use “revision” statement (in quotes) or > “description” etc. Please review any addition of quotation marks and > let us know if these were general uses instead of statement names and > we can revert if necessary. > > 3) Should the following text be in double quotes in the template? > Other parts of the template are not quoted... > > > "Applied updates as specified by RFC XXXX." > > > > and > > > "Applied updates as specified by the registration policy > > <Some_IANA_policy>". > > The incorporation of the updates requested by IANA are reviewable in > the most recent postings, which (again) are located at: > > The files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9907.txt > https://www.rfc-editor.org/authors/rfc9907.pdf > https://www.rfc-editor.org/authors/rfc9907.html > https://www.rfc-editor.org/authors/rfc9907.xml > > The related diff files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9907-diff.html (comprehensive) > https://www.rfc-editor.org/authors/rfc9907-rfcdiff.html > (comprehensive side by side) > https://www.rfc-editor.org/authors/rfc9907-auth48diff.html (AUTH48 > changes to date) > https://www.rfc-editor.org/authors/rfc9907-auth48rfcdiff.html (AUTH48 > changes side by side) > https://www.rfc-editor.org/authors/rfc9907-lastdiff.html (last > version to this) > https://www.rfc-editor.org/authors/rfc9907-lastrfcdiff.html (last > version side by side) > > Thank you. > > Megan Ferguson > RFC Production Center -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
