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

[Alex Campbell <[e-mail]>]

Isn't that exactly what the proposed applied configuration datastore is for?
If a device doesn't allow management stations to create or remove list entries, but still creates or removes list entries itself, then it can publish them through the applied configuration datastore, while leaving the intended configuration datastore empty.  Operational data can be contained inside those list entries which exist in the applied configuration store, instead of needing a separate tree to contain it.

- Alex





________________________________
From: netmod <[e-mail]> on behalf of Andy Bierman <[e-mail]>
Sent: Wednesday, 13 July 2016 4:17 a.m.
To: Lou Berger
Cc: netmod WG
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]<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.

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.  Why is that progress?


Andy