Re: [netmod] [Netconf] magic leaf 'type' in IETF interfaces

Qin Wu <bill.wu@huawei.com> Thu, 20 December 2018 00:48 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 5F0EF1294D0; Wed, 19 Dec 2018 16:48:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.589
X-Spam-Level:
X-Spam-Status: No, score=-2.589 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, 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 8YhcQZi6V7ZK; Wed, 19 Dec 2018 16:48:53 -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 CB0BD126C01; Wed, 19 Dec 2018 16:48:52 -0800 (PST)
Received: from lhreml706-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id A8AA64D9FC966; Thu, 20 Dec 2018 00:48:45 +0000 (GMT)
Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 20 Dec 2018 00:48:47 +0000
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.172]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0415.000; Thu, 20 Dec 2018 08:48:43 +0800
From: Qin Wu <bill.wu@huawei.com>
To: Jan Lindblad <janl@tail-f.com>, =?gb2312?B?QmFsqKJ6cyBMZW5neWVs?= <balazs.lengyel@ericsson.com>
CC: "netconf@ietf.org" <netconf@ietf.org>, "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: [netmod] [Netconf] magic leaf 'type' in IETF interfaces
Thread-Index: AQHUltbN9lVO78lVgUuAW3HVKNk4taWGzEeA
Date: Thu, 20 Dec 2018 00:48:42 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABA9B1B55C9@nkgeml513-mbx.china.huawei.com>
References: <VI1PR07MB39818BD20967B36B8F24DBA69BA10@VI1PR07MB3981.eurprd07.prod.outlook.com> <20181217.091505.218628572185200621.mbj@tail-f.com> <83b139a1-a0ab-5fbc-f702-7f0d50a46864@ericsson.com> <90DB3C3B-FD52-4903-81B0-93985E6F74FE@tail-f.com>
In-Reply-To: <90DB3C3B-FD52-4903-81B0-93985E6F74FE@tail-f.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_B8F9A780D330094D99AF023C5877DABA9B1B55C9nkgeml513mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/TrMWR6EmUAWnm5xZbDhM1f9lNeQ>
Subject: Re: [netmod] [Netconf] magic leaf 'type' in IETF interfaces
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: Thu, 20 Dec 2018 00:48:56 -0000

Hi:
发件人: netmod [mailto:netmod-bounces@ietf.org] 代表 Jan Lindblad
发送时间: 2018年12月18日 21:37
收件人: Balázs Lengyel
抄送: netconf@ietf.org; netmod@ietf.org
主题: Re: [netmod] [Netconf] magic leaf 'type' in IETF interfaces

Hi,
While I agree with Martin, in our systems we have a number of places, where the system does create configuration in running, due to

  *   different levels of automation and autonomous algorithms kick-in
  *   the created config needs to be possible to be further modified by the operator

  *   the created config needs to be referenced from operator created config
[Qin]: We have a new draft that has just been posted to discuss some of these issues which allow system creation configuration in running
https://tools.ietf.org/html/draft-wu-netconf-nmda-compatibility-00


  *   the created config is not always ephemeral, it might need to be part of backup/restore
This is only a sampling from "the list of excuses". I have heard many more. The road to hell is paved with good intentions, however. If we want to build automation based on sound theory, clearly separating the orders from managers from a system's own operational view is key, IMO. Reliability, security, accountability are growing in importance, and they all play in this direction.

We may not need to standardize rules to outlaw the above; the market will take care of that. What we need to ensure is that it is possible to be standards compliant without having to implement design excuses like these.
      [Qin]: I would support standardizing some of guidance rules or design rules on how to deal with these cases.

Best Regards,
/jan