Hi Kent, As you noted for 10011, the questions for RFC-to-be 10010 have been included as GitHub issues. Please see the initial edits and issues at https://github.com/rfc-editor-drafts/FinalReview-rfc10010.
Thanks, Sandy Ginoza RFC Production Center > On Jul 13, 2026, at 11:14 AM, [email protected] wrote: > > 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]
