Authors, While reviewing this document during Final Review, please resolve (as necessary) the following questions, which are also in the source file.
1) <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> 2) <!--[rfced] We note that draft-ietf-netconf-udp-client-server-10 (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. --> 3) <!--[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 NETCONF [RFC6241] and RESTCONF [RFC8040] protocols. --> 4) <!--[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). --> 5) <!--[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]. --> 6) <!--[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]. --> 7) <!--[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"). --> 8) <!-- [rfced] RFC 9643 was mentioned twice in this sentence. We think you mean to point to RFC 9645. Please review our update and let us know any objections. Original: This YANG module has normative references to [RFC6242], [RFC6991], [RFC7589], [RFC8071], [RFC9643], [RFC9644], and [RFC9643]. Current: This YANG module has normative references to [RFC6242], [RFC7589], [RFC8071], [RFC9643], [RFC9644], [RFC9645], and [RFC9911]. --> 9) <!--[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 10010 (draft-ietf-netconf-restconf-client-server-45): 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. must client-identity -> must 'client-identity' default 180 -> default "180" if-feature central-netconf-client-supported -> if-feature "central-netconf-client-supported" --> 10) <!--[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 update is listed below). Please let us know any concerns. if-feature central-netconf-server-supported -> if-feature "central-netconf-server-supported" --> 11) <!--[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. --> 12) <!-- [rfced] RFC 6991 has been obsoleted by RFC 9911. We have updated accordingly. Please let us know any objections. --> 13) <!--[rfced] RFC 8407 has been replaced by RFC 9907. We have updated accordingly. Please let us know any objections. --> 14) <!--[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. --> 15) <!--[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 (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. --> 16) <!-- [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. --> 17) <!-- [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:28 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-rfc10009 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-rfc10009/blob/Approved/README.md c) review the edits in the RPC-edits pull request: https://github.com/rfc-editor-drafts/FinalReview-rfc10009/pulls d) address the issues: https://github.com/rfc-editor-drafts/FinalReview-rfc10009/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/rfc10009/ Please let us know if you have any questions. Thank you for your cooperation, RFC Production Center Title : A YANG Data Model for NETCONF Clients and Servers Author(s) : K. Watsen Working Group Chair(s) : Kent Watsen, Per Andersson Area Director(s) : Mohamed Boucadair, Mahesh Jethanandani -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
