Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Robert Wilton <[e-mail]>]

Hi Andy,


On 12/07/2016 17:17, Andy Bierman wrote:
>
>
> On Tue, Jul 12, 2016 at 8:23 AM, Lou Berger <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     Acee,
>
>         I personally was assuming we'd follow 3, but I'd like to
>     understand
>     the implication of 2 as I'm not sure I really understand what you're
>     thinking here.  Can you elaborate what you're thinking here?
>
>     Thanks,
>
>     Lou
>     .....
>     >   3. #2 plus collapse the config (read-write) and system-state
>     > (read-only) into common containers. No more branching of
>     > <model-name>-config and <model-name>-state at the top level of
>     the model.
>     >.....
>
>
>
> I would really like to understand what problem (3) is supposed to solve.
My personal view is that I think that it makes the models simpler, with 
less duplication.

E.g. I also see that it makes it easier for a client to fetch all of the 
information associated with a particular feature in a single sub tree 
rather that needing to merge data from two separate config & state sub 
trees.

>
> Most of the foo-state variables are for monitoring.
> This information is useful even if the server uses proprietary 
> configuration mechanisms.
> (e.g., the way the SNMP world has worked for 30 years)
I thought that it was config that was originally driving YANG because 
there is already a solution for state data (SNMP).  Hence, I would have 
thought that the most common case would be that YANG is used just for 
config, or config & state.  So, I think that it makes sense to optimize 
models for these scenarios.

>
> If you forbid separate monitoring subtrees and force the data to be 
> co-located
> with configuration, that means the standard monitoring will not be 
> supported
> unless the standard configuration is also supported.
Both datastore draft solutions allow for system created config entries.  
So in both drafts the operational state datastore can instantiate 
whatever config nodes are necessary to parent config false state nodes.

I also don't think that separate monitoring subtrees are going to be 
banned, they should be used where appropriate.  It is just that it will 
be no longer be required to have separate state subtrees purely because 
of potential differences in the lifetime of config vs state objects 
(e.g. interfaces vs interfaces-state).

I would be very happy if "interfaces" and "interfaces-state" could be 
merged into "interfaces" as a new/updated interfaces YANG model that 
draft models could be updated to use.  I understand that would be a 
impactful change to make (but seemingly mostly on IETF models that 
haven't yet been standardized).  But I hope that we are going to have to 
live with the YANG model structure for a long time, and if we still have 
an opportunity to "fix" a fairly big wart then I think that it would be 
good to do so.

Rob

>   Why is that progress?
>
>
> Andy
>
>
>
>
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod