Re: [netmod] OpsState and Schema-Mount

On Mon, Aug 8, 2016 at 4:24 PM, Kent Watsen <kwatsen@juniper.net> 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 <andy@yumaworks.com>
> *Date: *Monday, August 8, 2016 at 5:51 PM
> *To: *Kent Watsen <kwatsen@juniper.net>
> *Cc: *"Acee Lindem (acee)" <acee@cisco.com>, "Robert Wilton -X (rwilton -
> ENSOFT LIMITED at Cisco)" <rwilton@cisco.com>, Ladislav Lhotka <
> lhotka@nic.cz>, Balazs Lengyel <balazs.lengyel@ericsson.com>, "
> netmod@ietf.org" <netmod@ietf.org>
> *Subject: *Re: [netmod] OpsState and Schema-Mount
>
>
>
>
>
>
>
> On Mon, Aug 8, 2016 at 1:16 PM, Kent Watsen <kwatsen@juniper.net> 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
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
>
>