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 protected]> 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 protected]> wrote: > >> Reviewer: Carl Moberg >> Review result: Almost Ready >> >> This is my review of the [email protected] 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 protected]> >> >> NEW: >> WG Chair: Linda Dunbar >> <mailto:[email protected]> >> >> _______________________________________________ >> I2nsf mailing list >> [email protected] >> 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 protected], [email protected] > 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 protected], [email protected] Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php <http://cpslab.skku.edu/people-jaehoon-jeong.php>
_______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
