Re: [I2nsf] request for comments to the gap analysis draft

["Romascanu, Dan (Dan)" <[e-mail]>]

Hi,
Thanks for doing this work. It's very useful, but I believe there is also some more work ahead.

1.       One of my concerns is that the current I-D is not synchronized well with the latest focused scope of work as it is reflected in the charter. This is very visible in the introduction section which speaks about VNF with SDN and about an 'I2NSF protocol' which is not in the scope of the charter. On the other hand there is nothing in this section or in the rest of the document about flow-based NSFs, or about the I2NSF Capability Layer

2.       The terminology and the diagrams in sections 2 and 3 are not aligned with the content of the other documents. Ideally they should have been defined in the problem statement or framework document and referred here only. The SEP/SPDP terminology (which I personally like) needs to be synchronized with the terminology in the merged-i2nsf-framework draft which talks about security controllers

3.       A pass on language, spelling, grammar is badly needed. I cannot figure out what for example 'MILE - looks at events that go Bump in night in the Security 2015.' Means

4.       It's not clear why some of the IETF activities are mentioned at all. Only these activities that may provide or yield into deliverables that can serve the capability layer security policy need to be reviewed. I do not believe that L3M, SFC, NSIS, VNFPool need to be mentioned at all, or maybe just listed as clearly out of scope.

5.       In general I find many of the descriptions of scope and status of other work to be much too detailed. Just focus on what role they can plat at the capability layer security policies - as protocols, information and data models.

6.       What about the work from outside the IETF? Section 6 in https://datatracker.ietf.org/doc/draft-dunbar-i2nsf-problem-statement/ mentions ETSI NFV ISG,  OpenStack Firewall / SaaS, CSA SaaS. Why are these not included here?
Thanks and Regards,

Dan

From: I2nsf [mailto:[e-mail]] On Behalf Of Dacheng Zhang
Sent: Wednesday, June 10, 2015 12:49 PM
To: [e-mail]
Subject: [I2nsf] request for comments to the gap analysis draft




Hi,




We have uploaded a new version of gap analysis (https://tools.ietf.org/html/draft-zhang-gap-analysis-03<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dzhang-2Dgap-2Danalysis-2D03&d=AwQFbw&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=Gk-f6ddpHV68JFqnB-MdUmkqbHG49i0jiRgUz5yH9rQ&s=5Qwj0saUWHE72DxXT9CTpp4bSHIDmYZuZZ9bCZwcocM&e=>), in which we compare the relationships between i2nsf and other work in IETF.  Some of the work are still as the BoF stage. It would be great if you could give us some comments or feedbacks to help us improve this draft. ^_^




Some of the texts are attached as follows.


Cheers


Dacheng












5.1.6<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dzhang-2Dgap-2Danalysis-2D03-23section-2D5.1.6&d=AwMFbw&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=Gk-f6ddpHV68JFqnB-MdUmkqbHG49i0jiRgUz5yH9rQ&s=0CdFEo-fWML-jMrXzerNXeeDj89isricPPqNvGXUcis&e=>.  SUPA BOF





   The IETF SUPA (Simplified Use of Policy Abstractions) BOF is

   proposing an IETF Working Group to develop a set of information

   models for defining standardized policy rules at different levels of

   abstraction, and will show how to map these (technology-independent)

   forms into YANG data models. The BOF introduces the concepts of

   multi-level (multiple levels of abstraction) (similar to figure 5)

   and multi-technology (e.g., IP, VPNs, MPLS) network abstractions to

   address the current separation between development and deployment





Hares & el.      Expires December 6, 2015                      [Page 12]

________________________________

 <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dzhang-2Dgap-2Danalysis-2D03-23page-2D13&d=AwMFbw&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=Gk-f6ddpHV68JFqnB-MdUmkqbHG49i0jiRgUz5yH9rQ&s=ezLnQ7o1AVK2lWoNxtgYCDAN__tSsxxclYC4KrjaF4Y&e=>

INTERNET DRAFT                      I2NSF Gap analysis      June 6, 2015



   operations. Multiple levels of abstraction enable common concepts

   present in different technologies and implementations to be

   represented in a common manner. This facilitates using diverse

   components and technologies to implement a network service.



   Three information models are envisioned:



   o A generic information model that defines concepts needed by policy

   management independent of the form and content of the policy.



   o A more specific information model that refines the generic

   information model to specify how to build policy rules of the

   event-condition-action paradigm.



   o A more specific information model that refines the generic

   information model to specify how to build policy rules that

   declaratively specify what goals to achieve (but not how to achieve

   those goals).



   The set of generic policy information models in SUPA's work will be

   mapped to a set of concrete YANG data models. These data models will

   provide a set of core YANG modules that define how to manage and

   communicate policies, expressed using the event-condition-action

   paradigm or the declarative goal-oriented paradigm, between systems.



   The SUPA BOF/WG plans to focus in the first phase of its work on

   completing the set of information models required to construct an

   extensible, policy-based framework. These information models will

   lead to a set of core YANG data models for a policy-based management

   framework to monitor and control network services.



   The working group will use the distributed data center (DDC) use

   case, which includes the dynamic policy-driven provisioning and

   operation of inter-datacenter (inter-dc) virtual private networks

   (VPNs) of various types, as a means to validate that the generic

   policy-framework is implementable and usable.



   I2NSF versus SUPA BOF work



   I2NSF is focus on passing policies between I2NSF client and I2NSF

   Agent in an interoperable format. The SUPA policies are more generic

   policies (Prescriptive Event-Condition-Action and declarative/Intent-

   based. The protocol between the I2NSF Client and I2NSF agent is

   specific to the security policies. If SUPA was completed now, it

   might provide wisdom for the I2NSF interoperable protocol. With SUPA

   running in parallel, the generic models may or may not provide timely

   advise to structure I2NSF protocol.