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?
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:
+-------------+ +-----------+ +-----------+
| <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
--
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
