Hi, Balazs, Thanks for the comments, much appreciated! I am trying to prepare a new version resolving your comments, please also see my reply below.
From: netmod [mailto:[email protected]] On Behalf Of Balázs Lengyel Sent: Friday, December 2, 2022 11:01 PM To: [email protected]<mailto:[email protected]> Subject: [netmod] Balazs comments on draft-ietf-netmod-system-config-00 Hello, Some comment on draft-ietf-netmod-system-config-00. General: I support this work, I see it as important. Thanks, Balazs. I see it both important and interesting. Since there is a broad implementation among multiple vendors, the authors would always welcome contributions from the WG. I think this draft should be dependent on the immutable draft. I see limited value of system-configuration if there is no way to protect It from client modification. While I agree that a lot of system configuration need to be protected from client modification, this work tries to define a standard mechanism to :1) allow the client to see what system configuration is available (includes inactive system configuration which is not present in <operational>) ;2) enable the client to reference system configuration without having to copy it into <running> explicitly; 3) support a better configuration of descendant nodes of system configuration. Ch 1) Why is explicit copying bad? Why do we need resolve-system parameter? the You should motivate that. I think the reason is that we always want the life easier and more convenient for clients. The device exists a lot of system configuration, the client would like to leafref system configuration (or put system configuration in when/must statement) directly in <running>, without having to declaring the referenced item in <running> manually. Sure, we will try to state it clearly in the Introduction section. Ch 1.4) edit-config and edit-data cannot be used towards the startup datastore. Copy-config can. Agree that edit-config and edit-data cannot be used towards <startup>. This sentence that might cause confusion can be traced from RFC7950 Sec.8.3.3 "If the datastore is 'running' or 'startup', these constraints MUST be enforced at the end of the <edit-config> or <copy-config> operation." Given the next comment that you made, see my proposed changes below. " If the target datastore of the <edit-config>/<edit-data> or <copy-config> is "candidate", the server's copy referenced nodes from <system> to the target datastore is delayed until a <commit> or <validate> operation takes place." This means that the device has to remember that resolve-system was used. Is this fact visible for other clients? What if someone overrides items that were planned for resolve-system? Other clients (not the one that used the resolve-system) will be confused. What happens if I have a must statement including a "count () <= max" on list items. Another client might create max number of list entries. This could prevent the device from adding new list-entries based on resolve-system. IMHO delaying the copy is a bad idea. Thanks for pointing this out. I think your arguments are valid to me. The server having to remember that there is a resolve-system parameter used before just complicates the implementation. Since this parameter is carried with the RPC operation, it makes sense the copy operation should always be finished at the end of RPC operation itself. Proposed update: OLD:" According to the NETCONF constraint enforcement model defined in the section 8.3 of [RFC7950], if the target datastore of the <edit- config>/<edit-data> or <copy-config> is "running" or "startup", the server's copy referenced nodes from <system> to the target datastore MUST be enforced at the end of the <edit-config>/<edit-data> or <copy-config> operations during the validation. If the target datastore of the <edit-config>/<edit-data> or <copy-config> is "candidate", the server's copy referenced nodes from <system> to the target datastore is delayed until a <commit> or <validate> operation takes place." NEW: "The server's copy referenced nodes from <system> to the target datastore MUST be enforced at the end of the <edit-config>/<edit-data> or <copy-config> operations. This is regardless of which target datastore it is." 1.5.2) IMHO we should have the same capability in Netconf too. I am thinking that a client can discover if the server supports the resolve-system parameter by reading the YANG library information in <operational> and checking if the server supports the "ietf-netconf-resolve-system" YANG module. Given that, there is no need to define a resolve-system capability identifier for NETCONF. Thoughts? 2) Define what does it mean if a part of system configuration is not active/ not applied? In which datastore is it visible? If I explicitly copy a conditionally-active item into <running> (while its condition is still not met) does it become active? If system configuration is inactive, it means this configuration is not "in use" and does not actually impact the current running configuration of the device. According to the definition of the Operational datastore in NMDA draft, such configurations are not present in <operational> but also depends on the server interpretation of "in use" and server implementation. While it is for sure that, inactive system configuration appears in <system> once it's generated. Conditionally-active item is generated and applied once specific conditions are met (e.g., physical or software resources). Take the interface for example, if a client explicitly creates an interface in <running> which does not physically exist, the interface does not appear in <operational> but only in <intended>, it's still inactive configuration. 3) 3.1) The headers seem strange. I would consider changing them. #Ch3 is about Static Characteristics of what? Does the title "Read-only to Clients" seem strange to you? Any suggestions to improve? #Ch3 is intended to describe the static characteristics of the system datastore, agree that this should be highlighted in the next version of the draft. Regards Balazs Best Regards, Qiufang
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
