Kent, 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 10009) 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 [RFC10009]. --> 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 10010 (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 [RFC10009] (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 [RFC10009]. --> 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 [RFC10009]. --> 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 13, 2026, at 11:01 AM, [email protected] wrote: *****IMPORTANT***** RFC Author(s): -------------- Final Review for RFC-to-be 10011 <draft-ietf-netconf-restconf-client-server> Your document is now available for Final Review (previously 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; see the Unavailable Authors section (https://authors.ietf.org/rfc-publication-process#unavailable-authors). 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 an archival mailing list to preserve discussion about the document while in the RPC editorial queue; 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/rfc10011.xml https://www.rfc-editor.org/authors/rfc10011.html https://www.rfc-editor.org/authors/rfc10011.pdf https://www.rfc-editor.org/authors/rfc10011.txt Diff file of the text: https://www.rfc-editor.org/authors/rfc10011-diff.html https://www.rfc-editor.org/authors/rfc10011-rfcdiff.html (side by side) Diff of the XML: https://www.rfc-editor.org/authors/rfc10011-xmldiff1.html Tracking progress ----------------- Details on the status of your Final Review are here: https://queue.rfc-editor.org/final-review/rfc10011/ Please let us know if you have any questions. Thank you for your cooperation, RFC Editor -------------------------------------- RFC 10011 (draft-ietf-netconf-restconf-client-server) Title : A YANG Data Model for RESTCONF Clients and Servers Author(s) : K. Watsen WG 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]
