Subject: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93

From: Linda Dunbar <[email-masked]>
Date: Thu, 7 May 2015 15:53:00 +0000

Thanks to I2NSF contributors for the good progresses made since  IETF92 side meetings. Among the two I2NSF interfaces,  i.e. the client facing Service Interface and the NSF facing Capability Interface, the work to be done at the Capability Interface becomes very clear and concrete. But the Service Interface is still a little vague.

The feedback from last IETF side meetings was "the scope is too big for one IETF WG". Therefore, we are leaning towards narrowing the I2NSF scope to the Capability Interface. The thinking logic is: Once the Capability Interface is completed, we will see more clearly the work for Service interface. Even if Capability layer alone is standardized, it is a giant leap forward in building blocks for Service Provider to automate their Security Controller that can utilize NSF by multiple vendors

Here is the narrower scoped I2NSF charter. Your comments and suggestions are greatly appreciated. CC'ed to DOTS, I2RS, and Netmod groups for wider review.

Enterprises, residential, and mobile customers are increasingly consuming network functions, especially network security related functions that are not running on their premises.  In addition, the European Telecommunications Standards Institute (ETSI) Network Function Virtualization (NFV) initiative creates new management challenges for security policies to be enforced by distributed, virtual, network security functions (vNSF). Without standard interface to express, monitor, and manage security policies to security functions deployed at different premises, it becomes virtually impossible for security service providers to automate the service offering utilizing security functions by multiple vendors.

The ultimate goal of I2NSF is to enable enterprises to utilize security functions not hosted on their own premises but instead hosted in service provider domain, to establish how to communicate desired security policies to NSF and how to get performance data or report out of NSF or vNSF.

There are two layers of interfaces:

-          Security Policies facing security functions (I2NSF Capability Layer)

-          Security Policies facing clients (I2NSF Service Layer)

The I2NSF Capability Layer specifies the functional security policies, which are translated from the client security policies, to security functions. I2NSF will NOT standardize security functions or devices. Instead, I2NSF is only to standardize the policy provisioning to the security functions (not devices), in the form of "Subject - Object - Function - Action" paradigm.

The I2NSF Service Layer is for clients to express and monitor security policies for their specific flows, which is usually based on customers' logical networks, addresses and context. I2NSF Service Layer can also be security expectation or loose security requirement, especially for customers who don't have the security expertise.

The concrete work at the L2NSF Capability Layer includes

-          The informational & data models for each category to be represented to virtual or physical network security functions,

-          The capability registry (IANA) of policy provisioning capability to flow based security function, and

-          The proper secure communication channels to carry the security policies between Controller and NSFs.
The capability registry is to make it feasible to categorize network security functions provided by different vendors based on security policy provisioning capability without any need to standardize security functions themselves.  Standard provisioning capability interface is an essential building block for Security Service Provider to automate their Security Controllers that can utilize NSF by multiple vendors. This layer will leverage the existing protocols and data models defined by I2RS, Netconf, and NETMOD.

For the I2NSF Service Layer, it is out of the scope for I2NSF (at least for now) to standardize the interface facing clients. However, I2NSF can have informational drafts showing sample APIs or/and RESTful interfaces to clients and demonstrating the feasibility of them being translated to the Capability Layer policies.

Since different security vendors support different features & functions on their devices, I2NSF will focus on flow based security functions that provide treatment to packets/flows, such as IPS/IDS, Web filter, and flow filter. (They are different from other security functions such as Authentication, Authorization, or Encryption). Exemplar services associated with Flow Based Security functions include deep packet inspection, packet/flow/stream filtering or pattern matching and remediation, etc.

Similar to I2RS focusing on the interface to RIB/FIB even though most routers provide far more functions than RIB/FIB, the I2NSF focused functions can be a portion of features supported by vendors' specific devices.

It is a non-goal to create new protocols or data modeling languages for I2NSF interfaces.
I2NSF WG Deliverables include:

-           Use Case document.

-          Framework Document.

-          Requirement for extensions (if there are any) to existing protocols used by the WG.

-           Gap analysis of existing protocols and modeling languages

-          A single, unified, Information Model for expressing policies to the Flow Based Security Functions described above.

-          Corresponding Data Models (e.g. YANG models) derived from the above Information Model.

-          IANA registry consideration for flow based security function policy provisioning capability.

-           (Optionally) Applicability Statements on how to use I2RS, Netconf, and NETMOD to carry the content of the specified information/data models.

[The WG may decide that the Use cases, Framework, and Requirement are Informational documents or simply reference documents during the lifetime of the WG. The framework, that describes the functional components and the I2NSF work items, is to make I2NSF work more organized.]

Suggested Milestones
  - Use Case Document:  Charter time + 1 month to WG Document
  - Framework: Charter time + 4 months to WG Document
  - Requirements for extensions to protocols:  Charter time + 6 months to WG document
  - Info model: Charter time + 7 months to WG Document
  - IANA registry consideration + 10 months to WG Document
  - All Early Drafts to IESG: 10 months

[decision point - +10 months]
  - Data Models: Charter + 9 Months to WG Document
  - Applicability Statements: 10 months to WG Document
  - Data Models and Applicability Statements to IESG  - 16 months

The WG will work closely with I2RS, Netconf and Netmod WGs. The WG will communicate with external SDOs like ETSI NFV and will encourage open source code development related to the WG scope in organizations like ONF, OpenStack, ODL, and OpenNFV.

Cheers,
Linda Dunbar

---

From: "Zarny, Myo" <[email-masked]>
Date: Sat, 9 May 2015 11:54:43 -0400

Hi Linda,

Thanks very much for putting this together. I agree that the scope needs to be tightened if it is to be meaningful. I'm fine with the suggested deliverables, milestones, etc. BUT we should tweak the first two paragraphs related to the goal of the WG. I2NSF shouldn't take a position on where the security functions are hosted or if the caller and the security service function belong to the same or different domains. Also, not sure if we should bring in another organization's name (ETSI) into an IETF charter.

I've taken a stab at rewording the first few paragraphs...

Network security functions (NSFs) are increasingly provided and consumed in increasingly diverse environments. Users of NSFs could consume network security services hosted by one or more providers, which may be their own enterprise, service providers, or a combination of both. Likewise, service providers may offer their customers network security services that consist of multiple security products from different vendors. Yet because no widely accepted industry standard security interfaces exist today, management of NSFs (device and policy provisioning, monitoring, etc.) tends to be bespoke, essentially as offered by product vendors. As a result, automation of such services, if it exists at all, is also bespoke.

The primary goal of I2NSF is to define a set of interfaces and data models for policy provisioning and management aspects of NSFs. Other aspects of NSFs such as device or network provisioning are out of scope.

The scope of I2NSF can be further divided into two layers:

*         I2NSF Capabilities Layer

*         I2NSF Services Layer
...

I've made a few comments inline below as well.

I'm not familiar with how detailed a charter needs to be, so I'll leave it others to comment on whether the level of detail here is sufficient, too much or too light.

Myo

From: I2nsf [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: 7 May 2015 11:53 AM
To: [email-masked]; Kathleen Moriarty
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93

The I2NSF Capability Layer specifies the functional security policies, which are translated from the client security policies, to security functions. I2NSF will NOT standardize security functions or devices. Instead, I2NSF is only to standardize the policy provisioning to the security functions (not devices), in the form of "Subject - Object - Function - Action" paradigm.
MZ:  Not sure if we need to explicitly specify a potential solution("Subject-Object-Function-Action") in the charter.

The I2NSF Service Layer is for clients to express and monitor security policies for their specific flows, which is usually based on customers' logical networks, addresses and context. I2NSF Service Layer can also be security expectation or loose security requirement, especially for customers who don't have the security expertise.
MZ:  I suggest "I2NSF Services Layer provides a set of interfaces for clients to express and monitor security policies. The policies may be intent-based."

-           Use Case document.

-          Framework Document.

Suggested Milestones

Cheers,
Linda Dunbar

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 11 May 2015 08:43:51 +0000

I am fine with the editing proposed by Myo as it makes the scope more clear. Maybe the only thing I would suggest is to use 'non-standard' rather than 'bespoke' which may puzzle the non-native English speakers. I had to go to the dictionary to see what it exactly means (but it may be only me!).

Mentioning another SDO in the charter is actually fine as long as it points to the fact that we are aiming to work in cooperation with other SDOs and avoid duplicating work. In this case we say at the end that we plan to cooperate with ETSI, so keeping explicit mentioning out of the introduction is fine.

Thanks and Regards,

Dan

From: I2nsf [mailto:[email-masked]] On Behalf Of Zarny, Myo
Sent: Saturday, May 09, 2015 6:55 PM
To: 'Linda Dunbar'; [email-masked]'; 'Kathleen Moriarty'
Cc: [email-masked]'; [email-masked]'; [email-masked]'
Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93

Hi Linda,

*         I2NSF Services Layer
...

Myo

From: I2nsf [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: 7 May 2015 11:53 AM
To: [email-masked]<mailto:[email-masked]>; Kathleen Moriarty
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93

-           Use Case document.

-          Framework Document.

Suggested Milestones

Cheers,
Linda Dunbar

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Mon, 11 May 2015 11:19:35 +0000

Hi,

Agree with Dan (and therefore Myo) in the suggested changes and in the fact that mentioning ETSI out of the introduction is fine.

And just a minor nit: I'd refrain to mention DPI as an exemplar function (the days of DPI as we know it days are close to be over, given the current concerns about privacy and the usage of E2E encryption) and rephrase the sentence mentioning it from
"Exemplar services associated with Flow Based Security functions include deep packet inspection, packet/flow/stream filtering or pattern matching and remediation, etc."
into
"Exemplar services associated with Flow Based Security functions include malware detection, packet/flow/stream filtering or pattern matching and remediation, etc."

Be goode,

On 11 May 2015, at 10:43 , Romascanu, Dan (Dan) <[email-masked]<mailto:[email-masked]>> wrote:

I am fine with the editing proposed by Myo as it makes the scope more clear. Maybe the only thing I would suggest is to use ‘non-standard’ rather than ‘bespoke’ which may puzzle the non-native English speakers. I had to go to the dictionary to see what it exactly means (but it may be only me!).

Thanks and Regards,

Dan

From: I2nsf [mailto:[email-masked]] On Behalf Of Zarny, Myo
Sent: Saturday, May 09, 2015 6:55 PM
To: 'Linda Dunbar'; [email-masked]<mailto:[email-masked]>'; 'Kathleen Moriarty'
Cc: [email-masked]<mailto:[email-masked]>'; [email-masked]<mailto:[email-masked]>'; [email-masked]<mailto:[email-masked]>'
Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93

Hi Linda,

Thanks very much for putting this together. I agree that the scope needs to be tightened if it is to be meaningful. I’m fine with the suggested deliverables, milestones, etc. BUT we should tweak the first two paragraphs related to the goal of the WG. I2NSF shouldn’t take a position on where the security functions are hosted or if the caller and the security service function belong to the same or different domains. Also, not sure if we should bring in another organization’s name (ETSI) into an IETF charter.

I’ve taken a stab at rewording the first few paragraphs…

The scope of I2NSF can be further divided into two layers:
•         I2NSF Capabilities Layer
•         I2NSF Services Layer
…

I’ve made a few comments inline below as well.

I’m not familiar with how detailed a charter needs to be, so I’ll leave it others to comment on whether the level of detail here is sufficient, too much or too light.

Myo

Here is the narrower scoped I2NSF charter. Your comments and suggestions are greatly appreciated. CC’ed to DOTS, I2RS, and Netmod groups for wider review.

The I2NSF Capability Layer specifies the functional security policies, which are translated from the client security policies, to security functions. I2NSF will NOT standardize security functions or devices. Instead, I2NSF is only to standardize the policy provisioning to the security functions (not devices), in the form of “Subject – Object – Function – Action” paradigm.
MZ:  Not sure if we need to explicitly specify a potential solution(“Subject-Object-Function-Action”) in the charter.

The I2NSF Service Layer is for clients to express and monitor security policies for their specific flows, which is usually based on customers’ logical networks, addresses and context. I2NSF Service Layer can also be security expectation or loose security requirement, especially for customers who don’t have the security expertise.
MZ:  I suggest “I2NSF Services Layer provides a set of interfaces for clients to express and monitor security policies. The policies may be intent-based.”

Similar to I2RS focusing on the interface to RIB/FIB even though most routers provide far more functions than RIB/FIB, the I2NSF focused functions can be a portion of features supported by vendors’ specific devices.

-           Use Case document.
-          Framework Document.

Suggested Milestones

[decision point – +10 months]
  - Data Models: Charter + 9 Months to WG Document
  - Applicability Statements: 10 months to WG Document
  - Data Models and Applicability Statements to IESG  - 16 months

Cheers,
Linda Dunbar
_______________________________________________
I2nsf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/i2nsf

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

---

From: "Xialiang (Frank)" <[email-masked]>
Date: Tue, 12 May 2015 11:07:10 +0000

Hi Linda,
I agree that we can specify capability interface firstly, and leave the currently vague service interface out of scope now. But still, as an essential part of the whole solution, the service interface is also very important for various clients to express their custom security requirement flexibly. So, I suggest we can set the specification of service interface as the second phase of I2NSF work.

Other comments are inline:

B.R.
Frank

发件人: I2nsf [mailto:[email-masked]] 代表 Linda Dunbar
发送时间: 2015年5月7日 23:53
收件人: [email-masked]; Kathleen Moriarty
抄送: [email-masked]; [email-masked]; [email-masked]
主题: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93

The ultimate goal of I2NSF is to enable enterprises to utilize security functions not hosted on their own premises but instead hosted in service provider domain, to establish how to communicate desired security policies to NSF and how to get performance data or report out of NSF or vNSF.
[Frank]: the I2NSF clients do not only include enterprise. So, change “enterprise” to “I2NSF clients”. Where are the performance data or report sent to? I think they should be the security service providers or just the I2NSF clients.

The I2NSF Service Layer is for clients to express and monitor security policies for their specific flows, which is usually based on customers’ logical networks, addresses and context. I2NSF Service Layer can also be security expectation or loose security requirement, especially for customers who don’t have the security expertise.
[Frank]: for the two interfaces, not mentioning the functions related with performance data or report?

-           Use Case document.

-          Framework Document.

Suggested Milestones

Cheers,
Linda Dunbar

---

From: Zongning <[email-masked]>
Date: Wed, 13 May 2015 08:57:25 +0000

Hi, Linda,

I support the current charter in general.
One quick comment - it seems that you have a whole architecture in your mind (so you have layer definitions, components like Controller, NSFs, etc), it would be good that such architecture is briefly described in the beginning of the charter. This is mainly to help people to understand your scope.

Thanks.

-Ning

发件人: Dots [mailto:[email-masked]] 代表 Linda Dunbar
发送时间: 2015年5月7日 23:53
收件人: [email-masked]; Kathleen Moriarty
抄送: [email-masked]; [email-masked]; [email-masked]
主题: [Dots] Further Narrowing the I2NSF scope: the new charter for IETF 93

-           Use Case document.

-          Framework Document.

Suggested Milestones

Cheers,
Linda Dunbar

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 13 May 2015 16:31:06 +0000

Thanks Dan, Myo, Diego, Xiao Jun, Frank and Zing's suggestions.

p.s. I had to check dictionary for "bespoke" too. Synonyms<http://en.wikipedia.org/wiki/Synonym> are "custom-made", "made to order", and "made to measure<http://en.wikipedia.org/wiki/Made_to_measure>", which is a very accurate description.

I will update the charter per your suggestions,

Linda

From: I2nsf [mailto:[email-masked]] On Behalf Of Romascanu, Dan (Dan)
Sent: Monday, May 11, 2015 3:44 AM
To: Zarny, Myo; Linda Dunbar; [email-masked]'; 'Kathleen Moriarty'
Cc: [email-masked]'; [email-masked]'; [email-masked]'
Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93

Thanks and Regards,

Dan

Hi Linda,

*       I2NSF Services Layer
...

Myo

-           Use Case document.

-          Framework Document.

Suggested Milestones

Cheers,
Linda Dunbar

---

From: John Strassner <[email-masked]>
Date: Wed, 13 May 2015 17:18:16 +0000

Dear Linda,

First, thank you for pulling together these changes. The charter development has progressed nicely.

Second, attached is a word document with my edits and suggestions for consideration by the working group. Despite the large number of edits and comments, I am very supportive of I2NSF being made a working group, and would like to volunteer to work on its deliverables. My edits and comments are to address the work that you started in better focusing the working group, and I hope that they help in this process.

Best regards,
John

Dr. John Strassner, Ph.D.
CTO, Software Laboratory, CRD

Futurewei Technologies
US R&D Center
2330 Central Expressway
Building A, office A2-2143
Santa Clara, California   95050

  Office:  +1.408.330.4923
  Email:   [email-masked]

Sent: Thursday, May 07, 2015 8:53 AM

-           Use Case document.

-          Framework Document.

Suggested Milestones

Cheers,
Linda Dunbar

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 13 May 2015 23:37:33 +0200

Can we please stop this cross-posting thread?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Wed, 13 May 2015 22:05:52 +0000

Hi,

(Restricting this to the I2NSF list, as Juergen was sensibly requesting)

While I agree with many of your edits I'd prefer to avoid the overuse of the term "policy" in the document. The text talks about policy at two many layers and can become misleading and difficult to be understood by the community. I'd leave the primary goal definition as:

"The primary goal of I2NSF is to define an extensible framework for managing NSFs"

and consistently talk about "configuration", "management" or "control" (the three terms have pros and cons...) when dealing with the Capability Layer, that I understand is the main goal of the proposed charter.

I see policies more associated to the Service Layer, for which I think the charter could consider some initial, informational documents, and let further development for a later stage.

Be goode,

On 13 May 2015, at 19:18 , John Strassner <[email-masked]<mailto:[email-masked]>> wrote:

Dear Linda,

Best regards,
John

Futurewei Technologies
US R&D Center
2330 Central Expressway

  Office:  +1.408.330.4923
  Email:   [email-masked]<mailto:[email-masked]>

-           Use Case document.
-          Framework Document.

Suggested Milestones

Cheers,
Linda Dunbar
<i2nsf charter-jcs-20150512.docx>_______________________________________________
I2nsf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/i2nsf

Dr Diego R. Lopez
Telefonica I+D

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 13 May 2015 23:09:46 +0000

Myo,

Thanks for taking the stab at the rewording.

A couple of questions inserted below for your wording:

From: Zarny, Myo [mailto:[email-masked]]

Network security functions (NSFs) are increasingly provided and consumed in increasingly diverse environments. Users of NSFs could consume network security services hosted by one or more providers, which may be their own enterprise, service providers, or a combination of both.

[Linda] Do you mean "which may be hosted on premises of their own enterprise, service providers, or a combination of both"?

Likewise, service providers may offer their customers network security services that consist of multiple security products from different vendors. Yet because no widely accepted industry standard security interfaces exist today, management of NSFs (device and policy provisioning, monitoring, etc.) tends to be bespoke, essentially as offered by product vendors. As a result, automation of such services, if it exists at all, is also bespoke.

[Linda] can we say "... if it exists at all, is also vendor specific"?

The primary goal of I2NSF is to define a set of interfaces and data models for policy provisioning and management aspects of NSFs. Other aspects of NSFs such as device or

[Linda] Can we remove the "management aspects of NSFs" from the I2NSF charter? I2NSF only "focuses on the "policy provisioning aspect of NSFs". Management aspects of NSFs can include many different aspects of provisioning, may be too broad for I2NSF.

network provisioning are out of scope.

*       I2NSF Services Layer
...

Myo

-           Use Case document.

-          Framework Document.

Suggested Milestones

Cheers,
Linda Dunbar

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 14 May 2015 07:34:04 +0000

(speaking as contributor)

I agree with Diego's observation. I also agree and like many of the edits proposed by John, but I do not believe that the scope should be focused around policies. Policies may be the right paradigm at certain layers, but they are not the only method for interoperable access and management of NSFs. The work should not IMO exclude policy, but neither should make of it the central (or exclusive) focus.

Regards,

Dan

From: I2nsf [mailto:[email-masked]] On Behalf Of DIEGO LOPEZ GARCIA
Sent: Thursday, May 14, 2015 1:06 AM
To: John Strassner
Cc: [email-masked]; Kathleen Moriarty; Linda Dunbar
Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93
Importance: High

Hi,

Be goode,

Dear Linda,

Best regards,
John

Futurewei Technologies
US R&D Center
2330 Central Expressway

  Office:  +1.408.330.4923

-           Use Case document.
-          Framework Document.

Suggested Milestones

Cheers,
Linda Dunbar
<i2nsf charter-jcs-20150512.docx>_______________________________________________
I2nsf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/i2nsf<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_i2nsf&d=AwMF-g&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=4gmAANF_TP3p2Ke3KgWjZr6PuZ8-VBNmfi1_yAbxHG8&s=H3raTbW2A2F31ayqGIGvQ_bEg90Bq0OfzS_BxkrEyCE&e=>

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/<https://urldefense.proofpoint.com/v2/url?u=http-3A__people.tid.es_diego.lopez_&d=AwMF-g&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=4gmAANF_TP3p2Ke3KgWjZr6PuZ8-VBNmfi1_yAbxHG8&s=-6AWQkmAmLzH0LMN1ykizbrYffPJ8LfIlhL4iAIClFo&e=>

e-mail: [email-masked]<mailto:[email-masked]>
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------

---

From: "Zarny, Myo" <[email-masked]>
Date: Thu, 14 May 2015 18:10:42 -0400

Hi Linda,

Please see inline.

Myo

From: Linda Dunbar [mailto:[email-masked]]
Sent: 13 May 2015 7:10 PM
To: Zarny, Myo [Tech]; [email-masked]'; 'Kathleen Moriarty'
Subject: RE: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93

Myo,

[Linda] Do you mean "which may be hosted on premises of their own enterprise, service providers, or a combination of both"?
Myo:  No. "which" here refers to "one or more providers". Where these services are hosted doesn't matter, from an I2NSF perspective.

Myo:  I suppose we could.

[Linda] Can we remove the "management aspects of NSFs" from the I2NSF charter? I2NSF only "focuses on the "policy provisioning aspect of NSFs". Management aspects of NSFs can include many different aspects of provisioning, may be too broad for I2NSF.
Myo:  I'll defer to the community on the question of how narrow the scope should be. But seems to me, we'll need to add at least some "management" work (monitoring, policy/config discovery, etc.)-even if it's just to facilitate policy provisioning. It doesn't make sense to me that we'll use I2NSF interfaces for "policy provisioning" but have to switch to proprietary vendor specific APIs to discover what the current policies happen to be, or if the policies we pushed are successful!?

*         I2NSF Services Layer
...

Myo

-           Use Case document.

-          Framework Document.

Suggested Milestones

Cheers,
Linda Dunbar

---

From: John Strassner <[email-masked]>
Date: Fri, 15 May 2015 06:07:04 +0000

I'm confused.

If we go to the info page for I2NSF (https://www.ietf.org/mailman/listinfo/I2NSF), we find, and I quote:

"...These trends require a standard interface to express, monitor, and manage security policies for physical and virtual distributed security functions that may be running on different premises.

In order to address the above challenges, vNSF devices may include two functional layers:
- Security Service and Policy Layer
- Capability (or Functional) Layer"

This is from the first two paragraphs.

Note also that in the charter, the following lines were there before (and untouched) by my edits:

There are two layers of interfaces envisioned in the I2NSF approach:

Therefore, please explain what "overuse of the term policy" means (Diego), and why you believe that my edits "focused around policies" (Dan). I would also like to understand what "alternative mechanisms" to policy you would like to propose.

I'm certainly for consensus, and would like to help agree on the charter asap; I just don't understand what in my edits made people think that it is now too focused on policy, given the existing starting text.

regards,
John

Futurewei Technologies
US R&D Center
2330 Central Expressway

  Office:  +1.408.330.4923

From: I2nsf [mailto:[email-masked]] On Behalf Of Romascanu, Dan (Dan)
Sent: Thursday, May 14, 2015 12:34 AM
To: DIEGO LOPEZ GARCIA; John Strassner
Cc: [email-masked]; Kathleen Moriarty; Linda Dunbar
Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93

Regards,

Dan

Hi,

Be goode,

Dear Linda,

Best regards,
John

Futurewei Technologies
US R&D Center
2330 Central Expressway

  Office:  +1.408.330.4923

-           Use Case document.
-          Framework Document.

Suggested Milestones

Cheers,
Linda Dunbar

Dr Diego R. Lopez
Telefonica I+D

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 15 May 2015 15:09:33 +0000

Myo,

Thanks,

Myo,

[Linda] Do you think the following captures what you want?
" The primary goal of I2NSF is to define a set of interfaces and data models for policy provisioning and monitoring aspects of NSFs. Other aspects of NSFs such as device or network provisioning are out of scope."

Linda

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 15 May 2015 16:02:15 +0000

John,

Maybe the wording "policy framework" in your suggested charter makes people think that the scope is too big.

"The primary goal of I2NSF is to define an extensible policy framework for managing NSFs. This should include an information model and a set of data models and software interfaces for specifying, representing, querying, monitoring, and controlling NSFs. Management of NSFs should include communicating, querying, and changing the configuration of NSFs by one or more management entities"

Do you think the following describes what you want?

The primary goal of I2NSF is to define a set of interfaces and data models for security policy provisioning and monitoring aspects of NSFs. Other aspects of NSFs such as device or network provisioning are out of scope. This should include an information model and a set of data models and software interfaces for specifying, representing, querying, monitoring, and controlling security policy aspects of NSFs by one or more management entities.

Linda
From: John Strassner
Sent: Friday, May 15, 2015 1:07 AM
To: Romascanu, Dan (Dan); DIEGO LOPEZ GARCIA
Cc: [email-masked]; Kathleen Moriarty; Linda Dunbar
Subject: RE: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93

I'm confused.

regards,
John

Futurewei Technologies
US R&D Center
2330 Central Expressway

  Office:  +1.408.330.4923

Cc: [email-masked]<mailto:[email-masked]>; Kathleen Moriarty; Linda Dunbar

Regards,

Dan

From: I2nsf [mailto:[email-masked]] On Behalf Of DIEGO LOPEZ GARCIA
Sent: Thursday, May 14, 2015 1:06 AM
To: John Strassner
Cc: [email-masked]<mailto:[email-masked]>; Kathleen Moriarty; Linda Dunbar
Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93
Importance: High

Hi,

Be goode,

Dear Linda,

Best regards,
John

Futurewei Technologies
US R&D Center
2330 Central Expressway

  Office:  +1.408.330.4923

-           Use Case document.
-          Framework Document.

Suggested Milestones

Cheers,
Linda Dunbar

Dr Diego R. Lopez
Telefonica I+D

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Fri, 15 May 2015 16:20:30 +0000

Hi Linda,

I believe that your wording still is too much policy-focused. An interface from an enterprise to NSFs can be or can be not policy based. Policies are one way of configuring security functions but not the only one.

I suggest:

The primary goal of I2NSF is to define a set of interfaces and data models for security functions provisioning and monitoring aspects of NSFs. Other aspects of NSFs such as device or network provisioning are out of scope. This should include an information model and a set of data models and software interfaces for specifying, representing, querying, monitoring, and controlling security functions including the security policy aspects of NSFs by one or more management entities.

Regards,

Dan

From: I2nsf [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Friday, May 15, 2015 7:02 PM
To: John Strassner; Romascanu, Dan (Dan); DIEGO LOPEZ GARCIA
Cc: [email-masked]; Kathleen Moriarty
Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93

John,

Linda
From: John Strassner

I'm confused.

If we go to the info page for I2NSF (https://www.ietf.org/mailman/listinfo/I2NSF<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_I2NSF&d=AwMFAw&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=GKuYchMFXF0De8gb_QAnvtUils5lH2TFAhQJSv7Grhs&s=9nmOI1MDxnbKnATRGfDX_a0c29efeINxYuhuMy_WYV0&e=>), we find, and I quote:

regards,
John

Futurewei Technologies
US R&D Center
2330 Central Expressway

  Office:  +1.408.330.4923

Regards,

Dan

Hi,

Be goode,

Dear Linda,

Best regards,
John

Futurewei Technologies
US R&D Center
2330 Central Expressway

  Office:  +1.408.330.4923

-           Use Case document.
-          Framework Document.

Suggested Milestones

Cheers,
Linda Dunbar

Dr Diego R. Lopez
Telefonica I+D

---

From: "Natale, Bob" <[email-masked]>
Date: Fri, 15 May 2015 16:41:14 +0000

- I liked Linda's version ... consider it a sensible adaptation of John's version.

- I would furthermore like to see this work explicitly connected with SUPA for the policy dimension.

- I understand Dan's perspective, but feel that it reflects an "old school" way of managing network resources and services ... the plus side of "old school" is often "tried and true", so I don't mean it in a pejorative way ... however, industry MUST move to a higher-order mode of operation - the new future mode of operation (FMO) - and that will be intent-driven policy-based provisioning (as a subset of intent-driven policy-based network management). Clearly, there is still some time on the tenure clock for device-type-specific-protocol-driven provisioning, and maybe that's where this work should focus. But I, personally, would rather see it buy into the FMO and contribute per Linda's and John's compromise.

>From the sidelines,
BobN

From: I2nsf [mailto:[email-masked]] On Behalf Of Romascanu, Dan (Dan)
Sent: Friday, May 15, 2015 12:21 PM
To: Linda Dunbar; John Strassner; DIEGO LOPEZ GARCIA
Cc: [email-masked]; Kathleen Moriarty
Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93

Hi Linda,

I suggest:

Regards,

Dan

Cc: [email-masked]<mailto:[email-masked]>; Kathleen Moriarty

John,

Linda
From: John Strassner

I'm confused.

regards,
John

Futurewei Technologies
US R&D Center
2330 Central Expressway

  Office:  +1.408.330.4923

Regards,

Dan

Hi,

Be goode,

Dear Linda,

Best regards,
John

Futurewei Technologies
US R&D Center
2330 Central Expressway

  Office:  +1.408.330.4923

-           Use Case document.
-          Framework Document.

Suggested Milestones

Cheers,
Linda Dunbar

Dr Diego R. Lopez
Telefonica I+D

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Fri, 15 May 2015 16:55:02 +0000

Hi,

While I tend to agree with Bob and am rather in favor of the "new school" I am trying to be realistic and avoid the so common accusations in WG-forming BoFs of trying to boil the ocean... And that's the reason for my comment on the overuse of the term policy, as this is one of those much overloaded words (another example could be "orchestration") that may mislead many within the community. I'd advocate for starting focused on a few concrete, short-term goals, and move forward as we show results and a clear path from them to the higher-order mode of operation.

Be goode,

On 15 May 2015, at 18:41 , Natale, Bob <[email-masked]<mailto:[email-masked]>> wrote:

- I liked Linda’s version … consider it a sensible adaptation of John’s version.

- I understand Dan’s perspective, but feel that it reflects an “old school” way of managing network resources and services … the plus side of “old school” is often “tried and true”, so I don’t mean it in a pejorative way … however, industry MUST move to a higher-order mode of operation – the new future mode of operation (FMO) – and that will be intent-driven policy-based provisioning (as a subset of intent-driven policy-based network management). Clearly, there is still some time on the tenure clock for device-type-specific-protocol-driven provisioning, and maybe that’s where this work should focus. But I, personally, would rather see it buy into the FMO and contribute per Linda’s and John’s compromise.

BobN

Hi Linda,

I suggest:

Regards,

Dan

John,

Maybe the wording “policy framework” in your suggested charter makes people think that the scope is too big.

“The primary goal of I2NSF is to define an extensible policy framework for managing NSFs. This should include an information model and a set of data models and software interfaces for specifying, representing, querying, monitoring, and controlling NSFs. Management of NSFs should include communicating, querying, and changing the configuration of NSFs by one or more management entities”

Linda
From: John Strassner

I’m confused.

“…These trends require a standard interface to express, monitor, and manage security policies for physical and virtual distributed security functions that may be running on different premises.

In order to address the above challenges, vNSF devices may include two functional layers:
- Security Service and Policy Layer
- Capability (or Functional) Layer”

Therefore, please explain what “overuse of the term policy” means (Diego), and why you believe that my edits “focused around policies” (Dan). I would also like to understand what “alternative mechanisms” to policy you would like to propose.

I’m certainly for consensus, and would like to help agree on the charter asap; I just don’t understand what in my edits made people think that it is now too focused on policy, given the existing starting text.

regards,
John

Futurewei Technologies
US R&D Center
2330 Central Expressway

  Office:  +1.408.330.4923

I agree with Diego’s observation. I also agree and like many of the edits proposed by John, but I do not believe that the scope should be focused around policies. Policies may be the right paradigm at certain layers, but they are not the only method for interoperable access and management of NSFs. The work should not IMO exclude policy, but neither should make of it the central (or exclusive) focus.

Regards,

Dan

Hi,

Be goode,

Dear Linda,

Best regards,
John

Futurewei Technologies
US R&D Center
2330 Central Expressway

  Office:  +1.408.330.4923

-           Use Case document.
-          Framework Document.

Suggested Milestones

Cheers,
Linda Dunbar

Dr Diego R. Lopez
Telefonica I+D

Dr Diego R. Lopez
Telefonica I+D

---

From: John Strassner <[email-masked]>
Date: Sat, 16 May 2015 04:54:46 +0000

Hi Linda,

While this is good speculation, I think we need Diego and Dan to clarify what they really meant. Otherwise, we run the risk of guessing.

With respect to your suggestion, I think the following is closer:

The primary goal of I2NSF is to define an information model, and a set of software interfaces and data models, for monitoring and controlling the physical and/or virtual policy provisioning and monitoring security aspects of NSFs. Other aspects of NSFs, such as device or network provisioning, are out of scope. This should include an information model and a set of data models and software interfaces for Monitoring and control of physical and/or virtual NSFs should include the use of policies to specifying, representing, querying, monitoring, and controlling the security policy aspects of NSFs by one or more management entities.

However, I think that this runs the risk of de-emphasizing policy to the point that the WG runs the risk of not fully utilizing the capabilities and power of policy management to scale and manage NSFs

regards,
John

Futurewei Technologies
US R&D Center
2330 Central Expressway

  Office:  +1.408.330.4923

From: Linda Dunbar
Sent: Friday, May 15, 2015 9:02 AM
To: John Strassner; Romascanu, Dan (Dan); DIEGO LOPEZ GARCIA
Cc: [email-masked]; Kathleen Moriarty
Subject: RE: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93

John,

Linda
From: John Strassner

I'm confused.

regards,
John

Futurewei Technologies
US R&D Center
2330 Central Expressway

  Office:  +1.408.330.4923

Regards,

Dan

Hi,

Be goode,

Dear Linda,

Best regards,
John

Futurewei Technologies
US R&D Center
2330 Central Expressway

  Office:  +1.408.330.4923

-           Use Case document.
-          Framework Document.

Suggested Milestones

Cheers,
Linda Dunbar

Dr Diego R. Lopez
Telefonica I+D

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sat, 16 May 2015 08:00:09 +0000

Hi,

I am fine with John's wording here. In order to avoid the risk of de-emphasizing policy (which I believe is an important aspect, but not the exclusive focus of the WG) we can do the following change in the last sentence:

s/should include the use of policies/will include the use of policies/.

Regards,

Dan

From: John Strassner [mailto:[email-masked]]
Sent: Saturday, May 16, 2015 7:55 AM
To: Linda Dunbar; Romascanu, Dan (Dan); DIEGO LOPEZ GARCIA; John Strassner
Cc: [email-masked]; Kathleen Moriarty
Subject: RE: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93

Hi Linda,

regards,
John

Futurewei Technologies
US R&D Center
2330 Central Expressway

  Office:  +1.408.330.4923

From: Linda Dunbar

John,

Linda
From: John Strassner

I'm confused.

If we go to the info page for I2NSF (https://www.ietf.org/mailman/listinfo/I2NSF<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_I2NSF&d=AwMFAw&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=qGm0rvr5nuDuGD1rdmOqli1ntwODZmlPR2etVmG8cvM&s=kS0d64IU3es8LJJiP9YtI4QA8lj8j_xufe6K-MKGApk&e=>), we find, and I quote:

regards,
John

Futurewei Technologies
US R&D Center
2330 Central Expressway

  Office:  +1.408.330.4923

Regards,

Dan

Hi,

Be goode,

Dear Linda,

Best regards,
John

Futurewei Technologies
US R&D Center
2330 Central Expressway

  Office:  +1.408.330.4923

-           Use Case document.
-          Framework Document.

Suggested Milestones

Cheers,
Linda Dunbar

Dr Diego R. Lopez
Telefonica I+D

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Sat, 16 May 2015 08:01:33 +0000

I can only say +1 to Dan's suggestion...

On 16 May 2015, at 10:00 , Romascanu, Dan (Dan) <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

I am fine with John’s wording here. In order to avoid the risk of de-emphasizing policy (which I believe is an important aspect, but not the exclusive focus of the WG) we can do the following change in the last sentence:

Regards,

Dan

Hi Linda,

The primary goal of I2NSF is to define an information model, and a set of softwareinterfaces and data models, for monitoring and controlling the physical and/or virtualpolicy provisioning and monitoring security aspects of NSFs. Other aspects of NSFs, such as device or network provisioning, are out of scope. This should include an information model and a set of data models and software interfaces for Monitoring and control of physical and/or virtual NSFs should include the use of policies to specifying, representing, querying, monitoring, and controlling the security policy aspects of NSFs by one or more management entities.

regards,
John

Futurewei Technologies
US R&D Center
2330 Central Expressway

  Office:  +1.408.330.4923

From: Linda Dunbar

John,

Linda
From: John Strassner

I’m confused.

regards,
John

Futurewei Technologies
US R&D Center
2330 Central Expressway

  Office:  +1.408.330.4923

Regards,

Dan

Hi,

Be goode,

Dear Linda,

Best regards,
John

Futurewei Technologies
US R&D Center
2330 Central Expressway

  Office:  +1.408.330.4923

-           Use Case document.
-          Framework Document.

Suggested Milestones

Cheers,
Linda Dunbar

Dr Diego R. Lopez
Telefonica I+D

Dr Diego R. Lopez
Telefonica I+D