For 1,2,3, realize that placing config false nodes under config true nodes has been with us from the beginning. All the issues you mentioned (if they’re issues at all) can’t be new. Having a duplicate -state tree is the wart here, it’s introducing an inconsistency in how models have been written for a long time. I prefer to remove the wart than celebrate it.
For 4, right, this discussion on s5.23 of 6087bis regards how to handle state for system-generated objects (e.g., interfaces). It is not directly related to the how to report applied configuration problem. It is however indirectly related, in that a holistic solution can address both. Kent From: Andy Bierman <[email protected]> Date: Monday, August 8, 2016 at 5:51 PM To: Kent Watsen <[email protected]> Cc: "Acee Lindem (acee)" <[email protected]>, "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" <[email protected]>, Ladislav Lhotka <[email protected]>, Balazs Lengyel <[email protected]>, "[email protected]" <[email protected]> Subject: Re: [netmod] OpsState and Schema-Mount On Mon, Aug 8, 2016 at 1:16 PM, Kent Watsen <[email protected]<mailto:[email protected]>> wrote: Acee writes: > Then I see no YANG language barriers in collapsing config and state trees > - the model root just needs to be “config true”. Great, I think we’re all agreed. Can we now discuss the text I proposed for 6087bis? - here’s the link to my proposal: https://mailarchive.ietf.org/arch/msg/netmod/-zbXNhw2BJYMyrBT9nnCwoLAJ0s. IMO this effort to avoid 2 containers is not well thought out. Some concerns: 1) modularity placing the monitoring objects within the configuration means the monitoring cannot be used on its own 2) access control placing the monitoring data within configuration means the monitoring-only clients need write permission turned on for the nodes they can access for read-only This relies on granular and complex NACM rules which require regular maintenance. 3) YANG conformance placing the monitoring data inside the configuration means the configuration will be required for conformance; it is not likely to be just 1 NP container. 4) pointless; given that new RPC operations are needed to access applied config, the only data not affected (and moved under the config container anyway) is stuff that does not share the same indexing, or counters which are not part of the opstate problem. Andy Hint: the first few edits are just nits...skip over the first few paragraphs until you start seeing large blocks of changed lines... Kent // as a contributor _______________________________________________ netmod mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
