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

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Wed, 6 Nov 2019 10:56:26 +0900

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 <
[email-masked]> 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 <
> [email-masked]> wrote:
>
>> 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]>
>>
>> _______________________________________________
>> 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>
>

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

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Tue, 26 Nov 2019 21:52:06 +0900

Hi Carl,
Did you have a change to check our revision for I2NSF Capability Draft?

Thanks.

Best Regards,
Paul

On Wed, Nov 6, 2019 at 10:56 AM Mr. Jaehoon Paul Jeong <
[email-masked]> wrote:

>>> This is my review of the [email-masked] module
>>> as part
>>> background material I found it hard to understand which of the
>>> components in
>>> 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.

---

From: Carl Moberg <[email-masked]>
Date: Wed, 27 Nov 2019 14:37:09 +0100

Paul,

 Yes! Updated and done.

> On 26 Nov 2019, at 13:52, Mr. Jaehoon Paul Jeong <[email-masked]> wrote:
> 
> Hi Carl,
> On Wed, Nov 6, 2019 at 10:56 AM Mr. Jaehoon Paul Jeong <[email-masked]> wrote:
> Hi Carl,
> I believe that I have addressed your comments on I2NSF Capability Data Model:
> If you are satisfied with the revision, could you update the Review result in the following page?
> On Thu, Jul 25, 2019 at 11:29 PM Mr. Jaehoon Paul Jeong <[email-masked]> wrote:
> Hi Carl,
> Here is the revision letter for the revised draft, reflecting your comments along with the revised draft:
> On Mon, Jul 15, 2019 at 6:50 PM Carl Moberg via Datatracker <[email-masked]> wrote:
> Reviewer: Carl Moberg
> This is my review of the [email-masked] module as part
> 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
> 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
> 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.
> 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
> Given my initial struggles I would suggest adding clearer upfront language on
> https://tools.ietf.org/html/rfc8407#section-3.12). I believe that would provide
> 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-hong-i2nsf-nsf-monitoring-data-model-06 - draft-ietf-i2nsf-capability-04
> 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.
> 
> 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]')
> yang-doctors mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/yang-doctors

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Wed, 27 Nov 2019 22:42:41 +0900

Hi Carl,
Thanks a lot.

Best Regards,
Paul