Kent Watsen <[email protected]> writes: > 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.
Before making changes to the existing models, I'd love to see a (proposal of a) complete solution. Just moving the config false stuff from foo-state to foo doesn't help at all. Lada > > 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 > -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
