Re: [netmod] New Version Notification for draft-wu-netmod-factory-default-01.txt

Qin Wu <bill.wu@huawei.com> Mon, 22 October 2018 12:28 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 C6D76130DFB for <netmod@ietfa.amsl.com>; Mon, 22 Oct 2018 05:28:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.59
X-Spam-Level:
X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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 fXY4ThuyrBwA for <netmod@ietfa.amsl.com>; Mon, 22 Oct 2018 05:28:08 -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 5301B130E05 for <netmod@ietf.org>; Mon, 22 Oct 2018 05:28:08 -0700 (PDT)
Received: from LHREML710-CAH.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id E77DC1692C5FB; Mon, 22 Oct 2018 13:28:03 +0100 (IST)
Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 22 Oct 2018 13:28:04 +0100
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.10]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0415.000; Mon, 22 Oct 2018 20:27:52 +0800
From: Qin Wu <bill.wu@huawei.com>
To: Rohit R Ranade <rohitrranade@huawei.com>, =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= <balazs.lengyel@ericsson.com>, "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: New Version Notification for draft-wu-netmod-factory-default-01.txt
Thread-Index: AQHUZ6d7+UoVtpxo7UuDBzpJ3BD45aUl/ikAgAQ0ZICAAKK+MP//q34AgACz8yA=
Date: Mon, 22 Oct 2018 12:27:52 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABA9B0BAD6B@nkgeml513-mbx.china.huawei.com>
References: <153995220514.31757.7726020817648103034.idtracker@ietfa.amsl.com> <a4eb1ee1-3bad-5035-705f-df1b0b4ead0e@ericsson.com> <991B70D8B4112A4699D5C00DDBBF878A6BC6988F@dggeml510-mbx.china.huawei.com> <B8F9A780D330094D99AF023C5877DABA9B0B9095@nkgeml513-mbx.china.huawei.com> <991B70D8B4112A4699D5C00DDBBF878A6BC69A29@dggeml510-mbx.china.huawei.com>
In-Reply-To: <991B70D8B4112A4699D5C00DDBBF878A6BC69A29@dggeml510-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.138.33.244]
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA9B0BAD6Bnkgeml513mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/dn_vA7EingPeYlZLXDqHBuRY_64>
Subject: Re: [netmod] New Version Notification for draft-wu-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, 22 Oct 2018 12:28:12 -0000

发件人: Rohit R Ranade
发送时间: 2018年10月22日 17:39
收件人: Qin Wu; Balázs Lengyel; netmod@ietf.org
主题: RE: New Version Notification for draft-wu-netmod-factory-default-01.txt


6.       Since we have scenario of copy to multiple targets, whether we can add a leaf called the error-option with possible values of “stop-on-error/continue-on-error/rollback-on-error”   ?

   [Qin]: Same as above. Should these error-option values be part of rpc-reply or part of operation request? By reading edit-config,it is also not clear to me whether

       Error-option should be part of edit-config operation that is sent in rpc-request message.


[Rohit] <error-option> is an input to the edit-config rpc-request.   So I suggested to have a similar approach. But this multi-datastore copy will be tricky because if we give two targets say <running> / <startup> and if after copy to <running>, copy to <startup> fails,  then how to handle this ?  Revert <running> config ?

[Qin]: Understand your concern, but I think the new operation can be handled in the same way as <discard-changes> in RFC6241, I see no error handling to be specified for <discard-changes>.
In addition, rpc-reply can be used to carry these error-option information and indicate failure reason.

With Regards,
Rohit R


From: Qin Wu
Sent: 22 October 2018 12:25
To: Rohit R Ranade <rohitrranade@huawei.com<mailto:rohitrranade@huawei.com>>; Balázs Lengyel <balazs.lengyel@ericsson.com<mailto:balazs.lengyel@ericsson.com>>; netmod@ietf.org<mailto:netmod@ietf.org>
Subject: RE: New Version Notification for draft-wu-netmod-factory-default-01.txt

Thanks Rohit, see reply inline below.

发件人: netmod [mailto:netmod-bounces@ietf.org] 代表 Rohit R Ranade
发送时间: 2018年10月22日 12:59
收件人: Balázs Lengyel; netmod@ietf.org<mailto:netmod@ietf.org>
主题: Re: [netmod] New Version Notification for draft-wu-netmod-factory-default-01.txt

Some suggestions,



1.       In YANG module, the identity has name as “factory-default”, but many places  the name "factory-default-running" is used. I suggest we used “factory-default”in all places.

[Qin]: works for me.

2.       This YANG module is importing ietf-netconf module. I suggest that this import should be removed as this module should not have dependencies on NETCONF.

[Qin]: Good catch, thanks.

3.       The description of this YANG module, still has the reference to <copy-config>.  Whether this can be removed ?

[Qin]: Good catch, thanks.

4.       The description of the indentity “factory-default”, suggest to describe the identity rather than tell “how” it can be used.

[Qin]: Okay.

5.       Whether we can also add the statement that if the “target-datastore”, have been locked , then the reset-datastore will fail with the <error-tag> value as “in-use” ?

[Qin]: I think we can reuse <error-tag> in the rpc-error element, similar to example in section 7.5 of RFC6241.

6.       Since we have scenario of copy to multiple targets, whether we can add a leaf called the error-option with possible values of “stop-on-error/continue-on-error/rollback-on-error”   ?

   [Qin]: Same as above. Should these error-option values be part of rpc-reply or part of operation request? By reading edit-config,it is also not clear to me whether

       Error-option should be part of edit-config operation that is sent in rpc-request message.

With Regards,

Rohit R

From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Balázs Lengyel
Sent: 19 October 2018 18:17
To: netmod@ietf.org<mailto:netmod@ietf.org>
Subject: [netmod] Fwd: New Version Notification for draft-wu-netmod-factory-default-01.txt


Hello,

A new version of I-D, draft-wu-netmod-factory-default-01.txt has been uploaded. Changes include:
Removed impacts to <copy-config> as the reset-datastore  RPC can anyway do the same thing.
Explained the difference between startup and factory-default datastores
Small corrections.

regards Balazs

-------- Forwarded Message --------
Subject:

New Version Notification for draft-wu-netmod-factory-default-01.txt

Date:

Fri, 19 Oct 2018 05:30:05 -0700

From:

internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>

To:

Ye Niu <niuye@huawei.com><mailto:niuye@huawei.com>, Qin Wu <bill.wu@huawei.com><mailto:bill.wu@huawei.com>, Balazs Lengyel <balazs.lengyel@ericsson.com><mailto:balazs.lengyel@ericsson.com>




A new version of I-D, draft-wu-netmod-factory-default-01.txt
has been successfully submitted by Balazs Lengyel and posted to the
IETF repository.

Name: draft-wu-netmod-factory-default
Revision: 01
Title: Factory default Setting
Document date: 2018-10-19
Group: Individual Submission
Pages: 10
URL: https://www.ietf.org/internet-drafts/draft-wu-netmod-factory-default-01.txt
Status: https://datatracker.ietf.org/doc/draft-wu-netmod-factory-default/
Htmlized: https://tools.ietf.org/html/draft-wu-netmod-factory-default-01
Htmlized: https://datatracker.ietf.org/doc/html/draft-wu-netmod-factory-default
Diff: https://www.ietf.org/rfcdiff?url2=draft-wu-netmod-factory-default-01

Abstract:
This document defines a method to reset a YANG datastore to its
factory-default content. The reset operation may be used e.g. during
initial zero-touch configuration or when the existing configuration
has major errors, so re-starting the configuration process from
scratch is the best option.

A new reset-datastore RPC is defined. Several methods of documenting
the factory-default content are specified.

Optionally a new "factory-default-running" read-only datastore is
defined, that contains the data that will be copied over to the
running datastore at reset.



Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

--

Balazs Lengyel                       Ericsson Hungary Ltd.

Senior Specialist

Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com<mailto:Balazs.Lengyel@ericsson.com>