Re: [netmod] Adoption poll for draft-wwx-netmod-event-yang-10

Qin Wu <bill.wu@huawei.com> Tue, 22 December 2020 02: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 E98543A0855; Mon, 21 Dec 2020 18:28:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, 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 akprCytLWOnA; Mon, 21 Dec 2020 18:28:24 -0800 (PST)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D9E03A084D; Mon, 21 Dec 2020 18:28:24 -0800 (PST)
Received: from fraeml737-chm.china.huawei.com (unknown [172.18.147.201]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4D0Ktj27xwz67Qhd; Tue, 22 Dec 2020 10:25:17 +0800 (CST)
Received: from fraeml737-chm.china.huawei.com (10.206.15.218) by fraeml737-chm.china.huawei.com (10.206.15.218) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Tue, 22 Dec 2020 03:28:21 +0100
Received: from DGGEML402-HUB.china.huawei.com (10.3.17.38) by fraeml737-chm.china.huawei.com (10.206.15.218) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.2106.2 via Frontend Transport; Tue, 22 Dec 2020 03:28:21 +0100
Received: from DGGEML531-MBS.china.huawei.com ([169.254.5.102]) by DGGEML402-HUB.china.huawei.com ([fe80::fca6:7568:4ee3:c776%31]) with mapi id 14.03.0487.000; Tue, 22 Dec 2020 10:28:19 +0800
From: Qin Wu <bill.wu@huawei.com>
To: "adrian@olddog.co.uk" <adrian@olddog.co.uk>, 'Lou Berger' <lberger@labn.net>, 'NETMOD Group' <netmod@ietf.org>
CC: 'NetMod WG Chairs' <netmod-chairs@ietf.org>
Thread-Topic: [netmod] Adoption poll for draft-wwx-netmod-event-yang-10
Thread-Index: AdbYCha4L5SnbqdVTh63ASjnIzeF2g==
Date: Tue, 22 Dec 2020 02:28:18 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABAADC53745@dggeml531-mbs.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.136.101.103]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/O0bTlwhO6DKT--N4IqpgWYurYr4>
Subject: Re: [netmod] Adoption poll for draft-wwx-netmod-event-yang-10
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, 22 Dec 2020 02:28:27 -0000

Thanks Adrian for valuable comments, see reply inline below.
-----邮件原件-----
发件人: netmod [mailto:netmod-bounces@ietf.org] 代表 Adrian Farrel
发送时间: 2020年12月8日 18:51
收件人: 'Lou Berger' <lberger@labn.net>; 'NETMOD Group' <netmod@ietf.org>
抄送: 'NetMod WG Chairs' <netmod-chairs@ietf.org>
主题: Re: [netmod] Adoption poll for draft-wwx-netmod-event-yang-10

Hi,

I have generally been sceptical about Intention-based network operations within the IETF, and I was ambivalent about this document at the first adoption poll. 

However, I think that some good work has been done since then and the document has reached a level where the WG could adopt it and further refine it. There is clearly a body of people who want to work on it, and it seems to be within the WG scope, so I support adoption.

I also think that splitting this piece off the larger body of Intention-based work is a wise first step.
[Qin]: Thanks ,Agree.

Here are a few comments for the authors based on a quick reading...

Abstract.
I appreciate the brevity of the Abstract, but I don't find it very clear. Specifically, what is "the server" and what role would it play absent this YANG model? Conversely, who/what is delegating some of the network management functions? And lastly, is the choice of which network management functions to delegate well known (I assume it is) or up to an implementation?


[Qin]: Good comment, I think the server is referred to an entity that provides access to YANG-defined data to a client, over some network management protocol. I will quote the terminology defined in RFC7950 for the "server" defined in this document.
The client, more precisely the remote client, i.e., NMS or management system will delegate the network management functions, these network management functions will realize the ECA logic or ECA Policy management. 
The choice of which network management function should be well known, that's why define this model and associated ECA XPath Function Library to make sure
these network management function can be implemented in the standard way or interoperable way.
---

Introduction
The first mention of "ECA" comes in...
   This document defines an ECA Policy management YANG data model.
I think you need to:
- Expand the abbreviation
- Explain in one or two sentences what ECA is
[Qin]: Good suggestion, here is the proposed change:
OLD TEXT:
"
This document defines a YANG data model for Event Condition Action (ECA) policy management.
"
NEW TEXT:
"
Event Condition Action (ECA) provides the structure of active rules in event-driven architecture which exhibits self-management 
properties such as self-configuration, self-healing, self-optimization, and self-protection. This document defines a YANG data 
model for ECA policy management.
"
---

Section 2.1
You need to update to the more recent boilerplate that mentions RFC 8174

[Qin] Good catch, will change the boilerplate and add reference to RFC8174.
---

Section 2.1
You use the term "Event Stream" without defining it
[Qin]: Will reference RFC5277 for event stream definition, thanks.
Cheers,
Adrian

-----Original Message-----
From: netmod <netmod-bounces@ietf.org> On Behalf Of Lou Berger
Sent: 07 December 2020 22:28
To: NETMOD Group <netmod@ietf.org>
Cc: NetMod WG Chairs <netmod-chairs@ietf.org>
Subject: [netmod] Adoption poll for draft-wwx-netmod-event-yang-10

This email begins a 2-week adoption poll for:

https://tools.ietf.org/html/draft-wwx-netmod-event-yang-10

Please voice your support or technical objections on list before the end of December 21, any time zone.

Thank you!

Netmod Chairs

PS Note the IPR poll is running concurrently as the private response all indicated that no IPR exists.  The draft will not be formally adopted until both the IPR and WG polls are complete.


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

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