[as a contributor]
Hi Rob, >I don¹t agree with this diagram. The applied configuration is essentially >the current running state of the hardware. It cannot be directly changed >by a user, and hence it needs to be read-only and hence config false. Agreed that the applied config is read-only, but that doesn't mean the data tree has to be config false. For instance, in the draft submitted yesterday, this requirement is achieved by defining a read-only datastore. >operational: true is used to represent op-state that does not correspond >to any configuration (neither applied, nor intended), but represent >parameters that are related to protocol interactions, counters, etc. This >again is read-only. I'm unclear with the difference, how is it different than data modeled config false? >>Consider a system that has a single NMS that talks to all elements, and >>it is the *only* means of managing those elements. In general, that NMS >>knows what the state of the intended config is (it wrote it), if the >>system is synchronous then it also knows the state of the applied >>config. Therefore if it is polling, it is likely to want to only get the >>derived state data, which can be filtered on operational true. The >>intention of these statements is to impress the need on the reader to >>have a mechanism to poll only this data efficiently (if this is, indeed, >>to be polled). Okay, but there are other ways to enable a client to poll just the derived state (config false nodes). For instance, the draft posted yesterday introduces a <get-state> operation to do this. K. _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
