Re: [netmod] OpsState and Schema-Mount

Kent Watsen <kwatsen@juniper.net> 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 <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<mailto: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<mailto:netmod@ietf.org>
> https://www.ietf.org/mailman/listinfo/netmod
>

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C