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

From: Qin Wu <[email-masked]>
Date: Thu, 28 Jun 2018 03:11:18 +0000

Hi, All:
We submit a new I-D to discuss "Factory default Setting Capability for RESTCONF"
https://tools.ietf.org/html/draft-wu-netconf-restconf-factory-restore-00
The abstract:
   This document defines capability based extension to RESTCONF protocol
   that allows RESTCONF client to configure newly deployed devices with
   just its preconfigured initial state (i.e., factory default settings)
   during zero touch bootstrapping process or restore the configuration
   to its preconfigured initial state or system restore point either
   during device rooting process or at the time of system fatal error or
   malfunction.
Your comments and suggestions are welcome.

-Qin
-----邮件原件-----
发件人: I-D-Announce [mailto:[email-masked]] 代表 [email-masked]
发送时间: 2018年6月27日 19:29
收件人: [email-masked]
主题: I-D Action: draft-wu-netconf-restconf-factory-restore-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

        Title           : Factory default Setting Capability for RESTCONF
        Authors         : Qin Wu
                          Ye Niu
	Filename        : draft-wu-netconf-restconf-factory-restore-00.txt
	Pages           : 11
	Date            : 2018-06-27

Abstract:
   This document defines capability based extension to RESTCONF protocol
   that allows RESTCONF client to configure newly deployed devices with
   just its preconfigured initial state (i.e., factory default settings)
   during zero touch bootstrapping process or restore the configuration
   to its preconfigured initial state or system restore point either
   during device rooting process or at the time of system fatal error or
   malfunction.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-wu-netconf-restconf-factory-restore/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-wu-netconf-restconf-factory-restore-00
https://datatracker.ietf.org/doc/html/draft-wu-netconf-restconf-factory-restore-00

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Rohit R Ranade <[email-masked]>
Date: Thu, 28 Jun 2018 05:16:28 +0000

Hi Wuqin,

Some initial comments.

1.  I feel it is better if all the datastores used for source / target should be datastore-ref used from ietf-datastore module
2.  I think the factory-restore may be helpful for the ephemeral data-stores, if they want to revert the configurations (without a reboot).
3.  ietf-restconf-restore why is it a RESTCONF module... Why any other protocol cannot use it ?
4.  RPC names factory-recovery vs factory-restore , which is correct ?
5.  Section 1
 "especially when the RESTCONF server is implemented in a
   device that does not have NETCONF support."
   ==> Better to add that Section 8.7.5.1 of RFC 6241 provides a mechanism to reset to factory defaults. 
   Else users may not know why it is OK, if NETCONF is supported.

With Regards,
Rohit R Ranade

-----Original Message-----
From: Netconf [mailto:[email-masked]] On Behalf Of Qin Wu
Sent: 28 June 2018 08:41
To: [email-masked]
Subject: Re: [Netconf] I-D Action: draft-wu-netconf-restconf-factory-restore-00.txt

Hi, All:

-Qin
-----邮件原件-----
发件人: I-D-Announce [mailto:[email-masked]] 代表 [email-masked]
发送时间: 2018年6月27日 19:29
收件人: [email-masked]
主题: I-D Action: draft-wu-netconf-restconf-factory-restore-00.txt

Abstract:

Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: Qin Wu <[email-masked]>
Date: Thu, 28 Jun 2018 09:42:20 +0000

Thanks Rohit for valuable review.
Please see my reply inline.

-Qin
-----邮件原件-----
发件人: Rohit R Ranade 
发送时间: 2018年6月28日 13:16
收件人: Qin Wu; [email-masked]
主题: RE: I-D Action: draft-wu-netconf-restconf-factory-restore-00.txt

Hi Wuqin,

Some initial comments.

1.  I feel it is better if all the datastores used for source / target should be datastore-ref used from ietf-datastore module 
[Qin]: Sounds good point, but the datastores used for source / target aligns with ones defined in RFC6241, shall we align with RFC6241 or RFC8342?

2.  I think the factory-restore may be helpful for the ephemeral data-stores, if they want to revert the configurations (without a reboot).
[Qin]: Yes, factory-restore operation can help ephemeral datastore to revert the configuration to factory default setting without reboot or restart.
We can add ephemeral as target in the model.

3.  ietf-restconf-restore why is it a RESTCONF module... Why any other protocol cannot use it ?
[Qin]: Good point, it is also applicable to NETCONF or others, maybe we should change module name into ietf-factory-restore.
NETCONF has already defined <delete-config> and can use <delete-config> to return 
The device to factory defaults, but <delete-config> is only applicable to <startup>.

4.  RPC names factory-recovery vs factory-restore , which is correct ?
[Qin]:Good catch, we will fix this terminology inconsistency issue.

5.  Section 1
[Qin]: Good point and will clarify this in the next version.

With Regards,
Rohit R Ranade

-----Original Message-----
From: Netconf [mailto:[email-masked]] On Behalf Of Qin Wu
Sent: 28 June 2018 08:41
To: [email-masked]
Subject: Re: [Netconf] I-D Action: draft-wu-netconf-restconf-factory-restore-00.txt

Hi, All:

-Qin
-----邮件原件-----
发件人: I-D-Announce [mailto:[email-masked]] 代表 [email-masked]
发送时间: 2018年6月27日 19:29
收件人: [email-masked]
主题: I-D Action: draft-wu-netconf-restconf-factory-restore-00.txt

Abstract:

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 28 Jun 2018 12:05:59 +0200

> We can add ephemeral as target in the model.

There is no defined ephemeral datastore. If you use datastore-ref, the
issue is likely resolved and also future proof.

/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/>

---

From: Qin Wu <[email-masked]>
Date: Thu, 28 Jun 2018 11:16:48 +0000

-----邮件原件-----
发件人: Juergen Schoenwaelder [mailto:[email-masked]] 
发送时间: 2018年6月28日 18:06
收件人: Qin Wu
抄送: Rohit R Ranade; [email-masked]
主题: Re: [Netconf] I-D Action: draft-wu-netconf-restconf-factory-restore-00.txt

On Thu, Jun 28, 2018 at 09:42:20AM +0000, Qin Wu wrote:
> 
> 1.  I feel it is better if all the datastores used for source / target 
> should be datastore-ref used from ietf-datastore module

There is no defined ephemeral datastore. If you use datastore-ref, the issue is likely resolved and also future proof.

[Qin]: Sounds good suggestion, we will see how to use datastore-ref in the next version.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 28 Jun 2018 14:37:50 +0200

Hi,

I have a couple of additional comments:

I have an intuitive idea of what factory default configuration is, and
many devices offer means for activating it. I see it as a useful
addition to enable RESTCONF clients to activate it, if the device
supports such a function.

However, I don't understand this text in sec. 2.1:

   The factory default setting datastore assumes the place of the
   datastore resource as defined in [RFC8040] Section 3.4.  This means
   that the entire datastore resources inside the "{+restconf}/data"
   subtree correspond to data instances in the factory default setting
   datastore.  Therefore, the contents of the factory default setting
   datastore can be retrieved by means of the GET method as specified in
   [RFC8040] and but can not be modified by means of PUT methods as
   specified in [RFC8040].

This looks like the factory default datastore is what the RESTCONF
client edits, which makes no sense to me.

In fact, this paragraph is almost literally copied from
draft-lhotka-netconf-restconf-transactions-00. In my draft, though, it
is intentional that the user's staging datastore appears exactly as the
"unified" datastore in RESTCONF. It is IMO not the case in your draft.

If the factory default configuration is made accessible to the RESTCONF
client (which is definitely useful), it should be a read-only datastore,
and the resource representing it should be something like

    {+restconf}/ds/ietf-restconf-restore:factory-default

Section 2 says:

   A RESTCONF server implementing this document ... is implemented in a
   device that does not have a NETCONF server [RFC8040].

On the other hand, the descriptions of all features defined in the YANG
module require each feature to be set if it corresponding NETCONF
capability is advertised. This seems contradictory to the above
statement.

Thanks, Lada

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

---

From: Qin Wu <[email-masked]>
Date: Fri, 29 Jun 2018 01:39:27 +0000

Hi, Lada:
-----邮件原件-----
发件人: Ladislav Lhotka [mailto:[email-masked]] 
发送时间: 2018年6月28日 20:38
收件人: Qin Wu; [email-masked]
主题: Re: [Netconf] I-D Action: draft-wu-netconf-restconf-factory-restore-00.txt

Hi,

I have an intuitive idea of what factory default configuration is, and many devices offer means for activating it. I see it as a useful addition to enable RESTCONF clients to activate it, if the device supports such a function.

This looks like the factory default datastore is what the RESTCONF client edits, which makes no sense to me.

In fact, this paragraph is almost literally copied from draft-lhotka-netconf-restconf-transactions-00. In my draft, though, it is intentional that the user's staging datastore appears exactly as the "unified" datastore in RESTCONF. It is IMO not the case in your draft.

If the factory default configuration is made accessible to the RESTCONF client (which is definitely useful), it should be a read-only datastore, and the resource representing it should be something like

[Qin]: Good comment, combining with Jurgen and Rohi's comments, here is the proposed change to section 2.1
"
2.1.  The factory default Datastore Resource

   This document introduces a new datastore resource named 'Factory default setting' that represents datastore 
   with its preconfigured initial state. This datastore resource is available using the following resource path:

   {+restconf}/ds/ietf-restconf-restore:factory-default
   'ietf-restconf-restore:factory-default' path component is encoded as an "identity" according to the JSON encoding 
   rules for identities, defined in Section 4 of [RFC7951].  Such an identity MUST be derived from the "datastore" identity 
   defined in the "ietf-datastores" YANG module [RFC8342].

   When the factory default configuration is made accessible to the RESTCONF client The Factory default datastore is essentially
   a read only datastore.
"

Section 2 says:

On the other hand, the descriptions of all features defined in the YANG module require each feature to be set if it corresponding NETCONF capability is advertised. This seems contradictory to the above statement.

[Qin]: Good catch, will fix this. Thanks.

Thanks, Lada

Qin Wu <[email-masked]> writes:

> Internet-Draft directories: http://www.ietf.org/shadow.html or 
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Kent Watsen <[email-masked]>
Date: Fri, 29 Jun 2018 17:43:27 +0000

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.

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.

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.

Kent // contributor

---

From: Qin Wu <[email-masked]>
Date: Sat, 30 Jun 2018 06:16:52 +0000

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

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

---

From: Qin Wu <[email-masked]>
Date: Sat, 30 Jun 2018 07:05:23 +0000

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

-----邮件原件-----
发件人: Kent Watsen [mailto:[email-masked]] 
发送时间: 2018年6月30日 1:43
收件人: Qin Wu; Ladislav Lhotka; [email-masked]
主题: Re: [Netconf] I-D Action: draft-wu-netconf-restconf-factory-restore-00.txt

Kent // contributor

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 30 Jun 2018 11:08:08 +0200

On Sat, Jun 30, 2018 at 07:05:23AM +0000, Qin Wu wrote:

> One point to add, we hope to support factory restore without
> reboot/restart and support factory restore with reboot, two cases,

So is the <factory> datastore conceptually copied into <startup> and
then you restart or is the the <factory> datastore conceptually copied
into <running>? Yes, <startup> is not mandatory to have, so there may
be multiple conceptual flows that are possible. I think it will be
helpful to be clear about the conceptual dataflow between the
datastores - and once this is clear, it should be relatively easy to
define the operations that are necessary.

/js