On Mon, Nov 14, 2016 at 11:23:04AM +0900, Ladislav Lhotka wrote: > Hi, > > I've read the revised-datastores-00 document, in general I like it, here > are my initial comments and questions: > > 1. Even if <intended> is valid, it can still be in conflict with the > actual content of <applied> that may come from e.g. dynamic > configuration protocols. How are such cases supposed to be resolved?
Yes. The whole idea is to expose these potential differences instead of hiding them behind a curtain. > 2. What is the distinction between dynamic configuration protocols and > control-plane protocols? Good question. I believe this to be at the end implementation specific. The question I think really is whether a control-plane protocol interacts with the configuration management component or not. > 3. Shared <candidate> has known problems. Maybe it's time to part with > it in this new datastore model? This clearly was not the focus of this work. > 4. Templates are briefly mentioned in several places, it would be useful > to explain this concept in more detail. I agree. > 5. Is it necessary that "<operational-state> datastore contains all > configuration data actually used by the system"? For example, static > routes should appear in RIBs, so having them separately in operational > state seems redundant. I do not understand your question. Is the RIB exposed or not? Anyway, we need a general model and not a model for specific aspects such as routing. Yes, there can be redundancy but there can also be semantic differences. The <operational-state> datastore tells me what is actually used (regardless of what has happened with the statically configured values). In other words, if I want to debug what my box is actually doing, looking at the <operational-state> datastore is probably a good idea. /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
