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

Qin Wu <> Wed, 05 December 2018 09:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E1574130DE3 for <>; Wed, 5 Dec 2018 01:25:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sfa1saB6yjhz for <>; Wed, 5 Dec 2018 01:25:45 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6C6F7126BED for <>; Wed, 5 Dec 2018 01:25:45 -0800 (PST)
Received: from (unknown []) by Forcepoint Email with ESMTP id 47A5C865B1D47; Wed, 5 Dec 2018 09:25:40 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 5 Dec 2018 09:25:41 +0000
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1591.10; Wed, 5 Dec 2018 09:25:41 +0000
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1591.10 via Frontend Transport; Wed, 5 Dec 2018 09:25:40 +0000
Received: from ([]) by ([]) with mapi id 14.03.0415.000; Wed, 5 Dec 2018 17:25:37 +0800
From: Qin Wu <>
To: Andy Bierman <>, Netconf <>
Thread-Topic: [Netconf] comments on draft-wu-netconf-restconf-factory-restore-03
Thread-Index: AQHUimld5kZN4e5FPUqSBuroEQ0zmKVv3jzw
Date: Wed, 5 Dec 2018 09:25:38 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA9B17C265nkgeml513mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [Netconf] comments on draft-wu-netconf-restconf-factory-restore-03
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 05 Dec 2018 09:25:48 -0000

Thanks Andy.
This draft has been agreed to move to netmod based on discussion and replaced with
Please see my comments inline below.

发件人: Netconf [] 代表 Andy Bierman
发送时间: 2018年12月3日 2:03
收件人: Netconf
主题: [Netconf] comments on draft-wu-netconf-restconf-factory-restore-03


I have comments and questions on the functional requirements and
scope of the problem(s) to be solved. Scope seem to be:
   G1) reset device to factory config
   G2) set any datastore to contents of the factory config with <copy-config>
            [Qin]: besides <copy-config>, you also can use new operation <reset-datastore> to set it to contents of the factory config.
   G3) retrieve contents of factory-config with <get-data>

Q1) what is the factory datastore?

The concept of a factory default config is universal but the implementation is not.
This needs to be precisely defined in the draft.
[Qin]: Yes, the definition has been provided in section 1.1.If there is any ambiguity, please let us know.

There is actually a factory-startup (--> running) and factory-intended.
By default the factory-startup is likely an empty config (i.e. just the YANG defaults
supported by the server).  The factory-intended is implementation-specific.

So what is standardized? factory-startup or factory-intended? both?

[Qin]: factory config content can be content of <running>,<startup>,<candidate>
As clarified in appendix B:
When the device first boots up, the content of the <startup> and
   <factory-default> will be identical.  The content of <startup> can be
   subsequently changed by using <startup> as a target in a <copy-
   config> operation.  The <factory-default> is a read-only datastore
   and it is usually static as described in earlier sections.

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.

Q3) filtered retrieval of the factory settings

If a real datastore is used as proposed, then is subtree and XPath filtering required?
It seems all operations except edit have to be supported by the server.

[Qin]:we can add subtree and xpath filter if more fine granularity operation is needed to deal with portion config of one datastore.
At the current version, <reset-datastore> is datastore level 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;
[Qin]: Good input, we will how to add this. Thanks.