To clarify, OpenConfig instituted a strategy of having a symmetric “config false” data tree in <running> to report the opstate values for “config true” nodes. This approach nearly doubles the size of the schema tree.
OC’s goal to report the opstate value for CT data is well reasoned and good. To support this goal, in part, the NETMOD WG published NMDA (RFC 8342). The NMDA approach differs in that it defines an <operational> datastore that contains the opstate value for all CT data, in addition to CF data. Thus eliminating the need to explicitly define a CF data tree. Sadly, to date, this benefit provided by NMDA has not been compelling enough to be widely implemented, much less adopted by OC, which it could’ve, if it wanted. [I’m envious of how OC can force quick change (assert an approach), whereas the IETF has to arduously wait for NC/RC-next to formally move to NMDA.] But NMDA offers more benefits than just being able to report the opstate value for CT data. This is seen with <factory> datastore, the <system> datastore, the cross-cutting “template” solution being discussed now, and the cross-cutting “inactive” solution I’m hoping someone will submit an I-D for. In short, NMDA supports use cases not possible otherwise. Strategically, IMO, NMDA is the way. My hope is that OC will migrate to use NMDA. It would benefit Operators for OC to align NMDA. My earlier message was not wholly on point. My intention was/is to state that NMDA, with templates + inactive, would be tremendously, perhaps overwhelmingly, compelling to all implementations, even to OC. Kent / contributor
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
