On Fri, Feb 05, 2016 at 05:22:03PM +0000, Robert Wilton wrote: > > 2. Personally, for a datastore solution, I would prefer if the new > datastore was for the intended configuration, and that the applied > configuration was stored in the same datastore (running?) as all the > rest of the operational state.
The running datastore is a configuration datastore, it does not hold operational state. > If the logical flows of system information is as follows: > [candidate] -> intended cfg -> applied cfg -> derived state > > Then it seems strange to bundle intended cfg & derived state together in > one datastore, and to have applied-cfg separate (a bit like an unwanted > step child). This is not what is being proposed. We always had [candidate] -> [running] -> operational state (and I mark configuration data stores in []). Both [candidate] and [running] have the same configuration data model. Now we are asked to expose that [running] may not be applied synchronously and hence [candidate] -> [running] -> [applied] -> derived state seems to make sense. > 5. Am I correct to presume that this draft doesn't provide any support > to return intended config, applied config & derived state all in a > single request? I appreciate that this isn't included as a formal > requirement - but part of me wonders whether this might have been an > oversight in the requirements. Can be defines easily as another RPC. That said, I heard that some big vendors even refuse to implement today's get operation that returns the combination of [running] and operational state. > 6. I can understand the decision of get-diff to reuse edit-config or > YANG patch, but I'm not sure that this makes it particularly easy for > clients to then process that data. I might be wrong, but I suspect that > a solution that returns the values of the intended and applied config > nodes in an easier to relate way may be preferable (perhaps something > along the lines of the encoding proposed in > draft-wilton-netmod-opstate-yang). A diff is a way to make delta's efficient. /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
