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

["Susan Hares" <[e-mail]>]

Dan: 

Thank you for the feedback.  It is really appreciated. Thank you for letting
me know where I missed aligning it with the charter, and the editorial
issues.   This draft definitely needs an large editing pass.  I will take
another editing pass early morning on Thursday.   If you get this could you
provide we with some-other feedback on a few key points.   

You staste: 

1.       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. 

Ok - I think you are wrong technically.  <soap box on> I think this type of
reasoning is the reason why we have stove-pipes instead of an integrated
solution in IETF.  I put it in because I think people should think about it.
If people are not willing to design both the protocol and place within other
protocol we will continue to be stove-pipes.  <soap box off>  

 If you are the BOF chair, you are the Boss - so you tell me what you want
in the BOF document and if I do not like it - I will send a minority report.


-----------

Most of the feedback  is reasonable, but I'm really having a bit of trouble
with your review on section 3 and section 5.   Section 3 discusses how the
I2NSF fits into the Security Area's efforts, and why it matters. Section 4
will be expanded to indicate ETSI NFV ISG,  OpenStack Firewall / SaaS, CSA
SaaS and ODL GDP use in firewalls.  Section 4 tells why the industry
matters.  Section 5 discusses how I2NSF fits into existing work in NM/OPS,
Internet,  Routing (I2RS interface, SFC), and Transport area.  The
discussion of these areas only point where I2NSF is different, and where it
aligns.  This is FAQ for Area directors. 

I'm trying to determine if my errors were editorial or technical.  Since
this is a GAP analysis for the Security area, I did not provide details on
the security working groups (MILE, DOTS, and SACM) - I would feel the gap
analysis was a failure.  Section 3 was written a bit light-hearted as I felt
repeating things to the security director in a repetitive fashion (It would
bore Stephen out of his mind.).   

In routing, we consider if a new protocol fits into all of the routing
protocols.  In OPS/NM, we consider if the protocol fits into the whole
management structure.  Section 3 - is that section for security.  To provide
a more detailed report: 

.         MILE WG deals with lightweight incidents, and for security these
are the things that go "bump in the night" the "Security incidents, such as
system compromises, worms, viruses, phishing incidents, and denial of
service, typically result in the loss of service, data, and resources both
human and system." RFC6545.  See MILES charter for any incident.   One thing
these incidents reports may cause is for the provisioning of NSF systems.
To not consider how MILE WG incident reporting fits in with NSF - seems
unwise. 

.         SCAM - charter indicates it look at automating systems that store,
process, and transmit information, and focus on endpoints.  These security
reports may run in NSF devices handling some of the endpoint configuration,
or run in end nodes reporting these systems to the work.  An overview of the
place of I2NSF should look at this point.  

.         draft-mglt-dots-use-cases-00 is describing how to signal threats.
It also will work in alignment with the I2NSF work  by running in the same
boxes. 

The I2NSF charter should not say much except - "works well with the other
security efforts".  However, the GAP analysis should clearly point out where
the NSF work fits into the security standardization work.  

I will try to put a summary section in the section 4 that points toward
charter input. 

I added L3SM because security and BNG into L3S is sometimes considered part
of L3SM services.  SFC is considering pathways to NSF boxes as part of the
BNG replacement (Access replacement) or the pipelines to the new vNSF boxes.
This is why I added this work.  NSIS - I agree, but it predated me joining
as an author so I hoped to get feedback.  VNFPool can be removed, but I
think it is a key technology for the ETSI to be successful.  I was going to
pull things out the ETSI management document and issues from MSOs.  This
document does not support it at this time.

Editorial comments are well taken.  I pushed out this document to an
untimely rebirth.  My apologies to my co-authors. 

Sue 

From: I2nsf [mailto:[e-mail]] On Behalf Of Romascanu, Dan
(Dan)
Sent: Wednesday, June 10, 2015 8:23 AM
To: Dacheng Zhang; [e-mail]
Subject: Re: [I2nsf] request for comments to the gap analysis draft

 

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_dr
aft-2Dzhang-2Dgap-2Danalysis-2D03&d=AwQFbw&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGx
R31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=Gk-f6ddpHV68JFqnB-MdUmkqbHG49i0jiRgU
z5yH9rQ&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
 
 
 
 
 




 
<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_dr
aft-2Dzhang-2Dgap-2Danalysis-2D03-23section-2D5.1.6&d=AwMFbw&c=BFpWQw8bsuKpl
1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=Gk-f6ddpHV68JFqnB-
MdUmkqbHG49i0jiRgUz5yH9rQ&s=0CdFEo-fWML-jMrXzerNXeeDj89isricPPqNvGXUcis&e=>
5.1.6.  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_dr
aft-2Dzhang-2Dgap-2Danalysis-2D03-23page-2D13&d=AwMFbw&c=BFpWQw8bsuKpl1SgiZH
64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=Gk-f6ddpHV68JFqnB-MdUmkq
bHG49i0jiRgUz5yH9rQ&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.