Re: [netmod] Review of draft-wwx-netmod-event-yang-09

Qin Wu <bill.wu@huawei.com> Wed, 26 August 2020 12:54 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 AA9063A0C99 for <netmod@ietfa.amsl.com>; Wed, 26 Aug 2020 05:54:20 -0700 (PDT)
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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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 bTAnP5VhWB2G for <netmod@ietfa.amsl.com>; Wed, 26 Aug 2020 05:54:18 -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 681EB3A0CA2 for <netmod@ietf.org>; Wed, 26 Aug 2020 05:54:18 -0700 (PDT)
Received: from lhreml701-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 1F45D41DB9B0AAADED73 for <netmod@ietf.org>; Wed, 26 Aug 2020 13:54:17 +0100 (IST)
Received: from lhreml701-chm.china.huawei.com (10.201.108.50) by lhreml701-chm.china.huawei.com (10.201.108.50) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Wed, 26 Aug 2020 13:54:16 +0100
Received: from DGGEML401-HUB.china.huawei.com (10.3.17.32) by lhreml701-chm.china.huawei.com (10.201.108.50) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1913.5 via Frontend Transport; Wed, 26 Aug 2020 13:54:16 +0100
Received: from DGGEML511-MBS.china.huawei.com ([169.254.4.157]) by DGGEML401-HUB.china.huawei.com ([fe80::89ed:853e:30a9:2a79%31]) with mapi id 14.03.0487.000; Wed, 26 Aug 2020 20:52:55 +0800
From: Qin Wu <bill.wu@huawei.com>
To: Jonathan Hansford <jonathan@hansfords.net>, "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: [netmod] Review of draft-wwx-netmod-event-yang-09
Thread-Index: AdZ7pfa70TM215BBQuKyqnb0rYAf/A==
Date: Wed, 26 Aug 2020 12:52:54 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABAAD9505B0@dggeml511-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.164.123.226]
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABAAD9505B0dggeml511mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/dW69Mt_sTNaxyyDeVg46JcVv-lQ>
Subject: Re: [netmod] Review of draft-wwx-netmod-event-yang-09
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: Wed, 26 Aug 2020 12:54:21 -0000

Hi, Jonathan:
Thanks for taking stabbing into this draft and have a valuable review on introduction and terminologies we defined and used in this draft.
See reply inline below.
发件人: netmod [mailto:netmod-bounces@ietf.org] 代表 Jonathan Hansford
发送时间: 2020年7月31日 19:29
收件人: netmod@ietf.org
主题: [netmod] Review of draft-wwx-netmod-event-yang-09

Hi,

Most of my comments are editorial and to date only address up to the end of Section 2:

Page 1

   Could the Abstract be simplified to:
      This document defines a YANG data model for Event Condition Action
      (ECA) policy management.  The ECA policy YANG module provides the
      ability to delegate some network management functions to the server
      which can take simple and instant action when a trigger condition on
      the system state is met.
[Qin]: The proposed changes look good, thanks.
Page 3

   1. Introduction

   1st bullet should end in a semi-colon, not a period
[Qi]:Fixed, thanks.
   2nd bullet:
      s/large amount/large amounts
[Qin]:Fixed.
   3rd bullet:
      s/can not/cannot
[Qin]:Accepted.
      s/disconnected from/not connected to
[Qin]:Okay.
   4th bullet:
      s/devices needs/devices need

      s/hundeds/hundreds

      I think a comma after "notifications" would make it easier to parse the sentence which should end in a period, not a semi-colon
[Qin]:Agree, thanks for your good suggestion.
   Either
      s/network management function/the network management function
   Or
      s/network management function/network management functions
[Qin]:I like your second proposed change.
   s/server monitor/server to monitor

   Is it a service or the server that is providing continuous performance monitoring?
[Qin]: I think it is the server, your proposed change looks good.
   s/monitoring and detect defects and failures and/monitoring, detect defects and failures, and
[Qin]:Okay.
   s/a ECA Policy/an ECA Policy
[Qin]:Fixed, thanks.
   The second sentence of the penultimate paragraph on page 3 is too long, confusing and unstructured. It needs re-writing.
[Qin]:Here is the rewriting text:
“
This document defines an ECA Policy management YANG data model. The ECA Policy YANG allows the client to move the network management task to the server,
which provides the ability to control the configurations and monitor state parameters, and take simple and instant action on the server when a trigger condition
on the system state is met.
”
Page 4

   2.1. Terminology

   Might it be worth including definitions from RFC3198 "Terminology for Policy-Based Management" as well, either to explain how this Internet Draft aligns or where it deviates? For example:

   o  Policy Decision Point (PDP)

   o  Policy Enforcement Point (PEP)

   o  provisioned policy

   It seems to me this Internet Draft provides support for provisioned policies where the server is both the PDP and the PEP.
[Qin]: I believe your understanding is correct, we have local PDP within the server.
   Neither "Implicit policy variable" nor "Explicit policy variable" are defined in RFC3460, though it does introduce (but not formally define) the following terms. Be good to properly align with the terms in the RFC:

   o  "Implicit PolicyVariable", "Implicitly bound policy variable" and "Implicitly defined policy variable"

   o  "Explicitly bound policy variable" and "Explicitly defined policy variable"
[Qin]: Agree, but we actually redefine policy variable which doesn’t depend on implicit policy variable or explicit policy variable any, I would rather remove these terms and reference to RFC3460.
   Event: The definition of "Event" is a direct lift from RFC5277, so shouldn't it just be included it in the list of predefined terms? However, it appears the term that is actually used in the Internet Draft is "Notification" (in the definitions of Server Event and Datastore Event) and, since "Event" is such an overloaded term, it may be better to define "Notification".
[Qin]:I think your understanding is correct, we can include them in the predefined terms. I haven’t figured out how to redefine notification, if you have any proposal, please suggest.
   Event Stream is used in this Internet Draft, where "Stream" is defined in RFC5277.

   Condition: s/cause/causes

   Action: s/Updates or invocations/Update or invocation
[Qin]:Okay.
   ECA Event:

      Is something missing in this definition, should there be a period after "processing", or should "Derived" not have a capital "D"?
[Qin]: Not sure why period is needed in this context.
      s/extensible list/an extensible list
[Qin]: Sounds good.
   Datastore Event: s/for a/for which a

   Self Monitoring: I find it confusing that "Self Monitoring" encompasses both monitor and control.
[Qin]: will remove control.
   Self Healing:

      s/discovery, and correction/discovery and correction

      s/actions/Actions

      s/system/the system
[Qin]: Good.
   Policy Variable (PV): It is rather confusing that this Internet Draft both uses the definition of "policy variable" from RFC3460 and has its own definition. Should we just rely on capitalisation to determine which is meant?
[Qin]: See above, I prefer to redefine Policy variable which add dependency to PV in RFC3460.
Jonathan