Hi Qiufang, We have updated the files per your request.
The files have been posted here (please refresh): https://www.rfc-editor.org/authors/rfc10016.xml https://www.rfc-editor.org/authors/rfc10016.txt https://www.rfc-editor.org/authors/rfc10016.html https://www.rfc-editor.org/authors/rfc10016.pdf The relevant diff files have been posted here: https://www.rfc-editor.org/authors/rfc10016-diff.html (comprehensive diff) https://www.rfc-editor.org/authors/rfc10016-auth48diff.html (Final Review changes) https://www.rfc-editor.org/authors/rfc10016-auth48rfcdiff.html (Final Review changes side by side) https://www.rfc-editor.org/authors/rfc10016-lastdiff.html (last version to this one) https://www.rfc-editor.org/authors/rfc10016-lastrfcdiff.html (rfcdiff between last version and this) Please see the Final Review status page for this document here: https://queue.rfc-editor.org/final-review/rfc10016/ Thank you, Alanna Paloma RFC Production Center > On Jul 9, 2026, at 8:20 PM, maqiufang (A) <[email protected]> wrote: > > Hi, Alanna, > > Thanks a lot for the update. I do have some further comments: > > 1. Sec.2.1 Would this be better? > OLD: Always present refers to system configuration that is generated in > <system> when the device is powered on... > NEW: It refers to system configuration that is generated in <system> when the > device is powered on... > Or: > NEW: The always-present system configuration is generated in <system> when > the device is powered on... > > 2. Sec.2.2 Similarly > OLD: Conditionally present refers to system configuration that is generated > in <system> based on specific conditions being met in a system. > NEW: It refers to system configuration that is generated in <system> based on > specific conditions being met in a system. > Or: > NEW: The conditionally-present system configuration is generated in <system> > based on specific conditions being met in a system. > > 3. Appendix A.1 > OLD: these applications are an immediately present system configuration. > NEW: these applications are immediately present system configuration. > > 4. Appendix B.1, the first paragraph is awkward, how about: > OLD: > When the device is powered on, suppose the system provides an always-present > loopback interface (named "lo0") that is not explicitly configured in > <running>. Thus, no configuration for interfaces appears in <running> and the > content of <system> is: > NEW: > When the device is powered on, assume the system provides an always-present > lookback interface named "lo0" that is not explicitly configured in > <running>. As a result, no interface configuration appears in <running>, and > the content of <system> is as follows: > > 5. Appendix B.3, to be consistent: > OLD: The contents of <running> remain unchanged: > NEW: The content of <running> remains unchanged: > > 6. Appendix B.4 > OLD: And the content of <intended>, which represents a merged results of > <running> and <system>, is as follows: > NEW: And the content of <intended>, which represents the merged result of > <running> and <system>, is as follows: > > > 7. Appendix B.4 > In the last XML snippet, the enabled leaf inside lo0 list entry should be > tagged as origin=default, sorry for not recognizing this issue earlier: > OLD: > <interfaces xmlns="urn:example:interfacemgmt" > xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin" > or:origin="or:intended"> > <interface or:origin="or:system"> > <name>lo0</name> > <type>loopback</type> > <enabled>true</enabled> > <ip-address>127.0.0.1</ip-address> > <ip-address>::1</ip-address> > <description>system-defined interface</description> > </interface> > <interface> > <name>et-0/0/0</name> > <type or:origin="or:system">ethernet</type> > <enabled or:origin="or:default">true</enabled> > <ip-address>192.168.10.10</ip-address> > <speed>10Mb</speed> > <description>pre-provisioned interface</description> > </interface> > </interfaces> > NEW: > <interfaces xmlns="urn:example:interfacemgmt" > xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin" > or:origin="or:intended"> > <interface or:origin="or:system"> > <name>lo0</name> > <type>loopback</type> > <enabled or:origin="or:default">true</enabled> > <ip-address>127.0.0.1</ip-address> > <ip-address>::1</ip-address> > <description>system-defined interface</description> > </interface> > <interface> > <name>et-0/0/0</name> > <type or:origin="or:system">ethernet</type> > <enabled or:origin="or:default">true</enabled> > <ip-address>192.168.10.10</ip-address> > <speed>10Mb</speed> > <description>pre-provisioned interface</description> > </interface> > </interfaces> > > Best regards, > Qiufang > > -----Original Message----- > From: Alanna Paloma [mailto:[email protected]] > Sent: Thursday, July 9, 2026 1:41 AM > To: maqiufang (A) <[email protected]> > Cc: [email protected]; Qin Wu <[email protected]>; > [email protected]; [email protected]; > [email protected]; [email protected]; [email protected]; > [email protected]; [email protected] > Subject: Re: [AD] Final Review: RFC-to-be 10016 > (draft-ietf-netmod-system-config) in XML > > Hi Qiufang, > > Thank you for your reply. We have updated as requested. > > The files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc10016.xml > https://www.rfc-editor.org/authors/rfc10016.txt > https://www.rfc-editor.org/authors/rfc10016.html > https://www.rfc-editor.org/authors/rfc10016.pdf > > The relevant diff files have been posted here: > https://www.rfc-editor.org/authors/rfc10016-diff.html (comprehensive diff) > https://www.rfc-editor.org/authors/rfc10016-auth48diff.html (Final Review > changes) https://www.rfc-editor.org/authors/rfc10016-auth48rfcdiff.html > (Final Review changes side by side) > > Please review the document carefully and contact us with any further updates > you may have. Note that we do not make changes once a document is published > as an RFC. > >> 5) <!--[rfced] *[AD] We have altered some text in the Security >> Considerations section to match the boilerplate text at >> <https://wiki.ietf.org/group/ops/yang-security-guidelines>. Also note that >> paragraph 4 varies from the template (we attempted to make it match more >> closely). Please review and let us know if any further updates are needed or >> if the text is agreeable as is. >> --> >> [Qiufang] Mahesh will comment this , but why not replace [YANG-GUIDE] with >> [RFC9907]? > > ) Note that we are awaiting Mahesh’s word on this. The citation has been > updated from "[YANG-GUIDE]" to "[RFC9907]". > > For the Final Review status of this document, please see: > https://queue.rfc-editor.org/final-review/rfc10016/ > > Thank you, > Alanna Paloma > RFC Production Center > >> On Jul 7, 2026, at 11:39 PM, maqiufang (A) >> <[email protected]> wrote: >> >> Hi, >> >> Please see below inline with [Qiufang]... >> >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] >> Sent: Tuesday, July 7, 2026 7:35 AM >> To: maqiufang (A) <[email protected]>; Qin Wu >> <[email protected]>; [email protected]; [email protected] >> Cc: [email protected]; [email protected]; >> [email protected]; [email protected]; >> [email protected]; [email protected] >> Subject: [AD] Re: Final Review: RFC-to-be 10016 >> (draft-ietf-netmod-system-config) in XML >> >> Authors and *AD, >> >> While reviewing this document during Final Review, please resolve (as >> necessary) the following questions, which are also in the source file. >> >> *AD, please review question #5 below. >> >> >> 1) <!--[rfced] We note that most of the recently published RFCs containing >> YANG modules format their titles as "A YANG Data Model for...", for example: >> >> RFC 9094 - A YANG Data Model for Wavelength Switched Optical Networks >> (WSONs) RFC 9093 - A YANG Data Model for Layer 0 Types RFC 9067 - A >> YANG Data Model for Routing Policy >> >> Please consider whether the title of this document should be updated. >> >> Current: >> System-Defined Configuration >> >> Perhaps: >> A YANG Data Model for System-Defined Configuration >> --> >> [Qiufang] The Current is better. This draft defines more than a YANG data >> model. >> >> 2) <!--[rfced] Per guidance from Section 2 of RFC 8340, we moved the lines >> in the YANG tree diagram (in Section 7.1) over two spaces to the left. >> Please review and let us know of any objections. >> --> >> [Qiufang] Okay. No objections. >> >> >> 3) <!--[rfced] Because XML examples are present in this document, we added a >> citation to W3C in Section 7.3 and a corresponding entry under the >> Informative References section. Please let us know if this is agreeable or >> if you prefer otherwise. >> >> Original: >> The following example shows how the configuration in <system> could >> be retrieved in a NETCONF <get-data> RPC operation. The example uses >> the "example-application" fictional data model defined in >> Appendix A.1. >> >> Current: >> The following example shows how the configuration in <system> could >> be retrieved in a NETCONF <get-data> RPC operation. The example >> uses XML [W3C.XML1.0] and the "example-application" fictional data >> model defined in Appendix A.1. >> --> >> >> [Qiufang] Perhaps: >> OLD: >> The following example shows how the configuration in <system> could >> be retrieved in a NETCONF <get-data> RPC operation. The example >> uses XML [W3C.XML1.0] and the "example-application" fictional data >> model defined in Appendix A.1. >> NEW: >> The following example shows how the configuration in <system> could >> be retrieved in a NETCONF <get-data> RPC operation. The example >> uses the "example-application" fictional data >> model defined in Appendix A.1 and the Extensible Markup Language (XML) >> [W3C.XML1.0] encoding. >> >> >> 4) <!--[rfced] FYI - In Section 7.3, note that we moved the example over >> three spaces to the left because >> "xmlns:sysds="urn:ietf:params:xml:ns:yang:ietf-system-datastore">" >> was 3 characters over the limit. >> --> >> [Qiufang] Okay. >> >> >> 5) <!--[rfced] *[AD] We have altered some text in the Security >> Considerations section to match the boilerplate text at >> <https://wiki.ietf.org/group/ops/yang-security-guidelines>. Also note that >> paragraph 4 varies from the template (we attempted to make it match more >> closely). Please review and let us know if any further updates are needed or >> if the text is agreeable as is. >> --> >> [Qiufang] Mahesh will comment this , but why not replace [YANG-GUIDE] with >> [RFC9907]? >> >> >> 6) <!--[rfced] Note that the YANG module examples have been updated per the >> formatting option of pyang. Please let us know any concerns. >> >> a) example-application has been updated as follows: >> >> prefix "ex-app" -> prefix ex-app >> prefix "inet" -> prefix inet >> >> b) example-acl has been updated as follows: >> >> prefix "ex-acl" -> prefix ex-acl >> prefix "ex-app" -> prefix ex-app >> prefix "inet" -> prefix inet >> >> c) example-interface has been updated as follows: >> >> prefix "ex-if" -> prefix ex-if >> prefix "inet" -> prefix inet >> key name -> key "name" >> >> d) example-interface-management has been updated as follows: >> >> prefix "ex-ifm" -> prefix ex-ifm >> prefix "inet" -> prefix inet >> --> >> >> [Qiufang] All above are good. >> >> 7) <!--[rfced] We note that the following system configuration terms are >> hyphenated. Are these specific terms that should always appear hyphenated? >> We are confirming because adverbs ending in "ly" are not typically >> hyphenated in the RFC Series, and we could not find the hyphenated forms of >> these terms in past RFCs. >> >> If the hyphens are not essential, we would remove them from >> "immediately-present" and "conditionally-present", and we would hyphenate >> "always present" only when in attributive position (i.e., when followed by a >> noun). Please let us know your preference. >> >> always-present >> conditionally-present >> immediately-present >> --> >> [Qiufang] Okay to remove the hyphen. >> >> >> 8) <!-- [rfced] FYI - We have added expansions for the following >> abbreviations per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review >> each expansion in the document carefully to ensure correctness. >> >> Access Control List (ACL) >> Network Configuration Protocol (NETCONF) >> --> >> [Qiufang] Looks good to me. >> >> >> 9) <!-- [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. >> --> >> [Qiufang] I do not think any changes are needed. Thanks. >> >> I do have one additional comment, in the Acknowledgements section, could you >> please update the following names: >> OLD: Balazs Lengyel >> NEW: Balázs Lengyel >> >> OLD: Martin Bjorklund >> NEW: Martin Björklund >> >> OLD: Juergen Schoenwaelder >> NEW: Jürgen Schönwälder >> >> Best Regards, >> Qiufang >> >> Thank you. >> >> Alanna Paloma and Karen Moore >> RFC Production Center >> >> >> On Jul 6, 2026, at 4:24 PM, [email protected] wrote: >> >> *****IMPORTANT***** >> >> RFC Author(s): >> -------------- >> >> Final Review for RFC-to-be 10016 <draft-ietf-netmod-system-config> >> >> 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-4Q9l2USxI >> Ae6P8O4Zc >> >> * 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/rfc10016.xml >> https://www.rfc-editor.org/authors/rfc10016.html >> https://www.rfc-editor.org/authors/rfc10016.pdf >> https://www.rfc-editor.org/authors/rfc10016.txt >> >> Diff file of the text: >> https://www.rfc-editor.org/authors/rfc10016-diff.html >> https://www.rfc-editor.org/authors/rfc10016-rfcdiff.html (side by >> side) >> >> Diff of the XML: >> https://www.rfc-editor.org/authors/rfc10016-xmldiff1.html >> >> >> Tracking progress >> ----------------- >> >> Details on the status of your Final Review are here: >> https://queue.rfc-editor.org/final-review/rfc10016/ >> >> Please let us know if you have any questions. >> >> Thank you for your cooperation, >> >> RFC Editor >> >> -------------------------------------- >> RFC 10016 (draft-ietf-netmod-system-config) >> >> Title : System-defined Configuration >> Author(s) : Q. Ma, Ed., >> Q. Wu, >> C. Feng >> WG Chair(s) : Kent Watsen, Lou Berger >> Area Director(s) : Mohamed Boucadair, Mahesh Jethanandani > > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
