Re: [netmod] I-D Action: draft-ietf-netmod-factory-default-01.txt
Qin Wu <bill.wu@huawei.com> Tue, 21 May 2019 01:27 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 09DB5120021 for <netmod@ietfa.amsl.com>; Mon, 20 May 2019 18:27:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.19
X-Spam-Level:
X-Spam-Status: No, score=-4.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] 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 DDGU0kFlnm8L for <netmod@ietfa.amsl.com>; Mon, 20 May 2019 18:27:46 -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 746F812001B for <netmod@ietf.org>; Mon, 20 May 2019 18:27:46 -0700 (PDT)
Received: from lhreml706-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 88500FF21A28ECBD1F1B; Tue, 21 May 2019 02:27:44 +0100 (IST)
Received: from lhreml705-chm.china.huawei.com (10.201.108.54) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 21 May 2019 02:27:44 +0100
Received: from lhreml705-chm.china.huawei.com (10.201.108.54) by lhreml705-chm.china.huawei.com (10.201.108.54) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Tue, 21 May 2019 02:27:44 +0100
Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml705-chm.china.huawei.com (10.201.108.54) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1713.5 via Frontend Transport; Tue, 21 May 2019 02:27:43 +0100
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.182]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0415.000; Tue, 21 May 2019 09:27:41 +0800
From: Qin Wu <bill.wu@huawei.com>
To: Kent Watsen <kent+ietf@watsen.net>, 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: AdUPc2PXvXy28ei0TDipRGM8M6juqA==
Date: Tue, 21 May 2019 01:27:41 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABAA493EB8F@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: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABAA493EB8Fnkgeml513mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/---vBqt3u1LUo0G7nanzYTYOAa4>
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: Tue, 21 May 2019 01:27:49 -0000
Thanks Kent, see reply inline. 发件人: netmod [mailto:netmod-bounces@ietf.org] 代表 Kent Watsen 发送时间: 2019年5月20日 21:57 收件人: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> 抄送: netmod@ietf.org 主题: Re: [netmod] I-D Action: draft-ietf-netmod-factory-default-01.txt The <copy-config> value-proposition is limited and not worth special effort to make happen. [Qin]: Okay, based on discussion with Juergen, Andy and Rob, I tend to agree with you. - RFC 6241: augment statements are needed to add to the existing RPCs, so just support <get-config>. - RFC 8040: datastore aren't supported, there's no way to access the "factory-default" datastore. - RFC 8342: Appendix A needs to be observed, which this draft does in its Section 3 (note, a reference to Appendix A should be added here). - RFC 8526's <get-data> and <edit-data> come along for free (though edits would fail due to this new datastore being read-only. Note that RFC 8526 does not define a <copy-data> RFC... - RFC 8527's datastore resource (i.e., /ds/ietf-datastores:operational:factory-default) and all the standard HTTP operations (OPTIONS, HEAD, GET, etc.) come for free but, again, there is no "COPY" operation Just supporting <get-config> (and not <copy-config>) is the most consistent option. [Qin]:Good point, I agree. PS: the "WG Chair" lines should be removed from he YANG module. We don't do that anymore. [Qin]: Okay, fixed in the local copy. Kent // contributor On May 20, 2019, at 6:31 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de<mailto:j.schoenwaelder@jacobs-university.de>> wrote: +1 /js On Mon, May 20, 2019 at 09:53:35AM +0000, Rob Wilton (rwilton) wrote: If the purpose of the extending the copy-config operation to the factory-default datastore is just another generic way to do the factory-reset RPC then I would suggest that we don't modify copy-config as part of this draft. Instead, I think that it would be good to fix this generically (for any datastore) in a future update of NETCONF - I see that you have already raised https://github.com/netconf-wg/netconf-next/issues/2 to track this. In theory, a client could use copy-config in a slightly different way to the factory-reset RPC, i.e., to copy from the factory-default to candidate, then have the client modify the configuration until they are happy with it, before committing it. But I'm not sure that this in the best approach. If I was writing a client, I would choose to code the client to read from the factory-default datastore (if needed), then construct whatever the desired configuration of the device is, before pushing it to device. For me, I think that the most important parts of this draft are being able to read from the factory-default datastore, and having an RPC to reset the device back to the factory-default state. I would probably defer updating copy-config until it can be fixed properly in NETCONF. Thanks, Rob -----Original Message----- From: netmod <netmod-bounces@ietf.org<mailto:netmod-bounces@ietf.org>> On Behalf Of Juergen Schoenwaelder Sent: 20 May 2019 07:20 To: Qin Wu <bill.wu@huawei.com<mailto:bill.wu@huawei.com>> Cc: netmod@ietf.org<mailto:netmod@ietf.org> Subject: Re: [netmod] I-D Action: draft-ietf-netmod-factory-default-01.txt On Mon, May 20, 2019 at 05:57:02AM +0000, Qin Wu wrote: -----邮件原件----- 发件人: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] 发送时间: 2019年5月17日 19:15 收件人: Qin Wu <bill.wu@huawei.com<mailto:bill.wu@huawei.com>> 抄送: netmod@ietf.org<mailto: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. This is not what the text says. And given the parameters of copy-config, it is obvious that you can't copy to multiple datastores. 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. No. You would allow any datastore, not a specific one. 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." You propose to invent another layer of encryption??? /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/> _______________________________________________ netmod mailing list netmod@ietf.org<mailto:netmod@ietf.org> https://www.ietf.org/mailman/listinfo/netmod -- 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/> _______________________________________________ netmod mailing list netmod@ietf.org<mailto:netmod@ietf.org> https://www.ietf.org/mailman/listinfo/netmod
- [netmod] I-D Action: draft-ietf-netmod-factory-de… internet-drafts
- Re: [netmod] I-D Action: draft-ietf-netmod-factor… Qin Wu
- Re: [netmod] I-D Action: draft-ietf-netmod-factor… Juergen Schoenwaelder
- Re: [netmod] I-D Action: draft-ietf-netmod-factor… Andy Bierman
- Re: [netmod] I-D Action: draft-ietf-netmod-factor… Qin Wu
- Re: [netmod] I-D Action: draft-ietf-netmod-factor… Juergen Schoenwaelder
- Re: [netmod] I-D Action: draft-ietf-netmod-factor… Qin Wu
- Re: [netmod] I-D Action: draft-ietf-netmod-factor… Qin Wu
- Re: [netmod] I-D Action: draft-ietf-netmod-factor… Juergen Schoenwaelder
- Re: [netmod] I-D Action: draft-ietf-netmod-factor… Rob Wilton (rwilton)
- Re: [netmod] I-D Action: draft-ietf-netmod-factor… Juergen Schoenwaelder
- Re: [netmod] I-D Action: draft-ietf-netmod-factor… Kent Watsen
- Re: [netmod] I-D Action: draft-ietf-netmod-factor… Qin Wu