On 09/08/2016 00:30, Andy Bierman wrote:
On Mon, Aug 8, 2016 at 4:24 PM, Kent Watsen <kwat...@juniper.net
<mailto:kwat...@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.
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 <a...@yumaworks.com <mailto:a...@yumaworks.com>>
*Date: *Monday, August 8, 2016 at 5:51 PM
*To: *Kent Watsen <kwat...@juniper.net <mailto:kwat...@juniper.net>>
*Cc: *"Acee Lindem (acee)" <a...@cisco.com
<mailto:a...@cisco.com>>, "Robert Wilton -X (rwilton - ENSOFT
LIMITED at Cisco)" <rwil...@cisco.com <mailto:rwil...@cisco.com>>,
Ladislav Lhotka <lho...@nic.cz <mailto:lho...@nic.cz>>, Balazs
Lengyel <balazs.leng...@ericsson.com
<mailto:balazs.leng...@ericsson.com>>, "netmod@ietf.org
<mailto:netmod@ietf.org>" <netmod@ietf.org <mailto:netmod@ietf.org>>
*Subject: *Re: [netmod] OpsState and Schema-Mount
On Mon, Aug 8, 2016 at 1:16 PM, Kent Watsen <kwat...@juniper.net
<mailto:kwat...@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
<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
<https://www.ietf.org/mailman/listinfo/netmod>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
