Re: [netmod] I-D Action: draft-ietf-netmod-factory-default-01.txt

Qin Wu <bill.wu@huawei.com> Mon, 20 May 2019 05:57 UTC

Return-Path: <bill.wu@huawei.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2837C120090 for <netmod@ietfa.amsl.com>; Sun, 19 May 2019 22:57:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 32am9Kd8gZVM for <netmod@ietfa.amsl.com>; Sun, 19 May 2019 22:57:11 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2549120041 for <netmod@ietf.org>; Sun, 19 May 2019 22:57:10 -0700 (PDT)
Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 5137E7E2FF6564300A9E; Mon, 20 May 2019 06:57:08 +0100 (IST)
Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 20 May 2019 06:57:07 +0100
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.182]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0415.000; Mon, 20 May 2019 13:57:01 +0800
From: Qin Wu <bill.wu@huawei.com>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
CC: "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-factory-default-01.txt
Thread-Index: AdUOwKSkoNULWGbCSDC9QJu82XvZFw==
Date: Mon, 20 May 2019 05:57:02 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABAA4935F8C@nkgeml513-mbx.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.134.31.203]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/p5INDE1KN4TQSqQtshfrytUsrp8>
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-factory-default-01.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 May 2019 05:57:13 -0000

-----邮件原件-----
发件人: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] 
发送时间: 2019年5月17日 19:15
收件人: Qin Wu <bill.wu@huawei.com>
抄送: netmod@ietf.org
主题: Re: [netmod] I-D Action: draft-ietf-netmod-factory-default-01.txt

I think this does not work:

      [...]  For <copy-config> operation,it can be used to copy
      the factory default content to another datastore, however the
      content of the datastore is not propagated automatically to any
      other datastores.

You can't change the way things work. If something is committed to lets say <running>, then this triggers the propagation to <intended> and eventually <operational>. You can't come along and say that copy-config from a particular source stops this.
[Qin]:Automatic propagation we were referred to is that when we have three datastores, let's say datastore A, datastore B, datastore C, one time <copy-config> operation can not copy content of datastore A to datstore B and datastore C at the same time,
But you are right, content of <running> will be automatically propagated to <intended> and <operational>, we will see how to tweak the text.

Is it really useful to expose factory default to copy config? Or said differenlty, would it not make sense to fix copy-config (at some other
place) so that it can generically work with new datastores?
[Qin]: Note that this is just an option feature to <copy-config> to assign one single target datastore with factory default content, I am wondering why it can not be defined in this draft in a more generic way?
Even in RFC6241bis or a separate draft, if you add this feature support to <copy-config>, you will augment <copy-config> in the same way, if my understanding is correct.

   The content of the factory-default datastore is usually not security
   sensitive as it is the same on any device of a certain type.

I am not sure this is true.

For non-trivial devices, the default is likely not static but something that takes into account device features available and the specific hardware configuration present. It is actually somewhat unclear what the factory-default datastore contains; the stuff I can expect to see in <running> after the reset or some static stuff that may be tweaked during the boot process to yield the initial <running>.
Or are we pretending these two are always the same?
[Qin]: We emphasize "usually not", to address your comments, we could add:
"
When its contents are considered sensitive, It is RECOMMENDED that the factory default 
Data is encrypted."

The copyright year needs adjustment. Indentation of the YANG statements should be fixed.
[Qin]: Good catch, will fix this, thanks.
/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/>