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

[Andy Bierman <[e-mail]>]

On Tue, Jul 12, 2016 at 10:43 AM, Acee Lindem (acee) <[e-mail]> wrote:

>
>
> From: netmod <[e-mail]> on behalf of Andy Bierman <
> [e-mail]>
> Date: Tuesday, July 12, 2016 at 1:27 PM
> To: "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" <
> [e-mail]>
> Cc: netmod WG <[e-mail]>
> Subject: Re: [netmod] OpsState Direction Impact on Recommended IETF YANG
> Model Structure
>
>
>
> On Tue, Jul 12, 2016 at 10:22 AM, Robert Wilton <[e-mail]> wrote:
>
>>
>>
>> On 12/07/2016 18:05, Andy Bierman wrote:
>>
>>
>>
>> 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]>
>>> [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).
>>
>>
>
> Filtering is not widely implemented or implemented correctly.
>
> IMO it is up to the data model designers how they want to organize their
> data.
> I have not heard any valid reasons why a generalized solution is even
> needed,
> let alone why separate config and state needs to be avoided.
>
>
> There is definitely value in having model conventions. One argument for
> collapsing the config and state is that once you have the implicit
> retrieval of the applied state, there is much less operational state that
> isn’t redundant.
>
>
Yes there is value in modeling conventions in general.
I am trying to understand the value of this specific convention.

If I have an RPC that asks for applied state, then it doesn't really matter
how the config and state is organized.  There is only overlap in the objects
if the data model is designed that way.

Whether or not an edit is applied yet is a property of the implementation,
not the data model.

There is also requirement #4 in
> https://www.ietf.org/id/draft-ietf-netmod-opstate-reqs-04.txt. However, I
> know you’ve never been a fan of this document.
>
> Thanks,
> Acee
>
>
>
>
>
Andy


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