[I2nsf] Yangdoctors last call review of draft-ietf-i2nsf-capability-data-model-04
Carl Moberg via Datatracker <noreply@ietf.org> Mon, 15 July 2019 22:50 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: i2nsf@ietf.org
Delivered-To: i2nsf@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A6BA4120108; Mon, 15 Jul 2019 15:50:48 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Carl Moberg via Datatracker <noreply@ietf.org>
To: yang-doctors@ietf.org
Cc: i2nsf@ietf.org, draft-ietf-i2nsf-capability-data-model.all@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.98.3
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Carl Moberg <calle@tail-f.com>
Message-ID: <156323104862.27197.7523333169738579602@ietfa.amsl.com>
Date: Mon, 15 Jul 2019 15:50:48 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2nsf/aHagO2zluaGa9rgNQ9FmjyFaYmA>
Subject: [I2nsf] Yangdoctors last call review of draft-ietf-i2nsf-capability-data-model-04
X-BeenThere: i2nsf@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" <i2nsf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2nsf>, <mailto:i2nsf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i2nsf/>
List-Post: <mailto:i2nsf@ietf.org>
List-Help: <mailto:i2nsf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2nsf>, <mailto:i2nsf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Jul 2019 22:50:49 -0000
Reviewer: Carl Moberg Review result: Almost Ready This is my review of the ietf-i2nsf-capability@2019-03-28.yang module as part of draft-ietf-i2nsf-capability-data-model-04. The module cleanly passes validation (i.e. 'pyang --ietf') and I have been able to load it into a NETCONF server and done basic operations on it (add, query for and remove capabilties). I have one high-level concern and a couple of nits. This document defines "a YANG data model for capabilities of various Network Security Functions (NSFs)". After my in initial reading of the draft and I2RS background material I found it hard to understand which of the components in the I2RS reference architecture that would implement the YANG module (i.e. provide NETCONF or RESTCONF protocol implementations). The draft says the following: """ This document provides a data model using YANG [RFC6020][RFC7950] that defines the capabilities of NSFs to centrally manage capabilities of those security devices. The security devices can register their own capabilities into Network Operator Management (Mgmt) Systems (i.e., Security Controllers) with this YANG data model through the registration interface [RFC8329]. """ This seems to point in the direction of the 'Network Operator Managemen (Mgmt) Systems' as the location of the YANG datastore, i.e. where this module would be implemented. My main question then becomes; given the fact that the top-level element of the data model is a container ('nsf') with a set of leaf-lists and containers under it, this model seems to only allow for the registration of one (1) single NSF. This seems to be also supported by the language of the description clauses referencing "network service function" in singular. I would intuitively expect such a registry to be able to store the capabilities of a multitude of NSFs. I would appreciate if the authors could clarify the intent and expected usage of the model based on this question. Given my initial struggles I would suggest adding clearer upfront language on the location of the module and the addition of usage examples of e.g. NSFs registering capability instances to registry. (See https://tools.ietf.org/html/rfc8407#section-3.12). I believe that would provide additional and helpful context to the usage of the model. The following drafts are referenced in 'reference' and 'description' fields in the YANG module, but are missing from the Informative References section of the draft. (See https://tools.ietf.org/html/rfc8407#appendix-A.) - draft-hong-i2nsf-nsf-monitoring-data-model-06 - draft-ietf-i2nsf-capability-04 - draft-dong-i2nsf-asf-config-01 The modules consistently seem to spell out 'capabilities', but shorten 'capability' to 'capa', e.g.: +--rw condition-capabilities | +--rw generic-nsf-capabilities | | +--rw ipv4-capa* identityref I would suggest following https://tools.ietf.org/html/rfc8407#section-4.3.1 and spell out 'capability' unless the authors are of the opinion that 'capa' is a well known abbreviation. Remove the following references (they're not used): [RFC6087] Bierman, A., "Guidelines for Authors and Reviewers of YANG Data Model Documents", RFC 6087, DOI 10.17487/RFC6087, January 2011, <https://www.rfc-editor.org/info/rfc6087>. [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, <https://www.rfc-editor.org/info/rfc6991>. The format used to reference drafts vary in format, some use the 'ietf-draft' prefix in the reference (e.g. '[draft-ietf-i2nsf-sdn-ipsec-flow-protection]') and some don't (e.g. '[i2nsf-advanced-nsf-dm]') Oh. and it looks like the email address of the WG Chair (no less! :-) is spelled incorrectly: OLD: WG Chair: Linda Dunbar <mailto:Linda.duhbar@huawei.com> NEW: WG Chair: Linda Dunbar <mailto:Linda.dunbar@huawei.com>
- [I2nsf] Yangdoctors last call review of draft-iet… Carl Moberg via Datatracker
- Re: [I2nsf] [yang-doctors] Yangdoctors last call … Mahesh Jethanandani
- Re: [I2nsf] Yangdoctors last call review of draft… Mr. Jaehoon Paul Jeong
- Re: [I2nsf] Yangdoctors last call review of draft… Mr. Jaehoon Paul Jeong
- Re: [I2nsf] Yangdoctors last call review of draft… Mr. Jaehoon Paul Jeong
- Re: [I2nsf] [yang-doctors] Yangdoctors last call … Carl Moberg
- Re: [I2nsf] [yang-doctors] Yangdoctors last call … Mr. Jaehoon Paul Jeong