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]
