Hi Qiufang, Thank you for confirming. Your approval has been noted: https://queue.rfc-editor.org/final-review/rfc10016/
Best regards, Alanna Paloma RFC Production Center > On Jul 13, 2026, at 11:15 PM, maqiufang (A) <[email protected]> wrote: > > Hi, Alanna, > > Thanks for the clarification. I agree to keep the current text without > hyphens, no changes are needed for those lines. I do not have any other > revisions to propose, please mark my approval. Thanks. > > Best regards, > Qiufang > > -----Original Message----- > From: Alanna Paloma [mailto:[email protected]] > Sent: Monday, July 13, 2026 11:47 PM > 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, > > The hyphen was not included here because adverbs ending in "ly" are not > typically hyphenated in the RFC Series, even in the attributive position > (e.g., "conditionally present system configuration”, not > "conditionally-present system configuration”). > > However, if “conditionally present” and “immediately present” are specific > terms that should be hyphenated, we can add those hyphens back into the > document. Please let us know how you would like to proceed or if any further > updates are needed. > > Thank you, > Alanna Paloma > RFC Production Center > >> On Jul 10, 2026, at 8:41 PM, maqiufang (A) <[email protected]> wrote: >> >> Hi, Alanna, >> >> Thanks for the update. It looks good to me. One comment: >> In 2.2. Conditionally Present >> The conditionally present system configuration is generated in >> <system> based on specific conditions being met in a system. >> >> I think it should be: >> The conditionally-present system configuration is generated in >> <system> based on specific conditions being met in a system. >> >> Agreed? >> >> Best regards, >> Qiufang >> >> -----Original Message----- >> From: Alanna Paloma <[email protected]> >> Sent: Saturday, July 11, 2026 6:46 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, >> >> 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-4Q9l2USx >>>> I >>>> 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]
