Mahesh, Sounds good. We have incorporated the change to “Optional”. We believe that closes out Issues 2 and 4 from our previous mail.
So we will wait to hear back: -from the authors regarding Issue 1 (the added text to Section 3.9) -that the wiki page has been updated (Issue 3) prior to moving this document forward. 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) The AUTH48 status page is viewable here: https://www.rfc-editor.org/auth48/rfc9907 Thank you. Megan Ferguson RFC Production Center > On Feb 12, 2026, at 4:32 PM, Mahesh Jethanandani <[email protected]> > wrote: > > Hi Megan, > >> On Feb 12, 2026, at 2:54 PM, Megan Ferguson <[email protected]> >> wrote: >> >> Hi Mahesh, >> >> Thanks for the quick reply! >> >> Some follow-ups below marked with [rfced]. >> >> Thank you. >> >> Megan Ferguson >> RFC Production Center >> >>>> >>>> >>>> Issue #2: Redundant text in Section 4.30.3.1: >>>> >>>> We have updated to remove the text from the first paragraph in this >>>> section as Mahesh suggested. >>>> >>>> Out of curiosity, is this a BCP 14 OPTIONAL? Or is this all caps just to >>>> call attention to it? >>>> >>>> Current: >>>> This template ends with a section labeled "OPTIONAL”. >>> >>> My take is that it is not. It just happens to be all caps, and it just >>> happens to be one of the keywords from BCP 14. If we want to disambiguate, >>> we could call it TEMPLATE. >> >> [rfced] Could we simply have this appear as “Optional” (as it is inside a >> template)? >> >> Note that this would include a change in multiple places (twice in both >> Sections 4.30.3.1 and 4.30.3.2). >> >> Current: >> This template ends with a section labeled "OPTIONAL”. >> … >> -- OPTIONAL: >> >> Perhaps: >> This template ends with a section labeled "Optional”. >> … >> --Optional: > > I am ok with that > >> >> >> >> Further related clean up: >> a) This discussion made me realize that we had not updated the <CODE BEGINS> >> and <CODE ENDS> tags used in Sections 4.30.3.1 and 4.30.3.2 to instead use >> <BEGIN TEMPLATE TEXT> and <END TEMPLATE TEXT> (as we had done in the >> security considerations template section (see discussion with Med below)). >> This change has now been incorporated (please refresh links to view). >> >> Note also that we made the following related change to the change log: >> >> Original: >> * Added code markers for the security template. >> >> Current: >> * Added template markers for the security template. > > I do agree that it is not code, and using code markers would be odd. Thanks > for updating them to use template markers. > >> >> b) Note also that we have removed the following text from Section 4.30.3.2 >> (to match its removal in 4.30.3.1). >> >> Original: >> >> 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 section. >> >> Current: >> This template ends with a section labeled "OPTIONAL”. > > Thanks for catching that. > > Cheers. > >> >> >> >>>>> b) In contrast, regarding your note (about Section 3.7.1): >>>>> * Added code markers for the security template. >>>>> >>>>> Why are the code markers being used for the security >>>>> considerations >>>>> template? It seems odd because it is prose, not code. >>>> >>>> [Med] This one was requested by the trust. Please see >>>> https://datatracker.ietf.org/meeting/116/materials/slides-116-netmod-05-security-considerations-template-for-yang-module-documents-00 >>>> or >>>> https://mailarchive.ietf.org/arch/msg/netmod/gBEuz3mgOuyghmeQk7T4so_ZxF8/. >>>> >>>>> >>>>> c) Similarly, why are code markers used for the templates >>>>> in Sections 4.30.3.1 and 4.30.3.2? >>>> >>>> [Med] For the same reasons as above. >>> >>> Might it be possible to update to <BEGIN TEMPLATE TEXT> and <END TEMPLATE >>> TEXT> instead? Additionally, should the following paragraph from the TLP >>> should be included? >>> >>> From https://trustee.ietf.org/documents/trust-legal-provisions/tlp-5/ >>> (which is linked to from >>> https://datatracker.ietf.org/meeting/116/materials/slides-116-netmod-05-security-considerations-template-for-yang-module-documents-00): >>> >>> Section 9. Template Text >>> a. Certain RFCs may contain text designated as “Template Text” by the >>> inclusion of the following legend in the introduction to the RFC: >>> >>> “This RFC contains text intended for use as a template as designated below >>> by the markers <BEGIN TEMPLATE TEXT> and <END TEMPLATE TEXT> or other clear >>> designation. Such Template Text is subject to the provisions of Section >>> 9(b) of the Trust Legal Provisions.” >> >>> [Med] Works for me. Thanks >> >> >>> >>>> >>>> >>>> >>>> Issue #3: The wiki page update to make >>>> https://wiki.ietf.org/group/ops/yang-security-guidelines? match the >>>> template in the document: >>>> >>>> Note that we have added this as an “approver” on the AUTH48 status page at >>>> https://www.rfc-editor.org/auth48/rfc9907 to ensure we match up >>>> differences between the doc and that page prior to publication. >>>> >>>> In addition to updating to point to this document’s RFC number (once it is >>>> published), we think the following still need to be updated on the wiki >>>> page prior to publication (also viewable in the diff at >>>> https://www.rfc-editor.org/authors/rfc9907-wiki-diff.html): >>>> >>>> Current (at wiki): >>>> The Network Configuration Access Control Model (NACM) [RFC8341] provides >>>> the means to restrict access for particular NETCONF or... >>>> >>>> Perhaps (to match document): >>>> The Network Configuration Access Control Model (NACM) [RFC8341] provides >>>> the means to restrict access for particular Network Configuration Protocol >>>> (NETCONF) or... >>>> >>>> Current (at wiki): >>>> All writable data nodes are likely to be sensitive... >>>> >>>> Perhaps (to match document): >>>> All writable data nodes are likely to be reasonably sensitive… >>>> >>>> Current (at wiki): >>>> ...e.g., ones that might be protected by a "nacm:default-deny-write”... >>>> >>>> Perhaps (to match document): >>>> ...e.g., ones that might be protected by a "nacm:default-deny-write”… >>> >>> Hmm. I am not sure if I am seeing a difference. >> >> [rfced] Sorry - copy and paste error: >> >> Perhaps: >> ...e.g., ones that are protected by a "nacm:default-deny-write”… >> >>> >>>> >>>> Current (at wiki): >>>> ...or get-config) are particularly sensitive or vulnerable… >>>> >>>> Perhaps (to match document): >>>> ...or get-config) that are particularly sensitive or vulnerable… >>>> >>>> Current (at wiki): >>>> ...readable data nodes are ones that might be protected by a… >>>> >>>> Perhaps (to match document): >>>> ...readable data nodes are ones that are protected by a… >>>> >>>> Current (at wiki): >>>> ...then add this text to remind the specific sensitivity… >>>> >>>> Perhaps (to match document): >>>> ...then add this text as a reminder of the specific sensitivity… >>>> >>>> >>>> >>>> Issue #4: Our request for AD approval of Med’s suggestion. >>>> >>>> *Mahesh - please review and approve the following change: >>>> >>>> OLD: >>>> The IANA Considerations Section MAY also provide the following >>>> information if a default action is expected: >>>> >>>> NEW: >>>> The IANA Considerations Section MAY also provide the following >>>> information if a default action is to be overridden: >>> >>> I am ok with this change. >>> >>> Thanks for checking. >> >> [rfced] No problem. We have recorded your approval of this change in the >> Notes field of the AUTH48 status page, but have left your “Approval” field >> blank until the issue with the text in Section 3.9 issue is resolved (we >> believe we’ve heard back from you approving all other changes we requested - >> thank you!). >>> >>>> >>>> Please review our updates carefully as we do not make changes once the >>>> document is published as an RFC. >>>> Please contact us with any further changes you may have. >>>> >>>> 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) >>>> >>>> The AUTH48 status page is viewable here: >>>> https://www.rfc-editor.org/auth48/rfc9907 >>>> >>>> Thank you. >>>> >>>> Megan Ferguson >>>> RFC Production Center >>>> >>>> >>>>> On Feb 10, 2026, at 8:39 PM, Mahesh Jethanandani >>>>> <[email protected]> wrote: >>>>> >>>>> Hi Megan, >>>>> >>>>>> On Jan 26, 2026, at 12:13 PM, Megan Ferguson >>>>>> <[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. >>>>>> >>>>>> <Screen Shot 2026-01-16 at 10.25.54 AM.png> >>>>> >>>>> Thanks for sharing the screenshot of the set of changes. I went and >>>>> looked at all the revisions of the document including -25, the version >>>>> approved by IESG. This whole text is a completely new addition, and was >>>>> never approved by the WG or by IESG. As such, this cannot be approved, >>>>> unless we poll the WG regarding the change. Alternatively, we can just >>>>> drop this new text. I will also note that in later in the document, when >>>>> it comes to IANA modules, we insist that the reference statement contain >>>>> the title of the RFC. As such, these guidances are contradicting each >>>>> other. >>>>> >>>>> Separately, I will note that in Section 4.30.3.1 this text is repeated >>>>> twice. The first time in the first paragraph: >>>>> >>>>> 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 section. >>>>> >>>>> and later in the “OPTIONAL” section: >>>>> >>>>> -- Include only text that needs to be customized for the module. >>>>> -- Text that does not require customization should be >>>>> -- omitted. >>>>> >>>>> Do we need it twice? Maybe remove the new text in the first paragraph?? >>>>> >>>>>> >>>>>> 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. >>>>> >>>>> Ok. >>>>> >>>>>> >>>>>> >>>>>> 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. >>>>> >>>>> Ok. >>>>> >>>>>> >>>>>> >>>>>> 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). >>>>> >>>>> I have reviewed these changes and approve of them. >>>>> >>>>> Thanks >>>>> >>>>>> >>>>>> 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 >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> Mahesh Jethanandani >>>>> [email protected] >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>> >>> >>> Mahesh Jethanandani >>> [email protected] >> > > > Mahesh Jethanandani > [email protected] > > > > > > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
