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

[Robert Wilton <[e-mail]>]

On 13/07/2016 17:27, Andy Bierman wrote:
>
>
> On Wed, Jul 13, 2016 at 3:04 AM, Robert Wilton <[e-mail] 
> <mailto:[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.
RW:
I agree with you, but I didn't read Alex's email as stating that.

Instead, I read it as: even if a device doesn't allow the nodes to be 
configured then they could still be populated by the device in the 
applied configuration datastore.


> 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.
RW:

Yes, OK.  That is perhaps because they are not completely related.

The original OpenConfig opstate draft also asked for a solution to what 
they perceived as an unnecessary split between "feature" vs "feature-state".

When discussing the datastore solutions it became clear that having a 
formal definition of an "operational state datastore" also allowed for a 
solution to the problem above.  Specifically by allowing the operational 
state datastore to contain any necessary config true leaves (even if 
they have not been configured) that are required to hold any descendant 
config false leaves.

To cite an example:

If the schema content of if:interfaces-state was merged into the schema 
for if:interfaces then the "operational state datastore" of a device 
would be allowed to contain entries in the if:interfaces list for 
interfaces that exist in the system but have not been configured.

As a side note, the metadata draft that I've put forward then suggests 
to use metadata annotations of these system created entries in the 
"operational state datastore" to allow clients to distinguish between 
config true entries that exist because they are applied configuration, 
vs config true entries that exist because they are system created.

Rob



>
>
>
>
>     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]>
>>     <mailto:[e-mail]> on behalf of Andy Bierman
>>     <[e-mail]> <mailto:[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
>>
>>
>>
>>
>>
>>     _______________________________________________
>>     netmod mailing list
>>     [e-mail] <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/listinfo/netmod
>
>