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

[Robert Wilton <[e-mail]>]

On 12/07/2016 18:05, Andy Bierman wrote:
>
>
> On Tue, Jul 12, 2016 at 9:59 AM, Robert Wilton <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     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.
>
>
> This is your opinion.
> I think separate makes it easier to read, especially if the monitoring 
> data
> is relevant regardless of how associated configuration was done.
This is easily achievable by filtering (e.g. only return config false 
leaves + config true structural nodes).


>
>>
>>     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.
>
>
>
> This is marketing.
> Do you have any technical arguments?
Yes, I gave them below: I don't see that merging config and state 
prevents entities from only monitoring state if they wish.

Thanks,
Rob


>
>>
>>     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.
>
>
> I can't say if the pre-provisioning model in ietf-interfaces should be 
> generalized.
> I have not seen any good general solutions for combining config and state.

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