Hi Qiufang, The changes look good to me. I have some few edits that I will send you as a PR for your convenience.
Kent raised a good point about lack of awareness of RFC 8080. You may consider this change: OLD: As a result, Figure 2 in Section 5 of [RFC8342] is updated with the below conceptual model of datastores which incorporates the system configuration datastore. NEW: As a result, Figure 2 in Section 5 of [RFC8342] is updated with the below conceptual model of datastores which incorporates the system configuration datastore. For completeness, this model also include the <factory-default> datastore introduced in [RFC8808]. Thank you. Cheers, Med > -----Message d'origine----- > De : maqiufang (A) <[email protected]> > Envoyé : mercredi 21 janvier 2026 09:09 > À : BOUCADAIR Mohamed INNOV/NET <[email protected]>; > [email protected] > Cc : [email protected]; Kent Watsen > <[email protected]>; [email protected]; NETMOD WG > <[email protected]> > Objet : RE: Mohamed Boucadair's Discuss on draft-ietf-netmod- > system-config-18: (with DISCUSS and COMMENT) > > > Hi, Med, > > Thanks for the follow-up. We try to address your comments below in > the proposed update, please review it at : > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > author- > tools.ietf.org%2Fdiff%3Furl_1%3Dhttps%3A%2F%2Fraw.githubuserconten > t.com%2FQiufangMa%2Fsystem-config%2Frefs%2Fheads%2Fmain%2Fdraft- > ietf-netmod-system-config- > 19.txt&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cd6b9dfa4fd1 > d4a4dcea108de58c451ec%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7 > C639045797369726809%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydW > UsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3 > D%3D%7C0%7C%7C%7C&sdata=eapW3bczXpX4pls3xg5e4REIFT5Qi14lE4UyvAkzhX > 0%3D&reserved=0. > Let me know if you have further comments/suggestions. Thanks a > lot. > > Best Regards, > Qiufang > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] > Sent: Tuesday, January 20, 2026 7:02 PM > To: maqiufang (A) <[email protected]>; > [email protected] > Cc: [email protected]; Kent Watsen > <[email protected]>; [email protected]; NETMOD WG > <[email protected]> > Subject: RE: Mohamed Boucadair's Discuss on draft-ietf-netmod- > system-config-18: (with DISCUSS and COMMENT) > > Hi Qiufang, all, > > Thanks for the follow-up. I also saw Rob's message. > > Please see inline. > > Cheers, > Med > > > -----Message d'origine----- > > De : maqiufang (A) <[email protected]> > > Envoyé : mardi 20 janvier 2026 05:01 > > À : BOUCADAIR Mohamed INNOV/NET <[email protected]>; > > [email protected] Cc : [email protected]; > Kent > > Watsen <[email protected]>; [email protected]; NETMOD WG > > <[email protected]> Objet : RE: Mohamed Boucadair's Discuss on > > draft-ietf-netmod- > > system-config-18: (with DISCUSS and COMMENT) > > > > > > Hi, Med, > > > > Thanks a lot for the review. While the authors are preparing a > new > > version to address your comments below, please find some of my > > response below inline with [Qiufang]... > > > > -----Original Message----- > > From: Mohamed Boucadair via Datatracker > [mailto:[email protected]] > > Sent: Monday, January 19, 2026 6:11 PM > > To: The IESG <[email protected]> > > Cc: [email protected]; > > [email protected]; [email protected]; [email protected] > > Subject: Mohamed Boucadair's Discuss on draft-ietf-netmod- > system- > > config-18: (with DISCUSS and COMMENT) > > > > ---------------------------------------------------------------- > -- > > DISCUSS: > > ---------------------------------------------------------------- > -- > > > > Hi Qiufang, Qin, and Chong, > > > > Thank you for the effort put into this specification. > > > > Also, thanks to Luis Contreras Murillo for the OPSDIR review and > the > > authors for engaging and implementing changes in -18. I see Luis > has > > some follow-up few suggestions, though. > > [Qiufang] Yes, I do see the follow-up from Luis, sorry for the > delay. > > I am preparing a new version to incorporate the follow-up > suggestions, > > as well as your comments below. > > > > Please find below some few points for DISCUSSion: > > > > # Design approach > > > > RFC 8342 has the following: > > > > dynamic | +-------- learned configuration > > configuration | +-------- system configuration > > datastores -----+ | +-------- default configuration > > | | | > > v v v > > +---------------+ > > | <operational> | <-- system state > > | (ct + cf, ro) | > > +---------------+ > > > > A design approach that would not impact other datastores is to > expand > > the "system configuration" branch above and replace it with > <system>. > > That would be also consistent with the hierarchy of origin > identity > > defined in RFC 8342: > > > > The values are YANG identities. The following identities > > are defined: > > > > o origin: abstract base identity from which the other origin > > identities are derived. > > > > o intended: represents configuration provided by <intended>. > > > > ... > > > > o system: represents configuration provided by the system > itself. > > Examples of system configuration include applied > configuration > > for > > an always-existing loopback interface, or interface > > configuration > > that is auto-created due to the hardware currently present > in > > the > > device. > > > > ## Is there any reason why that approach is not followed > compared to > > grafting <system> to <intended> as in the current version of the > > draft? > > [Qiufang] Having system configuration only present in > <operational> > > does not really make sense , as the configuration provided by > the > > client needs to interact with system configuration (i.e., > > reference/override/configure descendant nodes of system > > configuration). > > [Med] This interaction is only about retrieval, while actual > configuration (including overriding) is done via other datastores. > > For example, there is some system configuration > > which is predefined for the convenience of clients, e.g., built- > in > > rules, policies. A client should be able to reference a system- > > defined policy without copying it into <running>, and to allow > > <system> feeds into <intended>, the merging result in <intended> > does > > pass the validation. > > The current architecture also allows the existence of system- > defined > > templates and inactive system configuration, which are similar > > concepts defined in NMDA, except that they are provided by the > server. > > [Med] These are good points that are worth echoed in the draft to > motivate why this design is preferred over the one that builds on > constructs already present in RFC 8342. > > > Hopefully this clarifies. > > [Med] It does. However, as the doc says that it does not modify > operational, I think that is not accurate. Please double check the > provisions through RFC 8342. Maybe, some of this inconsistency can > be fixed by declaring that any discussion about system in RFC 8342 > is overridden by draft-ietf-netmod-system-config. > > > > > > > ## Note that with the current design, there are parts of RFC > 8342 that > > needs "tweaking" > > > > An example is provided below (there are other similar > > occurrences): > > > > RFC 8342: > > The system will only provide configuration for this > > interface if there is no data for it in <intended>. > > > > When no configuration for "lo0" appears in <intended>, > > <operational> > > will show the system-provided data: > > > > <interfaces xmlns:or="urn:ietf:params:xml:ns:yang:ietf- > > origin" > > or:origin="or:intended"> > > <interface or:origin="or:system"> > > <name>lo0</name> > > <ip-address>127.0.0.1</ip-address> > > <ip-address>::1</ip-address> > > </interface> > > </interfaces> > > [Qiufang] This is a good point. I am not convinced that the > presence > > of system configuration should depend on the configuration in > > <running>. It is also unclear in C.3.2 of 8342, as the first > sentence > > says " Imagine that the system provides a loopback interface > (named > > "lo0") with a default IPv4 address of "127.0.0.1" and a default > IPv6 > > address of "::1". ", and then contradictorily followed by your > > sentence above. Would it be okay for appendix B in > > draft-ietf-netmod-system-config to update > > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > > datatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8342%23appendix- > > > C.3.2&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C7b507c37821c > > > 407c028f08de57d87c6f%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C > > > 639044784484586745%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWU > > > sIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D > > > %3D%7C0%7C%7C%7C&sdata=akiZ7LaYw62Ycl%2Fx3KHACnBe4ZnsUo%2F0GDp%2Fi > > p5B7fs%3D&reserved=0? > > [Med] It does. See also my proposal above. > > > > > > > # Origin metadata annotation is normative > > > > CURRENT: > > * Origin: This document does not define any new origin > identity. > > The "system" identity of origin metadata annotation > [RFC7952] is > > used to indicate the origin of a data item provided by the > > system. > > > > This is needed to tag system ds. > > [Qiufang] How about the following update: > > OLD: > > * Origin: This document does not define any new origin > identity. > > The "system" identity of origin metadata annotation > [RFC7952] is > > used to indicate the origin of a data item provided by the > > system. > > NEW: > > * Origin: This document does not define any new origin > identity. > > The "system" identity of origin metadata annotation > [RFC7952] is > > used to indicate the origin of a data item in <system>. > > > > [Med] Thanks. Please list RFC7952 as normative. > > > > > ---------------------------------------------------------------- > -- > > ---- > > COMMENT: > > ---------------------------------------------------------------- > -- > > ---- > > > > # Desire > > > > CURRENT: > > However, there is a desire to enable a server to better > expose the > > system configuration, regardless of whether it is in use. > > > > Desire of whom? > > [Qiufang] How about the following? > > OLD: > > However, there is a desire to enable a server to better > expose the > > system configuration, regardless of whether it is in use. > > NEW: > > However, there is a desire from operators to enable a server > to > > better expose the > > system configuration, regardless of whether it is in use. > > > > [Med] ACK > > > # Root > > > > CURRENT: > > * YANG nodes: all "config true" data nodes up to the root of > the > > tree, generated by the system. > > > > This seems to assume one single data tree. Is that intended? > > [Qiufang] Yes, note 8342 states something similar, e.g., > > <running>/<intended> MUST always be a valid configuration data > tree. > > [Med] this says "a". > > > > > If not, I think that it is accurate to use the following: > > > > NEW: > > * YANG nodes: all "config true" data nodes up to the root of > a > > data > > tree, generated by the system. > > > > # It is weird to reason about modification for read-only ds > [Qiufang] > > I think there should be distinction between system configuration > and > > <system>. > > [Med] Can you please better clarify that in the draft? > > Note that the draft already states: > > The system datastore is read-only (i.e., edits towards <system> > > directly MUST be denied), though the client may be allowed to > > provide > > configuration that overrides the value of a system- > initialized node > > (see Section 6.3). > > > > Best Regards, > > Qiufang > > > > OLD: > > 6.3. Modifying (Overriding) System Configuration > > > > NEW: > > 6.3. Overriding System Configuration > > > > # IANA template for registration > > > > OLD: > > This document registers one YANG module in the 'YANG Module > Names' > > registry, defined in [RFC6020]. > > > > NEW: > > IANA is requested to register the following YANG module in > the > > "YANG > > Module Names" registry [RFC6020] within the "YANG > Parameters" > > registry group. > > > > # Examples are not normative > > > > CURRENT: > > The updates of system > > configuration may be obtained through YANG notifications > (e.g., > > on- > > change notification) [RFC8639][RFC8641]. > > > > [RFC8639] and [RFC8641] are listed as normative, while these > should > > not. Please fix that. > > > > # Nits > > > > ## Split long sentences + proper RFC citation > > > > CURRENT: > > This document updates RFC 8342 to define a configuration > datastore > > called "system" to hold system configuration (Section 3), it > also > > redefines the term "conventional configuration datastore" > from > > [RFC8342] to add "system" to the list of conventional > configuration > > datastores. > > > > or > > > > CURRENT: > > The "intended" identity of origin value defined in [RFC8342] > > represents the origin of configuration provided by > <intended>, this > > document updates its definition as the origin source of > > configuration > > explicitly provided by clients, and allows a subset of > > configuration > > in <intended> that flows from <system> yet is not configured > or > > overridden explicitly in <running> to use "system" as its > origin > > value. > > > > Cheers, > > Med > > > > > > __________________________________________________________________ > __________________________________________ > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc pas etre > diffuses, exploites ou copies sans autorisation. Si vous avez recu > ce message par erreur, veuillez le signaler a l'expediteur et le > detruire ainsi que les pieces jointes. Les messages electroniques > etant susceptibles d'alteration, Orange decline toute > responsabilite si ce message a ete altere, deforme ou falsifie. > Merci. > > This message and its attachments may contain confidential or > privileged information that may be protected by law; they should > not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender > and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that > have been modified, changed or falsified. > Thank you. > ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
