Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de> writes: > 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.
That's fine but it doesn't answer my question. > >> 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. OK, perhaps it can be said that dynamic configuration protocols modify "config true" data. Maybe a term like "configuration interface" may be better because it needn't be a communication protocol, and it needn't be any more dynamic than NETCONF/RESTCONF is. > >> 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. Then I would suggest to remove it entirely as a protocol-specific thing. > >> 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. But could this part of operational state be possibly different from what's already in <applied>? Lada > > /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/> -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
