Re: [netmod] [netconf] WG Last Call: draft-ietf-netmod-factory-default-05

Qin Wu <bill.wu@huawei.com> Tue, 19 November 2019 06:41 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 306E3120876; Mon, 18 Nov 2019 22:41:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 epXMXGqHQUbM; Mon, 18 Nov 2019 22:41:36 -0800 (PST)
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 CF71B1200A4; Mon, 18 Nov 2019 22:41:35 -0800 (PST)
Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 7D75D2283A719A922D31; Tue, 19 Nov 2019 06:41:32 +0000 (GMT)
Received: from lhreml713-chm.china.huawei.com (10.201.108.64) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 19 Nov 2019 06:41:32 +0000
Received: from lhreml713-chm.china.huawei.com (10.201.108.64) by lhreml713-chm.china.huawei.com (10.201.108.64) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Tue, 19 Nov 2019 06:41:31 +0000
Received: from DGGEML406-HUB.china.huawei.com (10.3.17.50) by lhreml713-chm.china.huawei.com (10.201.108.64) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1713.5 via Frontend Transport; Tue, 19 Nov 2019 06:41:31 +0000
Received: from DGGEML511-MBX.china.huawei.com ([169.254.1.41]) by dggeml406-hub.china.huawei.com ([10.3.17.50]) with mapi id 14.03.0439.000; Tue, 19 Nov 2019 14:41:28 +0800
From: Qin Wu <bill.wu@huawei.com>
To: "Joe Clarke (jclarke)" <jclarke@cisco.com>
CC: Kent Watsen <kent+ietf@watsen.net>, "netmod@ietf.org" <netmod@ietf.org>, "draft-ietf-netmod-factory-default@ietf.org" <draft-ietf-netmod-factory-default@ietf.org>
Thread-Topic: [netmod] [netconf] WG Last Call: draft-ietf-netmod-factory-default-05
Thread-Index: AdWd0qXxZf7a+zyeQkaNUTFpf5/BMQ==
Date: Tue, 19 Nov 2019 06:41:27 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABAA945C44C@dggeml511-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.52.33.50]
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABAA945C44Cdggeml511mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/9LPrqA_rlQ6WIVSo-2MhimRDaaU>
Subject: Re: [netmod] [netconf] WG Last Call: draft-ietf-netmod-factory-default-05
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, 19 Nov 2019 06:41:41 -0000

发件人: Joe Clarke (jclarke) [mailto:jclarke@cisco.com]
发送时间: 2019年11月18日 8:31
收件人: Qin Wu <bill.wu@huawei.com>
抄送: Kent Watsen <kent+ietf@watsen.net>et>; netmod@ietf.org; draft-ietf-netmod-factory-default@ietf.org
主题: Re: [netmod] [netconf] WG Last Call: draft-ietf-netmod-factory-default-05


On Nov 17, 2019, at 10:29, Qin Wu <bill.wu@huawei.com<mailto:bill.wu@huawei.com>> wrote:

Done, Kent.
https://datatracker.ietf.org/doc/draft-ietf-netmod-factory-default/?include_text=1
Thanks for follow up.

Hey, Qin.  I see you removed the ZTP reference.  I saw the conversation, and you still have the text about resetting other processes.  That said, you still have an informative reference to RFC8572.

[Qin]: Yes, resetting processes or restarting node did cover ZTP part, from Martin’s comment, I feel we don’t need to tie resetting process with RFC8572, since RFC8572 actually focuses on SZTP.
Actually we may have a lot of legacy ZTP mechanism we can leverage, I am not sure which reference I should stick to. Make sense?

More importantly, though, how do you see this practically being implemented?  With an ops dir hat, I’m walking through Section 2, and sending a factory-reset RPC to a device.  The device immediately resets <running> to default and <operational> to some similar default state.  The device has become unreachable within the network.  A reboot or other reset is optional to implement, so as an operator I’m not really sure what to expect at this point.

[Qin]:I am not sure we should make restart or reboot as mandatory after factory-reset rpc, I think factory-reset rpc affects kernel level, it will be good not to restart the node, if it touches hardware level, it is be important to reboot or restart the node. Another angle we can have is if factory-reset rpc is executed in the trust environment, it may be not necessary to restart the node or root.

Typically (well, at least for me), I’m either going to do a factory reset today through the console (if I’m going to RMA or otherwise decommission the device) in which case I don’t care if it’s reachable on the network; or I use a remote “write erase” then reload to prepare the device for a re-bootstrap.  For this latter use case I see the RPC being valuable, but I’d need to know that the device will reload or otherwise re-prepare itself for bootstrapping.  In a multi-vendor environment some consistency there would be useful.

I would think that practically an implementor would reboot the device after receiving and executing this RPC?  I admit that perhaps in virtual cases, a reload may not be required, but I wonder if some operational considerations are needed to let vendors know how best to go about implementing this for best results.
[Qin]: See above, may close to the example you raised above, let me know if you want to add some text in security section or somewhere else to address your comments. The proposal is appreciated.

Joe




-Qin
发件人: Kent Watsen [mailto:kent+ietf@watsen.net]
发送时间: 2019年11月16日 5:16
收件人: netmod@ietf.org<mailto:netmod@ietf.org>
抄送: draft-ietf-netmod-factory-default@ietf.org<mailto:draft-ietf-netmod-factory-default@ietf.org>
主题: Re: [netconf] WG Last Call: draft-ietf-netmod-factory-default-05


Today ends the two-week Last Call, which passed.  Thank you everyone who participated.

Qin, I'll start the shepherd writeup after -07 has been posted addressing the Last Call comments.

Kent // shepherd





On Nov 1, 2019, at 10:57 AM, Kent Watsen <kent+ietf@watsen.net<mailto:kent+ietf@watsen.net>> wrote:

This begins a two-week Working Group Last Call (WGLC) on draft-ietf-netmod-factory-default-05.  The WGLC ends on Nov 15 (two days before the NETMOD 106 session).  Please send your comments to the working group mailing list.

Positive comments, e.g., "I've reviewed this document and believe it is ready for publication", are welcome!  This is useful and important, even from authors.  Objections, concerns, and suggestions are also welcomed at this time.

Thank you,
NETMOD Chairs

_______________________________________________
netmod mailing list
netmod@ietf.org<mailto:netmod@ietf.org>
https://www.ietf.org/mailman/listinfo/netmod