As I understand it,the only purpose for the candidate and startup datastores is to indirectly set the contents of the running datastore.
Therefore it wouldn't make sense to have different factory defaults for the running, startup and candidate datastores. And those are the only writable ones. Joe, which other datastores were you thinking of? Alex ________________________________________ From: netmod <[email protected]> on behalf of joel jaeggli <[email protected]> Sent: Tuesday, 26 March 2019 8:18 p.m. To: Joe Clarke; [email protected] Subject: Re: [netmod] Question on draft-wu-netmod-factory-default On 3/25/19 07:14, Joe Clarke wrote: > I support the need for being able to reset a DS to its factory default. > However, I have a question on the current design of the model and the > "factory-default" DS. > > It seems to me that this is a single DS that might have been intended to > reset running or startup. However, what if I have different DSes that > each have unique factory default data? If I choose to extend > factory-default with a new identity of my other DS, how can I indicate > that the target DS will be reset to _that_ DS? Does that make sense? > > Or if I do a <get-data> on a factory-default DS, how do I know what > other DSes does this DS pertain? Perhaps the server will use this to > reset a given DS, but how would a user know that (other than perhaps > naming of the factory-default DS)? > > Maybe the module needs a mapping to let the client know what DS will be > used to reset what other DS? the germ of the idea is sensible enough. reset a DS to it's factory state. When it meets reality of course is that there seem to be a bunch of variants that seem like pretty compelling use cases. reset the whole device being one of them. the specification of a factory-default datastore and then o startup configuration datastore o candiate configuration datastore o running configuration datastore actually sound a bit implementation specific though I recognize that most network operating systems due tend to follow models that at least superficially resembled that. I'm generally sympathetic to the application the draft proposes. > > Joe > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
