Hi, I do not see any justification to RECOMMEND a combined tree. I do not think 6087bis should give guidelines based on speculation about a new holistic architecture in the future,
I agree with Juergen that the pros and cons of different approaches should be discussed, and designers can decide which trade-offs work best for them. Andy On Tue, Aug 9, 2016 at 2:31 PM, Kent Watsen <[email protected]> wrote: > Juergen, Andy, > > > > I think that my proposed text for 6087bis clearly articulates what > protocols can do today and tomorrow, while making a *very subtle* > recommendation for today’s model designers to future-proof their models. > > > > Please focus on the proposal, consistent with the Lou’s chair-request ( > https://mailarchive.ietf.org/arch/msg/netmod/NK864oXvIfeAYoCUTK40wn2Kw-8). > > > > Kent // as a contributor > > > > > > *From: *Andy Bierman <[email protected]> > *Date: *Tuesday, August 9, 2016 at 5:01 PM > *To: *Juergen Schoenwaelder <[email protected]>, > Robert Wilton <[email protected]>, Andy Bierman <[email protected]>, > Kent Watsen <[email protected]>, "[email protected]" <[email protected]> > *Subject: *Re: [netmod] OpsState and Schema-Mount > > > > > > > > On Tue, Aug 9, 2016 at 6:38 AM, 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. > > 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. > > > > +1 > > > > IMO the suggestion of using YANG extensions to associate data from > different subtrees > > was the most practical approach so far. Moving objects and overloading > object location > > semantics will have a big impact on existing code. Adding metadata and > RPC operations > > will not be disruptive, and it allows more complex associations to be > expressed. > > > > If the config needs to exist in order for the opstate and statistics to be > relevant, > > then of course put them in the config subtree. But if they can be > relevant without config, > > then the config data model has to be more complex to distinguish bogus > entries from real ones. > > The YANG validation has to know the difference as well, adding hacks to > that code. > > The access model needs to account for creation of bogus entries vs. real > ones, > > adding an operational cost to this solution approach. > > > > The YANG to use depends on the requirements. > > The /foo-state tree can be considered "always on". > > If this is not desired then a better design is to use a P-container: > > > > container foo { > > presence "Indicates foo counters are being collected"; > > container foo-stats { > > config false; > > /... > > } > > } > > > > This combination of config and state has a use-case. > > I don't see a use-case for NP-container though. > > > > > > > > > > > > > > /js > > > > > > Andy > > > > > -- > 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
