Authors, While reviewing this document during AUTH48 (https://www.rfc-editor.org/authors/rfc9907.html), please resolve (as necessary) the following questions, which are also in the source file.
1) <!-- [rfced] Note: [RFC6421] uses "Operations layer" and "Content layer" rather than "operations layer" and "content layer". Please let us know if/how to update for consistency. Current: This document defines usage guidelines related to the NETCONF operations layer and NETCONF content layer, as defined in [RFC6241], and the RESTCONF methods and RESTCONF resources, as defined in [RFC8040]. --> 2) <!--[rfced] Would you like to move the "Changes Since RFC 8407" section to an appendix? That placement would be more consistent with other RFCs. (Perhaps this was already considered, as we see this was suggested on https://mailarchive.ietf.org/arch/msg/netmod/0Fj8uYw4Tz9GjxOzNoOxYOzJYFQ/) --> 3) <!--[rfced] There is a slight difference between the text in the change log and the text in the document with regard to how RFC 7952 is listed (i.e., is it an example of an RFC that might disqualify a document from needing the Security Considerations template, or are RFC 8791 and 7952 the only RFCs that would do that?). Change log (Original): * Added statements that the security template is not required for modules that follow [RFC8791] or [RFC7952]. Section 3.7 (Original): Unless the modules comply with [RFC8791] or define YANG extensions (e.g., [RFC7952]),... and Documents that exclusively define modules that follow the extension in [RFC8791] are not required to include the security template in Section 3.7.1. Likewise, following the template is not required for modules that define YANG extensions such as [RFC7952]. --> 4) <!--[rfced] Would the following update be agreeable? Original: * Updated the IANA considerations to encourage registration requests to indicate whether a module is maintained by IANA or not. Perhaps: * Updated the guidance for writing IANA Considerations sections to encourage registration requests to indicate whether or not a module is maintained by IANA. --> 5) <!--[rfced] Section 2: We have the following questions related to the terminology in this section: a) Please review our updates to the following text; based on the text that follows defining "published" and "unpublished", please confirm that this update is accurate (i.e., can an IETF module not exist in an I-D, "IETF module" would only be the terminology used for a published RFC). Original: IETF module: A YANG module that is published by the IETF and that is not maintained by IANA. Current: IETF module: A YANG module that is published as an RFC from the IETF Stream and that is not maintained by IANA. b) Is it possible to have a YANG module that is not IANA-maintained and not an IETF module? If so, should their be some kind of terminology to address that? c) In the following definition of "unpublished", might "unstable publication" be a bit contradictory? Perhaps Original: unpublished: An unstable release of a module or submodule. For example the "Internet-Draft" described in Section 2.2 of [RFC2026] is considered an unstable publication that is a work in progress, subject to change at any time. Perhaps: unpublished: An unstable release of a module or submodule. For example, the "Internet-Draft" described in Section 2.2 of [RFC2026] is considered an unstable work in progress, subject to change at any time. d) In the "published" and "unpublished" definitions, it seems a bit odd to expand RFC and put Request for Comments and Internet-Draft in quotes. Original: published: A stable release of a module or submodule. For example, the "Request for Comments" described in Section 2.1 of [RFC2026] is considered a stable publication. unpublished: An unstable release of a module or submodule. For example the "Internet-Draft" described in Section 2.2 of [RFC2026] is considered an unstable publication that is a work in progress, subject to change at any time. Perhaps: published: A stable release of a module or submodule. For example, the Request for Comments Series described in Section 2.1 of [RFC2026] is considered a stable publication. unpublished: An unstable release of a module or submodule. For example, the Internet-Draft described in Section 2.2 of [RFC2026] is considered an unstable work in progress, subject to change at any time. --> 6) <!-- [rfced] FYI - we note that [RFC6241] defines "capability" rather than "capabilities" and "protocol operation" rather than "operation". Please let us know if/how to update for consistency. Current: The following terms are defined in [RFC6241] and are not redefined here: * capabilities * client * operation * server Perhaps: The following terms are defined in [RFC6241] and are not redefined here: * capability * client * protocol operation (or simply "operation") * server --> 7) <!--[rfced] Might it be possible to swap Sections 2.4 and 2.5? Reasoning: Sections 2.1 - 2.3 are all YANG-terminology related, and so is Section 2.5. The boilerplate in Section 2.4 seems to interrupt that. Suggested: 2. Terminology and Notation Conventions 2.1. NETCONF Terms 2.2. YANG Terms 2.3. Network Management Datastore Architecture (NMDA) Terms 2.4. YANG Data Model versus YANG Module 2.5. Requirements Notation --> 8) <!--[rfced] Would you like to clarify "under review" here, or mention (anywhere in the document) who is reviewing the YANG module? We note that Appendix A mentions being reviewed for "technical correctness and adherence to IETF documentation requirements". Original: YANG modules under review are likely to be contained in Internet-Drafts (I-Ds). Perhaps: YANG modules being considered for publication in an RFC are contained in Internet-Drafts (I-Ds). --> 9) <!--[rfced] Should this text be updated to indicate that there can be more than one definitions section? (e.g., RFC 8776 contains modules in Sections 4 and 5.) Original: The following sections MUST be present in an I-D or RFC containing a YANG module: * Narrative sections (Section 3.5) * Definitions section (Section 3.6) Perhaps: The following sections MUST be present in an I-D or RFC containing one or more YANG modules: * Narrative sections (Section 3.5) * Definitions section(s) (Section 3.6) In Section 3.6: Original: This section contains the module(s) defined by the specification. Perhaps: One or more sections contain the module(s) defined by the specification. --> 10) <!--[rfced] Will the reader know when the guidelines are applicable to example modules and fragments? If not, where can they get more information to guide them? Original: The guidelines in this document refer mainly to a normative module or submodule but may be applicable to example modules and YANG fragments as well. --> 11) <!--[rfced] May we update "narrative part" to "narrative sections" in the following for consistency? Original: The narrative part MUST include an overview section that describes the scope and field of application of the data model(s) defined by the specification and that specifies the relationship (if any) of these data models to other standards, particularly to standards containing other YANG data models. Perhaps: The narrative sections MUST include an overview section that describes the scope and field of application of the data model(s) defined by the specification and that specifies the relationship (if any) of these data models to other standards, particularly to standards containing other YANG data models. --> 12) <!--[rfced] The subject/verb agreement here is difficult to follow. Would the suggested update below correctly convey your meaning? Original: If the module or modules defined by the specification imports definitions from other modules (except for those defined in [RFC7950] or [RFC6991]) or are always implemented in conjunction with other modules, then those facts MUST be noted in the overview section; any special interpretations of definitions in other modules MUST be noted as well. Perhaps: If the module (or modules) defined by the specification imports definitions from other modules (except for those defined in [RFC7950] or [RFC6991]) or is always implemented in conjunction with other modules, then those facts MUST be noted in the overview section; any special interpretations of definitions in other modules MUST be noted as well. --> 13) <!-- [rfced] FYI, we updated "4.2" to "A.4.2" here, as [RFC8969] does not have an Appendix 4.2, but does have an Appendix A.4.2. Please let us know if this is not accurate. We note that A.4.2 (Device Management) uses 'YANG modules' rather than 'models'. Perhaps A.4.4 (Some Device Model Examples) was intended? However, it notes notes the list is not comprehensive. Original: A comprehensive list of device models is provided in Appendix 4.2 of [RFC8969]. Current: A comprehensive list of device models is provided in Appendix A.4.2 of [RFC8969]. Perhaps: A non-comprehensive list of device models is provided in Appendix A.4.4 of [RFC8969]. --> 14) <!--[rfced] Regarding the statements about keywords from BCP 14, may we update the second part to use the same term ("keywords")? Specifically, may we replace "all-uppercase reserved words" with "keywords"? Original: ...within a YANG module are considered normative. The use of keywords defined in [RFC2119] and [RFC8174] apply to YANG "description" statements in normative modules exactly as they would in any other normative section. and Example YANG modules and example YANG fragments MUST NOT contain any normative text, including any all-uppercase reserved words from [RFC2119] and [RFC8174]. Perhaps: Example YANG modules and example YANG fragments MUST NOT contain any normative text, including any keywords from [RFC2119] and [RFC8174]. --> 15) <!--[rfced] Regarding Section 3.7: a) This text seems redundant. Please let us know if/how this section should be updated. Original: Unless the modules comply with [RFC8791] or define YANG extensions (e.g., [RFC7952]), the security section MUST be modeled after the latest approved template (available at <https://wiki.ietf.org/group/ops/yang-security-guidelines>). and Documents that exclusively define modules that follow the extension in [RFC8791] are not required to include the security template in Section 3.7.1. Likewise, following the template is not required for modules that define YANG extensions such as [RFC7952]. b) Looking at the citations to RFC 7952 in Section 3.7, the first mention calls it an example, while the later mention and the related entry in the change log seem more definitive. Are there other RFCs that define YANG extensions or should the example indication be removed? Please review and advise. Section 3.7 (Original): Unless the modules comply with [RFC8791] or define YANG extensions (e.g., [RFC7952]),... and Documents that exclusively define modules that follow the extension in [RFC8791] are not required to include the security template in Section 3.7.1. Likewise, following the template is not required for modules that define YANG extensions such as [RFC7952]. Change log (Original): * Added statements that the security template is not required for modules that follow [RFC8791] or [RFC7952]. --> 16) <!--[rfced] Regarding Sections 3.7 and 3.7.1 (Security Considerations Section Template): a) We note the the following text was removed from Section 3.7 between RFC 8407 and this document: Section 3.7.1 contains the security considerations template dated 2013-05-08 and last updated on 2018-07-02. As the template listed at https://wiki.ietf.org/group/ops/yang-security-guidelines is likely to continue to evolve ("latest approved template"), should there be some mention here that Section 3.7.1 is a snapshot of the template that is available in the wiki at the time of writing in order to avoid author confusion? b) With point (a) in mind, would it make sense to begin Section 3.7.1 (prior to <CODE BEGINS> with a note mentioning that what follows is a snapshot and authors should go to <https://wiki.ietf.org/group/ops/yang-security-guidelines> for the most up-to-date version (i.e., might someone just look up Section 3.7.1, without seeing 3.7, and not realize there are differences)? c) There are some minor differences between Section 3.7.1 and the wiki page. Should this document be updated to match the wiki? In addition to the differences between square and angle brackets, we see the following: i) Section numbering difference: This document: This section is modeled after the template described in Section 3.7 The wiki: This section is modeled after the template described in Section 3.7.1 ii) Numbering and textual differences: This document: These YANG-based management protocols (1) have to use a secure transport layer (e.g., SSH [RFC4252], TLS [RFC8446], and QUIC [RFC9000]) and (2) have to use mutual authentication. The wiki: These protocols have to use a secure transport layer (e.g., SSH [RFC4252], TLS [RFC8446], and QUIC [RFC9000]) and have to use mutual authentication. iii) Use of "reasonably": This document: All writable data nodes are likely to be sensitive or vulnerable in some network environments. The wiki: All writable data nodes are likely to be reasonably sensitive or vulnerable in some network environments. d) Might it make the template in Section 3.7.1 more easily usable to authors if it were numbered? That is: 1. Writable nodes section: 2. Readable nodes section: 3. RPC/action operations section: 4. Reusable groupings from other modules section: 5. No data nodes section: (If added, this numbering would appear in this document and the wiki page, not in the RFCs that make use of the template, as they typically do not include these section names.) e) Is it clear to authors how to approach the security considerations section for documents that contain more than one YANG module that might have different security considerations template applications? Should they include subsections of the Security Considerations section for each module? f) The following abbreviations (that are not denoted as well-known at https://www.rfc-editor.org/rpc/wiki/doku.php?id=abbrev_list) are used in the template in Section 3.7.1 and/or at https://wiki.ietf.org/group/ops/yang-security-guidelines without expansion. As this may be the first use of these abbreviations in a document in which this text is inserted, should they be expanded? NETCONF (a bit odd since RESTCONF has no expansion) SSH RPC g) A formatting question/suggestion inspired by the aesthetics of https://wiki.ietf.org/group/ops/yang-security-guidelines but also applicable to the template in Section 3.7.1: Should the quoted text like "There are no particularly sensitive writeable data nodes." actually appear under the blue bubble to match the way the text above was formatted (e.g., "There are a number of data nodes defined...")? So that the comments/blue bubbles are saying something like "If X is true, insert:" and the actual text to insert is not in the comment? h) We see the template gives instructions on what to include: -if a YANG module contains something (e.g., writeable nodes), -if the YANG module contains something particularly sensitive, and -if NO data nodes at all are included. However, is there ever a case where just one (or two) of the sections in this template might not apply (e.g., readable nodes exist but no writable ones do)? If so, will it be clear to authors how to handle that case? For example, should an instruction to include something like "There are no writable data nodes in this YANG module." be included? i) Following on with point (h) above, Section 3.7 states that YANG modules that comply with [RFC8791] or define YANG extensions (e.g., [RFC7952]) do not need to model their Security Considerations sections after the template. However, does it make sense to update the template (and https://wiki.ietf.org/group/ops/yang-security-guidelines) with text instructing authors to overtly mention that the YANG module complies with [RFC8791] or defines YANG extensions and thus the security considerations at https://wiki.ietf.org/group/ops/yang-security-guidelines do not apply? j) Might it be helpful to move the note (about references) at the end of Section 3.7.1 to match its placement at https://wiki.ietf.org/group/ops/yang-security-guidelines? k) Is "that" missing in the first sentence of the second comment in the "Readable nodes section:"? That is, if you remove the parenthetical, you would get: "You must evaluate whether the data model contains any readable data nodes [snip] are particularly sensitive..." l) In the "Readable nodes section:", it could be read as the right course of action would be to include: "Some of the readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. Specifically, the following subtrees and data nodes have particular sensitivities/vulnerabilities: There are no particularly sensitive readable data nodes." However, perhaps the intended meaning is to either have the first paragraph or have the last sentence? Or, is it the case that some YANG modules have sensitive data nodes that are not "particularly" sensitive? Please review. m) For the following sentence, a reader may expect "remind" to be a transitive verb (with object). May we rewrite as follows? Original: If the data model reuses groupings from other modules and the document that specifies these groupings also includes those as data nodes, then add this text to remind the specific sensitivity or vulnerability of reused nodes. Perhaps: If the data model reuses groupings from other modules and the document that specifies these groupings also includes those as data nodes, then add this text as a reminder of the specific sensitivity or vulnerability of the reused nodes. --> 17) <!--[rfced] Regarding the use of code markers: a) Please consider whether you want the <CODE BEGINS> and <CODE ENDS> markers to be added to any snippets in this document (i.e., if you want to add markers="true" to the sourcecode elements). We note Section 3.2.1 contains the following, but how it should be applied within this document is not clear: Example modules are not code components. The <CODE BEGINS> convention MUST NOT be used for example modules. However, example modules MUST be validated (Section 3.10). 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. c) Similarly, why are code markers used for the templates in Sections 4.30.3.1 and 4.30.3.2? --> 18) <!--[rfced] Please review our update to the following text to clarify the punctuation and use of the BCP 14 keyword. Original: For modules published within IETF documents, the appropriate IETF Trust Copyright text MUST be present, as described in Section 3.1 and contain the following statement: Current: For modules published within IETF documents, the appropriate IETF Trust Copyright text MUST be present, as described in Section 3.1, and MUST contain the following statement: --> 19) <!--[rfced] We note that RFC 6021 and RFC 6991 have been obsoleted by RFC 9911. Please review mentions in the text and let us know how you would like to update. --> 20) <!--[rfced] Would you like to add examples of "reference" substatements? The RPC and OPS ADs discussed this topic during IETF 123. The examples would show that the RFC title does not need to be included. (The exception is in the "revision" statement, where the title is typically included.) For example: reference (with section) "RFC 8665, Section 5 RFC 8666, Section 6"; reference (just RFC number) "RFC 8665 RFC 8666"; --> 21) <!--[rfced] Is YANG 1.1 still considered "new"? It was published as RFC 7950 in August 2016. Original: The set of guidelines for YANG 1.1 will grow as operational experience is gained with the new language features. This section contains an initial set of guidelines for new YANG 1.1 language features. --> 22) <!--[rfced] Section 4.30.2: Would you like to update these two paragraphs to make them more aligned? Or remove some text to reduce redundancy? To paraphrase: (A) says the I-D MAY supply the module or only a script. (B) says the I-D SHOULD supply the module when a script is used. A) Original (paragraph 5): Designers of IANA-maintained modules MAY supply the full initial version of the module in a specification document that registers the module or only a script to be used (including by IANA) for generating the module (e.g., an XSLT stylesheet as in Appendix A of [RFC9108] or a Python script as in [RFC9645]). For both cases, the document that defines an IANA-maintained module MUST include a note indicating that the document is only documenting the initial version of the module and that the authoritative version is to be retrieved from the IANA registry B) Original (paragraph 7): It is RECOMMENDED to include the URL from where to retrieve the recent version of the module. When a script is used, the Internet- Draft that defines an IANA-maintained module have to include an appendix with the full script and SHOULD include an appendix with the initial full version of the module. Including such an appendix in pre-RFC versions is meant to assess the correctness of the outcome of the supplied script. The authors MUST include a note to the RFC Editor requesting that the appendix with the initial version of the module be removed before publication as RFC and that RFC IIII is replaced with the RFC number that is assigned to the document. Also: - May "in pre-RFC versions" be changed to "in Internet-Drafts"? - May the phrases (A) "full initial version" and (B) "initial full version" of the module be made consistent? They seemingly refer to the same concept. --> 23) <!--[rfced] Would you like to update this paragraph about URLs so that the URLs are shown, rather than in references? (This would be a change from xref to eref elements.) Original: Examples of IANA URLs from which to retrieve the latest version of an IANA-maintained module are as follows: [IANA_BGP-L2_URL], [IANA_PW-Types_URL], and [IANA_BFD_URL]. "IANA_FOO_URL" is used in the following to refer to such URLs. These URLs are expected to be sufficiently permanent and stable. Whenever referencing a specific version of an IANA-maintained module is needed, then URLs such as [IANA_BGP-L2_URL-Revision] are used. "IANA_FOO_URL_With_REV" is used in the following to refer to such URLs. Perhaps: Examples of IANA URLs from which to retrieve the latest version of an IANA-maintained module are as follows: <https://www.iana.org/assignments/iana-bgp-l2-encaps> <https://www.iana.org/assignments/iana-pseudowire-types> <https://www.iana.org/assignments/iana-bfd-types> "IANA_FOO_URL" is used in the following to refer to such URLs. These URLs are expected to be sufficiently permanent and stable. Whenever referencing a specific version of an IANA-maintained module is needed, then URLs such as the following are used: <https://www.iana.org/assignments/yang-parameters/iana-bfd-types@ 2021-10-21.yang> "IANA_FOO_URL_With_REV" is used in the following to refer to such URLs. --> 24) <!--[rfced] Might this update capture your intended meaning? Note: similar text occurs more than once. Original: Specifically, if the name begins with a number, it is RECOMMENDED to spell out (i.e., write in full) the number when used as an identifier. Perhaps: Specifically, if the name begins with a number, it is RECOMMENDED to spell out (i.e., not use a digit) the number when used as an identifier. --> 25) <!-- [rfced] FYI- The reference [RFC-STYLE] was not cited in the document (though it was in RFC 8407), so we have removed the reference entry. Please let us know any objections. --> 26) <!--[rfced] For "I-D Boilerplate", would you like to point to to https://authors.ietf.org/required-content ? It seems more relevant than the broad page that https://www.ietf.org/id-info/guidelines.html resolves to (https://authors.ietf.org/en/content-guidelines-overview). Original: * I-D Boilerplate: Verify that the document contains the required I-D boilerplate (see <https://www.ietf.org/id-info/ guidelines.html>), including the appropriate statement to permit publication as an RFC, and that the I-D boilerplate does not contain references or section numbers. Perhaps: * I-D Boilerplate: Verify that the document contains the required sections (see <https://authors.ietf.org/required-content>). --> 27) <!--[rfced] We assume these warnings and errors for the template modules are as expected (from pyang with the ietf option). Please let us know if any updates are needed. - Appendix B [email protected]:1: warning: unexpected latest revision "date-revision" in [email protected], should be "2023-07-26" [email protected]:52: warning: RFC 8407: 3.1: The IETF Trust Copyright statement seems to be missing or is not correct (see pyang -ietf-help for details). [email protected]:60: error: bad value "date-revision" (should be date) [email protected]:71: error: bad value "date-initial" (should be date) - Appendix C [email protected]:1: warning: unexpected latest revision "date-revision" in [email protected], should be "2023-12-08" [email protected]:57: warning: RFC 8407: 3.1: The IETF Trust Copyright statement seems to be missing or is not correct (see pyang -ietf-help for details). [email protected]:68: error: bad value "date-revision" (should be date) [email protected]:80: error: bad value "date-initial" (should be date) --> 28) <!--[rfced] We have the following questions related to terminology usage throughout the document. a) Should "IANA-maintained modules" be "IANA-maintained YANG modules"? We made this change in the Abstract and Intro already, but should this carry throughout the text? b) We note that <CODE BEGINS>, <CODE ENDS>, and some other bracketed terms (e.g., <b>) used in running text also appear in quotes (i.e., "<CODE BEGINS>") in some instances but simply bracketed in others (e.g., <get>). Please review and let us know if/how these may be made consistent. c) We note that templates in this document use a mix of filler numbers for RFCs (e.g., RFC IIII, RFC XXXX, FFFF). We suggest updating to use RFC XXXX throughout. Please let us know any objections. d) Please review the use of module/model when it appears without YANG and confirm that these instances appear as intended. For example, (a) uses "modules" and (b) uses "models" in the following: Original: (a) Modules that require immediate support for the NMDA features SHOULD be structured for NMDA. but then: ...as either an existing model or a model created by hand or with suitable tools that mirror the current modeling strategies. and: (b) For published models, the model should be republished with an NMDA-compatible structure, deprecating non-NMDA constructs. 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 Please review and let us know if/how these should be updated to fit with the other statement names (that are generally quoted). NOTE 1: We have added some quotes to "revision" statement. Please review and confirm these changes. NOTE 2: We see that the quotes around require-instance statement were removed between RFC 8407 and this document. Please review and confirm this update is as intended. NOTE 3: We sometimes see the use of YANG statement. Should these simply be statement? "when" statement vs. "when" YANG statement "must" statement vs. "must" YANG 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 "enumeration" data type vs. enumeration data type vs. enumeration typedefs present vs. "not present" anyxml vs. "anyxml" descendant data nodes vs. "descendant" axis user-ordered list vs. user-ordered "list" leaf-list vs. "leaf-list" false vs. "false" true vs. "true" "deprecated" vs. "status deprecated" --> 29) <!-- [rfced] We have the following questions related to the use of <tt> element to mark certain terms in the XML file. a) Please review instances in which more than one term is enclosed in the <tt> tag. For example, should: <tt>"<b>" and "</b>"</tt> be made <tt>"<b>"</tt> and <tt>"</b>"</tt> and we see both: <tt>"<CODE BEGINS>" and "<CODE ENDS>"</tt> and <tt>"<CODE BEGINS>"</tt> and <tt>"<CODE ENDS>"</tt> 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. d) Please review the use of <tt><> with URLs. Should these instead use <eref>? For example: Original: <tt><https://www.ietf.org/id-info/guidelines.html></tt> Perhaps: <eref target="https://www.ietf.org/id-info/guidelines.html"; brackets="angle"/> e) Other than CODE BEGINS / ENDS and URLs, we see the following uses of <tt>. Please confirm these appear as you intended. <tt>'//chapter[42]'</tt> <tt>"<b>" and "</b>"</tt> <tt><get></tt> <tt>'*'</tt> --> 30) <!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let us know if any changes are needed. Updates of this nature typically result in more precise language, which is helpful for readers. Note that our script did not flag any words in particular, but this should still be reviewed as a best practice. --> Thank you. Megan Ferguson and Alice Russo RFC Production Center On Jan 8, 2026, [email protected] wrote: *****IMPORTANT***** Updated 2026/01/08 RFC Author(s): -------------- Instructions for Completing AUTH48 Your document has now entered AUTH48. Once it has been reviewed and approved by you and all coauthors, it will be published as an RFC. If an author is no longer available, there are several remedies available as listed in the FAQ (https://www.rfc-editor.org/faq/). You and you coauthors are responsible for engaging other parties (e.g., Contributors or Working Group) as necessary before providing your approval. Planning your review --------------------- Please review the following aspects of your document: * RFC Editor questions Please review and resolve any questions raised by the RFC Editor that have been included in the XML file as comments marked as follows: <!-- [rfced] ... --> These questions will also be sent in a subsequent email. * Changes submitted by coauthors Please ensure that you review any changes submitted by your coauthors. We assume that if you do not speak up that you agree to changes submitted by your coauthors. * Content Please review the full content of the document, as this cannot change once the RFC is published. Please pay particular attention to: - IANA considerations updates (if applicable) - contact information - references * Copyright notices and legends Please review the copyright notice and legends as defined in RFC 5378 and the Trust Legal Provisions (TLP – https://trustee.ietf.org/license-info). * Semantic markup Please review the markup in the XML file to ensure that elements of content are correctly tagged. For example, ensure that <sourcecode> and <artwork> are set correctly. See details at <https://authors.ietf.org/rfcxml-vocabulary>. * Formatted output Please review the PDF, HTML, and TXT files to ensure that the formatted output, as generated from the markup in the XML file, is reasonable. Please note that the TXT will have formatting limitations compared to the PDF and HTML. Submitting changes ------------------ To submit changes, please reply to this email using ‘REPLY ALL’ as all the parties CCed on this message need to see your changes. The parties include: * your coauthors * [email protected] (the RPC team) * other document participants, depending on the stream (e.g., IETF Stream participants are your working group chairs, the responsible ADs, and the document shepherd). * [email protected], which is a new archival mailing list to preserve AUTH48 conversations; it is not an active discussion list: * More info: https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc * The archive itself: https://mailarchive.ietf.org/arch/browse/auth48archive/ * Note: If only absolutely necessary, you may temporarily opt out of the archiving of messages (e.g., to discuss a sensitive matter). If needed, please add a note at the top of the message that you have dropped the address. When the discussion is concluded, [email protected] will be re-added to the CC list and its addition will be noted at the top of the message. You may submit your changes in one of two ways: An update to the provided XML file — OR — An explicit list of changes in this format Section # (or indicate Global) OLD: old text NEW: new text You do not need to reply with both an updated XML file and an explicit list of changes, as either form is sufficient. We will ask a stream manager to review and approve any changes that seem beyond editorial in nature, e.g., addition of new text, deletion of text, and technical changes. Information about stream managers can be found in the FAQ. Editorial changes do not require approval from a stream manager. Approving for publication -------------------------- To approve your RFC for publication, please reply to this email stating that you approve this RFC for publication. Please use ‘REPLY ALL’, as all the parties CCed on this message need to see your approval. Files ----- The files are available here: https://www.rfc-editor.org/authors/rfc9907.xml https://www.rfc-editor.org/authors/rfc9907.html https://www.rfc-editor.org/authors/rfc9907.pdf https://www.rfc-editor.org/authors/rfc9907.txt Diff file of the text: https://www.rfc-editor.org/authors/rfc9907-diff.html https://www.rfc-editor.org/authors/rfc9907-rfcdiff.html (side by side) Diff of the XML: https://www.rfc-editor.org/authors/rfc9907-xmldiff1.html Tracking progress ----------------- The details of the AUTH48 status of your document are here: https://www.rfc-editor.org/auth48/rfc9907 Please let us know if you have any questions. Thank you for your cooperation, RFC Editor -------------------------------------- RFC9907 (draft-ietf-netmod-rfc8407bis-28) Title : Guidelines for Authors and Reviewers of Documents Containing YANG Data Models Author(s) : A. Bierman, M. Boucadair, Ed., Q. Wu WG Chair(s) : Kent Watsen, Lou Berger Area Director(s) : Mohamed Boucadair, Mahesh Jethanandani -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
