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

Ladislav Lhotka <lhotka@nic.cz> Thu, 28 June 2018 12:37 UTC

Return-Path: <lhotka@nic.cz>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39387130FB7 for <netconf@ietfa.amsl.com>; Thu, 28 Jun 2018 05:37:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Owp0xN63Bdi for <netconf@ietfa.amsl.com>; Thu, 28 Jun 2018 05:37:14 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 9ADB7130FBE for <netconf@ietf.org>; Thu, 28 Jun 2018 05:37:13 -0700 (PDT)
Received: by trail.lhotka.name (Postfix, from userid 109) id E452118202E1; Thu, 28 Jun 2018 14:43:29 +0200 (CEST)
Received: from localhost (unknown [195.113.220.121]) by trail.lhotka.name (Postfix) with ESMTPSA id BD0AE1820051; Thu, 28 Jun 2018 14:43:27 +0200 (CEST)
From: Ladislav Lhotka <lhotka@nic.cz>
To: Qin Wu <bill.wu@huawei.com>, "netconf@ietf.org" <netconf@ietf.org>
In-Reply-To: <B8F9A780D330094D99AF023C5877DABA9AEB9E31@nkgeml513-mbx.china.huawei.com>
References: <B8F9A780D330094D99AF023C5877DABA9AEB9E31@nkgeml513-mbx.china.huawei.com>
Date: Thu, 28 Jun 2018 14:37:50 +0200
Message-ID: <87a7rfjdcx.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/eNwDaJCUF5duDIBDCSpZK8cXMfY>
Subject: Re: [Netconf] I-D Action: draft-wu-netconf-restconf-factory-restore-00.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Jun 2018 12:37:17 -0000

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

Qin Wu <bill.wu@huawei.com> writes:

> 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:i-d-announce-bounces@ietf.org] 代表 internet-drafts@ietf.org
> 发送时间: 2018年6月27日 19:29
> 收件人: i-d-announce@ietf.org
> 主题: 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
> I-D-Announce@ietf.org
> 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
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf

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