Authors, While reviewing this document during Final Review, please resolve (as necessary) the following questions, which are also in GitHub issues (see https://github.com/rfc-editor-drafts/FinalReview-rfc/issues).
1) <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> 2) <!--[rfced] Should a citation be added after RESTCONF in the following text (there is a citation to RFC 6241 in the companion/twin document about NETCONF. Original: ... one module to configure a RESTCONF client and the other module to... --> 3) <!--[rfced] We note that RFC 9984 and draft-ietf-netconf-http-client-server-33 (RFC-to-be 10011) use "YANG 1.1 [RFC7950]" while this document does not mention 1.1. Please review and let us know if/how we may update for consistency. --> 4) <!--[rfced] For clarity, may we update this sentence to indicate that the modules, not the RFCs, support the configuration of the clients and servers for both protocols? Original: This document presents one or more YANG modules [RFC7950] that are part of a collection of RFCs that work together to, ultimately, support the configuration of both the clients and servers of both the NETCONF [RFC6241] and RESTCONF [RFC8040] protocols. Perhaps: This document presents two YANG modules [RFC7950] that belong to a collection of RFCs that are designed to work together. Ultimately, these modules support the configuration of clients and servers for both the Network Configuration Protocol (NETCONF) [RFC6241] and RESTCONF protocol [RFC8040]. --> 5) <!--[rfced] We have the following questions related to the diagram in Section 1.1: a) The XML file contained the following comment from the authors: Original: RFC Editor: is there anyway to flush-left the table in PDF/HTML views? We have set the figure to align="left". Does this resolve your concern? b) We happened to spot the following in RFC 9643: import ietf-crypto-types { prefix ct; reference "RFC 9640: YANG Data Types and Groupings for Cryptography"; Please confirm that no relationship between tcp-client-server and crypto-types should be illustrated in the diagram (that it is a "secondary grouping" not meant to be illustrated here). --> 6) <!--[rfced] May we create a "Conventions" section (similar to that in RFC 9641) after Section 1.2 ("Specification Language") so we may include citations for the XML and line wrapping used in this document? Note that we would place the corresponding W3C reference entry for the XML under the Informative References section as the XML schemas show example usage. Perhaps: 1.3 Conventions Various examples in this document use XML [W3C.REC-xml-20081126] encoding. Various examples in this document contain long lines that may be folded, as described in [RFC8792]. --> 7) <!--[rfced] Should the following text be marked using the <aside> element? There are author comments before and after with the <aside> commented out. Note that this occurs at least one other time as well. Original: The diagram above uses syntax that is similar to but not defined in [RFC8340]. --> 8) <!--[rfced] Please clarify "augmented in". Is the intended meaning perhaps that other options MAY be augmented into the module or grouping or MAY be added by future specifications? Note that there are two instances in the text. Original: This document only defines an "https" option, but other options MAY be augmented in. Perhaps: This document only defines an "https" option, but other options MAY be added by future specifications. --> 9) <!--[rfced] FYI: We updated this section reference to point to the correct section in [RFC10011] (I-D.ietf-netconf-http-client-server). Original: - The "http-server-grouping" grouping is discussed in Section 3.1.2.1 of [I-D.ietf-netconf-http-client-server]. Current: - The "http-server-grouping" grouping is discussed in Section 4.1.2.1 of [RFC10011]. --> 10) <!--[rfced] Per the following note, we removed '?' from 6 instances of "name?" within the YANG tree diagrams. Please review and let us know if any further changes are needed. Author note: Due to a bug in the pyang tool used to create tree diagrams, some "key" nodes appear as optional (i.e., have a '?' postfix). Ideally the '?' character is removed in the tree diagrams for "key" nodes. Recipe: search for lists using the string "* [", then note the nodes appearing in the square brackets (e.g., "* [name]"), then look for matching child nodes and remove the '?' characters (e.g., "name?" becomes "name"). --> 11) <!--[rfced] We have the following questions related to the YANG module in Section 2.3 vs. Section 2.3 of companion document RFC-to-be 10009 (draft-ietf-netconf-netconf-client-server-41): a) There is some variation in the following similar descriptions. Please let us know if/how they should be made uniform: Netconf: grouping netconf-client-listen-stack-grouping { description "A grouping for configuring a NETCONF client 'listen' protocol stack for listening on a single port. The 'listen' stack supports call home connections, as described in RFC 8071."; Restconf: grouping restconf-client-listen-stack-grouping { description "A grouping for configuring a RESTCONF client to listen to a port for call home connections, as described in RFC 8071."; b) Minor differences here between "the" and "this" and "the" and "a": Netconf: "A user-ordered list of endpoints that the NETCONF client will attempt to connect to in the specified sequence. Defining more than one enables high availability."; "An arbitrary name for the endpoint."; "Container for the list of endpoints."; Restconf: "A non-empty user-ordered list of endpoints for this RESTCONF client to try to connect to in sequence. Defining more than one enables high availability."; "An arbitrary name for this endpoint."; "Container for a list of endpoints."; c) Variation on the use of "gracefully": Netconf: The NETCONF client SHOULD close the underlying TCP connection upon completing planned activities. Restconf: The RESTCONF client SHOULD gracefully close the underlying TLS connection upon completing planned activities. d) Please confirm the use of TCP here: we would have expected RESTCONF: Netconf: A NETCONF session will be dropped if it is idle for an interval longer than this number of seconds. Restconf: A TCP session will be dropped if it is idle for an interval longer then this number of seconds. e) Note that the YANG module has been updated per the formatting option of pyang (the specific updates are listed below). Please let us know any concerns. if-feature listen -> if-feature "listen" refine 'uri/path' -> refine "uri/path" refine 'uri/query' -> refine "uri/query" refine 'uri/fragment' -> refine "uri/fragment" refine 'uri/authority/port' -> refine "uri/authority/port" if-feature central-restconf-client-supported -> if-feature "central-restconf-client-supported" --> 12) <!-- [rfced] FYI: We updated this section reference to point to the correct section in [RFC10011] (I-D.ietf-netconf-http-client-server). Original: - The "http-server-grouping" grouping is discussed in Section 3.1.2.1 of [I-D.ietf-netconf-http-client-server]. Current: - The "http-server-grouping" grouping is discussed in Section 4.1.2.1 of [RFC10011]. --> 13) <!-- [rfced] RFC 9984 (draft-ietf-netconf-udp-client-server) was not included in the references section and isn't mentioned in the introductory sentence to this YANG module (in Section 3.3). a) Should this be a Normative or Informative reference? We've currently added it as normative. Please review. b) Should mention of this document be added to the text below? Current: This YANG module has normative references to [RFC9911], [RFC7407], [RFC8040], [RFC8071], [RFC9643], [RFC9645], and [PRE-RFC10011]. --> 14) <!--[rfced] We have the following questions related to the YANG module in Section 3.3: a) We note a slight difference between the text in the NETCONF vs. RESTCONF docs with regard to a citation in this text. Please let us know if/how a citation should be added to the RESTCONF document. NETCONF: "Specifies mappings through which NETCONF client X.509 certificates are used to determine a NETCONF username, per RFC 7407. RESTCONF: "Specifies mappings through which RESTCONF client X.509 certificates are used to determine a RESTCONF username. b) A similar variation exists in the following: NETCONF: For TLS-based transports, if no matching and valid cert-to-name list entry can be found, then the NETCONF server MUST close the connection and MUST NOT accept NETCONF messages over it, per Section 7 in RFC 7589. RESTCONF: If no matching and valid cert-to-name list entry can be found, then the RESTCONF server MUST close the connection and MUST NOT accept RESTCONF messages over it."; c) Note that the YANG module has been updated per the formatting option of pyang (the specific updates are listed below). Please let us know any concerns. if-feature listen -> if-feature "listen" if-feature callhome -> if-feature "callhome" default 1 -> default "1" if-feature tls-callhome -> if-feature "tls-callhome" if-feature central-restconf-server-supported -> if-feature "central-restconf-server-supported" --> 15) <!--[rfced] We have the following questions/comments related to the Security Considerations section: a) [AD] Please review the mismatch between the text in the Security Considerations subsections with regard to readable, writable, and RPC nodes: we see that this text does not use either alternative listed at https://wiki.ietf.org/group/ops/yang-security-guidelines to describe those nodes. b) FYI - we have made a number of changes to more closely align the Security Considerations section with the text appearing at https://wiki.ietf.org/group/ops/yang-security-guidelines. Please review carefully and let us know any objections. c) FYI - we have moved the reference to RFC 8341 to the Normative References section per the guidance at https://wiki.ietf.org/group/ops/yang-security-guidelines. Please let us know any objections. d) We have attempted to add in the specific references for Security Considerations sections for the YANG module groupings. Please review to ensure accuracy. --> 16) <!-- [rfced] RFC 6991 has been obsoleted by RFC 9911. We have updated accordingly. Please let us know any objections. --> 17) <!--[rfced] RFC 8407 has been replaced by RFC 9907. We have updated accordingly. Please let us know any objections. --> 18) <!--[rfced] We updated <artwork> to <sourcecode> in several sections. Please review and confirm that this is correct. In addition, please consider whether the "type" attribute of each sourcecode element has been set correctly. The current list of preferred values for "type" is available at https://www.rfc-editor.org/materials/sourcecode-types.txt. If the current list does not contain an applicable type, feel free to suggest additions for consideration. Note that it is also acceptable to leave the "type" attribute not set. --> 19) <!--[rfced] We have the following questions related to terminology used throughout the document: a) We see the following similar forms. Please let us know how we may update for uniformity. Call Home connection vs. call-home connection vs. call home connection vs. call-home TCP connections (Note also that we see it in single quotes for the protocol stack: 'call-home' protocol stack) b) We have removed the additional references to RFC 8071 in the body of the document after first mention with Call Home connections. Please let us know any objections. --> 20) <!-- [rfced] Some author comments are present in the XML. Please review and let us know if any further action is necessary to resolve these issues or if they may simply be deleted prior to publication. --> 21) <!-- [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 Karen Moore RFC Production Center On Jul 1, 2026, at 4:41 PM, [email protected] wrote: *****IMPORTANT***** RFC Author(s): -------------- Your document has now entered Final Review (formerly AUTH48). Final Review is being handled in GitHub as part of the GitHub pilot test (see https://www.rfc-editor.org/rpc/wiki/doku.php?id=rpc-github-phase-0-pilot-test). Your document is available for review at: https://github.com/rfc-editor-drafts/FinalReview-rfc10010 Please do the following: a) accept your invitations to join the repo as collaborators. b) see the README for details on the Final Review process: https://github.com/rfc-editor-drafts/FinalReview-rfc10010/blob/Approved/README.md c) review the edits in the RPC-edits pull request: https://github.com/rfc-editor-drafts/FinalReview-rfc10010/pulls d) address the issues: https://github.com/rfc-editor-drafts/FinalReview-rfc10010/issues Once the content is stable in GitHub, we will provide the updated XML file and the output files for review and approval. You and your coauthors are responsible for engaging other parties (e.g., Contributors or Working Group) as necessary before providing your approval. Once the document has been reviewed and approved by all of the authors, it will be published as an RFC. If an author is no longer available, there are several remedies; see the Unavailable Authors section (https://authors.ietf.org/rfc-publication-process#unavailable-authors). Details on the status of your Final Review are here: https://queue.rfc-editor.org/final-review/rfc10010/ Please let us know if you have any questions. Thank you for your cooperation, RFC Production Center -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
