[Supa] review for draft-ietf-supa-policy-based-management-framework

Johannes Merkle <johannes.merkle@secunet.com> Tue, 20 June 2017 09:32 UTC

Return-Path: <Johannes.Merkle@secunet.com>
X-Original-To: supa@ietfa.amsl.com
Delivered-To: supa@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA2AB131968 for <supa@ietfa.amsl.com>; Tue, 20 Jun 2017 02:32:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 IbaX_uNauYTb for <supa@ietfa.amsl.com>; Tue, 20 Jun 2017 02:32:44 -0700 (PDT)
Received: from a.mx.secunet.com (a.mx.secunet.com [62.96.220.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3972129426 for <supa@ietf.org>; Tue, 20 Jun 2017 02:32:43 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 4950120097; Tue, 20 Jun 2017 11:32:40 +0200 (CEST)
X-Virus-Scanned: by secunet
Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yeAO8CKLfxQ8; Tue, 20 Jun 2017 11:32:37 +0200 (CEST)
Received: from mail-essen-01.secunet.de (mail-essen-01.secunet.de [10.53.40.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a.mx.secunet.com (Postfix) with ESMTPS id D2EFA2008A; Tue, 20 Jun 2017 11:32:37 +0200 (CEST)
Received: from [10.208.1.212] (10.208.1.212) by mail-essen-01.secunet.de (10.53.40.204) with Microsoft SMTP Server (TLS) id 14.3.351.0; Tue, 20 Jun 2017 11:32:37 +0200
From: Johannes Merkle <johannes.merkle@secunet.com>
References: <C9B5F12337F6F841B35C404CF0554ACB8A305BE9@dggeml510-mbx.china.huawei.com> <e21a77b3-72a0-ff14-6875-c3cb5f13edc5@secunet.com> <C9B5F12337F6F841B35C404CF0554ACB8A3071A1@dggeml510-mbx.china.huawei.com>
CC: "Liushucheng (Will Liu)" <liushucheng@huawei.com>
To: supa@ietf.org
Message-ID: <e68fdde6-d94c-83b0-399b-20df8964e88a@secunet.com>
Date: Tue, 20 Jun 2017 11:32:37 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <C9B5F12337F6F841B35C404CF0554ACB8A3071A1@dggeml510-mbx.china.huawei.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
X-Originating-IP: [10.208.1.212]
X-G-Data-MailSecurity-for-Exchange-State: 0
X-G-Data-MailSecurity-for-Exchange-Error: 0
X-G-Data-MailSecurity-for-Exchange-Sender: 23
X-G-Data-MailSecurity-for-Exchange-Server: d65e63f7-5c15-413f-8f63-c0d707471c93
X-EXCLAIMER-MD-CONFIG: 2c86f778-e09b-4440-8b15-867914633a10
X-G-Data-MailSecurity-for-Exchange-Guid: 80831A7B-7785-4BBC-962C-1FBBDAA669FC
Archived-At: <https://mailarchive.ietf.org/arch/msg/supa/Fn8uKd36mPmbpAlhgR7SiNI-vOA>
Subject: [Supa] review for draft-ietf-supa-policy-based-management-framework
X-BeenThere: supa@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." <supa.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/supa>, <mailto:supa-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/supa/>
List-Post: <mailto:supa@ietf.org>
List-Help: <mailto:supa-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/supa>, <mailto:supa-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Jun 2017 09:32:47 -0000

I have conducted a review of draft-ietf-supa-policy-based-management-framework. These are my comments:

- Generally, the specification is very abstract and not easy to understand. For instance, it is not explained, what
exactly the translation of the information models to data models means. Maybe I lack the necessary experience in
the field of network management. I was also surprised that the ID does not define any specific syntax or semantic. For
an ID / RFC, the specification is quite vague and unspecific, and it reads like an introduction.

- Abstract:
YANG data models to encode policy, which will point to
should be
YANG data models to encode policies, which point to
or
YANG data models to encode a policy, which points to

Section 1,

3rd paragraph:
   The GPIM defines concepts and terminology needed by policy management
   independent of the form and content of the policy rule.  The ECA
What does "form" exactly mean here. Syntax? Structure? Encoding?

4th paragraph:
                                                  The GPIM and the EPRIM
   will both be translated into corresponding YANG [RFC6020][RFC6020bis]
   modules that define policy concepts,
I suggest to replace "will" by "can".

                                additional YANG modules may also be
   defined from the GPIM and/or EPRIM to manage specific functions.
I suggest to change "defined" to "derived"

Section 2

General: The following Terms are missing: SUPA, ECA, YANG, EMS, EMS/NMS/Controller, OSS/BSS/Orchestrator

3rd Paragrapgh (GPDM):
  the service(s) to be managed using policy.
should be
  the service(s) to be managed using policies.
or
  the service(s) to be managed using a policy.

Section 3.1:

1st paragraph:
  information (e.g., part of a sentence that was cut out).)
The meaning of "sentence" in this context is not clear to me.

2nd paragraph:
   operator interacts with the interface, which is then translated to
   configuration snippets.
I don't understand. The interface is translated to configuration data?

3rd paragraph:
   Note that YANG models may not exist.
In which context?

7th paragraph (1st paragraph on page 6):
   types of policies: ECA policy rules and declarative policy
   statements.
The distinction between ECA policies and declarative policies is not explained. Furthermore, you could mention already
here, that declarative policies are out-of-scope for this ID.

9th paragraph:
   During the run time, components communicate with the data instances
   for management and monitoring.
I don't understand what you mean by "data instance" and how it could communicate?

Figure 2:
Some spaces are missing: ECAPolicyRule and PolicyRule

Figure 2: OSS/BSS Orchestrator is shown but not listed in the explanation above.

Explanation of Figure 2:

  ECA Policy Rule Information Data Model (EPRIM):
should be
  ECA Policy Rule Information Model (EPRIM):

   Network Service and Resource Data Models: models of the service as
These are not shown in Figure 2.

Below Figure 3:

   Policies are used to control the management of resources and
   services, while data from resources and services are used to select
   and/or modify policies during runtime.
The latter type of interaction should be mentioned in the explanation of the communication (1). Thus
      (1) policy manages and can adjust service behavior as necessary
      (1:1..n)
should be
      (1) policy manages and can adjust service behavior as necessary
      (1:1..n). In addition, data from resources and services are used to select
   and/or modify policies during runtime.


Section 3.3, 1st paragraph:
  ERPIM --> EPRIM


Best regards,
Johannes


Liushucheng (Will Liu) schrieb am 18.05.2017 um 18:10:
> Dear Johannes,
> 
> Thanks for your response. I understand. Actually one of use cases of SUPA is related to SMNP. 
> 
> A normal review will be also helpful. Many thanks!
> 
> Regards,
> Will (Shucheng LIU)
> 
> 
>> -----Original Message-----
>> From: Johannes Merkle [mailto:johannes.merkle@secunet.com]
>> Sent: Thursday, May 18, 2017 6:07 PM
>> To: Liushucheng (Will Liu) <liushucheng@huawei.com>
>> Subject: Re: IETF review
>>
>> Hi Will,
>>
>> I had a quick glance at your draft and see that it deals with network
>> management. I have to confess that I am completely unexperienced in that
>> area. My draft was dealing with authentication methods for SNMP and I was
>> very happy that I didn't have to write anything specific about SNMP, because
>> I wouldn't have been able to. Furthermore, I have not followed the activities
>> of opsawg (except for my draft).
>>
>> Therefore, I con only offer a formal review (language, typos,
>> comprehensibility for non-NM-experts), and I would be happy to do that in
>> the beginning of June. Please indicate, if this is fine for you.
>>
>> Regards,
>> Johannes
>>
>> Liushucheng (Will Liu) schrieb am 16.05.2017 um 17:58:
>>> Hi Johannes,
>>>
>>>
>>>
>>> This is Will, who reviewed your draft
>>> draft-ietf-opsawg-hmac-sha-2-usm-snmp-new
>>> <https://datatracker.ietf.org/doc/draft-ietf-opsawg-hmac-sha-2-usm-
>> snmp-new/>as an OPS area directorate.
>>>
>>> http://www.ietf.org/mail-archive/web/ops-dir/current/msg01694.html
>>>
>>>
>>>
>>> I wonder whether you could do me a favor. One of my drafts is looking
>>> for review before it can be progressed. If you could help, please
>>> review it and post your comments to the mailing list ( supa@ietf.org
>> <mailto:supa@ietf.org> ). Many thanks!
>>>
>>> My draft link:
>>> https://datatracker.ietf.org/doc/draft-ietf-supa-policy-based-manageme
>>> nt-framework/
>>>
>>>
>>>
>>> Regards,
>>>
>>> Will (Shucheng LIU)
>>>
>>
> 
> 


-- 
Mit freundlichen Grüßen,
Dr. Johannes Merkle
Principal
Division Innere Sicherheit
secunet Security Networks AG
Mergenthaler Allee 77
65760 Eschborn
Germany
Telefon +49 201 54 54-3091
Telefax +49 201 54 54-1325
Mobil   +49 175 2224439
johannes.merkle@secunet.com
www.secunet.com