> On 09 Aug 2016, at 15:38, Juergen Schoenwaelder > <[email protected]> wrote: > > On Tue, Aug 09, 2016 at 02:12:01PM +0100, Robert Wilton wrote: >> >> In particular, I think that the guideline would be along the lines: >> If a given module "foo" only contains state and no configuration, then >> having a single top-level "foo" config false node is fine, but if a given >> module contains both config and state then the recommendation is to put that >> under a config=true "foo" top-level node. Refining that slightly, If the >> state data is relevant even if "foo" hasn't been enabled then make the top >> level "foo" an NP container. If "foo" has to be enabled on the system for >> the state data to be relevant then make "foo" a P container (or give it a >> separate foo/enable leaf). In summary, I would suggest that the foo state >> data should be pushed as far down the combined config/state tree as >> possible. It should be sited below (or adjacent to) whichever config node >> is required to make that state data relevant. >> >> If config and state are in the same tree then it is easy to return all the >> data in one RPC, or have separate RPC operations that just return >> configuration (e.g. <get-config>), or just return "state + containing >> hieararchy" (e.g. a newly defined <get-state>, or equivalent). >> >> Having separate foo vs foo-state trees at the top level is always going to >> make it harder to return and manage a combined view of the config and state >> data. > > I think it is crucial to separate (a) what protocols do today and (b) > what protocols might do at some time in the future. > > The current protocol reality, that is (a), paired with the reality of > network interfaces has lead to the (/interfaces, /interfaces-state) > design pattern and until we have (b) in place I do not think we have > really an alternative for the (/interfaces, /interfaces-state) > design pattern.
I would also add that some aspects of YANG (config true/false dichotomy, validation rules) make everything else difficult. > > If you have config and state are in the same tree, you simply can't > represent certain things that exist in reality. A single tree may look > 'simpler' but in several cases also simply 'unusable'. We did not > particularly like the (/interfaces, /interfaces-state) design but it > was the only solution that seemed to work for all cases given the > protocol reality we were in. Right. We have tried hard to find something more elegant, and some attempts (for example [1]) were quite similar to the current OpState proposals, but we eventually realised that our shortcuts only work in simple examples and break down in more complex situations. That said, I don't claim that a more elegant solution is impossible (and Randy Presuhn would probably note that it was already available 25 years ago:-) but IMO it is not a low-hanging fruit given what we currently have (YANG and the protocols). Lada [1] https://tools.ietf.org/html/draft-bjorklund-netmod-operational-00 > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 <http://www.jacobs-university.de/> > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
