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

[Balazs Lengyel <[e-mail]>]

Hello,

Later I will try to provide a text proposal as well, but some points:

• I prefer a tight definition so even if we allow both 1) and 2)  we should state that other combinations e.g. trees spliting close to the leaves or a mix of 1) and 2) in the same module are not allowed (VERYYYY STRONGLY discouraged).
  
• In one of the earlier mails there was a a statement: if we have foo and foo-state trees, the containers/list/key-leafs SHOULD be the same in the two. The structures of the two trees SHOULD not just be si,i;ar, they should be the same.

This way you could look at the root objects of the module and immediately know what is the situation.

regards Balazs

On 2016-07-29 18:32, Juergen Schoenwaelder wrote:

On Fri, Jul 29, 2016 at 04:35:05PM +0100, Robert Wilton wrote:
 

I would like to know what should the common approach for IETF standard
models be?  E.g. is it one of the following:

1) All config false leaves for foo must go under /foo-state.

I think if you have /foo-state, then this is a logical consequence. Do
we have any data models that have a /foo-state tree and config false
nodes under the /foo tree?

2) All config false leaves for foo must go under /foo

This apparently does not make sense in certain circumstances until we
have a revised datastore solution defined and implemented that may
allow this to work in all situations.

3) All config false leaves go under /foo where possible, or /foo-state
otherwise (e.g. for restconf-monitoring).

I think it should be fairly easy for a tool to figure out whether a
/foo tree is a pure config true tree or whether there are any config
false leafs as well and /foo is a mixed tree. Things are fairly easy
as long as people split at the root if they split.

4) Config false leaves go wherever the model writer decides is appropriate.

I think we will have to live for a while with both the (i) /foo (pure
config true tree) and /foo-state (pure config false tree) split at the
root approach and the (ii) /foo (mixed config true and false tree)
approach. We need to document the trade-offs between the two so that
module writers can make an informed decision. Whether a module uses
(i) or (ii) should be possible to determine by inspecting the
properties of the schema tree, in particular if module writers follow
the guideline to use consistent names and structure in the /foo and
/foo-state approach wherever possible.

I think we also wanted to strongly discourage models where (iii) the
trees split at the leaves or very close to the leaves.

/js

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: [phone]              email: [e-mail]