Hi Qiufang, Thanks so much for the clarification and the new version which mostly addresses my comments.
See further comments based on your answer in-line, labelled with [lmcm>>]. Thanks, Luis De: maqiufang (A) <[email protected]> Enviado el: miércoles, 14 de enero de 2026 7:50 Para: LUIS MIGUEL CONTRERAS MURILLO <[email protected]>; [email protected] CC: [email protected]; [email protected]; [email protected] Asunto: RE: draft-ietf-netmod-system-config-16 ietf last call Opsdir review AVISO/WARNING: Este correo electrónico se originó desde fuera de la organización. No haga clic en enlaces ni abra archivos adjuntos a menos que reconozca al remitente y sepa que el contenido es seguro / This email has been originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi, Luis, Thanks a lot for the review, a new version is submitted to address your comments below, the diff is available at : https://author-tools.ietf.org/iddiff?url2=draft-ietf-netmod-system-config-18. Please also see my reply below inline with [Qiufang]... -----Original Message----- From: Luis Contreras via Datatracker [mailto:[email protected]] Sent: Saturday, January 10, 2026 12:30 AM To: [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: draft-ietf-netmod-system-config-16 ietf last call Opsdir review Document: draft-ietf-netmod-system-config Title: System-defined Configuration Reviewer: Luis Contreras Review result: Has Issues Hi, I have been selected as the Operational Directorate (opsdir) reviewer for this Internet-Draft. The Operational Directorate reviews all operational and management-related Internet-Drafts to ensure alignment with operational best practices and that adequate operational considerations are covered. A complete set of _"Guidelines for Considering Operations and Management in IETF Specifications"_ can be found at https://datatracker.ietf.org/doc/draft-opsarea-rfc5706bis/. While these comments are primarily for the Operations and Management Area Directors (Ops ADs), the authors should consider them alongside other feedback received. - Document: draft-ietf-netmod-system-config-16 - Title: System-defined Configuration - Reviewer: Luis M. Contreras - Review Date: 2026-01-09 - Intended Status: Standards Track --- ## Summary - Has Issues: I have some minor concerns about this document that I think should be resolved before publication. ## General Operational Comments Alignment with RFC 5706bis The draft defines a new system configuration datastore as an extension of the Network Management Datastore Architecture (NMDA) from RFC 8342; this datastore holds configuration that is provided and controlled by the system itself rather than by management clients. It introduces the concept of a read-only conventional configuration datastore called “system,” standardizing how system-defined configuration is exposed to clients, how it may be referenced (e.g., via leafref) or overridden by client-provided configuration, and how it integrates into the overall NMDA merge model. The work requires compliant NMDA servers to implement the ietf-system-datastore YANG module and updates RFC 8342’s definition of conventional datastores to include the system configuration datastore, enabling consistent access and usage of system-provided configuration across NETCONF/RESTCONF management operations The Operational Considerations section is missing and should be included, according to draft-ietf-opsawg-rfc5706bis. In particular, it would be good to add a description on implications in terms of backwards compatibility, and/or implications when porting configuration from legacy devices to new ones supporting this system-defined configuration (migration paths, etc). [Qiufang] Have added a new section to discuss operational considerations. [lmcm>>] ok, thanks ## Major Issues - Section 4. It is stated: “If it is desired to enable a client to delete system configuration, it can be approximated using <factory-default> ([RFC8808]).” It is not clear to me the difference between system-defined configuration and factory-default configuration. Specially because it is mentioned at the end of section 3 that “The system configuration datastore doesn't persist across reboots.”. Does this imply that system configuration is loaded after reboot? If so, in which part of the process the system-defined configuration is created? How far can be the system-defined configuration from the factory-default? How this relates with the always-present configuration generated in <system> when the device is powered on, as described in section 2.1? What is the relationship with the <startup< datastore depicted in Figure 1? [Qiufang] The concept of system configuration exists already since NMDA, while this draft proposes system datastore to hold system configuration. The different between <system> and <factory-default> is that, <factory-default> is the configuration that is used to initialize <running> when the device is first-time powered on or reset; while system provided configuration will not appear in <running> by default but will always be loaded and intended to be applied. We try to state less about <factory-default> because this is referring to the scope of <factory-default>. I also removed this sentence as it might bring confusion, as per your comments below. So when we discuss system configuration, it is non-deletable, if system provides some configuration that can be deleted, perhaps it should not be called system configuration, perhaps it should just be called factory-default configuration, or something else, which is out of scope of this draft. [lmcm>>] Maybe it would be convenient to add this to the document. I mean, clarifying the scope and also the kind of info (i.e., non-delatable) which is expected for the system configuration. - On the same sentence: it is a bit weird the expression of that “it can be approximated”. This is not clear in terms of operational effects. [Qiufang] As my comment below, this sentence is removed now. [lmcm>>] ok - Section 5.1 on Read-only to Clients. How consistent is this wrt the previous comment (i.e., the possibility of the client to delete the system configuration)? [Qiufang] Hopefully my clarification above helps avoid the terminology confusion. [lmcm>>] ok - On the dynamic behaviors as per section 6.1 “May Change via Software Upgrades or Resource Changes”. If the contents of <system> may change by licenses, etc, is it foreseen or expected any kind of warning or advice in this respect? [Qiufang] The document already says: “The updates of system configuration may be obtained through YANG notifications (e.g., on- change notification) [RFC8639][RFC8641].” Is there anything else that you think needs to be added? [lmcm>>] it is ok, thanks - Section 6.3 describes the possibility of modifying (overriding) system configuration. What happens if an overwritten value changes from the system perspective as consequence e.g. of a license as described in section 6.1? Is it kept the overwritten value or it is considered the new system value? [Qiufang] The merging logic as described in Sec.4 applies here. If the value is mutable, configuration provided by the client takes precedence and <intended> still contains the overridden value. [lmcm>>] I think it would be good to add one sentence in 6.3 with your comment. ## Minor Issues - It seems along the text that device and server are used interchangeably. It would be good to clarify, or as alternative, to use one single terminology for consistency. [Qiufang] Thanks for spotting this, the following sentence has been added: "The terms "device" and "server" are used interchangeably in this document." [lmcm>>] ok - Section 6.1. I wonder if SHOULD in the sentence “If system configuration changes, <running> SHOULD remain a valid configuration data tree” should be MUST. [Qiufang] this is based on some previous discussion in WG. There are some cases like when device upgrade, <system> may change and <running> becomes invalid, and there might need some handling to ensure <intended> (and <running>) remains valid. Some previous versions have examples of how a server/client may behave to ensure validity of <running>. But the WG then decides to just allow <running> to become invalid in such cases, and how to ensure the validity of <running> is out of scope. [lmcm>>] ok, got it, thanks ## Nits - Section 2.2: “Another example is when a special functionality is enabled, e.g., when a license or feature is enabled, specific configuration may be created by the system.” Maybe change the second “enabled” by “activated” or similar for avoiding repetition. [Qiufang] Have fixed this sentence as follows: “Another example is when a special functionality (e.g., a license or feature) is enabled, specific configuration may be created by the system.” - Annex B2: should not be "lo0" loopback interface instead of "lo" ? [Qiufang]Fixed, thanks. --- Best Regards. Qiufang ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción. The information contained in this transmission is confidential and privileged information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
