On Mon, Aug 8, 2016 at 4:24 PM, Kent Watsen <[email protected]> wrote:
> 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. > > > No, it actually is not the way we have been doing things all along. Historically (even with NETCONF, not just SNMP) we standardize read-only monitoring information. Sometimes configuration is added later. Issues 1 - 3 are practical issues that need to be addressed if top-level config=false nodes are not allowed anymore. Andy > 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]> 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] > https://www.ietf.org/mailman/listinfo/netmod > > >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
