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

[Andy Bierman <[e-mail]>]

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

>
>
> From: Andy Bierman <[e-mail]>
> Date: Tuesday, July 12, 2016 at 12:38 PM
> To: Acee Lindem <[e-mail]>
> Cc: Lou Berger <[e-mail]>, netmod WG <[e-mail]>
> Subject: Re: [netmod] OpsState Direction Impact on Recommended IETF YANG
> Model Structure
>
>
>
> On Tue, Jul 12, 2016 at 9:30 AM, Acee Lindem (acee) <[e-mail]>
> wrote:
>
>> Hi Andy,
>>
>> From: Andy Bierman <[e-mail]>
>> Date: Tuesday, July 12, 2016 at 12:17 PM
>> To: Lou Berger <[e-mail]>
>> Cc: Acee Lindem <[e-mail]>, netmod WG <[e-mail]>
>> Subject: Re: [netmod] OpsState Direction Impact on Recommended IETF YANG
>> Model Structure
>>
>>
>>
>> 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.
>>
>> 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)
>>
>> 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.
>>
>>
>> If they are meant to be supported independently, why wouldn’t they be
>> separate models?
>>
>>
>
> YANG features can be used and they can still be supported independently.
>
>
> True - but I have not run across a model featured at the config/state
> branch.
>
>
Can you answer the question "What problem is created by having separate
configuration
and monitoring subtrees?"

Seems like an RPC-based opstate solution does not depend on this change,
so why is it being proposed?


Acee
>
>
>
Andy


>
>
>
>
>> Thanks,
>> Acee
>>
>>
> Andy
>
>
>>
>> Why is that progress?
>>
>>
>> Andy
>>
>>
>>
>>
>>
>