Hi Jan, > After us all now having investigated this line of reasoning, my conclusion is > that we have to choose one of two approaches:
The primary open-question is if it is *needed* for a client to copy <system> nodes into <running>. IMO, to understand the requirements, this question must be answered first. The draft highlights three reasons: 1. so running-alone can be valid (e.g., 5.5.1 and 5.5.2) 2. so system-defined values can be changed (e.g., section 5.5.3) 3. so descendents can be added to system-defined nodes (e.g., 5.5.4) Each are discussed below. Regarding #1, I’m sympathetic to not flipping an established client-contract without warning. My proposal is to version the protocols (i.e. NETCONF 1.2 and RESTCONF 1.1) to indicate this change in behavior. That is, a server implementing the <system> datastore would have to implement the updated protocol versions. So, for this item, it seems that it is not *needed* for a client to copy nodes into <running>, if the protocols are versioned. Regarding #2, I am firstly unclear how this is needed, when we’re only just now, for the first time, exposing system-defined configuration. Up to now, system-defined configuration only appeared in <operational>, with no ability to tweak it, right? Secondly, the example is not compelling, e.g., why would a client care what the MTU is on the loopback interface? But, if this is important, how do vendors enable it to be changed today? Regarding #3, same as #2: how is this needed? The example is not compelling. If this is important, how do vendors enable such extensions today? Kent // as a contributor
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
