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

Hi Carl,
I believe that I have addressed your comments on I2NSF Capability Data
Model:
https://tools.ietf.org/html/draft-ietf-i2nsf-capability-data-model-05

If you are satisfied with the revision, could you update the Review result
in the following page?
https://datatracker.ietf.org/doc/review-ietf-i2nsf-capability-data-model-04-yangdoctors-lc-moberg-2019-07-15/

Thanks.

Best Regards,
Paul

On Thu, Jul 25, 2019 at 11:29 PM Mr. Jaehoon Paul Jeong <
jaehoon.paul@gmail.com> wrote:

> 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 <
> noreply@ietf.org> wrote:
>
>> 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 mailing list
>> I2nsf@ietf.org
>> 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: jaehoon.paul@gmail.com, pauljeong@skku.edu
> Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
> <http://cpslab.skku.edu/people-jaehoon-jeong.php>
>

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