Hi Megan and Alice, all, Thank you for the careful edits.
Please see inline. Cheers, Med > -----Message d'origine----- > De : [email protected] <[email protected]> > Envoyé : vendredi 9 janvier 2026 07:43 > À : [email protected]; BOUCADAIR Mohamed INNOV/NET > <[email protected]>; [email protected] > Cc : [email protected]; [email protected]; netmod- > [email protected]; [email protected]; [email protected]; > [email protected] > Objet : Re: AUTH48: RFC-to-be 9907 <draft-ietf-netmod-rfc8407bis- > 28> for your review > > > Authors, > > > 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]. > --> [Med] This was inherited from RFC8407, but I agree that we need to be consistent with RFC6421. > > > 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > mailarchive.ietf.org%2Farch%2Fmsg%2Fnetmod%2F0Fj8uYw4Tz9GjxOzNoOxY > OzJYFQ%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C8133dfb0 > 769d48d78e3f08de4f4a464f%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C > 0%7C639035377739503785%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnR > ydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyf > Q%3D%3D%7C0%7C%7C%7C&sdata=75USd6OlXiOMeTLW7i%2BNiE1gXswS1yC293dtO > OgVBP8%3D&reserved=0) > --> [Med] I suggest to leave this unchanged for consistency with RFC 8407, but also to not break the section mappings (RFC 8407 vs 9907). > > > 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]. [Med] I suggest we make this change: OLD: modules that follow [RFC8791] or [RFC7952]. NEW: modules that follow [RFC8791] or define YANG extensions such as [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. > --> [Med] ACK. > > > 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). > [Med] The community is currently working on an initiative (called, VELOCE) to publish YANG modules outside RFCs. The OLD wording is careful on this matter and does not tie it to an RFC. > Original: > IETF module: A YANG module that is published by the IETF and > that is > not maintained by IANA. > [Med] The original is accurate and future proof. Please revert to the OLD. > 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? [Med] There might be modules published by other streams, but I'm not sure we need to have a term for those. Although the guidance can be applied widely, we primarily target IETF/IANA ones. > > > 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. > [Med] Let me first remind that this text was inherited from RFC8407. Your updated version is better, though. > > 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. > --> [Med] Idem as above, this was inherited from RFC8407. The change looks good to me. > > > 6) <!-- [rfced] FYI - we note that [RFC6241] defines "capability" > rather > than "capabilities" and "protocol operation" rather than > "operation". [Med] Idem as above, this was inherited from RFC8407. Both "capabilities" and "operation" are used in RFC6241, although not formally listed under Section 1.1. I would not object to the change you suggest below for consistency with 6241 terms listed in 1.1. 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. [Med] The reason for the current order is to not break section mappings vs. 8407. I suggest to not make the change. > > 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? [Med] Idem as above, this was inherited from RFC8407. > 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). [Med] Works for me. > --> > > > 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) > [Med] ACK > > 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. > --> [Med] Idem as above, this was inherited from RFC8407. I would leave this unchanged. > > > 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. [Med] That is up to the authors of such modules to decide what to pick from the guidance. I don't think we need to say more here. > --> > > > 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. > --> [Med] OK. > > > 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. > --> > [Med] Works for me with s/6991/9911. > > 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]. [Med] This one is better. Thanks. > --> > > > 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]. [Med] This is an improvement compared to the text inherited from RFC8407. Thanks. > --> > > > 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 > Fwiki.ietf.org%2Fgroup%2Fops%2Fyang-security- > guidelines&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C8133dfb > 0769d48d78e3f08de4f4a464f%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7 > C0%7C639035377739518661%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn > RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoy > fQ%3D%3D%7C0%7C%7C%7C&sdata=SLnoDQhb2SZw%2FuB3q%2B%2BtcKDVEpinc%2F > CkByeJqADWL8g%3D&reserved=0>). > > 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]. > [Med] This is on purpose as we wanted to highlight that part. No change is needed here. > > 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]. [Med] I think that this is addressed by a change I proposed earlier. > --> > > > 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > wiki.ietf.org%2Fgroup%2Fops%2Fyang-security- > guidelines&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C8133dfb > 0769d48d78e3f08de4f4a464f%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7 > C0%7C639035377739530623%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn > RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoy > fQ%3D%3D%7C0%7C%7C%7C&sdata=J%2FbymyHkTg5ZoqFzx9WaHVgUDSj22dJPprNH > NIxMA9M%3D&reserved=0 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? [Med] The text in 3.7 is clear that the authoritative text is the wiki one and the authors MUST use that one. > > 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 > Fwiki.ietf.org%2Fgroup%2Fops%2Fyang-security- > guidelines&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C8133dfb > 0769d48d78e3f08de4f4a464f%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7 > C0%7C639035377739541381%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn > RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoy > fQ%3D%3D%7C0%7C%7C%7C&sdata=ELwXCK2kcrcxp6vJplUrspdU31mxOVNaIETQiB > 7BCOw%3D&reserved=0> 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 > [Med] Please update the draft to refer to 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. [Med] The wiki should be updated to use the version in the draft. > > 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. > [Med] The wiki should be updated to use the version in the draft. > 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.) > [Med] That's a good suggestion, but given the practice so far I suggest we keep the current formatting. > > 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? [Med] This is left to the authors to decide if they group the considerations in one single place or have dedicated section per module. > > 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www.rfc- > editor.org%2Frpc%2Fwiki%2Fdoku.php%3Fid%3Dabbrev_list&data=05%7C02 > %7Cmohamed.boucadair%40orange.com%7C8133dfb0769d48d78e3f08de4f4a46 > 4f%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C639035377739551935 > %7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwM > CIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&s > data=vzAhrDQROPi8pkqNRMXX5E6BhNvdSELy21v5qtZJ9rA%3D&reserved=0) > are used > in the template in Section 3.7.1 and/or at > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > wiki.ietf.org%2Fgroup%2Fops%2Fyang-security- > guidelines&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C8133dfb > 0769d48d78e3f08de4f4a464f%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7 > C0%7C639035377739562041%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn > RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoy > fQ%3D%3D%7C0%7C%7C%7C&sdata=M7NReiGO1avqkSYHcSu54X3Rl5yi%2FHnJIMNW > DgUkiI4%3D&reserved=0 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 > [Med] The practice so far is not expand these, however feel free to use the expanded version here. > > g) A formatting question/suggestion inspired by the aesthetics of > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > wiki.ietf.org%2Fgroup%2Fops%2Fyang-security- > guidelines&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C8133dfb > 0769d48d78e3f08de4f4a464f%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7 > C0%7C639035377739571982%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn > RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoy > fQ%3D%3D%7C0%7C%7C%7C&sdata=%2BuoHWKVjW1Rmk5Sf3n%2BZKauH04ijEZX8CN > d3Mq3RScA%3D&reserved=0 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? [Med] I think the current form is OK as this is relevant the assessment that in the same level as the last sentence of the previous blob "The following subtrees ...". > > 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? [Med] We have considered this one and my take is to only consider parts that are applicable. No need to have such mention when there are no such nodes. > > 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > wiki.ietf.org%2Fgroup%2Fops%2Fyang-security- > guidelines&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C8133dfb > 0769d48d78e3f08de4f4a464f%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7 > C0%7C639035377739581664%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn > RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoy > fQ%3D%3D%7C0%7C%7C%7C&sdata=RISzD%2FhJR2MhO7NqgCRJtV1bmnGpCip38P0t > AsA5d10%3D&reserved=0) 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > wiki.ietf.org%2Fgroup%2Fops%2Fyang-security- > guidelines&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C8133dfb > 0769d48d78e3f08de4f4a464f%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7 > C0%7C639035377739591696%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn > RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoy > fQ%3D%3D%7C0%7C%7C%7C&sdata=BD3VDLe%2FxzMD3hYpontbvMtrdrpABgM4qDZt > 4kZ8W4Q%3D&reserved=0 do not apply? [Med] I'm not sure we need to have this mention in the template as this will be conflicting with Unless the modules comply with [RFC8791] or define YANG extensions (e.g., [RFC7952]), the security section MUST be modeled after the latest approved template Authors can choose their wording when the models falls under the exception case. > > 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > wiki.ietf.org%2Fgroup%2Fops%2Fyang-security- > guidelines&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C8133dfb > 0769d48d78e3f08de4f4a464f%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7 > C0%7C639035377739602284%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn > RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoy > fQ%3D%3D%7C0%7C%7C%7C&sdata=MNv8tZzUn4EzLB93qJw5buBvcYR1YHMXSftSrl > VbuOM%3D&reserved=0? [Med] OK. > > 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..." [Med] good catch. "that" is missing. > > 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? [Med] You got it. There might be case with sensitive nodes, but only particularly sensitive ones are to be listed (if any). 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. > --> [Med] Works for me. > > > 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. [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. > --> > > > 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: > --> [Med] ACK. > > > 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. > --> [Med] the use of 6021/6991 in examples is OK as these are examples. However, [RFC6991] citation occurrences can be updated to [RFC9911]. > > > 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"; > --> [Med] Maybe we can add the following at the end of 3.9 NEW: Except the "import" and "revision" statements, note that it is acceptable to reference RFCs with their labels and without expanding their titles. An example of such use is as follows: leaf site-of-origin { type rt-types:route-origin; description "The Site of Origin attribute is encoded as a Route Origin Extended Community. It is meant to uniquely identify the set of routes learned from a site via a particular AC and is used to prevent routing loops."; reference "RFC 4364, Section 7"; } leaf ipv6-site-of-origin { type rt-types:ipv6-route-origin; description "The IPv6 Site of Origin attribute is encoded as an IPv6 Route Origin Extended Community. It is meant to uniquely identify the set of routes learned from a site."; reference "RFC 5701"; } > > > 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. [Med] We can delete "new". > --> > > > 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. > [Med] The MAY in A covers full initial module vs.** script only**. B is more a reco for 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"? [Med] OK > - 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. > --> [Med] We can use "initial full version". > > > 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 > Fwww.iana.org%2Fassignments%2Fiana-bgp-l2- > encaps&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C8133dfb0769 > d48d78e3f08de4f4a464f%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7 > C639035377739612697%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydW > UsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3 > D%3D%7C0%7C%7C%7C&sdata=bT5kCQA0N%2F9R7quaf8KVBlVyqHW%2B9ekcVdUHBD > 0dvU0%3D&reserved=0> > > <https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 > Fwww.iana.org%2Fassignments%2Fiana-pseudowire- > types&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C8133dfb0769d > 48d78e3f08de4f4a464f%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C > 639035377739622519%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWU > sIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D > %3D%7C0%7C%7C%7C&sdata=ieenhOkSaDldwugg5WnJNrd4G926YyVthJLG%2BYpbt > BI%3D&reserved=0> > > <https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 > Fwww.iana.org%2Fassignments%2Fiana-bfd- > types&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C8133dfb0769d > 48d78e3f08de4f4a464f%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C > 639035377739634459%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWU > sIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D > %3D%7C0%7C%7C%7C&sdata=BxUL7Afz4RMGsl%2Bu5a0sY%2BDWCaXjhB5MCvKxfRL > HLwE%3D&reserved=0> > > "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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 > Fwww.iana.org%2Fassignments%2Fyang-parameters%2Fiana-bfd- > types%40&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C8133dfb07 > 69d48d78e3f08de4f4a464f%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0 > %7C639035377739647214%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRy > dWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ > %3D%3D%7C0%7C%7C%7C&sdata=w70eFrdu8LtEyTjVM6ESGjixMi6H517Budt0fmsU > K3Y%3D&reserved=0 > 2021-10-21.yang> > > "IANA_FOO_URL_With_REV" is used in the following to refer to > such URLs. > --> [Med] Works for me. > > > 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. [Med] ACK. > --> > > > 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. [Med] ACK. > --> > > > 26) <!--[rfced] For "I-D Boilerplate", would you like to point to > to > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > authors.ietf.org%2Frequired- > content&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C8133dfb076 > 9d48d78e3f08de4f4a464f%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0% > 7C639035377739658902%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRyd > WUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ% > 3D%3D%7C0%7C%7C%7C&sdata=N4Bf0eWbPuK9KOvID%2F4kl%2FOYo0v6hZd8dFIL1 > 82l4wk%3D&reserved=0 ? > It seems more relevant than the broad page that > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www.ietf.org%2Fid- > info%2Fguidelines.html&data=05%7C02%7Cmohamed.boucadair%40orange.c > om%7C8133dfb0769d48d78e3f08de4f4a464f%7C90c7a20af34b40bfbc48b9253b > 6f5d20%7C0%7C0%7C639035377739668718%7CUnknown%7CTWFpbGZsb3d8eyJFbX > B0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFp > bCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=YNDMDsQ8slSitRUhU7E25IddtF > w%2BkGCC%2FWZTTd1rwOk%3D&reserved=0 resolves to > (https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 > Fauthors.ietf.org%2Fen%2Fcontent-guidelines- > overview&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C8133dfb07 > 69d48d78e3f08de4f4a464f%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0 > %7C639035377739678177%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRy > dWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ > %3D%3D%7C0%7C%7C%7C&sdata=fCGzRcd0QtWsHSWJmQRkhYq8j7DMSANOx%2BZsAx > %2BRJcw%3D&reserved=0). [Med] OK > > Original: > * I-D Boilerplate: Verify that the document contains the > required > I-D boilerplate (see > <https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 > Fwww.ietf.org%2Fid- > info%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C8133dfb076 > 9d48d78e3f08de4f4a464f%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0% > 7C639035377739688083%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRyd > WUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ% > 3D%3D%7C0%7C%7C%7C&sdata=qXZkHbcbuy7FJbcHInRfkalEDMfOsb6C0L8c6iAcX > QY%3D&reserved=0 > 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 > Fauthors.ietf.org%2Frequired- > content&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C8133dfb076 > 9d48d78e3f08de4f4a464f%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0% > 7C639035377739697772%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRyd > WUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ% > 3D%3D%7C0%7C%7C%7C&sdata=PXcabVQKsTMkNxfRse4F57wYum6yCEHp7Wcr6uLHk > gA%3D&reserved=0>). > --> > > > 27) <!--[rfced] We assume these warnings and errors for the > template > modules are as expected (from pyang with the ietf option). [Med] Yes. No update is needed. 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? [Med] We can use IANA-maintained YANG module > > 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. [Med] We tried to not touch to how this was done in 8407. > > 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. [Med] I need to check the full text as there are cases where using XXXX does not work. For example, OLD: revision date-initial { description "Initial version"; version."; reference "RFC YYYY: <Replace With Document Title>"; CURRENT: revision date-initial { description "Initial version"; version."; reference "RFC XXXX: <Replace With Document Title>"; XXXX is referring to the RFC that first defined the modules, while YYYY is the RFC that defines an update. IIII is used per the convention in the terminology section: RFC IIII is used to refer to an RFC that defines an initial version of an IANA-maintained module. BTW, OLD: "RFC YYYY: Common YANG Data Types"; CURRENT: "RFC 6991: Common YANG Data Types"; Please change that one to NEW: "RFC 9911: Common YANG Data Types"; > > 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. 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 [Med] Please follow the same convention as in RFC8407 for these. > > 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. [Med] ACK > > 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. [Med] Can you please indicate which one? I don't see these in my diff. > > 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 [Med] These are inherited from 8407. We can leave these as is. > > 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" [Med] Please use the same convention as in RFC8407 if possible. If not, I have a preference for the "word" variant. Thanks. > --> > > > 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> [Med] Yes, please. Same as for similar cases. > > 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://fra01.safelinks.protection.outlook.com/?url=https% > 3A%2F%2Fwww.ietf.org%2Fid- > info%2Fguidelines.html%26gt&data=05%7C02%7Cmohamed.boucadair%40ora > nge.com%7C8133dfb0769d48d78e3f08de4f4a464f%7C90c7a20af34b40bfbc48b > 9253b6f5d20%7C0%7C0%7C639035377739707916%7CUnknown%7CTWFpbGZsb3d8e > yJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjo > iTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=atrm4UUIXDis12D47%2Ft > xwjq426URdzM5I8P%2FIIwYs8w%3D&reserved=0;</tt> > Perhaps: <eref > target="https://fra01.safelinks.protection.outlook.com/?url=https% > 3A%2F%2Fwww.ietf.org%2Fid- > info%2Fguidelines.html&data=05%7C02%7Cmohamed.boucadair%40orange.c > om%7C8133dfb0769d48d78e3f08de4f4a464f%7C90c7a20af34b40bfbc48b9253b > 6f5d20%7C0%7C0%7C639035377739717937%7CUnknown%7CTWFpbGZsb3d8eyJFbX > B0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFp > bCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=mUT43eIjCWOf38xk9uDJZ%2B46 > IjFWQPPvXmEgx23ZxCA%3D&reserved=0" brackets="angle"/> [Med] ACK > > 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> > --> [Med] ACK > > > 30) <!-- [rfced] Please review the "Inclusive Language" portion of > the online > Style Guide > <https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 > Fwww.rfc- > editor.org%2Fstyleguide%2Fpart2%2F%23inclusive_language&data=05%7C > 02%7Cmohamed.boucadair%40orange.com%7C8133dfb0769d48d78e3f08de4f4a > 464f%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6390353777397279 > 90%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDA > wMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C > &sdata=%2B0Kr2OYKInebkEZeIohFINtSz8XaMAEGTZXOmrItWjs%3D&reserved=0 > > > 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. [Med] ACK. > --> > > > 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 > Fwww.rfc- > editor.org%2Ffaq%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com% > 7C8133dfb0769d48d78e3f08de4f4a464f%7C90c7a20af34b40bfbc48b9253b6f5 > d20%7C0%7C0%7C639035377739738235%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0e > U1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCI > sIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=HRgT8uwEIqdSjvpYfqZ5jvVU4nub1 > XyEGDjDL3KYLgA%3D&reserved=0). > > 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > trustee.ietf.org%2Flicense- > info&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C8133dfb0769d4 > 8d78e3f08de4f4a464f%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6 > 39035377739747609%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUs > IlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D% > 3D%7C0%7C%7C%7C&sdata=SOi1mjpRpl7ZMXrTfHhRBOQkfEkInyvTPQnFArXC0QI% > 3D&reserved=0). > > * 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 > Fauthors.ietf.org%2Frfcxml- > vocabulary&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C8133dfb > 0769d48d78e3f08de4f4a464f%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7 > C0%7C639035377739756891%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn > RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoy > fQ%3D%3D%7C0%7C%7C%7C&sdata=dh%2B0%2BO1wXTXM0lgXgq1T1E2dbNj6zFJUVZ > ptZf5xg%2Bs%3D&reserved=0>. > > * 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > mailarchive.ietf.org%2Farch%2Fmsg%2Fietf-announce%2Fyb6lpIGh- > 4Q9l2USxIAe6P8O4Zc&data=05%7C02%7Cmohamed.boucadair%40orange.com%7 > C8133dfb0769d48d78e3f08de4f4a464f%7C90c7a20af34b40bfbc48b9253b6f5d > 20%7C0%7C0%7C639035377739765844%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU > 1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIs > IldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=OX7hOJlXxW%2FTrlQ6roHKxJ00IDzp > PLiylJ3F44moqo8%3D&reserved=0 > > * The archive itself: > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > mailarchive.ietf.org%2Farch%2Fbrowse%2Fauth48archive%2F&data=05%7C > 02%7Cmohamed.boucadair%40orange.com%7C8133dfb0769d48d78e3f08de4f4a > 464f%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6390353777397751 > 42%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDA > wMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C > &sdata=DZ3nsVNvptF8Ctmc98FNWUT7JcPHmBUbWTF%2BCBdLFXA%3D&reserved=0 > > * 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www.rfc- > editor.org%2Fauthors%2Frfc9907.xml&data=05%7C02%7Cmohamed.boucadai > r%40orange.com%7C8133dfb0769d48d78e3f08de4f4a464f%7C90c7a20af34b40 > bfbc48b9253b6f5d20%7C0%7C0%7C639035377739785549%7CUnknown%7CTWFpbG > Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs > IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=mPxzBnu%2FjT7Y > iyZwYQnreHFaDXNkleqBb%2FhHwdnvzH4%3D&reserved=0 > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www.rfc- > editor.org%2Fauthors%2Frfc9907.html&data=05%7C02%7Cmohamed.boucada > ir%40orange.com%7C8133dfb0769d48d78e3f08de4f4a464f%7C90c7a20af34b4 > 0bfbc48b9253b6f5d20%7C0%7C0%7C639035377739795708%7CUnknown%7CTWFpb > GZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiI > sIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Gyf%2FDYyfzU1 > Ph5F69Imc2CKHZ2DdcsB6oS9s3Fz7gZM%3D&reserved=0 > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www.rfc- > editor.org%2Fauthors%2Frfc9907.pdf&data=05%7C02%7Cmohamed.boucadai > r%40orange.com%7C8133dfb0769d48d78e3f08de4f4a464f%7C90c7a20af34b40 > bfbc48b9253b6f5d20%7C0%7C0%7C639035377739811064%7CUnknown%7CTWFpbG > Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs > IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=a2jZ%2B8rpz85P > l53wSX4BzqnmlFw2u0tneFzgEZ%2BMrvQ%3D&reserved=0 > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www.rfc- > editor.org%2Fauthors%2Frfc9907.txt&data=05%7C02%7Cmohamed.boucadai > r%40orange.com%7C8133dfb0769d48d78e3f08de4f4a464f%7C90c7a20af34b40 > bfbc48b9253b6f5d20%7C0%7C0%7C639035377739827710%7CUnknown%7CTWFpbG > Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs > IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=qxIe9zyw0f90%2 > F1d8MXcLnZeibd%2FG1q9sEa%2B5Z%2F%2BfpOg%3D&reserved=0 > > Diff file of the text: > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www.rfc-editor.org%2Fauthors%2Frfc9907- > diff.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C8133dfb0 > 769d48d78e3f08de4f4a464f%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C > 0%7C639035377739840661%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnR > ydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyf > Q%3D%3D%7C0%7C%7C%7C&sdata=%2BVLnwmA0wnyxg8Rgg1nif8GmUEPLignBluxrI > budPac%3D&reserved=0 > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www.rfc-editor.org%2Fauthors%2Frfc9907- > rfcdiff.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C8133d > fb0769d48d78e3f08de4f4a464f%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0 > %7C0%7C639035377739850907%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGki > OnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIj > oyfQ%3D%3D%7C0%7C%7C%7C&sdata=hew6s73ZVGa%2FPBW%2BLeJY9cKOkLZgFRS0 > a%2BHWqYRUdgc%3D&reserved=0 (side by side) > > Diff of the XML: > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www.rfc-editor.org%2Fauthors%2Frfc9907- > xmldiff1.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C8133 > dfb0769d48d78e3f08de4f4a464f%7C90c7a20af34b40bfbc48b9253b6f5d20%7C > 0%7C0%7C639035377739860251%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGk > iOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUI > joyfQ%3D%3D%7C0%7C%7C%7C&sdata=ZZKzAZEEOBeWSu3WCE4KGLcoC4kca4YcLq8 > qanpF33w%3D&reserved=0 > > > Tracking progress > ----------------- > > The details of the AUTH48 status of your document are here: > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www.rfc- > editor.org%2Fauth48%2Frfc9907&data=05%7C02%7Cmohamed.boucadair%40o > range.com%7C8133dfb0769d48d78e3f08de4f4a464f%7C90c7a20af34b40bfbc4 > 8b9253b6f5d20%7C0%7C0%7C639035377739869872%7CUnknown%7CTWFpbGZsb3d > 8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOI > joiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=GZgrzdRzETcs3u5lKp1 > PttjpMoaVpo5zXj1A4BhqDmY%3D&reserved=0 > > 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 ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
