Kent, Apologies, I missed this email. If I can respond to a limited section of it.
On August 24, 2015 at 22:14:47, Kent Watsen ([email protected]) wrote: > > And yet again in Section 2, Figure 1 and text just below it don't square up. > The applied > config is shown as having the same leaves as the intended config, and is > listed below the > line marked config: false. Also, the text says "Only derived state is marked > as operational > data" and while I also see "operational:true" in Figure 1, this is a forward > reference > to Section 9.1, which is confusing. Attached is a picture illustrating my > view on this. 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. 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. > Also in Section 2, the end of the 6th paragraph states "To this end, > operational state > information can be considered to be 'unknown' to the network manager." - what > does this mean? > - isn't it just a matter of the NMS polling on this YANG-modeled data? 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). r. _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
