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. 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. /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 netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
