Re: [Netconf] I-D Action: draft-wu-netconf-restconf-factory-restore-00.txt

One point to add, we hope to support factory restore without reboot/restart and support factory restore with reboot, two cases,
this make factory restore can be supported in the whole lifetime of the device.

-Qin
-----邮件原件-----
发件人: Netconf [mailto:netconf-bounces@ietf.org] 代表 Qin Wu
发送时间: 2018年6月30日 14:17
收件人: Kent Watsen; Ladislav Lhotka; netconf@ietf.org
主题: Re: [Netconf] I-D Action: draft-wu-netconf-restconf-factory-restore-00.txt

Thanks for Kent for valuable review.
-----邮件原件-----
发件人: Kent Watsen [mailto:kwatsen@juniper.net] 
发送时间: 2018年6月30日 1:43
收件人: Qin Wu; Ladislav Lhotka; netconf@ietf.org
主题: Re: [Netconf] I-D Action: draft-wu-netconf-restconf-factory-restore-00.txt

I think this is a reasonable problem to solve.

I see the draft defining a new datastore called "factory".  As such, I expect it to primarily follow the guidelines defined
here: https://tools.ietf.org/html/rfc8342#appendix-A.

[Qin]:Yes, we hope a subset of all modules can be targeted to factory default datastore.
We hope configure true node in the <operational> can be targeted to factory default datastore.
We may see factory default datastore as special case of startup datastore,
The difference is startup datastore will be updated after running get altered. The the content in the startup datastore will change over time.

I don't believe this this a RESTCONF specific datastore. I'd expect NMDA-aware NETCONF servers to also be able to interact with this datastore.

[Qin]: Tend to agree, Rohi raised similar point on the list.
Yes, NMDA-aware NETCONF servers can take advantage of this new datastore as well.

I don't think there is a need for a factory-restore RPC. I think that the existing NC/RC operations and a "reboot" RPC would be
sufficient. I'm unsure which published RFC defines the "reboot"
RPC, it's possible that none do.

[Qin]: we see existing NC operations are not sufficient to support factory default setting, take copy-config as example, without 
New datastore to be defined for factory default, we can not return target datastore to factory default.
<delete-config> can return the device to factory default setting, but <delete-config> is only applied to startup and not applicable to candidate and running.

For RESTCONF, it doesn't support <delete-config> like operation using HTTP method, it support <copy-config> like operation, i.e., HTTP PUT, but HTTP put
Can not return the device to factory default setting without new factory default datastore.
RESTCONF also lack URL capability. In this draft, we also make an assumption that NETCONF is not supported.

For reboot, we see the example of reboot operation in RFC8040, 
but reboot lacks semantics for factory restore, i.e., restore factory default configuration on the device to the specified
Target datastore.
In some complicated cases, we may need to support system restore, we need to consider to how to restore saved configuration at any checkpoint or at any time on the device to the specified
Target datastore. Reboot doesn't have such semantics. Reboot seems only indicate that the server is restarted, but there is not initial state or configuration that should be loaded into the device.

Kent // contributor 

_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf