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

[Balazs Lengyel]

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: +36-70-330-7909 email: balazs.leng...@ericsson.com

_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod