Hi Andy,
I don't properly understand the points that you are making, please see
clarifying comments/questions inline ...
On 08/08/2016 22:51, Andy Bierman wrote:
On Mon, Aug 8, 2016 at 1:16 PM, Kent Watsen <[email protected]
<mailto:[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
<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
If it is one module with two top level augments (foo and foo-state) then
this problem still exists. Hence, please can you clarify why converging
them on a single root node means that monitoring cannot be used on it
own? Wouldn't a device need to use deviations in both cases to strip
out the config nodes that they are not supporting?
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.
Again, I don't quite follow this, in the specific example that I have
regarding putting a RIB under a config true NP container, I would have
thought that NACM read access would have been sufficient for a
monitoring-only client. Is that not the case?
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.
Similar to my response to the first question, I thought that conformance
was done on a per module base, not a per sub-tree basis. So even if you
have top level 'foo' and 'foo-state' as part of the same module don't
you run into the same conformance problem?
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.
Sorry, I don't really follow this one. The original opstate draft put
forward by OpenConfig was asking for both applied-configuration and
derived state (e.g. statistics and other state) to be co-located under
the same structures. The original discussions focused on applied
configuration, but when this was being discussed more recently the
desire for a solution to the co-located derived state was also discussed
- which is why both draft-schoenw-netmod-revised-datastores-01 and
draft-wilton-netmod-refined-datastores-01 propose solutions to this problem.
There are also benefits to merging this data:
1) Having co-located config and state data means that clients can easily
request config and state for a related object in a single request
1b) Having co-located config and state makes it easier for clients to
code - they don't need to unify data across two (potentially different
structures/indexes).
1c) Having a single structure, means less copying of the same
organization structure into both config and state sub trees (which could
be a source of bugs)
2) Having a single root makes schema mount work more nicely, it avoids a
duplicate hierarchy.
3) Finally, I also agree with Kent, in that merging these makes the
models easier to read and removes a historical wart.
Thanks,
Rob
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] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/netmod
<https://www.ietf.org/mailman/listinfo/netmod>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
