Re: [netmod] New Version Notification for draft-ietf-netmod-factory-default-04.txt

Qin Wu <bill.wu@huawei.com> Tue, 29 October 2019 03:02 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 15EF3120047 for <netmod@ietfa.amsl.com>; Mon, 28 Oct 2019 20:02:11 -0700 (PDT)
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 q-J-ACoa3uHT for <netmod@ietfa.amsl.com>; Mon, 28 Oct 2019 20:02:09 -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 E26EE120046 for <netmod@ietf.org>; Mon, 28 Oct 2019 20:02:08 -0700 (PDT)
Received: from LHREML712-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 380B1CF4EC0E9FC780AB for <netmod@ietf.org>; Tue, 29 Oct 2019 03:02:07 +0000 (GMT)
Received: from lhreml724-chm.china.huawei.com (10.201.108.75) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 29 Oct 2019 03:02:06 +0000
Received: from lhreml724-chm.china.huawei.com (10.201.108.75) by lhreml724-chm.china.huawei.com (10.201.108.75) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Tue, 29 Oct 2019 03:02:06 +0000
Received: from DGGEML402-HUB.china.huawei.com (10.3.17.38) by lhreml724-chm.china.huawei.com (10.201.108.75) 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, 29 Oct 2019 03:02:06 +0000
Received: from DGGEML511-MBX.china.huawei.com ([169.254.1.72]) by DGGEML402-HUB.china.huawei.com ([fe80::fca6:7568:4ee3:c776%31]) with mapi id 14.03.0439.000; Tue, 29 Oct 2019 11:01:59 +0800
From: Qin Wu <bill.wu@huawei.com>
To: Kent Watsen <kent+ietf@watsen.net>, "Joe Clarke (jclarke)" <jclarke@cisco.com>
CC: "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: [netmod] New Version Notification for draft-ietf-netmod-factory-default-04.txt
Thread-Index: AdWOBHnMwp4muW5FRMuCnT9t5WLBTQ==
Date: Tue, 29 Oct 2019 03:01:59 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABAA93B58A9@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.134.31.203]
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABAA93B58A9dggeml511mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/ykLA3Q5YijkUxoZdPKA-2pjEnnw>
Subject: Re: [netmod] New Version Notification for draft-ietf-netmod-factory-default-04.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, 29 Oct 2019 03:02:11 -0000

发件人: Kent Watsen [mailto:kent+ietf@watsen.net]
发送时间: 2019年10月28日 23:55
收件人: Joe Clarke (jclarke) <jclarke@cisco.com>
抄送: Qin Wu <bill.wu@huawei.com>; netmod@ietf.org
主题: Re: [netmod] New Version Notification for draft-ietf-netmod-factory-default-04.txt


Regarding this point:

First, I remember we talked about a reboot operation I think at the last IETF(?).  It was said that perhaps a reboot would happen as part of this RPC because once the <running> datastore is reset to factory-default, the device would not be reachable.  I don’t know where we landed on that.  However, I think some attention should be paid to things like zero-touch provisioning.  If I reset to factory-default, I would expect the device to undergo any out-of-the-box bootstrapping.  Perhaps adding some text that after the RPC is executed, the device SHOULD perform any initial bootstrapping processes?

Perhaps the draft could say something like:

"...resets the configuration to the device's factory default configuration, for the OS version it is running.  For devices supporting zero touch bootstrapping mechanisms, the factory default configuration causes the bootstrapping process to execute."

[Qin]:Thanks Kent, how about the following proposed changes:
OLD TEXT:
“
Section 2

In addition, the "factory-reset" RPC might also be used
   to trigger some other restoring and resetting tasks such as files
   cleanup, restarting the node or some of the software processes,
   setting some security data/passwords to the default value, removing
   logs, or removing any temporary data (from datastore or elsewhere),
   etc.  When and why these tasks are triggered is not the scope of this
   document.
”
NEW TEXT:
“
Section 2



   For the server supporting zero touch bootstrapping mechanisms, the

   factory default configuration causes the bootstrapping process to

   execute, e.g.,the server might reset configuration to device's factory

   default configuration, for the version of operating system software it

   is running.  In addition, the "factory-reset" RPC might also be used

   to trigger some other restoring and resetting tasks such as files

   cleanup, restarting the node or some of the software processes,

   setting some security data/passwords to the default value, removing

   logs, or removing any temporary data (from datastore or elsewhere),

   etc.  When and why these tasks are triggered is not the scope of this
   document.
”
“restarting the node or some of the software processes” description may be a little bit duplicated since
we have already had separate initial bootstrapping process description before the sentence “In addition, the “facory-reret”…”

Kent // contributor