Re: [Netconf] comments on draft-wu-netconf-restconf-factory-restore-03

[Juergen Schoenwaelder <[e-mail]>]

On Wed, Dec 05, 2018 at 09:25:38AM +0000, Qin Wu wrote:
> 
> Q2) leaf-list of datastores to reset
> 
> Setting specific datastores to factory default is complex and dangerous.
> It is unlikely a server will support all possible combinations.
> A simple RPC to return the entire server to factory default is much easier to use
> and implement. Vendors can add input parameters to support their variants.
> 
> [Qin]: in most case, we just return entire server to factory default, however for dynamic config, we believe in most case it will be set to empty which is different from other datastore.
> In earlier version, we consider to use choice case, allows default-allow-all case, if this address your comment, we can go with this.
>

I guess I am with Andy here. Let the device decide what it takes to
restart the factory default. If there is a dynamic datastore that
needs to be cleared, the device will do this. Why would a management
application need to know the internals of a reset to factory defaults
operation?

> Q4) why no retrieval without NMDA, factory-default-as-datastore feature?
> 
> [Qin]: talking with Balazs, we think in some cases, <reset-datastore> operation can be used without <factory> datastore.
> 
> It would be useful to know what will happen if <reset-datastore> is invoked
> by retrieving the contents of the factory config. This is not possible if
> the datastore feature is not supported. I suggest another RPC
> 
>    rpc get-factory-defaults {
>       if-feature "not factory-default-as-datastore";
>       output {
>         anydata data;
>       }
>    }

I am generally not a big an of get-* and set-*/edit-* operations that
replicate something for which we already have a solution in place.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://www.jacobs-university.de/>