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

[Andy Bierman <[e-mail]>]

On Wed, Jul 13, 2016 at 3:04 AM, Robert Wilton <[e-mail]> wrote:

> Hi Alex,
>
>
> What you describe is close, but not quite what either of the two datastore
> solutions are proposing.
>
> In this case, the two solutions in both proposed drafts would contain:
>   - intended config doesn't contain the list entries
>   - applied config doesn't contain the list entries
>   - operational state datastore contains the system created (config true)
> list entries + descendant config false nodes.
>
> The reason why these system created entries are not in the applied
> configuration is because of the requirement from
> draft-ietf-netmod-opstate-reqs state that "intended config" = "applied
> config" if the system has converged and all configuration has been
> successfully applied.
>
> But, yes, the reason for allowing system created config true entries in
> the operational state datastore is to solve this problem.
>
>


I do not agree with Alex that config=true can mean "no client can ever set
this value".
It can only if NACM is configured to disable client write access.
I understand how one might want to use server-created values in validation
rules
but YANG does not support that right now (for config=false).

The line between server-created config and operational state is confusing
at best.




Rob
>
>

Andy


>
> On 13/07/2016 10:49, Alex Campbell wrote:
>
> 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]> <[e-mail]> on
> behalf of Andy Bierman <[e-mail]> <[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]> 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
>
>
>
>
>
>
> _______________________________________________
> netmod mailing [e-mail]://www.ietf.org/mailman/listinfo/netmod
>
>
>