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]
