On 3/26/19 03:22, Juergen Schoenwaelder wrote: > On Tue, Mar 26, 2019 at 03:12:26AM -0400, Joe Clarke wrote: >> On 3/26/19 01:51, Juergen Schoenwaelder wrote: >>> Qin, >>> >>> the idea should be to make things simpler, not more complex. Perhaps >>> it is not necessary to expose N options to reset a device. Perhaps a >>> simple "factory-reset" RPC which resets all relevant datastores in an >>> implementation specific manner is sufficient. Why expose more details >>> to the management client? >> >> This would certainly make it simpler from the RPC standpoint. However, >> if one can <get-data> from the factory-default DSes, I still think there >> is a need to know what factory-default DS maps to what other DS (in the >> case where there might be multiple that are different). >> > > The notion of multiple factory-default datastores sounds complex. And > what is a management application going to do with them? How would a > management application know which sets of datastores to reset together > in a meaningful way?
This is why I think having a single RPC to "reset the device to factory" makes sense. Not to say that's the only use case, but it would be useful in a number of cases. > > My naive interpretation of the factory default DS (a single one) would > be that it exposes the content you will find in <running> after the > factory-reset has been executed. An extended version of Figure 2 of > RFC 8342 would look like this: Yep, this makes sense. And I fully admit that my use case is likely vendor-specific, but we may not be the only vendor with ancillary datastores that do not look like <running> or <startup>. Joe > > +-------------+ +-----------+ +-----------+ > | <candidate> | | <startup> | | <factory> | > | (ct, rw) |<---+ +--->| (ct, rw) | | (ct, ro) | > +-------------+ | | +-----------+ +-----------+ > | | | | | > | +-----------+ | | > +-------->| <running> |<--------+ | > | (ct, rw) |<----------------------------+ > +-----------+ > > And exposing such a factory default datastore would be optional I > think. > > /js > _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
