On 3/26/19 17:04, Alex Campbell wrote: > 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?
Again, this is likely vendor-dependent. I was thinking of additional system datastores that would also need to be reset to default for a full device reset. This is why I like the "reset-device" RPC, which would take care of any such DS. As a concrete example, Cisco switches have a vlan.dat file that is not part of <running> or <startup> that would need to be reset to factory to fully reset the device. Joe > > 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
