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 >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
