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

["Mr. Jaehoon Paul Jeong" <[e-mail]>]

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 <
[e-mail]> wrote:

> Reviewer: Carl Moberg
> Review result: Almost Ready
>
> This is my review of the [e-mail] 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:[e-mail]>
>
> NEW:
>      WG Chair: Linda Dunbar
>      <mailto:[e-mail]>
>
> _______________________________________________
> I2nsf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/i2nsf
>


-- 
===========================
Mr. Jaehoon (Paul) Jeong, Ph.D.
Associate Professor
Department of Software
Sungkyunkwan University
Office: [phone]
Email: [e-mail], [e-mail]
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
<http://cpslab.skku.edu/people-jaehoon-jeong.php>