Re: [netmod] OpsState and Schema-Mount

[Robert Wilton <[e-mail]>]

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 <[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
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
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/netmod
>     <https://www.ietf.org/mailman/listinfo/netmod>
>
>