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

[Andy Bierman <[e-mail]>]

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.



> Thanks,
> Acee
>
>
Andy


>
> Why is that progress?
>
>
> Andy
>
>
>
>
>