Subject: [I2nsf] Yangdoctors last call review of draft-ietf-i2nsf-capability-data-model-04

From: Carl Moberg via Datatracker <[email-masked]>
Date: Mon, 15 Jul 2019 15:50:48 -0700

Reviewer: Carl Moberg
Review result: Almost Ready

This is my review of the [email-masked] 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:[email-masked]>

NEW:
     WG Chair: Linda Dunbar
     <mailto:[email-masked]>

---

From: Mahesh Jethanandani <[email-masked]>
Date: Mon, 15 Jul 2019 17:11:03 -0700

> On Jul 15, 2019, at 3:50 PM, Carl Moberg via Datatracker <[email-masked]> wrote:
> 
>     <mailto:[email-masked] <mailto:[email-masked]>>
> 
> NEW:
>     WG Chair: Linda Dunbar
>     <mailto:[email-masked] <mailto:[email-masked]>>

Which according to RFC 8407, Section 4.8 should not even be included.

Mahesh Jethanandani
[email-masked]

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Thu, 25 Jul 2019 10:29:47 -0400

Hi Carl,
Here is the revision letter for the revised draft, reflecting your comments
along with the revised draft:
https://tools.ietf.org/html/draft-ietf-i2nsf-capability-data-model-05

This revision letter first addresses the comments from Acee and then
addresses your comments from page 6.

If you have further comments and questions, please let me know.

Thanks.

Best Regards,
Paul

On Mon, Jul 15, 2019 at 6:50 PM Carl Moberg via Datatracker <
[email-masked]> wrote:

> I would suggest following
> https://tools.ietf.org/html/rfc8407#section-4.3.1 and
> prefix in the reference (e.g.
> '[draft-ietf-i2nsf-sdn-ipsec-flow-protection]')
> _______________________________________________
> I2nsf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2nsf
>

-- 
===========================
Mr. Jaehoon (Paul) Jeong, Ph.D.
Associate Professor
Department of Software
Sungkyunkwan University
Office: +82-31-299-4957
Email: [email-masked], [email-masked]
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
<http://cpslab.skku.edu/people-jaehoon-jeong.php>