On Mon, Mar 25, 2019 at 10:51 PM Juergen Schoenwaelder < [email protected]> 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? > > +1 Some of us have not consumed the NMDA kool-aid ;-) We still manage servers, not datastores. You can reset the server so it comes back with the factory-default config. I have never heard of resetting specific datastores to factory-default. >From the client POV, why would I even want to know the implementation-specific details and have to provide reset contents for each datastore and the order to reset them? No customers are asking for this! /js > Andy > > On Tue, Mar 26, 2019 at 05:25:45AM +0000, Qin Wu wrote: > > Joe, > > > > > > -----邮件原件----- > > 发件人: netmod [mailto:[email protected]] 代表 Joe Clarke > > 发送时间: 2019年3月25日 22:14 > > 收件人: [email protected] > > 主题: [netmod] Question on draft-wu-netmod-factory-default > > > > 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? > > > > [Qin]:We start with a simple case, you case could be addressed by > invoking multiple rpc with each rpc to allow reset a set of datastores. > > 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? > > > > [Qin]: In simple case, target DS will only be reset by a single factory > datastore. If there is a new factory datastore could be derived from that > DS, I think target DS should be changed to reset that new factory datastore. > > > > 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? > > [Qin]: So your point is should we allow multiple source, multiple target > in the same RPC, will think it over. Thanks. > > 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 > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 <https://www.jacobs-university.de/> > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
