Re: [netmod] OpsState and Schema-Mount

[Robert Wilton <[e-mail]>]

On 09/08/2016 00:30, Andy Bierman wrote:
>
>
> On Mon, Aug 8, 2016 at 4:24 PM, Kent Watsen <[e-mail] 
> <mailto:[e-mail]>> 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.

For me, it seems to have been the opposite.  I.e. all the early pressure 
was to get configuration covered by YANG models, with the operational 
state following afterwards.  We are either being asked for config 
models, or config+state models.  I guess that is because there is an 
existing solution (SNMP) for monitoring devices, but there is no 
workable solution to configure devices without using YANG.

Further, it seems to me that NETCONF is quite config focused, and that 
handling state was more added as an afterthought (e.g. according to the 
NETCONF RFC, config false leaves don't even exist as part of any 
datastore!).  If reporting state was the main driver for NETCONF/YANG 
then I would have thought that the semantics for handling operational 
state would have been formalized earlier on.


>
> Issues 1 - 3 are practical issues that need to be addressed if 
> top-level config=false
> nodes are not allowed anymore.
I don't think that the proposal is to make them 'not allowed', but 'not 
recommended' instead.

In particular, I think that the guideline would be along the lines:
If a given module "foo" only contains state and no configuration, then 
having a single top-level "foo" config false node is fine, but if a 
given module contains both config and state then the recommendation is 
to put that under a config=true "foo" top-level node.  Refining that 
slightly, If the state data is relevant even if "foo" hasn't been 
enabled then make the top level "foo" an NP container.  If "foo" has to 
be enabled on the system for the state data to be relevant then make 
"foo" a P container (or give it a separate foo/enable leaf).  In 
summary, I would suggest that the foo state data should be pushed as far 
down the combined config/state tree as possible.  It should be sited 
below (or adjacent to) whichever config node is required to make that 
state data relevant.

If config and state are in the same tree then it is easy to return all 
the data in one RPC, or have separate RPC operations that just return 
configuration (e.g. <get-config>), or just return "state + containing 
hieararchy" (e.g. a newly defined <get-state>, or equivalent).

Having separate foo vs foo-state trees at the top level is always going 
to make it harder to return and manage a combined view of the config and 
state data.

Thanks,
Rob


>
>
> 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 <[e-mail] <mailto:[e-mail]>>
>     *Date: *Monday, August 8, 2016 at 5:51 PM
>     *To: *Kent Watsen <[e-mail] <mailto:[e-mail]>>
>     *Cc: *"Acee Lindem (acee)" <[e-mail]
>     <mailto:[e-mail]>>, "Robert Wilton -X (rwilton - ENSOFT
>     LIMITED at Cisco)" <[e-mail] <mailto:[e-mail]>>,
>     Ladislav Lhotka <[e-mail] <mailto:[e-mail]>>, Balazs
>     Lengyel <[e-mail]
>     <mailto:[e-mail]>>, "[e-mail]
>     <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>
>     *Subject: *Re: [netmod] OpsState and Schema-Mount
>
>     On Mon, Aug 8, 2016 at 1:16 PM, Kent Watsen <[e-mail]
>     <mailto:[e-mail]>> 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
>         <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
>         [e-mail] <mailto:[e-mail]>
>         https://www.ietf.org/mailman/listinfo/netmod
>         <https://www.ietf.org/mailman/listinfo/netmod>
>
>