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. _______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
