[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>