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

[Andy Bierman <[e-mail]>]

On Tue, Jul 12, 2016 at 9:59 AM, Robert Wilton <[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]> 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.



>
> 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?


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