From nobody Thu May 7 08:53:22 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 451851ACD0F; Thu, 7 May 2015 08:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lzcTHKAPxUlb; Thu, 7 May 2015 08:53:09 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 868781ACCF0; Thu, 7 May 2015 08:53:08 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BSG35636; Thu, 07 May 2015 15:53:07 +0000 (GMT) Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 7 May 2015 16:53:06 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml702-chm ([10.193.5.72]) with mapi id 14.03.0158.001; Thu, 7 May 2015 08:53:01 -0700 From: Linda Dunbar To: "i2nsf@ietf.org" , Kathleen Moriarty Thread-Topic: Further Narrowing the I2NSF scope: the new charter for IETF 93 Thread-Index: AdCI3eREQdBVQ8yORRe/7nCVEnyK2Q== Date: Thu, 7 May 2015 15:53:00 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657C11DC6@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.139.99] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657C11DC6dfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "i2rs@ietf.org" , "dots@ietf.org" , "netmod@ietf.org" Subject: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93 X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 15:53:15 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F657C11DC6dfweml701chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks to I2NSF contributors for the good progresses made since IETF92 sid= e 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 I= nterface 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 t= he Capability Interface. The thinking logic is: Once the Capability Interfa= ce is completed, we will see more clearly the work for Service interface. E= ven if Capability layer alone is standardized, it is a giant leap forward i= n building blocks for Service Provider to automate their Security Controlle= r that can utilize NSF by multiple vendors Here is the narrower scoped I2NSF charter. Your comments and suggestions ar= e greatly appreciated. CC'ed to DOTS, I2RS, and Netmod groups for wider rev= iew. Enterprises, residential, and mobile customers are increasingly consuming n= etwork functions, especially network security related functions that are no= t 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 i= nterface to express, monitor, and manage security policies to security func= tions deployed at different premises, it becomes virtually impossible for s= ecurity service providers to automate the service offering utilizing securi= ty functions by multiple vendors. The ultimate goal of I2NSF is to enable enterprises to utilize security fun= ctions not hosted on their own premises but instead hosted in service provi= der domain, to establish how to communicate desired security policies to NS= F 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 La= yer) - Security Policies facing clients (I2NSF Service Layer) The I2NSF Capability Layer specifies the functional security policies, whic= h 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 poli= cies 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 represen= ted 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 p= olicies between Controller and NSFs. The capability registry is to make it feasible to categorize network securi= ty functions provided by different vendors based on security policy provisi= oning capability without any need to standardize security functions themsel= ves. Standard provisioning capability interface is an essential building b= lock for Security Service Provider to automate their Security Controllers t= hat can utilize NSF by multiple vendors. This layer will leverage the exist= ing 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 clien= ts and demonstrating the feasibility of them being translated to the Capabi= lity Layer policies. Since different security vendors support different features & functions on = their devices, I2NSF will focus on flow based security functions that provi= de 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 Base= d Security functions include deep packet inspection, packet/flow/stream fil= tering or pattern matching and remediation, etc. Similar to I2RS focusing on the interface to RIB/FIB even though most route= rs 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 I2N= SF interfaces. I2NSF WG Deliverables include: - Use Case document. - Framework Document. - Requirement for extensions (if there are any) to existing protoc= ols 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 ab= ove Information Model. - IANA registry consideration for flow based security function pol= icy provisioning capability. - (Optionally) Applicability Statements on how to use I2RS, Netco= nf, and NETMOD to carry the content of the specified information/data model= s. [The WG may decide that the Use cases, Framework, and Requirement are Infor= mational 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 W= G 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 com= municate with external SDOs like ETSI NFV and will encourage open source co= de development related to the WG scope in organizations like ONF, OpenStack= , ODL, and OpenNFV. Cheers, Linda Dunbar --_000_4A95BA014132FF49AE685FAB4B9F17F657C11DC6dfweml701chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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

 

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

 

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

 

 <= /p>

 

Enterprises, residential, and mobile customers are i= ncreasingly consuming network functions, especially network security relate= d functions that are not running on their premises.  In addition, the = European Telecommunications Standards Institute (ETSI) Network Function Virtualization (NFV) initiative creates new manage= ment challenges for security policies to be enforced by distributed, virtua= l, 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 Lay= er)

 

The I2NSF Capability Lay= er specifies the functional security policies, which are translated from th= e client security policies, to security functions. I2NSF will NOT standardi= ze security functions or devices. Instead, I2NSF is only to standardize the policy provisioning to the security funct= ions (not devices), in the form of “Subject – Object – Fu= nction – Action” paradigm. 

 =

The I2NSF Service Layer is for clients to express an= d monitor security policies for their specific flows, which is usually base= d on customers’ logical networks, addresses and context. I2NSF Servic= e Layer can also be security expectation or loose security requirement, especially for customers who don’t ha= ve the security expertise.

 

The concrete work at the L2NSF Capability Layer incl= udes

-  &= nbsp;       The informational & data models for each= category to be represented to virtual or physical network security functio= ns,

-  &= nbsp;       The capability registry (IANA) of policy pro= visioning capability to flow based security function, and

-  &= nbsp;       The proper secure communication channels to = carry the security policies between Controller and NSFs.

The capability registry is to make it feasible to ca= tegorize network security functions provided by different vendors based on = security policy provisioning capability without any need to standardize sec= urity functions themselves.  Standard provisioning capability interface is an essential building block for Secur= ity Service Provider to automate their Security Controllers that can utiliz= e 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. H= owever, I2NSF can have informational drafts showing sample APIs or/and REST= ful interfaces to clients and demonstrating the feasibility of them being translated to the Capability Layer policies.=

 =

Since different security vendors support different f= eatures & functions on their devices, I2NSF will focus on flow based se= curity 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, Authorizat= ion, or Encryption). Exemplar services associated with Flow Based Security = functions include deep packet inspection, packet/flow/stream filtering or p= attern 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 I2NS= F focused functions can be a portion of features supported by vendors’= ; specific devices.

 

It is a non-goal to create new protocols or data mod= eling languages for I2NSF interfaces.

I2NSF WG Deliverables include:

 

-       = ;    Use Case document.

-       = ;   Framework Document.

-       = ;   Requirement for extensions (if there are any) to ex= isting protocols used by the WG.

-       = ;    Gap analysis of existing protocols and modeli= ng languages

-       = ;   A single, unified, Information Model for expressing= policies to the Flow Based Security Functions described above.<= /p>

-       = ;   Corresponding Data Models (e.g. YANG models) derive= d 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 info= rmation/data models.

 

[The W= G may decide that the Use cases, Framework, and Requirement are Information= al 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 W= G Document

  - Requirements for extensions to protocols:&n= bsp; 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]  <= /o:p>

  - Data Models: Charter + 9 Months to= WG Document

  - Applicability Statements: 10 months to WG D= ocument

  - Data Models and Applicability Statements to= IESG  - 16 months

 

The WG will work c= losely with I2RS, Netconf and Netmod WGs. The WG will communicate with exte= rnal SDOs like ETSI NFV and will encourage open source code development rel= ated to the WG scope in organizations like ONF, OpenStack, ODL, and OpenNFV.

 <= /p>

 

Cheers,

Linda Dunbar

--_000_4A95BA014132FF49AE685FAB4B9F17F657C11DC6dfweml701chm_-- From nobody Sat May 9 08:55:02 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B66D1A6EE9; Sat, 9 May 2015 08:55:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id En-8asQGPoUB; Sat, 9 May 2015 08:54:54 -0700 (PDT) Received: from mxe02.gs.com (mxe02.gs.com [199.99.47.104]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3E661A3BA0; Sat, 9 May 2015 08:54:53 -0700 (PDT) Received: from pps.filterd (gsppabdp02sd.idz.gs.com [127.0.0.1]) by gsppabdp02sd.idz.gs.com (8.14.5/8.14.5) with SMTP id t49Fssfm025057; Sat, 9 May 2015 11:54:54 -0400 Received: from gsppabdp04nd.inz.gs.com ([10.204.43.243]) by gsppabdp02sd.idz.gs.com with ESMTP id 1u9dk2sdnt-1; Sat, 09 May 2015 11:54:54 -0400 Received: from pps.filterd (gsppabdp04nd.inz.gs.com [127.0.0.1]) by gsppabdp04nd.inz.gs.com (8.14.5/8.14.5) with SMTP id t49FsVgN016925; Sat, 9 May 2015 11:54:46 -0400 Received: from gshcbdp13ex.firmwide.corp.gs.com (gshcbdp13ex.firmwide.corp.gs.com [10.135.172.22]) by gsppabdp04nd.inz.gs.com with ESMTP id 1u961u1ubs-1; Sat, 09 May 2015 11:54:46 -0400 Received: from GSCMAMP19EX.firmwide.corp.gs.com ([139.172.38.36]) by gshcbdp13ex.firmwide.corp.gs.com ([10.135.172.22]) with mapi; Sat, 9 May 2015 11:54:45 -0400 From: "Zarny, Myo" To: "'Linda Dunbar'" , "'i2nsf@ietf.org'" , "'Kathleen Moriarty'" Date: Sat, 9 May 2015 11:54:43 -0400 Thread-Topic: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93 Thread-Index: AdCI3eREQdBVQ8yORRe/7nCVEnyK2QBji2Zg Message-ID: References: <4A95BA014132FF49AE685FAB4B9F17F657C11DC6@dfweml701-chm> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657C11DC6@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-retentionstamp: Firmwide Content-Type: multipart/alternative; boundary="_000_A3233753A4B65F43BCA1B64DA99A9C230721826C6FGSCMAMP19EXfi_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-05-09_02:2015-05-09,2015-05-09,1970-01-01 signatures=0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-05-09_02:2015-05-09,2015-05-09,1970-01-01 signatures=0 Archived-At: Cc: "'i2rs@ietf.org'" , "'dots@ietf.org'" , "'netmod@ietf.org'" Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93 X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2015 15:55:00 -0000 --_000_A3233753A4B65F43BCA1B64DA99A9C230721826C6FGSCMAMP19EXfi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 delive= rables, milestones, etc. BUT we should tweak the first two paragraphs relat= ed to the goal of the WG. I2NSF shouldn't take a position on where the secu= rity functions are hosted or if the caller and the security service functio= n belong to the same or different domains. Also, not sure if we should brin= g 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 sec= urity services hosted by one or more providers, which may be their own ente= rprise, service providers, or a combination of both. Likewise, service prov= iders may offer their customers network security services that consist of m= ultiple security products from different vendors. Yet because no widely acc= epted industry standard security interfaces exist today, management of NSFs= (device and policy provisioning, monitoring, etc.) tends to be bespoke, es= sentially as offered by product vendors. As a result, automation of such se= rvices, 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 NS= Fs 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 mu= ch or too light. Myo From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: 7 May 2015 11:53 AM To: i2nsf@ietf.org; Kathleen Moriarty Cc: i2rs@ietf.org; dots@ietf.org; netmod@ietf.org Subject: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IET= F 93 Thanks to I2NSF contributors for the good progresses made since IETF92 sid= e 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 I= nterface 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 t= he Capability Interface. The thinking logic is: Once the Capability Interfa= ce is completed, we will see more clearly the work for Service interface. E= ven if Capability layer alone is standardized, it is a giant leap forward i= n building blocks for Service Provider to automate their Security Controlle= r that can utilize NSF by multiple vendors Here is the narrower scoped I2NSF charter. Your comments and suggestions ar= e greatly appreciated. CC'ed to DOTS, I2RS, and Netmod groups for wider rev= iew. Enterprises, residential, and mobile customers are increasingly consuming n= etwork functions, especially network security related functions that are no= t 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 i= nterface to express, monitor, and manage security policies to security func= tions deployed at different premises, it becomes virtually impossible for s= ecurity service providers to automate the service offering utilizing securi= ty functions by multiple vendors. The ultimate goal of I2NSF is to enable enterprises to utilize security fun= ctions not hosted on their own premises but instead hosted in service provi= der domain, to establish how to communicate desired security policies to NS= F 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 La= yer) - Security Policies facing clients (I2NSF Service Layer) The I2NSF Capability Layer specifies the functional security policies, whic= h 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("Subjec= t-Object-Function-Action") in the charter. The I2NSF Service Layer is for clients to express and monitor security poli= cies 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 clien= ts to express and monitor security policies. The policies may be intent-bas= ed." The concrete work at the L2NSF Capability Layer includes - The informational & data models for each category to be represen= ted 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 p= olicies between Controller and NSFs. The capability registry is to make it feasible to categorize network securi= ty functions provided by different vendors based on security policy provisi= oning capability without any need to standardize security functions themsel= ves. Standard provisioning capability interface is an essential building b= lock for Security Service Provider to automate their Security Controllers t= hat can utilize NSF by multiple vendors. This layer will leverage the exist= ing 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 clien= ts and demonstrating the feasibility of them being translated to the Capabi= lity Layer policies. Since different security vendors support different features & functions on = their devices, I2NSF will focus on flow based security functions that provi= de 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 Base= d Security functions include deep packet inspection, packet/flow/stream fil= tering or pattern matching and remediation, etc. Similar to I2RS focusing on the interface to RIB/FIB even though most route= rs 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 I2N= SF interfaces. I2NSF WG Deliverables include: - Use Case document. - Framework Document. - Requirement for extensions (if there are any) to existing protoc= ols 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 ab= ove Information Model. - IANA registry consideration for flow based security function pol= icy provisioning capability. - (Optionally) Applicability Statements on how to use I2RS, Netco= nf, and NETMOD to carry the content of the specified information/data model= s. [The WG may decide that the Use cases, Framework, and Requirement are Infor= mational 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 W= G 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 com= municate with external SDOs like ETSI NFV and will encourage open source co= de development related to the WG scope in organizations like ONF, OpenStack= , ODL, and OpenNFV. Cheers, Linda Dunbar --_000_A3233753A4B65F43BCA1B64DA99A9C230721826C6FGSCMAMP19EXfi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Linda,

 

Thanks very much for putting this together. I agre= e 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̵= 7;t take a position on where the security functions are hosted or if the ca= ller and the security service function belong to the same or different doma= ins. 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 fir= st few paragraphs…

 

Network security functions (NSFs) are increasingly provided= and consumed in increasingly diverse environments. Users of NSFs could con= sume network security services hosted by one or more providers, which may b= e their own enterprise, service providers, or a combination of both. Likewi= se, service providers may offer their customers network security services t= hat consist of multiple security products from different vendors. Yet becau= se no widely accepted industry standard security interfaces exist today, ma= nagement of NSFs (device and policy provisioning, monitoring, etc.) tends t= o be bespoke, essentially as offered by product vendors. As a result, autom= ation of such services, if it exists at all, is also bespoke.  

 <= /span>

The primary goal of I2NS= F 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 net= work provisioning are out of scope.

 

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

· &= nbsp;       I2NSF Cap= abilities Layer

·         I2NSF Services Layer

…

 =

I’ve ma= de 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.

&= nbsp;

My= o

<= o:p> 

 

From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of= Linda Dunbar
Sent: 7 May 2015 11:53 AM
To: i2nsf@i= etf.org; Kathleen Moriarty
Cc: i2rs@ietf.org; dots@ietf.org; netm= od@ietf.org
Subject: [I2nsf] Further Narrowing the I2NSF scope: t= he new charter for IETF 93

 

Thanks to I2NSF contributors for the good progre= sses made since  IETF92 side meetings. Among the two I2NSF interfaces,=  i.e. the client facing Service Interface and the NSF facing Capabili= ty 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". T= herefore, we are leaning towards narrowing the I2NSF scope to the Capabilit= y Interface. The thinking logic is: Once the Capability Interface is comple= ted, we will see more clearly the work for Service interface. Even if Capab= ility layer alone is standardized, it is a giant leap forward in building b= locks for Service Provider to automate their Security Controller that can u= tilize NSF by multiple vendors

 

Here is the narrower scoped I2NSF charter. Your comments and su= ggestions are greatly appreciated. CC’ed to DOTS, I2RS, and Netmod gr= oups for wider review.

 

 

 

Enterprises, residential, and mobile customers are increasi= ngly consuming network functions, especially network security related funct= ions that are not running on their premises.  In addition, the Europea= n Telecommunications Standards Institute (ETSI) Network Function Virtualiza= tion (NFV) initiative creates new management challenges for security polici= es to be enforced by distributed, virtual, network security functions (vNSF= ). Without standard interface to express, monitor, and manage security poli= cies to security functions deployed at different premises, it becomes virtu= ally impossible for security service providers to automate the service offe= ring utilizing security functions by multiple vendors.

 

The ultimate goal of I2NSF is to enabl= e enterprises to utilize security functions not hosted on their own premise= s but instead hosted in service provider domain, to establish how to commun= icate desired security policies to NSF and how to get performance data or r= eport out of NSF or vNSF.

 

There are two layers of interfaces:

-       &n= bsp;  Security Policies facing security functi= ons (I2NSF Capability Layer)

-          Security Policies facing clients (I2NSF Service Layer)=

 <= /o:p>

The I2NSF Capability Layer specifies the functional security poli= cies, which are translated from the client security policies, to security f= unctions. I2NSF will NOT standardize security functions or devices. Instead= , I2NSF is only to standardize the policy provisioning to the security func= tions (not devices), in the form of “Subject – Object – F= unction – Action” paradigm. 

MZ:&= nbsp; 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̵= 7; logical networks, addresses and context. I2NSF Service Layer can also be= security expectation or loose security requirement, especially for custome= rs who don’t have the security expertise.

MZ:  = I suggest “I2NSF Services Layer provides a set of interfaces for clie= nts to express and monitor security policies. The policies may be intent-ba= sed.”

 

= The concrete work at the L2NSF Capability Layer includes

-&n= bsp;         <= ![endif]>The informational & data models for each category to be repres= ented to virtual or physical network security functions,

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

-    &n= bsp;     The proper secu= re communication channels to carry the security policies between Controller= and NSFs.

The capability registry is to make it fea= sible to categorize network security functions provided by different vendor= s based on security policy provisioning capability without any need to stan= dardize security functions themselves.  Standard provisioning capabili= ty interface is an essential building block for Security Service Provider t= o automate their Security Controllers that can utilize NSF by multiple vend= ors. This layer will leverage the existing protocols and data models define= d 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, I2= NSF can have informational drafts showing sample APIs or/and RESTful interf= aces to clients and demonstrating the feasibility of them being translated = to the Capability Layer policies.

 <= /p>

Since different security= vendors support different features & functions on their devices, I2NSF= will focus on flow based security functions that provide treatment to pack= ets/flows, such as IPS/IDS, Web filter, and flow filter. (They are differen= t from other security functions such as Authentication, Authorization, or E= ncryption). Exemplar services associated with Flow Based Security functions= include deep packet inspection, packet/flow/stream filtering or pattern ma= tching 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 fu= nctions can be a portion of features supported by vendors’ specific d= evices.

=  

It is a non= -goal to create new protocols or data modeling languages for I2NSF interfac= es.

I2NSF WG= Deliverables include:

 

-          <= ![endif]> Use Case document.

<= ![if !supportLists]>-        &nbs= p; Framework Document.

-      &nbs= p;   Requirement for extensions (if there= are any) to existing protocols used by the WG.

-      &n= bsp;    Gap analysis of existing pro= tocols and modeling languages

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

-    &= nbsp;     Corresponding Data Mo= dels (e.g. YANG models) derived from the above Information Model.

-   &nb= sp;      IANA registry con= sideration for flow based security function policy provisioning capability.=

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

 

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

 

Sugg= ested Milestones

  - Use Case Document:  Charter time + 1 month to WG Document=

  - Fra= mework: Charter time + 4 months to WG Document

  - Requirements for extensions to p= rotocols:  Charter time + 6 months to WG document

  - Info model: Charter time= + 7 months to WG Document

  - IANA registry consideration + 10 months to WG Docume= nt

  - A= ll Early Drafts to IESG: 10 months

 

[decision point – +10 months] 

  - Data Models: Ch= arter + 9 Months to WG Document

  - Applicability Statements: 10 months to WG Docum= ent

  - = Data Models and Applicability Statements to IESG  - 16 months

 

=

The WG will = work closely with I2RS, Netconf and Netmod WGs. The WG will communicate wit= h external SDOs like ETSI NFV and will encourage open source code developme= nt related to the WG scope in organizations like ONF, OpenStack, ODL, and O= penNFV.

=  

=  

Cheers,

Linda Dunbar

= --_000_A3233753A4B65F43BCA1B64DA99A9C230721826C6FGSCMAMP19EXfi_-- From nobody Mon May 11 01:50:31 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2C831A7D85; Mon, 11 May 2015 01:50:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WmskAbyXcISE; Mon, 11 May 2015 01:50:18 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F13641A700E; Mon, 11 May 2015 01:50:17 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlgHAFFsUFWHCzIm/2dsb2JhbABcgkUhKVReBrJpAQEBAQEBBplbAoElTAEBAQEBAYELhCABAQEBAxIbPg4QAgEIDQQEAQELFgEGBzIUCQgCBAENBQgTB4gKAakYnXABAQEBAQEBAQEBAQEBAQEBAQEBAQEXhhaFI4RUMQYBgxeBFgWLMYcMjAeGS4sTg1UjYYEFghFvgUWBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,405,1427774400"; d="scan'208,217";a="119809747" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 11 May 2015 04:49:21 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 11 May 2015 04:43:52 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.03.0174.001; Mon, 11 May 2015 10:43:51 +0200 From: "Romascanu, Dan (Dan)" To: "Zarny, Myo" , 'Linda Dunbar' , "'i2nsf@ietf.org'" , 'Kathleen Moriarty' Thread-Topic: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93 Thread-Index: AQHQinCJ2OCaxrcKG02LhKTLY5q9wZ12diUw Date: Mon, 11 May 2015 08:43:51 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5CA27888@AZ-FFEXMB04.global.avaya.com> References: <4A95BA014132FF49AE685FAB4B9F17F657C11DC6@dfweml701-chm> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.47] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA5CA27888AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: Cc: "'i2rs@ietf.org'" , "'dots@ietf.org'" , "'netmod@ietf.org'" Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93 X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 08:50:25 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5CA27888AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 coop= erate with ETSI, so keeping explicit mentioning out of the introduction is = fine. Thanks and Regards, Dan From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Zarny, Myo Sent: Saturday, May 09, 2015 6:55 PM To: 'Linda Dunbar'; 'i2nsf@ietf.org'; 'Kathleen Moriarty' Cc: 'i2rs@ietf.org'; 'dots@ietf.org'; 'netmod@ietf.org' 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 delive= rables, milestones, etc. BUT we should tweak the first two paragraphs relat= ed to the goal of the WG. I2NSF shouldn't take a position on where the secu= rity functions are hosted or if the caller and the security service functio= n belong to the same or different domains. Also, not sure if we should brin= g 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 sec= urity services hosted by one or more providers, which may be their own ente= rprise, service providers, or a combination of both. Likewise, service prov= iders may offer their customers network security services that consist of m= ultiple security products from different vendors. Yet because no widely acc= epted industry standard security interfaces exist today, management of NSFs= (device and policy provisioning, monitoring, etc.) tends to be bespoke, es= sentially as offered by product vendors. As a result, automation of such se= rvices, 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 NS= Fs 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 mu= ch or too light. Myo From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: 7 May 2015 11:53 AM To: i2nsf@ietf.org; Kathleen Moriarty Cc: i2rs@ietf.org; dots@ietf.org; netmod@ietf.org Subject: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IET= F 93 Thanks to I2NSF contributors for the good progresses made since IETF92 sid= e 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 I= nterface 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 t= he Capability Interface. The thinking logic is: Once the Capability Interfa= ce is completed, we will see more clearly the work for Service interface. E= ven if Capability layer alone is standardized, it is a giant leap forward i= n building blocks for Service Provider to automate their Security Controlle= r that can utilize NSF by multiple vendors Here is the narrower scoped I2NSF charter. Your comments and suggestions ar= e greatly appreciated. CC'ed to DOTS, I2RS, and Netmod groups for wider rev= iew. Enterprises, residential, and mobile customers are increasingly consuming n= etwork functions, especially network security related functions that are no= t 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 i= nterface to express, monitor, and manage security policies to security func= tions deployed at different premises, it becomes virtually impossible for s= ecurity service providers to automate the service offering utilizing securi= ty functions by multiple vendors. The ultimate goal of I2NSF is to enable enterprises to utilize security fun= ctions not hosted on their own premises but instead hosted in service provi= der domain, to establish how to communicate desired security policies to NS= F 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 La= yer) - Security Policies facing clients (I2NSF Service Layer) The I2NSF Capability Layer specifies the functional security policies, whic= h 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("Subjec= t-Object-Function-Action") in the charter. The I2NSF Service Layer is for clients to express and monitor security poli= cies 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 clien= ts to express and monitor security policies. The policies may be intent-bas= ed." The concrete work at the L2NSF Capability Layer includes - The informational & data models for each category to be represen= ted 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 p= olicies between Controller and NSFs. The capability registry is to make it feasible to categorize network securi= ty functions provided by different vendors based on security policy provisi= oning capability without any need to standardize security functions themsel= ves. Standard provisioning capability interface is an essential building b= lock for Security Service Provider to automate their Security Controllers t= hat can utilize NSF by multiple vendors. This layer will leverage the exist= ing 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 clien= ts and demonstrating the feasibility of them being translated to the Capabi= lity Layer policies. Since different security vendors support different features & functions on = their devices, I2NSF will focus on flow based security functions that provi= de 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 Base= d Security functions include deep packet inspection, packet/flow/stream fil= tering or pattern matching and remediation, etc. Similar to I2RS focusing on the interface to RIB/FIB even though most route= rs 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 I2N= SF interfaces. I2NSF WG Deliverables include: - Use Case document. - Framework Document. - Requirement for extensions (if there are any) to existing protoc= ols 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 ab= ove Information Model. - IANA registry consideration for flow based security function pol= icy provisioning capability. - (Optionally) Applicability Statements on how to use I2RS, Netco= nf, and NETMOD to carry the content of the specified information/data model= s. [The WG may decide that the Use cases, Framework, and Requirement are Infor= mational 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 W= G 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 com= municate with external SDOs like ETSI NFV and will encourage open source co= de development related to the WG scope in organizations like ONF, OpenStack= , ODL, and OpenNFV. Cheers, Linda Dunbar --_000_9904FB1B0159DA42B0B887B7FA8119CA5CA27888AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am fine with the edi= ting proposed by Myo as it makes the scope more clear. Maybe the only thing= I would suggest is to use ‘non-standard’ rather than ‘be= spoke’ 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 a= re 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<= /p>

 

 

From: I2nsf [m= ailto:i2nsf-bounces@ietf.org] On Behalf Of Zarny, Myo
Sent: Saturday, May 09, 2015 6:55 PM
To: 'Linda Dunbar'; 'i2nsf@ietf.org'; 'Kathleen Moriarty'
Cc: 'i2rs@ietf.org'; 'dots@ietf.org'; 'netmod@ietf.org'
Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new char= ter for IETF 93

 

Hi Linda,

 

Thanks very much for p= utting this together. I agree that the scope needs to be tightened if it is= to be meaningful. I’m fine with the suggested deliverables, mileston= es, etc. BUT we should tweak the first two paragraphs related to the goal of the WG. I2NSF shouldn’t take a pos= ition on where the security functions are hosted or if the caller and the s= ecurity 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 sta= b at rewording the first few paragraphs…

 

Network security functions (NS= Fs) are increasingly provided and consumed in increasingly diverse environm= ents. 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 securi= ty interfaces exist today, management of NSFs (device and policy provisioni= ng, monitoring, etc.) tends to be bespoke, essentially as offered by produc= t vendors. As a result, automation of such services, if it exists at all, is also bespoke.  <= /span>

 

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

 

The scope of I2NSF can be furt= her divided into two layers:

·       &= nbsp; I2NSF Capabilities Layer

·       &= nbsp; I2NSF Services Layer<= /o:p>

…

 

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

 

 

From: I2nsf [mailt= o:i2nsf-bounces@ietf.org] On Behalf Of Linda Dunbar
Sent: 7 May 2015 11:53 AM
To: i2nsf@ietf.org; Kathleen M= oriarty
Cc: i2rs@ietf.org; dots@ietf.org; netmod@ietf.org Subject: [I2nsf] Further Narrowing the I2NSF scope: the new charter = for IETF 93

 

Thanks to I2NSF contrib= utors for the good progresses made since  IETF92 side meetings. Among = the two I2NSF interfaces,  i.e. the client facing Service Interface an= d the NSF facing Capability Interface, the work to be done at the Capability Interface becomes very clear and concrete. Bu= t 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". Th= erefore, 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 inte= rface. Even if Capability layer alone is standardized, it is a giant leap f= orward in building blocks for Service Provider to automate their Security C= ontroller that can utilize NSF by multiple vendors

 

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

 

 

 

Enterprises, residentia= l, and mobile customers are increasingly consuming network functions, espec= ially network security related functions that are not running on their prem= ises.  In addition, the European Telecommunications Standards Institute (ETSI) Network Function Virtualization (NFV) initiativ= e 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 premi= ses, it becomes virtually impossible for security service providers to auto= mate the service offering utilizing security functions by multiple vendors.

 

The ultimate goal of I2= NSF is to enable enterprises to utilize security functions not hosted on th= eir own premises but instead hosted in service provider domain, to establis= h how to communicate desired security policies to NSF and how to get performance data or report out of NSF or vN= SF.

 

There are two layers of= interfaces:

-       = ;   Security Policies facing s= ecurity functions (I2NSF Capability Layer)

-       = ;   Security Policies facing c= lients (I2NSF Service Layer)

 

The I2NSF Capability Layer specifies the functional security policies,= which are translated from the client security policies, to security functi= ons. I2NSF will NOT standardize security functions or devices. Instead, I2NSF is only to standardize the policy pro= visioning to the security functions (not devices), in the form of “Su= bject – Object – Function – Action” paradigm. 

MZ:  Not sure if we need to explicitly specify a potential solu= tion(“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, addres= ses and context. I2NSF Service Layer can also be security expectation or loose security requirement, especially for cust= omers who don’t have the security expertise.

MZ:  I suggest “I2NSF Services Layer provides a set of in= terfaces for clients to express and monitor security policies. The policies= may be intent-based.”

 

The concrete work at th= e L2NSF Capability Layer includes

-  &= nbsp;       The informational &= amp; data models for each category to be represented to virtual or physical= network security functions,<= /p>

-  &= nbsp;       The capability regi= stry (IANA) of policy provisioning capability to flow based security functi= on, and

-  &= nbsp;       The proper secure c= ommunication channels to carry the security policies between Controller and= NSFs.

The capability registry= is to make it feasible to categorize network security functions provided b= y different vendors based on security policy provisioning capability withou= t any need to standardize security functions themselves.  Standard provisioning capability interface is an essenti= al building block for Security Service Provider to automate their Security = Controllers that can utilize NSF by multiple vendors. This layer will lever= age the existing protocols and data models defined by I2RS, Netconf, and NETMOD.

 

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

 

Since different securit= y vendors support different features & functions on their devices, I2NS= F will focus on flow based security functions that provide treatment to pac= kets/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 associate= d with Flow Based Security functions include deep packet inspection, packet= /flow/stream filtering or pattern matching and remediation, etc.

 

Similar to I2RS focusin= g on the interface to RIB/FIB even though most routers provide far more fun= ctions than RIB/FIB, the I2NSF focused functions can be a portion of featur= es supported by vendors’ specific devices.

 

It is a non-goal to cre= ate new protocols or data modeling languages for I2NSF interfaces.

I2NSF WG Deliverables i= nclude:

 

-       = ;    Use Case document. <= o:p>

-       = ;   Framework Document.

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

-       = ;    Gap analysis of exis= ting protocols and modeling languages

-       = ;   A single, unified, Informa= tion Model for expressing policies to the Flow Based Security Functions des= cribed above.

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

-       = ;   IANA registry consideratio= n for flow based security function policy provisioning capability.

-       = ;    (Optionally) Applica= bility Statements on how to use I2RS, Netconf, and NETMOD to carry the cont= ent of the specified information/data models.

 

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

 

Suggested Milestones

  - Use Case Docum= ent:  Charter time + 1 month to WG Document

  - Framework: Cha= rter time + 4 months to WG Document

  - Requirements f= or extensions to protocols:  Charter time + 6 months to WG documen= t

  - Info model: Ch= arter time + 7 months to WG Document

  - IANA registry = consideration + 10 months to WG Document

  - All Early Draf= ts to IESG: 10 months

 

[decision point –= +10 months] 

  - Data Mode= ls: Charter + 9 Months to WG Document

  - Applicability = Statements: 10 months to WG Document

  - Data Models an= d Applicability Statements to IESG  - 16 months

 

The WG will work closel= y 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=

--_000_9904FB1B0159DA42B0B887B7FA8119CA5CA27888AZFFEXMB04globa_-- From nobody Mon May 11 04:20:52 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 085801A6F1D; Mon, 11 May 2015 04:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ufLWI5dKZQK; Mon, 11 May 2015 04:20:43 -0700 (PDT) Received: from smtptc.telefonica.com (smtptc.telefonica.com [195.76.34.108]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34EAC1A3B9B; Mon, 11 May 2015 04:20:41 -0700 (PDT) Received: from smtptc.telefonica.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C25033A01A8; Mon, 11 May 2015 13:20:38 +0200 (CEST) Received: from ESTGVMSP108.EUROPE.telefonica.corp (unknown [10.92.4.9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtptc.telefonica.com (Postfix) with ESMTPS id 945B43A02E0; Mon, 11 May 2015 13:20:38 +0200 (CEST) Received: from emea01-am1-obe.outbound.protection.outlook.com (10.92.5.139) by tls.telefonica.com (10.93.6.52) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 11 May 2015 13:20:38 +0200 Received: from DB4PR06MB0624.eurprd06.prod.outlook.com (25.161.13.142) by DB4PR06MB0624.eurprd06.prod.outlook.com (25.161.13.142) with Microsoft SMTP Server (TLS) id 15.1.160.19; Mon, 11 May 2015 11:19:36 +0000 Received: from DB4PR06MB0624.eurprd06.prod.outlook.com ([25.161.13.142]) by DB4PR06MB0624.eurprd06.prod.outlook.com ([25.161.13.142]) with mapi id 15.01.0160.009; Mon, 11 May 2015 11:19:36 +0000 From: DIEGO LOPEZ GARCIA To: "Romascanu, Dan (Dan)" Thread-Topic: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93 Thread-Index: AdCI3eREQdBVQ8yORRe/7nCVEnyK2QBji2ZgAFaiOYAABXA3AA== Date: Mon, 11 May 2015 11:19:35 +0000 Message-ID: <5E241E34-B620-4A92-A545-BA6A7C3E6870@telefonica.com> References: <4A95BA014132FF49AE685FAB4B9F17F657C11DC6@dfweml701-chm> <9904FB1B0159DA42B0B887B7FA8119CA5CA27888@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5CA27888@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: avaya.com; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [79.150.196.178] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB4PR06MB0624; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:DB4PR06MB0624; BCL:0; PCL:0; RULEID:; SRVR:DB4PR06MB0624; x-forefront-prvs: 05739BA1B5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(252514010)(24454002)(77156002)(19617315012)(82746002)(33656002)(76176999)(5001960100002)(16236675004)(50986999)(54356999)(62966003)(189998001)(92566002)(110136002)(2900100001)(2950100001)(40100003)(122556002)(36756003)(87936001)(83716003)(2656002)(15975445007)(66066001)(86362001)(102836002)(19580395003)(19580405001)(46102003)(7059030)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR06MB0624; H:DB4PR06MB0624.eurprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_5E241E34B6204A92A545BA6A7C3E6870telefonicacom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 May 2015 11:19:35.4160 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR06MB0624 X-OriginatorOrg: telefonica.com X-TM-AS-MML: No Archived-At: Cc: "i2rs@ietf.org" , "netmod@ietf.org" , "i2nsf@ietf.org" , "dots@ietf.org" , Linda Dunbar , "Zarny, Myo" , Kathleen Moriarty Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93 X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 11:20:50 -0000 --_000_5E241E34B6204A92A545BA6A7C3E6870telefonicacom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable 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 (t= he days of DPI as we know it days are close to be over, given the current c= oncerns about privacy and the usage of E2E encryption) and rephrase the sen= tence mentioning it from "Exemplar services associated with Flow Based Security functions include de= ep packet inspection, packet/flow/stream filtering or pattern matching and = remediation, etc." into "Exemplar services associated with Flow Based Security functions include ma= lware detection, packet/flow/stream filtering or pattern matching and remed= iation, etc." Be goode, On 11 May 2015, at 10:43 , Romascanu, Dan (Dan) > 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 =91non-standard=92 rather = than =91bespoke=92 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 coop= erate with ETSI, so keeping explicit mentioning out of the introduction is = fine. Thanks and Regards, Dan From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Zarny, Myo Sent: Saturday, May 09, 2015 6:55 PM To: 'Linda Dunbar'; 'i2nsf@ietf.org'; 'Kathleen Mori= arty' Cc: 'i2rs@ietf.org'; 'dots@ietf.org'; 'netmod@ietf.org' 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=92m fine with the suggested deli= verables, milestones, etc. BUT we should tweak the first two paragraphs rel= ated to the goal of the WG. I2NSF shouldn=92t take a position on where the = security functions are hosted or if the caller and the security service fun= ction belong to the same or different domains. Also, not sure if we should = bring in another organization=92s name (ETSI) into an IETF charter. I=92ve taken a stab at rewording the first few paragraphs=85 Network security functions (NSFs) are increasingly provided and consumed in= increasingly diverse environments. Users of NSFs could consume network sec= urity services hosted by one or more providers, which may be their own ente= rprise, service providers, or a combination of both. Likewise, service prov= iders may offer their customers network security services that consist of m= ultiple security products from different vendors. Yet because no widely acc= epted industry standard security interfaces exist today, management of NSFs= (device and policy provisioning, monitoring, etc.) tends to be bespoke, es= sentially as offered by product vendors. As a result, automation of such se= rvices, 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 NS= Fs such as device or network provisioning are out of scope. The scope of I2NSF can be further divided into two layers: =95 I2NSF Capabilities Layer =95 I2NSF Services Layer =85 I=92ve made a few comments inline below as well. I=92m not familiar with how detailed a charter needs to be, so I=92ll leave= it others to comment on whether the level of detail here is sufficient, to= o much or too light. Myo From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: 7 May 2015 11:53 AM To: i2nsf@ietf.org; Kathleen Moriarty Cc: i2rs@ietf.org; dots@ietf.org; netmod@ietf.org Subject: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IET= F 93 Thanks to I2NSF contributors for the good progresses made since IETF92 sid= e 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 I= nterface 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 t= he Capability Interface. The thinking logic is: Once the Capability Interfa= ce is completed, we will see more clearly the work for Service interface. E= ven if Capability layer alone is standardized, it is a giant leap forward i= n building blocks for Service Provider to automate their Security Controlle= r that can utilize NSF by multiple vendors Here is the narrower scoped I2NSF charter. Your comments and suggestions ar= e greatly appreciated. CC=92ed to DOTS, I2RS, and Netmod groups for wider r= eview. Enterprises, residential, and mobile customers are increasingly consuming n= etwork functions, especially network security related functions that are no= t 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 i= nterface to express, monitor, and manage security policies to security func= tions deployed at different premises, it becomes virtually impossible for s= ecurity service providers to automate the service offering utilizing securi= ty functions by multiple vendors. The ultimate goal of I2NSF is to enable enterprises to utilize security fun= ctions not hosted on their own premises but instead hosted in service provi= der domain, to establish how to communicate desired security policies to NS= F 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 La= yer) - Security Policies facing clients (I2NSF Service Layer) The I2NSF Capability Layer specifies the functional security policies, whic= h 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 =93Subject =96 Object =96 Function =96 Action=94 = paradigm. MZ: Not sure if we need to explicitly specify a potential solution(=93Subj= ect-Object-Function-Action=94) in the charter. The I2NSF Service Layer is for clients to express and monitor security poli= cies for their specific flows, which is usually based on customers=92 logic= al networks, addresses and context. I2NSF Service Layer can also be securit= y expectation or loose security requirement, especially for customers who d= on=92t have the security expertise. MZ: I suggest =93I2NSF Services Layer provides a set of interfaces for cli= ents to express and monitor security policies. The policies may be intent-b= ased.=94 The concrete work at the L2NSF Capability Layer includes - The informational & data models for each category to be represen= ted 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 p= olicies between Controller and NSFs. The capability registry is to make it feasible to categorize network securi= ty functions provided by different vendors based on security policy provisi= oning capability without any need to standardize security functions themsel= ves. Standard provisioning capability interface is an essential building b= lock for Security Service Provider to automate their Security Controllers t= hat can utilize NSF by multiple vendors. This layer will leverage the exist= ing 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 clien= ts and demonstrating the feasibility of them being translated to the Capabi= lity Layer policies. Since different security vendors support different features & functions on = their devices, I2NSF will focus on flow based security functions that provi= de 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 Base= d Security functions include deep packet inspection, packet/flow/stream fil= tering or pattern matching and remediation, etc. Similar to I2RS focusing on the interface to RIB/FIB even though most route= rs provide far more functions than RIB/FIB, the I2NSF focused functions can= be a portion of features supported by vendors=92 specific devices. It is a non-goal to create new protocols or data modeling languages for I2N= SF interfaces. I2NSF WG Deliverables include: - Use Case document. - Framework Document. - Requirement for extensions (if there are any) to existing protoc= ols 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 ab= ove Information Model. - IANA registry consideration for flow based security function pol= icy provisioning capability. - (Optionally) Applicability Statements on how to use I2RS, Netco= nf, and NETMOD to carry the content of the specified information/data model= s. [The WG may decide that the Use cases, Framework, and Requirement are Infor= mational 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 W= G 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 =96 +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 com= municate with external SDOs like ETSI NFV and will encourage open source co= de development related to the WG scope in organizations like ONF, OpenStack= , ODL, and OpenNFV. Cheers, Linda Dunbar _______________________________________________ I2nsf mailing list I2nsf@ietf.org 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: diego.r.lopez@telefonica.com Tel: +34 913 129 041 Mobile: +34 682 051 091 ---------------------------------- ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o= copia sin autorizaci=F3n puede estar prohibida en virtud de la legislaci= =F3n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo = comunique inmediatamente por esta misma v=EDa y proceda a su destrucci=F3n. The information contained in this transmission is privileged and confidenti= al 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 co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, div= ulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o pode estar proibida em virtude= da legisla=E7=E3o vigente. Se recebeu esta mensagem por erro, rogamos-lhe = que nos o comunique imediatamente por esta mesma via e proceda a sua destru= i=E7=E3o --_000_5E241E34B6204A92A545BA6A7C3E6870telefonicacom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable 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 functi= on (the days of DPI as we know it days are close to be over, given the curr= ent concerns about privacy and the usage of E2E encryption) and rephrase th= e sentence mentioning it from 
"Exemplar services associated with Flow Based Security functions = include deep packet inspection, packet/flow/stream filtering or pattern mat= ching 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) <dromasca@avaya.com> wrote:

I am fine with the editing propose= d by Myo as it makes the scope more clear. Maybe the only thing I would sug= gest is to use =91non-standard=92 rather than =91bespoke=92 which may puzzl= e 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 char= ter 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 ca= se we say at the end that we plan to cooperate with ETSI, so keeping explicit mentioning out of the introduc= tion is fine.
 
Thanks and Regards,
 
Dan
 
 
From:<= /span> I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Zarny, Myo=
Sent: Saturday, Ma= y 09, 2015 6:55 PM
To: 'Linda Dunbar'= ; 'i2nsf@ietf.org'; 'Kathleen Moriart= y'
Cc: 'i2rs@ietf.org'; 'd= ots@ietf.org'; 'netmod@ietf.org'=
Subject: Re: [I2ns= f] 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 meani= ngful. I=92m fine with the suggested deliverables, milestones, etc. BUT we = should tweak the first two paragraphs related to the goal of the WG. I2NSF shouldn=92t 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 sho= uld bring in another organization=92s name (ETSI) into an IETF charter.
 
I=92ve taken a stab at rewording t= he first few paragraphs=85
 
Network security functions (NSFs) are increasingly provided and consu= med in increasingly diverse environments. Users of NSFs could consume netwo= rk security services hosted by one or more providers, which may be their own enterprise, service providers, o= r a combination of both. Likewise, service providers may offer their custom= ers network security services that consist of multiple security products fr= om different vendors. Yet because no widely accepted industry standard security interfaces exist today, mana= gement of NSFs (device and policy provisioning, monitoring, etc.) tends to = be bespoke, essentially as offered by product vendors. As a result, automat= ion 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 m= odels 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:=
=B7         <= /span>I2NSF Capabilities Layer
=B7         <= /span>I2NSF Services Layer
=85
 
I=92ve made a few comments inline = below as well.
 
I=92m not familiar with how detail= ed a charter needs to be, so I=92ll leave it others to comment on whether t= he level of detail here is sufficient, too much or too light.
 
Myo
 
 
From:<= /span> I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Linda Dunb= ar
Sent: 7 May 2015 1= 1:53 AM
To: i2= nsf@ietf.org; Kathleen Moriarty
Cc: i2r= s@ietf.org; dots@ietf.org; netmod@ietf.org
Subject: [I2nsf] F= urther Narrowing the I2NSF scope: the new charter for IETF 93
 
Thanks to I2NSF contributors for the good progresses made since  IETF9= 2 side meetings. Among the two I2NSF interfaces,  i.e. the client faci= ng Service Interface and the NSF facing Capability Interface, the work to b= e 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 fo= r one IETF WG". Therefore, we are leaning towards narrowing the I2NSF = scope to the Capability Interface. The thinking logic is: Once the Capabili= ty 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 Pro= vider to automate their Security Controller that can utilize NSF by multipl= e vendors
 
Here is the narrower scoped I2NSF charter. Your comments and suggestions ar= e greatly appreciated. CC=92ed to DOTS, I2RS, and Netmod groups for wider r= eview.
 
 
 
Enterprises, residential, and mobile customers are increasingly consuming n= etwork functions, especially network security related functions that are no= t running on their premises.  In addition, the European Telecommunicat= ions Standards Institute (ETSI) Network Function Virtualization (NFV) initiative creates new management challenges= for security policies to be enforced by distributed, virtual, network secu= rity 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 s= ecurity functions by multiple vendors.
 
The ultimate goal of I2NSF is to enable enterprises to utilize security fun= ctions not hosted on their own premises but instead hosted in service provi= der domain, to establish how to communicate desired security policies to NS= F and how to get performance data or report out of NSF or vNSF.
 
There are two layers of interfaces:
-          S= ecurity Policies facing security functions (I2NSF Capability Layer)
-          S= ecurity Policies facing clients (I2NSF Service Layer)
 
The I2NSF Capability Layer specifies the functional securi= ty policies, which are translated from the client security policies, to sec= urity 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 fo= rm of =93Subject =96 Object =96 Function =96 Action=94 paradigm. =
MZ:  Not sure if we need to exp= licitly specify a potential solution(=93Subject-Object-Function-Action=94) = in the charter.
 
The I2NSF Service Layer is for clients to express and monitor security poli= cies for their specific flows, which is usually based on customers=92 logic= al networks, addresses and context. I2NSF Service Layer can also be securit= y expectation or loose security requirement, especially for customers who don=92t have the security expertise.
MZ:  I suggest =93I2NSF Service= s Layer provides a set of interfaces for clients to express and monitor sec= urity policies. The policies may be intent-based.=94
 
The concrete work at the L2NSF Capability Layer includes
-         = ; The informational & data models for each category to be represented to vir= tual 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 betwee= n Controller and NSFs.
The capability registry is to make it feasible to categorize network securi= ty functions provided by different vendors based on security policy provisi= oning capability without any need to standardize security functions themsel= ves.  Standard provisioning capability interface is an essential building block for Security Service Provider to = automate their Security Controllers that can utilize NSF by multiple vendor= s. 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 clien= ts 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 p= rovide treatment to packets/flows, such as IPS/IDS, Web filter, and flow fi= lter. (They are different from other security functions such as Authentication, Authorization, or Encryption). = Exemplar services associated with Flow Based Security functions include dee= p packet inspection, packet/flow/stream filtering or pattern matching and r= emediation, etc.
 
Similar to I2RS focusing on the interface to RIB/FIB even though most route= rs provide far more functions than RIB/FIB, the I2NSF focused functions can= be a portion of features supported by vendors=92 specific devices.
 
It is a non-goal to create new protocols or data modeling languages for I2N= SF interfaces.
I2NSF WG Deliverables include:
 
-          &= nbsp;Use Case document.
-          F= ramework Document.
-          R= equirement for extensions (if there are any) to existing protocols used by the WG.
-          &= nbsp;Gap analysis of existing protocols and modeling languages
-          A= single, unified, Information Model for expressing policies to the Flow Based Security Funct= ions described above.
-          C= orresponding Data Models (e.g. YANG models) derived from the above Information Model.
-          I= ANA registry consideration for flow based security function policy provisioning capabil= ity.
-          &= nbsp;(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 o= f the WG. The framework, that describes the functional components and the I2NSF work ite= ms, 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<= /div>
  - IANA registry consideration + 10 months to WG Document
  - All Early Drafts to IESG: 10 months
 
[decision point =96 +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 com= municate with external SDOs like ETSI NFV and will encourage open source co= de development related to the WG scope in organizations like ONF, OpenStack= , ODL, and OpenNFV.
 
 
Cheers,
Linda Dunbar
_______________________________________________
I2nsf mailing list
I2nsf@ietf.org
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.lo= pez/

e-mail: diego.r.lopez@telefonica.com
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------



Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o copia sin autorizaci=F3n puede e= star prohibida en virtud de la legislaci=F3n vigente. Si ha recibido este m= ensaje por error, le rogamos que nos lo comunique inmediatamente por esta m= isma v=EDa y proceda a su destrucci=F3n.

The information contained in this transmission is privileged and confidenti= al 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 y= ou have received this transmission in error, do not read it. Please immedia= tely 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=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, divulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o p= ode estar proibida em virtude da legisla=E7=E3o vigente. Se recebeu esta me= nsagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mes= ma via e proceda a sua destrui=E7=E3o
 --_000_5E241E34B6204A92A545BA6A7C3E6870telefonicacom_-- From nobody Mon May 11 06:35:31 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1CE91A87A5 for ; Mon, 11 May 2015 06:35:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_HTML_ATTACH=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BDz6FRAhcJNu for ; Mon, 11 May 2015 06:35:24 -0700 (PDT) Received: from smtpjc.telefonica.com (smtpjc.telefonica.com [81.47.204.76]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 948861A877C for ; Mon, 11 May 2015 06:35:12 -0700 (PDT) Received: from smtpjc.telefonica.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 42BE31B83E4 for ; Mon, 11 May 2015 15:35:10 +0200 (CEST) Received: from ESTGVMSP108.EUROPE.telefonica.corp (unknown [10.92.4.9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtpjc.telefonica.com (Postfix) with ESMTPS id 24DB71B8336 for ; Mon, 11 May 2015 15:35:10 +0200 (CEST) Received: from emea01-db3-obe.outbound.protection.outlook.com (10.92.5.139) by tls.telefonica.com (10.93.6.52) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 11 May 2015 15:35:09 +0200 Received: from DB4PR06MB0624.eurprd06.prod.outlook.com (25.161.13.142) by DB4PR06MB0623.eurprd06.prod.outlook.com (25.161.13.141) with Microsoft SMTP Server (TLS) id 15.1.154.19; Mon, 11 May 2015 13:35:07 +0000 Received: from DB4PR06MB0624.eurprd06.prod.outlook.com ([25.161.13.142]) by DB4PR06MB0624.eurprd06.prod.outlook.com ([25.161.13.142]) with mapi id 15.01.0160.009; Mon, 11 May 2015 13:35:07 +0000 From: DIEGO LOPEZ GARCIA To: "I2NSF@ietf.org" Thread-Topic: Merging draft-pastor-i2nsf-access-usecases and draft-qi-i2nsf-access-network-usecases Thread-Index: AQHQi+9KJGoo9SWpm0merEafcazIaA== Date: Mon, 11 May 2015 13:35:06 +0000 Message-ID: <9488CAA6-4890-4072-B712-10F0A71F4E95@telefonica.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [79.150.196.178] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB4PR06MB0623; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:DB4PR06MB0623; BCL:0; PCL:0; RULEID:; SRVR:DB4PR06MB0623; x-forefront-prvs: 05739BA1B5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(51164003)(66066001)(230783001)(2351001)(102836002)(33656002)(36756003)(86362001)(189998001)(99936001)(92566002)(229853001)(50986999)(54356999)(106116001)(2501003)(122556002)(82746002)(2900100001)(2656002)(40100003)(87936001)(46102003)(83716003)(450100001)(62966003)(19580405001)(77156002)(19580395003)(5001960100002)(110136002)(107886002)(16236675004)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR06MB0623; H:DB4PR06MB0624.eurprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/mixed; boundary="_005_9488CAA648904072B71210F0A71F4E95telefonicacom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 May 2015 13:35:06.4864 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR06MB0623 X-OriginatorOrg: telefonica.com X-TM-AS-MML: No Archived-At: Subject: [I2nsf] Merging draft-pastor-i2nsf-access-usecases and draft-qi-i2nsf-access-network-usecases X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 13:35:29 -0000 --_005_9488CAA648904072B71210F0A71F4E95telefonicacom_ Content-Type: multipart/alternative; boundary="_000_9488CAA648904072B71210F0A71F4E95telefonicacom_" --_000_9488CAA648904072B71210F0A71F4E95telefonicacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, After some conversations we had on merging draft-pastor-i2nsf-access-usecas= es and draft-qi-i2nsf-access-network-usecases, I asked our colleague Michae= l Georgiades from PrimeTel, who is collaborating with us in the SECURED pro= ject, to review the merged draft. I am forwarding his comments... Be goode, Begin forwarded message: From: Michael Georgiades > Subject: RE: Possible to merge draft-paster-i2nsf-access-usecases and draft= -qi-i2nsf-access-network-usecases? Date: 8 May 2015 at 10:36:57.000 GMT+2 To: ANTONIO AGUSTIN PASTOR PERALES >, DIEGO LOPEZ GARCIA > Hi Antonio and Diego, Thank you for the latest version. Please find attached some comments from m= y side and corrections in the attachement. One thing I see lacking under the security functions (section 7) is authori= sation related functions where the vNSF could provide value added features = compared to legacy methods on who has access to what services, and where th= e interface with user and operator is important to support this. This from my side for now. Michael Dr Michael Georgiades PrimeTel, R&D Manager The Maritime Center, 141 Omonia Avenue, 3045 Limassol, Cyprus Tel: +357 25 867000, Dir: +357 25 867212, Fax: +357 25 028422 CONFIDENTIALITY NOTICE AND DISCLAIMER This message contains information, which may be confidential and privileged= . Unless you are the intended recipient (or authorized to receive this mess= age for the intended recipient), you may not use, copy, disseminate or disc= lose to anyone the message or any information contained in the message. If = you have received the message in error, please advise the sender by reply e= -mail, and delete the message. PrimeTel Plc ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=C3=B3n privilegiada o confidencial y es para uso exc= lusivo de la persona o entidad de destino. Si no es usted. el destinatario = indicado, queda notificado de que la lectura, utilizaci=C3=B3n, divulgaci= =C3=B3n y/o copia sin autorizaci=C3=B3n puede estar prohibida en virtud de = la legislaci=C3=B3n vigente. Si ha recibido este mensaje por error, le roga= mos que nos lo comunique inmediatamente por esta misma v=C3=ADa y proceda a= su destrucci=C3=B3n. The information contained in this transmission is privileged and confidenti= al 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 co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=C3=A1= rio, pode conter informa=C3=A7=C3=A3o privilegiada ou confidencial e =C3=A9= para uso exclusivo da pessoa ou entidade de destino. Se n=C3=A3o =C3=A9 vo= ssa senhoria o destinat=C3=A1rio indicado, fica notificado de que a leitura= , utiliza=C3=A7=C3=A3o, divulga=C3=A7=C3=A3o e/ou c=C3=B3pia sem autoriza= =C3=A7=C3=A3o pode estar proibida em virtude da legisla=C3=A7=C3=A3o vigent= e. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imedi= atamente por esta mesma via e proceda a sua destrui=C3=A7=C3=A3o --_000_9488CAA648904072B71210F0A71F4E95telefonicacom_ Content-Type: text/html; charset="utf-8" Content-ID: <159654C3EF4881468DAFE4B9DA076E2F@eurprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Hi,

After some conversations we had on merging draft-pastor-i2nsf-access-usecases and draft-qi-i2nsf-acc= ess-network-usecases, I asked our colleague Michael Georgiades from PrimeTel, who is collaborating with us in the SECURED project, to review t= he merged draft. I am forwarding his comments...

Be goode,

Begin forwarded message:

From= : Michael Georgiade= s <michaelg@prime-tel.com&= gt;
Subj= ect: RE: Possibl= e to merge draft-paster-i2nsf-access-usecases and draft-qi-i2nsf-access-net= work-usecases?
Date= : 8 May 2015 at 10:= 36:57.000 GMT+2
To:&= nbsp;ANTONIO AGUSTIN PAS= TOR PERALES <ant= onio.pastorperales@telefonica.com>, DIEGO LOPEZ GARCIA <diego.r.lopez@t= elefonica.com>

Hi Ant= onio and Diego,

Thank you for the latest version. Please find attached some comments f= rom my side and corrections in the attachement. 

One thing I see lacking under the security functions (section 7) is au= thorisation related functions where the vNSF could provide value added feat= ures compared to legacy methods on who has access to what services, and whe= re the interface with user and operator is important to support this. 

This from my side for now. 

Michael

Dr Michael Georgiades
PrimeTel, R&D Manager
The Maritime Center, 141 Omo= nia Avenue, 3045 Limassol, Cyprus
Tel: +357 25 867000, Dir= : +357 25 867212, Fax: +357 25 028422

CONFIDENTIALITY NOTICE = AND DISCLAIMER

This message contains information, which may be confidential and privileged= . Unless you are the intended recipient (or authorized to receive this mess= age for the intended recipient), you may not use, copy, disseminate or disc= lose to anyone the message or any information contained in the message. If you have received the message in = error, please advise the sender by reply e-mail, and delete the message. PrimeTel Plc
 


Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=C3=B3n privilegiada o confidencial y es para uso exc= lusivo de la persona o entidad de destino. Si no es usted. el destinatario = indicado, queda notificado de que la lectura, utilizaci=C3=B3n, divulgaci=C3=B3n y/o copia sin autorizaci=C3=B3= n puede estar prohibida en virtud de la legislaci=C3=B3n vigente. Si ha rec= ibido este mensaje por error, le rogamos que nos lo comunique inmediatament= e por esta misma v=C3=ADa y proceda a su destrucci=C3=B3n.

The information contained in this transmission is privileged and confidenti= al 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 y= ou have received this transmission in error, do not read it. Please immedia= tely 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=C3=A1= rio, pode conter informa=C3=A7=C3=A3o privilegiada ou confidencial e =C3=A9= para uso exclusivo da pessoa ou entidade de destino. Se n=C3=A3o =C3=A9 vo= ssa senhoria o destinat=C3=A1rio indicado, fica notificado de que a leitura, utiliza=C3=A7=C3=A3o, divulga=C3=A7=C3=A3o e/ou c=C3=B3pia sem au= toriza=C3=A7=C3=A3o pode estar proibida em virtude da legisla=C3=A7=C3=A3o = vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique= imediatamente por esta mesma via e proceda a sua destrui=C3=A7=C3=A3o
 --_000_9488CAA648904072B71210F0A71F4E95telefonicacom_-- --_005_9488CAA648904072B71210F0A71F4E95telefonicacom_ Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document; name="draft-pastor-i2nsf-access-usecases-00-zxj-mg.docx" Content-Description: draft-pastor-i2nsf-access-usecases-00-zxj-mg.docx Content-Disposition: attachment; filename="draft-pastor-i2nsf-access-usecases-00-zxj-mg.docx"; size=30476; creation-date="Mon, 11 May 2015 13:35:06 GMT"; modification-date="Mon, 11 May 2015 13:35:06 GMT" Content-ID: <555DA22B52D18143B234142925F7C31F@eurprd06.prod.outlook.com> Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQCM4VCwlgEAADAHAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0 lclOwzAURfdI/EPkLWrcskAINe2CYQmVKB/g2i+tRTzIfp3+npe0iRAqiWjJJlIU+dzr+4aMpztT JBsIUTubsVE6ZAlY6ZS2y4x9zF8G9yyJKKwShbOQsT1ENp1cX43new8xodM2ZmyF6B84j3IFRsTU ebD0JXfBCKTXsOReyE+xBH47HN5x6SyCxQGWDDYZv5GBoBUkMxHwVRjS4VsXFM+dQ+sQYko4ljwe zpXSGRPeF1oKJON8Y9UP0YHLcy1BObk2JJWWOB+chBjpaqZIG/RNieYtJqQzJaIHDzW5tvAEuVgX mDzvKJ5DRQIU8W8XPyad0skqnLjSPrYotCfbFU4TcDvmjAI1ZCO0rf3/2il2bRYQqLT/3ykNutNE xH3RR68euJ3yYFVPw1KT2yxQvWbB+chpMC8uApQToEANaGY9BNTQtPCvLRABkRqghzmtyW3Xr/YV 0v4DXj1HF2dQYTolc9qJc7Eo4GK9EyvyiO40sYXFe2/pf4O3GWn6T7pwRhj12ixPn+g6Xv3vJl8A AAD//wMAUEsDBBQABgAIAAAAIQAekRq38wAAAE4CAAALAAgCX3JlbHMvLnJlbHMgogQCKKAAAgAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjJLb SgNBDIbvBd9hyH032woi0tneSKF3IusDhJnsAXcOzKTavr2jILpQ217m9OfLT9abg5vUO6c8Bq9h WdWg2JtgR99reG23iwdQWchbmoJnDUfOsGlub9YvPJGUoTyMMaui4rOGQSQ+ImYzsKNchci+VLqQ HEkJU4+RzBv1jKu6vsf0VwOamabaWQ1pZ+9AtcdYNl/WDl03Gn4KZu/Yy4kVyAdhb9kuYipsScZy jWop9SwabDDPJZ2RYqwKNuBpotX1RP9fi46FLAmhCYnP83x1nANaXg902aJ5x687HyFZLBZ9e/tD g7MvaD4BAAD//wMAUEsDBBQABgAIAAAAIQDegMHnMQEAAEEFAAAcAAgBd29yZC9fcmVscy9kb2N1 bWVudC54bWwucmVscyCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKyUy07DMBBF 90j8Q+Q9cVKgPFSnG4TULYQPcJPJQ8SeyJ4C+XtMUdKUVmbjjaW5lu89GtuzWn+pLvoAY1vUgqVx wiLQBZatrgV7y5+v7llkSepSdqhBsAEsW2eXF6sX6CS5Q7Zpexs5F20Fa4j6R85t0YCSNsYetNup 0ChJrjQ172XxLmvgiyRZcjP3YNmRZ7QpBTOb0uXnQ++S//fGqmoLeMJip0DTmQheoaZcbjtwptLU QIJNUuxIGT8PcR0SwgKRa689MIyKD+EuJEKB6qdFM4RR8SEsQiJYGjr3lqZ7+K198WnIeL1TWzDu Gg4Ek+SDWIaEAF1qpHkXRsWHcBsSoUKkPwyT5IO4CQnxCdvXk08xE30gDyFByM2t2WzYl3y/piMD Pxp82TcAAAD//wMAUEsDBBQABgAIAAAAIQCYHysaYT8AANMUBAARAAAAd29yZC9kb2N1bWVudC54 bWzsfetS41i25v+JmHfYwYnozowC0jaQXLqTEySQ3cTJCwNUTZzu09FHyNugQpbckgxJRv6Y15jX myeZb+2LrG0sME4Zy6mVVYGNZGxra+11/da3/vzvX/uhuJVJGsTRu5X2emtFyMiPu0F09W7l14sP azsrIs28qOuFcSTfrdzLdOXf9//n//jz3V439od9GWUCbxGle7c4e51lg703b1L/Wva9dD0eyAgn e3HS9zL8mly96XvJzXCw5sf9gZcFl0EYZPdvOq3W2xXzNvG7lWES7Zm3WOsHfhKncS+jP9mLe73A l+bB/kUyzefqvzwyX1l94ptEhvgOcZReB4PUvlt/1nfDJV7bN7l97CJu+6F93d1gmk/rJt4d7kc/ 1F/7Lk66gyT2ZZri6JE+mb9ju/XYZ5sFpLfI/2Kar+B+pv0mfS+I8rch6Ri7//nNW8fNe6M/+w29 1ehCsBb7kKXLuHtPjwNxtwdZ7J69W4FMHLa2Opsr9tApbvSDg0ey5w3D7OGZ08Ih9c6nCT14wyw+ H3i+PDrG+956IV628sY983n8TPf3YZqdBVfX2UnUHTv5u28PhLKX6bdK9GclH+IoS3HaS/0geLdy HvTPh1iwuz3ppdlBGnjFY36a/6a+z41MIvvW5ium3+yBToc+6Q0Wiz4KjwPzkXiBWj9nsejyXvo7 3e1l+59lhrt9I/43fkBUxV+SeDgQU/87WBenWKg4oQvM9OXqi1U31F5q4UbbQ87V24MsKjUWlZMo g7zLbA36rJdNLSL5C4/WxUeYm28sKj+9ViFRibqyS35JNkz3xPHXgUwCckW8MBeISU8uJHR0HAW+ J05+OWJR+elFBZIRJBIicjBIglB0dlZFp9XemiQbzrEvfhZfykR0ttQfbLKoVC4q5LOwGbc+4awe 35xWcfegtdV+qzxz41i+iN8cD7MwiOTH2xA+W9E3f2nntaYONYXIeylFL+9WBtBrMrmVK/vQXAc+ RYPi11SKQy+VqUDILbxIfEEALhzldbeHUIxM5ZkXXcnzzEsyrHXQzcOgxLrLjg+9oAhi8gV/Ofgk lL/Yw0o8dnnHKlqbdHEUM2xtdra3dpSQW/k6z+5DaWXv0CyU7MkEORFZjLhGy2jPFlcR4gNXGz/q tJb7WSx+C5Js6IXBN3hP59IfJsi+OOLB+qRJAfrk7eV4QhN+OYfaQRYuZcFpbGZnSsFxJISSfPEN 5X+LVqdN6bDI68Oiffl4/M+PJ5//Y1vltia/vDPh5Rs66Tbp3TcmvHzT5OhqpZuR4kWKe6CyXWtB J0p7a56y6WvDVPpk0tdarZLlHFm5trsSoxNjKzo6odZuTkrfpG+Vk9+A5OucVpFd8Xrmtg8u0yzx /MzZlHOSAd5JD+o+TnRiVTln+Oub4S91GS6ug1TkteSuTP0kuEQIm11LAeMnlPVTAS2KnrcBVaYF CgWqsATb+GIxTMM2Yc2i11Lx8VLhCcqEICQRQaTERrtOuZTI6DZI4oiyHutCnGTCR80/6AL0IC7j 7Jo1eOXJ3WURnn4MBIpEpqwrkE6DSERZgBqSlp91FozKBWNODhI7yfV0khHpo0Ir4h7UMqz8J9mP eVPxpsqLDZPAU1wEQuWgDOkFHFSpJ6Qc6TEcDTZdOrzsB1mGjD+8o94wDMn9UZBM1DTEXZBdk8/E 27LybbksTpAKqwj/qxT1+8NTsb2jXCL1dJfdoOqBmnNygzhEVYDhWhWrUUBzdTLi1QR610BibeLD OEkyf7E4jq6AhQCwLbp6CeXMLnQtXehya++lN+JDnMCGvzo5vvjwGqmNz3EmYcy9TCCtAfjaFeGt U9H37oUXprHoBshZB5fDjM199Tp9Wcz9Q82DFNqYioIsXSD9GkJeKHhDkhUImGz0qpdQSGzMamnM FD4/FQgsoGZMv0/XQ5yPYhhaVtYDmfVUp5cqaadvjOy8YTeyepXDbuTez9c1VWrxx3S0ciPVJsur Z6kAaDboavQnzP7XoD/skwJPg6+ij2a06xcBbbHmrqXmpioHuYKXqKsOoLJldxVVj0EIEC2eATAc X6ZxKClTdHlvPMhReAJt70UvAhZl8aml+GTosNLlU9j+IPIGyBuhqwZyJIAspkr9AwWVQr4MeJo9 xsbmF9EYjywGyqpQMZAUP1BBqoRhUkEq4tVIIARZUYgO5KghV1eoxqbrKyw0lQvNnFxGzh4tWfaI yrGuvkYpCLUhqTomRRyNtUxy+LY04RvvxVruxf3DeHCfEIkI5WmBVmPrtizWjSOSWkYkow31yn9N jf2bgioh4iIBXY+qYMPBFOCGSKm2rdF9vQDhLbxNnOH9V/n+W5YaiE1rCLS1X8dJirj2AM6P0s4U tKrO6i77POzzjPjBGKtGuIpnsJI9iVXLd6FGqf0u/YwSBAUEEunvkUr/Yyo+yisvfAnFzU50LZ3o 0uLIKfUGaRDbmaJ1RJcQZEkJz5FhfeTiR/X6fFks/itTqs7IN5RyVKYOEYlFqVwLgIl9TRBZ2euR IkIGhLQP1UlQQXsJlcNRRi2jjMHwEjKiiGLzRgZrueA3noYg85TwGW8DeUcig1/saVY4zVU4PlCe hLa/XzXh5r2wva3iPh4mNtgwvWfA5fmKi1gj8hGCDKCFWO00NkSF86J6pqwugao5jLvg9wJzNpi4 iVhYfiXQFdXre0ncd18u+rBzLD4/ufiEIIw5kyBDTWT31LuS7xPp3SguwfI2oSDywyEECWzUgzBQ +bD350fio/aDRAapIo1llZVqGwJXGCknsbnOzlATmLtLwyxyiXV6VUXiohB2kSGjzgaU78HSAKVE rWVo5hN3XpJ4UQYMOvtDzfWHHH1CYjRZ/3DOtXoRmRPmo2HxKq9iFWBrXkVeRU3tzONSXELhbP9U 0T+KP3j9wZ/0NIsC+6qhsh+DZRVeoJ/+ncIA0f4Hh34/eeh3SeTS2f2AqMBxy60s7dONZ2L9n2yU 0iNx/v4YitNqhINJlPAnnc/nH+wr8JjPuQB2hjVG5RqDt2KNnR2u8Neywr9/4V2Ckg9Ni4doWKQ8 NysmVkyPMobZ6R0NH7dYmrRtU9telCVxd6jT+GL92f9t8C6sfBcuC3amA/k5k/8aYpQacegChYfZ QUOKM6eXI3Yvq8/rLov8bEB+DjBRD3zLhqDZBCfHI2Jm8YQssfw0V342IT+YZJZ4EKG1T14EzTMa XyU+DCODnHlMG7H8NFd+BHAL5APdUvLjCIwX8T3ZsSc0jitNW+z/NNb/IfkhH0jJzyFwVXEf5Ho5 9IEGUjwpSyw/zdU/W5AdKzaz2i+Wn+bKjxBbyn6dy7C35qgd10Y99hvLT7Plh+zXb0QOpxsZnrRX 47LE8tNc+XkL2TmN0QQTYCwXwTyRme8FV0MEZAQKnkqW3rL/3Fj/eRvyY6dNF8J1MAoSDtTkgj6b kW4l0rTN8tNY+RFiW/k/FxiS2wt81DJUc9TUuodsGctPc+0XyQ/5P1Z+kEIMBsPwGdaL5Sc7aLb8 UA3jpK+5hLTgjHvIj//O+qe58rNT9H/gO6vZo0qI0hJv56Es7bD/01j/Z5d0z8HnA4q7ZpEdkiaW n+bqn3ZrHfgNQ8SdThevj2sglp/myo8QkCAUUD/HCbi8g1s5gzSx/DRcfhCAneixozNJEMtPc+Xn QJN0/lEcdLs0GABZ6Kn9ZmvHWH6qlx9ub6lxewt357daZg3QKJkgbjo7TdBGMH7wSPa8YZg9PHNa OETMp4PThB7AGByfDzAz6egY74t5W3lrwujM5/Ez3d+BGjoj7vcTlM/cP5vEK7uojgbe0byj69Kd z7LIssiyyNYFhpttNFwP0ofkgrBeZL3IepH1IuvFPRUmsV4M+ufDaAVhZQXDsNm68CqydWHrwtaF rQtXDEbJXc7SaqvQIqLBYhacc92b5HpRgYErBrAaMJ3jJRauu6TfbNGn07FMnTaXYx9VjclIEq/i cwYNcgTIESDtHrbRbKNNqZ8rBlwxyDmgq8mM1YxtrUK2+A6zxVcf6tZLXJgtXmfIMavz5+9kZLZ4 B5bH4LutzuaKCi8ZwjgrEJTZ4i0AluaOPFxFEq+XRq1i/sn+OLc1t8lW3ibLJeEqSsL18gfLx8Ne XAcY/hr7Q0WRaqc2poqqZ4jZ5j6mnaeiFydgghLxQEbiy8En8DpnMun5UmQx78DKd+CyyM5tkGRD kMx9Az9zZPicUukPkwDTX1OZ3GLGsOIARxcXRsRGWeCFilCsH18GoWTJaazkWGnx1NQqHgJbfT6C rXiTrPjnOBNxFN4LKFmZDJKALLdhrk5XxSXGcnthGovJihh/KnnsUvV7cFnsOI1xv5R+3Cdq836M 34j1Uz/BNHc1nYuoGyMJQ0+uoDXyq4IaHdkJ/PlzjOUBRC+ArGTXYPe0UjFy/Uh2rr0E52OKHUAg q0VLCZsU8iviiRQEI+wJNtYTNBOCKMykIYAJMvZxhJGACCDiAWLTLPAhNV1loojTkcLVKxlBlkKR JRKyd+2x7Wqu7fI9ZCmMAoqQxEjiYWp0DQ2gIkOW66VbiAsdTDMvIaslQnkLQbpi/dNg+QnjYXft EuqHPJ6uDJH6igUeYZZGjg6UUTgk9vOUuPkiMYAABT44ZZNVypSx/Wqs/erL7DruQtFA8UDXWFpz O6VM/GZzZJpF9tXnD7+9xoul6EsPM6k4f9pgouGe5wdhkJFXTOFVX426U3l4eEK3XhKQLUPIHg8T SqRS5EWvu4T70wsQ8PdY7zRW7xSyO3fXMWTnXkSUBLpDlSYRg+v7FI5zCDf6OqYIHT8pfs/u4uSG paaxUtOzwzM55V69y8sp9yal3N3COUx3eP8NRpoMtFs3pyODJL4NUsQPqyY2pWEmiE1ZFTdWFY95 ezZMQBhqY4hzW0rPg4lXNJL0tZmqzbLTWNnRZXPrz6HoByRGHFHksCo85LeuyQ00mdVeHIbxHVV2 1Aw3yZafLT/3uf+8nK7LUnQW+GenJOPpL/S7HQ5IT/WBQ1Sj2dA11tCRIBT+fS88V0/1gV/WzL9f WFRYVLSMFERlVUkHhAS1m+/Wuf7OosKiMiYqq38cHfjvte9fFGIlTlhUqveYl8ZLyW0LlMgvwmqV N+owXBR94Punq34mzu9TFpUGi8r3s1Gbw/c1Izhv1lynBKydcZ8i9TMvupLnColytxd0361saqqt evXb3R6eHjuW0v3+xyh5T/72xAvV3m59ONhQrai2V/A8uw8l/kR17B6albCz6opUSaPPsWeLH4RU OwgvaqZE9q1SELnScO89FwiaVCAYSUHBdLxBYEvuqDYd/6X9DfVzz9lmLCqNEpWCHOCpciogKfk/ OlCQFfYyGuxl5EKhnpBk/Kl4SMmOVTEQJdYqHOZq+SDJUNJhxUX98p1KivoZiwqLykhU9qyY0KMS ENYqaupCIzilyvu9imJhJaMoKyQqBd+FDVCzfZVRKKyVCImKVSQQlYKkiD+xAWq0Afr+SdGCwNqY 5Nl/IU52ZGKUFBpPnm3VMnl2fHr4yPcfJc/Gv/3ckmfqg2qePLMG5o2zdJwQaVpCZNxyUAqkYDlI TE7OT8Xq2h9ZUBptN6zCwKOKU/D436rYPzrwz3WWkgY32hUkhJ5aKaHnkBR4GfTjj6xHmh2qkDiY fxp8aH/Do+uHsjNShTPCq1jjVWQCZEuAXIbXeFvDkFN87Yd76cDz5buVATrHwcEpV/YLemz09ENw NQQNQXtvhMI+UGyMtv/I8ardyHsUuY4vwtwiV/VBOnJlvVFjvfH2sMX083oNJhKn24M8sYgnFlU8 sYj1IutFnuUND0Q7Zt4wM11+PLOWZ9YCLDywtpecVOOn2EM8s/apmbV1A1ufYrQXmI7+4PUHfxIf wS77bRTbiOOvgwDhjzgAFXYoOjurotNqbxVeoJ/+/RTkj2KD5+H97Ik/nofH8/BgAbL9E+LHBw/a 2lHi9bJcIZjMx68gSTvMB96cdACNzF8ixBc/iy9BCgpVsukkR9jxZsf7J3e8OR1s08H16s/roKf9 TP5rCG+HmgpT8RHIqCFTWs9jIgOr+SrUfM3iiNKKyQVo+27kvQBjKuidVz79en6xsqofxecv6vnZ 8f/69eTs+IiOn//14OPH/Il+BTsJjcUlQR6+/PrRSAY9G8nM4ZdPn44/H2mx+XTwnxAamlKw8uX0 4uTL54OPK5q5LeCpFj97VFreZJEP5CSmeMwjuJR65CZqujQMBRx/dlJnl6Tl72cfDjvt9u4/mNyv eplhs98ks4/hHllxJK6a74G0gHYD7oIQE0wHA+khDAiya7wWg6/UNFzammrGA1v9xlp9NYLx7hpD kqGU4Q+Kw4PTc0RoH+M75I3UjCtwQ2M+UY94onOpIiVP5P1K0bP4NFZ8cj2iTbzvJck9EffCuq+R eRdpcBUFPQx2iHzm8Z0Dnp1NfRWmfk6ryCnIeqYgN2DgDlAawWA9QzluqinHI1pyNmqVG7U57bKG 4TeXJRt5FPR6EuNO4STeD7QH6ewpF59dpBXcriFMfd9T+uKRKxghzMe/P4F3dlqtzfdvKyYWVB+E XVU/YsGSHDXcQDVqBg+Av0Tiy8EnHYpirpzKGtHkGaL34Uxi9VmhZVEciCkxBi6mIcoqzWzHcJtZ cKPhuKPRYDRlGcO5Yb1pYpHkIUXNlR6tp2leKdNTVi8F7MJVEW4uiyaOhe2sK8wnV/ljNR2uq/Wz HgumzLYJp4LE8ZNYaJokNIAfet1+EAVplqC6cCtFN+57iLPVLGDMnL66FvIrYRq9UE8Z7Mok5TIg K+t6zvhaImVth1OlwGeoxmhKxWfXes9RaGVHydg5IRrHkSg0Hr3WY71dedZrWeQHeju14zupCz9A RB70B6FCaaK8c3kvEFqRFu9jwpky96y0l0ZpcymilqWIkjyZzmdoHZ7PTM2kfx3FYXx1XxyfilxJ GgNb1QsiPcuZVXhjVbh/7SXIf8gEvnfgW9CGyr8TgMPIE1xx6fnX+cxvzpMsjRbnUldO1WLHM32I qYfkbs9L/SAo0lNUTHqOVrxSZY08yWEYp3CSCnOt8aWuUf8i2BR+BtiNUahdqLHw2OS1WW83Vm/D 9dY5EuASPpFzjTGO/SBNKXlilLYPMU/iMFUVkTC4uoaWFxhJFnQZwYm2+jkgq5YpbrtGwYwQ91Q3 u4MaCqI0QHaWQn6TfLuUvgcgp8FxUt4N7iSA+ax1mqx1CuYKqoc6za8oZxtHGiouv5IjibwQhCnK guxe6Fw/9W2y4DRZcNL7NJN9wOdgkCj+HMSwVpchQ3znYIi4fNak8hliCWTnEaKPoKg2kkjjvkFH oTEjInt/HWMbqn46W1FjtdxktTwWWWrfj6pB6NZVWXswTGVJ4KuybJ7tH8UWiWT5abL86Eqg7MIZ JECd6u4haGZKjV4UTShspugP00ylD7MEz6CAkHiMIhlyFX8O5n+J4tATGyb0Eq8v0X96o/MVPQmI h4or8DvSG8RPjhijH3chM6IXM1yo+gz0EokNaE/RgIqKhQ49yVgd4FCcBN/UES4zVy8eHFRUEVTM aRW5WF/LYv3+JvwiC51a++RFIC3rinMLmvkwjOBYxxH3rrC6Yiij5TQvI2m+2wtRtzmTEVxD2SVW 4/eJ9G7e7BPpaWmllaKS34IkGwI7fHh6LJxw9W4PdQ+UgoPuu5WdFaoJKy/i3cqnAAGKDMVfZJxc BR6IiOgsKmeYOUMsy2st/L990e7stfB/62+6TQ8vSVBGOaP2vc23na3jXad9b+GF59SXkZcEsbsI MElYBVrFetE+uuxPnz/89uvhP3IISir+bUslKf5tG8HBLUqb8AidezsnS8uAiloCKlRkSLXKW73X TSBAoSKixssg1J0nyGbpyhS0ga6Tr45AFyw+jc1k6Y5RkhUPiJteL4y97gNwMxIPSdxXWS0fWSzk 1hNBXachC05jBadQdBGvID/yFpUYynsCbYOWJi98bROhuYgFEZJdSKoP/WzI6fMG5z/T4WAQJwou QRLjgrc5hbU0MSEnX2qZfCkNCR1zXU4qs1tHUpkL4u0kWB4RLT5yISNumfHLKAlOz7N7+Mh3esTD IcotyK+fScXH40taCcRTBkFth8Xas/grCqDVB9GrahdKlkjC2PKNUgHtFucC6pYLyLuVcmIBXWxG 90qOPqRaM5wv1b3q3FzOBdS4dtGwjArLIstiXQYp1S3lW928w02ed1h9/FQvceF5hzzvkOcdngD7 ZKI2MxP6d98eCGUvM0HsqY7KXqoESU4OfSQ7O+zssLPjAdzR6bhJlHLEAs107wNpQF0aqCIoNDUm tNwPAHcM0RAOWp33nfcKEjuMDAQypQZg1Dr7+KvLe459G1uPokJCXmka9V4K23736sv5+Zv35+ev ub5QvX88J2vH9YVa1hcA7mwD3qmSjkdyEMb33OU8F14F3lYNCvTK/aILmLZuvs+IkAJtZin8IFBX pGD0AfgLJZzMQ18ImkCIm1LvTfQNMUtl9cauXsmgcrEx4F8LCDxx0DfiFXClJ68BAsSgQzPZx7pP 7EU31oue2BX9Kn1NXKboo7et8yMOJlWWJ2oLYRtiWXoaKz1ocB6AawHhOEBdIoeKEgNDOrxM/SQA EQPNLHmAMMV5BQljlqUGwwKNGaK4goP06v0WjibmHE1cxvFN30tuigPa2m1CVEXo8X+38uXj8T8/ nnz+j522rk1MfH1nwutVBrVmbieSAB2bBLBk+uI0ifVcKUQh7AdU7gfMaQc3DIdUs41UgtFE+zTm QNtQHh62zgDILlEU3T/iXAWZpqTh/Vf5/lsWyVEjp2i8HyWDwqAn/XsfGOcg8sMhmksns5hbazQC UMN2qR7jCWeMRRrAtuWNv0aN2EOnCQGuxw4eyZ43DLOHZ04LhwhGrYroqi05Ph+AVuno2Nb2TbGf ioX6zOfxM93f0aR2RsS/jBFQ6IfRWv2Eq7gsm5KYz23zpIxAUB1S1US1ciNA9mUYak4fZHOplmkC 5oECeVPMzPq8sfpcuLwF4GMAQ4PuPWlvFDs2/L7v0+9FvobNtc7mRbu11377kK9hko4+ksTIYRW3 aml5YQyVur4L5BpLXCNKENBuwCrQq3SHjvqJI/SFCw0tm1Mvz/Zoeaq4aNwF5NVh6exwBW1LbzDM b8xeldN+lC3AuCrA9Y5d9tbUl12Qitpc9n7Ot2mma5VccIKVVO6HI8dVXIbye553r/Y5Z7U0OSuO eGvJZQIXydnpjiZ/O61K67RqqMn3L5wrg/V6qLS3p77Cdh2v8AE16cMrdKimHnNWankPJ7sjXpQa z/3pO7y73HdYscDYsp5ztbDDizK7/+///N95fJU5+m+pq+Um6YKO04j96E4poWHbPtw4OmqvVHFX 5rkUlhHSuYUTV0QVUixN3aMrUtCO1kHUEc32+4NqiOkqWRF4uXp0bIEw3FmGijZVJV92su5bLZPk UYAK+D++wFT3bWNk1ex9cxx7czAPUCu7nc/39k3oOXlVDuOoF1wNzXgguqXm5Y9Fqp2pA/nOhHWq pXz749Js72rh29pDzo2uQmk9/56WRNsPbmYx4WBcnKROl7FvMoiUJlkVl6BL6WKgokgH0g96gU+4 0ZF4Aj36wG8b0Ppzav8ccIHnShH2uqlc1EokJuspzFKkcYqYgXsLEdHOnR43kOdfBnEY+AGGWuip yWq0ebHTZtach/FO7LbhspBpGeXW0YjcBT/Nx9P+7DsQOY8ziUFD4E9UtaAQkH47elJ12PQMVzoG mGbYiasEwlWjq82W5cJQ9WnHZakpQn2j1REFfpIZILShpgllO8jiRINAhJmY/FhrpOOlkQFj879y HvQbYv4JnN2VkKIuys6AGYGkFd3UuhSNwBSUwCD77crMA5M0NWYXzjLfmK3t5daqWbYL6oecQUWL mPgBqMXtdDPL/WuThbP6iQwfekihYGOMiar64HB7Y/eQfKhCYXTsYMHbfr/d3txVNXJ6uQJh1bTp GpE2LoroNjtT1vTbexs6U6JcyGTeDDBY8dPkENP9rohNVH3RKavw+Rct5D0Klztl4St/l5e63BCX iiu9JQn9dr12+JmiZQilIkvVj3o5nKMmPC5c35Rlr/z61Cq5Am7EuLB+i7jdU1a33At5IWwNzZB5 9u0qHS+zub5hsf+O91jOKdwZZ+PVCb9a3LiNKYstS3Xj9ocDQoE5tweb0iQsLZMxaasR4PfBTaJE 7fu3rd2dHaeQ9OOUyfqTSEko5fAw5BgzWVpaxg4W7Jh7Rtkxc0gFM3qTvSQMdqTfNqYsXOXS9VL6 e9xcbUxZqcm/aEHdFi53yjpG/i4vdbkz6D/IpzJX9KjkyFod2heuyJ09JaETPK0XkNBAkeQRHR78 ph3lOJGHgr4A/bta/Ed48wr3dVm8ro1KvK6Nn9zr2vhZvK6N5nhdCLdLzHlhm04DMdohPHinBDiy tb3ROVJKvBBBmoMFjT93B5ucA223s31iwFHJcO3U5BQ4yFchdX51RXMRiR7Qphv+CHYcFYk9nGVF eVJLdCJeyfWrdWHeVH1AGveyOxq8jdxXJO8EBuxRI9XrdUx5x6c9/PygPwgldXLob/BocQy3iVZw dLc2Z/I8rRWqkQu9+Vwn5yUladbY5yGiW93Aid7AWKLqKW/AfTk3v5nZoe6yGJ9q7GDB63fP1Dl7 9WLa0rqsUJ6umjBr9ZL7rqjBt5AvsO1vPA+aUple6gdBsXAwp2LC9OrK3U5nj2+0gjw1oVe3Zvup FNCT83GB+y8EiXKESh6QBXZw1mjmKxWOMUla9aAqdoFQXhH38riH+TDwHRMTberGDrLsFAA9yyI7 3SCRfgaibQNItt60gRLAa47El4NPKAIbdm7i3u4HYKDUf8mi09gOZSUSeiJZCga47E6aabAqqNLg AhSKTf+7EigoHbC6x3cpi01jxcYKBML4WFx7MFTde3BlAaRMItML5dfgUhGXQOFY6SLC0pw/kGWn sbJjumcAiOwrvsmu/NcQDowafJ9LERSMX6TVwPzQ2yDJhgBTfmNf56fnmgwxbvxMRoC4y+4pvN33 ifRuVM2jpNkDKdYc+24FjLFL1QNs5xSU1hS7tIDsj+XsKnJRbk7gltzecjm+nNerKoDLXbn9Vr++ btklGkhxLsPeGlNQzpXldE4bl7NJtSTkUNkkO29CR2toMkgksKKoeBHgF9W0fnwJbHge3JErr/nN qOsQ2QH20Rvro8d3EYnDBL53RVHZ1TVTO66EGlhSqbqfKG2g004sPc2VnocJxz4ySHZWgOo9KDAp Gj012V23/tAI7AhvSEUCE85s6DPcAv0jPVBz8hTYxa9lh/n+lqKD/w2JFcCOgZhhvV253p7TjmLf u5a+t0VLpOLTwX/a6UrkTaHhhvaYQcR5t+jM9OCBB9n9KgHjbmVEdMJEE8/F3OozV8tSzKWyrB8n VNEFYwBotkgpm0qukSAcGCEpDTe88DIREhJlMkk8u0Q1dIkapsDZDFbBj8KryKuoe3epO8gk9V+o GRWyp6D9JIPmI2sFVj2F/UNi8w9ef/An8RG4p2+oC9p/x18HwEml4mCQBKHo7KyKTqu9Zc/mj3+n eqPY+gfHQZXHQfVywS6pFJbdDzDgbYBbTjuJ5Fv9ZPBkDnBWubZnMOrXUzc8AijYPyFYJPiW1o4S r5fliuDAV9O6fwX05BBcjKkCqJx0kODOX4JZX34WX4JoB6pkkzVG5RqDhIk6Hzh84fCFnR1toExv ZWknAYgJSaNdJUgsFQkJbQ6BFBgwvFGcKQ66wRAs+LK7ztqLtRfoEXRA8QizwAIwUbXCLD2679JY j5Qwey3P3xX3IW2+lBBP4HMGO1+EWjq4+Xj7Vb796hVulANX4U4iJL31/HtbLaDmLmJ0FH3M3AzW MlUZuBepjydJEKesrKuvD0x0NTudt+8fcCqUt8y5L69zX3OBymBqfpjWpprzoALCBViBwleeminG fGXVPF2rTNWWu4VV3gE/fjCPh0v88dmF+xuOLVoKLQp7O/alLTrIwUUrbqAxXLTht5v4esW1475+ x3hIyBPV5X79SoRxzuVDlynGC4eyZGq+nTKCmaPd7QPMN6rPhZeR5BU0xTSsOpiyislDSzRGVHmP CohpZoWX3Hwr0wXsnOkCmHBm2yRAH+ZbXKv2JLmH+3JlBM0hlcnRKm4xlH5bU9P2LNTWTXRFxryO p7r3F3MXirR1G5qe09DWgVE2wXCItr4FOZcdvUg5FPWKOEcaZGtqgqS6+hplAaujNO72rEooGsyt SY1HSlGUvH5S49GOvsHLEMQ7SzIyonZpRnoUC6OkdsIZg0EuSNDUDnZnwgA8vc8LCvRHfcTn1nNQ IwONG3IWBqZtmv+naicxrGvErVb4p6HfSHuMd2wqFBw6VBQlnNNc4NyYgkdKfJ4VuiWzrE2h76HI NNf3KJpPh2XfvBb3NcwoyeB1u+AVxQ1VvHmUHlYjSUxHR36QOvvpqn4HlN+5qtFGKQj91CHasnib JWr06ZWYmpC0ttu/sI2dGXTUJ6Z4E0HlGERoKqPun1ep4lyURNY4TjszSxcIZErVPR76pc/0iNyX 1zk5s4DkSq2s8/5bxPOndoId6R1nMuf4lpuHZBhhWVDE8uICUEXEMWF/NWwVC46JE55VkTGZwTUp sVhCM/I6mhyQc4yTuvWSez1OMlXsuCIZhsC9vArW5bq4BCPLDZyEo6P4nHdgY4tVXpZ5/s1r1c8i IS4YSAEe5a/ucFrxSiiZ6coe6psQGtAYJqIH+OUdmtFZehorPVqhgH1QeIMBJtSqjkPV/ZTFfhyu ijQeJr4eqImRiBm8Smp/EYM4ybgvKs1+euKn8io5olTE0xRcgNFdQiLSNNDdcwSuGKYUwjo2TWQS qgnYJqQuIHAUm7DmaazmIaA3IW88slh9qJR4oDSLB0pnGYZuOZbdYe6x4R6bhxMsS+fKIbtLSjmf z0HRxGCYjvg+oa/NQHqrqSe4jcw4VD2saVliUuShkUoMwEql6M27OkjN9KhiYqMq8p6n9ymMu/EE bJ6RjXtjjfuI2Pwa9pyIq3xl5RXbQkbFq0K4sdYF2BKp6UsJ4uIAA9dZcCoXHHagqnCglkV3HyIH NEQP3Vrq3d6OhnmRyr6HG5CkQ8oBIacIwhMn8jdbkTdg5RtwWURnLGI35l4VFR+UD1fF5RAkchkK Ql7CFDnN9RWLPKYKleASmRq9k8ge0j5wBmiGDkmUykYHKuqPe6xzGqtzcthRHpPq4IPasPqUTPTD OJVrWbyG7PMw8cI1GkE8JFqIlOZFgqSLI9Xmah81x+Q6uLpeC+WtDM0MJYQUqcZNXQ0BYRtLRVuK U5UmYdXTWNWTyAGMF5SILmtB4ZBlgn3KVdFdEIYITW3DKKkkZnSrXtlwgFpFgMqrWMUqLkus9sua /vcLsv3m+eSn5nXq4Re2do21dt/Ph5e/g8f0u/hFfD/wKfJST7+Mjn4IZNj9pyrOvhMgoR7K7yww jRUY1jBg+H23snhiRzbsVRj2Oa0iT1KoJftoKdy60PomxIfgaphI0dkTf6UUwkeVQjgHzbei61JN D/fiA6K+hy393Ofww6SUvCPnOmRuWSIZ45ei+bFLGGRk7qg+YIcaUxqvK28D4JBNYhhwAkBPGSjA eRh4Z7UkLKhT/94jXLulNlJHh6oLKdATLYAYQD9SIDWJpRkivif8a+nfrKK1uotuEj/DtBSaRb/K QWNjg0bVmEYSgakp3VWo7HQAwVhfZ3XN6prVtTVX6TeQw6nsQkdxl8ATNkwi5S03Ok+nlDJVpFTD BLr8CXJBeyzoBcZzUnXyvGaldbVG57JebqxeBtzGA32parpBTdPxsDMw7fcCXyO6YpxK0KSlOrow kBhSOoRgeckDfjeOgH84Al6WEA3AwAhmHCUDSAIUjvN7Rq19GQdkc2gH5QwJZ0iQsCzU5cz4eAAp /UTS+Erq6V+7SjR1uQWukOPth0NikmKb32Cbn/fspyIMMPNbk4eIk9N0VXTjPoQmfb1K2hw4ykxQ 4dcSjPQCkI1wIF990LYsJl9COkKSjjvkZeM7wCl7Igv60sjQnZQ3MuriPNCUii6CErWY23QXJzdA 5iaUsWXd01jdYzTNXy8uTl9z7qd6NTInz5A5wmo5xfwgwvRpzNFEPA41DNYMsH7GfTTUKIfvHlE9 w5J5j9Uzv8qaqsboJdb3i9T3+9WNSH7LI5KrNwD1itV4RHKDkoGPwDZ4RLKpndYQ+8POTo2dHYZq LxdUe+UTpmyCHJIYowhXhlEkmk0K8E/xwfMlDXzRFNntnb2NFp3ttDAWcYUTj5UnHlmzsWYbZ+GM h1mI8uPH29DCmew8xh8cnflcfn0STvORtRosug3cVd5O8mEYWQgFam2AuB8oILv4rIsmrLNYZzGe 3SiQWQCSauAX6IQUpxT460M8hecALPKI5uNW6kK4IilHk4mXouKNXyzcjTdh5ZuwXkmUcnwtUdJT 65GXQWL+NURDA2HdJg3OIqIYwkwksYbfapJcGhPPlc7qk3Bzcjw5GKyry9QmsLqGJIsT3T8C4Clr 5so185x2FteUFllTKm/qg81SszaIgZMcH2JYzJEEsHUqGqHBLRSbnAASmADOpVj0MJKUnCqPh0VV b96WxT0ykD7ykJJ4eHWNKQCUmMvpO9Mh5vrcBinkhIJeoFMsZAWilUjGp1QvOqy/q0jJLcsGjAUp 5QQTW5AS78rMBLp6+gZT4PL2qif8a4m215GUAzHAQE24PaZxnQOPeUw5ZMPVMMN15GWeCKV3Q7Tt 1DCijRfH9MsS03O2rJbZsvJgf2LiWtGZKyiFivGRw+4RAZ6mP6f+LgT+PJm10YN9R36P6KG/GOyI 6R6GRV1pUpFUDAc0xg3to3ZgGyhIBl7i9RGQgDYiTlinV67Tl8WFVsTRpEZM8h5wLJsVklwZW5oA lW19LW39/vZ6p1AZ++RFwWCIieoconKIqqjEagiHXxbLdSD6MXigMbmW8qsACeU1Mpgz8ogNnwog IeQj+x6yRIHmwgT4Q+9DZjuo3sIti/yQUFivB/gh+lWXUwuMGFcKICQc//hur4uZZXd7Qffdytb2 Cp55w+w6Tt6tfAr8aw/n/iLj5CrwujKls+R7v1vptNpbay38v3PRbu1tvAXi/W8r+38uWyyDiD2S lCBubW1t7e629ctfGKWrrvZCfi3DYNHSYD3oFfv0PFE/caT82tSZF7+MbJ/rmzn3HcRLenOJmTlN 3LA08Znhkba6FHzSKSyvsblArMAaw/ZmZKEHcZJ5Idc9qze6vO0atu3eh7F/Y/fcHtgGE3mHLDGS fMYhBuAAEPpbAJwJe6ARB9ib+HXtKD53PJpZhcd4J4ebnU5HOUJJGnTPjjRrLfktBlVonJnTMVfG dP/Ae4rP4ZvLo2O8sBgVjc58Hj/T/R1sOmeY/5KdgNrU/bPffXvgwRgo+CU4pzy3ndk8t/aW8txU s1PyAYDyFG/opX4QvIBxLfMWF+RRlVYyQH/Zl/CFoyDtp+M88lh/MNKau7A7211obT70n0m6Njut t+3dBTnK2f6vANxZYm9fKFp9Kp7CApaQ62El6N6NFuRta8YF0WLpON2LX5ASATFR17gOergY7RkX Y7uO0lGyGK/k+tW6G2FCHz9ci85sa7FRIhgLDSmzfbU3qEP8aSHYmO3CW7UUgv03KLxlwRgqu6DX adMag1ovrW5TJb0k7lOP1VDl3TLZffoObs52B9vtydt4Y/Pt287BopR8yTZ+ehW2ZluFmsoxkq3J 66cv+u1sF40U2YP8GO2M963tVmenXre+RHnP6lTX2n9+cY931lU0oYmxcvA2pwhNFtsDNQpN3v5Y UplDk7u9smy1EEDkO1rLcb5njAk3NiZrq8X6WJMN1YXBeTiLMHI4E7tVTlHPyAP4BXki+8eRn9wP Mue7OjdsxvCxnjdsfwIq4EEcsD1jgFjPOGCyjLo7dCScIxW5PWNkOOnGO5JuxN81H4sRf1ztrHW3 UT5he9awsSTBsliVtk9zjKAUvEFagqIx+6UgKTOGj0soKfuFvIoRnrqXZPfEb6efbXLMEHnI/P6i II/7jd/JCFBBqdQQbM8YYi6/VpzGQX48I79Yt7egqmYMkM1OXZTbW1A1Mwa7Pw8YBHl/7V4vifqh JIatoblg5yLIZ/vH4jEnJ/8TOhu1ChlKHMoDcX7+Udka4iUdZxczYzrGJaCgmmYNDCfAvCisWqwX VbJGjnG1TvdE8zKWVXlapm1QWTBE7nuo0vBiDVFBj88aVWqfeTGGaPob5a58Md3onqlBuX7u6Ubk BU+TQxSqUaVFYgGIzp1Z4+tCwDSGbXyAtFMScgOqHnzmCO+AO6jmSetH/aW0/07vR/fXPpJFGdg9 VUjT2EOTNmTxPk+AZXD/SC37R0pUtRAYLhUPZCS+HHwiwI9MegDQYOwfxkRX0is6humZQaIKRcwF AH1GtntnxlQRA32MPnosm543UhDGzPaerqKD0L8mGGhisaEUx+uSfzLEjFLH1SgmdHdmTFe1SjLw C8YDuR4lVPiD9NTOLOmp1u7e1u7DksOkTXqkGwiO2623R4sqmdtgUK2G/YVEQJs1HCGDVtixsyRz StaErONCL76sEuVsgZFkFFZhxnSI0VtO1EmrUNDHys3A8r8UfLFUg5y4MHFnTfD9rD+z8K//yGCf yRaakKt99P10c6Xo1jTqdHElEmoY7sUXUAR6GbFOAvRzSf12oKDs48rQLBUnNK08vEeLq3PvrDzj cTAHZ3WxgeKLbRtavTm6/LyKeX3bKppJFpQDJxWulpH7WyEtaDRnFZUdGguI5w2Xh71B4/0GtNJJ H9oL44i44567/Yq5lru9R5pEXlzB12zvTHZpUNlRDbR65AI5A0G+uVCozUmpbTWXSKjBfaoJqU37 A4Z9jfsJ7B/kfUOT04J3e0umekvFBxyCt0FXjuine0MzXInJp1+mf4z98YZ1if41juT9IM6oLTTX 1jQuwEf7JOje0a1GBPA+kcPZpN1fLy5OV2nA2fsgdjN104hPocQ3ocyw2JijkFyZEaqhJlX+bWUx Jb5lcRPgKcD2n5//9Wlbf9xu7+oE/Tg+3z1Tg/pwQXhmxIMsVHgm7t3WVutw55BadNTyO4GbPVjY 0O7L1T0xh1SSR0d5o6btObZzPzXEsnCzZoRubOoOpEXt9MIFzIhGMBfg5IEn3eC8QqB24oLC9VKf cao6p6NnaqYl96cm7MUt12V+tZns9qPct7vvzp6+i/aPl3zv7s6IxajN3gVnF24FNOIz6cGe3Lt1 26YF59IpBIfBDUjWwKw2SgAUHNGHBLO8B7QRHan/3Rkr4hu6QLwY+zXR2XA9uolarJhrd19eAwfw xdOCE1fRDaqeXEX35byK4Ccii3q02+l8UMq54PiOHSwYT/eMWsWaAuYKisNBlvh93ydbVCSj3Fzr bF6AZGFrkbjVIvBj1wF+TPGVJzi35lYtyECi7LSJZKY41JOsKdNynoGRX82rzofKn+uci7DD5R3/ Fbu+3Aq6gmh2/9jBx+W2sD4LheXtOvCWKe51jSzZ2IJrf3zs4MLvQqB40YgB7d3KZkfluwjnDJHU v6v1fKQKVtAkTrKstrfK0SROimaKr1w7TVIaEVMR7g0wviLNFcuoJAd8jq9VDwA6GOXwoOTiDQZh 4KtyeAlvibOMTvKkZBkVoXFr5yEekQzt1vZG52ijEsIWWK9rQJ3frVg8vU7DPsDRlxfMSnFoXyI5 GcDkLIaTiClZjKJBXRKZMt1PGAy7N3kRJvqhY+ruZ9eB7ZaTi5ji7tfIXrlBwJNew+bO9s4HtfPJ OVbe7gt4DUV7tbGhVtvYK7TCJOm7lfZW8eC7FXrRU0bsxWO2osJot5z0zxQyozTGglzXUoMzzphj HVT3Up00xaOXWiAkrOJSKzEL+wcTfXD3Ep8bUDn6/6mos4qlULvhefZwHwPi71M0xYKj9DK4EogP PTVjHmPk7+LkJgdrTLE+00dvBWrGKq67EhEokf8prnv6SKbgJNXmuvdvAw+jUyhUpUTtyH3U/uUU 1//c8GAp9kVZ684oLGq3nCBj+uEf7YIYQHRVBorUg8l4ViEZM2iCEvk/Hw6ItZ90gozSwNcawjNq g4H/EWXVbESSQ/lwzIfLch70z4fRs+MUcrifB/x3XbZiGt31/TgBbBLA7rJwGv1JkOnEIJBXERt9 1MFfnnmwO7pu4IRTtAUAq/UHrz/4k/iIjvJvSF7bf8dfB5gqkYqDQRKEorOzKmiIlT2bP/79lDju t/8x7ikwsvuHDUC9xOUygbTTvNh3KwPccjJrkGvDTUFeS8WcFEa7qHd+QWxZoj9rAakDWt9CPbJw /S/9ne72Hml53bdtHWtHIJPNckVw4ANHnAoMwRCHXgrFAZ9RnHRoEuPo3xc/iy+BO4Yq2WSNUfnY aTbTL+t4j3lAhaqfe6aJjne9rFdJmzs0ExKcB1Ec3feDb6owZsFq6Im4DqjBXSPY4mECih00MGGE VnY/PuaOdVnlumxZ5IdEqCcuvpw9WwbqrC6KiS6nDDx9oqt+GMSmIqnbLad4vSS30Cm/tJ0C7LOv wEk6P42gr1cSdgq+N0f3qKgMP144kinFV1AgMP4FJ8Y65mAtelL2HxKOI9at0aqKfhwFSN+Qh0IE awYQNBygiDdOlV6zbz4uDLVaV1MCI0o72HXdveAPEzh91jMcF2Y/7tOg+DPiEQXeE+USqC6Qibbb bZ38X9Ty79sW+7EFL37hYwUULP+659l9SOyoKs95aK5U9iTqQX6eBNKaxr6tPesug04W1U03jcHg 8PWMEppYFKiFZiop1Tn3GItdDiNurBvUdmAqz3YiVFn1xRODE3M6U9zCYhnQfXkTsxETV9FN0jy2 490FLC6t+x5qaQuV/JcE2T/VFQ2mzVwjO2Cm6TfCglsri1fgwI2efQXTxgPmvi/GQcHlPjICaoqo gJwXMgvmjWzBZjojV4dLf7x9euyy9IWWNFG727RJW93Bpz17o7yszVPIF4eQv9128GXTf//OaHzw yylhsjLkC+vHAom/+QpFBTYjfOzJ5nDjvx5p6uc67OISh1UUesFdAvFp+sZ/YPMvSd61PVPeFWKv Jf9ld25R8slaOmCAnVZr873axw/r2zbcKtwU9+VN9FaBHyzNKezqnEIhQd+ZKTcKKSnQ5i/GwyGi 1i0ncHWvvJicMNft5FKqSE6o94X4arVdHjVP4UE8EReYd1DbQ2dMXoQt6aXzwI+qgh9fxZq23r94 XqDMi1/QTp5s5HeI21Oa9OkjG91Jm3Zs2tTaBqdgs6Dr2z+MAYDvEhs+nBWXGbFUaT24EgL6vz/Y Ptw4WileRwV6TH9UrscYfvnD8EvSY0pXWzGkm8f6S7U8VNDesBT6C+COi/dHjuKaKBZbm53trbxp tugHuGdq4MwWHcfn58PfXmDCTP2oLN1Vfiy9c7DT2ilw/xTCDvc9anCnCtmCzvMTtjW9Uz+uQNmN ZjNEfXUwyz+fGdrfhcd8cvD5ACRSpf7mRBPEGwsC8ZxurDmtIsenyzVL9eL/s3dtO20DQfRXVnmg rYgc21BIgooaAlSoBaGE8oKqyLKXxNTYri9E5es7u7abmBDKw5o6yUFICMKTPZczZ2bOTEj/wAns VMzw0M3KX6lce/ODzA0tW9Z72r8xIBywHg4IfAB8sL74wNAJIAyKEbsyD1VRRoNDwaHW2qEMcqkL OmtK1O4Dh3PVQ9TkCZyaI2rKn9SAqEHv597rxqFlC20A0owggWPeOCTu9GZw2jfpyM8Pxo4iy/F5 1GRDrckaX/lvRgJjTrYlntLOuOsz+udYyJae+Y4QKS0vMSC3rSHb8XzTkAxn7muQVWSyOvvGH7gX N5rsqH/JjN2mMBkmDKzJzq3InjCj09lHqRYrX8atyPvAldSSKzmkIsMUPKQ89g5UlAu5Eb3x36Xe ythnvtFY/gSoaNasn5+0OA38JKYX+QZHyJcmt5uL0+vvfcJEjDVOroZnjH5nX6IgDdkw5LZ7m0u0 yzOcUoa1OBWBcl99aluVOYQ5SHTtRklqeYVgyXuynw8z4SWCR1tecjBJkrDbak2nU40nsasF0bgF Els5MlpB86G5AuI5opYwi9E4bpH5tHTdGOmdjvjZ0g1Nfo/2dFgMAg4FnnE8IiMh23jQSdZeN0It dG63xskBai319lFRrZXjQznRiOnzVy2iPAOpUbHWs2LtySur8TvWcxxiIEl/ElhHOdapKDLBp2rp U0vr156fkPRQwDL5aPiZcj+rV03xghbwUhO54nR6kIzEttjZ9ivm58uZ9tn5bXBds81yyWgRi7WI YurGdR2TjNbAIqky5nDmWawfpY9N1jYRNdY8aiwX3D23nMh1mlRWmrTpvQdL2FhLGIaW6+P9K3// wOnZekhF3bp6wbPlgfZyEvi8y7Z3dlnH2GGG2Wb7+234m3J/WxWDOLm3XK9LarGyftNCef4npJV2 j8efk7+QXSPxEViJciupKCqD11UxnY2niKcY+VhgolT2ViMyIh4WlIbsShWEhhqdDXg0PBoeLflA eLTlUVDJhPMs5y6Nk4E7niS0aPAk4t/ZxR+Iv05y9f6sW464OL9cvzJPsWa12aG6m6tt3FxVP3xT L3PBzdUNIvJe6LPi5mpZ2gVpuqR0M5ORvSjgC8CO3IDBaNFqjRYdu3wcsIGWXaMHCa2chK4Xvlne u8IA0X0uubHhTUwMEFW+q1gQsasSGzBA5CI4SH0RDBBRC7+nngWpqFUNNL5aaHxhgKjD9F0DqHxj UXk+QOSIKk2LNC8I+SMGh6rOxhVFYzTI0SBHgxwNcnDG8paw2KXaRNUkZBcVwop4iniKWU8Og0N0 /hUdyWRxihXZxXUGi48F297d+LHo25umGDqkbCKvtoqsghFpVaeekKORo5GjZ4PQaRJQA8Xmx6gA UQESaAspCUlFEeTonxzMGJgxxEXERcTFXP2eypJpF3ERy2DAix9NxEXERcTFBrhucgNw3eC6wdJm i5p2/KmBuIi4KGoFxEXERcRFxMUutrWxrZ13FnDFOZLdfcRFxMWNj4t/AAAA///sVktP4zAQ/itR DpyQSNK0JGVTCfFYrQQoao6Ig5u4qSGNLXtCgV/PjN00FXDgsNrl0Fw8D3tm/Cmeb7zN9Jk1mR/4 J7NfmynrQBaKlfzy7qOneuwMzEW9gj9t9cH5WPaGhi/BhdK5poj6WrZg0M1MKUTmF2JddK2PBs4M nBvB9m2l2Wm2nieu2z70tkTz1huiiDKdYA5KhavqV0qscJs2oprj5YLJRTCOYspqTbn+wnjJl6xr 4LMn3zPZyO5mA1ZXfUUHFOcHFA//4u4N47s4vGjbX/9/X8TW92X7s036H/fqzRRmObZ/qb0jtlZn 3o1U/M0bvqsXJTQ33rnSovGi5NiLgnA8+LfSfc5q7qUP1PzBUYEjgk8EMIpP01HwlwjgJwG5oGLg VfHMVwhGz4gDDIaXkO8qJir7BhYFHtrbauGsC2LeTeaHYRpMCMoVypNklDjCV/Uts8VIhfY4dmjT wIBqElh1IQHkenDTsxi8K84qjtScjEMKv5QSSE3TiNS6A6tuSbaUDY0VhqaVzI+jsauikuVvLWhA caA0ouWGjpOQCyix6FHYTw4OHAvWQlavVsAI3Zq3MHsHAAD//wMAUEsDBBQABgAIAAAAIQBPFIUu cgEAAN4DAAASAAAAd29yZC9mb290bm90ZXMueG1srJLbTsMwDIbvkXiHKvdb0gkmqNZOQMU14vAA oU3XiCaOkrRlb4975DRNE+ImVe34+3/H3mzfVRU0wjoJOibhkpFA6AxyqXcxeXm+X1yRwHmuc16B FjHZC0e2yfnZpo0KAK/BCxcgQ7uowXTpvYkodVkpFHdLMEJjsgCruMdfu6OK27faLDJQhnv5Kivp 93TF2JqMGIhJbXU0IhZKZhYcFL4riaAoZCbGz1RhT9EdKlPIaiW07xWpFRV6AO1KadxEU3+lYYvl BGmONdGoarrXmlPUcstbHIiqBtst2NxYyIRzGE2H5EwM2THt8QE7xFxxioXvmpMTxaWeMd16/Jj/ PLwlDo8O2rRDfTaCb5F8WaagjfzeIMkJwy33YAmGZB4T1t8z+IfLmj9igN1esPRu1V3oQ6koeF35 35mHLnR9wy7DdQ+xneIsQJMNRUJ/mv6cNvugsQy0l7ruF+fpp8nwn00eFDtmGDuZ3LvkAwAA//8D AFBLAwQUAAYACAAAACEAMwIGaHMBAADYAwAAEQAAAHdvcmQvZW5kbm90ZXMueG1srJPLTsMwEEX3 SPxD5H1rp4IKoiYVELFGPD7AJE5jEXss20no3zN5IkpVVYiNI894zr1jTzbbT1UFjbBOgo5JuGQk EDqDXOpdTN5eHxc3JHCe65xXoEVM9sKRbXJ5sWkjoXMNXrgAEdpFDWZL701EqctKobhbghEakwVY xT1u7Y4qbj9qs8hAGe7lu6yk39MVY2syYiAmtdXRiFgomVlwUPiuJIKikJkYP1OFPUd3qEwhq5XQ vlekVlToAbQrpXETTf2Vhi2WE6Q51USjqulca85Ryy1v8T1UNdhuwebGQiacw2g6JGdiyE5pjxfY IeaKcyz81JycKC71jOmm4+D958db4uPRQZt2qO9G8C6S71kK2sjvDYKcMNxyD5ZgSOYxYf0xgzsc 1fwZA+z+iqUPq+5AH0pFwevK/848daHbO3YdrnuI7QRnAZpsKBL61fTrONfHbGWgvdR1PzUvhxbD f7Z4VOyEXWxj+iWTLwAAAP//AwBQSwMEFAAGAAgAAAAhAMccbRScBgAAURsAABUAAAB3b3JkL3Ro ZW1lL3RoZW1lMS54bWzsWU1vG0UYviPxH0Z7b2MndhpHdarYsRto00axW9TjeD3enXp2ZzUzTuob ao9ISIiCeqAS4sIBAZVaCSTKr0kpKkXqX+Cdmd31TrwmSRtBBfUh8c4+7/fHvDO+eOlOxNA+EZLy uOlVz1c8RGKfD2kcNL0b/e65NQ9JheMhZjwmTW9KpHdp4/33LuJ1FZKIIKCP5TpueqFSyfrSkvRh GcvzPCExvBtxEWEFjyJYGgp8AHwjtrRcqawuRZjGHopxBGyvj0bUJ+jZz7+8+OaBt5Fx7zAQESup F3wmepo3cUgMdjiuaoScyjYTaB+zpgeChvygT+4oDzEsFbxoehXz8ZY2Li7h9ZSIqQW0Bbqu+aR0 KcFwvGxkimCQC612a40LWzl/A2BqHtfpdNqdas7PALDvg6VWlyLPWnet2sp4FkD26zzvdqVeqbn4 Av+VOZ0brVar3kh1sUwNyH6tzeHXKqu1zWUHb0AWX5/D11qb7faqgzcgi1+dw3cvNFZrLt6AQkbj 8RxaB7TbTbnnkBFn26XwNYCvVVL4DAXZkGeXFjHisVqUaxG+zUUXABrIsKIxUtOEjLAPadzG0UBQ rAXgdYILb+ySL+eWtCwkfUET1fQ+TDCUxIzfq6ffv3r6GB3efXJ496fDe/cO7/5oGTlU2zgOilQv v/3sz4cfoz8ef/3y/hfleFnE//bDJ89+/bwcCOUzU+f5l49+f/Lo+YNPX3x3vwS+KfCgCO/TiEh0 jRygPR6BYcYrruZkIE5H0Q8xLVJsxoHEMdZSSvh3VOigr00xS6Pj6NEirgdvCmgfZcDLk9uOwr1Q TBQtkXwljBzgDuesxUWpF65oWQU39ydxUC5cTIq4PYz3y2S3cezEtzNJoG9maekY3g6Jo+Yuw7HC AYmJQvodHxNSYt0tSh2/7lBfcMlHCt2iqIVpqUv6dOBk04xom0YQl2mZzRBvxzc7N1GLszKrt8i+ i4SqwKxE+T5hjhsv44nCURnLPo5Y0eFXsQrLlOxNhV/EdaSCSAeEcdQZEinLaK4LsLcQ9CsYOlZp 2HfYNHKRQtFxGc+rmPMicouP2yGOkjJsj8ZhEfuBHEOKYrTLVRl8h7sVop8hDjheGO6blDjhPr4b 3KCBo9IsQfSbidCxhFbtdOCIxn/XjhmFfmxz4OzaMTTA5189LMmst7URb8KeVFYJ20fa7yLc0abb 5mJI3/6eu4Un8S6BNJ/feN613Hct1/vPt9xF9XzSRjvrrdB29dxgh2IzIkcLJ+QRZaynpoxclWZI lrBPDLuwqOnM8ZDkJ6YkhK9pX3dwgcCGBgmuPqIq7IU4gQG76mkmgUxZBxIlXMLBziyX8tZ4GNKV PRbW9YHB9gOJ1Q4f2uUVvZydC3I2ZrcJzOEzE7SiGZxU2MqFlCmY/TrCqlqpE0urGtVMq3Ok5SZD DOdNg8XcmzCAIBhbwMurcEDXouFgghkZar/bvTcLi4nCWYZIhnhI0hhpu+djVDVBynLF3ARA7pTE SB/yjvFaQVpDs30DaScJUlFcbYG4LHpvEqUsg2dR0nV7pBxZXCxOFqODpteoL9c95OOk6Y3gTAtf owSiLvXMh1kAN0O+Ejbtjy1mU+WzaDYyw9wiqMI1hfX7nMFOH0iEVFtYhjY1zKs0BVisJVn9l+vg 1rMywGb6a2ixsgbJ8K9pAX50Q0tGI+KrYrALK9p39jFtpXyiiOiFwwM0YBOxhyH8OlXBniGVcDVh OoJ+gHs07W3zym3OadEVb68Mzq5jloQ4bbe6RLNKtnBTx7kO5qmgHthWqrsx7vSmmJI/I1OKafw/ M0XvJ3BTsDLUEfDhHldgpOu16XGhQg5dKAmp3xUwOJjeAdkCd7HwGpIKbpPNf0H29X9bc5aHKWs4 8Kk9GiBBYT9SoSBkF9qSyb5jmFXTvcuyZCkjk1EFdWVi1R6QfcL6ugeu6r3dQyGkuukmaRswuKP5 5z6nFTQI9JBTrDenh+R7r62Bf3ryscUMRrl92Aw0mf9zFUt2VUtvyLO9t2iIfjEbs2pZVYCwwlbQ SMv+NVU45VZrO9acxcv1TDmI4rzFsJgPRAnc9yD9B/Y/KnxGTBrrDbXP96C3IvihQTODtIGsPmcH D6QbpF0cwOBkF20yaVbWtenopL2WbdZnPOnmco84W2t2knif0tn5cOaKc2rxLJ2detjxtV1b6GqI 7NEShaVRdpAxgTG/aRV/deKD2xDoLbjfnzAlTTLBb0oCw+jZM3UAxW8lGtKNvwAAAP//AwBQSwME FAAGAAgAAAAhAPmvLDC8BAAAMhQAABEAAAB3b3JkL2NvbW1lbnRzLnhtbOxYXW/qOBB9X2n/g5v3 QkJLaVGhaqG9Wum2t7rt7kr7ZhKHWDh21nZC2V+/x06gwEX9WAmJK61UUeLJzNhz5syMubx6yQWp mDZcyUEQtcKAMBmrhMvpIPj9+e74PCDGUplQoSQbBAtmgqvhr79czvuxynMmrSEwIU2/gjSztui3 2ybOWE5NSxVMQpgqnVOLRz1t51TPyuIYugW1fMIFt4t2JwzPgsaMGgSllv3GxHHOY62MSq1T6as0 5TFr/i019Ef81ppjFZduz95jWzOBPShpMl6YpbX8v1rDEbOlkeqtQ1S5WL43Lz7iLdF0DjxyUW97 rnRSaBUzY7A6roUri1H4lu8mgM7ESuMjW9j0udxJTrlcmXHZsYX/CrwWwGvXvtvO1OtBEIvhay6R eZ8ngwBJOO/T0mYK2N7zOKNMkC8M+cNpggSENKEW/jph1D0O8Xf+HEX9qNMPw7+clEtuORUG2l+8 /QKLyPHkO4yH3dNOr4u8bpbGLKWlsGsSt6PiUft/T3YhGF6tqBgEozrln9mLDdrDy/bqNf+urlX0 LpXvLGUazGKNXvMulVJZn4R4obZYm3K+7fA544aUpqRCLIhlMjHEKqKdLfeFS8t0SmNGQDHy7fqe IC+sipUwfoUnyHWeLpAmxJ/REDCZFFBylMRuSMKmmiKYoEGLjBVZqJLYjMsZPql1Xw2JVSkSMmEk 50Yw6mrD0ZU7vPUhwIZdIPwncHb8+hHS0/1CGvXCu+uTXZA2koOB9Hoy0aziPuKkGj3eEmQAYS+F AJlYAkwRdAawX2yLPGU+9JQYUMESuq4LPLiMRZlAacIAKJSgiJzQKiljh+hnQer+D1LNu02QbkeP BwQSOuU+i+PPw6QH8MaXQg0GWHX0yYrU228cz8Pw9MZj5fvOWpNpJIdSkdzc1TcFusggKDQzTFcs GI6EKhPiHjBwubZSoZlo9A9hFIlpjmKj0A/QTTbCjpa6bKuun46j7s3FKPCk2u2HtaYtZyqjFSM0 dkONe6SSUGNUjDoJcKuHp7sWcXibEmWOTlRZt6ajTe/vt6GL/YJ+etbp3nof26A3kkMBffgbwVQl pwguRygVMTGTVHOHbWl8iIGHGwZWw0YHgwiD2DCzAfn7Qe/sOeo3Z+HF+c55rpEcStR3U+BPN2jV OU0xC2SY7Uw5Mcy3cKKkT3/gECuZ8mmpm2HtensJz3+XzNjXec1qPp1i7MSAgPERw4EjEgA3TKQO dLckmcVEPiO4q8EyxkibaVVOs3qY6EiTro2ZzXDikoCodJN8W9Q/uzg5u+29Rf1SzqSayx+s+Gox zKngMVelQTBMUQejtZF4n3ZIvvIZUhulRVCdLwOwOvhajK62CgtcvVHDNk/wPh+iKNpvGQq74eh8 5Hxsl6FNyaOr0c3SoXBk+Igrhis0GYtn/rpCk8R1BlwbcfEQi40c+Eiw91x9fvJGv1Z9UN81qa/d /J/6giIcY6YcvaCg2vK4BHOWbXqFiWOS163vm3bhYUO5wk1EiNfqs2LaeonBaFEo4/rQ8jLb+jSf Onvm0811b3Qy3sWnRnIo5NndYO7x6wZfBr/9x8M3dAiJH0Ncwcct8ejqvYCDZc3F3gz/BQAA//8D AFBLAwQUAAYACAAAACEABevIF+kEAABWDQAAEQAAAHdvcmQvc2V0dGluZ3MueG1snFfbjts2EH0v 0H8w9Nxd635DvIGu2RS7bRBn22daom12JVEgKXudr+9QEqM44QZBnkzNcA7nRs7xm7cvbbM6YcYJ 7TaGdWsaK9xVtCbdYWM8fSpvQmPFBepq1NAOb4wL5sbbu99/e3OOORYCtvEVQHQ8phtjYF3MqyNu Eb9pScUop3txU9E2pvs9qfD8Y8wWbGMchejj9Xo2uqU97gBtT1mLBL+l7LCeLHNaDS3uxNo2TX/N cIMEOMyPpOcKrf1VNDjqqEBOPwri1DZq39kyf7RzDvdMWf3F4mfckwY9oxXmHDLbNlO4LSKdguHN z+BM+XwgO4bY5SuQOyjbZ0rb1TnuMasgoVBz0zTWUrGDw6ERcvoXFduBMTp09T1GIHtVXVIqZrVg qHr+iE9EdhIfLWq8R0MjPqHdVtAezjwh8N615/Nqhs4Q5TtG6n8wE6RCzbZHFYjUVsvzJ9dqwvsG Xe4pI59pJ1CTL7YFdO9FWSjoab+CfW23PaFXRwTOQyDz8RkcwWijMKF/ewYV+TB0lRjGxpvsjjXb HlGP8ylOfveGxlwK5sD56hTjF0gxromAa9STukUvkHHP8cej1+f4e4xzvIesdpDYD0yWRX2BO6Te GHOE30gt6RHAKfFkirt6wZk/rmGuhQrlyk6Gj4T0hEN1cEnZ08PUEKhBXYW3ULAGpxeBczrsptW/ pBbHqQdkNz1gdMIp9AdvED8m8iUZlUPziSEyVn0S1HJ38dLDe7M9kr34iAW8KeNeVP83cPFAOnyP yeEo3nfQV82Mw3FZPKALHQTshTQsPsPDVkNhzrFcfITEqqrCO5KZnu1OpZTaRWN6ZhZmOo0VmGXi aDWpb6p2vUazbT/NtTaO7XtlqkNzXN+3E70miJy5Ca7PcRIzM+cLc62BK+dbkQ7N9W2v0GsCN41K rU0YhGWo1eRgo0XzXDvwtDae50XR2HhTjZYqeIFj6/PmW4HnaSvn23akr6kfOX4R6Lx+vQ/8LEgT bTxB5uS51uvQNN1UW4WwMJOg0HkQJaZnaW0Szyr1GU1CMyy1HiRZ4ETa7k0KN9T3Tiqvg9aD1AxM W1u51DXzbH5Cr/sNrkIU6m0Cy420lUsD14v0NonMti5vmWvbtrammWdGgTaeLHR9U1uFLPSjQhtP bnmpPqN5ZNv6KuRRkKhJd52dvLAS29PFU1imn2tvfWFZUaitdhF4uaPXRKanv6dF6VqW1qaMbMse Ox5eUek2vJ1tLBmSnCjTqoTxuGqnYZ6hdscIWj1KDgVvbxvv2HNKOqXfYeBy+GvNdtgp5c3NpOAt apoSRrBSAH2aNHLuw3QdgZtHxA4L8vgEtjHTSmEA//kFTdIczN4Bn+kn1DND/fuuBrE60HLdGY90 MGNaJefDbqusOqBSX6mGrv77xCTgeknQORbAfmFGAgpaeAzubp62citMpoZtJUPGj6jvJ6qzO1gb o5EzzTLg9RPwVSP2PH7sDvass0cdfEnd+IEqGRnsnhdyw7SEXfNikTlK5iwyV8ncReYpmbfIfCXz pex4Ae7YkO4ZmKhaSvmeNg094/peCTfGd6IpCSNJ+mXWNJMs4IMw768oliRgkmP1V9JVjQQC1jXW 6sp45ArfOHOOa1wR6Mjtpd0tJPB28rwhXGxxD3xRUAYxj4z2jxF5+UN09z8AAAD//wMAUEsDBBQA BgAIAAAAIQAoh3GlzwAAAB8BAAAUAAAAd29yZC93ZWJTZXR0aW5ncy54bWyMj8tOAzEMRfdI/MMo e5qBRYVGnamEUNlQqMRjn2Y8nUiJHdmB0H495rFhx/LaV8fHq/VHis07sATC3lwuWtMAehoDHnrz 8ry5uDaNFIeji4TQmyOIWQ/nZ6vaVdg/QSnalEYpKB33Zi4ld9aKnyE5WVAG1N1EnFzRyAdL0xQ8 3JJ/S4DFXrXt0jJEV9RA5pDF/NLqf2iVeMxMHkRUJMUfXnIBzaCOlEtI4QQb4humKsD2a6z3jo/4 ur3/Ti5GqruHOw32z1vDJwAAAP//AwBQSwMEFAAGAAgAAAAhAAvcJUioCQAAb0sAAA8AAAB3b3Jk L3N0eWxlcy54bWzMXNty2zYQfe9M/4HD99SWFVtxpkrHkZMmM7k4kTN9pkjIYk0RKknFcb6+iwUI QbyIuybt9kkWLnuwtwOQxur3P36sE++7yPJYplN/9Nux74k0lFGc3kz9b9dvn73wvbwI0ihIZCqm /r3I/T9e/frL73cv8+I+EbkHAtL8ZTb1V0WxeXl0lIcrsQ7y3+RGpNC3lNk6KOBrdnMkl8s4FJcy 3K5FWhydHB+fHWUiCQoAz1fxJveNtDuKtDuZRZtMhiLPYbXrRMtbB3Hqv4LlRTK8FMtgmxS5+ppd Zear+YYfb2Va5N7dyyAP4/gaFg4qruNUZu8u0jz2oUcEeXGRx4Hb+ca0qf6VGuh22plhXjgCX8dR 7B8p0FuRpTDxe5BM/RPdlP+0DaOyZabWpQeZUUmQ3pRtIn32be6ub+r/XD2bfVJNC4Ca+kH2bH6h hB2h8uWnY4SNNYkeVbEY+AW8NNdeBnuK5QcZ3opoXkDH1IdIwcZv76+yWGZxcT/1z89N41ys43dx FAkVVOXAdBVH4q+VSL/lItq1f3mLIWIkhnKbFmCYswl6McmjNz9CsVEhAnhpoDz0SU1IlNjcwcEF bePdanRDBRUb/ykhjbUbUVYiUGng4foPAqHW295AJ0ojVwGUy1rruL+I5/1FnPYXcdZfxKS/CCC/ vh7RseFEJd2phQx18LkxMT7XBNEYsmpGLYo6Z9SCpnNGLUY6Z9RConNGLQI6Z9Qc3jmj5t/OGTV3 HpwRBkhc1SgaozVIiX0dF4lQ8w8S0Kgn1ZlNwbsKsuAmCzYrT22M1WUfIsv5dlHQlop0+nCynBeZ TG86LXKi0+DBnPxmvVkFeQwnkg7Tn/Q0/XWwSIT3ZxZHnVCnOvhqOuGpopEPrpIgFCuZRCLzrsUP 7VHG/E/Sm2+CEHbBzsX1dOuH+GZVePMVbrmdYGctRm+3hJb/Ic7RBgeT6axFlS7hJB+etcRlu/CP Ioq369I0hNPImeZzhpsrELjEwyZ6rlxUT+JOLZQDKCro7YKvAsonrF9vLnz5yseU9eut6IHyCevX G9cD5WN8HPYvm2kug+zWI6XXhJ27M5nIbLlNyhzopIcJO4MtBE0FdhJb+SSSmLAzeI8+vYswhCc3 SpyyfbHjUQYK2x0aBZONrgvbKRXaGzE0YjuognXCwOrHtQwgNul+Fd9j9eKIuxkgS9uzZmc6j1ss AFsQ6Qz9ZSuL7jP0SQvnUVHep/C6JBceDW3cknlUNBNPer9j+LjfxscA6rcDMoD6bYUMoJb4aD/z 2D2RDtJ/c2RgsWnZ7mIYdmRmnrCZ2QLxtoCB9k3C+asle9tjob5vElDYDqrvmwQUtncqe5ndNwlY g+2bBKyWXaPdRy6ncpRi75sukD0JEDQahrwJQMOQNwFoGPImAPUn726Q4cibgMXmBsupLnkTgHAI 51HfArnkTQBic4NmO/POqNz3UMrhh9sByJuAwnZQnbwJKGzvtJE3AQuHcCKhgmWpjoA1DHkTgIYh bwLQMORNABqGvAlAw5A3Aag/eXeDDEfeBCw2N1hOdcmbAMSmBwvkkjcBCIdwuKGRvDHrH528CShs B9XJm4DC9k6FUO0hlYDFdlAFy5I3AQuHcILBYGFwc5QahrwJGg1D3gSgYcibADQMeROA+pN3N8hw 5E3AYnOD5VSXvAlAbHqwQC55E4DY3NBI3piMj07eBBS2g+rkTUBhe6dCqJbnCFhsB1WwLHkTsDBe epM3AQiHPBSIo9Ew5E3QaBjyJgANQ94EoP7k3Q0yHHkTsNjcYDnVJW8CEJseLJBL3gQgNjc0kjfm yKOTNwGF7aA6eRNQ2N6pEKolbwIW20EVLEt1BKxhyJsAhIHZm7wJQDjkAUCYRRw3DUPeBI2GIW8C UH/y7gYZjrwJWGxusJzqkjcBiE0PFsglbwIQmxvUPVu4L0q+njpqCQLqPYPyVgMZ8KTFSVRAo+BX sRQZVCKJ7tshPQFLDRmILeFBVfG1lLce7WL3uCVAyFDxIoklXum+x1s6TiHCeHKgkuD688x7pwtg avMwpPZv3kCNkVsupMqcsDwM1lncb6BkZ1PeLFfSoJRI1WWZEiAc+B4KgkxZj5qs6nxgIJY/mWb8 v61Bxb+hZi0qxxwfj59PzuFSDfZAYZMSchdH8m4GF9kzmdiBesTfYdmwkMVKtYEGOA0+cUF1FcIV 6BAWIjuggrlIb+824TX6qkItt+1x6btSj3KBZUGYrXTS4/bufur1t6y7UDfMD6wZb6AftL2HQ7Tl 6guEoi9c0u702LxCe1sLu4tFor0Ef7xPlSOh6A//M6cDJvoRaLHQPxNJ8jFAnxZy0z40EctC946O cZetiAJfF3LdPj/DS+i4kiYBEBruYvRXpUR7zKTb9UJk5v58a9ir3Qmr3fbDXt+n1ca0eQurx6yg Wr19bXspaZPwdZAkUqZYLVANXNOnSwlwXYsASvk+23JGN1WTOL0tF+sInUEW9Y+k/dyfzMaXlyZP oM4TU9dWVI5emPD8uauo1G1gGhzdbqK9lA+3OUTPXNVDVpmrqt8hw3k7C1Ss10geaOYWWzLt+ERG a46rS1P1+zHY1EK97PNUJyeuyokwb2fVPgy1b6Lzi+PT0ZlekYmrbK9ieOrP4/V8ixdgy0Jh24aK 7Cp7nyIOq/aoxmHZrwzdNw5LWdZnZLv/T43cHLfqEARbftWSqjgYmjnBqiU9dpyas8/mdYQ8aLc8 3DRUobwpJ/w59fXzCdR3lXwWqkILqBzfFlJpBrxYioEzBFbRw2fJ6arEQJ+FNjKf+s9Hp2NtDmcM bqjq6IFDXoyPMZlAbikvT4PNtcSHJrOvmSPc7oBmcMx6NLv/JyTv+K8aDbqrb0ZpKdqIwyXTMAzU nBxvJdysryfHUjdzkkNLeqLkKKPPidSnimZ1RC1z6z+MZcfc1VjWXX1jWUv5f8Zy6D7I2YPvTK7V r5LsXgNUDROkqYSfvlA/RJHZtxNNMd5+jiNn9f4LTwTp3DV3iQ7vYHBK7hx5dVv3kbc50Y1xGp8K HLsUqsa4ySRtDwaO3CfK/d3GUk3F/o8BVW2qEWT68fmpb4I5WANlWbv+B2MCXtj9LcL686sTFrkZ 0hQZNT1SiKHyjFHrdB+ETKfBf+zwMUeOhdZhlsNndzLtMc2B58cGVdpix6jbHj6OzXY2abfbQMFj HqXhx4dYBmqOLPU+5Mq+MKxaAt/l77qbgsqlmzrnQj0hTmp/mXh6enp+bkjUHKhjfEelOGPqT+BH H1BCCC8XIVy3QWJ+JgFaISoqLxLLxMpf/QsAAP//AwBQSwMEFAAGAAgAAAAhAI6rkb/5AgAAsQ0A ABIAAAB3b3JkL251bWJlcmluZy54bWzMV0tu2zAQ3RfoHQztE33tJEKUIB8bSNEGBZKia1qiI6L8 CCRlxdtcpkfosXKFDkVJsWUgsJUsvDGt+ZKP80aj88tnRkdLLBURPHH8Y88ZYZ6KjPCnxPn1ODs6 dUZKI54hKjhOnBVWzuXF1y/nVcxLNscSDEcQg6t4Cepc6yJ2XZXmmCF1LArMQbkQkiENj/LJZUj+ KYujVLACaTInlOiVG3jexGnCiMQpJY+bEEeMpFIosdDGJRaLBUlxs7Qecpe81vNWpCXDXNcZXYkp 7EFwlZNCtdHY0GhwxLwNsnzvEEtGW7uq2CVbJlEFODNqt10JmRVSpFgpkN5aZRfR997L3QBoQnQe u2xhM2e7E4YI78KY8ujdf3d5x3B5rs3tmlBvBwEsLqCY0FxpiVJ9X7LRxtNdljhebcIVyUC3RDRx xpPQi0IvdFzjzEqqyXe8xPRxVeDWJl/NJcl+GB01OmurWUFbi8gPb4Lr68Bq6NIoCCwmI/zVBU0T 5/Z6Op3OoqndQ8lmTLf+85JSrDvvR/zcqV5f/nXyb2nrQPGiMS9+SrNzws2RjDhxTk7rrDniTzX7 wolnQrhV3BhL6yNngmsFbkilhCTOw4rNBVRUFWOk9JUiCGSEPZRwNVWcXwFu60ap2lATDqkzvECA U5OuzgNpAQmzx3Vc/DdcvMg78zy4AkiigVLAJNMB/BonaBmyw8K3SEC/2A07sS9y/tgbBt2NKCXB cnSPqzWselIDWE+U74dasIXa+PNRe335uy9uQRAMw+03FKh5RUDT7CpsU7YfQLaIaro1ZWUL7VPL agAlg7NoGEBvnNzi3561E23VziEwLpxAczJ3v2+z6hPJdqee9OOMs/xaL6jDYFwUDmzym+yyqG3K 9mMcjFvtC+6gGDf2B7byz2PcyRY0h8C48enAXt3jVtOPetKPMw6+E3oFdRiMm4wHtvBNdg1hHIxQ a2OtGaVgBAKU4NdMtXZSWrO4M7NgPd62gx9Y1gMgrPZT6+I/AAAA//8DAFBLAwQUAAYACAAAACEA eq7jjVEBAACDAgAAEQAIAWRvY1Byb3BzL2NvcmUueG1sIKIEASigAAEAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAnJJRS8MwFIXfBf9DyXubdEMZpc1AZb44EJwovoWbuy3YpCGJ6/bvTdutbuiT kJfknvvlnJuU872ukx06rxpTkTxjJEEDjVRmU5HX1SKdkcQHYaSoG4MVOaAnc359VYItoHH47BqL Lij0SSQZX4CtyDYEW1DqYYta+CwqTCyuG6dFiFu3oVbAp9ggnTB2SzUGIUUQtAOmdiSSI1LCiLRf ru4BEijWqNEET/Mspz/agE77Pxv6yplSq3CwMdPR7jlbwlAc1XuvRmHbtlk77W1E/zl9Xz699FFT ZbpZARJeSijAoQiN46ABSnp20A2vFj4s45zXCuXdgS8VbAXWySPG8Sgh0Zf0t6prdLhT3WvxSa8Y t/HGPuBwLcokWi6GgKfK2/T+YbUgfMLym5TFNVuxWZFPC8Y+OoMX/V2E4UAfbf6beALw3vHlt+Hf AAAA//8DAFBLAwQUAAYACAAAACEAONjG3VoCAABKCAAAEgAAAHdvcmQvZm9udFRhYmxlLnhtbLyV T47bIBTG95V6B4t9x9hJHCeaZDRNJ8tZdKbqmtg4QTJgAYknZ+iy9+gNepv2Hn0YO38ZNak0tWVb ecADfnzfy+3dCy+DDVWaSTFB0Q1GARWZzJlYTtCX5/mHFAXaEJGTUgo6QVuq0d30/bvbelxIYXQA 44UeqwlaGVONw1BnK8qJvpEVFdBWSMWJgZ9qGcqiYBn9JLM1p8KEMcZJqGhJDMytV6zSqM1WX5Kt liqvlMyo1rBYXrp8nDCBpu3qgnosCIdVP235QpZNvCJCahpB04aUE4QHcEc4hmeIE/gO8BCFNkG2 IkpTs+sYu3BBOCu3XVRJToRrqJjJVl18QxQji5K6Js2W0LDWCwwTthdykQigH0fisz6940jW5EkP RkEE8uwyw/JDdzznIBh/WjtApDSPAKdb8e8f3379/N5u5YSRpZNA+h5829t1PGGUJi58zIisjWzz XoWot0cUp+ncbq+N7BBFSRvxIoIBfXgi2+dyRDO5Voyq4JHWXsHEIJQeHoFUrFhimKLvhQGrbXR0 DIPLnCqfYgr2QnM34lAuD7CB+H4+37OYQWSY9js6OxZ49BcWQMLluZzFM+NUWxLB50boVk+nBrIc EiAyABKWR+8qHtcbyBF5OCfSnDOY7E2JfIVaY4uj9mpjAGdzcvm14S0m/2qUzhb/uZbMSMkWinlB xHjeiMGKow+SgLcfhNckumZau/4XVtV7Sz0+FIV1Plj1Y2uKvSg6Wq+VDBg3asR1uU1mhAMI8goJ awtnD2uT60hcbw8/CaiEb0Oi/aPR0z8AAAD//wMAUEsDBBQABgAIAAAAIQCNaDQB5AEAAOADAAAQ AAgBZG9jUHJvcHMvYXBwLnhtbCCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJxT y27bMBC8F+g/CLrHlJzUaYI1g8JBkUPbGLCSnFlqZROlSIJkjLhf36VUy3TbU3WafWh2NLuCu7de F3v0QVmzLOtZVRZopG2V2S7Lp+bzxceyCFGYVmhrcFkeMJR3/P07WHvr0EeFoSAKE5blLkZ3y1iQ O+xFmFHZUKWzvheRQr9ltuuUxHsrX3s0kc2rasHwLaJpsb1wE2E5Mt7u4/+StlYmfeG5OTgSzKHB 3mkRkX9LcjSwKQGNjUI3qkdeU3oKYC22GHh9A2xE8GJ9G/j8Q3UNbMSw2gkvZCT7eH01v7kElmXg k3NaSRHJWv5VSW+D7WLxOJhQJAZgeQuQMRuUr17FA6+A5SF8USapSXJGSPq82HrhdoFf0uAshI0U GldkAO+EDgjslIAHFGm5a6FINOzj7R5ltL4I6ietd14W30XAZNuy3AuvhIlkX2obgwFrF6LnjYqa uKk2xgPM23KsrpK91EvgvDElRw1UOFc3TAiPHX1b/IfYOhc7aBilZnIyOM34g3VleyfMgYZPiBz+ EZ5cY+/Tyfz28DyZrf5Fxd3GCZn2s7he0HWcjiCrwYaOBVva6pHxlIAHMtzrNJbeNVtsjz1/F9JZ PY8/LK/ns4qe4Y6OOTqF6U/ivwAAAP//AwBQSwECLQAUAAYACAAAACEAjOFQsJYBAAAwBwAAEwAA AAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQAekRq38wAA AE4CAAALAAAAAAAAAAAAAAAAAM8DAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQDegMHnMQEA AEEFAAAcAAAAAAAAAAAAAAAAAPMGAAB3b3JkL19yZWxzL2RvY3VtZW50LnhtbC5yZWxzUEsBAi0A FAAGAAgAAAAhAJgfKxphPwAA0xQEABEAAAAAAAAAAAAAAAAAZgkAAHdvcmQvZG9jdW1lbnQueG1s UEsBAi0AFAAGAAgAAAAhAE8UhS5yAQAA3gMAABIAAAAAAAAAAAAAAAAA9kgAAHdvcmQvZm9vdG5v dGVzLnhtbFBLAQItABQABgAIAAAAIQAzAgZocwEAANgDAAARAAAAAAAAAAAAAAAAAJhKAAB3b3Jk L2VuZG5vdGVzLnhtbFBLAQItABQABgAIAAAAIQDHHG0UnAYAAFEbAAAVAAAAAAAAAAAAAAAAADpM AAB3b3JkL3RoZW1lL3RoZW1lMS54bWxQSwECLQAUAAYACAAAACEA+a8sMLwEAAAyFAAAEQAAAAAA AAAAAAAAAAAJUwAAd29yZC9jb21tZW50cy54bWxQSwECLQAUAAYACAAAACEABevIF+kEAABWDQAA EQAAAAAAAAAAAAAAAAD0VwAAd29yZC9zZXR0aW5ncy54bWxQSwECLQAUAAYACAAAACEAKIdxpc8A AAAfAQAAFAAAAAAAAAAAAAAAAAAMXQAAd29yZC93ZWJTZXR0aW5ncy54bWxQSwECLQAUAAYACAAA ACEAC9wlSKgJAABvSwAADwAAAAAAAAAAAAAAAAANXgAAd29yZC9zdHlsZXMueG1sUEsBAi0AFAAG AAgAAAAhAI6rkb/5AgAAsQ0AABIAAAAAAAAAAAAAAAAA4mcAAHdvcmQvbnVtYmVyaW5nLnhtbFBL AQItABQABgAIAAAAIQB6ruONUQEAAIMCAAARAAAAAAAAAAAAAAAAAAtrAABkb2NQcm9wcy9jb3Jl LnhtbFBLAQItABQABgAIAAAAIQA42MbdWgIAAEoIAAASAAAAAAAAAAAAAAAAAJNtAAB3b3JkL2Zv bnRUYWJsZS54bWxQSwECLQAUAAYACAAAACEAjWg0AeQBAADgAwAAEAAAAAAAAAAAAAAAAAAdcAAA ZG9jUHJvcHMvYXBwLnhtbFBLBQYAAAAADwAPAL8DAAA3cwAAAAA= --_005_9488CAA648904072B71210F0A71F4E95telefonicacom_ Content-Type: text/html; name="ATT00001.htm" Content-Description: ATT00001.htm Content-Disposition: attachment; filename="ATT00001.htm"; size=1111; creation-date="Mon, 11 May 2015 13:35:06 GMT"; modification-date="Mon, 11 May 2015 13:35:06 GMT" Content-ID: <1EF1C647115405408E424E3E1B677B1A@eurprd06.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWwgY2hhcnNldD11cy1hc2NpaSI+PC9oZWFkPjxib2R5IHN0eWxlPSJ3b3JkLXdyYXA6IGJy ZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBh ZnRlci13aGl0ZS1zcGFjZTsiPjxkaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEx1Y2lkYUdy YW5kZTsiPjxkaXY+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGRpdiBmcHN0eWxlPSIxIiBvY3Np PSIwIiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyBmb250LXNpemU6IDE0cHg7IGZvbnQt ZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+PC9kaXY+PC9ibG9ja3F1b3RlPjwvZGl2Pjxi cj48L2Rpdj48ZGl2IGFwcGxlLWNvbnRlbnQtZWRpdGVkPSJ0cnVlIj4NCjxkaXYgc3R5bGU9ImNv bG9yOiByZ2IoMCwgMCwgMCk7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87 IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9u ZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsg LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13 ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1z cGFjZTsiPi0tPGJyPiJFc3RhIHZleiBubyBmYWxsYXJlbW9zLCBEb2N0b3IgSW5maWVybm8iPGJy Pjxicj5EciBEaWVnbyBSLiBMb3Blejxicj5UZWxlZm9uaWNhIEkrRDxicj48YSBocmVmPSJodHRw Oi8vcGVvcGxlLnRpZC5lcy9kaWVnby5sb3Blei8iPmh0dHA6Ly9wZW9wbGUudGlkLmVzL2RpZWdv LmxvcGV6LzwvYT48YnI+PGJyPmUtbWFpbDogZGllZ28uci5sb3BlekB0ZWxlZm9uaWNhLmNvbTxi cj5UZWw6ICZuYnNwOyAmbmJzcDsrMzQgOTEzIDEyOSAwNDE8YnI+TW9iaWxlOiArMzQgNjgyIDA1 MSAwOTE8YnI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTwvZGl2Pg0KDQo8L2Rp dj4NCjxicj48L2Rpdj48L2JvZHk+PC9odG1sPg== --_005_9488CAA648904072B71210F0A71F4E95telefonicacom_-- From nobody Tue May 12 04:07:33 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 220931A87A9; Tue, 12 May 2015 04:07:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.74 X-Spam-Level: * X-Spam-Status: No, score=1.74 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UvjLhoyo54tB; Tue, 12 May 2015 04:07:24 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E87031A8779; Tue, 12 May 2015 04:07:22 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BSK47304; Tue, 12 May 2015 11:07:21 +0000 (GMT) Received: from SZXEMA411-HUB.china.huawei.com (10.82.72.70) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 12 May 2015 12:07:19 +0100 Received: from SZXEMA502-MBS.china.huawei.com ([169.254.4.144]) by szxema411-hub.china.huawei.com ([10.82.72.70]) with mapi id 14.03.0158.001; Tue, 12 May 2015 19:07:10 +0800 From: "Xialiang (Frank)" To: Linda Dunbar , "i2nsf@ietf.org" , Kathleen Moriarty Thread-Topic: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93 Thread-Index: AdCI3eREQdBVQ8yORRe/7nCVEnyK2QDwXbrg Date: Tue, 12 May 2015 11:07:10 +0000 Message-ID: References: <4A95BA014132FF49AE685FAB4B9F17F657C11DC6@dfweml701-chm> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657C11DC6@dfweml701-chm> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.135.43.91] Content-Type: multipart/alternative; boundary="_000_C02846B1344F344EB4FAA6FA7AF481F12ADB7711SZXEMA502MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "i2rs@ietf.org" , "dots@ietf.org" , "netmod@ietf.org" Subject: [I2nsf] =?gb2312?b?tPC4tDogIEZ1cnRoZXIgTmFycm93aW5nIHRoZSBJMk5T?= =?gb2312?b?RiBzY29wZTogdGhlIG5ldyBjaGFydGVyIGZvciBJRVRGCTkz?= X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 11:07:28 -0000 --_000_C02846B1344F344EB4FAA6FA7AF481F12ADB7711SZXEMA502MBSchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgTGluZGEsDQpJIGFncmVlIHRoYXQgd2UgY2FuIHNwZWNpZnkgY2FwYWJpbGl0eSBpbnRlcmZh Y2UgZmlyc3RseSwgYW5kIGxlYXZlIHRoZSBjdXJyZW50bHkgdmFndWUgc2VydmljZSBpbnRlcmZh Y2Ugb3V0IG9mIHNjb3BlIG5vdy4gQnV0IHN0aWxsLCBhcyBhbiBlc3NlbnRpYWwgcGFydCBvZiB0 aGUgd2hvbGUgc29sdXRpb24sIHRoZSBzZXJ2aWNlIGludGVyZmFjZSBpcyBhbHNvIHZlcnkgaW1w b3J0YW50IGZvciB2YXJpb3VzIGNsaWVudHMgdG8gZXhwcmVzcyB0aGVpciBjdXN0b20gc2VjdXJp dHkgcmVxdWlyZW1lbnQgZmxleGlibHkuIFNvLCBJIHN1Z2dlc3Qgd2UgY2FuIHNldCB0aGUgc3Bl Y2lmaWNhdGlvbiBvZiBzZXJ2aWNlIGludGVyZmFjZSBhcyB0aGUgc2Vjb25kIHBoYXNlIG9mIEky TlNGIHdvcmsuDQoNCk90aGVyIGNvbW1lbnRzIGFyZSBpbmxpbmU6DQoNCkIuUi4NCkZyYW5rDQoN CreivP7IyzogSTJuc2YgW21haWx0bzppMm5zZi1ib3VuY2VzQGlldGYub3JnXSC0+rHtIExpbmRh IER1bmJhcg0Kt6LLzcqxvOQ6IDIwMTXE6jXUwjfI1SAyMzo1Mw0KytW8/sjLOiBpMm5zZkBpZXRm Lm9yZzsgS2F0aGxlZW4gTW9yaWFydHkNCrOty806IGkycnNAaWV0Zi5vcmc7IGRvdHNAaWV0Zi5v cmc7IG5ldG1vZEBpZXRmLm9yZw0K1vfM4jogW0kybnNmXSBGdXJ0aGVyIE5hcnJvd2luZyB0aGUg STJOU0Ygc2NvcGU6IHRoZSBuZXcgY2hhcnRlciBmb3IgSUVURiA5Mw0KDQpUaGFua3MgdG8gSTJO U0YgY29udHJpYnV0b3JzIGZvciB0aGUgZ29vZCBwcm9ncmVzc2VzIG1hZGUgc2luY2UgIElFVEY5 MiBzaWRlIG1lZXRpbmdzLiBBbW9uZyB0aGUgdHdvIEkyTlNGIGludGVyZmFjZXMsICBpLmUuIHRo ZSBjbGllbnQgZmFjaW5nIFNlcnZpY2UgSW50ZXJmYWNlIGFuZCB0aGUgTlNGIGZhY2luZyBDYXBh YmlsaXR5IEludGVyZmFjZSwgdGhlIHdvcmsgdG8gYmUgZG9uZSBhdCB0aGUgQ2FwYWJpbGl0eSBJ bnRlcmZhY2UgYmVjb21lcyB2ZXJ5IGNsZWFyIGFuZCBjb25jcmV0ZS4gQnV0IHRoZSBTZXJ2aWNl IEludGVyZmFjZSBpcyBzdGlsbCBhIGxpdHRsZSB2YWd1ZS4NCg0KVGhlIGZlZWRiYWNrIGZyb20g bGFzdCBJRVRGIHNpZGUgbWVldGluZ3Mgd2FzICJ0aGUgc2NvcGUgaXMgdG9vIGJpZyBmb3Igb25l IElFVEYgV0ciLiBUaGVyZWZvcmUsIHdlIGFyZSBsZWFuaW5nIHRvd2FyZHMgbmFycm93aW5nIHRo ZSBJMk5TRiBzY29wZSB0byB0aGUgQ2FwYWJpbGl0eSBJbnRlcmZhY2UuIFRoZSB0aGlua2luZyBs b2dpYyBpczogT25jZSB0aGUgQ2FwYWJpbGl0eSBJbnRlcmZhY2UgaXMgY29tcGxldGVkLCB3ZSB3 aWxsIHNlZSBtb3JlIGNsZWFybHkgdGhlIHdvcmsgZm9yIFNlcnZpY2UgaW50ZXJmYWNlLiBFdmVu IGlmIENhcGFiaWxpdHkgbGF5ZXIgYWxvbmUgaXMgc3RhbmRhcmRpemVkLCBpdCBpcyBhIGdpYW50 IGxlYXAgZm9yd2FyZCBpbiBidWlsZGluZyBibG9ja3MgZm9yIFNlcnZpY2UgUHJvdmlkZXIgdG8g YXV0b21hdGUgdGhlaXIgU2VjdXJpdHkgQ29udHJvbGxlciB0aGF0IGNhbiB1dGlsaXplIE5TRiBi eSBtdWx0aXBsZSB2ZW5kb3JzDQoNCkhlcmUgaXMgdGhlIG5hcnJvd2VyIHNjb3BlZCBJMk5TRiBj aGFydGVyLiBZb3VyIGNvbW1lbnRzIGFuZCBzdWdnZXN0aW9ucyBhcmUgZ3JlYXRseSBhcHByZWNp YXRlZC4gQ0Ohr2VkIHRvIERPVFMsIEkyUlMsIGFuZCBOZXRtb2QgZ3JvdXBzIGZvciB3aWRlciBy ZXZpZXcuDQoNCg0KDQpFbnRlcnByaXNlcywgcmVzaWRlbnRpYWwsIGFuZCBtb2JpbGUgY3VzdG9t ZXJzIGFyZSBpbmNyZWFzaW5nbHkgY29uc3VtaW5nIG5ldHdvcmsgZnVuY3Rpb25zLCBlc3BlY2lh bGx5IG5ldHdvcmsgc2VjdXJpdHkgcmVsYXRlZCBmdW5jdGlvbnMgdGhhdCBhcmUgbm90IHJ1bm5p bmcgb24gdGhlaXIgcHJlbWlzZXMuICBJbiBhZGRpdGlvbiwgdGhlIEV1cm9wZWFuIFRlbGVjb21t dW5pY2F0aW9ucyBTdGFuZGFyZHMgSW5zdGl0dXRlIChFVFNJKSBOZXR3b3JrIEZ1bmN0aW9uIFZp cnR1YWxpemF0aW9uIChORlYpIGluaXRpYXRpdmUgY3JlYXRlcyBuZXcgbWFuYWdlbWVudCBjaGFs bGVuZ2VzIGZvciBzZWN1cml0eSBwb2xpY2llcyB0byBiZSBlbmZvcmNlZCBieSBkaXN0cmlidXRl ZCwgdmlydHVhbCwgbmV0d29yayBzZWN1cml0eSBmdW5jdGlvbnMgKHZOU0YpLiBXaXRob3V0IHN0 YW5kYXJkIGludGVyZmFjZSB0byBleHByZXNzLCBtb25pdG9yLCBhbmQgbWFuYWdlIHNlY3VyaXR5 IHBvbGljaWVzIHRvIHNlY3VyaXR5IGZ1bmN0aW9ucyBkZXBsb3llZCBhdCBkaWZmZXJlbnQgcHJl bWlzZXMsIGl0IGJlY29tZXMgdmlydHVhbGx5IGltcG9zc2libGUgZm9yIHNlY3VyaXR5IHNlcnZp Y2UgcHJvdmlkZXJzIHRvIGF1dG9tYXRlIHRoZSBzZXJ2aWNlIG9mZmVyaW5nIHV0aWxpemluZyBz ZWN1cml0eSBmdW5jdGlvbnMgYnkgbXVsdGlwbGUgdmVuZG9ycy4NCg0KVGhlIHVsdGltYXRlIGdv YWwgb2YgSTJOU0YgaXMgdG8gZW5hYmxlIGVudGVycHJpc2VzIHRvIHV0aWxpemUgc2VjdXJpdHkg ZnVuY3Rpb25zIG5vdCBob3N0ZWQgb24gdGhlaXIgb3duIHByZW1pc2VzIGJ1dCBpbnN0ZWFkIGhv c3RlZCBpbiBzZXJ2aWNlIHByb3ZpZGVyIGRvbWFpbiwgdG8gZXN0YWJsaXNoIGhvdyB0byBjb21t dW5pY2F0ZSBkZXNpcmVkIHNlY3VyaXR5IHBvbGljaWVzIHRvIE5TRiBhbmQgaG93IHRvIGdldCBw ZXJmb3JtYW5jZSBkYXRhIG9yIHJlcG9ydCBvdXQgb2YgTlNGIG9yIHZOU0YuDQpbRnJhbmtdOiB0 aGUgSTJOU0YgY2xpZW50cyBkbyBub3Qgb25seSBpbmNsdWRlIGVudGVycHJpc2UuIFNvLCBjaGFu Z2UgobBlbnRlcnByaXNlobEgdG8gobBJMk5TRiBjbGllbnRzobEuIFdoZXJlIGFyZSB0aGUgcGVy Zm9ybWFuY2UgZGF0YSBvciByZXBvcnQgc2VudCB0bz8gSSB0aGluayB0aGV5IHNob3VsZCBiZSB0 aGUgc2VjdXJpdHkgc2VydmljZSBwcm92aWRlcnMgb3IganVzdCB0aGUgSTJOU0YgY2xpZW50cy4N Cg0KVGhlcmUgYXJlIHR3byBsYXllcnMgb2YgaW50ZXJmYWNlczoNCg0KLSAgICAgICAgICBTZWN1 cml0eSBQb2xpY2llcyBmYWNpbmcgc2VjdXJpdHkgZnVuY3Rpb25zIChJMk5TRiBDYXBhYmlsaXR5 IExheWVyKQ0KDQotICAgICAgICAgIFNlY3VyaXR5IFBvbGljaWVzIGZhY2luZyBjbGllbnRzIChJ Mk5TRiBTZXJ2aWNlIExheWVyKQ0KDQpUaGUgSTJOU0YgQ2FwYWJpbGl0eSBMYXllciBzcGVjaWZp ZXMgdGhlIGZ1bmN0aW9uYWwgc2VjdXJpdHkgcG9saWNpZXMsIHdoaWNoIGFyZSB0cmFuc2xhdGVk IGZyb20gdGhlIGNsaWVudCBzZWN1cml0eSBwb2xpY2llcywgdG8gc2VjdXJpdHkgZnVuY3Rpb25z LiBJMk5TRiB3aWxsIE5PVCBzdGFuZGFyZGl6ZSBzZWN1cml0eSBmdW5jdGlvbnMgb3IgZGV2aWNl cy4gSW5zdGVhZCwgSTJOU0YgaXMgb25seSB0byBzdGFuZGFyZGl6ZSB0aGUgcG9saWN5IHByb3Zp c2lvbmluZyB0byB0aGUgc2VjdXJpdHkgZnVuY3Rpb25zIChub3QgZGV2aWNlcyksIGluIHRoZSBm b3JtIG9mIKGwU3ViamVjdCCoQyBPYmplY3QgqEMgRnVuY3Rpb24gqEMgQWN0aW9uobEgcGFyYWRp Z20uDQoNClRoZSBJMk5TRiBTZXJ2aWNlIExheWVyIGlzIGZvciBjbGllbnRzIHRvIGV4cHJlc3Mg YW5kIG1vbml0b3Igc2VjdXJpdHkgcG9saWNpZXMgZm9yIHRoZWlyIHNwZWNpZmljIGZsb3dzLCB3 aGljaCBpcyB1c3VhbGx5IGJhc2VkIG9uIGN1c3RvbWVyc6GvIGxvZ2ljYWwgbmV0d29ya3MsIGFk ZHJlc3NlcyBhbmQgY29udGV4dC4gSTJOU0YgU2VydmljZSBMYXllciBjYW4gYWxzbyBiZSBzZWN1 cml0eSBleHBlY3RhdGlvbiBvciBsb29zZSBzZWN1cml0eSByZXF1aXJlbWVudCwgZXNwZWNpYWxs eSBmb3IgY3VzdG9tZXJzIHdobyBkb26hr3QgaGF2ZSB0aGUgc2VjdXJpdHkgZXhwZXJ0aXNlLg0K W0ZyYW5rXTogZm9yIHRoZSB0d28gaW50ZXJmYWNlcywgbm90IG1lbnRpb25pbmcgdGhlIGZ1bmN0 aW9ucyByZWxhdGVkIHdpdGggcGVyZm9ybWFuY2UgZGF0YSBvciByZXBvcnQ/DQoNClRoZSBjb25j cmV0ZSB3b3JrIGF0IHRoZSBMMk5TRiBDYXBhYmlsaXR5IExheWVyIGluY2x1ZGVzDQoNCi0gICAg ICAgICAgVGhlIGluZm9ybWF0aW9uYWwgJiBkYXRhIG1vZGVscyBmb3IgZWFjaCBjYXRlZ29yeSB0 byBiZSByZXByZXNlbnRlZCB0byB2aXJ0dWFsIG9yIHBoeXNpY2FsIG5ldHdvcmsgc2VjdXJpdHkg ZnVuY3Rpb25zLA0KDQotICAgICAgICAgIFRoZSBjYXBhYmlsaXR5IHJlZ2lzdHJ5IChJQU5BKSBv ZiBwb2xpY3kgcHJvdmlzaW9uaW5nIGNhcGFiaWxpdHkgdG8gZmxvdyBiYXNlZCBzZWN1cml0eSBm dW5jdGlvbiwgYW5kDQoNCi0gICAgICAgICAgVGhlIHByb3BlciBzZWN1cmUgY29tbXVuaWNhdGlv biBjaGFubmVscyB0byBjYXJyeSB0aGUgc2VjdXJpdHkgcG9saWNpZXMgYmV0d2VlbiBDb250cm9s bGVyIGFuZCBOU0ZzLg0KVGhlIGNhcGFiaWxpdHkgcmVnaXN0cnkgaXMgdG8gbWFrZSBpdCBmZWFz aWJsZSB0byBjYXRlZ29yaXplIG5ldHdvcmsgc2VjdXJpdHkgZnVuY3Rpb25zIHByb3ZpZGVkIGJ5 IGRpZmZlcmVudCB2ZW5kb3JzIGJhc2VkIG9uIHNlY3VyaXR5IHBvbGljeSBwcm92aXNpb25pbmcg Y2FwYWJpbGl0eSB3aXRob3V0IGFueSBuZWVkIHRvIHN0YW5kYXJkaXplIHNlY3VyaXR5IGZ1bmN0 aW9ucyB0aGVtc2VsdmVzLiAgU3RhbmRhcmQgcHJvdmlzaW9uaW5nIGNhcGFiaWxpdHkgaW50ZXJm YWNlIGlzIGFuIGVzc2VudGlhbCBidWlsZGluZyBibG9jayBmb3IgU2VjdXJpdHkgU2VydmljZSBQ cm92aWRlciB0byBhdXRvbWF0ZSB0aGVpciBTZWN1cml0eSBDb250cm9sbGVycyB0aGF0IGNhbiB1 dGlsaXplIE5TRiBieSBtdWx0aXBsZSB2ZW5kb3JzLiBUaGlzIGxheWVyIHdpbGwgbGV2ZXJhZ2Ug dGhlIGV4aXN0aW5nIHByb3RvY29scyBhbmQgZGF0YSBtb2RlbHMgZGVmaW5lZCBieSBJMlJTLCBO ZXRjb25mLCBhbmQgTkVUTU9ELg0KDQpGb3IgdGhlIEkyTlNGIFNlcnZpY2UgTGF5ZXIsIGl0IGlz IG91dCBvZiB0aGUgc2NvcGUgZm9yIEkyTlNGIChhdCBsZWFzdCBmb3Igbm93KSB0byBzdGFuZGFy ZGl6ZSB0aGUgaW50ZXJmYWNlIGZhY2luZyBjbGllbnRzLiBIb3dldmVyLCBJMk5TRiBjYW4gaGF2 ZSBpbmZvcm1hdGlvbmFsIGRyYWZ0cyBzaG93aW5nIHNhbXBsZSBBUElzIG9yL2FuZCBSRVNUZnVs IGludGVyZmFjZXMgdG8gY2xpZW50cyBhbmQgZGVtb25zdHJhdGluZyB0aGUgZmVhc2liaWxpdHkg b2YgdGhlbSBiZWluZyB0cmFuc2xhdGVkIHRvIHRoZSBDYXBhYmlsaXR5IExheWVyIHBvbGljaWVz Lg0KDQpTaW5jZSBkaWZmZXJlbnQgc2VjdXJpdHkgdmVuZG9ycyBzdXBwb3J0IGRpZmZlcmVudCBm ZWF0dXJlcyAmIGZ1bmN0aW9ucyBvbiB0aGVpciBkZXZpY2VzLCBJMk5TRiB3aWxsIGZvY3VzIG9u IGZsb3cgYmFzZWQgc2VjdXJpdHkgZnVuY3Rpb25zIHRoYXQgcHJvdmlkZSB0cmVhdG1lbnQgdG8g cGFja2V0cy9mbG93cywgc3VjaCBhcyBJUFMvSURTLCBXZWIgZmlsdGVyLCBhbmQgZmxvdyBmaWx0 ZXIuIChUaGV5IGFyZSBkaWZmZXJlbnQgZnJvbSBvdGhlciBzZWN1cml0eSBmdW5jdGlvbnMgc3Vj aCBhcyBBdXRoZW50aWNhdGlvbiwgQXV0aG9yaXphdGlvbiwgb3IgRW5jcnlwdGlvbikuIEV4ZW1w bGFyIHNlcnZpY2VzIGFzc29jaWF0ZWQgd2l0aCBGbG93IEJhc2VkIFNlY3VyaXR5IGZ1bmN0aW9u cyBpbmNsdWRlIGRlZXAgcGFja2V0IGluc3BlY3Rpb24sIHBhY2tldC9mbG93L3N0cmVhbSBmaWx0 ZXJpbmcgb3IgcGF0dGVybiBtYXRjaGluZyBhbmQgcmVtZWRpYXRpb24sIGV0Yy4NCg0KU2ltaWxh ciB0byBJMlJTIGZvY3VzaW5nIG9uIHRoZSBpbnRlcmZhY2UgdG8gUklCL0ZJQiBldmVuIHRob3Vn aCBtb3N0IHJvdXRlcnMgcHJvdmlkZSBmYXIgbW9yZSBmdW5jdGlvbnMgdGhhbiBSSUIvRklCLCB0 aGUgSTJOU0YgZm9jdXNlZCBmdW5jdGlvbnMgY2FuIGJlIGEgcG9ydGlvbiBvZiBmZWF0dXJlcyBz dXBwb3J0ZWQgYnkgdmVuZG9yc6GvIHNwZWNpZmljIGRldmljZXMuDQoNCkl0IGlzIGEgbm9uLWdv YWwgdG8gY3JlYXRlIG5ldyBwcm90b2NvbHMgb3IgZGF0YSBtb2RlbGluZyBsYW5ndWFnZXMgZm9y IEkyTlNGIGludGVyZmFjZXMuDQpJMk5TRiBXRyBEZWxpdmVyYWJsZXMgaW5jbHVkZToNCg0KDQot ICAgICAgICAgICBVc2UgQ2FzZSBkb2N1bWVudC4NCg0KLSAgICAgICAgICBGcmFtZXdvcmsgRG9j dW1lbnQuDQoNCi0gICAgICAgICAgUmVxdWlyZW1lbnQgZm9yIGV4dGVuc2lvbnMgKGlmIHRoZXJl IGFyZSBhbnkpIHRvIGV4aXN0aW5nIHByb3RvY29scyB1c2VkIGJ5IHRoZSBXRy4NCg0KLSAgICAg ICAgICAgR2FwIGFuYWx5c2lzIG9mIGV4aXN0aW5nIHByb3RvY29scyBhbmQgbW9kZWxpbmcgbGFu Z3VhZ2VzDQoNCi0gICAgICAgICAgQSBzaW5nbGUsIHVuaWZpZWQsIEluZm9ybWF0aW9uIE1vZGVs IGZvciBleHByZXNzaW5nIHBvbGljaWVzIHRvIHRoZSBGbG93IEJhc2VkIFNlY3VyaXR5IEZ1bmN0 aW9ucyBkZXNjcmliZWQgYWJvdmUuDQoNCi0gICAgICAgICAgQ29ycmVzcG9uZGluZyBEYXRhIE1v ZGVscyAoZS5nLiBZQU5HIG1vZGVscykgZGVyaXZlZCBmcm9tIHRoZSBhYm92ZSBJbmZvcm1hdGlv biBNb2RlbC4NCg0KLSAgICAgICAgICBJQU5BIHJlZ2lzdHJ5IGNvbnNpZGVyYXRpb24gZm9yIGZs b3cgYmFzZWQgc2VjdXJpdHkgZnVuY3Rpb24gcG9saWN5IHByb3Zpc2lvbmluZyBjYXBhYmlsaXR5 Lg0KDQotICAgICAgICAgICAoT3B0aW9uYWxseSkgQXBwbGljYWJpbGl0eSBTdGF0ZW1lbnRzIG9u IGhvdyB0byB1c2UgSTJSUywgTmV0Y29uZiwgYW5kIE5FVE1PRCB0byBjYXJyeSB0aGUgY29udGVu dCBvZiB0aGUgc3BlY2lmaWVkIGluZm9ybWF0aW9uL2RhdGEgbW9kZWxzLg0KDQpbVGhlIFdHIG1h eSBkZWNpZGUgdGhhdCB0aGUgVXNlIGNhc2VzLCBGcmFtZXdvcmssIGFuZCBSZXF1aXJlbWVudCBh cmUgSW5mb3JtYXRpb25hbCBkb2N1bWVudHMgb3Igc2ltcGx5IHJlZmVyZW5jZSBkb2N1bWVudHMg ZHVyaW5nIHRoZSBsaWZldGltZSBvZiB0aGUgV0cuIFRoZSBmcmFtZXdvcmssIHRoYXQgZGVzY3Jp YmVzIHRoZSBmdW5jdGlvbmFsIGNvbXBvbmVudHMgYW5kIHRoZSBJMk5TRiB3b3JrIGl0ZW1zLCBp cyB0byBtYWtlIEkyTlNGIHdvcmsgbW9yZSBvcmdhbml6ZWQuXQ0KDQpTdWdnZXN0ZWQgTWlsZXN0 b25lcw0KICAtIFVzZSBDYXNlIERvY3VtZW50OiAgQ2hhcnRlciB0aW1lICsgMSBtb250aCB0byBX RyBEb2N1bWVudA0KICAtIEZyYW1ld29yazogQ2hhcnRlciB0aW1lICsgNCBtb250aHMgdG8gV0cg RG9jdW1lbnQNCiAgLSBSZXF1aXJlbWVudHMgZm9yIGV4dGVuc2lvbnMgdG8gcHJvdG9jb2xzOiAg Q2hhcnRlciB0aW1lICsgNiBtb250aHMgdG8gV0cgZG9jdW1lbnQNCiAgLSBJbmZvIG1vZGVsOiBD aGFydGVyIHRpbWUgKyA3IG1vbnRocyB0byBXRyBEb2N1bWVudA0KICAtIElBTkEgcmVnaXN0cnkg Y29uc2lkZXJhdGlvbiArIDEwIG1vbnRocyB0byBXRyBEb2N1bWVudA0KICAtIEFsbCBFYXJseSBE cmFmdHMgdG8gSUVTRzogMTAgbW9udGhzDQoNCltkZWNpc2lvbiBwb2ludCCoQyArMTAgbW9udGhz XQ0KICAtIERhdGEgTW9kZWxzOiBDaGFydGVyICsgOSBNb250aHMgdG8gV0cgRG9jdW1lbnQNCiAg LSBBcHBsaWNhYmlsaXR5IFN0YXRlbWVudHM6IDEwIG1vbnRocyB0byBXRyBEb2N1bWVudA0KICAt IERhdGEgTW9kZWxzIGFuZCBBcHBsaWNhYmlsaXR5IFN0YXRlbWVudHMgdG8gSUVTRyAgLSAxNiBt b250aHMNCg0KVGhlIFdHIHdpbGwgd29yayBjbG9zZWx5IHdpdGggSTJSUywgTmV0Y29uZiBhbmQg TmV0bW9kIFdHcy4gVGhlIFdHIHdpbGwgY29tbXVuaWNhdGUgd2l0aCBleHRlcm5hbCBTRE9zIGxp a2UgRVRTSSBORlYgYW5kIHdpbGwgZW5jb3VyYWdlIG9wZW4gc291cmNlIGNvZGUgZGV2ZWxvcG1l bnQgcmVsYXRlZCB0byB0aGUgV0cgc2NvcGUgaW4gb3JnYW5pemF0aW9ucyBsaWtlIE9ORiwgT3Bl blN0YWNrLCBPREwsIGFuZCBPcGVuTkZWLg0KDQoNCkNoZWVycywNCkxpbmRhIER1bmJhcg0K --_000_C02846B1344F344EB4FAA6FA7AF481F12ADB7711SZXEMA502MBSchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Linda,

I agree that we can specify capability interface firstly, and lea= ve 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 expres= s their custom security requirement flexibly. So, I suggest we can set the = specification of service interface as the second phase of I2NSF work.<= /o:p>

 

Other comments are inline:

 

B.R.

Frank

 

=B7=A2=BC=FE=C8=CB: I2nsf [= mailto:i2nsf-bounces@ietf.org] =B4=FA= =B1=ED Linda Dunbar
=B7=A2= =CB=CD=CA=B1=BC=E4: 2015=C4=EA5=D4=C27=C8=D5 23:53
=CA=D5=BC=FE=C8=CB: i2nsf@ietf.org; Kathleen Moriarty
=B3=AD=CB=CD: i2rs@ietf.org; dots@ietf.org; netmod@ietf.org
=D6=F7=CC=E2: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93

 

Thanks to I2NSF contributors fo= r the good progresses made since  IETF92 side meetings. Among the two = I2NSF interfaces,  i.e. the client facing Service Interface and the NS= F 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 sid= e meetings was "the scope is too big for one IETF WG". Therefore,= we are leaning towards narrowing the I2NSF scope to the Capability Interfa= ce. The thinking logic is: Once the Capability Interface is completed, we will see more clearly the work for Service inte= rface. Even if Capability layer alone is standardized, it is a giant leap f= orward in building blocks for Service Provider to automate their Security C= ontroller that can utilize NSF by multiple vendors

 

Here is the narrower scoped I2N= SF charter. Your comments and suggestions are greatly appreciated. CC=A1=AF= ed to DOTS, I2RS, and Netmod groups for wider review.

 

 

 

Enterprises, residential, and m= obile customers are increasingly consuming network functions, especially ne= twork security related functions that are not running on their premises.&nb= sp; In addition, the European Telecommunications Standards Institute (ETSI) Network Function Virtualization (NFV) initiativ= e 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 premi= ses, it becomes virtually impossible for security service providers to auto= mate the service offering utilizing security functions by multiple vendors.

 

The ultimate goal of I2NSF is t= o 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.<= /o:p>

[Frank]: the I2NSF clients do not only include enterprise. So, ch= ange =A1=B0enterprise=A1=B1 to =A1=B0I2NSF clients=A1=B1. Where are the per= formance data or report sent to? I think they should be the security service providers or just the I2NSF clients.

 

There are two layers of interfa= ces:

-=    &n= bsp;      Security Policies facin= g security functions (I2NSF Capability Layer)

-=    &n= bsp;      Security Policies facin= g clients (I2NSF Service Layer)

 

The I2NSF= Capability Layer specifies the functional security policies, which are tra= nslated from the client security policies, to security functions. I2NSF wil= l 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 =A1=B0Subject =A8C Obj= ect =A8C Function =A8C Action=A1=B1 paradigm. 

&nbs= p;

The I2NSF Service Layer is for = clients to express and monitor security policies for their specific flows, = which is usually based on customers=A1=AF logical networks, addresses and c= ontext. I2NSF Service Layer can also be security expectation or loose security requirement, especially for customers who do= n=A1=AFt have the security expertise.

[Frank]: for the two interfaces, not mentioning the functions rel= ated with performance data or report?

 

The concrete work at the L2NSF = Capability Layer includes

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

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

-The proper secure commu= nication channels to carry the security policies between Controller and NSF= s.

The capability registry is to m= ake it feasible to categorize network security functions provided by differ= ent vendors based on security policy provisioning capability without any ne= ed to standardize security functions themselves.  Standard provisioning capability interface is an essenti= al building block for Security Service Provider to automate their Security = Controllers that can utilize NSF by multiple vendors. This layer will lever= age 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 interf= ace facing clients. However, I2NSF can have informational drafts showing sa= mple APIs or/and RESTful interfaces to clients and demonstrating the feasibility of them being translated to t= he Capability Layer policies.

&nbs= p;

Since different security vendor= s support different features & functions on their devices, I2NSF will f= ocus on flow based security functions that provide treatment to packets/flo= ws, such as IPS/IDS, Web filter, and flow filter. (They are different from other security functions such as Authenti= cation, Authorization, or Encryption). Exemplar services associated with Fl= ow Based Security functions include deep packet inspection, packet/flow/str= eam 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 t= han RIB/FIB, the I2NSF focused functions can be a portion of features suppo= rted by vendors=A1=AF specific devices.

 

It is a non-goal to create new = protocols or data modeling languages for I2NSF interfaces.

I2NSF WG Deliverables include:<= o:p>

 

-=    &n= bsp;       Use Case document= .

-=    &n= bsp;      Framework Document.

-=    &n= bsp;      Requirement for extensi= ons (if there are any) to existing protocols used by the WG.

-=    &n= bsp;       Gap analysis of e= xisting protocols and modeling languages

-=    &n= bsp;      A single, unified, Info= rmation Model for expressing policies to the Flow Based Security Functions = described above.

-=    &n= bsp;      Corresponding Data Mode= ls (e.g. YANG models) derived from the above Information Model.<= /span>

-=    &n= bsp;      IANA registry considera= tion for flow based security function policy provisioning capability.<= /o:p>

-=    &n= bsp;       (Optionally) Appl= icability Statements on how to use I2RS, Netconf, and NETMOD to carry the c= ontent of the specified information/data models.

 

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

 

Suggested Milestones=

  - Use Case Document:&nbs= p; Charter time + 1 month to WG Document

  - Framework: Charter tim= e + 4 months to WG Document

  - Requirements for exten= sions to protocols:  Charter time + 6 months to WG document

  - Info model: Charter ti= me + 7 months to WG Document

  - IANA registry consider= ation + 10 months to WG Document

  - All Early Drafts to IE= SG: 10 months

 

[decision point =A8C +10 mo= nths] 

  - Data Models: Char= ter + 9 Months to WG Document

  - Applicability Statemen= ts: 10 months to WG Document

  - Data Models and Applic= ability Statements to IESG  - 16 months

 

The WG will work closely with I= 2RS, Netconf and Netmod WGs. The WG will communicate with external SDOs lik= e ETSI NFV and will encourage open source code development related to the W= G scope in organizations like ONF, OpenStack, ODL, and OpenNFV.

 

 

Cheers,

Linda Dunbar<= /p>

--_000_C02846B1344F344EB4FAA6FA7AF481F12ADB7711SZXEMA502MBSchi_-- From nobody Tue May 12 20:55:36 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AE4E1A9105; Tue, 12 May 2015 20:55:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RdONEigTiZnf; Tue, 12 May 2015 20:55:29 -0700 (PDT) Received: from out4133-50.mail.aliyun.com (out4133-50.mail.aliyun.com [42.120.133.50]) by ietfa.amsl.com (Postfix) with ESMTP id 88C431A8F45; Tue, 12 May 2015 20:55:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1431489313; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=cwNWZqs8M1TIDYg6hwGFobH/ejKNObyv2IQQcH5xIuE=; b=mqGIdA/rUQb5VY3Vn9Whn+XICpW6+WLo2YWCazKFbrSyUNf9rTGPL7sbo8/cFl8g9ON9z4z3PtyZghulixUd5wTZ2XJrGGIcjMdWejUPWwGEEK8YHOdwMZPN9bqsq3dlHmMIlCfoa+m1ot916/Xeesp/aEehPfr6iy/DvPjfyfc= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R631e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=r41g03024; MF=dacheng.zdc@alibaba-inc.com; PH=DS; RN=6; RT=6; SR=0; Received: from 10.62.55.14(mailfrom:dacheng.zdc@alibaba-inc.com ip:182.92.253.23) by smtp.aliyun-inc.com(127.0.0.1); Wed, 13 May 2015 11:55:09 +0800 User-Agent: Microsoft-MacOutlook/14.4.9.150325 Date: Wed, 13 May 2015 11:55:02 +0800 From: "Dacheng Zhang" To: Linda Dunbar , "i2nsf@ietf.org" , Kathleen Moriarty Message-ID: Thread-Topic: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93 Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3514362909_21843223" Archived-At: Cc: "i2rs@ietf.org" , "dots@ietf.org" , "netmod@ietf.org" Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93 X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 03:55:35 -0000 > ´ËÓʼþʹÓà MIME ¸ñʽ¡£ÓÉÓÚÓʼþÔĶÁ³ÌÐò²»ÄÜʶ±ð ´Ë¸ñʽ£¬Òò´Ë£¬¿ÉÄÜÎÞ·¨Ê¶±ð¸ÃÓʼþµÄ·Ö²¿»ò²¿·ÖÄÚÈÝ¡£ --B_3514362909_21843223 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi=EF=BC=8CLinda: I like the current version of charter, which clarifies a reasonable scope o= f this work. Some tiny comments. 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. >>Dacheng: the third bullet is quite trival compared with the first two bul= lets, since we will try to re-use the work of I2RS,Netconf where the generation o= f security channels have already considered. So, maybe we could remove it. 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. >>Dacheng: I suggest to change the last sentence to =E2=80=9CIn this layer, we wi= ll leverage the existing protocols and data models defined by I2RS, Netconf, a= nd NETMOD as much as possible.=E2=80=9D Similar to I2RS focusing on the interface to RIB/FIB even though most routers provide far more functions than RIB/FIB, the I2NSF focused function= s can be a portion of features supported by vendors=E2=80=99 specific devices. >>Dacheng: the first part of this sentence is redundant. We don=E2=80=99t have to= imply that =E2=80=9Cwe work in this way because I2RS used to do similar things. So if y= ou want to challenge us, please challenge I2RS first=E2=80=9D. Maybe we could remove it. =E5=8F=91=E4=BB=B6=E4=BA=BA: Linda Dunbar =E6=97=A5=E6=9C=9F: 2015=E5=B9=B45=E6=9C=887=E6=97=A5 =E6=98=9F=E6=9C=9F=E5=9B=9B =E4=B8=8B=E5=8D=8811:53 =E8=87=B3: "i2nsf@ietf.org" , Kathleen Moriarty =E6=8A=84=E9=80=81: "i2rs@ietf.org" , "dots@ietf.org" , "netmod@ietf.org" =E4=B8=BB=E9=A2=98: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IET= F 93 Thanks to I2NSF contributors for the good progresses made since IETF92 sid= e 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. =20 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 th= e 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 =20 Here is the narrower scoped I2NSF charter. Your comments and suggestions ar= e greatly appreciated. CC=E2=80=99ed to DOTS, I2RS, and Netmod groups for wider review.=20 =20 =20 =20 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 Telecommunication= s 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. =20 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. =20 There are two layers of interfaces: - Security Policies facing security functions (I2NSF Capability Layer) - Security Policies facing clients (I2NSF Service Layer) =20 The I2NSF Capability Layer specifies the functional security policies, whic= h 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 =E2=80=9CSubject =E2=80=93 Object =E2=80=93 Function =E2=80=93 Action=E2=80=9D p= aradigm. =20 The I2NSF Service Layer is for clients to express and monitor security policies for their specific flows, which is usually based on customers=E2=80=99 logical networks, addresses and context. I2NSF Service Layer can also be security expectation or loose security requirement, especially for customer= s who don=E2=80=99t have the security expertise. =20 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. =20 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. =20 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. =20 Similar to I2RS focusing on the interface to RIB/FIB even though most routers provide far more functions than RIB/FIB, the I2NSF focused function= s can be a portion of features supported by vendors=E2=80=99 specific devices. =20 It is a non-goal to create new protocols or data modeling languages for I2NSF interfaces.=20 I2NSF WG Deliverables include: =20 - 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. =20 [The WG may decide that the Use cases, Framework, and Requirement are Informational documents or simply reference documents during the lifetime o= f the WG. The framework, that describes the functional components and the I2NSF work items, is to make I2NSF work more organized.] =20 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 W= G 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 =20 [decision point =E2=80=93 +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 =20 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. =20 =20 Cheers,=20 Linda Dunbar _______________________________________________ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf --B_3514362909_21843223 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable
Hi=EF=BC=8CLinda:

I like the current version of charter, which clarifies a reasonable s= cope of this work. Some tiny comments. 


The = concrete work at the L2NSF Capability Layer includes

-          <= /span>The informational & data models for each category to be represente= d to virtual or physical network security functions,

-          <= /span>The capability registry (IANA) of policy provisioning capability to fl= ow based security function, and

- =          The proper secu= re communication channels to carry the security policies between Controller = and NSFs.


>>Dacheng: the third bullet is quite tri= val compared with the first two bullets, since we will try to re-use the wor= k of I2RS,Netconf where the generation of security channels have already con= sidered.  So, maybe we could remove it. 


The capability registry is to make it fe= asible to categorize network security functions provided by different vendor= s based on security policy provisioning capability without any need to stand= ardize security functions themselves.  Standard provisioning capability= interface is an essential building block for Security Service Provider to a= utomate 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.


>>Dacheng: I suggest to change the last sentence to “= ;In this layer, we will leverage the existing protocols and data models defi= ned by I2RS, Netconf, and NETMOD as much as possible.”


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


=

>>Dache= ng: the first part of this sentence is redundant. We don’t have to imp= ly that “we work in this way becau= se I2RS used to do similar things. So if you want to challenge us, please ch= allenge I2RS first”. Maybe we could remove it. 

<= div>
=E5=8F=91=E4=BB=B6=E4=BA=BA: Linda Dunbar &l= t;linda.dunbar@huawei.com>=E6=97=A5=E6=9C=9F: 2015=E5=B9=B45=E6=9C=887=E6=97=A5 =E6=98=9F=E6=9C=9F=E5=9B=9B =E4= =B8=8B=E5=8D=8811:53
=E8=87=B3: "i2nsf@ietf.org" <i2nsf= @ietf.org>, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
=E6=8A=84=E9=80=81: "i2rs@ietf.org<= /a>" <i2rs@ietf.org>, "dots@ietf.org" <dot= s@ietf.org>, "netmod@ietf.org" &= lt;netmod@ietf.org>
=E4=B8=BB=E9=A2=98: [I2nsf] Further Narrowing the I2NSF scope:= the new charter for IETF 93

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

 

The feedback from last IETF side meetings was "the scope is too big for o= ne IETF WG". Therefore, we are leaning towards narrowing the I2NSF scope to = the Capability Interface. The thinking logic is: Once the Capability Interfa= ce is completed, we will see more clearly the work for Service interface. Even if Capabilit= y 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 co= mments and suggestions are greatly appreciated. CC’ed to DOTS, I2RS, a= nd Netmod groups for wider review.

 

<= o:p> 

 

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 Tele= communications Standards Institute (ETSI) Network Function Virtualization (NFV) initiative creates new manage= ment 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 f= unctions not hosted on their own premises but instead hosted in service prov= ider domain, to establish how to communicate desired security policies to NS= F and how to get performance data or report out of NSF or vNSF.

 

There are two layers o= f interfaces:

<= span style=3D"mso-list:Ignore">-        &nbs= p; Security Policies facing security functions (I2= NSF Capability Layer)

-       &n= bsp;  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 functio= ns or devices. Instead, I2NSF is only to standardize the policy provisioning to the security funct= ions (not devices), in the form of “Subject – Object – Fun= ction – Action” paradigm. 

&= nbsp;

The I2NSF Service Layer is for cl= ients to express and monitor security policies for their specific flows, whi= ch is usually based on customers’ logical networks, addresses and cont= ext. I2NSF Service Layer can also be security expectation or loose security requirement, especially for customers who don’t ha= ve the security expertise.

 

The concrete work at the L2NSF Capability Layer = includes

-     &= nbsp;    The informational & data models for = each category to be represented to virtual or physical network security func= tions,

= -=           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 ca= pability registry is to make it feasible to categorize network security func= tions provided by different vendors based on security policy provisioning ca= pability without any need to standardize security functions themselves. &nbs= p;Standard provisioning capability interface is an essential building block for Secur= ity Service Provider to automate their Security Controllers that can utilize= NSF by multiple vendors. This layer will leverage the existing protocols an= d data models defined by I2RS, Netconf, and NETMOD.

 <= /p>

For the I2NSF Service Layer, it is out of the scope = for I2NSF (at least for now) to standardize the interface facing clients. Ho= wever, I2NSF can have informational drafts showing sample APIs or/and RESTfu= l 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 fl= ow 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, Authorizat= ion, or Encryption). Exemplar services associated with Flow Based Security f= unctions include deep packet inspection, packet/flow/stream filtering or pat= tern matching and remediation, etc.

 

Similar to I2RS focusing on the interface to RIB/FIB even though mo= st routers provide far more functions than RIB/FIB, the I2NSF focused functi= ons can be a portion of features supported by vendors’ specific device= s.

 

It is a non-goal to create new protocols or data modeling languages for = I2NSF interfaces.

I2NSF WG Deliverables include:

 

-     &n= bsp;     Use Case document.

-  = ;        Framework Document.

-   = ;       Requirement for extensions (if there are any) t= o existing protocols used by the WG.

-           Gap analysis of existing protocols and mo= deling languages

A single, unified, Information Model for expres= sing policies to the Flow Based Security Functions described above.

-= -    &n= bsp;     IANA registry consideration for flow based secu= rity function policy provisioning capability.

-   &n= bsp;       (Optionally) Applicability Statements on = how to use I2RS, Netconf, and NETMOD to carry the content of the specified i= nformation/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 month= s to WG Document

  - Requirements fo= r extensions to protocols:  Charter time + 6 months to WG document=

  - Info model: Charter time + 7 months = to WG Document

  - IANA registry con= sideration + 10 months to WG Document

&nb= sp; - All Early Drafts to IESG: 10 months

 

[decision point – +10 month= s] 

  - Data Models: Char= ter + 9 Months to WG Document

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

_______________________________________________ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org/= mailman/listinfo/i2nsf --B_3514362909_21843223-- From nobody Wed May 13 01:57:45 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8A111A92F5 for ; Wed, 13 May 2015 01:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.26 X-Spam-Level: X-Spam-Status: No, score=-98.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bP6jajhzI3_z for ; Wed, 13 May 2015 01:57:40 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB5031A92F2 for ; Wed, 13 May 2015 01:57:39 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BSL46964; Wed, 13 May 2015 08:57:38 +0000 (GMT) Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 13 May 2015 09:57:37 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.244]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Wed, 13 May 2015 16:57:26 +0800 From: Zongning To: Linda Dunbar , "i2nsf@ietf.org" , Kathleen Moriarty Thread-Topic: [Dots] Further Narrowing the I2NSF scope: the new charter for IETF 93 Thread-Index: AdCI3eREQdBVQ8yORRe/7nCVEnyK2QEfA2nA Date: Wed, 13 May 2015 08:57:25 +0000 Message-ID: References: <4A95BA014132FF49AE685FAB4B9F17F657C11DC6@dfweml701-chm> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657C11DC6@dfweml701-chm> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.181] Content-Type: multipart/alternative; boundary="_000_B0D29E0424F2DE47A0B36779EC6667796629951Ankgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [I2nsf] =?gb2312?b?tPC4tDogW0RvdHNdIEZ1cnRoZXIgTmFycm93aW5nIHRo?= =?gb2312?b?ZSBJMk5TRiBzY29wZTogdGhlIG5ldyBjaGFydGVyIGZvciBJRVRGCTkz?= X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 08:57:44 -0000 --_000_B0D29E0424F2DE47A0B36779EC6667796629951Ankgeml501mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksIExpbmRhLA0KDQpJIHN1cHBvcnQgdGhlIGN1cnJlbnQgY2hhcnRlciBpbiBnZW5lcmFsLg0K T25lIHF1aWNrIGNvbW1lbnQgLSBpdCBzZWVtcyB0aGF0IHlvdSBoYXZlIGEgd2hvbGUgYXJjaGl0 ZWN0dXJlIGluIHlvdXIgbWluZCAoc28geW91IGhhdmUgbGF5ZXIgZGVmaW5pdGlvbnMsIGNvbXBv bmVudHMgbGlrZSBDb250cm9sbGVyLCBOU0ZzLCBldGMpLCBpdCB3b3VsZCBiZSBnb29kIHRoYXQg c3VjaCBhcmNoaXRlY3R1cmUgaXMgYnJpZWZseSBkZXNjcmliZWQgaW4gdGhlIGJlZ2lubmluZyBv ZiB0aGUgY2hhcnRlci4gVGhpcyBpcyBtYWlubHkgdG8gaGVscCBwZW9wbGUgdG8gdW5kZXJzdGFu ZCB5b3VyIHNjb3BlLg0KDQpUaGFua3MuDQoNCi1OaW5nDQoNCreivP7IyzogRG90cyBbbWFpbHRv OmRvdHMtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBMaW5kYSBEdW5iYXINCreiy83KsbzkOiAyMDE1 xOo11MI3yNUgMjM6NTMNCsrVvP7IyzogaTJuc2ZAaWV0Zi5vcmc7IEthdGhsZWVuIE1vcmlhcnR5 DQqzrcvNOiBpMnJzQGlldGYub3JnOyBkb3RzQGlldGYub3JnOyBuZXRtb2RAaWV0Zi5vcmcNCtb3 zOI6IFtEb3RzXSBGdXJ0aGVyIE5hcnJvd2luZyB0aGUgSTJOU0Ygc2NvcGU6IHRoZSBuZXcgY2hh cnRlciBmb3IgSUVURiA5Mw0KDQpUaGFua3MgdG8gSTJOU0YgY29udHJpYnV0b3JzIGZvciB0aGUg Z29vZCBwcm9ncmVzc2VzIG1hZGUgc2luY2UgIElFVEY5MiBzaWRlIG1lZXRpbmdzLiBBbW9uZyB0 aGUgdHdvIEkyTlNGIGludGVyZmFjZXMsICBpLmUuIHRoZSBjbGllbnQgZmFjaW5nIFNlcnZpY2Ug SW50ZXJmYWNlIGFuZCB0aGUgTlNGIGZhY2luZyBDYXBhYmlsaXR5IEludGVyZmFjZSwgdGhlIHdv cmsgdG8gYmUgZG9uZSBhdCB0aGUgQ2FwYWJpbGl0eSBJbnRlcmZhY2UgYmVjb21lcyB2ZXJ5IGNs ZWFyIGFuZCBjb25jcmV0ZS4gQnV0IHRoZSBTZXJ2aWNlIEludGVyZmFjZSBpcyBzdGlsbCBhIGxp dHRsZSB2YWd1ZS4NCg0KVGhlIGZlZWRiYWNrIGZyb20gbGFzdCBJRVRGIHNpZGUgbWVldGluZ3Mg d2FzICJ0aGUgc2NvcGUgaXMgdG9vIGJpZyBmb3Igb25lIElFVEYgV0ciLiBUaGVyZWZvcmUsIHdl IGFyZSBsZWFuaW5nIHRvd2FyZHMgbmFycm93aW5nIHRoZSBJMk5TRiBzY29wZSB0byB0aGUgQ2Fw YWJpbGl0eSBJbnRlcmZhY2UuIFRoZSB0aGlua2luZyBsb2dpYyBpczogT25jZSB0aGUgQ2FwYWJp bGl0eSBJbnRlcmZhY2UgaXMgY29tcGxldGVkLCB3ZSB3aWxsIHNlZSBtb3JlIGNsZWFybHkgdGhl IHdvcmsgZm9yIFNlcnZpY2UgaW50ZXJmYWNlLiBFdmVuIGlmIENhcGFiaWxpdHkgbGF5ZXIgYWxv bmUgaXMgc3RhbmRhcmRpemVkLCBpdCBpcyBhIGdpYW50IGxlYXAgZm9yd2FyZCBpbiBidWlsZGlu ZyBibG9ja3MgZm9yIFNlcnZpY2UgUHJvdmlkZXIgdG8gYXV0b21hdGUgdGhlaXIgU2VjdXJpdHkg Q29udHJvbGxlciB0aGF0IGNhbiB1dGlsaXplIE5TRiBieSBtdWx0aXBsZSB2ZW5kb3JzDQoNCkhl cmUgaXMgdGhlIG5hcnJvd2VyIHNjb3BlZCBJMk5TRiBjaGFydGVyLiBZb3VyIGNvbW1lbnRzIGFu ZCBzdWdnZXN0aW9ucyBhcmUgZ3JlYXRseSBhcHByZWNpYXRlZC4gQ0Ohr2VkIHRvIERPVFMsIEky UlMsIGFuZCBOZXRtb2QgZ3JvdXBzIGZvciB3aWRlciByZXZpZXcuDQoNCg0KDQpFbnRlcnByaXNl cywgcmVzaWRlbnRpYWwsIGFuZCBtb2JpbGUgY3VzdG9tZXJzIGFyZSBpbmNyZWFzaW5nbHkgY29u c3VtaW5nIG5ldHdvcmsgZnVuY3Rpb25zLCBlc3BlY2lhbGx5IG5ldHdvcmsgc2VjdXJpdHkgcmVs YXRlZCBmdW5jdGlvbnMgdGhhdCBhcmUgbm90IHJ1bm5pbmcgb24gdGhlaXIgcHJlbWlzZXMuICBJ biBhZGRpdGlvbiwgdGhlIEV1cm9wZWFuIFRlbGVjb21tdW5pY2F0aW9ucyBTdGFuZGFyZHMgSW5z dGl0dXRlIChFVFNJKSBOZXR3b3JrIEZ1bmN0aW9uIFZpcnR1YWxpemF0aW9uIChORlYpIGluaXRp YXRpdmUgY3JlYXRlcyBuZXcgbWFuYWdlbWVudCBjaGFsbGVuZ2VzIGZvciBzZWN1cml0eSBwb2xp Y2llcyB0byBiZSBlbmZvcmNlZCBieSBkaXN0cmlidXRlZCwgdmlydHVhbCwgbmV0d29yayBzZWN1 cml0eSBmdW5jdGlvbnMgKHZOU0YpLiBXaXRob3V0IHN0YW5kYXJkIGludGVyZmFjZSB0byBleHBy ZXNzLCBtb25pdG9yLCBhbmQgbWFuYWdlIHNlY3VyaXR5IHBvbGljaWVzIHRvIHNlY3VyaXR5IGZ1 bmN0aW9ucyBkZXBsb3llZCBhdCBkaWZmZXJlbnQgcHJlbWlzZXMsIGl0IGJlY29tZXMgdmlydHVh bGx5IGltcG9zc2libGUgZm9yIHNlY3VyaXR5IHNlcnZpY2UgcHJvdmlkZXJzIHRvIGF1dG9tYXRl IHRoZSBzZXJ2aWNlIG9mZmVyaW5nIHV0aWxpemluZyBzZWN1cml0eSBmdW5jdGlvbnMgYnkgbXVs dGlwbGUgdmVuZG9ycy4NCg0KVGhlIHVsdGltYXRlIGdvYWwgb2YgSTJOU0YgaXMgdG8gZW5hYmxl IGVudGVycHJpc2VzIHRvIHV0aWxpemUgc2VjdXJpdHkgZnVuY3Rpb25zIG5vdCBob3N0ZWQgb24g dGhlaXIgb3duIHByZW1pc2VzIGJ1dCBpbnN0ZWFkIGhvc3RlZCBpbiBzZXJ2aWNlIHByb3ZpZGVy IGRvbWFpbiwgdG8gZXN0YWJsaXNoIGhvdyB0byBjb21tdW5pY2F0ZSBkZXNpcmVkIHNlY3VyaXR5 IHBvbGljaWVzIHRvIE5TRiBhbmQgaG93IHRvIGdldCBwZXJmb3JtYW5jZSBkYXRhIG9yIHJlcG9y dCBvdXQgb2YgTlNGIG9yIHZOU0YuDQoNClRoZXJlIGFyZSB0d28gbGF5ZXJzIG9mIGludGVyZmFj ZXM6DQoNCi0gICAgICAgICAgU2VjdXJpdHkgUG9saWNpZXMgZmFjaW5nIHNlY3VyaXR5IGZ1bmN0 aW9ucyAoSTJOU0YgQ2FwYWJpbGl0eSBMYXllcikNCg0KLSAgICAgICAgICBTZWN1cml0eSBQb2xp Y2llcyBmYWNpbmcgY2xpZW50cyAoSTJOU0YgU2VydmljZSBMYXllcikNCg0KVGhlIEkyTlNGIENh cGFiaWxpdHkgTGF5ZXIgc3BlY2lmaWVzIHRoZSBmdW5jdGlvbmFsIHNlY3VyaXR5IHBvbGljaWVz LCB3aGljaCBhcmUgdHJhbnNsYXRlZCBmcm9tIHRoZSBjbGllbnQgc2VjdXJpdHkgcG9saWNpZXMs IHRvIHNlY3VyaXR5IGZ1bmN0aW9ucy4gSTJOU0Ygd2lsbCBOT1Qgc3RhbmRhcmRpemUgc2VjdXJp dHkgZnVuY3Rpb25zIG9yIGRldmljZXMuIEluc3RlYWQsIEkyTlNGIGlzIG9ubHkgdG8gc3RhbmRh cmRpemUgdGhlIHBvbGljeSBwcm92aXNpb25pbmcgdG8gdGhlIHNlY3VyaXR5IGZ1bmN0aW9ucyAo bm90IGRldmljZXMpLCBpbiB0aGUgZm9ybSBvZiChsFN1YmplY3QgqEMgT2JqZWN0IKhDIEZ1bmN0 aW9uIKhDIEFjdGlvbqGxIHBhcmFkaWdtLg0KDQpUaGUgSTJOU0YgU2VydmljZSBMYXllciBpcyBm b3IgY2xpZW50cyB0byBleHByZXNzIGFuZCBtb25pdG9yIHNlY3VyaXR5IHBvbGljaWVzIGZvciB0 aGVpciBzcGVjaWZpYyBmbG93cywgd2hpY2ggaXMgdXN1YWxseSBiYXNlZCBvbiBjdXN0b21lcnOh ryBsb2dpY2FsIG5ldHdvcmtzLCBhZGRyZXNzZXMgYW5kIGNvbnRleHQuIEkyTlNGIFNlcnZpY2Ug TGF5ZXIgY2FuIGFsc28gYmUgc2VjdXJpdHkgZXhwZWN0YXRpb24gb3IgbG9vc2Ugc2VjdXJpdHkg cmVxdWlyZW1lbnQsIGVzcGVjaWFsbHkgZm9yIGN1c3RvbWVycyB3aG8gZG9uoa90IGhhdmUgdGhl IHNlY3VyaXR5IGV4cGVydGlzZS4NCg0KVGhlIGNvbmNyZXRlIHdvcmsgYXQgdGhlIEwyTlNGIENh cGFiaWxpdHkgTGF5ZXIgaW5jbHVkZXMNCg0KLSAgICAgICAgICBUaGUgaW5mb3JtYXRpb25hbCAm IGRhdGEgbW9kZWxzIGZvciBlYWNoIGNhdGVnb3J5IHRvIGJlIHJlcHJlc2VudGVkIHRvIHZpcnR1 YWwgb3IgcGh5c2ljYWwgbmV0d29yayBzZWN1cml0eSBmdW5jdGlvbnMsDQoNCi0gICAgICAgICAg VGhlIGNhcGFiaWxpdHkgcmVnaXN0cnkgKElBTkEpIG9mIHBvbGljeSBwcm92aXNpb25pbmcgY2Fw YWJpbGl0eSB0byBmbG93IGJhc2VkIHNlY3VyaXR5IGZ1bmN0aW9uLCBhbmQNCg0KLSAgICAgICAg ICBUaGUgcHJvcGVyIHNlY3VyZSBjb21tdW5pY2F0aW9uIGNoYW5uZWxzIHRvIGNhcnJ5IHRoZSBz ZWN1cml0eSBwb2xpY2llcyBiZXR3ZWVuIENvbnRyb2xsZXIgYW5kIE5TRnMuDQpUaGUgY2FwYWJp bGl0eSByZWdpc3RyeSBpcyB0byBtYWtlIGl0IGZlYXNpYmxlIHRvIGNhdGVnb3JpemUgbmV0d29y ayBzZWN1cml0eSBmdW5jdGlvbnMgcHJvdmlkZWQgYnkgZGlmZmVyZW50IHZlbmRvcnMgYmFzZWQg b24gc2VjdXJpdHkgcG9saWN5IHByb3Zpc2lvbmluZyBjYXBhYmlsaXR5IHdpdGhvdXQgYW55IG5l ZWQgdG8gc3RhbmRhcmRpemUgc2VjdXJpdHkgZnVuY3Rpb25zIHRoZW1zZWx2ZXMuICBTdGFuZGFy ZCBwcm92aXNpb25pbmcgY2FwYWJpbGl0eSBpbnRlcmZhY2UgaXMgYW4gZXNzZW50aWFsIGJ1aWxk aW5nIGJsb2NrIGZvciBTZWN1cml0eSBTZXJ2aWNlIFByb3ZpZGVyIHRvIGF1dG9tYXRlIHRoZWly IFNlY3VyaXR5IENvbnRyb2xsZXJzIHRoYXQgY2FuIHV0aWxpemUgTlNGIGJ5IG11bHRpcGxlIHZl bmRvcnMuIFRoaXMgbGF5ZXIgd2lsbCBsZXZlcmFnZSB0aGUgZXhpc3RpbmcgcHJvdG9jb2xzIGFu ZCBkYXRhIG1vZGVscyBkZWZpbmVkIGJ5IEkyUlMsIE5ldGNvbmYsIGFuZCBORVRNT0QuDQoNCkZv ciB0aGUgSTJOU0YgU2VydmljZSBMYXllciwgaXQgaXMgb3V0IG9mIHRoZSBzY29wZSBmb3IgSTJO U0YgKGF0IGxlYXN0IGZvciBub3cpIHRvIHN0YW5kYXJkaXplIHRoZSBpbnRlcmZhY2UgZmFjaW5n IGNsaWVudHMuIEhvd2V2ZXIsIEkyTlNGIGNhbiBoYXZlIGluZm9ybWF0aW9uYWwgZHJhZnRzIHNo b3dpbmcgc2FtcGxlIEFQSXMgb3IvYW5kIFJFU1RmdWwgaW50ZXJmYWNlcyB0byBjbGllbnRzIGFu ZCBkZW1vbnN0cmF0aW5nIHRoZSBmZWFzaWJpbGl0eSBvZiB0aGVtIGJlaW5nIHRyYW5zbGF0ZWQg dG8gdGhlIENhcGFiaWxpdHkgTGF5ZXIgcG9saWNpZXMuDQoNClNpbmNlIGRpZmZlcmVudCBzZWN1 cml0eSB2ZW5kb3JzIHN1cHBvcnQgZGlmZmVyZW50IGZlYXR1cmVzICYgZnVuY3Rpb25zIG9uIHRo ZWlyIGRldmljZXMsIEkyTlNGIHdpbGwgZm9jdXMgb24gZmxvdyBiYXNlZCBzZWN1cml0eSBmdW5j dGlvbnMgdGhhdCBwcm92aWRlIHRyZWF0bWVudCB0byBwYWNrZXRzL2Zsb3dzLCBzdWNoIGFzIElQ Uy9JRFMsIFdlYiBmaWx0ZXIsIGFuZCBmbG93IGZpbHRlci4gKFRoZXkgYXJlIGRpZmZlcmVudCBm cm9tIG90aGVyIHNlY3VyaXR5IGZ1bmN0aW9ucyBzdWNoIGFzIEF1dGhlbnRpY2F0aW9uLCBBdXRo b3JpemF0aW9uLCBvciBFbmNyeXB0aW9uKS4gRXhlbXBsYXIgc2VydmljZXMgYXNzb2NpYXRlZCB3 aXRoIEZsb3cgQmFzZWQgU2VjdXJpdHkgZnVuY3Rpb25zIGluY2x1ZGUgZGVlcCBwYWNrZXQgaW5z cGVjdGlvbiwgcGFja2V0L2Zsb3cvc3RyZWFtIGZpbHRlcmluZyBvciBwYXR0ZXJuIG1hdGNoaW5n IGFuZCByZW1lZGlhdGlvbiwgZXRjLg0KDQpTaW1pbGFyIHRvIEkyUlMgZm9jdXNpbmcgb24gdGhl IGludGVyZmFjZSB0byBSSUIvRklCIGV2ZW4gdGhvdWdoIG1vc3Qgcm91dGVycyBwcm92aWRlIGZh ciBtb3JlIGZ1bmN0aW9ucyB0aGFuIFJJQi9GSUIsIHRoZSBJMk5TRiBmb2N1c2VkIGZ1bmN0aW9u cyBjYW4gYmUgYSBwb3J0aW9uIG9mIGZlYXR1cmVzIHN1cHBvcnRlZCBieSB2ZW5kb3Jzoa8gc3Bl Y2lmaWMgZGV2aWNlcy4NCg0KSXQgaXMgYSBub24tZ29hbCB0byBjcmVhdGUgbmV3IHByb3RvY29s cyBvciBkYXRhIG1vZGVsaW5nIGxhbmd1YWdlcyBmb3IgSTJOU0YgaW50ZXJmYWNlcy4NCkkyTlNG IFdHIERlbGl2ZXJhYmxlcyBpbmNsdWRlOg0KDQoNCi0gICAgICAgICAgIFVzZSBDYXNlIGRvY3Vt ZW50Lg0KDQotICAgICAgICAgIEZyYW1ld29yayBEb2N1bWVudC4NCg0KLSAgICAgICAgICBSZXF1 aXJlbWVudCBmb3IgZXh0ZW5zaW9ucyAoaWYgdGhlcmUgYXJlIGFueSkgdG8gZXhpc3RpbmcgcHJv dG9jb2xzIHVzZWQgYnkgdGhlIFdHLg0KDQotICAgICAgICAgICBHYXAgYW5hbHlzaXMgb2YgZXhp c3RpbmcgcHJvdG9jb2xzIGFuZCBtb2RlbGluZyBsYW5ndWFnZXMNCg0KLSAgICAgICAgICBBIHNp bmdsZSwgdW5pZmllZCwgSW5mb3JtYXRpb24gTW9kZWwgZm9yIGV4cHJlc3NpbmcgcG9saWNpZXMg dG8gdGhlIEZsb3cgQmFzZWQgU2VjdXJpdHkgRnVuY3Rpb25zIGRlc2NyaWJlZCBhYm92ZS4NCg0K LSAgICAgICAgICBDb3JyZXNwb25kaW5nIERhdGEgTW9kZWxzIChlLmcuIFlBTkcgbW9kZWxzKSBk ZXJpdmVkIGZyb20gdGhlIGFib3ZlIEluZm9ybWF0aW9uIE1vZGVsLg0KDQotICAgICAgICAgIElB TkEgcmVnaXN0cnkgY29uc2lkZXJhdGlvbiBmb3IgZmxvdyBiYXNlZCBzZWN1cml0eSBmdW5jdGlv biBwb2xpY3kgcHJvdmlzaW9uaW5nIGNhcGFiaWxpdHkuDQoNCi0gICAgICAgICAgIChPcHRpb25h bGx5KSBBcHBsaWNhYmlsaXR5IFN0YXRlbWVudHMgb24gaG93IHRvIHVzZSBJMlJTLCBOZXRjb25m LCBhbmQgTkVUTU9EIHRvIGNhcnJ5IHRoZSBjb250ZW50IG9mIHRoZSBzcGVjaWZpZWQgaW5mb3Jt YXRpb24vZGF0YSBtb2RlbHMuDQoNCltUaGUgV0cgbWF5IGRlY2lkZSB0aGF0IHRoZSBVc2UgY2Fz ZXMsIEZyYW1ld29yaywgYW5kIFJlcXVpcmVtZW50IGFyZSBJbmZvcm1hdGlvbmFsIGRvY3VtZW50 cyBvciBzaW1wbHkgcmVmZXJlbmNlIGRvY3VtZW50cyBkdXJpbmcgdGhlIGxpZmV0aW1lIG9mIHRo ZSBXRy4gVGhlIGZyYW1ld29yaywgdGhhdCBkZXNjcmliZXMgdGhlIGZ1bmN0aW9uYWwgY29tcG9u ZW50cyBhbmQgdGhlIEkyTlNGIHdvcmsgaXRlbXMsIGlzIHRvIG1ha2UgSTJOU0Ygd29yayBtb3Jl IG9yZ2FuaXplZC5dDQoNClN1Z2dlc3RlZCBNaWxlc3RvbmVzDQogIC0gVXNlIENhc2UgRG9jdW1l bnQ6ICBDaGFydGVyIHRpbWUgKyAxIG1vbnRoIHRvIFdHIERvY3VtZW50DQogIC0gRnJhbWV3b3Jr OiBDaGFydGVyIHRpbWUgKyA0IG1vbnRocyB0byBXRyBEb2N1bWVudA0KICAtIFJlcXVpcmVtZW50 cyBmb3IgZXh0ZW5zaW9ucyB0byBwcm90b2NvbHM6ICBDaGFydGVyIHRpbWUgKyA2IG1vbnRocyB0 byBXRyBkb2N1bWVudA0KICAtIEluZm8gbW9kZWw6IENoYXJ0ZXIgdGltZSArIDcgbW9udGhzIHRv IFdHIERvY3VtZW50DQogIC0gSUFOQSByZWdpc3RyeSBjb25zaWRlcmF0aW9uICsgMTAgbW9udGhz IHRvIFdHIERvY3VtZW50DQogIC0gQWxsIEVhcmx5IERyYWZ0cyB0byBJRVNHOiAxMCBtb250aHMN Cg0KW2RlY2lzaW9uIHBvaW50IKhDICsxMCBtb250aHNdDQogIC0gRGF0YSBNb2RlbHM6IENoYXJ0 ZXIgKyA5IE1vbnRocyB0byBXRyBEb2N1bWVudA0KICAtIEFwcGxpY2FiaWxpdHkgU3RhdGVtZW50 czogMTAgbW9udGhzIHRvIFdHIERvY3VtZW50DQogIC0gRGF0YSBNb2RlbHMgYW5kIEFwcGxpY2Fi aWxpdHkgU3RhdGVtZW50cyB0byBJRVNHICAtIDE2IG1vbnRocw0KDQpUaGUgV0cgd2lsbCB3b3Jr IGNsb3NlbHkgd2l0aCBJMlJTLCBOZXRjb25mIGFuZCBOZXRtb2QgV0dzLiBUaGUgV0cgd2lsbCBj b21tdW5pY2F0ZSB3aXRoIGV4dGVybmFsIFNET3MgbGlrZSBFVFNJIE5GViBhbmQgd2lsbCBlbmNv dXJhZ2Ugb3BlbiBzb3VyY2UgY29kZSBkZXZlbG9wbWVudCByZWxhdGVkIHRvIHRoZSBXRyBzY29w ZSBpbiBvcmdhbml6YXRpb25zIGxpa2UgT05GLCBPcGVuU3RhY2ssIE9ETCwgYW5kIE9wZW5ORlYu DQoNCg0KQ2hlZXJzLA0KTGluZGEgRHVuYmFyDQo= --_000_B0D29E0424F2DE47A0B36779EC6667796629951Ankgeml501mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi, Linda,

 

I support the current charter in general.

One quick comment - it seems that you have a whole architecture i= n your mind (so you have layer definitions, components like Controller, NSF= s, etc), it would be good that such architecture is briefly described in the beginning of the charter. This is mainly to he= lp people to understand your scope.

 

Thanks.

 

-Ning

 

=B7=A2=BC=FE=C8=CB: Dots [m= ailto:dots-bounces@ietf.org] =B4=FA= =B1=ED Linda Dunbar
=B7=A2= =CB=CD=CA=B1=BC=E4: 2015=C4=EA5=D4=C27=C8=D5 23:53
=CA=D5=BC=FE=C8=CB: i2nsf@ietf.org; Kathleen Moriarty
=B3=AD=CB=CD: i2rs@ietf.org; dots@ietf.org; netmod@ietf.org
=D6=F7=CC=E2: [Dots] Further Narrowing the I2NSF scope: the new charter for IETF 93

 

Thanks to I2NSF contributors fo= r the good progresses made since  IETF92 side meetings. Among the two = I2NSF interfaces,  i.e. the client facing Service Interface and the NS= F 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 sid= e meetings was "the scope is too big for one IETF WG". Therefore,= we are leaning towards narrowing the I2NSF scope to the Capability Interfa= ce. The thinking logic is: Once the Capability Interface is completed, we will see more clearly the work for Service inte= rface. Even if Capability layer alone is standardized, it is a giant leap f= orward in building blocks for Service Provider to automate their Security C= ontroller that can utilize NSF by multiple vendors

 

Here is the narrower scoped I2N= SF charter. Your comments and suggestions are greatly appreciated. CC=A1=AF= ed to DOTS, I2RS, and Netmod groups for wider review.

 

 

 

Enterprises, residential, and m= obile customers are increasingly consuming network functions, especially ne= twork security related functions that are not running on their premises.&nb= sp; In addition, the European Telecommunications Standards Institute (ETSI) Network Function Virtualization (NFV) initiativ= e 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 premi= ses, it becomes virtually impossible for security service providers to auto= mate the service offering utilizing security functions by multiple vendors.

 

The ultimate goal of I2NSF is t= o 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.<= /o:p>

 

There are two layers of interfa= ces:

-=    &n= bsp;      Security Policies facin= g security functions (I2NSF Capability Layer)

-=    &n= bsp;      Security Policies facin= g clients (I2NSF Service Layer)

 

The I2NSF= Capability Layer specifies the functional security policies, which are tra= nslated from the client security policies, to security functions. I2NSF wil= l 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 =A1=B0Subject =A8C Obj= ect =A8C Function =A8C Action=A1=B1 paradigm. 

&nbs= p;

The I2NSF Service Layer is for = clients to express and monitor security policies for their specific flows, = which is usually based on customers=A1=AF logical networks, addresses and c= ontext. I2NSF Service Layer can also be security expectation or loose security requirement, especially for customers who do= n=A1=AFt 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 net= work security functions,

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

-The proper secure commu= nication channels to carry the security policies between Controller and NSF= s.

The capability registry is to m= ake it feasible to categorize network security functions provided by differ= ent vendors based on security policy provisioning capability without any ne= ed to standardize security functions themselves.  Standard provisioning capability interface is an essenti= al building block for Security Service Provider to automate their Security = Controllers that can utilize NSF by multiple vendors. This layer will lever= age 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 interf= ace facing clients. However, I2NSF can have informational drafts showing sa= mple APIs or/and RESTful interfaces to clients and demonstrating the feasibility of them being translated to t= he Capability Layer policies.

&nbs= p;

Since different security vendor= s support different features & functions on their devices, I2NSF will f= ocus on flow based security functions that provide treatment to packets/flo= ws, such as IPS/IDS, Web filter, and flow filter. (They are different from other security functions such as Authenti= cation, Authorization, or Encryption). Exemplar services associated with Fl= ow Based Security functions include deep packet inspection, packet/flow/str= eam 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 t= han RIB/FIB, the I2NSF focused functions can be a portion of features suppo= rted by vendors=A1=AF specific devices.

 

It is a non-goal to create new = protocols or data modeling languages for I2NSF interfaces.

I2NSF WG Deliverables include:<= o:p>

 

-=    &n= bsp;       Use Case document= .

-=    &n= bsp;      Framework Document.

-=    &n= bsp;      Requirement for extensi= ons (if there are any) to existing protocols used by the WG.

-=    &n= bsp;       Gap analysis of e= xisting protocols and modeling languages

-=    &n= bsp;      A single, unified, Info= rmation Model for expressing policies to the Flow Based Security Functions = described above.

-=    &n= bsp;      Corresponding Data Mode= ls (e.g. YANG models) derived from the above Information Model.<= /span>

-=    &n= bsp;      IANA registry considera= tion for flow based security function policy provisioning capability.<= /o:p>

-=    &n= bsp;       (Optionally) Appl= icability Statements on how to use I2RS, Netconf, and NETMOD to carry the c= ontent of the specified information/data models.

 

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

 

Suggested Milestones=

  - Use Case Document:&nbs= p; Charter time + 1 month to WG Document

  - Framework: Charter tim= e + 4 months to WG Document

  - Requirements for exten= sions to protocols:  Charter time + 6 months to WG document

  - Info model: Charter ti= me + 7 months to WG Document

  - IANA registry consider= ation + 10 months to WG Document

  - All Early Drafts to IE= SG: 10 months

 

[decision point =A8C +10 mo= nths] 

  - Data Models: Char= ter + 9 Months to WG Document

  - Applicability Statemen= ts: 10 months to WG Document

  - Data Models and Applic= ability Statements to IESG  - 16 months

 

The WG will work closely with I= 2RS, Netconf and Netmod WGs. The WG will communicate with external SDOs lik= e ETSI NFV and will encourage open source code development related to the W= G scope in organizations like ONF, OpenStack, ODL, and OpenNFV.

 

 

Cheers,

Linda Dunbar<= /p>

--_000_B0D29E0424F2DE47A0B36779EC6667796629951Ankgeml501mbschi_-- From nobody Wed May 13 09:26:44 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C53EC1A8A84; Wed, 13 May 2015 09:26:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rKUS6xKe1b2K; Wed, 13 May 2015 09:26:34 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 073211A88FF; Wed, 13 May 2015 09:26:32 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BSM49135; Wed, 13 May 2015 16:26:31 +0000 (GMT) Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 13 May 2015 17:26:31 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml702-chm ([10.193.5.72]) with mapi id 14.03.0158.001; Wed, 13 May 2015 09:26:21 -0700 From: Linda Dunbar To: Dacheng Zhang , "i2nsf@ietf.org" , "sacm@ietf.org" Thread-Topic: secure communication channel to exchange security policy and monitor execution status for I2NSF (was RE: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93 Thread-Index: AQHQjTCk1xjNa7wv+UGGDcLStnhTlZ16Fx/w Date: Wed, 13 May 2015 16:26:21 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657C1443C@dfweml701-chm> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.128] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657C1443Cdfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "i2rs@ietf.org" , "dots@ietf.org" , "netmod@ietf.org" Subject: [I2nsf] secure communication channel to exchange security policy and monitor execution status for I2NSF (was RE: Further Narrowing the I2NSF scope: the new charter for IETF 93 X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 16:26:39 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F657C1443Cdfweml701chm_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGEgQ2hlbmcsDQoNCg0KWW91IHN0YXRlZCB0aGF0IHRoZSBidWxsZXQgZm9yIOKAnFRoZSBwcm9w ZXIgc2VjdXJlIGNvbW11bmljYXRpb24gY2hhbm5lbHMgdG8gY2FycnkgdGhlIHNlY3VyaXR5IHBv bGljaWVzIGJldHdlZW4gQ29udHJvbGxlciBhbmQgTlNGc+KAnSAgaXMgdHJpdmlhbC4gQnV0DQpT QUNNIGlzIGNvbnNpZGVyaW5nIHVzaW5nIFhNUFAgdG8gZXhjaGFuZ2UgZGF0YSBhbW9uZyBlbmQg ZGV2aWNlcyAoaW5zdGVhZCBvZiBORVRDT05GKTogc2VlICBodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1zYWxvd2V5LXNhY20teG1wcC1ncmlkLw0KDQoNClNvIHRoZXJlIG1p Z2h0IGJlIG1vcmUgdGhhbiBzaW1wbGUgTkVUQ09ORiwgbWF5IGJlIFRMUyAreHh4IGhhdmUgdG8g YmUgY29uc2lkZXJlZC4NCg0KTGluZGENCg0KRnJvbTogRGFjaGVuZyBaaGFuZyBbbWFpbHRvOmRh Y2hlbmcuemRjQGFsaWJhYmEtaW5jLmNvbV0NClNlbnQ6IFR1ZXNkYXksIE1heSAxMiwgMjAxNSAx MDo1NSBQTQ0KVG86IExpbmRhIER1bmJhcjsgaTJuc2ZAaWV0Zi5vcmc7IEthdGhsZWVuIE1vcmlh cnR5DQpDYzogaTJyc0BpZXRmLm9yZzsgZG90c0BpZXRmLm9yZzsgbmV0bW9kQGlldGYub3JnDQpT dWJqZWN0OiBSZTogW0kybnNmXSBGdXJ0aGVyIE5hcnJvd2luZyB0aGUgSTJOU0Ygc2NvcGU6IHRo ZSBuZXcgY2hhcnRlciBmb3IgSUVURiA5Mw0KDQpIae+8jExpbmRhOg0KDQpJIGxpa2UgdGhlIGN1 cnJlbnQgdmVyc2lvbiBvZiBjaGFydGVyLCB3aGljaCBjbGFyaWZpZXMgYSByZWFzb25hYmxlIHNj b3BlIG9mIHRoaXMgd29yay4gU29tZSB0aW55IGNvbW1lbnRzLg0KDQoNClRoZSBjb25jcmV0ZSB3 b3JrIGF0IHRoZSBMMk5TRiBDYXBhYmlsaXR5IExheWVyIGluY2x1ZGVzDQoNCi0gICAgICAgICAg VGhlIGluZm9ybWF0aW9uYWwgJiBkYXRhIG1vZGVscyBmb3IgZWFjaCBjYXRlZ29yeSB0byBiZSBy ZXByZXNlbnRlZCB0byB2aXJ0dWFsIG9yIHBoeXNpY2FsIG5ldHdvcmsgc2VjdXJpdHkgZnVuY3Rp b25zLA0KDQotICAgICAgICAgIFRoZSBjYXBhYmlsaXR5IHJlZ2lzdHJ5IChJQU5BKSBvZiBwb2xp Y3kgcHJvdmlzaW9uaW5nIGNhcGFiaWxpdHkgdG8gZmxvdyBiYXNlZCBzZWN1cml0eSBmdW5jdGlv biwgYW5kDQoNCi0gICAgICAgICAgVGhlIHByb3BlciBzZWN1cmUgY29tbXVuaWNhdGlvbiBjaGFu bmVscyB0byBjYXJyeSB0aGUgc2VjdXJpdHkgcG9saWNpZXMgYmV0d2VlbiBDb250cm9sbGVyIGFu ZCBOU0ZzLg0KDQoNCg0KPj5EYWNoZW5nOiB0aGUgdGhpcmQgYnVsbGV0IGlzIHF1aXRlIHRyaXZh bCBjb21wYXJlZCB3aXRoIHRoZSBmaXJzdCB0d28gYnVsbGV0cywgc2luY2Ugd2Ugd2lsbCB0cnkg dG8gcmUtdXNlIHRoZSB3b3JrIG9mIEkyUlMsTmV0Y29uZiB3aGVyZSB0aGUgZ2VuZXJhdGlvbiBv ZiBzZWN1cml0eSBjaGFubmVscyBoYXZlIGFscmVhZHkgY29uc2lkZXJlZC4gIFNvLCBtYXliZSB3 ZSBjb3VsZCByZW1vdmUgaXQuDQoNClRoZSBjYXBhYmlsaXR5IHJlZ2lzdHJ5IGlzIHRvIG1ha2Ug aXQgZmVhc2libGUgdG8gY2F0ZWdvcml6ZSBuZXR3b3JrIHNlY3VyaXR5IGZ1bmN0aW9ucyBwcm92 aWRlZCBieSBkaWZmZXJlbnQgdmVuZG9ycyBiYXNlZCBvbiBzZWN1cml0eSBwb2xpY3kgcHJvdmlz aW9uaW5nIGNhcGFiaWxpdHkgd2l0aG91dCBhbnkgbmVlZCB0byBzdGFuZGFyZGl6ZSBzZWN1cml0 eSBmdW5jdGlvbnMgdGhlbXNlbHZlcy4gIFN0YW5kYXJkIHByb3Zpc2lvbmluZyBjYXBhYmlsaXR5 IGludGVyZmFjZSBpcyBhbiBlc3NlbnRpYWwgYnVpbGRpbmcgYmxvY2sgZm9yIFNlY3VyaXR5IFNl cnZpY2UgUHJvdmlkZXIgdG8gYXV0b21hdGUgdGhlaXIgU2VjdXJpdHkgQ29udHJvbGxlcnMgdGhh dCBjYW4gdXRpbGl6ZSBOU0YgYnkgbXVsdGlwbGUgdmVuZG9ycy4gVGhpcyBsYXllciB3aWxsIGxl dmVyYWdlIHRoZSBleGlzdGluZyBwcm90b2NvbHMgYW5kIGRhdGEgbW9kZWxzIGRlZmluZWQgYnkg STJSUywgTmV0Y29uZiwgYW5kIE5FVE1PRC4NCg0KPj5EYWNoZW5nOiBJIHN1Z2dlc3QgdG8gY2hh bmdlIHRoZSBsYXN0IHNlbnRlbmNlIHRvIOKAnEluIHRoaXMgbGF5ZXIsIHdlIHdpbGwgbGV2ZXJh Z2UgdGhlIGV4aXN0aW5nIHByb3RvY29scyBhbmQgZGF0YSBtb2RlbHMgZGVmaW5lZCBieSBJMlJT LCBOZXRjb25mLCBhbmQgTkVUTU9EIGFzIG11Y2ggYXMgcG9zc2libGUu4oCdDQoNClNpbWlsYXIg dG8gSTJSUyBmb2N1c2luZyBvbiB0aGUgaW50ZXJmYWNlIHRvIFJJQi9GSUIgZXZlbiB0aG91Z2gg bW9zdCByb3V0ZXJzIHByb3ZpZGUgZmFyIG1vcmUgZnVuY3Rpb25zIHRoYW4gUklCL0ZJQiwgdGhl IEkyTlNGIGZvY3VzZWQgZnVuY3Rpb25zIGNhbiBiZSBhIHBvcnRpb24gb2YgZmVhdHVyZXMgc3Vw cG9ydGVkIGJ5IHZlbmRvcnPigJkgc3BlY2lmaWMgZGV2aWNlcy4NCg0KPj5EYWNoZW5nOiB0aGUg Zmlyc3QgcGFydCBvZiB0aGlzIHNlbnRlbmNlIGlzIHJlZHVuZGFudC4gV2UgZG9u4oCZdCBoYXZl IHRvIGltcGx5IHRoYXQg4oCcd2Ugd29yayBpbiB0aGlzIHdheSBiZWNhdXNlIEkyUlMgdXNlZCB0 byBkbyBzaW1pbGFyIHRoaW5ncy4gU28gaWYgeW91IHdhbnQgdG8gY2hhbGxlbmdlIHVzLCBwbGVh c2UgY2hhbGxlbmdlIEkyUlMgZmlyc3TigJ0uIE1heWJlIHdlIGNvdWxkIHJlbW92ZSBpdC4NCg0K 5Y+R5Lu25Lq6OiBMaW5kYSBEdW5iYXIgPGxpbmRhLmR1bmJhckBodWF3ZWkuY29tPG1haWx0bzps aW5kYS5kdW5iYXJAaHVhd2VpLmNvbT4+DQrml6XmnJ86IDIwMTXlubQ15pyIN+aXpSDmmJ/mnJ/l m5sg5LiL5Y2IMTE6NTMNCuiHszogImkybnNmQGlldGYub3JnPG1haWx0bzppMm5zZkBpZXRmLm9y Zz4iIDxpMm5zZkBpZXRmLm9yZzxtYWlsdG86aTJuc2ZAaWV0Zi5vcmc+PiwgS2F0aGxlZW4gTW9y aWFydHkgPGthdGhsZWVuLm1vcmlhcnR5LmlldGZAZ21haWwuY29tPG1haWx0bzprYXRobGVlbi5t b3JpYXJ0eS5pZXRmQGdtYWlsLmNvbT4+DQrmioTpgIE6ICJpMnJzQGlldGYub3JnPG1haWx0bzpp MnJzQGlldGYub3JnPiIgPGkycnNAaWV0Zi5vcmc8bWFpbHRvOmkycnNAaWV0Zi5vcmc+PiwgImRv dHNAaWV0Zi5vcmc8bWFpbHRvOmRvdHNAaWV0Zi5vcmc+IiA8ZG90c0BpZXRmLm9yZzxtYWlsdG86 ZG90c0BpZXRmLm9yZz4+LCAibmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+ IiA8bmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+Pg0K5Li76aKYOiBbSTJu c2ZdIEZ1cnRoZXIgTmFycm93aW5nIHRoZSBJMk5TRiBzY29wZTogdGhlIG5ldyBjaGFydGVyIGZv ciBJRVRGIDkzDQoNClRoYW5rcyB0byBJMk5TRiBjb250cmlidXRvcnMgZm9yIHRoZSBnb29kIHBy b2dyZXNzZXMgbWFkZSBzaW5jZSAgSUVURjkyIHNpZGUgbWVldGluZ3MuIEFtb25nIHRoZSB0d28g STJOU0YgaW50ZXJmYWNlcywgIGkuZS4gdGhlIGNsaWVudCBmYWNpbmcgU2VydmljZSBJbnRlcmZh Y2UgYW5kIHRoZSBOU0YgZmFjaW5nIENhcGFiaWxpdHkgSW50ZXJmYWNlLCB0aGUgd29yayB0byBi ZSBkb25lIGF0IHRoZSBDYXBhYmlsaXR5IEludGVyZmFjZSBiZWNvbWVzIHZlcnkgY2xlYXIgYW5k IGNvbmNyZXRlLiBCdXQgdGhlIFNlcnZpY2UgSW50ZXJmYWNlIGlzIHN0aWxsIGEgbGl0dGxlIHZh Z3VlLg0KDQpUaGUgZmVlZGJhY2sgZnJvbSBsYXN0IElFVEYgc2lkZSBtZWV0aW5ncyB3YXMgInRo ZSBzY29wZSBpcyB0b28gYmlnIGZvciBvbmUgSUVURiBXRyIuIFRoZXJlZm9yZSwgd2UgYXJlIGxl YW5pbmcgdG93YXJkcyBuYXJyb3dpbmcgdGhlIEkyTlNGIHNjb3BlIHRvIHRoZSBDYXBhYmlsaXR5 IEludGVyZmFjZS4gVGhlIHRoaW5raW5nIGxvZ2ljIGlzOiBPbmNlIHRoZSBDYXBhYmlsaXR5IElu dGVyZmFjZSBpcyBjb21wbGV0ZWQsIHdlIHdpbGwgc2VlIG1vcmUgY2xlYXJseSB0aGUgd29yayBm b3IgU2VydmljZSBpbnRlcmZhY2UuIEV2ZW4gaWYgQ2FwYWJpbGl0eSBsYXllciBhbG9uZSBpcyBz dGFuZGFyZGl6ZWQsIGl0IGlzIGEgZ2lhbnQgbGVhcCBmb3J3YXJkIGluIGJ1aWxkaW5nIGJsb2Nr cyBmb3IgU2VydmljZSBQcm92aWRlciB0byBhdXRvbWF0ZSB0aGVpciBTZWN1cml0eSBDb250cm9s bGVyIHRoYXQgY2FuIHV0aWxpemUgTlNGIGJ5IG11bHRpcGxlIHZlbmRvcnMNCg0KSGVyZSBpcyB0 aGUgbmFycm93ZXIgc2NvcGVkIEkyTlNGIGNoYXJ0ZXIuIFlvdXIgY29tbWVudHMgYW5kIHN1Z2dl c3Rpb25zIGFyZSBncmVhdGx5IGFwcHJlY2lhdGVkLiBDQ+KAmWVkIHRvIERPVFMsIEkyUlMsIGFu ZCBOZXRtb2QgZ3JvdXBzIGZvciB3aWRlciByZXZpZXcuDQoNCg0KDQpFbnRlcnByaXNlcywgcmVz aWRlbnRpYWwsIGFuZCBtb2JpbGUgY3VzdG9tZXJzIGFyZSBpbmNyZWFzaW5nbHkgY29uc3VtaW5n IG5ldHdvcmsgZnVuY3Rpb25zLCBlc3BlY2lhbGx5IG5ldHdvcmsgc2VjdXJpdHkgcmVsYXRlZCBm dW5jdGlvbnMgdGhhdCBhcmUgbm90IHJ1bm5pbmcgb24gdGhlaXIgcHJlbWlzZXMuICBJbiBhZGRp dGlvbiwgdGhlIEV1cm9wZWFuIFRlbGVjb21tdW5pY2F0aW9ucyBTdGFuZGFyZHMgSW5zdGl0dXRl IChFVFNJKSBOZXR3b3JrIEZ1bmN0aW9uIFZpcnR1YWxpemF0aW9uIChORlYpIGluaXRpYXRpdmUg Y3JlYXRlcyBuZXcgbWFuYWdlbWVudCBjaGFsbGVuZ2VzIGZvciBzZWN1cml0eSBwb2xpY2llcyB0 byBiZSBlbmZvcmNlZCBieSBkaXN0cmlidXRlZCwgdmlydHVhbCwgbmV0d29yayBzZWN1cml0eSBm dW5jdGlvbnMgKHZOU0YpLiBXaXRob3V0IHN0YW5kYXJkIGludGVyZmFjZSB0byBleHByZXNzLCBt b25pdG9yLCBhbmQgbWFuYWdlIHNlY3VyaXR5IHBvbGljaWVzIHRvIHNlY3VyaXR5IGZ1bmN0aW9u cyBkZXBsb3llZCBhdCBkaWZmZXJlbnQgcHJlbWlzZXMsIGl0IGJlY29tZXMgdmlydHVhbGx5IGlt cG9zc2libGUgZm9yIHNlY3VyaXR5IHNlcnZpY2UgcHJvdmlkZXJzIHRvIGF1dG9tYXRlIHRoZSBz ZXJ2aWNlIG9mZmVyaW5nIHV0aWxpemluZyBzZWN1cml0eSBmdW5jdGlvbnMgYnkgbXVsdGlwbGUg dmVuZG9ycy4NCg0KVGhlIHVsdGltYXRlIGdvYWwgb2YgSTJOU0YgaXMgdG8gZW5hYmxlIGVudGVy cHJpc2VzIHRvIHV0aWxpemUgc2VjdXJpdHkgZnVuY3Rpb25zIG5vdCBob3N0ZWQgb24gdGhlaXIg b3duIHByZW1pc2VzIGJ1dCBpbnN0ZWFkIGhvc3RlZCBpbiBzZXJ2aWNlIHByb3ZpZGVyIGRvbWFp biwgdG8gZXN0YWJsaXNoIGhvdyB0byBjb21tdW5pY2F0ZSBkZXNpcmVkIHNlY3VyaXR5IHBvbGlj aWVzIHRvIE5TRiBhbmQgaG93IHRvIGdldCBwZXJmb3JtYW5jZSBkYXRhIG9yIHJlcG9ydCBvdXQg b2YgTlNGIG9yIHZOU0YuDQoNClRoZXJlIGFyZSB0d28gbGF5ZXJzIG9mIGludGVyZmFjZXM6DQoN Ci0gICAgICAgICAgU2VjdXJpdHkgUG9saWNpZXMgZmFjaW5nIHNlY3VyaXR5IGZ1bmN0aW9ucyAo STJOU0YgQ2FwYWJpbGl0eSBMYXllcikNCg0KLSAgICAgICAgICBTZWN1cml0eSBQb2xpY2llcyBm YWNpbmcgY2xpZW50cyAoSTJOU0YgU2VydmljZSBMYXllcikNCg0KVGhlIEkyTlNGIENhcGFiaWxp dHkgTGF5ZXIgc3BlY2lmaWVzIHRoZSBmdW5jdGlvbmFsIHNlY3VyaXR5IHBvbGljaWVzLCB3aGlj aCBhcmUgdHJhbnNsYXRlZCBmcm9tIHRoZSBjbGllbnQgc2VjdXJpdHkgcG9saWNpZXMsIHRvIHNl Y3VyaXR5IGZ1bmN0aW9ucy4gSTJOU0Ygd2lsbCBOT1Qgc3RhbmRhcmRpemUgc2VjdXJpdHkgZnVu Y3Rpb25zIG9yIGRldmljZXMuIEluc3RlYWQsIEkyTlNGIGlzIG9ubHkgdG8gc3RhbmRhcmRpemUg dGhlIHBvbGljeSBwcm92aXNpb25pbmcgdG8gdGhlIHNlY3VyaXR5IGZ1bmN0aW9ucyAobm90IGRl dmljZXMpLCBpbiB0aGUgZm9ybSBvZiDigJxTdWJqZWN0IOKAkyBPYmplY3Qg4oCTIEZ1bmN0aW9u IOKAkyBBY3Rpb27igJ0gcGFyYWRpZ20uDQoNClRoZSBJMk5TRiBTZXJ2aWNlIExheWVyIGlzIGZv ciBjbGllbnRzIHRvIGV4cHJlc3MgYW5kIG1vbml0b3Igc2VjdXJpdHkgcG9saWNpZXMgZm9yIHRo ZWlyIHNwZWNpZmljIGZsb3dzLCB3aGljaCBpcyB1c3VhbGx5IGJhc2VkIG9uIGN1c3RvbWVyc+KA mSBsb2dpY2FsIG5ldHdvcmtzLCBhZGRyZXNzZXMgYW5kIGNvbnRleHQuIEkyTlNGIFNlcnZpY2Ug TGF5ZXIgY2FuIGFsc28gYmUgc2VjdXJpdHkgZXhwZWN0YXRpb24gb3IgbG9vc2Ugc2VjdXJpdHkg cmVxdWlyZW1lbnQsIGVzcGVjaWFsbHkgZm9yIGN1c3RvbWVycyB3aG8gZG9u4oCZdCBoYXZlIHRo ZSBzZWN1cml0eSBleHBlcnRpc2UuDQoNClRoZSBjb25jcmV0ZSB3b3JrIGF0IHRoZSBMMk5TRiBD YXBhYmlsaXR5IExheWVyIGluY2x1ZGVzDQoNCi0gICAgICAgICAgVGhlIGluZm9ybWF0aW9uYWwg JiBkYXRhIG1vZGVscyBmb3IgZWFjaCBjYXRlZ29yeSB0byBiZSByZXByZXNlbnRlZCB0byB2aXJ0 dWFsIG9yIHBoeXNpY2FsIG5ldHdvcmsgc2VjdXJpdHkgZnVuY3Rpb25zLA0KDQotICAgICAgICAg IFRoZSBjYXBhYmlsaXR5IHJlZ2lzdHJ5IChJQU5BKSBvZiBwb2xpY3kgcHJvdmlzaW9uaW5nIGNh cGFiaWxpdHkgdG8gZmxvdyBiYXNlZCBzZWN1cml0eSBmdW5jdGlvbiwgYW5kDQoNCi0gICAgICAg ICAgVGhlIHByb3BlciBzZWN1cmUgY29tbXVuaWNhdGlvbiBjaGFubmVscyB0byBjYXJyeSB0aGUg c2VjdXJpdHkgcG9saWNpZXMgYmV0d2VlbiBDb250cm9sbGVyIGFuZCBOU0ZzLg0KVGhlIGNhcGFi aWxpdHkgcmVnaXN0cnkgaXMgdG8gbWFrZSBpdCBmZWFzaWJsZSB0byBjYXRlZ29yaXplIG5ldHdv cmsgc2VjdXJpdHkgZnVuY3Rpb25zIHByb3ZpZGVkIGJ5IGRpZmZlcmVudCB2ZW5kb3JzIGJhc2Vk IG9uIHNlY3VyaXR5IHBvbGljeSBwcm92aXNpb25pbmcgY2FwYWJpbGl0eSB3aXRob3V0IGFueSBu ZWVkIHRvIHN0YW5kYXJkaXplIHNlY3VyaXR5IGZ1bmN0aW9ucyB0aGVtc2VsdmVzLiAgU3RhbmRh cmQgcHJvdmlzaW9uaW5nIGNhcGFiaWxpdHkgaW50ZXJmYWNlIGlzIGFuIGVzc2VudGlhbCBidWls ZGluZyBibG9jayBmb3IgU2VjdXJpdHkgU2VydmljZSBQcm92aWRlciB0byBhdXRvbWF0ZSB0aGVp ciBTZWN1cml0eSBDb250cm9sbGVycyB0aGF0IGNhbiB1dGlsaXplIE5TRiBieSBtdWx0aXBsZSB2 ZW5kb3JzLiBUaGlzIGxheWVyIHdpbGwgbGV2ZXJhZ2UgdGhlIGV4aXN0aW5nIHByb3RvY29scyBh bmQgZGF0YSBtb2RlbHMgZGVmaW5lZCBieSBJMlJTLCBOZXRjb25mLCBhbmQgTkVUTU9ELg0KDQpG b3IgdGhlIEkyTlNGIFNlcnZpY2UgTGF5ZXIsIGl0IGlzIG91dCBvZiB0aGUgc2NvcGUgZm9yIEky TlNGIChhdCBsZWFzdCBmb3Igbm93KSB0byBzdGFuZGFyZGl6ZSB0aGUgaW50ZXJmYWNlIGZhY2lu ZyBjbGllbnRzLiBIb3dldmVyLCBJMk5TRiBjYW4gaGF2ZSBpbmZvcm1hdGlvbmFsIGRyYWZ0cyBz aG93aW5nIHNhbXBsZSBBUElzIG9yL2FuZCBSRVNUZnVsIGludGVyZmFjZXMgdG8gY2xpZW50cyBh bmQgZGVtb25zdHJhdGluZyB0aGUgZmVhc2liaWxpdHkgb2YgdGhlbSBiZWluZyB0cmFuc2xhdGVk IHRvIHRoZSBDYXBhYmlsaXR5IExheWVyIHBvbGljaWVzLg0KDQpTaW5jZSBkaWZmZXJlbnQgc2Vj dXJpdHkgdmVuZG9ycyBzdXBwb3J0IGRpZmZlcmVudCBmZWF0dXJlcyAmIGZ1bmN0aW9ucyBvbiB0 aGVpciBkZXZpY2VzLCBJMk5TRiB3aWxsIGZvY3VzIG9uIGZsb3cgYmFzZWQgc2VjdXJpdHkgZnVu Y3Rpb25zIHRoYXQgcHJvdmlkZSB0cmVhdG1lbnQgdG8gcGFja2V0cy9mbG93cywgc3VjaCBhcyBJ UFMvSURTLCBXZWIgZmlsdGVyLCBhbmQgZmxvdyBmaWx0ZXIuIChUaGV5IGFyZSBkaWZmZXJlbnQg ZnJvbSBvdGhlciBzZWN1cml0eSBmdW5jdGlvbnMgc3VjaCBhcyBBdXRoZW50aWNhdGlvbiwgQXV0 aG9yaXphdGlvbiwgb3IgRW5jcnlwdGlvbikuIEV4ZW1wbGFyIHNlcnZpY2VzIGFzc29jaWF0ZWQg d2l0aCBGbG93IEJhc2VkIFNlY3VyaXR5IGZ1bmN0aW9ucyBpbmNsdWRlIGRlZXAgcGFja2V0IGlu c3BlY3Rpb24sIHBhY2tldC9mbG93L3N0cmVhbSBmaWx0ZXJpbmcgb3IgcGF0dGVybiBtYXRjaGlu ZyBhbmQgcmVtZWRpYXRpb24sIGV0Yy4NCg0KU2ltaWxhciB0byBJMlJTIGZvY3VzaW5nIG9uIHRo ZSBpbnRlcmZhY2UgdG8gUklCL0ZJQiBldmVuIHRob3VnaCBtb3N0IHJvdXRlcnMgcHJvdmlkZSBm YXIgbW9yZSBmdW5jdGlvbnMgdGhhbiBSSUIvRklCLCB0aGUgSTJOU0YgZm9jdXNlZCBmdW5jdGlv bnMgY2FuIGJlIGEgcG9ydGlvbiBvZiBmZWF0dXJlcyBzdXBwb3J0ZWQgYnkgdmVuZG9yc+KAmSBz cGVjaWZpYyBkZXZpY2VzLg0KDQpJdCBpcyBhIG5vbi1nb2FsIHRvIGNyZWF0ZSBuZXcgcHJvdG9j b2xzIG9yIGRhdGEgbW9kZWxpbmcgbGFuZ3VhZ2VzIGZvciBJMk5TRiBpbnRlcmZhY2VzLg0KSTJO U0YgV0cgRGVsaXZlcmFibGVzIGluY2x1ZGU6DQoNCg0KLSAgICAgICAgICAgVXNlIENhc2UgZG9j dW1lbnQuDQoNCi0gICAgICAgICAgRnJhbWV3b3JrIERvY3VtZW50Lg0KDQotICAgICAgICAgIFJl cXVpcmVtZW50IGZvciBleHRlbnNpb25zIChpZiB0aGVyZSBhcmUgYW55KSB0byBleGlzdGluZyBw cm90b2NvbHMgdXNlZCBieSB0aGUgV0cuDQoNCi0gICAgICAgICAgIEdhcCBhbmFseXNpcyBvZiBl eGlzdGluZyBwcm90b2NvbHMgYW5kIG1vZGVsaW5nIGxhbmd1YWdlcw0KDQotICAgICAgICAgIEEg c2luZ2xlLCB1bmlmaWVkLCBJbmZvcm1hdGlvbiBNb2RlbCBmb3IgZXhwcmVzc2luZyBwb2xpY2ll cyB0byB0aGUgRmxvdyBCYXNlZCBTZWN1cml0eSBGdW5jdGlvbnMgZGVzY3JpYmVkIGFib3ZlLg0K DQotICAgICAgICAgIENvcnJlc3BvbmRpbmcgRGF0YSBNb2RlbHMgKGUuZy4gWUFORyBtb2RlbHMp IGRlcml2ZWQgZnJvbSB0aGUgYWJvdmUgSW5mb3JtYXRpb24gTW9kZWwuDQoNCi0gICAgICAgICAg SUFOQSByZWdpc3RyeSBjb25zaWRlcmF0aW9uIGZvciBmbG93IGJhc2VkIHNlY3VyaXR5IGZ1bmN0 aW9uIHBvbGljeSBwcm92aXNpb25pbmcgY2FwYWJpbGl0eS4NCg0KLSAgICAgICAgICAgKE9wdGlv bmFsbHkpIEFwcGxpY2FiaWxpdHkgU3RhdGVtZW50cyBvbiBob3cgdG8gdXNlIEkyUlMsIE5ldGNv bmYsIGFuZCBORVRNT0QgdG8gY2FycnkgdGhlIGNvbnRlbnQgb2YgdGhlIHNwZWNpZmllZCBpbmZv cm1hdGlvbi9kYXRhIG1vZGVscy4NCg0KW1RoZSBXRyBtYXkgZGVjaWRlIHRoYXQgdGhlIFVzZSBj YXNlcywgRnJhbWV3b3JrLCBhbmQgUmVxdWlyZW1lbnQgYXJlIEluZm9ybWF0aW9uYWwgZG9jdW1l bnRzIG9yIHNpbXBseSByZWZlcmVuY2UgZG9jdW1lbnRzIGR1cmluZyB0aGUgbGlmZXRpbWUgb2Yg dGhlIFdHLiBUaGUgZnJhbWV3b3JrLCB0aGF0IGRlc2NyaWJlcyB0aGUgZnVuY3Rpb25hbCBjb21w b25lbnRzIGFuZCB0aGUgSTJOU0Ygd29yayBpdGVtcywgaXMgdG8gbWFrZSBJMk5TRiB3b3JrIG1v cmUgb3JnYW5pemVkLl0NCg0KU3VnZ2VzdGVkIE1pbGVzdG9uZXMNCiAgLSBVc2UgQ2FzZSBEb2N1 bWVudDogIENoYXJ0ZXIgdGltZSArIDEgbW9udGggdG8gV0cgRG9jdW1lbnQNCiAgLSBGcmFtZXdv cms6IENoYXJ0ZXIgdGltZSArIDQgbW9udGhzIHRvIFdHIERvY3VtZW50DQogIC0gUmVxdWlyZW1l bnRzIGZvciBleHRlbnNpb25zIHRvIHByb3RvY29sczogIENoYXJ0ZXIgdGltZSArIDYgbW9udGhz IHRvIFdHIGRvY3VtZW50DQogIC0gSW5mbyBtb2RlbDogQ2hhcnRlciB0aW1lICsgNyBtb250aHMg dG8gV0cgRG9jdW1lbnQNCiAgLSBJQU5BIHJlZ2lzdHJ5IGNvbnNpZGVyYXRpb24gKyAxMCBtb250 aHMgdG8gV0cgRG9jdW1lbnQNCiAgLSBBbGwgRWFybHkgRHJhZnRzIHRvIElFU0c6IDEwIG1vbnRo cw0KDQpbZGVjaXNpb24gcG9pbnQg4oCTICsxMCBtb250aHNdDQogIC0gRGF0YSBNb2RlbHM6IENo YXJ0ZXIgKyA5IE1vbnRocyB0byBXRyBEb2N1bWVudA0KICAtIEFwcGxpY2FiaWxpdHkgU3RhdGVt ZW50czogMTAgbW9udGhzIHRvIFdHIERvY3VtZW50DQogIC0gRGF0YSBNb2RlbHMgYW5kIEFwcGxp Y2FiaWxpdHkgU3RhdGVtZW50cyB0byBJRVNHICAtIDE2IG1vbnRocw0KDQpUaGUgV0cgd2lsbCB3 b3JrIGNsb3NlbHkgd2l0aCBJMlJTLCBOZXRjb25mIGFuZCBOZXRtb2QgV0dzLiBUaGUgV0cgd2ls bCBjb21tdW5pY2F0ZSB3aXRoIGV4dGVybmFsIFNET3MgbGlrZSBFVFNJIE5GViBhbmQgd2lsbCBl bmNvdXJhZ2Ugb3BlbiBzb3VyY2UgY29kZSBkZXZlbG9wbWVudCByZWxhdGVkIHRvIHRoZSBXRyBz Y29wZSBpbiBvcmdhbml6YXRpb25zIGxpa2UgT05GLCBPcGVuU3RhY2ssIE9ETCwgYW5kIE9wZW5O RlYuDQoNCg0KQ2hlZXJzLA0KTGluZGEgRHVuYmFyDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXyBJMm5zZiBtYWlsaW5nIGxpc3QgSTJuc2ZAaWV0Zi5vcmc8 bWFpbHRvOkkybnNmQGlldGYub3JnPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2kybnNmDQo= --_000_4A95BA014132FF49AE685FAB4B9F17F657C1443Cdfweml701chm_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpTaW1TdW47DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1 IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBh bm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk65a6L5L2TO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxAU2ltU3Vu IjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5r DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENo YXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4 LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KcC5Nc29MaXN0UGFy YWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28t c3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsN CgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0 O30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQg Q2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29u IFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWls U3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGlu IDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K LyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6NTg2MzA2NTcy Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTYxNTk5 ODIyIDE5ODI2NjA0MzYgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2 OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1s ZXZlbC1zdGFydC1hdDowOw0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDotOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoyMi41cHQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3Qt Zm9udC1mYW1pbHk6U2ltU3VuOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t YW4iO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlz dCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw0 DQoJe21zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2 ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLXRhYi1zdG9w OjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBs aXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZl bDkNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6 MTU1MDYwNjg1NDsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1p ZHM6MTMxMTkxOTA3MiAyMTMzMDcwMzI2IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4 NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwxOmxldmVs MQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6LTsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJbWFyZ2luLWxlZnQ6MjIuNXB0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6U2ltU3VuOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRv bTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv Pg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFu Zz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNl Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij5EYSBDaGVuZywgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MjIuNXB0O3Rl eHQtaW5kZW50Oi0uMjVpbiI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPllvdSBzdGF0ZWQg dGhhdCB0aGUgYnVsbGV0IGZvciDigJw8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBw dDtjb2xvcjpibGFjayI+VGhlIHByb3BlciBzZWN1cmUgY29tbXVuaWNhdGlvbiBjaGFubmVscyB0 byBjYXJyeSB0aGUgc2VjdXJpdHkgcG9saWNpZXMgYmV0d2Vlbg0KIENvbnRyb2xsZXIgYW5kIE5T RnPigJ0gPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDtpcyB0cml2aWFs LiBCdXQgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlNBQ00gaXMgY29uc2lkZXJpbmcgdXNpbmcgWE1QUCB0byBl eGNoYW5nZSBkYXRhIGFtb25nIGVuZCBkZXZpY2VzIChpbnN0ZWFkIG9mIE5FVENPTkYpOiBzZWUN Cjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDs8 YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1zYWxvd2V5LXNh Y20teG1wcC1ncmlkLyI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtc2Fs b3dleS1zYWNtLXhtcHAtZ3JpZC88L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjpibGFjayI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5TbyB0aGVyZSBtaWdodCBi ZSBtb3JlIHRoYW4gc2ltcGxlIE5FVENPTkYsIG1heSBiZSBUTFMgJiM0Mzt4eHggaGF2ZSB0byBi ZSBjb25zaWRlcmVkLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5MaW5k YSA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk aW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPiBEYWNoZW5nIFpoYW5nIFttYWlsdG86ZGFjaGVuZy56ZGNAYWxpYmFiYS1pbmMuY29t XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIE1heSAxMiwgMjAxNSAxMDo1NSBQTTxicj4N CjxiPlRvOjwvYj4gTGluZGEgRHVuYmFyOyBpMm5zZkBpZXRmLm9yZzsgS2F0aGxlZW4gTW9yaWFy dHk8YnI+DQo8Yj5DYzo8L2I+IGkycnNAaWV0Zi5vcmc7IGRvdHNAaWV0Zi5vcmc7IG5ldG1vZEBp ZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0kybnNmXSBGdXJ0aGVyIE5hcnJvd2lu ZyB0aGUgSTJOU0Ygc2NvcGU6IHRoZSBuZXcgY2hhcnRlciBmb3IgSUVURiA5MzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OuWui+S9kztjb2xvcjpibGFjayI+SGk8L3NwYW4+ PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6U2lt U3VuO2NvbG9yOmJsYWNrIj7vvIw8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtm b250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2siPkxpbmRhOjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2Zv bnQtZmFtaWx5OuWui+S9kztjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3 LjBwdDtmb250LWZhbWlseTrlrovkvZM7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk65a6L5L2TO2NvbG9yOmJsYWNrIj5JIGxpa2Ug dGhlIGN1cnJlbnQgdmVyc2lvbiBvZiBjaGFydGVyLCB3aGljaCBjbGFyaWZpZXMgYSByZWFzb25h YmxlIHNjb3BlIG9mIHRoaXMgd29yay4gU29tZSB0aW55IGNvbW1lbnRzLiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk65a6L5L2TO2NvbG9yOmJsYWNrIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OuWui+S9kztj b2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlRoZSBjb25j cmV0ZSB3b3JrIGF0IHRoZSBMMk5TRiBDYXBhYmlsaXR5IExheWVyIGluY2x1ZGVzPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjIy LjVwdDt0ZXh0LWluZGVudDotLjI1aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29s b3I6YmxhY2siPi0mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDtUaGUgaW5mb3JtYXRpb25hbCAmYW1wOyBkYXRhIG1vZGVscyBmb3IgZWFj aCBjYXRlZ29yeSB0byBiZSByZXByZXNlbnRlZCB0byB2aXJ0dWFsIG9yIHBoeXNpY2FsIG5ldHdv cmsgc2VjdXJpdHkgZnVuY3Rpb25zLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MjIuNXB0O3RleHQtaW5kZW50Oi0u MjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjpibGFjayI+LSZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1RoZSBj YXBhYmlsaXR5IHJlZ2lzdHJ5IChJQU5BKSBvZiBwb2xpY3kgcHJvdmlzaW9uaW5nIGNhcGFiaWxp dHkgdG8gZmxvdyBiYXNlZCBzZWN1cml0eSBmdW5jdGlvbiwgYW5kPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoyMi41 cHQ7dGV4dC1pbmRlbnQ6LS4yNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9y OmJsYWNrIj4tJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7VGhlIHByb3BlciBzZWN1cmUgY29tbXVuaWNhdGlvbiBjaGFubmVscyB0byBj YXJyeSB0aGUgc2VjdXJpdHkgcG9saWNpZXMgYmV0d2VlbiBDb250cm9sbGVyIGFuZCBOU0ZzLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MjIuNXB0O3RleHQtaW5kZW50Oi0uMjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo3LjBwdDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoyMi41cHQ7dGV4dC1p bmRlbnQ6LS4yNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9yOmJsYWNrIj4m Z3Q7Jmd0O0RhY2hlbmc6IHRoZSB0aGlyZCBidWxsZXQgaXMgcXVpdGUgdHJpdmFsIGNvbXBhcmVk IHdpdGggdGhlIGZpcnN0IHR3byBidWxsZXRzLCBzaW5jZSB3ZSB3aWxsIHRyeSB0byByZS11c2Ug dGhlIHdvcmsgb2YgSTJSUyxOZXRjb25mIHdoZXJlIHRoZQ0KIGdlbmVyYXRpb24gb2Ygc2VjdXJp dHkgY2hhbm5lbHMgaGF2ZSBhbHJlYWR5IGNvbnNpZGVyZWQuICZuYnNwO1NvLCBtYXliZSB3ZSBj b3VsZCByZW1vdmUgaXQuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPlRoZSBjYXBhYmlsaXR5IHJlZ2lzdHJ5IGlzIHRvIG1ha2UgaXQg ZmVhc2libGUgdG8gY2F0ZWdvcml6ZSBuZXR3b3JrIHNlY3VyaXR5IGZ1bmN0aW9ucyBwcm92aWRl ZCBieSBkaWZmZXJlbnQgdmVuZG9ycyBiYXNlZCBvbiBzZWN1cml0eSBwb2xpY3kgcHJvdmlzaW9u aW5nDQogY2FwYWJpbGl0eSB3aXRob3V0IGFueSBuZWVkIHRvIHN0YW5kYXJkaXplIHNlY3VyaXR5 IGZ1bmN0aW9ucyB0aGVtc2VsdmVzLiAmbmJzcDtTdGFuZGFyZCBwcm92aXNpb25pbmcgY2FwYWJp bGl0eSBpbnRlcmZhY2UgaXMgYW4gZXNzZW50aWFsIGJ1aWxkaW5nIGJsb2NrIGZvciBTZWN1cml0 eSBTZXJ2aWNlIFByb3ZpZGVyIHRvIGF1dG9tYXRlIHRoZWlyIFNlY3VyaXR5IENvbnRyb2xsZXJz IHRoYXQgY2FuIHV0aWxpemUgTlNGIGJ5IG11bHRpcGxlIHZlbmRvcnMuDQogVGhpcyBsYXllciB3 aWxsIGxldmVyYWdlIHRoZSBleGlzdGluZyBwcm90b2NvbHMgYW5kIGRhdGEgbW9kZWxzIGRlZmlu ZWQgYnkgSTJSUywgTmV0Y29uZiwgYW5kIE5FVE1PRC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPiZndDsmZ3Q7RGFjaGVuZzogSSBzdWdnZXN0IHRvIGNoYW5nZSB0aGUgbGFz dCBzZW50ZW5jZSB0byDigJxJbiB0aGlzIGxheWVyLCB3ZSB3aWxsIGxldmVyYWdlIHRoZSBleGlz dGluZyBwcm90b2NvbHMgYW5kIGRhdGEgbW9kZWxzIGRlZmluZWQgYnkgSTJSUywgTmV0Y29uZiwg YW5kDQogTkVUTU9EIGFzIG11Y2ggYXMgcG9zc2libGUu4oCdPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj5TaW1pbGFyIHRvIEkyUlMgZm9jdXNpbmcgb24gdGhlIGludGVyZmFj ZSB0byBSSUIvRklCIGV2ZW4gdGhvdWdoIG1vc3Qgcm91dGVycyBwcm92aWRlIGZhciBtb3JlIGZ1 bmN0aW9ucyB0aGFuIFJJQi9GSUIsIHRoZSBJMk5TRiBmb2N1c2VkIGZ1bmN0aW9ucyBjYW4NCiBi ZSBhIHBvcnRpb24gb2YgZmVhdHVyZXMgc3VwcG9ydGVkIGJ5IHZlbmRvcnPigJkgc3BlY2lmaWMg ZGV2aWNlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDsmZ3Q7RGFj aGVuZzogdGhlIGZpcnN0IHBhcnQgb2YgdGhpcyBzZW50ZW5jZSBpcyByZWR1bmRhbnQuIFdlIGRv buKAmXQgaGF2ZSB0byBpbXBseSB0aGF0Jm5ic3A74oCcd2Ugd29yayBpbiB0aGlzIHdheSBiZWNh dXNlIEkyUlMgdXNlZCB0byBkbyBzaW1pbGFyIHRoaW5ncy4gU28gaWYNCiB5b3Ugd2FudCB0byBj aGFsbGVuZ2UgdXMsIHBsZWFzZSBjaGFsbGVuZ2UgSTJSUyBmaXJzdOKAnS4gTWF5YmUgd2UgY291 bGQgcmVtb3ZlIGl0LiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1m YW1pbHk65a6L5L2TO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAx LjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuO2NvbG9yOmJsYWNr Ij7lj5Hku7bkuro8L3NwYW4+PC9iPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Ojwvc3Bh bj48L2I+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4NCjwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj5MaW5kYSBEdW5iYXIgJmx0OzxhIGhyZWY9Im1haWx0bzpsaW5kYS5k dW5iYXJAaHVhd2VpLmNvbSI+bGluZGEuZHVuYmFyQGh1YXdlaS5jb208L2E+Jmd0Ozxicj4NCjwv c3Bhbj48Yj48c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1bjtjb2xv cjpibGFjayI+5pel5pyfPC9zcGFuPjwvYj48Yj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjo8 L3NwYW4+PC9iPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+DQo8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+MjAxNTwvc3Bhbj48c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9 ImZvbnQtZmFtaWx5OlNpbVN1bjtjb2xvcjpibGFjayI+5bm0PC9zcGFuPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+NTwvc3Bhbj48c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtZmFtaWx5 OlNpbVN1bjtjb2xvcjpibGFjayI+5pyIPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ Nzwvc3Bhbj48c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1bjtjb2xv cjpibGFjayI+5pelPC9zcGFuPjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iY29sb3I6YmxhY2si Pg0KPC9zcGFuPjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuO2Nv bG9yOmJsYWNrIj7mmJ/mnJ/lm5s8L3NwYW4+PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJjb2xv cjpibGFjayI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LWZhbWlseTpT aW1TdW47Y29sb3I6YmxhY2siPuS4i+WNiDwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PjExOjUzPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PGJyPg0KPC9zcGFuPjxiPjxz cGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuO2NvbG9yOmJsYWNrIj7o h7M8L3NwYW4+PC9iPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Ojwvc3Bhbj48L2I+PGI+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4NCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj4mcXVvdDs8YSBocmVmPSJtYWlsdG86aTJuc2ZAaWV0Zi5vcmciPmkybnNmQGlldGYu b3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmkybnNmQGlldGYub3JnIj5pMm5zZkBp ZXRmLm9yZzwvYT4mZ3Q7LCBLYXRobGVlbiBNb3JpYXJ0eSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmth dGhsZWVuLm1vcmlhcnR5LmlldGZAZ21haWwuY29tIj5rYXRobGVlbi5tb3JpYXJ0eS5pZXRmQGdt YWlsLmNvbTwvYT4mZ3Q7PGJyPg0KPC9zcGFuPjxiPjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0i Zm9udC1mYW1pbHk6U2ltU3VuO2NvbG9yOmJsYWNrIj7mioTpgIE8L3NwYW4+PC9iPjxiPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+Ojwvc3Bhbj48L2I+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj4NCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mcXVvdDs8YSBocmVm PSJtYWlsdG86aTJyc0BpZXRmLm9yZyI+aTJyc0BpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhy ZWY9Im1haWx0bzppMnJzQGlldGYub3JnIj5pMnJzQGlldGYub3JnPC9hPiZndDssICZxdW90Ozxh IGhyZWY9Im1haWx0bzpkb3RzQGlldGYub3JnIj5kb3RzQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmRvdHNAaWV0Zi5vcmciPmRvdHNAaWV0Zi5vcmc8L2E+Jmd0OywgJnF1 b3Q7PGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9yZyI+bmV0bW9kQGlldGYub3JnPC9hPiZx dW90Ow0KICZsdDs8YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3JnIj5uZXRtb2RAaWV0Zi5v cmc8L2E+Jmd0Ozxicj4NCjwvc3Bhbj48Yj48c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQt ZmFtaWx5OlNpbVN1bjtjb2xvcjpibGFjayI+5Li76aKYPC9zcGFuPjwvYj48Yj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPjo8L3NwYW4+PC9iPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+W0kybnNmXSBGdXJ0aGVyIE5h cnJvd2luZyB0aGUgSTJOU0Ygc2NvcGU6IHRoZSBuZXcgY2hhcnRlciBmb3IgSUVURiA5MzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk65a6L5L2TO2NvbG9yOmJsYWNr Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5UaGFua3MgdG8gSTJO U0YgY29udHJpYnV0b3JzIGZvciB0aGUgZ29vZCBwcm9ncmVzc2VzIG1hZGUgc2luY2UgJm5ic3A7 SUVURjkyIHNpZGUgbWVldGluZ3MuIEFtb25nIHRoZSB0d28gSTJOU0YgaW50ZXJmYWNlcywgJm5i c3A7aS5lLiB0aGUgY2xpZW50IGZhY2luZyBTZXJ2aWNlIEludGVyZmFjZSBhbmQgdGhlIE5TRiBm YWNpbmcgQ2FwYWJpbGl0eSBJbnRlcmZhY2UsIHRoZSB3b3JrDQogdG8gYmUgZG9uZSBhdCB0aGUg Q2FwYWJpbGl0eSBJbnRlcmZhY2UgYmVjb21lcyB2ZXJ5IGNsZWFyIGFuZCBjb25jcmV0ZS4gQnV0 IHRoZSBTZXJ2aWNlIEludGVyZmFjZSBpcyBzdGlsbCBhIGxpdHRsZSB2YWd1ZS4NCjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5UaGUgZmVlZGJhY2sgZnJvbSBsYXN0IElFVEYgc2lk ZSBtZWV0aW5ncyB3YXMgJnF1b3Q7dGhlIHNjb3BlIGlzIHRvbyBiaWcgZm9yIG9uZSBJRVRGIFdH JnF1b3Q7LiBUaGVyZWZvcmUsIHdlIGFyZSBsZWFuaW5nIHRvd2FyZHMgbmFycm93aW5nIHRoZSBJ Mk5TRiBzY29wZSB0byB0aGUgQ2FwYWJpbGl0eSBJbnRlcmZhY2UuIFRoZSB0aGlua2luZyBsb2dp YyBpczogT25jZSB0aGUgQ2FwYWJpbGl0eQ0KIEludGVyZmFjZSBpcyBjb21wbGV0ZWQsIHdlIHdp bGwgc2VlIG1vcmUgY2xlYXJseSB0aGUgd29yayBmb3IgU2VydmljZSBpbnRlcmZhY2UuIEV2ZW4g aWYgQ2FwYWJpbGl0eSBsYXllciBhbG9uZSBpcyBzdGFuZGFyZGl6ZWQsIGl0IGlzIGEgZ2lhbnQg bGVhcCBmb3J3YXJkIGluIGJ1aWxkaW5nIGJsb2NrcyBmb3IgU2VydmljZSBQcm92aWRlciB0byBh dXRvbWF0ZSB0aGVpciBTZWN1cml0eSBDb250cm9sbGVyIHRoYXQgY2FuIHV0aWxpemUgTlNGIGJ5 DQogbXVsdGlwbGUgdmVuZG9yczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5IZXJl IGlzIHRoZSBuYXJyb3dlciBzY29wZWQgSTJOU0YgY2hhcnRlci4gWW91ciBjb21tZW50cyBhbmQg c3VnZ2VzdGlvbnMgYXJlIGdyZWF0bHkgYXBwcmVjaWF0ZWQuIEND4oCZZWQgdG8gRE9UUywgSTJS UywgYW5kIE5ldG1vZCBncm91cHMgZm9yIHdpZGVyIHJldmlldy4NCjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWJvdHRvbTpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAxLjBwdCAwaW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5FbnRlcnByaXNlcywgcmVz aWRlbnRpYWwsIGFuZCBtb2JpbGUgY3VzdG9tZXJzIGFyZSBpbmNyZWFzaW5nbHkgY29uc3VtaW5n IG5ldHdvcmsgZnVuY3Rpb25zLCBlc3BlY2lhbGx5IG5ldHdvcmsgc2VjdXJpdHkgcmVsYXRlZCBm dW5jdGlvbnMgdGhhdCBhcmUgbm90IHJ1bm5pbmcgb24gdGhlaXIgcHJlbWlzZXMuJm5ic3A7IElu IGFkZGl0aW9uLCB0aGUgRXVyb3BlYW4gVGVsZWNvbW11bmljYXRpb25zDQogU3RhbmRhcmRzIElu c3RpdHV0ZSAoRVRTSSkgTmV0d29yayBGdW5jdGlvbiBWaXJ0dWFsaXphdGlvbiAoTkZWKSBpbml0 aWF0aXZlIGNyZWF0ZXMgbmV3IG1hbmFnZW1lbnQgY2hhbGxlbmdlcyBmb3Igc2VjdXJpdHkgcG9s aWNpZXMgdG8gYmUgZW5mb3JjZWQgYnkgZGlzdHJpYnV0ZWQsIHZpcnR1YWwsIG5ldHdvcmsgc2Vj dXJpdHkgZnVuY3Rpb25zICh2TlNGKS4gV2l0aG91dCBzdGFuZGFyZCBpbnRlcmZhY2UgdG8gZXhw cmVzcywgbW9uaXRvciwgYW5kDQogbWFuYWdlIHNlY3VyaXR5IHBvbGljaWVzIHRvIHNlY3VyaXR5 IGZ1bmN0aW9ucyBkZXBsb3llZCBhdCBkaWZmZXJlbnQgcHJlbWlzZXMsIGl0IGJlY29tZXMgdmly dHVhbGx5IGltcG9zc2libGUgZm9yIHNlY3VyaXR5IHNlcnZpY2UgcHJvdmlkZXJzIHRvIGF1dG9t YXRlIHRoZSBzZXJ2aWNlIG9mZmVyaW5nIHV0aWxpemluZyBzZWN1cml0eSBmdW5jdGlvbnMgYnkg bXVsdGlwbGUgdmVuZG9ycy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5UaGUg dWx0aW1hdGUgZ29hbCBvZiBJMk5TRiBpcyB0byBlbmFibGUgZW50ZXJwcmlzZXMgdG8gdXRpbGl6 ZSBzZWN1cml0eSBmdW5jdGlvbnMgbm90IGhvc3RlZCBvbiB0aGVpciBvd24gcHJlbWlzZXMgYnV0 IGluc3RlYWQgaG9zdGVkIGluIHNlcnZpY2UgcHJvdmlkZXIgZG9tYWluLCB0byBlc3RhYmxpc2gg aG93IHRvIGNvbW11bmljYXRlIGRlc2lyZWQgc2VjdXJpdHkNCiBwb2xpY2llcyB0byBOU0YgYW5k IGhvdyB0byBnZXQgcGVyZm9ybWFuY2UgZGF0YSBvciByZXBvcnQgb3V0IG9mIE5TRiBvciB2TlNG LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5UaGVyZSBhcmUgdHdvIGxheWVycyBv ZiBpbnRlcmZhY2VzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFy YWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MjIuNXB0O3RleHQtaW5kZW50Oi0uMjVpbjttc28t bGlzdDpsMCBsZXZlbDEgbGZvMiI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3BhbiBzdHlsZT0i Zm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3Nw YW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+U2VjdXJpdHkgUG9saWNpZXMg ZmFjaW5nIHNlY3VyaXR5IGZ1bmN0aW9ucyAoSTJOU0YgQ2FwYWJpbGl0eSBMYXllcik8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjIyLjVwdDt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIi Pg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48c3BhbiBz dHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPlNlY3VyaXR5IFBvbGljaWVzIGZhY2luZyBjbGllbnRzIChJMk5T RiBTZXJ2aWNlIExheWVyKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5UaGUgSTJO U0YgQ2FwYWJpbGl0eSBMYXllciBzcGVjaWZpZXMgdGhlIGZ1bmN0aW9uYWwgc2VjdXJpdHkgcG9s aWNpZXMsIHdoaWNoIGFyZSB0cmFuc2xhdGVkIGZyb20gdGhlIGNsaWVudCBzZWN1cml0eSBwb2xp Y2llcywgdG8gc2VjdXJpdHkgZnVuY3Rpb25zLiBJMk5TRiB3aWxsIE5PVCBzdGFuZGFyZGl6ZSBz ZWN1cml0eSBmdW5jdGlvbnMgb3IgZGV2aWNlcy4gSW5zdGVhZCwNCiBJMk5TRiBpcyBvbmx5IHRv IHN0YW5kYXJkaXplIHRoZSBwb2xpY3kgcHJvdmlzaW9uaW5nIHRvIHRoZSBzZWN1cml0eSBmdW5j dGlvbnMgKG5vdCBkZXZpY2VzKSwgaW4gdGhlIGZvcm0gb2Yg4oCcU3ViamVjdCDigJMgT2JqZWN0 IOKAkyBGdW5jdGlvbiDigJMgQWN0aW9u4oCdIHBhcmFkaWdtLiZuYnNwOw0KPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPlRoZSBJMk5TRiBTZXJ2aWNlIExheWVyIGlzIGZvciBjbGll bnRzIHRvIGV4cHJlc3MgYW5kIG1vbml0b3Igc2VjdXJpdHkgcG9saWNpZXMgZm9yIHRoZWlyIHNw ZWNpZmljIGZsb3dzLCB3aGljaCBpcyB1c3VhbGx5IGJhc2VkIG9uIGN1c3RvbWVyc+KAmSBsb2dp Y2FsIG5ldHdvcmtzLCBhZGRyZXNzZXMgYW5kIGNvbnRleHQuIEkyTlNGIFNlcnZpY2UgTGF5ZXIg Y2FuIGFsc28NCiBiZSBzZWN1cml0eSBleHBlY3RhdGlvbiBvciBsb29zZSBzZWN1cml0eSByZXF1 aXJlbWVudCwgZXNwZWNpYWxseSBmb3IgY3VzdG9tZXJzIHdobyBkb27igJl0IGhhdmUgdGhlIHNl Y3VyaXR5IGV4cGVydGlzZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+VGhlIGNv bmNyZXRlIHdvcmsgYXQgdGhlIEwyTlNGIENhcGFiaWxpdHkgTGF5ZXIgaW5jbHVkZXM8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjIyLjVwdDt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIi Pg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48c3BhbiBz dHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPlRoZSBpbmZvcm1hdGlvbmFsICZhbXA7IGRhdGEgbW9kZWxzIGZv ciBlYWNoIGNhdGVnb3J5IHRvIGJlIHJlcHJlc2VudGVkIHRvIHZpcnR1YWwgb3IgcGh5c2ljYWwg bmV0d29yayBzZWN1cml0eSBmdW5jdGlvbnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoyMi41cHQ7dGV4dC1pbmRl bnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8yIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNd PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+ LTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3Nw YW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5UaGUg Y2FwYWJpbGl0eSByZWdpc3RyeSAoSUFOQSkgb2YgcG9saWN5IHByb3Zpc2lvbmluZyBjYXBhYmls aXR5IHRvIGZsb3cgYmFzZWQgc2VjdXJpdHkgZnVuY3Rpb24sIGFuZA0KPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoy Mi41cHQ7dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8yIj4NCjwhW2lm ICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PHNwYW4gc3R5bGU9Im1z by1saXN0Oklnbm9yZSI+LTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj5UaGUgcHJvcGVyIHNlY3VyZSBjb21tdW5pY2F0aW9uIGNoYW5uZWxzIHRvIGNh cnJ5IHRoZSBzZWN1cml0eSBwb2xpY2llcyBiZXR3ZWVuIENvbnRyb2xsZXIgYW5kIE5TRnMuDQo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPlRoZSBjYXBhYmlsaXR5IHJlZ2lzdHJ5IGlzIHRvIG1ha2UgaXQgZmVhc2li bGUgdG8gY2F0ZWdvcml6ZSBuZXR3b3JrIHNlY3VyaXR5IGZ1bmN0aW9ucyBwcm92aWRlZCBieSBk aWZmZXJlbnQgdmVuZG9ycyBiYXNlZCBvbiBzZWN1cml0eSBwb2xpY3kgcHJvdmlzaW9uaW5nIGNh cGFiaWxpdHkgd2l0aG91dCBhbnkgbmVlZCB0byBzdGFuZGFyZGl6ZSBzZWN1cml0eSBmdW5jdGlv bnMNCiB0aGVtc2VsdmVzLiAmbmJzcDtTdGFuZGFyZCBwcm92aXNpb25pbmcgY2FwYWJpbGl0eSBp bnRlcmZhY2UgaXMgYW4gZXNzZW50aWFsIGJ1aWxkaW5nIGJsb2NrIGZvciBTZWN1cml0eSBTZXJ2 aWNlIFByb3ZpZGVyIHRvIGF1dG9tYXRlIHRoZWlyIFNlY3VyaXR5IENvbnRyb2xsZXJzIHRoYXQg Y2FuIHV0aWxpemUgTlNGIGJ5IG11bHRpcGxlIHZlbmRvcnMuIFRoaXMgbGF5ZXIgd2lsbCBsZXZl cmFnZSB0aGUgZXhpc3RpbmcgcHJvdG9jb2xzIGFuZCBkYXRhIG1vZGVscw0KIGRlZmluZWQgYnkg STJSUywgTmV0Y29uZiwgYW5kIE5FVE1PRC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+Rm9yIHRoZSBJMk5TRiBTZXJ2aWNlIExheWVyLCBpdCBpcyBvdXQgb2YgdGhlIHNjb3BlIGZv ciBJMk5TRiAoYXQgbGVhc3QgZm9yIG5vdykgdG8gc3RhbmRhcmRpemUgdGhlIGludGVyZmFjZSBm YWNpbmcgY2xpZW50cy4gSG93ZXZlciwgSTJOU0YgY2FuIGhhdmUgaW5mb3JtYXRpb25hbCBkcmFm dHMgc2hvd2luZyBzYW1wbGUgQVBJcyBvci9hbmQgUkVTVGZ1bCBpbnRlcmZhY2VzDQogdG8gY2xp ZW50cyBhbmQgZGVtb25zdHJhdGluZyB0aGUgZmVhc2liaWxpdHkgb2YgdGhlbSBiZWluZyB0cmFu c2xhdGVkIHRvIHRoZSBDYXBhYmlsaXR5IExheWVyIHBvbGljaWVzLg0KPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPlNpbmNlIGRpZmZlcmVudCBzZWN1cml0eSB2ZW5kb3JzIHN1cHBv cnQgZGlmZmVyZW50IGZlYXR1cmVzICZhbXA7IGZ1bmN0aW9ucyBvbiB0aGVpciBkZXZpY2VzLCBJ Mk5TRiB3aWxsIGZvY3VzIG9uIGZsb3cgYmFzZWQgc2VjdXJpdHkgZnVuY3Rpb25zIHRoYXQgcHJv dmlkZSB0cmVhdG1lbnQgdG8gcGFja2V0cy9mbG93cywgc3VjaCBhcyBJUFMvSURTLCBXZWIgZmls dGVyLA0KIGFuZCBmbG93IGZpbHRlci4gKFRoZXkgYXJlIGRpZmZlcmVudCBmcm9tIG90aGVyIHNl Y3VyaXR5IGZ1bmN0aW9ucyBzdWNoIGFzIEF1dGhlbnRpY2F0aW9uLCBBdXRob3JpemF0aW9uLCBv ciBFbmNyeXB0aW9uKS4gRXhlbXBsYXIgc2VydmljZXMgYXNzb2NpYXRlZCB3aXRoIEZsb3cgQmFz ZWQgU2VjdXJpdHkgZnVuY3Rpb25zIGluY2x1ZGUgZGVlcCBwYWNrZXQgaW5zcGVjdGlvbiwgcGFj a2V0L2Zsb3cvc3RyZWFtIGZpbHRlcmluZyBvciBwYXR0ZXJuDQogbWF0Y2hpbmcgYW5kIHJlbWVk aWF0aW9uLCBldGMuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5TaW1pbGFyIHRv IEkyUlMgZm9jdXNpbmcgb24gdGhlIGludGVyZmFjZSB0byBSSUIvRklCIGV2ZW4gdGhvdWdoIG1v c3Qgcm91dGVycyBwcm92aWRlIGZhciBtb3JlIGZ1bmN0aW9ucyB0aGFuIFJJQi9GSUIsIHRoZSBJ Mk5TRiBmb2N1c2VkIGZ1bmN0aW9ucyBjYW4gYmUgYSBwb3J0aW9uIG9mIGZlYXR1cmVzIHN1cHBv cnRlZCBieSB2ZW5kb3Jz4oCZIHNwZWNpZmljIGRldmljZXMuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPkl0IGlzIGEgbm9uLWdvYWwgdG8gY3JlYXRlIG5ldyBwcm90b2NvbHMgb3Ig ZGF0YSBtb2RlbGluZyBsYW5ndWFnZXMgZm9yIEkyTlNGIGludGVyZmFjZXMuDQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPkkyTlNGIFdHIERlbGl2ZXJhYmxlcyBpbmNsdWRlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJt YXJnaW4tbGVmdDoyMi41cHQ7dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBs Zm8yIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PHNw YW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+LTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDtVc2UgQ2FzZSBkb2N1bWVudC4gPG86cD4NCjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjIyLjVwdDt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIi Pg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48c3BhbiBz dHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPkZyYW1ld29yayBEb2N1bWVudC48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjIyLjVw dDt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPg0KPCFbaWYgIXN1 cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48c3BhbiBzdHlsZT0ibXNvLWxp c3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPlJlcXVpcmVtZW50IGZvciBleHRlbnNpb25zIChpZiB0aGVyZSBhcmUgYW55KSB0byBl eGlzdGluZyBwcm90b2NvbHMgdXNlZCBieSB0aGUgV0cuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjIyLjVwdDt0 ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPg0KPCFbaWYgIXN1cHBv cnRMaXN0c10+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6 SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPiZuYnNwO0dhcCBhbmFseXNpcyBvZiBleGlzdGluZyBwcm90b2NvbHMgYW5kIG1vZGVsaW5n IGxhbmd1YWdlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdy YXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MjIuNXB0O3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlz dDpsMCBsZXZlbDEgbGZvMiI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3BhbiBzdHlsZT0iZm9u dDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+ PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+QSBzaW5nbGUsIHVuaWZpZWQsIElu Zm9ybWF0aW9uIE1vZGVsIGZvciBleHByZXNzaW5nIHBvbGljaWVzIHRvIHRoZSBGbG93IEJhc2Vk IFNlY3VyaXR5IEZ1bmN0aW9ucyBkZXNjcmliZWQgYWJvdmUuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoyMi41cHQ7 dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8yIj4NCjwhW2lmICFzdXBw b3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PHNwYW4gc3R5bGU9Im1zby1saXN0 Oklnbm9yZSI+LTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj5Db3JyZXNwb25kaW5nIERhdGEgTW9kZWxzIChlLmcuIFlBTkcgbW9kZWxzKSBkZXJpdmVk IGZyb20gdGhlIGFib3ZlIEluZm9ybWF0aW9uIE1vZGVsLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MjIuNXB0O3Rl eHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+DQo8IVtpZiAhc3VwcG9y dExpc3RzXT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJ Z25vcmUiPi08c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw Ow0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+SUFOQSByZWdpc3RyeSBjb25zaWRlcmF0aW9uIGZvciBmbG93IGJhc2VkIHNlY3VyaXR5IGZ1 bmN0aW9uIHBvbGljeSBwcm92aXNpb25pbmcgY2FwYWJpbGl0eS48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjIyLjVw dDt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPg0KPCFbaWYgIXN1 cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48c3BhbiBzdHlsZT0ibXNvLWxp c3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPiZuYnNwOyhPcHRpb25hbGx5KSBBcHBsaWNhYmlsaXR5IFN0YXRlbWVudHMgb24gaG93 IHRvIHVzZSBJMlJTLCBOZXRjb25mLCBhbmQgTkVUTU9EIHRvIGNhcnJ5IHRoZSBjb250ZW50IG9m IHRoZSBzcGVjaWZpZWQgaW5mb3JtYXRpb24vZGF0YSBtb2RlbHMuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj5bPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+VGhlIFdH IG1heSBkZWNpZGUgdGhhdCB0aGUgVXNlIGNhc2VzLCBGcmFtZXdvcmssIGFuZCBSZXF1aXJlbWVu dCBhcmUgSW5mb3JtYXRpb25hbCBkb2N1bWVudHMgb3Igc2ltcGx5IHJlZmVyZW5jZSBkb2N1bWVu dHMgZHVyaW5nIHRoZSBsaWZldGltZQ0KIG9mIHRoZSBXRy4gVGhlIGZyYW1ld29yaywgdGhhdCBk ZXNjcmliZXMgdGhlIGZ1bmN0aW9uYWwgY29tcG9uZW50cyBhbmQgdGhlIEkyTlNGIHdvcmsgaXRl bXMsIGlzIHRvIG1ha2UgSTJOU0Ygd29yayBtb3JlIG9yZ2FuaXplZC5dPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPlN1Z2dlc3RlZCBNaWxlc3RvbmVzPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJz cDsgLSBVc2UgQ2FzZSBEb2N1bWVudDombmJzcDsgQ2hhcnRlciB0aW1lICYjNDM7IDEgbW9udGgg dG8gV0cgRG9jdW1lbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyAtIEZyYW1ld29yazogQ2hhcnRlciB0 aW1lICYjNDM7IDQgbW9udGhzIHRvIFdHIERvY3VtZW50PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsgLSBS ZXF1aXJlbWVudHMgZm9yIGV4dGVuc2lvbnMgdG8gcHJvdG9jb2xzOiZuYnNwOyBDaGFydGVyIHRp bWUgJiM0MzsgNiBtb250aHMgdG8gV0cgZG9jdW1lbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyAtIElu Zm8gbW9kZWw6IENoYXJ0ZXIgdGltZSAmIzQzOyA3IG1vbnRocyB0byBXRyBEb2N1bWVudDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+Jm5ic3A7IC0gSUFOQSByZWdpc3RyeSBjb25zaWRlcmF0aW9uICYjNDM7IDEwIG1v bnRocyB0byBXRyBEb2N1bWVudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7IC0gQWxsIEVhcmx5IERyYWZ0 cyB0byBJRVNHOiAxMCBtb250aHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+W2Rl Y2lzaW9uIHBvaW50IOKAkyAmIzQzOzEwIG1vbnRoc10mbmJzcDsgPG86cD4NCjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZu YnNwOyZuYnNwOy0gRGF0YSBNb2RlbHM6IENoYXJ0ZXIgJiM0MzsgOSBNb250aHMgdG8gV0cgRG9j dW1lbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyAtIEFwcGxpY2FiaWxpdHkgU3RhdGVtZW50czogMTAg bW9udGhzIHRvIFdHIERvY3VtZW50PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsgLSBEYXRhIE1vZGVscyBh bmQgQXBwbGljYWJpbGl0eSBTdGF0ZW1lbnRzIHRvIElFU0cmbmJzcDsgLSAxNiBtb250aHM8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1ib3R0b206c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBpbiAw aW4gMS4wcHQgMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+VGhlIFdHIHdpbGwgd29yayBjbG9zZWx5IHdpdGggSTJSUywgTmV0Y29uZiBhbmQgTmV0 bW9kIFdHcy4gVGhlIFdHIHdpbGwgY29tbXVuaWNhdGUgd2l0aCBleHRlcm5hbCBTRE9zIGxpa2Ug RVRTSSBORlYgYW5kIHdpbGwgZW5jb3VyYWdlIG9wZW4gc291cmNlIGNvZGUgZGV2ZWxvcG1lbnQg cmVsYXRlZCB0byB0aGUgV0cgc2NvcGUgaW4gb3JnYW5pemF0aW9ucyBsaWtlDQogT05GLCBPcGVu U3RhY2ssIE9ETCwgYW5kIE9wZW5ORlYuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5DaGVlcnMsIDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+TGluZGEg RHVuYmFyPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk65a6L5L2T O2NvbG9yOmJsYWNrIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXyBJMm5zZiBtYWlsaW5nIGxpc3QNCjxhIGhyZWY9Im1haWx0bzpJMm5zZkBpZXRmLm9yZyI+ STJuc2ZAaWV0Zi5vcmc8L2E+IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vaTJuc2YiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9p Mm5zZjwvYT4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_4A95BA014132FF49AE685FAB4B9F17F657C1443Cdfweml701chm_-- From nobody Wed May 13 09:31:27 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC4071B2DFB; Wed, 13 May 2015 09:31:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QQzgfpmJKayQ; Wed, 13 May 2015 09:31:17 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3C211B2CEB; Wed, 13 May 2015 09:31:15 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BSM49385; Wed, 13 May 2015 16:31:14 +0000 (GMT) Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 13 May 2015 17:31:14 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml705-chm ([10.193.5.142]) with mapi id 14.03.0158.001; Wed, 13 May 2015 09:31:06 -0700 From: Linda Dunbar To: "Romascanu, Dan (Dan)" , "Zarny, Myo" , "'i2nsf@ietf.org'" , "'Kathleen Moriarty'" Thread-Topic: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93 Thread-Index: AQHQinCAWnYgWx+c3k2SduRLi+ubTp127a2AgAMwn9A= Date: Wed, 13 May 2015 16:31:06 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657C14453@dfweml701-chm> References: <4A95BA014132FF49AE685FAB4B9F17F657C11DC6@dfweml701-chm> <9904FB1B0159DA42B0B887B7FA8119CA5CA27888@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5CA27888@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.128] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657C14453dfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "'i2rs@ietf.org'" , "'dots@ietf.org'" , "'netmod@ietf.org'" Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93 X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 16:31:24 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F657C14453dfweml701chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Dan, Myo, Diego, Xiao Jun, Frank and Zing's suggestions. p.s. I had to check dictionary for "bespoke" too. Synonyms are "custom-made", "made to order", and "made to meas= ure", which is a very accurat= e description. I will update the charter per your suggestions, Linda From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Romascanu, Dan (Da= n) Sent: Monday, May 11, 2015 3:44 AM To: Zarny, Myo; Linda Dunbar; 'i2nsf@ietf.org'; 'Kathleen Moriarty' Cc: 'i2rs@ietf.org'; 'dots@ietf.org'; 'netmod@ietf.org' Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new charter for= IETF 93 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 coop= erate with ETSI, so keeping explicit mentioning out of the introduction is = fine. Thanks and Regards, Dan From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Zarny, Myo Sent: Saturday, May 09, 2015 6:55 PM To: 'Linda Dunbar'; 'i2nsf@ietf.org'; 'Kathleen Moriarty' Cc: 'i2rs@ietf.org'; 'dots@ietf.org'; 'netmod@ietf.org' 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 delive= rables, milestones, etc. BUT we should tweak the first two paragraphs relat= ed to the goal of the WG. I2NSF shouldn't take a position on where the secu= rity functions are hosted or if the caller and the security service functio= n belong to the same or different domains. Also, not sure if we should brin= g 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 sec= urity services hosted by one or more providers, which may be their own ente= rprise, service providers, or a combination of both. Likewise, service prov= iders may offer their customers network security services that consist of m= ultiple security products from different vendors. Yet because no widely acc= epted industry standard security interfaces exist today, management of NSFs= (device and policy provisioning, monitoring, etc.) tends to be bespoke, es= sentially as offered by product vendors. As a result, automation of such se= rvices, 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 NS= Fs 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 mu= ch or too light. Myo From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: 7 May 2015 11:53 AM To: i2nsf@ietf.org; Kathleen Moriarty Cc: i2rs@ietf.org; dots@ietf.org; netmod@ietf.org Subject: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IET= F 93 Thanks to I2NSF contributors for the good progresses made since IETF92 sid= e 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 I= nterface 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 t= he Capability Interface. The thinking logic is: Once the Capability Interfa= ce is completed, we will see more clearly the work for Service interface. E= ven if Capability layer alone is standardized, it is a giant leap forward i= n building blocks for Service Provider to automate their Security Controlle= r that can utilize NSF by multiple vendors Here is the narrower scoped I2NSF charter. Your comments and suggestions ar= e greatly appreciated. CC'ed to DOTS, I2RS, and Netmod groups for wider rev= iew. Enterprises, residential, and mobile customers are increasingly consuming n= etwork functions, especially network security related functions that are no= t 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 i= nterface to express, monitor, and manage security policies to security func= tions deployed at different premises, it becomes virtually impossible for s= ecurity service providers to automate the service offering utilizing securi= ty functions by multiple vendors. The ultimate goal of I2NSF is to enable enterprises to utilize security fun= ctions not hosted on their own premises but instead hosted in service provi= der domain, to establish how to communicate desired security policies to NS= F 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 La= yer) - Security Policies facing clients (I2NSF Service Layer) The I2NSF Capability Layer specifies the functional security policies, whic= h 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("Subjec= t-Object-Function-Action") in the charter. The I2NSF Service Layer is for clients to express and monitor security poli= cies 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 clien= ts to express and monitor security policies. The policies may be intent-bas= ed." The concrete work at the L2NSF Capability Layer includes - The informational & data models for each category to be represen= ted 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 p= olicies between Controller and NSFs. The capability registry is to make it feasible to categorize network securi= ty functions provided by different vendors based on security policy provisi= oning capability without any need to standardize security functions themsel= ves. Standard provisioning capability interface is an essential building b= lock for Security Service Provider to automate their Security Controllers t= hat can utilize NSF by multiple vendors. This layer will leverage the exist= ing 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 clien= ts and demonstrating the feasibility of them being translated to the Capabi= lity Layer policies. Since different security vendors support different features & functions on = their devices, I2NSF will focus on flow based security functions that provi= de 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 Base= d Security functions include deep packet inspection, packet/flow/stream fil= tering or pattern matching and remediation, etc. Similar to I2RS focusing on the interface to RIB/FIB even though most route= rs 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 I2N= SF interfaces. I2NSF WG Deliverables include: - Use Case document. - Framework Document. - Requirement for extensions (if there are any) to existing protoc= ols 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 ab= ove Information Model. - IANA registry consideration for flow based security function pol= icy provisioning capability. - (Optionally) Applicability Statements on how to use I2RS, Netco= nf, and NETMOD to carry the content of the specified information/data model= s. [The WG may decide that the Use cases, Framework, and Requirement are Infor= mational 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 W= G 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 com= municate with external SDOs like ETSI NFV and will encourage open source co= de development related to the WG scope in organizations like ONF, OpenStack= , ODL, and OpenNFV. Cheers, Linda Dunbar --_000_4A95BA014132FF49AE685FAB4B9F17F657C14453dfweml701chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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

 

p.s. I had to check di= ctionary for “bespoke” too. Synonyms are "custom-made", "made to or= der", and "made to measure", which is a very accurate description.

 

I will update the char= ter per your suggestions,

 

Linda

 

From: I2nsf [m= ailto:i2nsf-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Monday, May 11, 2015 3:44 AM
To: Zarny, Myo; Linda Dunbar; 'i2nsf@ietf.org'; 'Kathleen Moriarty'<= br> Cc: 'i2rs@ietf.org'; 'dots@ietf.org'; 'netmod@ietf.org'
Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new char= ter for IETF 93

 

I am fine with the edi= ting proposed by Myo as it makes the scope more clear. Maybe the only thing= I would suggest is to use ‘non-standard’ rather than ‘be= spoke’ 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 a= re 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<= /p>

 

 

From: I2nsf [<= a href=3D"mailto:i2nsf-bounces@ietf.org">mailto:i2nsf-bounces@ietf.org] On Behalf Of Zarny, Myo
Sent: Saturday, May 09, 2015 6:55 PM
To: 'Linda Dunbar'; 'i2nsf@ietf.org'; 'Kathleen Moriarty'
Cc: 'i2rs@ietf.org'; 'dots@ietf.org'; 'netmod@ietf.org'
Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new char= ter for IETF 93

 

Hi Linda,

 

Thanks very much for p= utting this together. I agree that the scope needs to be tightened if it is= to be meaningful. I’m fine with the suggested deliverables, mileston= es, etc. BUT we should tweak the first two paragraphs related to the goal of the WG. I2NSF shouldn’t take a pos= ition on where the security functions are hosted or if the caller and the s= ecurity 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 sta= b at rewording the first few paragraphs…

 

Network security functions (NSFs= ) are increasingly provided and consumed in increasingly diverse environmen= ts. 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 securi= ty interfaces exist today, management of NSFs (device and policy provisioni= ng, monitoring, etc.) tends to be bespoke, essentially as offered by produc= t vendors. As a result, automation of such services, if it exists at all, is also bespoke.  <= /span>

 

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

 

The scope of I2NSF can be furthe= r 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<= /p>

 

 

From: I2nsf [mailto:= i2nsf-bounces@ietf.org] On Behalf Of Linda Dunbar
Sent: 7 May 2015 11:53 AM
To: i2nsf@ietf.org; Kathleen M= oriarty
Cc: i2rs@ietf.org; dots@ietf.org; netmod@ietf.org Subject: [I2nsf] Further Narrowing the I2NSF scope: the new charter = for IETF 93

 

Thanks to I2NSF contribut= ors for the good progresses made since  IETF92 side meetings. Among th= e 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. Bu= t the Service Interface is still a little vague.

 

The feedback from last IE= TF side meetings was "the scope is too big for one IETF WG". Ther= efore, we are leaning towards narrowing the I2NSF scope to the Capability I= nterface. The thinking logic is: Once the Capability Interface is completed, we will see more clearly the work for Service inte= rface. Even if Capability layer alone is standardized, it is a giant leap f= orward in building blocks for Service Provider to automate their Security C= ontroller that can utilize NSF by multiple vendors

 

Here is the narrower scop= ed 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, especia= lly network security related functions that are not running on their premis= es.  In addition, the European Telecommunications Standards Institute (ETSI) Network Function Virtualization (NFV) initiativ= e 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 premi= ses, it becomes virtually impossible for security service providers to auto= mate the service offering utilizing security functions by multiple vendors.

 

The ultimate goal of I2NS= F is to enable enterprises to utilize security functions not hosted on thei= r 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 vN= SF.

 

There are two layers of i= nterfaces:

-       = ;   Security Policies facing security functions (I2NSF = Capability Layer)

-       = ;   Security Policies facing clients (I2NSF Service Lay= er)

 

The I2NSF Capability Layer specifies the functional security policies, w= hich are translated from the client security policies, to security function= s. I2NSF will NOT standardize security functions or devices. Instead, I2NSF is only to standardize the policy pro= visioning to the security functions (not devices), in the form of “Su= bject – Object – Function – Action” paradigm. 

MZ:  Not sure if we need to explicitly specify a potential soluti= on(“Subject-Object-Function-Action”) in the charter.=

 

The I2NSF Service Layer i= s for clients to express and monitor security policies for their specific f= lows, which is usually based on customers’ logical networks, addresse= s and context. I2NSF Service Layer can also be security expectation or loose security requirement, especially for cust= omers who don’t have the security expertise.

MZ:  I suggest “I2NSF Services Layer provides a set of inte= rfaces for clients to express and monitor security policies. The policies m= ay be intent-based.”

 

The concrete work at the = L2NSF Capability Layer includes

-  &= nbsp;       The informational & data models for each= category to be represented to virtual or physical network security functio= ns,

-  &= nbsp;       The capability registry (IANA) of policy pro= visioning capability to flow based security function, and

-  &= nbsp;       The proper secure communication channels to = carry the security policies between Controller and NSFs.

The capability registry i= s 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 essenti= al building block for Security Service Provider to automate their Security = Controllers that can utilize NSF by multiple vendors. This layer will lever= age the existing protocols and data models defined by I2RS, Netconf, and NETMOD.

 

For the I2NSF Service Lay= er, it is out of the scope for I2NSF (at least for now) to standardize the = interface facing clients. However, I2NSF can have informational drafts show= ing sample APIs or/and RESTful interfaces to clients and demonstrating the feasibility of them being translated to t= he 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 packe= ts/flows, such as IPS/IDS, Web filter, and flow filter. (They are different from other security functions such as Aut= hentication, Authorization, or Encryption). Exemplar services associated wi= th Flow Based Security functions include deep packet inspection, packet/flo= w/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 funct= ions than RIB/FIB, the I2NSF focused functions can be a portion of features= supported by vendors’ specific devices.

 

It is a non-goal to creat= e new protocols or data modeling languages for I2NSF interfaces.

I2NSF WG Deliverables inc= lude:

 

-       = ;    Use Case document.

-       = ;   Framework Document.

-       = ;   Requirement for extensions (if there are any) to ex= isting protocols used by the WG.

-       = ;    Gap analysis of existing protocols and modeli= ng languages

-       = ;   A single, unified, Information Model for expressing= policies to the Flow Based Security Functions described above.<= /p>

-       = ;   Corresponding Data Models (e.g. YANG models) derive= d 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 info= rmation/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 descri= bes the functional components and the I2NSF work items, is to make I2NSF wo= rk more organized.]

 

Suggested Milestones=

  - Use Case Documen= t:  Charter time + 1 month to WG Document

  - Framework: Chart= er time + 4 months to WG Document

  - Requirements for= extensions to protocols:  Charter time + 6 months to WG document<= o:p>

  - Info model: Char= ter time + 7 months to WG Document

  - IANA registry co= nsideration + 10 months to WG Document

  - All Early Drafts= to IESG: 10 months

 

[decision point – &= #43;10 months] 

  - Data Models= : Charter + 9 Months to WG Document

  - Applicability St= atements: 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 SD= Os 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

--_000_4A95BA014132FF49AE685FAB4B9F17F657C14453dfweml701chm_-- From nobody Wed May 13 10:18:37 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8AEF1B30CD; Wed, 13 May 2015 10:18:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eM0rbJs24JMW; Wed, 13 May 2015 10:18:29 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 402FA1B30CA; Wed, 13 May 2015 10:18:28 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BVZ87055; Wed, 13 May 2015 17:18:26 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.218.25.35) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 13 May 2015 18:18:25 +0100 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.83]) by SJCEML702-CHM.china.huawei.com ([169.254.4.88]) with mapi id 14.03.0158.001; Wed, 13 May 2015 10:18:17 -0700 From: John Strassner To: Linda Dunbar , "i2nsf@ietf.org" , Kathleen Moriarty Thread-Topic: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93 Thread-Index: AdCI3eREQdBVQ8yORRe/7nCVEnyK2QEwhD0w Importance: high X-Priority: 1 Date: Wed, 13 May 2015 17:18:16 +0000 Message-ID: References: <4A95BA014132FF49AE685FAB4B9F17F657C11DC6@dfweml701-chm> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657C11DC6@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.47.155.161] Content-Type: multipart/mixed; boundary="_006_B818037A70EDCC4A86113DA25EC02098200B4523SJCEML701CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "i2rs@ietf.org" , "dots@ietf.org" , "netmod@ietf.org" Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93 X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 17:18:35 -0000 --_006_B818037A70EDCC4A86113DA25EC02098200B4523SJCEML701CHMchi_ Content-Type: multipart/related; boundary="_005_B818037A70EDCC4A86113DA25EC02098200B4523SJCEML701CHMchi_"; type="multipart/alternative" --_005_B818037A70EDCC4A86113DA25EC02098200B4523SJCEML701CHMchi_ Content-Type: multipart/alternative; boundary="_000_B818037A70EDCC4A86113DA25EC02098200B4523SJCEML701CHMchi_" --_000_B818037A70EDCC4A86113DA25EC02098200B4523SJCEML701CHMchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Linda, First, thank you for pulling together these changes. The charter developmen= t has progressed nicely. Second, attached is a word document with my edits and suggestions for consi= deration by the working group. Despite the large number of edits and commen= ts, I am very supportive of I2NSF being made a working group, and would lik= e to volunteer to work on its deliverables. My edits and comments are to ad= dress 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 [logo.gif] Futurewei Technologies US R&D Center 2330 Central Expressway Building A, office A2-2143 Santa Clara, California 95050 Office: +1.408.330.4923 Email: john.sc.strassner@huawei.com From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Thursday, May 07, 2015 8:53 AM To: i2nsf@ietf.org; Kathleen Moriarty Cc: i2rs@ietf.org; dots@ietf.org; netmod@ietf.org Subject: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IET= F 93 Thanks to I2NSF contributors for the good progresses made since IETF92 sid= e 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 I= nterface 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 t= he Capability Interface. The thinking logic is: Once the Capability Interfa= ce is completed, we will see more clearly the work for Service interface. E= ven if Capability layer alone is standardized, it is a giant leap forward i= n building blocks for Service Provider to automate their Security Controlle= r that can utilize NSF by multiple vendors Here is the narrower scoped I2NSF charter. Your comments and suggestions ar= e greatly appreciated. CC'ed to DOTS, I2RS, and Netmod groups for wider rev= iew. Enterprises, residential, and mobile customers are increasingly consuming n= etwork functions, especially network security related functions that are no= t 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 i= nterface to express, monitor, and manage security policies to security func= tions deployed at different premises, it becomes virtually impossible for s= ecurity service providers to automate the service offering utilizing securi= ty functions by multiple vendors. The ultimate goal of I2NSF is to enable enterprises to utilize security fun= ctions not hosted on their own premises but instead hosted in service provi= der domain, to establish how to communicate desired security policies to NS= F 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 La= yer) - Security Policies facing clients (I2NSF Service Layer) The I2NSF Capability Layer specifies the functional security policies, whic= h 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 poli= cies 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 represen= ted 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 p= olicies between Controller and NSFs. The capability registry is to make it feasible to categorize network securi= ty functions provided by different vendors based on security policy provisi= oning capability without any need to standardize security functions themsel= ves. Standard provisioning capability interface is an essential building b= lock for Security Service Provider to automate their Security Controllers t= hat can utilize NSF by multiple vendors. This layer will leverage the exist= ing 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 clien= ts and demonstrating the feasibility of them being translated to the Capabi= lity Layer policies. Since different security vendors support different features & functions on = their devices, I2NSF will focus on flow based security functions that provi= de 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 Base= d Security functions include deep packet inspection, packet/flow/stream fil= tering or pattern matching and remediation, etc. Similar to I2RS focusing on the interface to RIB/FIB even though most route= rs 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 I2N= SF interfaces. I2NSF WG Deliverables include: - Use Case document. - Framework Document. - Requirement for extensions (if there are any) to existing protoc= ols 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 ab= ove Information Model. - IANA registry consideration for flow based security function pol= icy provisioning capability. - (Optionally) Applicability Statements on how to use I2RS, Netco= nf, and NETMOD to carry the content of the specified information/data model= s. [The WG may decide that the Use cases, Framework, and Requirement are Infor= mational 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 W= G 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 com= municate with external SDOs like ETSI NFV and will encourage open source co= de development related to the WG scope in organizations like ONF, OpenStack= , ODL, and OpenNFV. Cheers, Linda Dunbar --_000_B818037A70EDCC4A86113DA25EC02098200B4523SJCEML701CHMchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Linda,=

 

First, thank you for p= ulling together these changes. The charter development has progressed nicel= y.

 

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

 

Best regards,

John

 

Dr. John Strassner, Ph.D.<= /p>

CTO, Software Laboratory, CRD

3D"logo=

 

Futurewei Technolog= ies

US R&D Center

2330 Central Expresswa= y
Building A, office A2-2143

Santa Clara, Californi= a   95050

  Office:  +1.408.330.4923

  Email:   john.sc.strassner@huawei.com

 

 

 

From: I2nsf [m= ailto:i2nsf-bounces@ietf.org] On Behalf Of Linda Dunbar
Sent: Thursday, May 07, 2015 8:53 AM
To: i2nsf@ietf.org; Kathleen Moriarty
Cc: i2rs@ietf.org; dots@ietf.org; netmod@ietf.org
Subject: [I2nsf] Further Narrowing the I2NSF scope: the new charter = for IETF 93

 

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

 

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

 

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

 

 

 

Enterprises, residential, and mobile customers are i= ncreasingly consuming network functions, especially network security relate= d functions that are not running on their premises.  In addition, the = European Telecommunications Standards Institute (ETSI) Network Function Virtualization (NFV) initiative creates new manage= ment challenges for security policies to be enforced by distributed, virtua= l, 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 Lay= er)

 

The I2NSF Capability Lay= er specifies the functional security policies, which are translated from th= e client security policies, to security functions. I2NSF will NOT standardi= ze security functions or devices. Instead, I2NSF is only to standardize the policy provisioning to the security funct= ions (not devices), in the form of “Subject – Object – Fu= nction – Action” paradigm. 

 =

The I2NSF Service Layer is for clients to express an= d monitor security policies for their specific flows, which is usually base= d on customers’ logical networks, addresses and context. I2NSF Servic= e Layer can also be security expectation or loose security requirement, especially for customers who don’t ha= ve the security expertise.

 

The concrete work at the L2NSF Capability Layer incl= udes

-  &= nbsp;       The informational & data models for each= category to be represented to virtual or physical network security functio= ns,

-  &= nbsp;       The capability registry (IANA) of policy pro= visioning capability to flow based security function, and

-  &= nbsp;       The proper secure communication channels to = carry the security policies between Controller and NSFs.

The capability registry is to make it feasible to ca= tegorize network security functions provided by different vendors based on = security policy provisioning capability without any need to standardize sec= urity functions themselves.  Standard provisioning capability interface is an essential building block for Secur= ity Service Provider to automate their Security Controllers that can utiliz= e 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. H= owever, I2NSF can have informational drafts showing sample APIs or/and REST= ful interfaces to clients and demonstrating the feasibility of them being translated to the Capability Layer policies.=

 =

Since different security vendors support different f= eatures & functions on their devices, I2NSF will focus on flow based se= curity 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, Authorizat= ion, or Encryption). Exemplar services associated with Flow Based Security = functions include deep packet inspection, packet/flow/stream filtering or p= attern 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 I2NS= F focused functions can be a portion of features supported by vendors’= ; specific devices.

 

It is a non-goal to create new protocols or data mod= eling languages for I2NSF interfaces.

I2NSF WG Deliverables include:

 

-       = ;    Use Case document.

-       = ;   Framework Document.

-       = ;   Requirement for extensions (if there are any) to ex= isting protocols used by the WG.

-       = ;    Gap analysis of existing protocols and modeli= ng languages

-       = ;   A single, unified, Information Model for expressing= policies to the Flow Based Security Functions described above.<= /p>

-       = ;   Corresponding Data Models (e.g. YANG models) derive= d 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 info= rmation/data models.

 

[The W= G may decide that the Use cases, Framework, and Requirement are Information= al 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 W= G Document

  - Requirements for extensions to protocols:&n= bsp; 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]  <= /o:p>

  - Data Models: Charter + 9 Months to= WG Document

  - Applicability Statements: 10 months to WG D= ocument

  - Data Models and Applicability Statements to= IESG  - 16 months

 

The WG will work closely with I2RS, Netconf and Netm= od WGs. The WG will communicate with external SDOs like ETSI NFV and will e= ncourage open source code development related to the WG scope in organizati= ons like ONF, OpenStack, ODL, and OpenNFV.

 

 

Cheers,

Linda Dunbar

--_000_B818037A70EDCC4A86113DA25EC02098200B4523SJCEML701CHMchi_-- --_005_B818037A70EDCC4A86113DA25EC02098200B4523SJCEML701CHMchi_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif"; size=2669; creation-date="Wed, 13 May 2015 17:18:15 GMT"; modification-date="Wed, 13 May 2015 17:18:15 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhMgAyAPf/AO3b2elrUvbKwuNBIPa0g/GUa8WJguZWOfGjk8zMzKguI7Ozs/Hx8e+Pe6ZE OeZcQvvi3f39/eXl5et5YnNzc8lGNvj4+NU5I+6JdfS3qudZPfvl4OSimoyMjOlpTOx3VPSkdvnH lODg4JSUlKOjo/W4rBsbG+jo6NSDe9HR0fOfc9bW1p4uIvPj4f729ODAvP77+rkxJMuVj/749u6N e/nUzVNTU/jOxfGZhNRKOHh4eNnZ2e+Tgfa5ieM/IP3w7sQ0JOhhRuRAKcLCwjs7OzIyMuM8IOVR MelmTPb29uVNMUBAQPKuoQoKCvv7+xQUFCoqKktLS+WNgfr6+vrVxNZ4bvKpmZiYmPW9spcrH++L ZcGAeSMjI+ZRNPjRyPCXhfbBt7u7u/rd1vzq5803JK6urvWuf/nZ0uRGLeM9JfOlefa7mmNjY/fG vei7t9k7Iut3Xvrf2eRKKoaGhuREK/308vT09OVPL+2Gcv3y72xsbPOrnGhoaPrg25ycnP3v7PbF u7RGO6qqqlxcXO23sOZPNPGejfSoefv49t89Ifny8fjKtO2CXupxWO29uLdrY/XBuYGBgfzp4eyB av76+fOzpv75+Pbs6+tzYO3t7fjBjvCYifOwot3d3adLQe2Cbfzs6Prs6/bZ1eA+IeQ9JcbGxu/B u/Onm+S+uuhkR+M/H+VKL+yupeM8IvW7r+x7V/CPaP37+/Gdiex9Z9A5Jfra1O2FbtarpvnTzPfI v+x/WudcP+RHJ9w7IeVLMONDIudfRedXP+RCK//9/PnX0Pzt6v/+/fzu6/KXbvnQv+ZUN/nw7+x2 W967t+6cj+zGwvbQy/Pn5u+HYvfCr/Otl+M+I/OvnuvRzueAcPWwi/vt7PCMZ/zr6OhgQ/a/tvTW 0uNFI7BgV68vI+NEK+NELNxVQOydkelkRPnXyfa8o/vo5P3u5vWpfuZPOfa1kvSwn7pya757c+LG wuXIxf/8/OfNyuzLyPS0qOM7I+pxXvK9tepwT+NAIONCIAAAAP///yH5BAEAAP8ALAAAAAAyADIA QAj/AP8JHEiwoMBh6rydckHQmKRFkiwZM0ixosBin/o1mCHwz4R+/fgZaSVs1YFUoIxN24ZMBYiX KpDBSjawTwA6WIZZvOGDH78BIIPu2iDgSNCQPmjMECZE2DhyaNDMMnaKVCsjRvgdDfCH4KMs4mKQ ufBm1CwBM7B4ABr0C71GIMHAgAvOVZ4DR8FhiFPMSrejIJU0IBjhEoDD367Ze2bKEaFKTBDwqKHT YB1Om5hUKoEFUK4buGr1gQAhDiWLqFOrXm3ChB2BQ/wN+qfD35IRFJ5w2RHF35AkSSwsaTIk0xN/ UCT8u+LPnx6BYaA0icKHjR4GV55YWP0vToB+Poyk/0HTZZcXgTDWqCGgKYQmAocWTeQuEMKdn0cR wNjwHaTIVkKswgQMcKTiwT4IJvjOP9xM4IswaRjhwwANMDRQFVWg9c8xs/ikFWBg4IJXUIZQ0kVQ v0xSBxyABaUMJ/VZ0UglAlFiQBYsKBADEGP1MkpPvtCwwQ8ZBIEBDH0wtEEdtXSBAS6UYAFXiwN4 qIwAFrWwRRZcchkOKsvQJ1Af5uRwAS20kJEDIZZQ1JoEdliwgD98SMDFEicINIc/I/yThAk2dOCP HxEwNwdtTRBhQikMLFGEBHz4Q8I/FlQawQja0UdPJQdUkwYdSvDQpkDHqKAGO2aYscY6YhpkDEcD Df9jC0jhjVfILg3Q848kyIBgRg+a9ACfClQQBAMMqp2hRFBB1CCQLL/QKh6oB9xADw6vMCKNFtxK w0gDYvwDwx7KoJFGK5/kUdEePrEVFBx14KJBUPyER8omlGjQxQEa9NvvYG0EQ8e5WYF0BCgUzcBu u4DJQQwgdwDGwwxyhIeVEZjU0YCEHx51AAQFOSAOj+U4A3KRPgFmxRh/gbQHDC2Dg8MMQbT4yycg tzFJUEcE8E80DmShI48X+OgDMEwUUwMe0fZDwz+y9FMLPRjI0Yc6RvWzyx6gnIEBLy2GpMomBcXy QjwODN1jIj/21EgNuhY0DAwI3DHA3Xh7yA8vASD/EG5Fl8DTJZcshAUEEDmwcgxqxhCDR08+RD7K KIn08sYF+py2Wh2XhNmqQZaEoo3mFXEBRRIClfKEHhIUYYNy/3TwhB8CnVDEEx38s8ITRAi0Ahcm RCKQICZQsBwXTSTfxAkkmLAd8npQQIENztmJp0CC0k4EnZFw4c8CFtjwRBlP8HGCCVEIOmlvg0Si gw6R2OFHpvQNQwwGwbSzCi4EUZIOMuxwBxVI9zmLGOMeXagVGgqBhB8chAq+IkAPeqAqdRWwIgiI lgLLYw2duEANh2BPCEIAn2xI4oK1QIA6BnKMj4BnWoXQADNmYAx0FEAFh0iVGQ6hggLQZCBguEcd /1JDjz2A5A6VmAglZtWPAfgAQOTZhRiGQQ1GaKEAyMhiAWCxjWL9wwV4WIUQ2nEGi7igAR3rxwTU hYWsDQArQligK2Bgi3184BW6yOMrPiALdQkACWK8ygCcRRFAMCwoGrjBP3gADpA4cVr6QcIuunGO c6QiFeeAQw0sIQtfDAwrWklFVwzCCQ+5y2X/sEXTqhQeURUCDb5QQiFm+YA25CEfQoiQhFyEMIOA IhimlJgxZgEYCrmADkbARxrSQAo0uEIdwcBKTwCDgFEJpAWhEEgdOpQywMDBBZNoGki+QAm71csH qwADMXiBH8AcwRWViQMi/hGIGFRACtD4hyV4IP+HbjLLBYwMin5G1I8D1AAMYetHKsDwjz+UgC5B +EfadkSLNwTgHjPoAwZ+ccou/KASjexHBmDgAZCk4hicaNEuOGEMMfAgYiD5xRFS8Y9b4GhkPRpF qCCgDkOcCCRygMAZImatnc3iH4Y4SiPAkAcwTAkwqngAyGrKJbUVrW1waEMdAMGMfvxCDHVoBATo YQhD/OML/TjCF+IACgTMi0o+AcYGCKIIGbCgcDta2yjqFYQ9GAMCGbBQTeYYB1vIAa4eCkAuLIII AMwDFW5whCNMAYnKggELlaAMRergihKAoQ1tyEUuQAsIQAgAFytETT0c4InWeiIQgaiAbHPwhjf/ 0GAMFYGBAIDBDzkoQQldUAa/dvEAYDwAGw7M0lcGlyNxoOAb3PkBFoCRiOpa7nK0YEVlUqMIeRjg EVtoRjQuOANRcABDHBDFdi/IXu7sYAcREEgSEiABJ+ygE06oXQIyMZBOpGA7DEgB7KYgghUwQCAW WAF+/8GAHaTgwU7IxAoE8gTnpc4fbJCACYgAuz316R+RSJ4JGJCEIjRhwnPyRxTyS4HvLaAJXBjB AsoAvuw8zx+tMcFxWHenPP3Dw/8YgT/C8A8TQCECIvAHESxAhCIIwh8dSEETKGCB3uTYyCeY33ZM wIVKWSA2bLAdFBIQ3xaHgXxPeEITTKDkf5QBSjlPEEQE2LDmIuzgH4OQVAScMIX8Ymo7RSDCa/6R gNX9QwR8MEHyijCEFbjOx/9ong4ioIcn2CB1UDDBpASygCWoec0nEEQRthMQADs= --_005_B818037A70EDCC4A86113DA25EC02098200B4523SJCEML701CHMchi_-- --_006_B818037A70EDCC4A86113DA25EC02098200B4523SJCEML701CHMchi_ Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document; name="i2nsf charter-jcs-20150512.docx" Content-Description: i2nsf charter-jcs-20150512.docx Content-Disposition: attachment; filename="i2nsf charter-jcs-20150512.docx"; size=26676; creation-date="Wed, 13 May 2015 04:54:14 GMT"; modification-date="Wed, 13 May 2015 06:46:58 GMT" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQBjgxjKjgEAAKUGAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0 ldtOg0AQhu9NfAeytwa29cIYA/TCw6WaWB9guwwtkT1kZ+nh7R2gJUYttcXekBB2vvn/fydDPFmr MliCw8LohI2jEQtAS5MVep6w9+lTeMsC9EJnojQaErYBZJP08iKebixgQNUaE7bw3t5xjnIBSmBk LGj6khunhKdXN+dWyA8xB349Gt1wabQH7UNfM1gav5AAV2QQvArnn4WiPnxlXEYHlaKDGBGNBfdt Wd05YcLaspDCk26+1Nm3nqHJ80JCZmRVA6KaZp2RgEjOVBntyFc1mafxA+SiKn3wuCZlbRgOSjyu 6dZkRJWNMFwUFns69LvaKtsbTmeuH3NCOB1ZiULv9O/VoSs1A0ex/v8tdeiDItBvSjjDnLTcvvYU 1qszFjlN5OAEoB6/DLKQhtWC8wV087M3fwTvKf1zmN+S/2RfVuiNGpxAiznGv6elA7x5jge3bzB9 fpu9lNMmmopZCYP7/VhMHfqgiBXM3s529V/gfUK64ZfGnRDGbmHW1b9cOW9+MuknAAAA//8DAFBL AwQUAAYACAAAACEAmVV+BQQBAADhAgAACwAIAl9yZWxzLy5yZWxzIKIEAiigAAIAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKySz0rDQBDG74Lv sMy9mbSKiDTpRYTeROIDDLvTJJj9w+5U27d3LYgGatKDx5355pvffOx6c7CDeueYeu8qWBYlKHba m961Fbw2T4t7UEnIGRq84wqOnGBTX1+tX3ggyUOp60NS2cWlCjqR8ICYdMeWUuEDu9zZ+WhJ8jO2 GEi/Ucu4Kss7jL89oB55qq2pIG7NDajmGPLmeW+/2/WaH73eW3ZyZgXyQdgZNosQM1uUPl+jGoot SwXG6+dcTkghFBkb8DzR6nKiv69Fy0KGhFD7yNM8X4opoOXlQPMRjRU/6Xz4aDBHdMp2iub2P2n0 Pom3M/GcNN9IOPqY9ScAAAD//wMAUEsDBBQABgAIAAAAIQBBQiNEGAEAADkEAAAcAAgBd29yZC9f cmVscy9kb2N1bWVudC54bWwucmVscyCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AKyTTU7DMBCF90jcwZo9cVKgIFSnG4TULYQDOMnkR8R2ZE+B3B4TKU0qqrDxxtI8y+99nrF3+2/V sU+0rjVaQBLFwFAXpmx1LeA9e7l5BOZI6lJ2RqOAAR3s0+ur3St2kvwh17S9Y95FOwENUf/EuSsa VNJFpkftdypjlSRf2pr3sviQNfJNHG+5XXpAeubJDqUAeyhvgWVD75P/9zZV1Rb4bIqjQk0XIrhD In8z5z2lrZEETErkOYFfRngIiUC+NTjnjyUf12SNYROSwdHQ+TnOTRjrtfgkZLw+qhytn8NMcJLW ILYhISqjKZN5t5jFSVqDuA8JURj1+1QXo5iUNYS7kAhfmL/9+RULcQLhZx8+/QEAAP//AwBQSwME FAAGAAgAAAAhAAPXirT4IwAAlr8AABEAAAB3b3JkL2RvY3VtZW50LnhtbORd3W7bSJa+X2DfgfDF IgEcW5L/vR020nE8yKA3E7S9M5hZ7AUtlSxOKFJNUlY7V/0Oe7XADjDPMo/STzLfqR9WFYtF02Wp 0cD2RTvWD+v8n++cOlX+5tuflln0wMoqLfK3e+OD0V7E8mkxS/P7t3v/eXv95nwvquoknyVZkbO3 e4+s2vs2/td/+WZzOSum6yXL6wiPyKvLB7y7qOvV5eFhNV2wZVIdFCuW4815US6TGr+W94fLpPyy Xr2ZFstVUqd3aZbWj4eT0eh0Tz6meLu3LvNL+Yg3y3RaFlUxr+krl8V8nk6Z/KG+UQ5ZV3zzSpLM VzwsWQYairxapKtKPW0Z+jSwuFAPeehj4mGZqc9tVkNWm5XJBvpYZoLsTVHOVmUxZVWFV6/Em80T x6O+taUA6RHNN4aQYK+pKFkmad48hqyjpf9GeQdQ3qFY+5AepRmBLGLY0l0xe6Sfq2hzCVuc/fB2 bzR6fzQZnZ3tqZeu2DxZZ7X7zmfjJXpISf/jZnlZrZIp6FqVrGLlA9uLP+Q1K1dlWrFqP8Kr6QwW nCbZfgQbj5YFLJJF03VVF0s4RZSULErzackSknX2GE1hLusl/h3lrAYrX6L5Op9yK9qPvjnEujH9 n5MwYxloT2cgj5hI1vWigLFelQfR74tFHt3UZVJVOSvp3VlSg9DJaHzyZnTyZjy5nYwvT44vR6O/ cAGVUgpXLCNuz84mV9dX/B2scst+8rDLqhWbgj1QTmTJzyoSxSskrTSvJKnjrZHKdWgQWseQZLam 0NISlGLO+QbFBFeHtpzBBKh/Su9KWxWbrkvEHPsZXDJSAJNAAZy8VFc8HLFZv6L6bLuxxDZzWrtH W2PO0VX86tPNdfX6IKIf8JN1NovuWIRINVtPwdbdY4QMEhUlvAxehdcf4HzkY3A84VY9n9qHG8Jz l2yWJmVKzosHMXxzDceu5KLLBGvg+cmjZWDaQrRHHgcK4nS4luN6kdQUQXo9r0+hUV7Ufl2ebI0F R5fdfgdteuQqmIjLdZ5TaCzyqF5wtjujIXJ9UDR8juzTMlzqyBZLShAWs2aM5DkpIJy7DAyUfFTM SaLKTUr1O7maRaU2de3zQHDPF/fkcjxyTJ1TezKeXH93xlNPHcu02fgdt1jh9eTd3Osf0rJeJ1n6 Fb+m+Rw5ry7X03otHKOxEE16n0sc/OPvthFuLoEtCIb+kOT37KZOyloG8ou9Q8oK2ufHoWn4zJHE 1fPS8Mc8SmazlGDCPlfkh3UJcJzk0S3LGDGwztOpAKOABQS3y1kVfcyrOq3XNYtefbi9+fg6+iQx x7XEHNEflWz5d6NXn67/+BpCxkp44QEGA+RSswpgZYOwmCf3jCP26QKQgEFeVQRwHjVJcVVk6RTR NaoLit0sx7syds9SqC29AzGz/UiqdL8BQc0TdA569QDrRDro9UNTdx8QzQVckpor8WsDBj+8P7m4 vuBmV37mFlLe1I8Aa5vLhwSY6L20AjZnJSoYRsqHScnPqnXUu+ZC9CkNH+I/pYBp61pWPSXZLBLP HDjS8jQzHoxDQZNrWE5AiH0O3uclpD/2E6FeJMplAXsoSuGqLR4M5wjFPS4Pz3QOYZf9dqKj2TgU wrh0urIGDKnLImsJybJDE9B2p0k7Pg0La43/NB7YosFQVCh0cQXwTEXBqIgqkEIFR28REYpNXBpd JXFYdV+gacFhBgLVInlIEcaQJHsSoiHBUADiUueVYNxoVEfEGVtlxSOyIGDhLJ3zQFUDCPcK1SA7 FHacD09fsUY+XjWLwIPUn9aQPSIr8oVMCCgz0+WqQGPiDpHZSi1Uf6N3Y+B+mBMwVIG+CeuAi4bH BwEYVM8u364xCZxoGjMW1tnA4+GKGbQ0WOnWswbtFyHgayDtSNOoMKxAMSzaROsajbev1jfNfDYJ BUpDJG6nUU2wNvRJaDp1l/f7p9TaE1bu0b9fcqFZ1CXdsdVuWnQgsYjScu3DCR1BynqKZRShiXcA a/G8LJbWypp+wy5CM9+FNwBen343ut6TZQLPane8dxBmFku0J9MVIt8DOhMFtSXaPK1oqRc3OXld 8+KnPBXlblFwWvSbtdQkKMNPoAifLq5PJqNrSxfdBk8y5jmDaPPqSYfgSVC276SUu6RBZx2jk4wd DbvdhHLCLFzMz3dzZEtZW36f594XSUaA5+MEkCdKecXWUpYhgiDkABGMHWW5IpixeYq+XmKtrpkw qAjK42hEeKiwGhE56p2a5QJ4cBD9GKHVsGSiR8+7gih/qTtFGPEgul1AaBUqPbQpRV96EA9B+Xxy OXG7wzK+H4/fqWZKTu0RvleGPgHKNop81Bx9WrRHQQl7mII9NluxmuwP2xaJIFU0cmmrbiN2TWTV LFoMT1rHUVDSBwvkqfYeCZesZR18F2T+CO3Tpg/VxbTrQ7/9uGaleF2WyfxV2ZKmWjBTJvM0B0G5 H+QfDeDgIPoP3b6RhU7bfKnJIftINmucnQX6Y8SL7CPO0/t1KbpG/XWTduCjIAQABj19T1NFHitr bRoYLSxSYI1WlUctGjUcBaEGsipHLVei62dEdJl/uqlneUJlEFEoP+fWzAadoRnVu0loyFetD6mp 7U/qEYk6gOkGoC5WaethUVRo98l2fooCe5OjfhMlYoRWIOIVPpDM1AfTHE+yy7xohgIvpa4nOlIY JLjL0mqBz2/oBW2wLJphL7bEYg0kbToh+CDlODJi+b17xJ4VenIUK9HqE0EIIR6uXaD9S907YdO0 G0RtyF4VyHr2oG1JLlaTilfZffCG9Eo2LMWPaZGBLNm2HF8fX5xdiU519VW9igqIY7zq63val+UN TvEabIm3NPFTPZXjuC0+2rt3/l/XZZJ/+e9LG6/4G/BHp4ILLuCmEbsF5mmXncKYAD/TLIVZV7A0 vvtQ5NSF4DvN1MFW9m5p16ZZN54bipWKaa/dcKPtdZ7FSqTNBoZvWULdMekguimcQQXVHW/voByd 7U6B3eRhYwK7EtEvP/+f1twvP/+NggVes/SNl1v1lVerio3da5WvpLTqFev57sQa/2mB/Q8+t0Ie 0hMlCQJBrt9GHwEJ0vwLAYNHBSmw+UNfb4JxO6xXFFn/ijEZ/jFLL8McTYlg9yrhKymV7CQUDcgc IaNM267y41ttGpsiypJHmr5Aomw2uGwwZTZ/jgLrnrEH256eT87G7/co9nkmlxC6H1KaSuS7xoaZ JSuMjiTThWVn0C+wSBNK6/iy/babzUN0QivIvLuyth+/x/bo56RM7stktRDuna+XIiun2QMNgvEs Pmre+0i7nfw1nuzBgfwC/mWm9jq+UTNLn9X2LHYjCco37qlh2yvhi++TVSKGK6PvSc+v/z+IQwEB KYMbCUV3LQAeU+r4H3/fuYy7EMKI/0dWRTGODK5lP8O+5PVDBA2Js9o2FYmqmo8L4EPKBtGXauxS Yfj9aLNIpwuRlgAiKwzewq+p68s925Kc2WY8DmxsjL1FkRF5hkqmt8gTRtdf5OkS+jiwy9HBD+9y BHBTx0j8NAHJG3eyI9BSgNXADFmjG93ZhQPsVMZsQz6BPZSJW6wHy6ebdtVwJVhkSUuz4QUXro9S BWN7ifVMM/UeB3ZdMD/c2RgLUWdsd7g1y7p9cRzYZukg80q0WQIIVW0O2RdSv5JsRWDEK5TCDYML 7LqM3T2lLRscwTLskNMuOgVJzAxMMS8GYI4d9oyPcbGZZTRaK88zxG57d4pEQ2aBOypjTxM8QNEe 0Mi75Sh/MBQs5qh9G/tDQ79nHSjGEr1lUYGbLbuXjuxwq4Fr6m7bbGgLMpQduGvT4ddbdhCKxObs j6URzcrznEFHZYVnsFckMPUmzbLo0x9um8lATLRqqNN8nCrjGaNZF385dRxaTu3cg+R8Tnd1sRUJ d4cbCFn0kveltK21TEh4EgoJXdm9ONF084KNRaJ+QPY5CYWDLi/BzhWTXbek/Svjv+e5aLfQedu3 xQY0gBqbDmCdBOLKjqC8I6ORKcVrNNuQkTjIWc4ocPlFFYg3f0VRSQi+JVnFvEptyUMnwJNAYNsh j3AfHbLReRIKZd1g8mIbFwXDlhTU7fBtCzY09pvFpxzGGzDsEFhBzpy7fRANYQzWQsGlZws+BHrH BuiyvEYTDMWrwBsIH8cuwS83Sn7mkHrKvOtREPG7NVGCqE2ZrxHiK9pclxjR7sxaQCcUJO5CdHT+ kpsoL0exaYDtuA752Vtw5mmsU9n5VtDi5dq8Wd/9lU1rUPI/0R/0P6/V2Sh6/R0/mt1BqFA99QLM XTq9E9wm1xO6t3AGSawEeniG155zGooNd6F+2oNdYXtjlt7zOd2duo1zxg/C2fr2zbAOAK2seup8 7wdhrTmSZm8gSYM+O+MTfepzgTMihhkEIteJ2Hnz7wt4Whu632/tn9CIqRXszUh1GgoZ3dFwKUUj LylTQ+CJ1A4PwDITx9t6XVvnzdNQEOdS2I4EHjnOcdUIdaEwyWnJDRYFssiWDB0HIreOHotXfh4Q RR2zXhnyqFTHErRYrJhdr9NAzNXBgiNg3BtxbzataCTTIkTLVFDr4bXJxGpbytaMxU4gzpp4plEN e/bYC4eGNDiL/W0MNM1o5EVusE0jnGrGzJuaWvbwbthTIOjqoP6Z9kROCtCDWcGG9nlWbHAKVWwA DjE1RJp1hQPjGOO6S4QLWRxbegrESB2cOmbnsSKuH3FW+w23Snm1yJuG45L9uMYsI520tluA2k61 rs4C21kdHDxTV/qam19+/t8oK+5xAj1TJ7qhMZxYpwPEoo0JgrsPffZ6HB88xplazOb3zmqZQPFM zj4aInpZCqRY20KdMknLKMwZEz1eO+fRhkuSVfwsfBM8kHiAOuXkdAm5FZUB8g3d72Pgtbl9h2ev 5lqhzaLAuGIOuWPINsE5fatQoBXKGjdQ8MEir+S7gasSn+KYm7XBr8Q9WwCuYiXYNEwA//9VENrL x2VNqVlmd7TDobxmclbGxwhXRxljV7hHAQUhxQtVm6Ju1OWiuhhog5sJeib6vm1FSZNTXdicKT4V QhXXSTXHULZoH3ylLdvHtofiuoM8gWD0ZXB7Bs4m8xNE2H4lH22J2IhRgQCz42DQlbpbpNGJCgHf 0/LqF/q38Dy8QpFMo92zUDzpdgLb4aOOP1oyABESzopEEPPzaM6okJzHdtKhGzRa9dPn0rBPZbLP Lap2NqoHDcgRv+b+tLNQICwuF+D2bZ0QcIdHIHM5IAjNQya0wSHuyXvunUSdB9OufPbn95WhdhmK S4fY5bvcMkyd8x0T7ubD9m3Hro2jea11DCWEolGXP68S4oRv1mHRADzWolxHjPNQFOo2mwaKWxxv 5FUPH0TDJRIWdVoBBpWBLbGJ8C0TCDpUxhTv2QrnSCSEw3giiplKXsaUfuU9Y6QA4wwa2qANLFQ1 ZScT5LG0+lbObO96/rgJagFh6DwUqrsa8nvAvyXL1b+TnL1OYJhMYGtqkMm8g/rpqFmnznl29o7V 2sZuJu/zUCThaVUZ2N/Tevjzu0+/s+nRziezunHM12LWIjwUdQwgHLfNzHDTyoM5NJzc4Q4goGi4 Ke4DaI5M71sEtjkZEvvtPQGzSDiXJ9pgeDLvnoc2ilymvQbfTTNFJ4ZzEBgLrNl9UT5xw2t3NaAY 2n21KFaCOrhFGQIMxQQvFiAabJimbI6Di5bb0LASmuldqp1M1K1u0T8TR4rp4h8kInGvW6s5Sgd6 AjxAXuBkf9X07otQhOAZlDXDUow+0WEv0TGMfbV4rMwWlc69TalsPcOiPhQ5DKC+W1/Uv4V5yaZg /6gu7tH0Ux6YUY88lnZ8NjkH2iM04kkH1NS0yFExFD+fQjEyhslFECP5Ztlvr17T8eciECBI+YbW axeBWb5DrbbMSbHgjoqDbsPkvQ19PKxk93Sz52P06uO7T+9eU/jgUPZRTIKqaYmp/gYMm3r6sjnf AGDlhPqeSUkG7w4i6sN88MqwXqEo+3/zZqRx5kUg+AkyI55CM9yj+wPumcJx39lnXOz6Ha56/cLN sUfxmIBBb1lETmpxNReGYJuSzl7nLONXCU2TEiZBWabRrypwENXqDWOtbU2uW4mJLgJbIEfeIsAI Wr22/V7c35mBRWlu3UWyobdA/NZBK0/kBqXijgKjXJTnrl5ZwRUxtSyK+YeSIFj9uMIfAcAZ0iVH nbIjrcIodcKs5xf86sjmjIPnUej9PvGg7kBBlyfwK1baI0oWWDQJ8jzH4lclk/7ySG1LG7wZOguE jEN01s2C0/ptcxHTpVIWnxb6CESL4QTDSQkXCuPrzub9Cmht13Wmfql6ZZ5PxWz74/yPdhjGI7sa Kb8EOmNz/J0PQE4ez7Y+qvPDYEDCI21PPDXSYpNIvWYwHgVi6I6k7wSbbsNV9YJFkzZe7VPjUSBC PvIgZEO1HvmRUyHnlMkUd7QAg6RTcYWYMV5qlyPddO8QH5NXD5BcKIIcILmYZ2OzjsBsBK/45B2T b3K2xp+Rwd9wKqbJ3TprX0aoZYbEKfPzeBQKPl2Kr8RmgaHt3gSN2Q7Ax2XyBY2bOprTn9WhK7Lw GslZflUBRn8fZjw6sVOal4xYdkfoyIPzN2AUZOWRu7W4IEei6UZwocjGLca8FHc7cpd8NIndzZ1G SmCt4SAU77iqNxsXMge4TG1vO1lyA6Z5UFYgxF0S3HLUx6e95d+g0LfkyqtZm9GiFsD1lj0d9qnl 35cmItq2pyvJrEhiwoPxKBTQeJRieKMn9oo9DrWlQeDFJg+sITe0rT8Qxhy7h/P9WkvyRzgqb8Z1 ifyfAgAAAP//3FzbcttGEv2VKT1s2WVZoiiSsrkxqmRdHG0ljkrUVmp3Kw8QOBRRBgEGACXTT/mH fdo3f4s/JV+yp+dCzgADCppQdip+kC1eMD19Od19psf3wzFPgu/uh3FaMPwcv9k5OOjs4J/hopxm +Zud03yP/SObpmxU5mFRpDynd8dhyd/sdDsH/Zed/suD7nW3O+x1hp3Ov3foaTk+khfx+OrNTqfT O+q+etURr5dBOeWzgid3vGBl9t3+/bAM6GcufkII8W36UbKPs2RYzMMIC81zXvD8ju8EzPqOLffB 08ntFuaG2+JgI9YWgqIM03GYj+NPfIPc3aeTOxhb664FhNlX9j7c2vqnPKlYHOtc849Nxix4tMjj cskmizQq4wxOSPKqL2nPuB9G2WzG0/IqTG/5qAzzciV7b2ffdLhGAQzHc6wg16QHmSudpeOmdaqO nV/Cg+HGo3KZcHzpLoQiTpTUfMJznkacRMVK6rN6Jf2uvRR9TjyRfjSob499+QxtCA+zHdGOi76n fQ9axHOcljyfIEgLNslyNsvSuMzyOL1lkItFWVrmWZLQ74h8dsOn4V2Mz2UT9n50XrAwtwMD21YR BB9YaWSwtQ00+8c8z+7iAi5IskbhPLyJE/LM1QZZDHHTjc4jLNZgLMaLAi4chwm7WcTJmJa5SbLo Az1xBYK24Y62tu+qv5ZBYa271vvGPZCJRzpmR0DkOOLskjQ35rn1QHsjrzw30m3hgV4bKTOGBJfN kMY2Rc7rp5PbnVEoSBYFp/gYxxOBG6WMlEmezdhskZTxHAhzx9NxlhfsZmmL386OWCU2DNlsuK5v KdDGcLMwDW854XpFgByB76we3DqzNXA/RCRnk7OcnlIu56geijlPEpE27GRRDwoK0DLmTS5lYFLX t9ioa6YZk04UfHJYupyGJXApZYsSwPSJk1eQ+asuQbqEnJR0df6UrzycTSpm0AmqlnS7XalHt6KR NZWaN6Su6ynQNAmXHFaKk4Ql/I7n8AaRJfjHuCgJH7FAmUVZQsA7Zqg5QyQYbK5gYz6JUz4mBVx0 r0a7j/cBIVzwnpfIUZPKzlttLNgVUr0/u/7xp9PKA0zVGVWEVlyTg2+xipBLwfJGFRHsWWLizTlp YW6G28lht3Mk8o6IwFM+CYE5VNTZ71waL4kK7A8/5SH/PEfuIXi86JLn6+TzA/nQLotLSs/ZoiTk pE8VUTbnoiSRn3+G6El4WJTitTS7f47+gxn1ufjWOtmjpBGFQBIDE4o99n12Ty66q5anQEQpw1Ee ICcijaBwQGYf5+GkLFgxze7p20U4I7C2tG4lxq5v6d1zJ8b+oHty9mpnQ+AZQVQJGriD3bwcX17Y QGiL3tuB33h0iS1ED3YtlVUla5cGTLD2rYDrsiqwNhStwTbL90lq/Sv9G7EnX1n7dgAkszZnK9W3 0q0LKpKbIWYZ7Gd2ieanVhParFase7QpK5jpV7hncHU2up4skooyWkFvgwOsold2kav819jVaZEt PDZ0tk08FtqRPqFAuaFRACxFEnVk1uPoqQpwLyIjErRNAGOx6k4k2s3QWBHe4FNpkaCmHRO40WdP 1o2MQEo2z5I4QoWzZ6MSBNtOLiDbzlUzLP9C/gZyq5a4I/6Qo5Aq6AO0sv5bfPmPZqN1rLndZBSj FTeq6xUHoWvqYjGfZ6AY1gU4NF4uQEHZOrMj17fFGTyM5DXMgM7qXXLXt1mpS9AMcn9DRvs72ewB mHOr3qB5spT8E13ImFMTWejEKqrBSRYtkM1TNkmy+wpAYOPwEEFUHnp2J/0jt87Pjo9OB29l9gxe Wus6NX7o2QM41lcaNyRQCm5QpLcJbsIC6LDy+TXvJvoLoC+18gASeDx1ZlWPh1Qr7XvSlv1XNe0/ cvfAto37N13Es8ByCCkSqmGgMsiqfYOVR8yPbrDiKkutXQyo2Mj5gQ//wMtinyIDQVMsoikLC3Zx Odq/OEUf9DO/YZM4ASkn2xP6nHqhAvkihlfG9KrmDofdRmP2ev3jw1MRTMqVg2cOq9m52SooDvuq j1QZQXlJ/cFu7V5PuSRH9PK0ukw4eIVUbJYyRpdWXVfSBOvtbLEqkEtJuWx7eBWCj7OHW21gZM3M R6xTBqTOXZihve8YZ0VEnUSiD9pl9DtI4E/qV6T/szTKl3Pqkp5LN2w0yibnP/vI0VCFJIugHsEL FEUWxaLiuY/L6Sa48iJTD4eH/Sa4qjticO7wcFhX+Zu7tjUqYxO4vOoJp7hV/y0DG7eqwBPUky42 sEIKrzLDKdipOi1ah5byCrdntgb9nldd4BSxrrsbMrEDtA0V9bzqAuf6jSoK3m50NRlFASV7S14U 2052tBVpV40uw117XsUAtlwvPusqt1mItbuaKvfK8871m1U+aqNyfTqyrqzQbyQLFFVjzudM5m/Q RiClxYnnrnpJZPR9NHo8nKmEjZauYjxT454Zu5XGRe1gre3WuhevAq3XC/BGrTdggeQy4AGPJ7qh 8BL1UcpA20VT6puJXbZ22xQmBlarCMtxgDFGAkJmqzzB9E7PbP4YPYGOBpdNMngppVYcbsQJrPIQ XaAMenbSf30uUkZ7PlnQABaHYOrSN4+/Fnncj3lQm1EZX9WjV63I8c2b8c3yMoAcm7GrWque7r2W 9bShzL5vpnxEAAejeBZT0Ya2jc5qQMCju6ewkxyAccKOT1xdvN0/v3jLQLYTQ5Atbqc48wFtn4Pc p3Mw+KVoUSd44ixDsboGWrSwqX7ArqC/JPcvFkTXu/4k0fcY3glBh+UUunRqsCJ5FP8jT5cUKfT7 b/9jhNjxJI40ZbG3MdgamgttBKtVNCrJLTYXcimEqmx6Wgbs1n2871sNNfp4C/TxjU0jwfZ9S5pG oNnM+16II6yQpVn68jbDYRKiISIehrOU3xtnoWin1qc4FEcJTmgXODyVIzjS59dceAXZncprRmn7 nac89Quk4D+/Y0DbmI6DbxJsSVVPQyu7OjdhH1C284DtHV0q0ntuTYD9gIPsyxAH23k4n0r0TRcz mdri5I6aKjEp1lm9d0EjZ+K1A3oNG1VfoC2rnLiBHvry+Z+YHjlB3c/GgFmi8NrY30d1RmL7apsO zvNwxu+z/AM71dt7Gsf4Frtzl7pX/NdFTGUm2Fiav8JgB09pUK1gz2Jx2I0kSKxNmC7FobZjfAIj RWJWAjQN+/ndX8ojvnx+F86x9zBZFjQCMIGCnOMjYnLEgkvLc6zTnL5nO9k0Aq1QdEPgCtPKCmMJ IXdZzsXQM1g1+u3XBc/l6+sJS0nwmiOWK1pfn/JZOwSCIL2RDGaW82wje/U5JtG4mzutz5uI9bcG 3n+eGD1mVNAmfJctUpSIfIzjrPVgCPuRhpZU8JJVRfWrbUR53rKTRQT3PVvsXn14VzUxhoUgVfNw NmEFyaU+JHKRrCTxStWLPBtch5R1L1IeL7p05e0VfVnFtLG/hhN2W93rsMC+NMvZ9+wyHRs6lSyn IZbW6Ga22AxSzzbRIU1dvY8mg03BPMngVoK1OIEdePavjvUbzeTOyq1DY+DZ/jhErNuuBRk98Gxj HOs3qqgVGe3WoziOroQz4kPH4cA3ET8C/oLVRPu5voXSFvcGvtmzLl7duHRBwtKME6kG3yxBgAcp ojy+QWkZ3mR34iKHhjaS20oWii4VnIl5evIQK9GujfvzVAInWY4EP89SccHDMp9Vdw2eMGO6I+1f x+/fNWU+aR33905p7FpUMLX5JzNQv0LCdMv3jO/d7jGxOzkc/nwzNitPxIUVkAwgBemEm2od4cP1 su3RHmujJIDMi/h+spYa8kgawTSeb30hm4DH0dCDOg195JvG602IrX3CBexTnBFdHL8/Rld1i+Yw X9LNNNxPBckk6F/qq8WkTMN4lBybXEryuX5JTPiIXqcGfQ1MsNZDU/G6RSZYLrWC5L8a5n75/Own MVsSJgkokOP5HDOu+v4ejkBKQZ6IgUIM5lO/RVes/hT3RgTJG+ZwSIIg6m6I5tF3GOSBA0DKuGWw v+Z+i0djU7tsuj1SVGCtduRz7I5mN8MiiuM3O9fxDPTue1DbV7iHl+7gnekxgtL5TlTUXxZiPjBd TKMa/6lkYVOoFl+/FpwZDouXKHgiMR1JV7HIXsS1RqhgMYi3IiYlK2OSdsTNGWwAmH1NzcIlMcsU Y6ZpCWQSt/2iNXGLW064HE1j3VgqiSe8hMa0b4DFq2zLwPMj356jfo2gjqfKnA9qTuGhO2m7UjQy k8qW9UXVwwIyxkRzwHTGB0voMpTuyK2PA6FmAC8KMQSUvD9G78ozBkEgx4AFGA6cIQBhFn6w3hQn i1l+G6a4ajfejO+P9KdfLLsBlLcDx9sLWjNfWQfIR+ren9hwgrtUVzxFCuXjSxw+vcVR1QchRBmM Frc4jaJrCD/GOMMpYQS7k7FPqY3Zy9USum6ia2YGdaKxxDplOfG6Zy+XeoKkKNRTBl8+s5cCIcRp jD6uGOLlkyn+BwNMVIp4fsEO6NY8ZhfhhnT4pc41nsZLqCAy5VvB1rAqVU9KJaLjq4tlwKc81DQO PaAmzACU4l6oQ5sDW24NtV9HnQTzWB9oVdPnkS2Xr5ltaNRR8scnUY58iRY5HovAp0iizoIQrdZh HPkSJY3TtwYo6OQgIm5TmY9Y6zSbQT9G7ETsA6/I/Qh+QSvbuPmqX2qt/2Zs1cPutJQCj2NcjD4L cxQHp/JeKVz/4mz0brjehuXWzaiqH67lfUJUFUttGVW3l9sU9lVLwtqwGw7sZ/VhP6r/qPuraN35 7XYTtfMMgxrs99/+y16sXPMX+LG1AkXU1jxwhf5fPr9kBrezBqwX7DX4HmSkb4P9Te2b4fXfJFUa uhJHUU1yknAUpZYJYcHq3LXbxQjD2nyznXsd6GxoPXJr/rTtuHT3ClTzowIRNwNF5R4lWcH/DwAA //+sVE1v2zAM/SuEz0HrZFk3BI1PSYMCW1LUxXpWJdoWKouCxDRNf/1oJe2yw4Ch7cXghx75RD7Z 7WFnuYPryW09gsvz3Yyr4Rury90sRKJmGSNIdB9wXqSAztWsIhfnw4F8iqs1sibf/Bd66c0pFp57 N0tBaakeIiaMT1hUoLz5AJmezCdyuV+lM7jrEO5XMivnQFPfb73VivEwPHxmjF45qBebBM4+Iizv 6mtYX/3KN8ko9Jq2UbUIFNBDEkej1DIIBp/QUejRM0R0UtcAE/ChZ9ICAOuBYqu8fVFsyR/bbNZX 797aRmjILvXj581qBJvFj9FHtjeQkrG9h1J19hdKRByyiEW9MVlzOy/Kcjoel+VF8RpaYKO2jk8y WdYJNd8Mqv8Hrpb8CSZ3aesXAezmxXgymZZDh07sr9/FzjVD+1Plh0RB4tPDkWjbTiq9ug/ETP0f 32Fzku1QGYzz4tskl2+IRHVvbrvl7B7baXJJOBxf1gDJLAzpVbRGMs56vLGsheWXi5yVgR0unn8A D2T22RDIdlBm9RsAAP//AwBQSwMEFAAGAAgAAAAhANmE+NlTCgAAVCYAABEAAAB3b3JkL2NvbW1l bnRzLnhtbOxY227bRhB9L9B/WPDJBnSh5IscNZKh2DWQomkDx0WAvq2WS3FrcpfdXUrWm/+hTwXa n/OX9MySlOzUCCwDaYMgL7pwuTPDmTNzzvLl6U2Rs6W0Thk9iQa9OGJSC5MovZhEv1xddE8i5jzX Cc+NlpNoLV10Ov32m5ersTBFIbV3DCa0Gy+xmnlfjvt9JzJZcNczpdRYTI0tuMdfu+gX3F5XZRd7 S+7VXOXKr/vDOD6OGjNmElVWjxsT3UIJa5xJPW0ZmzRVQjZf7Q77FL/1znMjKoo5eOxbmSMGo12m StdaK55rDY+YtUaWH3uIZZG3963Kp3hLLF+hHkVeh70yNimtEdI5XD2vFzcWB/HHfDcJJBObHU8J 4aHPNpKCK70xQ+j4oP6b4vVQvH7tu0+mtg+CXEy3WGKrsUom0YsIP3jlM4Pantse+8Fkmr3zljun paXVhHv4G8aDo2581B0Mr4YH48PjcRz/SqtKK6947ibRb8IFByWuAuTJ5SSK4+/Pjl5cBCfh0rlM eZX7eysUUvnWhq93fp1L7F7yfBKd1Zi/kjc+6k9f9je3hXttvcU+tuVSptKitWSzr7mXa218QCFu qC3Wpsi3n/5kPEOdAVk8DvOG+UwykXHrpe2Rex+CwBYKJXwi1QTxf2f1AD22e1qHY2T2aWk9Ggwv Xo3IyYdpbVY+m7TOFlbKXdMXnmxXVH6R6TtXjlMGe+wqU44VfM1UUeZrxpnIFcDXddKCVFjJLU/U oviOrSRzmanyhAHvbC5ZrgrlZVJjWrmdwQxe+grmMCO21biUpbEg5CbTyDJNjnZsOCkqC7pFvTRf SBoSzK2dl8WuyT+GSvikyT8+GY4GZ49Nkmbls5kkF8o632GvWWL03e2fSHam9DU+ub+HeVdKoVL0 h14zIm0QStsaPXZhLJM3HA0kO7RnBZ5gxqqF0jxHUyXKiSpwPVPaU3fNuUPnlCZXQkmHTZkSGSII vaU0W0iwJPhCGE3aq+2xez7fSawlHWbAJ9s2dWxP9ha9Dvv+bLbPOMIoDD5KK0F+BBfYrpzEYyTM Sie5FVmYARamFJZdE4GvwL9LieDNfKlM5RAiEkLklai0IUK6fS79SkrN7m7/uqi0IDV2d/t3cIBL s82Fu9s/yHnKBZINM0hlWcI/PRpgToYdL+SuQB4NngnkwydS4mh0OJg9SonNymcD5C2CK53gPECa H3lFjWiGkHDpsR/NQgnCZIcJXvKg3gHALVL43EGkCao012ADogEIdra3/Wnl75UCeMKqZyZ9YGq/ w+ZVDRTSiWgVQokpS+PAFi2Qdy7zwdcyB1Xpp4GwkdJVtsbQomZGnxUGehlTiEqOueCtyakLlQY5 8IRqVFPGrnk/eabiPBh8ce31HvnGgMZ415JUDxrrdEcBOoiPngfjg9EXl87ttHJSssys6lGVybx0 YCR+3XACyVLZsisBmQs6N7co76EHBCZVIlOlwWssW8+tCoi/fDU7Cw0xox97DnI1r/nm7ZvZGdiR 6FOlNe3V1J8r9AuuBptBDNRtg3tO2c+W6o+lTIprNgfxsgcuiMVBhDWLBtrdo3bMEe1+PU5JUzyG GRz82iMXHWE/FeX46XvicD43GNCc5YYnECI514KmdIqZvgI1/K8BXkEGUBHYwoBgjH5sXv1X2aLX WWNXcoHXFBBQ4UAUTd+QnoJmIcFSGsi5DnswBXB0vl/Lw9Hw5CSOSCT4aSBjAjRRLhmQNwQ4MHMA NjAqC9XdZ6QcMWH4jdGmgAJLQcON8k8bjYUeeZ0SqiBSOYzZCtITJjUAuj088Dl6B8FuumPTBK1t qMtGQvp1SSlvmSIcLjbeOmwtPaQhWizETG2Hp2l1cv1gJAYFJ0aqewC22jNi5cN7wieUs0lYm8O3 eH8Uxx9cvPe6515+n/G6x29q/A8AAAD//9xY3XLiNhR+lTNcJyzhJz90ocOG0NKLNBPo7EzvhC2D GltyJRnHvcprdKa97YPlSfod26Shy04I04ukMx6wJUtI5/s5R8hBI7XSSbuWjeF8JSlfmVhSapT2 ZCL6+CHv+yF/2uHHzcdNea8+VO3Vkx8GIhULFSuvpNs1zNN9EvddKoKtHyW3Mlkc0kKSNxTKSGlJ QpO891I7tcBqEhPKmPxKeJJaoMXhQWLESqyVsbxOfo4yHXhlNHoNTxdKF1i1kCEpTeKLrRC241R4 e2MHjVare9Y+P281yk3u3p+TZUQWmYpDpZe0iE1w95qdHtH1j/P/Zi1e3BttkmJnnIfNrWZgl5ZI BSZJpAaaeb++RQhUOGicnHQbuBWZXxkEY2yb9INZaZp5K5zT0nJvKDxwa7dOeset3vFJe95u97sn /VbrZ+5VGriL2A0avwSujGKK1jK+z6K7aRrLSGSxf9bDi0qruKczXwD0vL8W8aBxWS16Djo0KsLV r1V8rIbYXUNuZSSt1IGsx9nqXaG18YJ5ghdqCj9R20MDyhEupxIVC8tUyhzDPanZJWL6VCLPSM4K 52VCY+nUUr867O32gWHv/O/CPp3Q7KebEUfeZ1aXmkXoBX3+7ojFrUl5CkqjyDxM5je4BSS/lGCn CuBXsQoKiqxIZG7sHVsCz/d6SM4OhKS3JyS90/bl1Tn/SCmOZ0qoe96KEna79TSiXIL5oL0IyaUy UJECWp5lI3BpGi0cfCPwNBZe0LxIZY0gBuaMoH58+N0TvLt0fMBlCxILk/kS0lBFtW7h4T6XgJ4n vZniK+RbZCZpI2SR5heWzrFzRYLgRkbDXj5DuOzVjuMdrATMbdLqjjaGULriS97Y6R3CiE6/sy8j ut3eqDPexYi6560wYvj48Md8JYvHhz9ZpyJZqGVmMnfEwLNwIUiHBMOe26Rr48lllisK5O3CZCTw 4G3BZgppO4GJ/nptpupeHIjGxZ76fA9obMyD8+fVZe9iclFm3K8UWAyElb9mykKnEcolQSwFiKhJ t9NPpawm/A14AgPsUp+JOC5oo0TWJXSH63o2+QbDeVQ5Dw9jJmB+ZzIbsCkDbDRt4YrUbo2JrqzF yj0MYdCAc8TxzGMZLEaY4df2NHSZDPea7UqHL8y129KqshPhSLjyLNkK90J9wB1e3MG+8pVCRVIF oNowV8wKNN9a2R6V1umB/O3um/JrPmzCWRW3/2p8lnSe0ectlF+7EZp6SkQB4w8lKIzKXqQgVGoV SlIGqSo+cQ+EpqPrEdX4MdmtXCokK8uuswUWOFcSb3ex/+JhZnhEC2SsKYWGUFCC+ErfVfQvc6HG UjcHkX/SJEpGdskn/cFOoTpWnoixSM0bykXhuH4JcQaDUyKxvpplZwcVlp1+d9+c9W4INfzepDLK 2M5KWOo0FSnrPK0lajDoHMFm5hyPkclQYzCceC5JtgbhQhNkfHD6llD9OIOX4rg+czqcMoEZLBAQ eoOCdbmEFzq1lltk28MZzg6sM7qne2a294MZ9I7gS2G5pkA+gWQQaA4x/hwQXPyHjJZrlvKrykkn Ja1M/oRyaoAC/ip4STtApj4Mu+HfAAAA//8DAFBLAwQUAAYACAAAACEAlrWt4pYGAABQGwAAFQAA AHdvcmQvdGhlbWUvdGhlbWUxLnhtbOxZT2/bNhS/D9h3IHRvYyd2Ggd1itixmy1NG8Ruhx5piZbY UKJA0kl9G9rjgAHDumGHFdhth2FbgRbYpfs02TpsHdCvsEdSksVYXpI22IqtPiQS+eP7/x4fqavX 7scMHRIhKU/aXv1yzUMk8XlAk7Dt3R72L615SCqcBJjxhLS9KZHetY3337uK11VEYoJgfSLXcduL lErXl5akD8NYXuYpSWBuzEWMFbyKcCkQ+AjoxmxpuVZbXYoxTTyU4BjI3hqPqU/QUJP0NnLiPQav iZJ6wGdioEkTZ4XBBgd1jZBT2WUCHWLW9oBPwI+G5L7yEMNSwUTbq5mft7RxdQmvZ4uYWrC2tK5v ftm6bEFwsGx4inBUMK33G60rWwV9A2BqHtfr9bq9ekHPALDvg6ZWljLNRn+t3slplkD2cZ52t9as NVx8if7KnMytTqfTbGWyWKIGZB8bc/i12mpjc9nBG5DFN+fwjc5mt7vq4A3I4lfn8P0rrdWGizeg iNHkYA6tHdrvZ9QLyJiz7Ur4GsDXahl8hoJoKKJLsxjzRC2KtRjf46IPAA1kWNEEqWlKxtiHKO7i eCQo1gzwOsGlGTvky7khzQtJX9BUtb0PUwwZMaP36vn3r54/RccPnh0/+On44cPjBz9aQs6qbZyE 5VUvv/3sz8cfoz+efvPy0RfVeFnG//rDJ7/8/Hk1ENJnJs6LL5/89uzJi68+/f27RxXwTYFHZfiQ xkSim+QI7fMYFDNWcSUnI3G+FcMI0/KKzSSUOMGaSwX9nooc9M0pZpl3HDk6xLXgHQHlowp4fXLP EXgQiYmiFZx3otgB7nLOOlxUWmFH8yqZeThJwmrmYlLG7WN8WMW7ixPHv71JCnUzD0tH8W5EHDH3 GE4UDklCFNJz/ICQCu3uUurYdZf6gks+VuguRR1MK00ypCMnmmaLtmkMfplW6Qz+dmyzewd1OKvS eoscukjICswqhB8S5pjxOp4oHFeRHOKYlQ1+A6uoSsjBVPhlXE8q8HRIGEe9gEhZteaWAH1LTt/B ULEq3b7LprGLFIoeVNG8gTkvI7f4QTfCcVqFHdAkKmM/kAcQohjtcVUF3+Vuhuh38ANOFrr7DiWO u0+vBrdp6Ig0CxA9MxHal1CqnQoc0+TvyjGjUI9tDFxcOYYC+OLrxxWR9bYW4k3Yk6oyYftE+V2E O1l0u1wE9O2vuVt4kuwRCPP5jeddyX1Xcr3/fMldlM9nLbSz2gplV/cNtik2LXK8sEMeU8YGasrI DWmaZAn7RNCHQb3OnA5JcWJKI3jM6rqDCwU2a5Dg6iOqokGEU2iw654mEsqMdChRyiUc7MxwJW2N hyZd2WNhUx8YbD2QWO3ywA6v6OH8XFCQMbtNaA6fOaMVTeCszFauZERB7ddhVtdCnZlb3YhmSp3D rVAZfDivGgwW1oQGBEHbAlZehfO5Zg0HE8xIoO1u997cLcYLF+kiGeGAZD7Ses/7qG6clMeKuQmA 2KnwkT7knWK1EreWJvsG3M7ipDK7xgJ2uffexEt5BM+8pPP2RDqypJycLEFHba/VXG56yMdp2xvD mRYe4xS8LnXPh1kIF0O+EjbsT01mk+Uzb7ZyxdwkqMM1hbX7nMJOHUiFVFtYRjY0zFQWAizRnKz8 y00w60UpYCP9NaRYWYNg+NekADu6riXjMfFV2dmlEW07+5qVUj5RRAyi4AiN2ETsY3C/DlXQJ6AS riZMRdAvcI+mrW2m3OKcJV359srg7DhmaYSzcqtTNM9kCzd5XMhg3krigW6Vshvlzq+KSfkLUqUc xv8zVfR+AjcFK4H2gA/XuAIjna9tjwsVcahCaUT9voDGwdQOiBa4i4VpCCq4TDb/BTnU/23OWRom reHAp/ZpiASF/UhFgpA9KEsm+k4hVs/2LkuSZYRMRJXElakVe0QOCRvqGriq93YPRRDqpppkZcDg Tsaf+55l0CjUTU4535waUuy9Ngf+6c7HJjMo5dZh09Dk9i9ErNhV7XqzPN97y4roiVmb1cizApiV toJWlvavKcI5t1pbseY0Xm7mwoEX5zWGwaIhSuG+B+k/sP9R4TP7ZUJvqEO+D7UVwYcGTQzCBqL6 km08kC6QdnAEjZMdtMGkSVnTZq2Ttlq+WV9wp1vwPWFsLdlZ/H1OYxfNmcvOycWLNHZmYcfWdmyh qcGzJ1MUhsb5QcY4xnzSKn914qN74OgtuN+fMCVNMME3JYGh9RyYPIDktxzN0o2/AAAA//8DAFBL AwQUAAYACAAAACEAVPDOsgMNAACoOAAAEQAAAHdvcmQvc2V0dGluZ3MueG1snFvZbiPHFX0PkH8Q 9JwZ1b4IloNas8BODMv+gJbU0hBDsgmSM/Lk63NaFC0PctowgnkYqm9X9a27L3W/+esvm/XF53F/ WE3bm0v5XlxejNv76WG1fbq5/Pmn/i5cXhyOw/ZhWE/b8ebyy3i4/Ou3f/7TN8/Xh/F4xGuHC2yx PVxPN5ef9tvrw/2HcTMc3m1W9/vpMD0e391Pm+vp8XF1P77+d/m6Yn9z+eF43F1fXb0uej/txi12 e5z2m+F4eD/tn65OK+t0/2kzbo9XSgh3tR/XwxEIHz6sdofzbpv/dzd86sN5k8+/d4jPm/X5vWcp fu/N1+M+T/uHX1f8EfTmBbv9dD8eDqDsZn067mZYbc/bHNZ/ZJ8TPb9b3e2H/ZffbPIt2Pafadpc PF/vxv09CAqeK3F5NQMepn9Nx7o67NbDlx+GpzFPn8D2/Wo8vICB1/R4exyOI1YfduN6/SIj9+tx AHbP10/7YbMZwNPTk5c1x/1w//HH8fNqFq/TNg/j4/BpffxpuLs9Tjus+zzgSP6MxP2HAWuO4/52 N9zjA2XaHvfT+vzeC45l2uz2INEJbYjXbji+fA5S/HCYjzL/+HGajudlQhSthPenFTP0DSKEkFVS iBTFL0CMWIAoIbulu2mpvOYQVapZgLTQOMToznHTxluOgVFWZrqbU7UFDtEicay9l43vFnXvfE20 qkb6neS0dRSSXXCcc0VUuwAx2XBI1bp0+p1qoqkc4lLmuzWdu6JrumiZ8lQKV1tia6TSWdDvSGVz 5RCts+Pf0bZ0eh5pQDcqIdI4HwvFDZKj+G5W1kIlUVqFE/HdVBdUDqQzIfHzeNUap4E30lPplZDR QvVHBuG5VMkghebnCaZqTreoeuU8jbo6vlsSNVJJlMkZxemWhQ6cC9mIxKmTbVmgTnbVUemVRSTL MSimcUshi03ciskqsCGVgypC5vyBZkcuIdUlwbldwW5OnSaDXoIkbkdlQ6zBMWgqak63Zjy3sLLB 8nE56E5zXwKPpTl/lBSB64KSMmfKOaWkLdQqQ0udpdRRCjylMqq0EFxClFEi8+8Y5QO1LsoYz7kA SOvULygsUZQ/yiqh+Hesc4FKonKyZ77GKdOo1iunIpc3QDqXeOW0NlR6lTNFUV1QzgnuS5QHuznn gi6R2gM1QxbWmF6pXKvgKpdrFZXhvkRFSC//ToGt4LgVEwqnTrExUv1R1RrJJQTWLVOrrKoLie6m hZKKrgHEZqoLGh6dUweQ1vlu0iRPJVFLh3/MWiKETYGeVCsdE+UcgkGlqVRpawyXN2198FQXYI5s pjqnvXKCYxDgazkkKWs5RZPy3C/ooqTj5ylGcs+kq+5RU4pW4+wCxGMZXdNsWaBBc1FwbjcHmae7 deEiX9Ot4dGTESoZupsRzgiKtZESmTPDwEgLw0MhainaMPAlXOeMUplbPqO0llTrjXLNUzkwGhkY tb1G6wV7bYzI3tDzGAO/ySE28fjAWNcqp5tzPVJJNF5YHsNCGU2lNhGQwD2TCUJoztMgY+LnCabF TE8aTSqcC8h+DLVIBnqqOH+SSYZD5piPU6fCVnEMqukLuCFfiVwOmmieWiTTdeb5qRXSdrrGStV5 pmelr1zrEWxEQXlqNWoBVE+ttr1TGljtBbfK8HKdS4i1YiEetU4VbhOts8VRu2Odl4pKlfU62gUI QqQFiEXIwyTReucstTs2CK2oBtugvaFSBUhPnAvBxsbXROd5Tcgmlw2XkCJap1qC4Lpb/h1kRoHv 1nThHtAJt5DTOnCH89QhwOcajL2yoRR1SiBlYfwBpPHswynZeBXHaWES1VOnZeb1nRnCPaBDpCyo FUPGJHge7KxQPEd3UG6ezwGiF+hmZQlUeiG6zlG/MEO45XPWdUl1zvnZp1MuoEqROA2CrJ3aXheQ F1C744JXlkqviybzqpSLrvHo1iUpub12WSJroucpKvGIyxUXeVbg4Et4pueq0TzudRUmnp+0+uao rXLNFJ7Tuo7iCqW1F9pwj+EhVJlqFiJymyhu4E7kOQbCa28pRb3yKdLzeG00z5m8UQs5kze+cf3x 1iEBYTz1Tlhu37yTUVE/551FmER38wIGgUOULFTnvFeV1zo9aoM82oDpX4IEaAPndoDscC4g8g+c 21F7Ltc+ic5tok/GJepLfIL9r5Q6yQde9fBZ9MZxy9prail81n2BBhVpPV/TEPxzznWdPOdct3qB p8h/eIzku8OJKA06pJRaS6SgNVDPhGADlXK2GwrB2VCsg5KRx2IBWU7ka9BI4RFKgKHgOhe0VQtY G9F5lBaQSnCpCg6+nloKNFgar/uHKBO3vSHOLQFKN9RnF05adFmAVFW5noZqC48TQxNBUC0JkERu 40MzmVvL0JwvVHpDV91Q7xyFqbz/E6WQvH4NSOC5cwTOnHMwISA3o3U0VvEKYDQu8ywnWlF5nSJa ExXlabToQFEtgdNe8M7RiaSo3YlzyEX1NEJ4G/+OtypS2xtR0eSeKUIZuN0BZCHjj9EIXh+NEahx rJNRhWMNS84rWRG5M48gAWlKU24nW3k/GCk1AgS6JovAawEx+8Q7ArFYyXuhEZLDM4lYZeVVw1hN 5X1NQBqvlMTqnOG0bmKhfhAbInwuIQ0BPpfEZuWCNnYruQ9OAo6B0joJXT21FFAEwSU+aRE7PWnS xvBeQbLSauplkkN0SU+avEJfkUlI8jrx/gIgleclCHY6t28pysjrbwlRlaf2OkF/eDSYgDO3/qkI w6v7qUgXOEWLjFJRGhRleZ0PKoL4lq/Rjcd8qZjMs4JUbeW2KjVRuQanZlugfjsL9PLpedAodpLK QUaNy1I/l6VOnG4ZmTP3mhl8k3w33Hbh1jJrpxuN/bORgVdkACmexr0I0QLvxmYrRaJakuE0NdWF 7CTaH4zbuGaxcN8lw/IunBTXKXimlwM6KVRGM3IMQX1Jxo0BXi3KyUbeZ8q4B8Nj2Fx0XeBcMZ37 rFy8WvhOlYFXi3JVIXNuV58Tl52Grh7nQp/DJ8qfjltUCxCbuIUtAt0KygVAOu87F2EXpBdBSHb0 pGVuBPLvIKfmEl+QlfC+MwwSirSMBij/1UjtQTGoDdKYoqCPzuuWCAI0j9YRkAebKAbWGh4nFidz oTpXnOmOWtjitZIca496FZWd4lHB4GuCKAtygNNwy1ei64FTtKBXQPW0AMJz2tLg0TluyFx5dbJ0 VDco3SoiCo5BFabwWLmi28dv6VSJ20DUWla0XHnVvSpfuAbjml2rlKfVeMSDTHaqFQt3cQDpvG5Z rQ48CwWkcMtXoT28J1Fxn4Jzu3qdeZ0cEPSX6XkCtITagxqc5fpT0UviWVuNEmUh+p2ocK+SQ9AR pnanJqW4RaoJBXnOn4y7IxwD3D7j0XqFE17AYHa1XN6y07zHUqvDdV160orrYvykiP0XuNBw8Yqf tC/VLWt3jVfZmnAL93ub1Oi+M6wbboHwTkqT3vKIqylUi/huWi1YvoYmP69fN1y75ZUFFDozj4ib hx2lnGseUQC1ic0jGKMxbPPosFO/3dCt4DcGGgovPGtruInJ6/4tIsegEtISXC2Vg5Z81AtrfOVy 3RBcco8OiFvg9hw6cOoU3O+lfq7BcfPaeisWDKLyhltU3Lq0giCW6jauP3ie8bdmXeLc7sYtSEi3 IALDrYOl3I52ie/Q83QUi3idr+M6kqTnAaTymnfXqnAf3FE+4PfFOtr/vAuHgwqem6Hov3DTojtZ +d1JXBLtvDfV4cy4VHVc0Oedu45+I+dPx2a8k48wBJE85VyQntfs+lzs5JxLtvGea0eqx28hdtwO 1ByDJhd8cEdVt1Fb1WHGGo3FOnIMHo925Bg8d8bAw0LdsiO6PsWWV6fBFEyobK7noaMf9udfHVMu F5vTKEwZNnf71XDx/TyWhLGWzfXd/mNebc/wuxHjUeNvIbef7s7Ad+9OgMNmWK87JmnOAEwknSAP GPCp4+PLxuvvh/3T284vTmVzvadPMbfzz193myeHxv3f9tOn3WnX5/2w+8f2AY/PH5S4h3WCrbbH 71ab8/PDp7vb86otppN+A8K40b8/7+dFV28Eer4+YqBsnCn03bB9Os/tjNt3P9/Orz5f36/3t/PQ 2fj9sNthZAiv3D3Jm8v16unDUc6jSUf8hUmmjy9/3D2pV5h6geGvGfbyx3A/nwxvv/6YXzj9xFuv P96e6fMz/fbMnJ+Zt2f2/My+PXPnZ25+9uELxrEwT/URw13nn/Pzx2m9np7Hh7+fH95c/s+jExEO H4bdCL7Os1UQsOn65cHrsNXh4vP1+AtmvcaH1RHzfLvVw2b45eZSiVNg9Po25r6mT8ev3p13ml/e ffX04mE4Dpgce2HVV4vBOgyHfY0LJsvG+xUE8vbL5u5tlOv9CfH16nC8HXeY+jpOexz5ZRzsLy87 v40YfvtfAAAA//8DAFBLAwQUAAYACAAAACEAA1BAKn4BAABuBwAAFAAAAHdvcmQvd2ViU2V0dGlu Z3MueG1s7FVLT8JAEL6b+B+avUtfpEBDISEEL/iIovel3dJNdnea3aUVfr1DQQX1YBNNPHDqvPvN fO3McPwihVMxbTiohPgdjzhMpZBxtUrI02J21SeOsVRlVIBiCdkwQ8ajy4thHdds+cisxUjjYBVl Yp2Qwtoydl2TFkxS04GSKfTloCW1qOqVC3nOUzaFdC2Zsm7geZGrmaAWEZiCl4YcqtU/qVaDzkoN KTMGgUixrycpV2SEGDNemcPTqWOeYYthEIZR5Pca/xKyzZRX6KuoQCdxd9GS6jnL7ZvVe7c+8FXx jXkB5dfYCVgL8pMd8UwyvXuH/chROFmCgWabEJw/CiVNcdaNnIIAnCtdW9jDEEfI2mUuTxC1y9XH nbdJdRsSmqb34ikdQdgd9EIvGpzpaPMR/BUdfhRFnh/0g/DMx3/gI8B11Q1Dzzuvq1ZL8jf/j/3a as4IlJZLvmUz0BMNtWG6uRd4vjZ36vlm3mhUCKjvb69RwdSjKzl6BQAA//8DAFBLAwQUAAYACAAA ACEAekoIgM8IAADWRAAADwAAAHdvcmQvc3R5bGVzLnhtbLxb33ObOBB+v5n7Hxjee0mcNr526nZa p7l2pk1/OJl7lrEcc8HIB7hJ+tffagUCA4LdQO4pBaT9tLufvlVS7eu399vI+ymTNFTxzD/549j3 ZByoVRjfzPzrq4tnf/pemol4JSIVy5n/IFP/7Zvff3t99yrNHiKZemAgTl8lM3+TZbtXR0dpsJFb kf6hdjKGb2uVbEUGj8nNkVqvw0Ceq2C/lXF2NDk+PjtKZCQyAE834S71c2t3FGt3KlntEhXINIXV biNjbyvC2H8Dy1up4FyuxT7KUv2YfEvyx/wJf1yoOEu9u1ciDcLwChYOLm7DWCUf38Vp6MMXKdLs XRqK1o8bPar1S5BmFWvvw1XoH2nE9BfY/CmimT+ZFG/megUH7yIR3xTvZPzselFdycy3r5Zgd+aL 5NninTZ2hG4WPyvu7g6chydcyk4EEDjAEetMQgIhHxonCnWiJ9Oz4uHHPoIXYp+pHAQNAFjVLDzW Ig55hSwvDEvgq1x/VsGtXC0y+DDzEQteXn/6loQqCbOHmf/ypcaElwu5DT+Gq5XUpMzfXcebcCX/ 3sj4OpWr8v33C6RYbjFQ+ziD5Z9NkQVRuvpwH8idphiYjoXO8KWeEGmzaQUHF7QPy9WYFzVUfPlv AXlictiKspFCbyMP198JhF7vBwNNtEdVB9Aua62nw008H27ixXATSN5hsZgOXwWI59CMGG5UWElP aqYCQ75qHE5fdlBWz2iwqHdGgzS9Mxoc6Z3RoETvjAYDemc0Et47o5Hf3hmNdHbOCAQKV51FpxgN 0sa+CrNI6vmdAnQyUOryUuN9E4m4ScRu4+nCWl92l1gu9suMtlSU08eL5SJLVHzTGxGoznrrPlqT P2x3G5GGcKLpCf1kYOivxDKS3l9JuOqFemHI1/AJDyatJexbJAK5UdFKJt6VvDcZZcy/VN7CnDJ6 FzcwrZ/Dm03mLTZYcnvBzhxBd0fC2P8cphiDzs105nClzzgph2cOXrqNf5GrcL8tQkM4jZwZPWek uQaBS+wO0XOdoubu6vVCJ4DigikXfBfQPmH9prjw7escU9ZvStEj7RPWbwrXI+0jP7rzy1aac5Hc eqTtNWXv3bmKVLLeR8Ue6JWHKXsHWwiaC+xNbO2TRGLK3sEH8um9CwL4zY3CU3YuSh1loLDTYVBw s9F9YSelJnsnDI/YCaphTRhYw7SWAcQW3R/yZ6j/8MQtBqjS9qzZu51PHRGAEkQ6Q3/fq6z/DD1x aB4V5VMMfy5JpUdDO3XsPCpazidT7xg5Hlb4GEDDKiADaFgpZAA5+OE+89iaSAcZXhwZWGxZtlUM aUdW5ilbmS0QrwSMVDcJ5y/H7nVzoVk3CSjsBDXrJgGFnZ1aLbN1k4A1Wt0kYDmqhjtHVU3lOMWu m1UgexIgeDSOeBOAxhFvAtA44k0AGi7e/SDjiTcBi60NVlOr4k0AwiGcX/UtUFW8CUBsbTBql//N qKh7aKX7l9sRxJuAwk5QU7wJKOzsuMSbgIVDOEyoYVmpI2CNI94EoHHEmwA0jngTgMYRbwLQOOJN ABou3v0g44k3AYutDVZTq+JNAGLLgwWqijcBCIdwtKFVvHHXP7l4E1DYCWqKNwGFnZ2aoNpDKgGL naAalhVvAhYO4ZAhx0Jyc5waR7wJHo0j3gSgccSbADSOeBOAhot3P8h44k3AYmuD1dSqeBOA2PJg gariTQBia0OreONmfHLxJqCwE9QUbwIKOzs1QbU6R8BiJ6iGZcWbgIV8GSzeBCAc8lggjkfjiDfB o3HEmwA0jngTgIaLdz/IeOJNwGJrg9XUqngTgNjyYIGq4k0AYmtDq3jjHnly8SagsBPUFG8CCjs7 NUG14k3AYieohmWljoA1jngTgJCYg8WbAIRDHgGEu4iTpnHEm+DROOJNABou3v0g44k3AYutDVZT q+JNAGLLgwWqijcBiK0N+p4t3BclX089cZCAes+guNVABpw4kkQFzB38IdcygU4m2X87ZCBg4SED 0UEPqovvlbr1aBe7Tx0EIUOFyyhUeKX7AW/pVBoRTqcdnQRXX+feR9MA05iHlDq8eQPdQ9V2IWxP 0o1DsM7sYQctO7viZrm2Bg1Cuq8rbwHCPrRP0BCUt/XoybrPBwZiU1X+Gv/fNkfFf0PP26oYc3w8 P50cT3OPXA1S+B8/eXvUc/vQ3h6Vt2LBj4Mes5k/F1G4TELtR9FbNvMX4Xaxx3tQ2FJ2MCpI7Xfz f8+mOayc/GvzbH6Zt2ZBmxv2f2FQmmEMNhDHALq9OsKYX+a396vwKn89qI4b/7jAst2kCG9+8788 H5pxB/dP4RWwwLHuTN9y71gz3oLvzL+HQwxjmwuExjNcUt8K7Y0xHJ0tI9NKB//4FGsyQeMi8sKQ dnUvjFn4PpdR9EVg412mdu6hkVxn5uvJMVb6mqmlyjK1dc9P8CI8rqTNAIS4uhjz2M2ZeL9dygQ6 2Trif6l0hcSOu8OtZ+70mnRb7YDV486kRt3NiwNZsEKg12Lp21gU1vLyM65tKaCl8KvuEGxIRpMs cJ8QJ7HEJER+6OzO/Ck0fYAFcKvopHTQ/mC7Wvfmaqv7Z8uCU9+cIo4VNFnqlsfE1sE2P1u3Og5s ek1NFijegbBOp5Pzi3MTMVQn2OS2CfbkzHxIf5VNsOYdBKdHy9pznwcHu1U64pLpbpa2kFSrBUj9 bUGJit05iKiZ+z9FydBFx62MkqVQT5QOKBTsUxCPha6s9eJZ968eu/w7tgF5ZQRqG8dNKEcsmXHs pdbo1bbkqjsL+vCCjdSPqsmdPIbj7D8yaCprZYun+ZA2NleyaiIdA+9bKG0+tuQoxy8T/qSUXxof 5in87BcAJrWrrrjYnY9xE7wS0DIm7riNTW9egNqZ9V5EkVJxq0Lm30yzXxuhXPJYMVrG5Um5Ut/p V2KjtkKfUfIjdPlCn6DzJ/Sp3NND6g+VfvXQ1LlXjbmbeDRlrWCNTT13vEvVa/waMywHPF0tTonp m/8AAAD//wMAUEsDBBQABgAIAAAAIQAQLL6n9gAAAGwBAAATAAgBZG9jUHJvcHMvY3VzdG9tLnht bCCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJyQy26DMBBF95X6D5b3jo0DJSBD 1ECy7iLt3jKGIOGHbIcWVf33GqWPfZYzd3TmzLD9h5rALJ0fja5gsiEQSC1MN+qhgq/nE9pB4APX HZ+MlhVcpIf7+vGBvThjpQuj9CAitK/gJQRbYuzFRSruNzHWMemNUzzE0g3Y9P0oZGvEVUkdMCXk CYurD0Yh+4eDN145h3uRnRGrnX87Lzbq1uwHvoBehbGr4GebNW2bkQzRY9GghCQHVGyLHJEdIfRA m1PxfPyCwK7DFALNVTzd9xMfIm0O5WTffXB1km6TtKB5mjP832X4d1/N8Cpye1P9DQAA//8DAFBL AwQUAAYACAAAACEAoog5JmABAACmAgAAEQAIAWRvY1Byb3BzL2NvcmUueG1sIKIEASigAAEAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjJJda8IwGIXvB/sPJfdtWr82QlthEy/GhIGOjd2F5FXD mg+SzOq/X9pqVebF7pKe8z6c96T5dC+raAfWCa0KlCUpikAxzYXaFOh9NY8fUeQ8VZxWWkGBDuDQ tLy/y5khTFt4s9qA9QJcFEjKEWYKtPXeEIwd24KkLgkOFcS1tpL6cLUbbCj7phvAgzSdYAmecuop boCx6YnoiOSsR5ofW7UAzjBUIEF5h7Mkw2evByvdzYFWuXBK4Q8m7HSMe8nmrBN7996J3ljXdVIP 2xghf4Y/F6/LdtVYqKYrBqjMOSNe+ArKHJ+P4cQsUK9tObNJ9KK3Klp6S51TYFvjSW76rajzi/AU awH86XBz4q+rGbSwE82Dlg85vryGUG0HXQjgUdiKdB2clI/h82w1R+UgzcZxOo6z4SodkfGApOlX E/Bqvtmy+yCPMf9JnJDR5Jp4AoS6QuLrP6v8BQAA//8DAFBLAwQUAAYACAAAACEAAsiKd0cDAABS DgAAEgAAAHdvcmQvbnVtYmVyaW5nLnhtbKxXS27bMBDdF+gdDAJd2pJlyXaMKEGaxECLNi2K9AC0 RMdE+RFI2o7P0GXv0Rv0Nu09OqQ+UeLUsBpuoohv5s284Ygcn57fc9bbEKWpFCkaDkLUIyKTORV3 Kfp6O+9PUU8bLHLMpCAp2hGNzs9evzrdzsSaL4gCwx5wCD3bALwyppgFgc5WhGM9kAURAC6l4tjA q7oLOFbf1kU/k7zAhi4oo2YXRGE4RhWNTNFaiVlF0ec0U1LLpbEuM7lc0oxUj9pDHRO39LyS2ZoT YVzEQBEGOUihV7TQNRv/XzaQuKpJNodEbDir7bbFMdFyhbdQZ87KtLdS5YWSGdEaVq9KsGEchodi VwW0FI3HMSk8jllnwjEVDY1tjyf732zeADYvKGMHlupBCNTiDJoJL7RRODM3a9579PYuT1HoTISm OWAbzFIURfMoicNLFFhnvmaGfiAbwm53BaltVruFovlHizGLlbaGF6y2mI+T6+j6bVQibGMBCg8b Ef41BctSNBlHl/N5Epc5rPmcm9p/sWaMmMb7ltw3UL9ZfZ/V5owsK+Pis7J5U2EF2eUUxYmLucLi zn17o3FoKYLtrDJWpY+aS2E0uGGdUZqiS8wo6LT5EqzNhaY4RX9+fv/964ddW11A2R5ZZTpFt5QT 3bsh294XyTFsIRhSAVnkZImhYFVkFxIygJLYdNsFGj4UKIzDkzAMR65AcFaopgjDsghwULSKlpOM clztBlC2q/YmGhxTNwPdYhOCJ2TuGgJi2IwKCeqGcVzXrrZsV9rBVvE/Sv284GhPcOJD8MiH4GjY NMtzgh3cWfBoT/DQh+DYi+Dp9NAORxbuLDjeE+ylpRMfguE0OCTYwZ0FJ3uCvbT02IfgeBQdEuzg zoJhxqhP9erQ8tLSEx+CE8ioOnaf+4Yd3FnwZE+wl5aeehE8OXhoJRbuLBim1Sc77KWlT3wIHscH Dy0HHyEYrqfWsGSvQbj7wA/+2lmp7OiWxTs7Y7g70vWXu8Y/wcQPs5Edlep5xw1ScB3vQa1PpIU5 Qne/l9dlDVVzQv3aBIge7o4W1pWl1b0vYClHOTepvICl1VgvYBl7qcvEC8u0IwvsPDSdm1HhWf4W PPsLAAD//wMAUEsDBBQABgAIAAAAIQD3hgv5XQIAAEAIAAASAAAAd29yZC9mb250VGFibGUueG1s tJVNjtowFID3lXqHyPtOnPDTDJowmqHDchYdRl2b4BBLsR3ZhnTO0GXv0Rv0Nu09+hw7YRqgQNUm Eojn5PH8+fPzze1nXgZbqjSTIkXRFUYBFZlcMbFO0fNi/i5BgTZErEgpBU3RC9Xodvr2zU09yaUw OoD3hZ6oFBXGVJMw1FlBOdFXsqICxnKpODHwU61Dmecsox9ktuFUmDDGeBwqWhID/60LVmnks9Xn ZKulWlVKZlRrKJaXLh8nTKCpry6oJ4JwqHpGSrZUrBmoiJCaRjC2JWWKcIzneASf9h7igf1Eoc2Q FURparoHsQvnhLPypY3qmmntBipmsqKNb4liZFlSN6TZGgY2eolT9IDhiudz5CJRioYQuJt1kRiK clfknxl0EVgeKKzJ0zwSXTd5IAJ5/FtNnaFbnz0SP799+fH9awOClOYR6LQVLxinOnikdfBRciIu YEA2Rh5AsKI52ZRmn0BXZ0egF9kRaOYL3I4TgFc9kzMJ9OdpEe07EeMxuDACI6wbg4ucUDt+FzgR 33UGwExmMK/3ybA1YEfk+rQTLs/5Tjwx/rRxu6bnhLel2Q77jCJghIFN1N4HnUnGLvz7vjnizPFt 4xUZ+OkDojhJ5jbqIx2iaHwCkd1vDdjzES1IAYt6pH/cAwfbOawtw//fPyJoHw99V8Z4dN8HEZ9y BRbuUlc+Qa+1h4M+yGLkV+nV10EncPwvnWgNACeATXP1UXSWHGwkyau3zndiRjicKceksI3DKWEb yWWHyt81kP1DBQ87Tbrd8WcSDYjTh4o/XfT0FwAAAP//AwBQSwMEFAAGAAgAAAAhAMMMd/z3AQAA +gMAABAACAFkb2NQcm9wcy9hcHAueG1sIKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAnFPLbtswELwX6D8IOjeW5MZJYNAMCgeFD2ljwEpy3lIriShFEiTtxv36LqVYkdOeqtM+BrPD 3RG7felUckDnpdGrtJjlaYJamErqZpU+ll8vbtLEB9AVKKNxlR7Rp7f84we2dcaiCxJ9QhTar9I2 BLvMMi9a7MDPqK2pUxvXQaDUNZmpaynwzoh9hzpk8zy/yvAloK6wurAjYTowLg/hf0krI6I+/1Qe LQnmrMTOKgjIv0c5imVjgZUmgCplh7woLqkxpmwLDXpesGwI2LNxFeXFgmBDzNYtOBCB9sevFjdU nxTYF2uVFBBotfybFM54U4fkoV9CEglYNoUwWswOxd7JcOQ5y6Ypu5eatMTJQ0TiHDQObEuKFlHi mLKdAIVrej+vQXlk2VuBbRDibbcgSTI7hOUBRTAu8fI3XXeeJj/AY9zaKj2Ak6ADbS/ChqSPlfXB 8VIGRdzUG/I+nMKmsbyMeyQsBefAWBw0UONcXT/BP9T0tvAPscVUbK9hkDqRMwnHGe9Y16azoI98 s4dfKJMSRauNMk009trMPt2HakZnfUXFO/z0j7Y0d9FNr/s9L05M8SxDu7Mg6HTX1/PPU3tMWmxH LsKK7n0ifCuwDd3CqTiVrKUbrE6YvxvRcE/Dr8yL+Synr3fYqUYuGf8x/gcAAP//AwBQSwECLQAU AAYACAAAACEAY4MYyo4BAAClBgAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnht bFBLAQItABQABgAIAAAAIQCZVX4FBAEAAOECAAALAAAAAAAAAAAAAAAAAMcDAABfcmVscy8ucmVs c1BLAQItABQABgAIAAAAIQBBQiNEGAEAADkEAAAcAAAAAAAAAAAAAAAAAPwGAAB3b3JkL19yZWxz L2RvY3VtZW50LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAAPXirT4IwAAlr8AABEAAAAAAAAAAAAA AAAAVgkAAHdvcmQvZG9jdW1lbnQueG1sUEsBAi0AFAAGAAgAAAAhANmE+NlTCgAAVCYAABEAAAAA AAAAAAAAAAAAfS0AAHdvcmQvY29tbWVudHMueG1sUEsBAi0AFAAGAAgAAAAhAJa1reKWBgAAUBsA ABUAAAAAAAAAAAAAAAAA/zcAAHdvcmQvdGhlbWUvdGhlbWUxLnhtbFBLAQItABQABgAIAAAAIQBU 8M6yAw0AAKg4AAARAAAAAAAAAAAAAAAAAMg+AAB3b3JkL3NldHRpbmdzLnhtbFBLAQItABQABgAI AAAAIQADUEAqfgEAAG4HAAAUAAAAAAAAAAAAAAAAAPpLAAB3b3JkL3dlYlNldHRpbmdzLnhtbFBL AQItABQABgAIAAAAIQB6SgiAzwgAANZEAAAPAAAAAAAAAAAAAAAAAKpNAAB3b3JkL3N0eWxlcy54 bWxQSwECLQAUAAYACAAAACEAECy+p/YAAABsAQAAEwAAAAAAAAAAAAAAAACmVgAAZG9jUHJvcHMv Y3VzdG9tLnhtbFBLAQItABQABgAIAAAAIQCiiDkmYAEAAKYCAAARAAAAAAAAAAAAAAAAANVYAABk b2NQcm9wcy9jb3JlLnhtbFBLAQItABQABgAIAAAAIQACyIp3RwMAAFIOAAASAAAAAAAAAAAAAAAA AGxbAAB3b3JkL251bWJlcmluZy54bWxQSwECLQAUAAYACAAAACEA94YL+V0CAABACAAAEgAAAAAA AAAAAAAAAADjXgAAd29yZC9mb250VGFibGUueG1sUEsBAi0AFAAGAAgAAAAhAMMMd/z3AQAA+gMA ABAAAAAAAAAAAAAAAAAAcGEAAGRvY1Byb3BzL2FwcC54bWxQSwUGAAAAAA4ADgCBAwAAnWQAAAAA --_006_B818037A70EDCC4A86113DA25EC02098200B4523SJCEML701CHMchi_-- From nobody Wed May 13 13:15:25 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58FCA1ACE4A for ; Wed, 13 May 2015 13:15:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kt1ZY61Pc3m6 for ; Wed, 13 May 2015 13:15:23 -0700 (PDT) Received: from mail.rozanak.com (mail.rozanak.com [IPv6:2a01:238:42ad:1500:aa19:4238:e48f:61cf]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 579861ACE53 for ; Wed, 13 May 2015 13:15:23 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id 0B48D25CA284 for ; Wed, 13 May 2015 20:15:21 +0000 (UTC) X-Virus-Scanned: amavisd-new at rozanak.com Received: from mail.rozanak.com ([127.0.0.1]) by localhost (mail.iknowlaws.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6W_-UZ5ax0h1 for ; Wed, 13 May 2015 22:15:19 +0200 (CEST) Received: from kopoli (p5B341B03.dip0.t-ipconnect.de [91.52.27.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id B5C9E25CA072 for ; Wed, 13 May 2015 22:15:19 +0200 (CEST) From: "Hosnieh Rafiee" To: Date: Wed, 13 May 2015 22:15:17 +0200 Message-ID: <00a801d08db9$8919a5d0$9b4cf170$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdCNuYd1I6wWEMDQTdCBeM+dl8v0bA== Content-Language: en-us Archived-At: Subject: [I2nsf] gap analysis X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 20:15:24 -0000 Hi Linda and All, I would like to start the revision of gap analysis. Shall I consider the recent charter for this? Thanks, Best, Hosnieh From nobody Wed May 13 14:45:49 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DCF11AD0C9; Wed, 13 May 2015 14:37:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3pSg3MP4uKk3; Wed, 13 May 2015 14:37:42 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64FBA1AD0CA; Wed, 13 May 2015 14:37:39 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id D565519; Wed, 13 May 2015 23:37:37 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id WZY8lSeXizdW; Wed, 13 May 2015 23:37:29 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 13 May 2015 23:37:37 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 49B0F2002B; Wed, 13 May 2015 23:37:37 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id IhtJzKnap8i8; Wed, 13 May 2015 23:37:36 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1B2C920013; Wed, 13 May 2015 23:37:34 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 88009333336F; Wed, 13 May 2015 23:37:33 +0200 (CEST) Date: Wed, 13 May 2015 23:37:33 +0200 From: Juergen Schoenwaelder To: John Strassner Message-ID: <20150513213733.GA629@elstar.local> Mail-Followup-To: John Strassner , Linda Dunbar , "i2nsf@ietf.org" , Kathleen Moriarty , "i2rs@ietf.org" , "dots@ietf.org" , "netmod@ietf.org" References: <4A95BA014132FF49AE685FAB4B9F17F657C11DC6@dfweml701-chm> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: X-Mailman-Approved-At: Wed, 13 May 2015 14:45:47 -0700 Cc: "i2rs@ietf.org" , "netmod@ietf.org" , "i2nsf@ietf.org" , "dots@ietf.org" , Linda Dunbar , Kathleen Moriarty Subject: Re: [I2nsf] [netmod] Further Narrowing the I2NSF scope: the new charter for IETF 93 X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 21:37:44 -0000 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 From nobody Wed May 13 15:06:12 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 698BB1B3174 for ; Wed, 13 May 2015 15:06:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZCm7tGcxDtAg for ; Wed, 13 May 2015 15:05:59 -0700 (PDT) Received: from smtptc.telefonica.com (smtptc.telefonica.com [195.76.34.108]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 799F51B3173 for ; Wed, 13 May 2015 15:05:58 -0700 (PDT) Received: from smtptc.telefonica.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id DFE418816D; Thu, 14 May 2015 00:05:55 +0200 (CEST) Received: from ESTGVMSP103.EUROPE.telefonica.corp (unknown [10.92.4.9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtptc.telefonica.com (Postfix) with ESMTPS id C402F8813D; Thu, 14 May 2015 00:05:55 +0200 (CEST) Received: from emea01-db3-obe.outbound.protection.outlook.com (10.92.5.139) by tls.telefonica.com (10.92.6.50) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 14 May 2015 00:05:55 +0200 Received: from DB4PR06MB0621.eurprd06.prod.outlook.com (25.161.13.139) by DB4PR06MB0687.eurprd06.prod.outlook.com (25.161.14.11) with Microsoft SMTP Server (TLS) id 15.1.160.19; Wed, 13 May 2015 22:05:54 +0000 Received: from DB4PR06MB0624.eurprd06.prod.outlook.com (25.161.13.142) by DB4PR06MB0621.eurprd06.prod.outlook.com (25.161.13.139) with Microsoft SMTP Server (TLS) id 15.1.166.22; Wed, 13 May 2015 22:05:53 +0000 Received: from DB4PR06MB0624.eurprd06.prod.outlook.com ([25.161.13.142]) by DB4PR06MB0624.eurprd06.prod.outlook.com ([25.161.13.142]) with mapi id 15.01.0160.009; Wed, 13 May 2015 22:05:53 +0000 From: DIEGO LOPEZ GARCIA To: John Strassner Thread-Topic: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93 Thread-Index: AdCI3eREQdBVQ8yORRe/7nCVEnyK2QEwhD0wAApA4QA= Importance: high X-Priority: 1 Date: Wed, 13 May 2015 22:05:52 +0000 Message-ID: <3AF7BE6A-DD17-4C1C-9F31-42C6D2AB99B5@telefonica.com> References: <4A95BA014132FF49AE685FAB4B9F17F657C11DC6@dfweml701-chm> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: huawei.com; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [83.51.62.246] x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:DB4PR06MB0621; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:DB4PR06MB0687; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:DB4PR06MB0621; BCL:0; PCL:0; RULEID:; SRVR:DB4PR06MB0621; x-forefront-prvs: 0575F81B58 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(252514010)(24454002)(43234003)(377454003)(83716003)(2900100001)(2950100001)(15975445007)(102836002)(19617315012)(62966003)(77156002)(82746002)(40100003)(122556002)(110136002)(19580405001)(19580395003)(5001960100002)(36756003)(92566002)(189998001)(87936001)(2656002)(16236675004)(5890100001)(81686999)(50986999)(54356999)(76176999)(66066001)(86362001)(46102003)(33656002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR06MB0621; H:DB4PR06MB0624.eurprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_3AF7BE6ADD174C1C9F3142C6D2AB99B5telefonicacom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 May 2015 22:05:52.1066 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR06MB0621 X-OriginatorOrg: telefonica.com X-TM-AS-MML: No Archived-At: Cc: "i2nsf@ietf.org" , Kathleen Moriarty , Linda Dunbar Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93 X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 22:06:08 -0000 --_000_3AF7BE6ADD174C1C9F3142C6D2AB99B5telefonicacom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable 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 th= e term "policy" in the document. The text talks about policy at two many la= yers and can become misleading and difficult to be understood by the commun= ity. I'd leave the primary goal definition as: "The primary goal of I2NSF is to define an extensible framework for managin= g 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 furth= er development for a later stage. Be goode, On 13 May 2015, at 19:18 , John Strassner > wrote: Dear Linda, First, thank you for pulling together these changes. The charter developmen= t has progressed nicely. Second, attached is a word document with my edits and suggestions for consi= deration by the working group. Despite the large number of edits and commen= ts, I am very supportive of I2NSF being made a working group, and would lik= e to volunteer to work on its deliverables. My edits and comments are to ad= dress 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: john.sc.strassner@huawei.com From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Thursday, May 07, 2015 8:53 AM To: i2nsf@ietf.org; Kathleen Moriarty Cc: i2rs@ietf.org; dots@ietf.org; netmod@ietf.org Subject: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IET= F 93 Thanks to I2NSF contributors for the good progresses made since IETF92 sid= e 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 I= nterface 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 t= he Capability Interface. The thinking logic is: Once the Capability Interfa= ce is completed, we will see more clearly the work for Service interface. E= ven if Capability layer alone is standardized, it is a giant leap forward i= n building blocks for Service Provider to automate their Security Controlle= r that can utilize NSF by multiple vendors Here is the narrower scoped I2NSF charter. Your comments and suggestions ar= e greatly appreciated. CC=92ed to DOTS, I2RS, and Netmod groups for wider r= eview. Enterprises, residential, and mobile customers are increasingly consuming n= etwork functions, especially network security related functions that are no= t 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 i= nterface to express, monitor, and manage security policies to security func= tions deployed at different premises, it becomes virtually impossible for s= ecurity service providers to automate the service offering utilizing securi= ty functions by multiple vendors. The ultimate goal of I2NSF is to enable enterprises to utilize security fun= ctions not hosted on their own premises but instead hosted in service provi= der domain, to establish how to communicate desired security policies to NS= F 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 La= yer) - Security Policies facing clients (I2NSF Service Layer) The I2NSF Capability Layer specifies the functional security policies, whic= h 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 =93Subject =96 Object =96 Function =96 Action=94 = paradigm. The I2NSF Service Layer is for clients to express and monitor security poli= cies for their specific flows, which is usually based on customers=92 logic= al networks, addresses and context. I2NSF Service Layer can also be securit= y expectation or loose security requirement, especially for customers who d= on=92t have the security expertise. The concrete work at the L2NSF Capability Layer includes - The informational & data models for each category to be represen= ted 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 p= olicies between Controller and NSFs. The capability registry is to make it feasible to categorize network securi= ty functions provided by different vendors based on security policy provisi= oning capability without any need to standardize security functions themsel= ves. Standard provisioning capability interface is an essential building b= lock for Security Service Provider to automate their Security Controllers t= hat can utilize NSF by multiple vendors. This layer will leverage the exist= ing 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 clien= ts and demonstrating the feasibility of them being translated to the Capabi= lity Layer policies. Since different security vendors support different features & functions on = their devices, I2NSF will focus on flow based security functions that provi= de 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 Base= d Security functions include deep packet inspection, packet/flow/stream fil= tering or pattern matching and remediation, etc. Similar to I2RS focusing on the interface to RIB/FIB even though most route= rs provide far more functions than RIB/FIB, the I2NSF focused functions can= be a portion of features supported by vendors=92 specific devices. It is a non-goal to create new protocols or data modeling languages for I2N= SF interfaces. I2NSF WG Deliverables include: - Use Case document. - Framework Document. - Requirement for extensions (if there are any) to existing protoc= ols 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 ab= ove Information Model. - IANA registry consideration for flow based security function pol= icy provisioning capability. - (Optionally) Applicability Statements on how to use I2RS, Netco= nf, and NETMOD to carry the content of the specified information/data model= s. [The WG may decide that the Use cases, Framework, and Requirement are Infor= mational 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 W= G 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 =96 +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 com= municate with external SDOs like ETSI NFV and will encourage open source co= de development related to the WG scope in organizations like ONF, OpenStack= , ODL, and OpenNFV. Cheers, Linda Dunbar __________________________________________= _____ I2nsf mailing list I2nsf@ietf.org 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: diego.r.lopez@telefonica.com Tel: +34 913 129 041 Mobile: +34 682 051 091 ---------------------------------- ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o= copia sin autorizaci=F3n puede estar prohibida en virtud de la legislaci= =F3n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo = comunique inmediatamente por esta misma v=EDa y proceda a su destrucci=F3n. The information contained in this transmission is privileged and confidenti= al 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 co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, div= ulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o pode estar proibida em virtude= da legisla=E7=E3o vigente. Se recebeu esta mensagem por erro, rogamos-lhe = que nos o comunique imediatamente por esta mesma via e proceda a sua destru= i=E7=E3o --_000_3AF7BE6ADD174C1C9F3142C6D2AB99B5telefonicacom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <2152AFA7E197A8479416802F6B5FAB15@eurprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Hi,

(Restricting this to the I2NSF list, as Juergen was sensibly requestin= g)

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 understoo= d by the community. I'd leave the primary goal definition as:

"The primary goal of I2NSF is to define an e= xtensible framework for managing NSFs" 

and consistently talk about "configuration", "managemen= t" or "control" (the three terms have pros and cons...) when= dealing with the Capability Layer, that I understand is the main goal of t= he 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 <John.sc.Strassner@huawei.com> wrote:

Dear Linda,
 
First, thank you for pulling toget= her these changes. The charter development has progressed nicely.
 
Second, attached is a word documen= t with my edits and suggestions for consideration by the working group. Des= pite 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 t= o address the work that you started in better focusing the working group, a= nd I hope that they help in this process.
 
Best= regards,
John=
&nbs= p;
Dr. = John Strassner, Ph.D.
CTO,= Software Laboratory, CRD

<image001.gif>

 
Futurewei Technologies
US R&D Center
2330 Central Expressway
Building A, office A2-2143
Santa Clara, California  = 95050
&nbs= p; Office:  += 1.408.330.4923
&nbs= p; Email:  <= span class=3D"Apple-converted-space"> john.sc.strassner@huawei.com
&nbs= p;
&nbs= p;
 
From:<= /span> I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Linda Dunb= ar
Sent: Thursday, Ma= y 07, 2015 8:53 AM
To: i2= nsf@ietf.org; Kathleen Moriarty
Cc: i2r= s@ietf.org; dots@ietf.org; netmod@ietf.org
Subject: [I2nsf] F= urther Narrowing the I2NSF scope: the new charter for IETF 93
 
Thanks to I2NSF contributors for the good progresses made since  IETF9= 2 side meetings. Among the two I2NSF interfaces,  i.e. the client faci= ng Service Interface and the NSF facing Capability Interface, the work to b= e 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 fo= r one IETF WG". Therefore, we are leaning towards narrowing the I2NSF = scope to the Capability Interface. The thinking logic is: Once the Capabili= ty 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 Pro= vider to automate their Security Controller that can utilize NSF by multipl= e vendors
 
Here is the narrower scoped I2NSF charter. Your comments and suggestions ar= e greatly appreciated. CC=92ed to DOTS, I2RS, and Netmod groups for wider r= eview.
 
 
 
Enterprises, residential, and mobile customers are increasingly consuming n= etwork functions, especially network security related functions that are no= t running on their premises.  In addition, the European Telecommunicat= ions Standards Institute (ETSI) Network Function Virtualization (NFV) initiative creates new management challenges= for security policies to be enforced by distributed, virtual, network secu= rity 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 s= ecurity functions by multiple vendors.
 
The ultimate goal of I2NSF is to enable enterprises to utilize security fun= ctions not hosted on their own premises but instead hosted in service provi= der domain, to establish how to communicate desired security policies to NS= F and how to get performance data or report out of NSF or vNSF.
 
There are two layers of interfaces:
-          Security Policies facing s= ecurity functions (I2NSF Capability Layer)
-          Security Policies facing c= lients (I2NSF Service Layer)
 
The I2NSF Capability Layer specifies the functional securi= ty policies, which are translated from the client security policies, to sec= urity 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 fo= rm of =93Subject =96 Object =96 Function =96 Action=94 paradigm. =
 
The I2NSF Service Layer is for clients to express and monitor security poli= cies for their specific flows, which is usually based on customers=92 logic= al networks, addresses and context. I2NSF Service Layer can also be securit= y expectation or loose security requirement, especially for customers who don=92t have the security expertise.
 
The concrete work at the L2NSF Capability Layer includes
-         = ; Th= e informational & data models for each category to be represented to virtual or physic= al network security functions,
-         = ; Th= e capability registry (IANA) of policy provisioning capability to flow based security f= unction, and
-         = ; Th= e proper secure communication channels to carry the security policies between Controller a= nd NSFs.
The capability registry is to make it feasible to categorize network securi= ty functions provided by different vendors based on security policy provisi= oning capability without any need to standardize security functions themsel= ves.  Standard provisioning capability interface is an essential building block for Security Service Provider to = automate their Security Controllers that can utilize NSF by multiple vendor= s. 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 clien= ts 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 p= rovide treatment to packets/flows, such as IPS/IDS, Web filter, and flow fi= lter. (They are different from other security functions such as Authentication, Authorization, or Encryption). = Exemplar services associated with Flow Based Security functions include dee= p packet inspection, packet/flow/stream filtering or pattern matching and r= emediation, etc.
 
Similar to I2RS focusing on the interface to RIB/FIB even though most route= rs provide far more functions than RIB/FIB, the I2NSF focused functions can= be a portion of features supported by vendors=92 specific devices.
 
It is a non-goal to create new protocols or data modeling languages for I2N= SF 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 exis= ting protocols and modeling languages
-          A single, unified, Informa= tion Model for expressing policies to the Flow Based Security Functions described abo= ve.
-          Corresponding Data Models = (e.g. YANG models) derived from the above Information Model.
-          IANA registry consideratio= n for flow based security function policy provisioning capability.
-           (Optionally) Applica= bility Statements on how to use I2RS, Netconf, and NETMOD to carry the content of the specif= ied information/data models.
 
[The WG may decide that the Use cases, Framework, and Requirement are = Informational documents or simply reference documents during the lifetime o= f the WG. The framework, that describes the functional components and the I2NSF work ite= ms, 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<= /div>
  - IANA registry consideration + 10 months to WG Document
  - All Early Drafts to IESG: 10 months
 
[decision point =96 +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 com= municate with external SDOs like ETSI NFV and will encourage open source co= de development related to the WG scope in organizations like ONF, OpenStack= , ODL, and OpenNFV.
 
 
Cheers,
Linda Dunbar
<i2nsf charter-jcs-20150512.docx>_______________________= ________________________
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2n= sf

--
"Esta vez no fallaremos, Doctor Infierno"

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

e-mail: diego.r.lopez@telefonica.com
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------



Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o copia sin autorizaci=F3n puede e= star prohibida en virtud de la legislaci=F3n vigente. Si ha recibido este m= ensaje por error, le rogamos que nos lo comunique inmediatamente por esta m= isma v=EDa y proceda a su destrucci=F3n.

The information contained in this transmission is privileged and confidenti= al 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 y= ou have received this transmission in error, do not read it. Please immedia= tely 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=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, divulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o p= ode estar proibida em virtude da legisla=E7=E3o vigente. Se recebeu esta me= nsagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mes= ma via e proceda a sua destrui=E7=E3o
 --_000_3AF7BE6ADD174C1C9F3142C6D2AB99B5telefonicacom_-- From nobody Wed May 13 15:08:34 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51A4D1B3177 for ; Wed, 13 May 2015 15:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RoB1UXYoEjls for ; Wed, 13 May 2015 15:08:29 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CA831B3176 for ; Wed, 13 May 2015 15:08:29 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BSM66539; Wed, 13 May 2015 22:08:27 +0000 (GMT) Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 13 May 2015 23:08:27 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml702-chm ([10.193.5.72]) with mapi id 14.03.0158.001; Wed, 13 May 2015 15:08:20 -0700 From: Linda Dunbar To: "'i2nsf@ietf.org'" Thread-Topic: Interim meeting to reach consensus on I2NSF charter Thread-Index: AQHQjclRpN36wJxMfUaayc6mlz/ddQ== Date: Wed, 13 May 2015 22:08:20 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657C146CF@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.128] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657C146CFdfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [I2nsf] Interim meeting to reach consensus on I2NSF charter X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 22:08:32 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F657C146CFdfweml701chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks to many people comments on the narrower scoped I2NSF charter. Let's = have a call to address the comments to the charter. Here are some slots for the interim meeting. Please let me know if any of t= hose slots conflict with your schedule: Mo 5/18: after 1PM EDT Tu 5/19: any time We 5/20: after 2PM EDT Thu 5/21: after 2PM EDT Mo 5/25: after 1PM EDT Tu 5/26: after 2PM EDT Regards, Linda --_000_4A95BA014132FF49AE685FAB4B9F17F657C146CFdfweml701chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks to many people = comments on the narrower scoped I2NSF charter. Let’s have a call to a= ddress the comments to the charter.

Here are some slots fo= r the interim meeting. Please let me know if any of those slots conflict wi= th your schedule:  

 

 

Mo 5/18: after 1PM EDT

Tu 5/19: any time

We 5/20: after 2PM EDT

Thu 5/21: after 2PM EDT

 

Mo 5/25: after 1PM EDT

Tu 5/26: after 2PM EDT

 

 

Regards,

 

Linda

 

--_000_4A95BA014132FF49AE685FAB4B9F17F657C146CFdfweml701chm_-- From nobody Wed May 13 15:12:18 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4168F1B3178 for ; Wed, 13 May 2015 15:12:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5c5QnSizO-RW for ; Wed, 13 May 2015 15:12:12 -0700 (PDT) Received: from smtpjc.telefonica.com (smtpjc.telefonica.com [81.47.204.76]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E10C1B3176 for ; Wed, 13 May 2015 15:12:11 -0700 (PDT) Received: from smtpjc.telefonica.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 7E79BE01EE; Thu, 14 May 2015 00:12:08 +0200 (CEST) Received: from ESTGVMSP111.EUROPE.telefonica.corp (unknown [10.92.4.9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtpjc.telefonica.com (Postfix) with ESMTPS id 66CC5E01CC; Thu, 14 May 2015 00:12:08 +0200 (CEST) Received: from emea01-db3-obe.outbound.protection.outlook.com (10.92.5.139) by tls.telefonica.com (10.92.6.54) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 14 May 2015 00:12:07 +0200 Received: from DB4PR06MB0624.eurprd06.prod.outlook.com (25.161.13.142) by DB4PR06MB0622.eurprd06.prod.outlook.com (25.161.13.140) with Microsoft SMTP Server (TLS) id 15.1.166.22; Wed, 13 May 2015 22:12:06 +0000 Received: from DB4PR06MB0624.eurprd06.prod.outlook.com ([25.161.13.142]) by DB4PR06MB0624.eurprd06.prod.outlook.com ([25.161.13.142]) with mapi id 15.01.0160.009; Wed, 13 May 2015 22:12:06 +0000 From: DIEGO LOPEZ GARCIA To: Linda Dunbar Thread-Topic: [I2nsf] Interim meeting to reach consensus on I2NSF charter Thread-Index: AQHQjclRpN36wJxMfUaayc6mlz/ddZ16eBwA Date: Wed, 13 May 2015 22:12:05 +0000 Message-ID: References: <4A95BA014132FF49AE685FAB4B9F17F657C146CF@dfweml701-chm> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657C146CF@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: huawei.com; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [83.51.62.246] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB4PR06MB0622; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:DB4PR06MB0622; BCL:0; PCL:0; RULEID:; SRVR:DB4PR06MB0622; x-forefront-prvs: 0575F81B58 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(495834002)(252514010)(83716003)(82746002)(110136002)(76176999)(54356999)(189998001)(19617315012)(36756003)(2656002)(87936001)(46102003)(2900100001)(92566002)(86362001)(62966003)(2950100001)(77156002)(122556002)(5001960100002)(50986999)(19580405001)(40100003)(19580395003)(106116001)(33656002)(102836002)(15975445007)(66066001)(16236675004)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR06MB0622; H:DB4PR06MB0624.eurprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_CE3D34398B514A63BD33F18859C7AEE0telefonicacom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 May 2015 22:12:05.6971 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR06MB0622 X-OriginatorOrg: telefonica.com X-TM-AS-MML: No Archived-At: Cc: "i2nsf@ietf.org" Subject: Re: [I2nsf] Interim meeting to reach consensus on I2NSF charter X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 22:12:16 -0000 --_000_CE3D34398B514A63BD33F18859C7AEE0telefonicacom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Linda, Next week it will be NFV for me in Sanya, and I won't be able to make it...= 25 and 26 sound doable to me (I'd prefer 25, anyway) Be goode, On 14 May 2015, at 24:08 , Linda Dunbar > wrote: Thanks to many people comments on the narrower scoped I2NSF charter. Let=92= s have a call to address the comments to the charter. Here are some slots for the interim meeting. Please let me know if any of t= hose slots conflict with your schedule: Mo 5/18: after 1PM EDT Tu 5/19: any time We 5/20: after 2PM EDT Thu 5/21: after 2PM EDT Mo 5/25: after 1PM EDT Tu 5/26: after 2PM EDT Regards, Linda _______________________________________________ I2nsf mailing list I2nsf@ietf.org 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: diego.r.lopez@telefonica.com Tel: +34 913 129 041 Mobile: +34 682 051 091 ---------------------------------- ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o= copia sin autorizaci=F3n puede estar prohibida en virtud de la legislaci= =F3n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo = comunique inmediatamente por esta misma v=EDa y proceda a su destrucci=F3n. The information contained in this transmission is privileged and confidenti= al 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 co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, div= ulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o pode estar proibida em virtude= da legisla=E7=E3o vigente. Se recebeu esta mensagem por erro, rogamos-lhe = que nos o comunique imediatamente por esta mesma via e proceda a sua destru= i=E7=E3o --_000_CE3D34398B514A63BD33F18859C7AEE0telefonicacom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <217CD5BC5CD7D643BFFAA43694A59CAB@eurprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Hi Linda,

Next week it will be NFV for me in Sanya, and I won't be able to make = it... 25 and 26 sound doable to me (I'd prefer 25, anyway)

Be goode,

On 14 May 2015, at 24:08 , Linda Dunbar <linda.dunbar@huawei.com> wrote:

Thanks to many people comments on = the narrower scoped I2NSF charter. Let=92s have a call to address the comme= nts to the charter.
Here are some slots for the interi= m meeting. Please let me know if any of those slots conflict with your sche= dule:  
 
 
Mo 5/18: after 1PM EDT
Tu 5/19: any time
We 5/20: after 2PM EDT
Thu 5/21: after 2PM EDT
 
Mo 5/25: after 1PM EDT
Tu 5/26: after 2PM EDT
 
 
Regards,
 
Linda
 
_______________________________________________
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2n= sf

--
"Esta vez no fallaremos, Doctor Infierno"

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

e-mail: diego.r.lopez@telefonica.com
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------



Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o copia sin autorizaci=F3n puede e= star prohibida en virtud de la legislaci=F3n vigente. Si ha recibido este m= ensaje por error, le rogamos que nos lo comunique inmediatamente por esta m= isma v=EDa y proceda a su destrucci=F3n.

The information contained in this transmission is privileged and confidenti= al 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 y= ou have received this transmission in error, do not read it. Please immedia= tely 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=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, divulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o p= ode estar proibida em virtude da legisla=E7=E3o vigente. Se recebeu esta me= nsagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mes= ma via e proceda a sua destrui=E7=E3o
 --_000_CE3D34398B514A63BD33F18859C7AEE0telefonicacom_-- From nobody Wed May 13 15:20:28 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B69B11A9140 for ; Wed, 13 May 2015 15:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NJRAy1rfrC9C for ; Wed, 13 May 2015 15:20:25 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D59B1A1A47 for ; Wed, 13 May 2015 15:20:24 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BSM67050; Wed, 13 May 2015 22:20:23 +0000 (GMT) Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 13 May 2015 23:20:23 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml705-chm ([10.193.5.142]) with mapi id 14.03.0158.001; Wed, 13 May 2015 15:20:17 -0700 From: Linda Dunbar To: Hosnieh Rafiee , "i2nsf@ietf.org" Thread-Topic: [I2nsf] gap analysis Thread-Index: AdCNuYd1I6wWEMDQTdCBeM+dl8v0bAAEHmZg Date: Wed, 13 May 2015 22:20:16 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657C146E7@dfweml701-chm> References: <00a801d08db9$8919a5d0$9b4cf170$@rozanak.com> In-Reply-To: <00a801d08db9$8919a5d0$9b4cf170$@rozanak.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.128] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [I2nsf] gap analysis X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 22:20:26 -0000 Hosnieh,=20 Yes, please consider the latest narrower scoped I2NSF charter. Even though = there are many comments not resolved yet, the general direction is: focusin= g on the interface towards NSFs Thanks, Linda -----Original Message----- From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Hosnieh Rafiee Sent: Wednesday, May 13, 2015 3:15 PM To: i2nsf@ietf.org Subject: [I2nsf] gap analysis Hi Linda and All, I would like to start the revision of gap analysis. Shall I consider the re= cent charter for this?=20 Thanks, Best, Hosnieh _______________________________________________ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf From nobody Wed May 13 16:10:10 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 320981B31D0 for ; Wed, 13 May 2015 16:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sidYlOraMdBD for ; Wed, 13 May 2015 16:10:02 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D8FD1B31CF for ; Wed, 13 May 2015 16:10:01 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BSM69098; Wed, 13 May 2015 23:09:59 +0000 (GMT) Received: from DFWEML706-CHM.china.huawei.com (10.193.5.225) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 14 May 2015 00:09:59 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml706-chm ([10.193.5.225]) with mapi id 14.03.0158.001; Wed, 13 May 2015 16:09:46 -0700 From: Linda Dunbar To: "Zarny, Myo" , "'i2nsf@ietf.org'" , "'Kathleen Moriarty'" Thread-Topic: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93 Thread-Index: AQHQinCAWnYgWx+c3k2SduRLi+ubTp16jRzw Date: Wed, 13 May 2015 23:09:46 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657C147B9@dfweml701-chm> References: <4A95BA014132FF49AE685FAB4B9F17F657C11DC6@dfweml701-chm> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.128] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657C147B9dfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93 X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 23:10:09 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F657C147B9dfweml701chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Myo, Thanks for taking the stab at the rewording. A couple of questions inserted below for your wording: From: Zarny, Myo [mailto:Myo.Zarny@gs.com] Network security functions (NSFs) are increasingly provided and consumed in= increasingly diverse environments. Users of NSFs could consume network sec= urity services hosted by one or more providers, which may be their own ente= rprise, service providers, or a combination of both. [Linda] Do you mean "which may be hosted on premises of their own enterpris= e, service providers, or a combination of both"? Likewise, service providers may offer their customers network security serv= ices that consist of multiple security products from different vendors. Yet= because no widely accepted industry standard security interfaces exist tod= ay, management of NSFs (device and policy provisioning, monitoring, etc.) t= ends 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 NS= Fs such as device or [Linda] Can we remove the "management aspects of NSFs" from the I2NSF chart= er? I2NSF only "focuses on the "policy provisioning aspect of NSFs". Manage= ment aspects of NSFs can include many different aspects of provisioning, ma= y be too broad for I2NSF. 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 mu= ch or too light. Myo From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: 7 May 2015 11:53 AM To: i2nsf@ietf.org; Kathleen Moriarty Cc: i2rs@ietf.org; dots@ietf.org; netmod@ietf.org Subject: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IET= F 93 Thanks to I2NSF contributors for the good progresses made since IETF92 sid= e 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 I= nterface 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 t= he Capability Interface. The thinking logic is: Once the Capability Interfa= ce is completed, we will see more clearly the work for Service interface. E= ven if Capability layer alone is standardized, it is a giant leap forward i= n building blocks for Service Provider to automate their Security Controlle= r that can utilize NSF by multiple vendors Here is the narrower scoped I2NSF charter. Your comments and suggestions ar= e greatly appreciated. CC'ed to DOTS, I2RS, and Netmod groups for wider rev= iew. Enterprises, residential, and mobile customers are increasingly consuming n= etwork functions, especially network security related functions that are no= t 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 i= nterface to express, monitor, and manage security policies to security func= tions deployed at different premises, it becomes virtually impossible for s= ecurity service providers to automate the service offering utilizing securi= ty functions by multiple vendors. The ultimate goal of I2NSF is to enable enterprises to utilize security fun= ctions not hosted on their own premises but instead hosted in service provi= der domain, to establish how to communicate desired security policies to NS= F 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 La= yer) - Security Policies facing clients (I2NSF Service Layer) The I2NSF Capability Layer specifies the functional security policies, whic= h 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("Subjec= t-Object-Function-Action") in the charter. The I2NSF Service Layer is for clients to express and monitor security poli= cies 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 clien= ts to express and monitor security policies. The policies may be intent-bas= ed." The concrete work at the L2NSF Capability Layer includes - The informational & data models for each category to be represen= ted 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 p= olicies between Controller and NSFs. The capability registry is to make it feasible to categorize network securi= ty functions provided by different vendors based on security policy provisi= oning capability without any need to standardize security functions themsel= ves. Standard provisioning capability interface is an essential building b= lock for Security Service Provider to automate their Security Controllers t= hat can utilize NSF by multiple vendors. This layer will leverage the exist= ing 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 clien= ts and demonstrating the feasibility of them being translated to the Capabi= lity Layer policies. Since different security vendors support different features & functions on = their devices, I2NSF will focus on flow based security functions that provi= de 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 Base= d Security functions include deep packet inspection, packet/flow/stream fil= tering or pattern matching and remediation, etc. Similar to I2RS focusing on the interface to RIB/FIB even though most route= rs 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 I2N= SF interfaces. I2NSF WG Deliverables include: - Use Case document. - Framework Document. - Requirement for extensions (if there are any) to existing protoc= ols 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 ab= ove Information Model. - IANA registry consideration for flow based security function pol= icy provisioning capability. - (Optionally) Applicability Statements on how to use I2RS, Netco= nf, and NETMOD to carry the content of the specified information/data model= s. [The WG may decide that the Use cases, Framework, and Requirement are Infor= mational 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 W= G 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 com= municate with external SDOs like ETSI NFV and will encourage open source co= de development related to the WG scope in organizations like ONF, OpenStack= , ODL, and OpenNFV. Cheers, Linda Dunbar --_000_4A95BA014132FF49AE685FAB4B9F17F657C147B9dfweml701chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Myo,

 

Thanks for taking the = stab at the rewording.

 

A couple of questions = inserted below for your wording:

 

 

 

From: Zarny, M= yo [mailto:Myo.Zarny@gs.com]

 

Network security functions (NSFs= ) are increasingly provided and consumed in increasingly diverse environmen= ts. 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 &#= 8220;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 se= curity 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 res= ult, automation of such services, if it exists at all, is also bespoke.  

 

[Linda] can we say = 220;… 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 mana= gement 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.

 

The scope of I2NSF can be furthe= r 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<= /p>

 

 

From: I2nsf [mailto:= i2nsf-bounces@ietf.org] On Behalf Of Linda Dunbar
Sent: 7 May 2015 11:53 AM
To: i2nsf@ietf.org; Kathleen M= oriarty
Cc: i2rs@ietf.org; dots@ietf.org; netmod@ietf.org Subject: [I2nsf] Further Narrowing the I2NSF scope: the new charter = for IETF 93

 

Thanks to I2NSF contribut= ors for the good progresses made since  IETF92 side meetings. Among th= e 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. Bu= t the Service Interface is still a little vague.

 

The feedback from last IE= TF side meetings was "the scope is too big for one IETF WG". Ther= efore, we are leaning towards narrowing the I2NSF scope to the Capability I= nterface. The thinking logic is: Once the Capability Interface is completed, we will see more clearly the work for Service inte= rface. Even if Capability layer alone is standardized, it is a giant leap f= orward in building blocks for Service Provider to automate their Security C= ontroller that can utilize NSF by multiple vendors

 

Here is the narrower scop= ed 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, especia= lly network security related functions that are not running on their premis= es.  In addition, the European Telecommunications Standards Institute (ETSI) Network Function Virtualization (NFV) initiativ= e 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 premi= ses, it becomes virtually impossible for security service providers to auto= mate the service offering utilizing security functions by multiple vendors.

 

The ultimate goal of I2NS= F is to enable enterprises to utilize security functions not hosted on thei= r 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 vN= SF.

 

There are two layers of i= nterfaces:

-       = ;   Security Policies facing security functions (I2NSF = Capability Layer)

-       = ;   Security Policies facing clients (I2NSF Service Lay= er)

 

The I2NSF Capability Layer specifies the functional security policies, w= hich are translated from the client security policies, to security function= s. I2NSF will NOT standardize security functions or devices. Instead, I2NSF is only to standardize the policy pro= visioning to the security functions (not devices), in the form of “Su= bject – Object – Function – Action” paradigm. 

MZ:  Not sure if we need to explicitly specify a potential soluti= on(“Subject-Object-Function-Action”) in the charter.=

 

The I2NSF Service Layer i= s for clients to express and monitor security policies for their specific f= lows, which is usually based on customers’ logical networks, addresse= s and context. I2NSF Service Layer can also be security expectation or loose security requirement, especially for cust= omers who don’t have the security expertise.

MZ:  I suggest “I2NSF Services Layer provides a set of inte= rfaces for clients to express and monitor security policies. The policies m= ay be intent-based.”

 

The concrete work at the = L2NSF Capability Layer includes

-  &= nbsp;       The informational & data models for each= category to be represented to virtual or physical network security functio= ns,

-  &= nbsp;       The capability registry (IANA) of policy pro= visioning capability to flow based security function, and

-  &= nbsp;       The proper secure communication channels to = carry the security policies between Controller and NSFs.

The capability registry i= s 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 essenti= al building block for Security Service Provider to automate their Security = Controllers that can utilize NSF by multiple vendors. This layer will lever= age the existing protocols and data models defined by I2RS, Netconf, and NETMOD.

 

For the I2NSF Service Lay= er, it is out of the scope for I2NSF (at least for now) to standardize the = interface facing clients. However, I2NSF can have informational drafts show= ing sample APIs or/and RESTful interfaces to clients and demonstrating the feasibility of them being translated to t= he 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 packe= ts/flows, such as IPS/IDS, Web filter, and flow filter. (They are different from other security functions such as Aut= hentication, Authorization, or Encryption). Exemplar services associated wi= th Flow Based Security functions include deep packet inspection, packet/flo= w/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 funct= ions than RIB/FIB, the I2NSF focused functions can be a portion of features= supported by vendors’ specific devices.

 

It is a non-goal to creat= e new protocols or data modeling languages for I2NSF interfaces.

I2NSF WG Deliverables inc= lude:

 

-       = ;    Use Case document.

-       = ;   Framework Document.

-       = ;   Requirement for extensions (if there are any) to ex= isting protocols used by the WG.

-       = ;    Gap analysis of existing protocols and modeli= ng languages

-       = ;   A single, unified, Information Model for expressing= policies to the Flow Based Security Functions described above.<= /p>

-       = ;   Corresponding Data Models (e.g. YANG models) derive= d 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 info= rmation/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 descri= bes the functional components and the I2NSF work items, is to make I2NSF wo= rk more organized.]

 

Suggested Milestones=

  - Use Case Documen= t:  Charter time + 1 month to WG Document

  - Framework: Chart= er time + 4 months to WG Document

  - Requirements for= extensions to protocols:  Charter time + 6 months to WG document<= o:p>

  - Info model: Char= ter time + 7 months to WG Document

  - IANA registry co= nsideration + 10 months to WG Document

  - All Early Drafts= to IESG: 10 months

 

[decision point – &= #43;10 months] 

  - Data Models= : Charter + 9 Months to WG Document

  - Applicability St= atements: 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 SD= Os 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

--_000_4A95BA014132FF49AE685FAB4B9F17F657C147B9dfweml701chm_-- From nobody Thu May 14 00:25:33 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5AB51B3491 for ; Thu, 14 May 2015 00:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.354 X-Spam-Level: X-Spam-Status: No, score=-96.354 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lm2EdQUDsxVa for ; Thu, 14 May 2015 00:25:31 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 37A981B348C for ; Thu, 14 May 2015 00:25:31 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Linda Dunbar'" , References: <4A95BA014132FF49AE685FAB4B9F17F657C146CF@dfweml701-chm> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657C146CF@dfweml701-chm> Date: Thu, 14 May 2015 03:25:24 -0400 Message-ID: <009901d08e17$24fb37e0$6ef1a7a0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_009A_01D08DF5.9DEB1E80" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHm1ITLUAhTflStYESagBi+BlxveJ1OhS9g Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [I2nsf] Interim meeting to reach consensus on I2NSF charter X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 07:25:33 -0000 This is a multipart message in MIME format. ------=_NextPart_000_009A_01D08DF5.9DEB1E80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit No conflict with the schedule . Sue From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Wednesday, May 13, 2015 6:08 PM To: 'i2nsf@ietf.org' Subject: [I2nsf] Interim meeting to reach consensus on I2NSF charter Thanks to many people comments on the narrower scoped I2NSF charter. Let's have a call to address the comments to the charter. Here are some slots for the interim meeting. Please let me know if any of those slots conflict with your schedule: Mo 5/18: after 1PM EDT Tu 5/19: any time We 5/20: after 2PM EDT Thu 5/21: after 2PM EDT Mo 5/25: after 1PM EDT Tu 5/26: after 2PM EDT Regards, Linda ------=_NextPart_000_009A_01D08DF5.9DEB1E80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

No conflict with the schedule = .

 

Sue =

 

From:= = I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Linda = Dunbar
Sent: Wednesday, May 13, 2015 6:08 PM
To: = 'i2nsf@ietf.org'
Subject: [I2nsf] Interim meeting to reach = consensus on I2NSF charter

 

Thanks to many people comments on the narrower = scoped I2NSF charter. Let’s have a call to address the comments to = the charter.

Here are some slots for the interim meeting. = Please let me know if any of those slots conflict with your schedule: =  

 

 

Mo 5/18: after 1PM EDT

Tu 5/19: any time

We 5/20: after 2PM EDT

Thu 5/21: after 2PM EDT

 

Mo 5/25: = after 1PM EDT

Tu 5/26: after 2PM = EDT

 

 

Regards,

 

Linda

 

------=_NextPart_000_009A_01D08DF5.9DEB1E80-- From nobody Thu May 14 00:34:24 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A94FE1B34BD for ; Thu, 14 May 2015 00:34:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.91 X-Spam-Level: X-Spam-Status: No, score=-4.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_HI=-5, T_FILL_THIS_FORM_SHORT=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id agyOBDZz6uqg for ; Thu, 14 May 2015 00:34:13 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D60601B34B3 for ; Thu, 14 May 2015 00:34:11 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmwFAENPVFWHCzIm/2dsb2JhbABZA4JFISlUXgaFIa1EAQEBAQEBBpM0GQEGhggCgTZMAQEBAQEBgQuEIAEBAQEDAQEBDwgTPgMGBQ4CAgEIDQQEAQELFgEGBxYRAgkUCQgBAQQBDQUIDA6ICgEMqA+vBAEBAQEBAQEBAQEBAQEBAQEBAQEBARcEhhKEIoEChCIRASAGBxICBgUBBAYBAgQDCIIcTR2BFgWGYoUNhmyEJ4UOAYJgPoMlgnELixuDVyNhfAkjHIFSbwEBAYEJOYEBAQEB X-IronPort-AV: E=Sophos;i="5.13,426,1427774400"; d="scan'208,217";a="102606168" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by de307622-de-outbound.net.avaya.com with ESMTP; 14 May 2015 03:34:07 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 14 May 2015 03:34:06 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0174.001; Thu, 14 May 2015 09:34:05 +0200 From: "Romascanu, Dan (Dan)" To: DIEGO LOPEZ GARCIA , John Strassner Thread-Topic: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93 Thread-Index: AdCI3eREWnYgWx+c3k2SduRLi+ubTgEwhD0wAAYQSwAAF9sOcA== Date: Thu, 14 May 2015 07:34:04 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5CA2E131@AZ-FFEXMB04.global.avaya.com> References: <4A95BA014132FF49AE685FAB4B9F17F657C11DC6@dfweml701-chm> <3AF7BE6A-DD17-4C1C-9F31-42C6D2AB99B5@telefonica.com> In-Reply-To: <3AF7BE6A-DD17-4C1C-9F31-42C6D2AB99B5@telefonica.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.47] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA5CA2E131AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: Cc: "i2nsf@ietf.org" , Kathleen Moriarty , Linda Dunbar Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93 X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 07:34:22 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5CA2E131AZFFEXMB04globa_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable (speaking as contributor) I agree with Diego's observation. I also agree and like many of the edits p= roposed by John, but I do not believe that the scope should be focused arou= nd policies. Policies may be the right paradigm at certain layers, but they= are not the only method for interoperable access and management of NSFs. T= he work should not IMO exclude policy, but neither should make of it the ce= ntral (or exclusive) focus. Regards, Dan From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of DIEGO LOPEZ GARCIA Sent: Thursday, May 14, 2015 1:06 AM To: John Strassner Cc: i2nsf@ietf.org; Kathleen Moriarty; Linda Dunbar Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new charter for= IETF 93 Importance: High 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 th= e term "policy" in the document. The text talks about policy at two many la= yers and can become misleading and difficult to be understood by the commun= ity. I'd leave the primary goal definition as: "The primary goal of I2NSF is to define an extensible framework for managin= g 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 furth= er development for a later stage. Be goode, On 13 May 2015, at 19:18 , John Strassner > wrote: Dear Linda, First, thank you for pulling together these changes. The charter developmen= t has progressed nicely. Second, attached is a word document with my edits and suggestions for consi= deration by the working group. Despite the large number of edits and commen= ts, I am very supportive of I2NSF being made a working group, and would lik= e to volunteer to work on its deliverables. My edits and comments are to ad= dress 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: john.sc.strassner@huawei.com From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Thursday, May 07, 2015 8:53 AM To: i2nsf@ietf.org; Kathleen Moriarty Cc: i2rs@ietf.org; dots@ietf.org; netmod@ietf.org Subject: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IET= F 93 Thanks to I2NSF contributors for the good progresses made since IETF92 sid= e 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 I= nterface 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 t= he Capability Interface. The thinking logic is: Once the Capability Interfa= ce is completed, we will see more clearly the work for Service interface. E= ven if Capability layer alone is standardized, it is a giant leap forward i= n building blocks for Service Provider to automate their Security Controlle= r that can utilize NSF by multiple vendors Here is the narrower scoped I2NSF charter. Your comments and suggestions ar= e greatly appreciated. CC'ed to DOTS, I2RS, and Netmod groups for wider rev= iew. Enterprises, residential, and mobile customers are increasingly consuming n= etwork functions, especially network security related functions that are no= t 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 i= nterface to express, monitor, and manage security policies to security func= tions deployed at different premises, it becomes virtually impossible for s= ecurity service providers to automate the service offering utilizing securi= ty functions by multiple vendors. The ultimate goal of I2NSF is to enable enterprises to utilize security fun= ctions not hosted on their own premises but instead hosted in service provi= der domain, to establish how to communicate desired security policies to NS= F 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 La= yer) - Security Policies facing clients (I2NSF Service Layer) The I2NSF Capability Layer specifies the functional security policies, whic= h 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 poli= cies 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 represen= ted 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 p= olicies between Controller and NSFs. The capability registry is to make it feasible to categorize network securi= ty functions provided by different vendors based on security policy provisi= oning capability without any need to standardize security functions themsel= ves. Standard provisioning capability interface is an essential building b= lock for Security Service Provider to automate their Security Controllers t= hat can utilize NSF by multiple vendors. This layer will leverage the exist= ing 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 clien= ts and demonstrating the feasibility of them being translated to the Capabi= lity Layer policies. Since different security vendors support different features & functions on = their devices, I2NSF will focus on flow based security functions that provi= de 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 Base= d Security functions include deep packet inspection, packet/flow/stream fil= tering or pattern matching and remediation, etc. Similar to I2RS focusing on the interface to RIB/FIB even though most route= rs 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 I2N= SF interfaces. I2NSF WG Deliverables include: - Use Case document. - Framework Document. - Requirement for extensions (if there are any) to existing protoc= ols 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 ab= ove Information Model. - IANA registry consideration for flow based security function pol= icy provisioning capability. - (Optionally) Applicability Statements on how to use I2RS, Netco= nf, and NETMOD to carry the content of the specified information/data model= s. [The WG may decide that the Use cases, Framework, and Requirement are Infor= mational 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 W= G 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 com= municate with external SDOs like ETSI NFV and will encourage open source co= de development related to the WG scope in organizations like ONF, OpenStack= , ODL, and OpenNFV. Cheers, Linda Dunbar __________________________________________= _____ I2nsf mailing list I2nsf@ietf.org 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: diego.r.lopez@telefonica.com Tel: +34 913 129 041 Mobile: +34 682 051 091 ---------------------------------- ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o= copia sin autorizaci=F3n puede estar prohibida en virtud de la legislaci= =F3n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo = comunique inmediatamente por esta misma v=EDa y proceda a su destrucci=F3n. The information contained in this transmission is privileged and confidenti= al 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 co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, div= ulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o pode estar proibida em virtude= da legisla=E7=E3o vigente. Se recebeu esta mensagem por erro, rogamos-lhe = que nos o comunique imediatamente por esta mesma via e proceda a sua destru= i=E7=E3o --_000_9904FB1B0159DA42B0B887B7FA8119CA5CA2E131AZFFEXMB04globa_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

(speaking as contributor)=

 <= /p>

I agree with Diego’= s observation. I also agree and like many of the edits proposed by John, bu= t 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 shou= ld not IMO exclude policy, but neither should make of it the central (or ex= clusive) focus.

 <= /p>

Regards,

 <= /p>

Dan

 <= /p>

 <= /p>

From: I2nsf [m= ailto:i2nsf-bounces@ietf.org] On Behalf Of DIEGO LOPEZ GARCIA
Sent: Thursday, May 14, 2015 1:06 AM
To: John Strassner
Cc: i2nsf@ietf.org; Kathleen Moriarty; Linda Dunbar
Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new char= ter for IETF 93
Importance: High

 

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 difficu= lt to be understood by the community. I'd leave the primary goal definition as:

 

"The primary goal of I2NSF is to define an exte= nsible 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 d= ocuments, and let further development for a later stage.

 

Be goode,

 

On 13 May 2015, at 19:18 , John Strassner <John.sc.Strassner@huawei.com&= gt; wrote:



Dear Linda,

 

First, thank you for pull= ing together these changes. The charter development has progressed nicely.<= /span>

 

Second, attached is a wor= d document with my edits and suggestions for consideration by the working g= roup. 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

 <= o:p>

Dr. John Strassner, Ph.D.

CTO, Software Laboratory, C= RD

<image001.gif>

 

Futurewei Technologies=

US R&D Center

2330 Central Expressway Building A, office A2-2143

Santa Clara, California&n= bsp;  95050

  Office:  +1.408.330.4923

  Email:   john.sc.strassner@huawei.com=

 <= o:p>

 <= o:p>

 

From: I2nsf [ma= ilto:i2nsf-bounces@ietf.org] On Behalf Of <= /span>Linda Dunbar
Sent: Thursday, Ma= y 07, 2015 8:53 AM
To: i2nsf@ietf.org;= Kathleen Moriarty
Cc: i2rs@ietf.org; dots@ietf.org; netmod@ietf.org
Subject: [I2nsf] F= urther Narrowing the I2NSF scope: the new charter for IETF 93

 

Thanks to I2NSF contributors for the go= od progresses made since  IETF92 side meetings. Among the two I2NSF in= terfaces,  i.e. the client facing Service Interface and the NSF facing Capability Interface, the work to be done at the Capability Interfa= ce becomes very clear and concrete. But the Service Interface is still a li= ttle vague.

 

The feedback from last IETF side meetin= gs 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 Se= rvice Provider to automate their Security Controller that can utilize NSF by multiple vendors

 

Here is the narrower scoped I2NSF chart= er. Your comments and suggestions are greatly appreciated. CC’ed to D= OTS, I2RS, and Netmod groups for wider review.

 

 

 

Enterprises, residential, and mobile cu= stomers are increasingly consuming network functions, especially network se= curity related functions that are not running on their premises.  In addition, the European Telecommunications Standards Institute (ETSI) Ne= twork Function Virtualization (NFV) initiative creates new management chall= enges for security policies to be enforced by distributed, virtual, network= security functions (vNSF). Without standard interface to express, monitor, and manage security policies to se= curity functions deployed at different premises, it becomes virtually impos= sible for security service providers to automate the service offering utili= zing 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 perform= ance data or report out of NSF or vNSF.

 

There are two layers of interfaces:

-<= span style=3D"font-size:7.0pt">       &n= bsp;  Security Policies facing security functions (I2NSF Capability Layer)

-<= span style=3D"font-size:7.0pt">       &n= bsp;  Security Policies facing clients (I2NSF Service Layer)

 

The I2NSF Capability Layer specifies th= e functional security policies, which are translated from the client securi= ty policies, to security functions. I2NSF will NOT standardize security functions or devices. Instead, I2NSF is only to standardize the p= olicy provisioning to the security functions (not devices), in the form of = “Subject – Object – Function – Action” paradi= gm. 

 

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 se= curity expertise.

 

The concrete work at the L2NSF Capabili= ty Layer includes

-<= span style=3D"font-size:7.0pt">       &n= bsp;  The informational & data models for each category to be represented to vir= tual or physical network security functions,

-<= span style=3D"font-size:7.0pt">       &n= bsp;  The capability registry (IANA) of policy provisioning capability to flow based= security function, and

-<= span style=3D"font-size:7.0pt">       &n= bsp;  The proper secure communication channels to carry the security policies betwee= n Controller and NSFs.

The capability registry is to make it f= easible to categorize network security functions provided by different vend= ors based on security policy provisioning capability without any need to standardize security functions themselves.  Standard prov= isioning capability interface is an essential building block for Security S= ervice 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 faci= ng 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 suppor= t 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 oth= er security functions such as Authentication, Authorization, or Encryption)= . Exemplar services associated with Flow Based Security functions include d= eep packet inspection, packet/flow/stream filtering or pattern matching and remediation, etc.

 

Similar to I2RS focusing on the interfa= ce 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 protocol= s or data modeling languages for I2NSF interfaces.

I2NSF WG Deliverables include:

 

-<= span style=3D"font-size:7.0pt">       &n= bsp;   Use Case document.

-<= span style=3D"font-size:7.0pt">       &n= bsp;  Framework Document.

-<= span style=3D"font-size:7.0pt">       &n= bsp;  Requirement for extensions (if there are any) to existing protocols used by the WG.

-<= span style=3D"font-size:7.0pt">       &n= bsp;   Gap analysis of existing protocols and modeling languages

-<= span style=3D"font-size:7.0pt">       &n= bsp;  A single, unified, Information Model for expressing policies to the Flow Bas= ed Security Functions described above.

-<= span style=3D"font-size:7.0pt">       &n= bsp;  Corresponding Data Models (e.g. YANG models) derived from the above Information Model.

-<= span style=3D"font-size:7.0pt">       &n= bsp;  IANA registry consideration for flow based security function policy provisionin= g capability.

-<= span style=3D"font-size:7.0pt">       &n= bsp;   (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 Info= rmational documents or simply reference documents during the lifetime of the WG. The = framework, that describes the functional components and the I2NSF work item= s, is to make I2NSF work more organized.]

 

Suggested Milestones<= /p>

  - Use Case Document:  Chart= er 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 &#= 43; 10 months to WG Document

  - All Early Drafts to IESG: 10 m= onths

 

[decision point – +10 months]=  

  - Data Models: Charter += ; 9 Months to WG Document

  - Applicability Statements: 10 m= onths to WG Document

  - Data Models and Applicability = Statements to IESG  - 16 months

 

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

 

 

Cheers,

Linda Dunbar

<i2nsf charter-jcs-20150512.docx>_= ______________________________________________
I2nsf mailing list
I2nsf@ietf.o= rg
https://www.ietf.org/mailman/lis= tinfo/i2nsf

 

--
"Esta vez no fallaremos, Doctor Infierno"

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

e-mail: diego.r.lopez@telef= onica.com
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------

 

 


Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o copia sin autorizaci=F3n puede e= star prohibida en virtud de la legislaci=F3n vigente. Si ha recibido este m= ensaje por error, le rogamos que nos lo comunique inmediatamente por esta m= isma v=EDa y proceda a su destrucci=F3n.

The information contained in this transmission is privileged and confidenti= al 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 y= ou have received this transmission in error, do not read it. Please immedia= tely 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=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, divulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o p= ode estar proibida em virtude da legisla=E7=E3o vigente. Se recebeu esta me= nsagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mes= ma via e proceda a sua destrui=E7=E3o

--_000_9904FB1B0159DA42B0B887B7FA8119CA5CA2E131AZFFEXMB04globa_-- From nobody Thu May 14 05:52:53 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4D231AC3C8 for ; Thu, 14 May 2015 05:52:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sGZ5ETwmF6rJ for ; Thu, 14 May 2015 05:52:49 -0700 (PDT) Received: from mail-yk0-x233.google.com (mail-yk0-x233.google.com [IPv6:2607:f8b0:4002:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC0071ACE46 for ; Thu, 14 May 2015 05:48:48 -0700 (PDT) Received: by ykep21 with SMTP id p21so23718704yke.3 for ; Thu, 14 May 2015 05:48:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FAp7lOrWWVGmfIbStZbRqqjpZZrSlpKLeCpB1LuN7KM=; b=BHxhuaw38OVJSXvsiDqDbCmffgZGJClEnuRP5O7MlNF8UdSnzsniOpbqUmTdujsPR5 WUl81fSwH5JHN5HKYgUp4CvK5B5b8Y5yX23c1hkUlUHjrdczH5Hfv9V3gPbOC+kqVRyb 0/xfYUL9BgimaPGByTzRe+7tr/SAQac/EU9YAIeMXw2Vp7r0oRGY6XjnVw7JKm3201lK P4ZU0iWnhvPPvNIm4DiiXejmbGwKI5lHe8QnP7m6xd9cokPW+vhrbF58d/I4T3lBVJ0T FLdXdibF61laXMHv/eiDamK5Ds2Q7vBxl/z/m6rN2J93XdzOAz/HtIDbDM0BwbWzZh/C NdFg== MIME-Version: 1.0 X-Received: by 10.170.123.83 with SMTP id p80mr4686367ykb.20.1431607728180; Thu, 14 May 2015 05:48:48 -0700 (PDT) Received: by 10.13.225.13 with HTTP; Thu, 14 May 2015 05:48:48 -0700 (PDT) In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657C146CF@dfweml701-chm> References: <4A95BA014132FF49AE685FAB4B9F17F657C146CF@dfweml701-chm> Date: Thu, 14 May 2015 21:48:48 +0900 Message-ID: From: "Mr. Jaehoon Paul Jeong" To: Linda Dunbar Content-Type: multipart/alternative; boundary=001a1137be1c1893bf05160a26d9 Archived-At: Cc: "i2nsf@ietf.org" Subject: Re: [I2nsf] Interim meeting to reach consensus on I2NSF charter X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 12:52:51 -0000 --001a1137be1c1893bf05160a26d9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi all, I support Linda's draft for I2NSF's charter. I will join the conference call for the interim meeting. Thanks. Paul =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Mr. Jaehoon (Paul) Jeong, Ph.D. Assistant Professor Department of Software / Department of Computer Engineering Sungkyunkwan University Office: +82-31-299-4957 Mobile: +82-10-4758-1765 Fax: +82-31-290-5119 Email: pauljeong@skku.edu, jaehoon.paul@gmail.com CPS Lab Website: http://cpslab.skku.edu Personal Homepage: http://cpslab.skku.edu/people-jaehoon-jeong.php On Thu, May 14, 2015 at 7:08 AM, Linda Dunbar wrote: > Thanks to many people comments on the narrower scoped I2NSF charter. > Let=E2=80=99s have a call to address the comments to the charter. > > Here are some slots for the interim meeting. Please let me know if any of > those slots conflict with your schedule: > > > > > > Mo 5/18: after 1PM EDT > > Tu 5/19: any time > > We 5/20: after 2PM EDT > > Thu 5/21: after 2PM EDT > > > > Mo 5/25: after 1PM EDT > > Tu 5/26: after 2PM EDT > > > > > > Regards, > > > > Linda > > > > _______________________________________________ > I2nsf mailing list > I2nsf@ietf.org > https://www.ietf.org/mailman/listinfo/i2nsf > > --001a1137be1c1893bf05160a26d9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,
I support Linda's draft for I2NSF's ch= arter.=C2=A0
I will join the conference call for the interim meetin= g.

Thanks.

Paul

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Mr. Jaehoon (Paul) Jeong, Ph.D.
Assist= ant Professor
Department of Software /
Department of Computer Enginee= ring
Sungkyunkwan University
Office: +82-31-299-4957
Mobile: +82-1= 0-4758-1765
Fax: +82-31-290-5119
Email: pauljeong@skku.edu, jaehoon.paul@gmail.com
CPS Lab W= ebsite: http://cpslab.= skku.edu
Personal Homepage: http://cpslab.skku.edu/people-jaehoon= -jeong.php

On Thu, May 14, 2015 at 7:08 AM, Linda Dunba= r <linda.dunbar@huawei.com> wrote:

Thanks to many people = comments on the narrower scoped I2NSF charter. Let=E2=80=99s have a call to= address the comments to the charter.

Here are some slots fo= r the interim meeting. Please let me know if any of those slots conflict wi= th your schedule: =C2=A0

=C2=A0

=C2=A0

Mo 5/18: after 1PM EDT

Tu 5/19: any time

We 5/20: after 2PM EDT

Thu 5/21: after 2PM EDT

=C2=A0

Mo 5/25: after 1PM EDT

Tu 5/26: after 2PM EDT

=C2=A0

=C2=A0

Regards,

=C2=A0

Linda=

=C2=A0


_______________________________________________
I2nsf mailing list
I2nsf@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/i2nsf


--001a1137be1c1893bf05160a26d9-- From nobody Thu May 14 09:17:08 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E657F1A8820 for ; Thu, 14 May 2015 09:17:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E8DcikzlhI2E for ; Thu, 14 May 2015 09:17:04 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD3A41A8835 for ; Thu, 14 May 2015 09:17:02 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BSN77209; Thu, 14 May 2015 16:17:01 +0000 (GMT) Received: from DFWEML704-CHM.china.huawei.com (10.193.5.141) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 14 May 2015 17:17:00 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml704-chm ([10.193.5.141]) with mapi id 14.03.0158.001; Thu, 14 May 2015 09:16:47 -0700 From: Linda Dunbar To: "'i2nsf@ietf.org'" , "Romascanu, Dan (Dan)" , Kathleen Moriarty , Joseph Salowey Thread-Topic: discussion minutes with AD Kathleen on I2NSF progress and BOF preparation for IETF 93 Thread-Index: AQHQjmFg53dWoGfjrE6UB410IsKRzw== Date: Thu, 14 May 2015 16:16:48 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657C14D66@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.138.54] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657C14D66dfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [I2nsf] discussion minutes with AD Kathleen on I2NSF progress and BOF preparation for IETF 93 X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 16:17:08 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F657C14D66dfweml701chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Time: May 13, 2pm EST Participants: Kathleen Moriarty, Dan Romascanu, and Linda Dunbar Highlight of the discussion: We discussed the newly proposed I2NSF charter proposals and the comments po= sted on the list. Kathleen thinks that it is definitely more focused. Dan thinks that there are a lot of good suggestions from John Strassner's e= dited version. However, Dan thinks that "general policies" is too broad for= I2NSF for now. Dan suggests to work on narrower scoped area first and then= expand. Kathleen agrees with Dan's suggestion. We should adopt Myo Zarny's suggestions and rewording. Should change the w= ording to accommodate Diego, Frank, DaChang, Ning's comments. With regard to if the I2NSF charter should explicitly states "The capabilit= y registry" that enables the characteristics and behavior of NSFs to be spe= cified using a vendor-neutral vocabulary without requiring the NSFs themsel= ves to be standardized, Dan thinks that is necessary to have some descripti= on there, but better wording is needed. Dan will provide some wording for t= his. We asked AD Kathleen if the currently proposed I2NSF charter is too narrow = for an IETF Working Group, Kathleen reassured that IESG tends to like short= term WGs, some may even just focus on one or two drafts. Therefore, the pr= oposed charter is not too narrow. Kathleen thinks the I2NSF is an important piece of work for CSO (http://www= .csoonline.com/ ). Kathleen will be extremely busy next two weeks. She expe= cts us to reach consensus on the narrow scoped I2NSF charter and update the= drafts to reflect the charter within next few weeks. Kathleen will review = the charter and the drafts in detail after she finished her next two week's= busy work. Dan stated that I2NSF has made very good progress. The OCC (OpenCloud Conn= ect) considers the work from I2NSF as important for managing security funct= ions. Kathleen advised to submit a WG-forming BOF request for IETF 93 with a char= ter proposal similar or close to the focused version of the charter posted = recently on the mail list. Linda --_000_4A95BA014132FF49AE685FAB4B9F17F657C14D66dfweml701chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Time: May 13, 2pm EST

Participants: Kathleen Moriarty, Dan Romascanu, and = Linda Dunbar

 

Highlight of the discussion:

 

We discussed the newly proposed I2NSF charter propos= als and the comments posted on the list. Kathleen thinks that it is definit= ely more focused.

Dan thinks that there ar= e a lot of good suggestions from John Strassner’s edited version. How= ever, Dan thinks that “general policies” is too broad for I2NSF= for now. Dan suggests to work on narrower scoped area first and then expand. Kathleen agrees = with Dan’s suggestion.

We should adopt Myo Zarny’s suggestions and re= wording.  Should change the wording to accommodate Diego, Frank, DaCha= ng, Ning’s comments.

 =

With regard to if the I2= NSF charter should explicitly states “The capability registry&= #8221; that enables the characteristics and behavior of NSFs to be specifie= d using a vendor-neutral vocabulary without requiring the NSFs themselves to be standardized, Dan thinks that is necessary to ha= ve some description there, but better wording is needed. Dan will provide s= ome wording for this.   

 

We asked AD Kathleen if the currently proposed I2NSF= charter is too narrow for an IETF Working Group, Kathleen reassured that I= ESG tends to like short term WGs, some may even just focus on one or two dr= afts. Therefore, the proposed charter is not too narrow.

 

Kathleen thinks the I2NSF is an important piece of w= ork for CSO (http://www.csoonline.com= / ). Kathleen will be extremely busy next two weeks. She expects us to = reach consensus on the narrow scoped I2NSF charter and update the drafts to reflect the charter within next few= weeks. Kathleen will review the charter and the drafts in detail after she= finished her next two week’s busy work.

 

Dan stated that I2NSF has made very good progress. T= he  OCC (OpenCloud Connect) considers the work from I2NSF as important= for managing security functions.

 

Kathleen advised to submit a WG-forming BOF request = for IETF 93 with a charter proposal similar or close to the focused version= of the charter posted recently on the mail list.

 

 

Linda

 

 

--_000_4A95BA014132FF49AE685FAB4B9F17F657C14D66dfweml701chm_-- From nobody Thu May 14 15:11:05 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FF4E1ACE03 for ; Thu, 14 May 2015 15:11:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AAwA-QRYgLh6 for ; Thu, 14 May 2015 15:10:56 -0700 (PDT) Received: from mxe02.gs.com (mxe02.gs.com [199.99.47.104]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 407411ACE02 for ; Thu, 14 May 2015 15:10:56 -0700 (PDT) Received: from pps.filterd (gsppabdp01sd.idz.gs.com [127.0.0.1]) by gsppabdp01sd.idz.gs.com (8.14.5/8.14.5) with SMTP id t4EM73p6031074; Thu, 14 May 2015 18:10:39 -0400 Received: from gsppabdp05nd.inz.gs.com ([10.204.43.244]) by gsppabdp01sd.idz.gs.com with ESMTP id 1ud3rd8atr-1; Thu, 14 May 2015 18:10:39 -0400 Received: from pps.filterd (gsppabdp05nd.inz.gs.com [127.0.0.1]) by gsppabdp05nd.inz.gs.com (8.14.5/8.14.5) with SMTP id t4EM80vb011856; Thu, 14 May 2015 18:10:49 -0400 Received: from gshcbdp12ex.firmwide.corp.gs.com (gshcbdp12ex.firmwide.corp.gs.com [10.135.172.21]) by gsppabdp05nd.inz.gs.com with ESMTP id 1ucyht2m9f-1; Thu, 14 May 2015 18:10:49 -0400 Received: from GSCMAMP19EX.firmwide.corp.gs.com ([139.172.38.36]) by gshcbdp12ex.firmwide.corp.gs.com ([10.135.172.21]) with mapi; Thu, 14 May 2015 18:10:48 -0400 From: "Zarny, Myo" To: "'Linda Dunbar'" , "'i2nsf@ietf.org'" , "'Kathleen Moriarty'" Date: Thu, 14 May 2015 18:10:42 -0400 Thread-Topic: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93 Thread-Index: AQHQinCAWnYgWx+c3k2SduRLi+ubTp16jRzwgAF1EIA= Message-ID: References: <4A95BA014132FF49AE685FAB4B9F17F657C11DC6@dfweml701-chm> <4A95BA014132FF49AE685FAB4B9F17F657C147B9@dfweml701-chm> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657C147B9@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-retentionstamp: Firmwide Content-Type: multipart/alternative; boundary="_000_A3233753A4B65F43BCA1B64DA99A9C230721AABBAFGSCMAMP19EXfi_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-05-14_07:2015-05-14,2015-05-14,1970-01-01 signatures=0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-05-14_07:2015-05-14,2015-05-14,1970-01-01 signatures=0 Archived-At: Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93 X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 22:11:04 -0000 --_000_A3233753A4B65F43BCA1B64DA99A9C230721AABBAFGSCMAMP19EXfi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Linda, Please see inline. Myo From: Linda Dunbar [mailto:linda.dunbar@huawei.com] Sent: 13 May 2015 7:10 PM To: Zarny, Myo [Tech]; 'i2nsf@ietf.org'; 'Kathleen Moriarty' Subject: RE: [I2nsf] Further Narrowing the I2NSF scope: the new charter for= IETF 93 Myo, Thanks for taking the stab at the rewording. A couple of questions inserted below for your wording: From: Zarny, Myo [mailto:Myo.Zarny@gs.com] Network security functions (NSFs) are increasingly provided and consumed in= increasingly diverse environments. Users of NSFs could consume network sec= urity services hosted by one or more providers, which may be their own ente= rprise, service providers, or a combination of both. [Linda] Do you mean "which may be hosted on premises of their own enterpris= e, service providers, or a combination of both"? Myo: No. "which" here refers to "one or more providers". Where these servi= ces are hosted doesn't matter, from an I2NSF perspective. Likewise, service providers may offer their customers network security serv= ices that consist of multiple security products from different vendors. Yet= because no widely accepted industry standard security interfaces exist tod= ay, management of NSFs (device and policy provisioning, monitoring, etc.) t= ends 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"? Myo: I suppose we could. 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 NS= Fs such as device or [Linda] Can we remove the "management aspects of NSFs" from the I2NSF chart= er? I2NSF only "focuses on the "policy provisioning aspect of NSFs". Manage= ment aspects of NSFs can include many different aspects of provisioning, ma= y be too broad for I2NSF. Myo: I'll defer to the community on the question of how narrow the scope s= hould be. But seems to me, we'll need to add at least some "management" wor= k (monitoring, policy/config discovery, etc.)-even if it's just to facilita= te policy provisioning. It doesn't make sense to me that we'll use I2NSF in= terfaces for "policy provisioning" but have to switch to proprietary vendor= specific APIs to discover what the current policies happen to be, or if th= e policies we pushed are successful!? 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 mu= ch or too light. Myo From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: 7 May 2015 11:53 AM To: i2nsf@ietf.org; Kathleen Moriarty Cc: i2rs@ietf.org; dots@ietf.org; netmod@ietf.org Subject: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IET= F 93 Thanks to I2NSF contributors for the good progresses made since IETF92 sid= e 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 I= nterface 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 t= he Capability Interface. The thinking logic is: Once the Capability Interfa= ce is completed, we will see more clearly the work for Service interface. E= ven if Capability layer alone is standardized, it is a giant leap forward i= n building blocks for Service Provider to automate their Security Controlle= r that can utilize NSF by multiple vendors Here is the narrower scoped I2NSF charter. Your comments and suggestions ar= e greatly appreciated. CC'ed to DOTS, I2RS, and Netmod groups for wider rev= iew. Enterprises, residential, and mobile customers are increasingly consuming n= etwork functions, especially network security related functions that are no= t 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 i= nterface to express, monitor, and manage security policies to security func= tions deployed at different premises, it becomes virtually impossible for s= ecurity service providers to automate the service offering utilizing securi= ty functions by multiple vendors. The ultimate goal of I2NSF is to enable enterprises to utilize security fun= ctions not hosted on their own premises but instead hosted in service provi= der domain, to establish how to communicate desired security policies to NS= F 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 La= yer) - Security Policies facing clients (I2NSF Service Layer) The I2NSF Capability Layer specifies the functional security policies, whic= h 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("Subjec= t-Object-Function-Action") in the charter. The I2NSF Service Layer is for clients to express and monitor security poli= cies 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 clien= ts to express and monitor security policies. The policies may be intent-bas= ed." The concrete work at the L2NSF Capability Layer includes - The informational & data models for each category to be represen= ted 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 p= olicies between Controller and NSFs. The capability registry is to make it feasible to categorize network securi= ty functions provided by different vendors based on security policy provisi= oning capability without any need to standardize security functions themsel= ves. Standard provisioning capability interface is an essential building b= lock for Security Service Provider to automate their Security Controllers t= hat can utilize NSF by multiple vendors. This layer will leverage the exist= ing 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 clien= ts and demonstrating the feasibility of them being translated to the Capabi= lity Layer policies. Since different security vendors support different features & functions on = their devices, I2NSF will focus on flow based security functions that provi= de 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 Base= d Security functions include deep packet inspection, packet/flow/stream fil= tering or pattern matching and remediation, etc. Similar to I2RS focusing on the interface to RIB/FIB even though most route= rs 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 I2N= SF interfaces. I2NSF WG Deliverables include: - Use Case document. - Framework Document. - Requirement for extensions (if there are any) to existing protoc= ols 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 ab= ove Information Model. - IANA registry consideration for flow based security function pol= icy provisioning capability. - (Optionally) Applicability Statements on how to use I2RS, Netco= nf, and NETMOD to carry the content of the specified information/data model= s. [The WG may decide that the Use cases, Framework, and Requirement are Infor= mational 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 W= G 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 com= municate with external SDOs like ETSI NFV and will encourage open source co= de development related to the WG scope in organizations like ONF, OpenStack= , ODL, and OpenNFV. Cheers, Linda Dunbar --_000_A3233753A4B65F43BCA1B64DA99A9C230721AABBAFGSCMAMP19EXfi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Linda,

 

Please see inline.

 

Myo

 

From:<= span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Linda Du= nbar [mailto:linda.dunbar@huawei.com]
Sent: 13 May 2015 7:10 PM<= br>To: Zarny, Myo [Tech]; 'i2nsf@ietf.org'; 'Kathleen Moriarty'
<= b>Subject: RE: [I2nsf] Further Narrowing the I2NSF scope: the new chart= er for IETF 93

 

Myo,

 

Thanks for taking the stab at the rewording= .

 

A couple of quest= ions inserted below for your wording:

 

 

 

From: Zarny, Myo [mailto:Myo.Zarny@gs.com]

 =

Network security funct= ions (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 provid= ers, or a combination of both.

 

 <= /p>

[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 &#= 8220;one or more providers”. Where these services are hosted doesn= 217;t matter, from an I2NSF perspective.

 

Likewise, service providers may offer the= ir customers network security services that consist of multiple security pr= oducts from different vendors. Yet because no widely accepted industry stan= dard security interfaces exist today, management of NSFs (device and policy= provisioning, monitoring, etc.) tends to be bespoke, essentially as offere= d by product vendors. As a result, automation of such services, if it exist= s at all, is also bespoke.  

 =

[Linda] can we say “… if it exists at all, is als= o vendor specific”?

Myo:  I suppose we= could.

 

= 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 NS= Fs such as device or

 

<= p class=3DMsoNormal style=3D'margin-left:.5in'>[Linda] Can we remove the “management aspects of NSFs” from t= he I2NSF charter? I2NSF only “focuses on the “policy provisioni= ng aspect of NSFs”. Management aspects of NSFs can include many diffe= rent 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 le= ast 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 &= #8220;policy provisioning” but have to switch to proprietary vendor s= pecific APIs to discover what the current policies happen to be, or if the = policies we pushed are successful!?

 

network provisioning are out of scope.

 <= /span>

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

·        = ; I2NSF Capabilities Layer

·     &n= bsp;   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.<= /span>

 

Myo

 

 

From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Linda Dunbar
Sent: 7 May 2015 11:53 AM
To: i2nsf@ietf.org; Kathleen Moriarty
Cc:= i2rs@ietf.org; dots@ietf.org; netmod@iet= f.org
Subject: [I2nsf] Further Narrowing the I2NSF scope: the= new charter for IETF 93

 

Thanks to I2NSF contributors for the good progre= sses made since  IETF92 side meetings. Among the two I2NSF interfaces,=  i.e. the client facing Service Interface and the NSF facing Capabili= ty 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 la= st IETF side meetings was "the scope is too big for one IETF WG".= Therefore, we are leaning towards narrowing the I2NSF scope to the Capabil= ity Interface. The thinking logic is: Once the Capability Interface is comp= leted, we will see more clearly the work for Service interface. Even if Cap= ability 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 Net= mod groups for wider review.

 

 

 

Enterprises, residential, and mobile customers are = increasingly consuming network functions, especially network security relat= ed functions that are not running on their premises.  In addition, the= European Telecommunications Standards Institute (ETSI) Network Function Vi= rtualization (NFV) initiative creates new management challenges for securit= y policies to be enforced by distributed, virtual, network security functio= ns (vNSF). Without standard interface to express, monitor, and manage secur= ity policies to security functions deployed at different premises, it becom= es virtually impossible for security service providers to automate the serv= ice offering utilizing security functions by multiple vendors. <= /p>

 

The ultimate goal of I2NSF i= s to enable enterprises to utilize security functions not hosted on their o= wn 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:

-     &n= bsp;    Security Policies facing sec= urity functions (I2NSF Capability Layer)

-       &nbs= p;  Security Policies facing clients (I2NSF Se= rvice 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 de= vices. Instead, I2NSF is only to standardize the policy provisioning to the= security functions (not devices), in the form of “Subject – Ob= ject – 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 an= d monitor security policies for their specific flows, which is usually base= d on customers’ logical networks, addresses and context. I2NSF Servic= e Layer can also be security expectation or loose security requirement, esp= ecially 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 polic= ies may be intent-based.”

 

The concrete work at the L2NSF Capability Layer incl= udes

-         = The informational & data models for eac= h category to be represented to virtual or physical network security functi= ons,

-   &= nbsp;      The capa= bility registry (IANA) of policy provisioning capability to flow based secu= rity function, and

-&nbs= p;         The proper secure communication channels to carry the security polic= ies between Controller and NSFs.

The capability reg= istry is to make it feasible to categorize network security functions provi= ded by different vendors based on security policy provisioning capability w= ithout any need to standardize security functions themselves.  Standar= d provisioning capability interface is an essential building block for Secu= rity Service Provider to automate their Security Controllers that can utili= ze 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 ou= t of the scope for I2NSF (at least for now) to standardize the interface fa= cing clients. However, I2NSF can have informational drafts showing sample A= PIs or/and RESTful interfaces to clients and demonstrating the feasibility = of them being translated to the Capability Layer policies.

<= p class=3DMsoNormal style=3D'margin-left:1.0in'> 

Since different security vendors support different features & functi= ons on their devices, I2NSF will focus on flow based security functions tha= t provide treatment to packets/flows, such as IPS/IDS, Web filter, and flow= filter. (They are different from other security functions such as Authenti= cation, Authorization, or Encryption). Exemplar services associated with Fl= ow Based Security functions include deep packet inspection, packet/flow/str= eam filtering or pattern matching and remediation, etc.

 

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

 

It is a non-goal to create new protocols or data mod= eling languages for I2NSF interfaces.

I2NSF WG Deliverables include:

 

-     &nbs= p;     Use Case document. =

-  &nbs= p;       Framework Do= cument.

-&nbs= p;         = Requirement for extensions (if there are any) to existing protocols used by= the WG.

-&n= bsp;          Gap analysis of existing protocols and modeling languages

-   &nb= sp;      A single, unified= , Information Model for expressing policies to the Flow Based Security Func= tions described above.

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

-          IANA registry consideration for flow based security fun= ction policy provisioning capability.

-        &= nbsp;  (Optionally) Applicability Statements o= n how to use I2RS, Netconf, and NETMOD to carry the content of the specifie= d 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 describ= es the functional components and the I2NSF work items, is to make I2NSF wor= k more organized.]

 

Suggested Milestones

  - Use Case Document:&n= bsp; 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 r= egistry 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

&nb= sp; - Applicability Statements: 10 months to WG Document

  - Data Models and Appli= cability Statements to IESG  - 16 months

 

The WG will work closely with I= 2RS, Netconf and Netmod WGs. The WG will communicate with external SDOs lik= e ETSI NFV and will encourage open source code development related to the W= G scope in organizations like ONF, OpenStack, ODL, and OpenNFV.<= /p>

 

 

<= p class=3DMsoNormal style=3D'margin-left:1.0in'>Cheers,

Linda Dunbar

= --_000_A3233753A4B65F43BCA1B64DA99A9C230721AABBAFGSCMAMP19EXfi_-- From nobody Thu May 14 23:08:03 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4364C1AC3DC for ; Thu, 14 May 2015 23:08:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.221 X-Spam-Level: X-Spam-Status: No, score=-2.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Kdz4D8PyJTc for ; Thu, 14 May 2015 23:07:51 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17E661A92DE for ; Thu, 14 May 2015 23:07:23 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BWB29896; Fri, 15 May 2015 06:07:22 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.218.25.36) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 15 May 2015 07:07:19 +0100 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.83]) by SJCEML703-CHM.china.huawei.com ([169.254.5.112]) with mapi id 14.03.0158.001; Thu, 14 May 2015 23:07:05 -0700 From: John Strassner To: "Romascanu, Dan (Dan)" , DIEGO LOPEZ GARCIA Thread-Topic: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93 Thread-Index: AdCI3eREQdBVQ8yORRe/7nCVEnyK2QEwhD0wAApA4QAAIoN/AAAgQqQw Date: Fri, 15 May 2015 06:07:04 +0000 Message-ID: References: <4A95BA014132FF49AE685FAB4B9F17F657C11DC6@dfweml701-chm> <3AF7BE6A-DD17-4C1C-9F31-42C6D2AB99B5@telefonica.com> <9904FB1B0159DA42B0B887B7FA8119CA5CA2E131@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5CA2E131@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.47.151.88] Content-Type: multipart/related; boundary="_004_B818037A70EDCC4A86113DA25EC02098200B5351SJCEML701CHMchi_"; type="multipart/alternative" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "i2nsf@ietf.org" , Kathleen Moriarty , Linda Dunbar Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93 X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2015 06:08:01 -0000 --_004_B818037A70EDCC4A86113DA25EC02098200B5351SJCEML701CHMchi_ Content-Type: multipart/alternative; boundary="_000_B818037A70EDCC4A86113DA25EC02098200B5351SJCEML701CHMchi_" --_000_B818037A70EDCC4A86113DA25EC02098200B5351SJCEML701CHMchi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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 mana= ge security policies for physical and virtual distributed security function= s that may be running on different premises. In order to address the above challenges, vNSF devices may include two func= tional 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 u= ntouched) by my edits: There are two layers of interfaces envisioned in the I2NSF approach: - Security Policies facing security functions (I2NSF Capability La= yer) - Security Policies facing clients (I2NSF Service 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 l= ike to propose. I'm certainly for consensus, and would like to help agree on the charter as= ap; I just don't understand what in my edits made people think that it is n= ow too focused on policy, given the existing starting text. regards, John Dr. John Strassner, Ph.D. CTO, Software Laboratory, CRD [logo.gif] Futurewei Technologies US R&D Center 2330 Central Expressway Building A, office A2-2143 Santa Clara, California 95050 Office: +1.408.330.4923 Email: john.sc.strassner@huawei.com From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Romascanu, Dan (Da= n) Sent: Thursday, May 14, 2015 12:34 AM To: DIEGO LOPEZ GARCIA; John Strassner Cc: i2nsf@ietf.org; Kathleen Moriarty; Linda Dunbar Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new charter for= IETF 93 (speaking as contributor) I agree with Diego's observation. I also agree and like many of the edits p= roposed by John, but I do not believe that the scope should be focused arou= nd policies. Policies may be the right paradigm at certain layers, but they= are not the only method for interoperable access and management of NSFs. T= he work should not IMO exclude policy, but neither should make of it the ce= ntral (or exclusive) focus. Regards, Dan From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of DIEGO LOPEZ GARCIA Sent: Thursday, May 14, 2015 1:06 AM To: John Strassner Cc: i2nsf@ietf.org; Kathleen Moriarty; Linda Dunbar Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new charter for= IETF 93 Importance: High 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 th= e term "policy" in the document. The text talks about policy at two many la= yers and can become misleading and difficult to be understood by the commun= ity. I'd leave the primary goal definition as: "The primary goal of I2NSF is to define an extensible framework for managin= g 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 furth= er development for a later stage. Be goode, On 13 May 2015, at 19:18 , John Strassner > wrote: Dear Linda, First, thank you for pulling together these changes. The charter developmen= t has progressed nicely. Second, attached is a word document with my edits and suggestions for consi= deration by the working group. Despite the large number of edits and commen= ts, I am very supportive of I2NSF being made a working group, and would lik= e to volunteer to work on its deliverables. My edits and comments are to ad= dress 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: john.sc.strassner@huawei.com From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Thursday, May 07, 2015 8:53 AM To: i2nsf@ietf.org; Kathleen Moriarty Cc: i2rs@ietf.org; dots@ietf.org; netmod@ietf.org Subject: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IET= F 93 Thanks to I2NSF contributors for the good progresses made since IETF92 sid= e 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 I= nterface 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 t= he Capability Interface. The thinking logic is: Once the Capability Interfa= ce is completed, we will see more clearly the work for Service interface. E= ven if Capability layer alone is standardized, it is a giant leap forward i= n building blocks for Service Provider to automate their Security Controlle= r that can utilize NSF by multiple vendors Here is the narrower scoped I2NSF charter. Your comments and suggestions ar= e greatly appreciated. CC'ed to DOTS, I2RS, and Netmod groups for wider rev= iew. Enterprises, residential, and mobile customers are increasingly consuming n= etwork functions, especially network security related functions that are no= t 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 i= nterface to express, monitor, and manage security policies to security func= tions deployed at different premises, it becomes virtually impossible for s= ecurity service providers to automate the service offering utilizing securi= ty functions by multiple vendors. The ultimate goal of I2NSF is to enable enterprises to utilize security fun= ctions not hosted on their own premises but instead hosted in service provi= der domain, to establish how to communicate desired security policies to NS= F 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 La= yer) - Security Policies facing clients (I2NSF Service Layer) The I2NSF Capability Layer specifies the functional security policies, whic= h 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 poli= cies 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 represen= ted 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 p= olicies between Controller and NSFs. The capability registry is to make it feasible to categorize network securi= ty functions provided by different vendors based on security policy provisi= oning capability without any need to standardize security functions themsel= ves. Standard provisioning capability interface is an essential building b= lock for Security Service Provider to automate their Security Controllers t= hat can utilize NSF by multiple vendors. This layer will leverage the exist= ing 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 clien= ts and demonstrating the feasibility of them being translated to the Capabi= lity Layer policies. Since different security vendors support different features & functions on = their devices, I2NSF will focus on flow based security functions that provi= de 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 Base= d Security functions include deep packet inspection, packet/flow/stream fil= tering or pattern matching and remediation, etc. Similar to I2RS focusing on the interface to RIB/FIB even though most route= rs 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 I2N= SF interfaces. I2NSF WG Deliverables include: - Use Case document. - Framework Document. - Requirement for extensions (if there are any) to existing protoc= ols 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 ab= ove Information Model. - IANA registry consideration for flow based security function pol= icy provisioning capability. - (Optionally) Applicability Statements on how to use I2RS, Netco= nf, and NETMOD to carry the content of the specified information/data model= s. [The WG may decide that the Use cases, Framework, and Requirement are Infor= mational 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 W= G 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 com= municate with external SDOs like ETSI NFV and will encourage open source co= de development related to the WG scope in organizations like ONF, OpenStack= , ODL, and OpenNFV. Cheers, Linda Dunbar __________________________________________= _____ I2nsf mailing list I2nsf@ietf.org 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: diego.r.lopez@telefonica.com Tel: +34 913 129 041 Mobile: +34 682 051 091 ---------------------------------- ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o= copia sin autorizaci=F3n puede estar prohibida en virtud de la legislaci= =F3n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo = comunique inmediatamente por esta misma v=EDa y proceda a su destrucci=F3n. The information contained in this transmission is privileged and confidenti= al 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 co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, div= ulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o pode estar proibida em virtude= da legisla=E7=E3o vigente. Se recebeu esta mensagem por erro, rogamos-lhe = que nos o comunique imediatamente por esta mesma via e proceda a sua destru= i=E7=E3o --_000_B818037A70EDCC4A86113DA25EC02098200B5351SJCEML701CHMchi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I’m confused.<= /o:p>

 <= /p>

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

 <= /p>

“…Thes= e trends require a standard interface to express, monitor, and manage secur= ity 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 func= tional layers:
- Security Service and Policy Layer
- Capability (or Functional) Layer”

 <= /p>

This is from the first tw= o paragraphs.

 <= /p>

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

 <= /p>

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

-       = ;   Security Policies facing security functions (I2NSF = Capability Layer)

-       = ;   Security Policies facing clients (I2NSF Service Lay= er)

 <= /p>

Therefore, please explain= what “overuse of the term policy” means (Diego), and why you b= elieve that my edits “focused around policies” (Dan). I would a= lso like to understand what “alternative mechanisms” to policy you woul= d like to propose.

 <= /p>

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

 <= /p>

 <= /p>

regards,<= /p>

John

 

Dr. John Strassner, Ph.D.

CTO, Software Laboratory, C= RD

3D"logo.gi=

 

Futurewei Technologies=

US R&D Center=

2330 Central Expressway Building A, office A2-2143

Santa Clara, California&n= bsp;  95050

  Office:  +1.408.330.4923

  Email:   john.sc.strassner@huawei.com

 

 

 <= /p>

From: I2nsf [m= ailto:i2nsf-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Thursday, May 14, 2015 12:34 AM
To: DIEGO LOPEZ GARCIA; John Strassner
Cc: i2nsf@ietf.org; Kathleen Moriarty; Linda Dunbar
Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new char= ter for IETF 93

 

(speaking as contributor)=

 <= /p>

I agree with Diego’= s observation. I also agree and like many of the edits proposed by John, bu= t 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 shou= ld not IMO exclude policy, but neither should make of it the central (or ex= clusive) focus.

 <= /p>

Regards,

 <= /p>

Dan

 <= /p>

 <= /p>

From: I2nsf [m= ailto:i2nsf-bounces@ietf.org] On Behalf Of DIEGO LOPEZ GARCIA
Sent: Thursday, May 14, 2015 1:06 AM
To: John Strassner
Cc: i2nsf@ietf.org; Kathleen Moriarty; Linda Dunbar
Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new char= ter for IETF 93
Importance: High

 

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 difficu= lt to be understood by the community. I'd leave the primary goal definition as:

 

"The primary goal of I2NSF is to define an exte= nsible 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 d= ocuments, and let further development for a later stage.

 

Be goode,

 

On 13 May 2015, at 19:18 , John Strassner <John.sc.Strassner@huawei.com&= gt; wrote:

 

Dear Linda,

 

First, thank you for pull= ing together these changes. The charter development has progressed nicely.<= /span>

 

Second, attached is a wor= d document with my edits and suggestions for consideration by the working g= roup. 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

 <= o:p>

Dr. John Strassner, Ph.D.

CTO, Software Laboratory, C= RD

<image001.gif>

 

Futurewei Technologies=

US R&D Center

2330 Central Expressway Building A, office A2-2143

Santa Clara, California&n= bsp;  95050

  Office:  +1.408.330.4923

  Email:   john.sc.strassner@huawei.com=

 <= o:p>

 <= o:p>

 

From: I2nsf [ma= ilto:i2nsf-bounces@ietf.org] On Behalf Of <= /span>Linda Dunbar
Sent: Thursday, Ma= y 07, 2015 8:53 AM
To: i2nsf@ietf.org;= Kathleen Moriarty
Cc: i2rs@ietf.org; dots@ietf.org; netmod@ietf.org
Subject: [I2nsf] F= urther Narrowing the I2NSF scope: the new charter for IETF 93

 

Thanks to I2NSF contributors for the go= od progresses made since  IETF92 side meetings. Among the two I2NSF in= terfaces,  i.e. the client facing Service Interface and the NSF facing Capability Interface, the work to be done at the Capability Interfa= ce becomes very clear and concrete. But the Service Interface is still a li= ttle vague.

 

The feedback from last IETF side meetin= gs 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 Se= rvice Provider to automate their Security Controller that can utilize NSF by multiple vendors

 

Here is the narrower scoped I2NSF chart= er. Your comments and suggestions are greatly appreciated. CC’ed to D= OTS, I2RS, and Netmod groups for wider review.

 

 

 

Enterprises, residential, and mobile cu= stomers are increasingly consuming network functions, especially network se= curity related functions that are not running on their premises.  In addition, the European Telecommunications Standards Institute (ETSI) Ne= twork Function Virtualization (NFV) initiative creates new management chall= enges for security policies to be enforced by distributed, virtual, network= security functions (vNSF). Without standard interface to express, monitor, and manage security policies to se= curity functions deployed at different premises, it becomes virtually impos= sible for security service providers to automate the service offering utili= zing 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 perform= ance data or report out of NSF or vNSF.

 

There are two layers of interfaces:

-       &nb= sp;  Security Policies facing security functions (I2NSF Capability Layer)

-       &nb= sp;  Security Policies facing clients (I2NSF Service Layer)

 

The I2NSF Capability Layer specifies th= e functional security policies, which are translated from the client securi= ty policies, to security functions. I2NSF will NOT standardize security functions or devices. Instead, I2NSF is only to standardize the p= olicy provisioning to the security functions (not devices), in the form of = “Subject – Object – Function – Action” paradi= gm. 

 

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 se= curity expertise.

 

The concrete work at the L2NSF Capabili= ty Layer includes

-       &nb= sp;  The informational & data models for each category to be represented to vir= tual or physical network security functions,

-       &nb= sp;  The capability registry (IANA) of policy provisioning capability to flow based= security function, and

-       &nb= sp;  The proper secure communication channels to carry the security policies betwee= n Controller and NSFs.

The capability registry is to make it f= easible to categorize network security functions provided by different vend= ors based on security policy provisioning capability without any need to standardize security functions themselves.  Standard prov= isioning capability interface is an essential building block for Security S= ervice 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 faci= ng 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 suppor= t 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 oth= er security functions such as Authentication, Authorization, or Encryption)= . Exemplar services associated with Flow Based Security functions include d= eep packet inspection, packet/flow/stream filtering or pattern matching and remediation, etc.

 

Similar to I2RS focusing on the interfa= ce 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 protocol= s or data modeling languages for I2NSF interfaces.

I2NSF WG Deliverables include:

 

-       &nb= sp;   Use Case document.

-       &nb= sp;  Framework Document.

-       &nb= sp;  Requirement for extensions (if there are any) to existing protocols used by the WG.

-       &nb= sp;   Gap analysis of existing protocols and modeling languages

-       &nb= sp;  A single, unified, Information Model for expressing policies to the Flow Bas= ed Security Functions described above.

-       &nb= sp;  Corresponding Data Models (e.g. YANG models) derived from the above Information Model.

-       &nb= sp;  IANA registry consideration for flow based security function policy provisionin= g capability.

-       &nb= sp;   (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 Info= rmational documents or simply reference documents during the lifetime of the WG. The = framework, that describes the functional components and the I2NSF work item= s, is to make I2NSF work more organized.]

 

Suggested Milestones<= /p>

  - Use Case Document:  Chart= er 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 &#= 43; 10 months to WG Document

  - All Early Drafts to IESG: 10 m= onths

 

[decision point – +10 months]=  

  - Data Models: Charter += ; 9 Months to WG Document

  - Applicability Statements: 10 m= onths to WG Document

  - Data Models and Applicability = Statements to IESG  - 16 months

 

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

 

 

Cheers,

Linda Dunbar

<i2nsf charter-jcs-20150512.docx>_= ______________________________________________
I2nsf mailing list
I2nsf@ietf.o= rg
https://www.ietf.org/mailman/lis= tinfo/i2nsf

 

--
"Esta vez no fallaremos, Doctor Infierno"

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

e-mail: diego.r.lopez@telef= onica.com
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------

 

 


Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o copia sin autorizaci=F3n puede e= star prohibida en virtud de la legislaci=F3n vigente. Si ha recibido este m= ensaje por error, le rogamos que nos lo comunique inmediatamente por esta m= isma v=EDa y proceda a su destrucci=F3n.

The information contained in this transmission is privileged and confidenti= al 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 y= ou have received this transmission in error, do not read it. Please immedia= tely 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=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, divulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o p= ode estar proibida em virtude da legisla=E7=E3o vigente. Se recebeu esta me= nsagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mes= ma via e proceda a sua destrui=E7=E3o

--_000_B818037A70EDCC4A86113DA25EC02098200B5351SJCEML701CHMchi_-- --_004_B818037A70EDCC4A86113DA25EC02098200B5351SJCEML701CHMchi_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif"; size=2669; creation-date="Fri, 15 May 2015 06:07:03 GMT"; modification-date="Fri, 15 May 2015 06:07:03 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhMgAyAPf/AO3b2elrUvbKwuNBIPa0g/GUa8WJguZWOfGjk8zMzKguI7Ozs/Hx8e+Pe6ZE OeZcQvvi3f39/eXl5et5YnNzc8lGNvj4+NU5I+6JdfS3qudZPfvl4OSimoyMjOlpTOx3VPSkdvnH lODg4JSUlKOjo/W4rBsbG+jo6NSDe9HR0fOfc9bW1p4uIvPj4f729ODAvP77+rkxJMuVj/749u6N e/nUzVNTU/jOxfGZhNRKOHh4eNnZ2e+Tgfa5ieM/IP3w7sQ0JOhhRuRAKcLCwjs7OzIyMuM8IOVR MelmTPb29uVNMUBAQPKuoQoKCvv7+xQUFCoqKktLS+WNgfr6+vrVxNZ4bvKpmZiYmPW9spcrH++L ZcGAeSMjI+ZRNPjRyPCXhfbBt7u7u/rd1vzq5803JK6urvWuf/nZ0uRGLeM9JfOlefa7mmNjY/fG vei7t9k7Iut3Xvrf2eRKKoaGhuREK/308vT09OVPL+2Gcv3y72xsbPOrnGhoaPrg25ycnP3v7PbF u7RGO6qqqlxcXO23sOZPNPGejfSoefv49t89Ifny8fjKtO2CXupxWO29uLdrY/XBuYGBgfzp4eyB av76+fOzpv75+Pbs6+tzYO3t7fjBjvCYifOwot3d3adLQe2Cbfzs6Prs6/bZ1eA+IeQ9JcbGxu/B u/Onm+S+uuhkR+M/H+VKL+yupeM8IvW7r+x7V/CPaP37+/Gdiex9Z9A5Jfra1O2FbtarpvnTzPfI v+x/WudcP+RHJ9w7IeVLMONDIudfRedXP+RCK//9/PnX0Pzt6v/+/fzu6/KXbvnQv+ZUN/nw7+x2 W967t+6cj+zGwvbQy/Pn5u+HYvfCr/Otl+M+I/OvnuvRzueAcPWwi/vt7PCMZ/zr6OhgQ/a/tvTW 0uNFI7BgV68vI+NEK+NELNxVQOydkelkRPnXyfa8o/vo5P3u5vWpfuZPOfa1kvSwn7pya757c+LG wuXIxf/8/OfNyuzLyPS0qOM7I+pxXvK9tepwT+NAIONCIAAAAP///yH5BAEAAP8ALAAAAAAyADIA QAj/AP8JHEiwoMBh6rydckHQmKRFkiwZM0ixosBin/o1mCHwz4R+/fgZaSVs1YFUoIxN24ZMBYiX KpDBSjawTwA6WIZZvOGDH78BIIPu2iDgSNCQPmjMECZE2DhyaNDMMnaKVCsjRvgdDfCH4KMs4mKQ ufBm1CwBM7B4ABr0C71GIMHAgAvOVZ4DR8FhiFPMSrejIJU0IBjhEoDD367Ze2bKEaFKTBDwqKHT YB1Om5hUKoEFUK4buGr1gQAhDiWLqFOrXm3ChB2BQ/wN+qfD35IRFJ5w2RHF35AkSSwsaTIk0xN/ UCT8u+LPnx6BYaA0icKHjR4GV55YWP0vToB+Poyk/0HTZZcXgTDWqCGgKYQmAocWTeQuEMKdn0cR wNjwHaTIVkKswgQMcKTiwT4IJvjOP9xM4IswaRjhwwANMDRQFVWg9c8xs/ikFWBg4IJXUIZQ0kVQ v0xSBxyABaUMJ/VZ0UglAlFiQBYsKBADEGP1MkpPvtCwwQ8ZBIEBDH0wtEEdtXSBAS6UYAFXiwN4 qIwAFrWwRRZcchkOKsvQJ1Af5uRwAS20kJEDIZZQ1JoEdliwgD98SMDFEicINIc/I/yThAk2dOCP HxEwNwdtTRBhQikMLFGEBHz4Q8I/FlQawQja0UdPJQdUkwYdSvDQpkDHqKAGO2aYscY6YhpkDEcD Df9jC0jhjVfILg3Q848kyIBgRg+a9ACfClQQBAMMqp2hRFBB1CCQLL/QKh6oB9xADw6vMCKNFtxK w0gDYvwDwx7KoJFGK5/kUdEePrEVFBx14KJBUPyER8omlGjQxQEa9NvvYG0EQ8e5WYF0BCgUzcBu u4DJQQwgdwDGwwxyhIeVEZjU0YCEHx51AAQFOSAOj+U4A3KRPgFmxRh/gbQHDC2Dg8MMQbT4yycg tzFJUEcE8E80DmShI48X+OgDMEwUUwMe0fZDwz+y9FMLPRjI0Yc6RvWzyx6gnIEBLy2GpMomBcXy QjwODN1jIj/21EgNuhY0DAwI3DHA3Xh7yA8vASD/EG5Fl8DTJZcshAUEEDmwcgxqxhCDR08+RD7K KIn08sYF+py2Wh2XhNmqQZaEoo3mFXEBRRIClfKEHhIUYYNy/3TwhB8CnVDEEx38s8ITRAi0Ahcm RCKQICZQsBwXTSTfxAkkmLAd8npQQIENztmJp0CC0k4EnZFw4c8CFtjwRBlP8HGCCVEIOmlvg0Si gw6R2OFHpvQNQwwGwbSzCi4EUZIOMuxwBxVI9zmLGOMeXagVGgqBhB8chAq+IkAPeqAqdRWwIgiI lgLLYw2duEANh2BPCEIAn2xI4oK1QIA6BnKMj4BnWoXQADNmYAx0FEAFh0iVGQ6hggLQZCBguEcd /1JDjz2A5A6VmAglZtWPAfgAQOTZhRiGQQ1GaKEAyMhiAWCxjWL9wwV4WIUQ2nEGi7igAR3rxwTU hYWsDQArQligK2Bgi3184BW6yOMrPiALdQkACWK8ygCcRRFAMCwoGrjBP3gADpA4cVr6QcIuunGO c6QiFeeAQw0sIQtfDAwrWklFVwzCCQ+5y2X/sEXTqhQeURUCDb5QQiFm+YA25CEfQoiQhFyEMIOA IhimlJgxZgEYCrmADkbARxrSQAo0uEIdwcBKTwCDgFEJpAWhEEgdOpQywMDBBZNoGki+QAm71csH qwADMXiBH8AcwRWViQMi/hGIGFRACtD4hyV4IP+HbjLLBYwMin5G1I8D1AAMYetHKsDwjz+UgC5B +EfadkSLNwTgHjPoAwZ+ccou/KASjexHBmDgAZCk4hicaNEuOGEMMfAgYiD5xRFS8Y9b4GhkPRpF qCCgDkOcCCRygMAZImatnc3iH4Y4SiPAkAcwTAkwqngAyGrKJbUVrW1waEMdAMGMfvxCDHVoBATo YQhD/OML/TjCF+IACgTMi0o+AcYGCKIIGbCgcDta2yjqFYQ9GAMCGbBQTeYYB1vIAa4eCkAuLIII AMwDFW5whCNMAYnKggELlaAMRergihKAoQ1tyEUuQAsIQAgAFytETT0c4InWeiIQgaiAbHPwhjf/ 0GAMFYGBAIDBDzkoQQldUAa/dvEAYDwAGw7M0lcGlyNxoOAb3PkBFoCRiOpa7nK0YEVlUqMIeRjg EVtoRjQuOANRcABDHBDFdi/IXu7sYAcREEgSEiABJ+ygE06oXQIyMZBOpGA7DEgB7KYgghUwQCAW WAF+/8GAHaTgwU7IxAoE8gTnpc4fbJCACYgAuz316R+RSJ4JGJCEIjRhwnPyRxTyS4HvLaAJXBjB AsoAvuw8zx+tMcFxWHenPP3Dw/8YgT/C8A8TQCECIvAHESxAhCIIwh8dSEETKGCB3uTYyCeY33ZM wIVKWSA2bLAdFBIQ3xaHgXxPeEITTKDkf5QBSjlPEEQE2LDmIuzgH4OQVAScMIX8Ymo7RSDCa/6R gNX9QwR8MEHyijCEFbjOx/9ong4ioIcn2CB1UDDBpASygCWoec0nEEQRthMQADs= --_004_B818037A70EDCC4A86113DA25EC02098200B5351SJCEML701CHMchi_-- From nobody Fri May 15 08:09:45 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE3A11A92E9 for ; Fri, 15 May 2015 08:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7QfDHHd79YEZ for ; Fri, 15 May 2015 08:09:40 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBB971A92B5 for ; Fri, 15 May 2015 08:09:39 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BWB82464; Fri, 15 May 2015 15:09:38 +0000 (GMT) Received: from DFWEML703-CHM.china.huawei.com (10.193.5.130) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 15 May 2015 16:09:37 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml703-chm ([10.193.5.130]) with mapi id 14.03.0158.001; Fri, 15 May 2015 08:09:34 -0700 From: Linda Dunbar To: "Zarny, Myo" , "'i2nsf@ietf.org'" , "'Kathleen Moriarty'" Thread-Topic: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93 Thread-Index: AQHQinCAWnYgWx+c3k2SduRLi+ubTp16jRzwgAF1EICAASqv4A== Date: Fri, 15 May 2015 15:09:33 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657C15649@dfweml701-chm> References: <4A95BA014132FF49AE685FAB4B9F17F657C11DC6@dfweml701-chm> <4A95BA014132FF49AE685FAB4B9F17F657C147B9@dfweml701-chm> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.138.20] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657C15649dfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93 X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2015 15:09:43 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F657C15649dfweml701chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Myo, Thanks, From: Linda Dunbar [mailto:linda.dunbar@huawei.com] Sent: 13 May 2015 7:10 PM To: Zarny, Myo [Tech]; 'i2nsf@ietf.org'; 'Kathleen Moriarty' Subject: RE: [I2nsf] Further Narrowing the I2NSF scope: the new charter for= IETF 93 Myo, Thanks for taking the stab at the rewording. A couple of questions inserted below for your wording: From: Zarny, Myo [mailto:Myo.Zarny@gs.com] 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 NS= Fs such as device or [Linda] Can we remove the "management aspects of NSFs" from the I2NSF chart= er? I2NSF only "focuses on the "policy provisioning aspect of NSFs". Manage= ment aspects of NSFs can include many different aspects of provisioning, ma= y be too broad for I2NSF. Myo: I'll defer to the community on the question of how narrow the scope s= hould be. But seems to me, we'll need to add at least some "management" wor= k (monitoring, policy/config discovery, etc.)-even if it's just to facilita= te policy provisioning. It doesn't make sense to me that we'll use I2NSF in= terfaces for "policy provisioning" but have to switch to proprietary vendor= specific APIs to discover what the current policies happen to be, or if th= e policies we pushed are successful!? [Linda] Do you think the following captures what you want? " The primary goal of I2NSF is to define a set of interfaces and data model= s for policy provisioning and monitoring aspects of NSFs. Other aspects of = NSFs such as device or network provisioning are out of scope." Linda --_000_4A95BA014132FF49AE685FAB4B9F17F657C15649dfweml701chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Myo,

 

Thanks,

 

 

 

 

From: Linda Dunbar [mailto:linda.dunbar@huawei.com]
Sent: 13 May 2015 7:10 PM
To: Zarny, Myo [Tech]; 'i2nsf@ietf.org'; 'Kathleen Moriarty'
Subject: RE: [I2nsf] Further Narrowing the I2NSF scope: the new char= ter for IETF 93

 

Myo,

 

Thanks for taking the stab at the rewording.

 

A couple of questions inserted below for your wording:

 

 

 

From: Zarny, Myo [mailto:Myo.Zarny@gs.com]

 

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

 

[Linda] Can we remove the “management aspects of NSFs” fro= m the I2NSF charter? I2NSF only “focuses on the “policy provisi= oning aspect of NSFs”. Management aspects of NSFs can include many different aspects of provisioning, may be too broad for I2NSF. <= /o:p>

Myo:  I’ll defer to the community on the question of how na= rrow 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 &#= 8220;policy provisioning” but have to switch to proprietary vendor sp= ecific APIs to discover what the current policies happen to be, or if the policies we pushed are successful!?

 

[Linda] Do you think t= he following captures what you want?

“ The primary go= al of I2NSF is to define a set of interfaces and data models for policy pro= visioning and monitoring aspects of NSFs. Other aspects of NSFs such as device or network provisioning are out of scope.&#= 8221;

 

 

Linda

--_000_4A95BA014132FF49AE685FAB4B9F17F657C15649dfweml701chm_-- From nobody Fri May 15 09:03:06 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8537D1A049A for ; Fri, 15 May 2015 09:03:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.221 X-Spam-Level: X-Spam-Status: No, score=-2.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H5Oa7iFkziRn for ; Fri, 15 May 2015 09:02:51 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCF921A03AA for ; Fri, 15 May 2015 09:02:49 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BSO72930; Fri, 15 May 2015 16:02:46 +0000 (GMT) Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 15 May 2015 17:02:23 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml705-chm ([10.193.5.142]) with mapi id 14.03.0158.001; Fri, 15 May 2015 09:02:15 -0700 From: Linda Dunbar To: John Strassner , "Romascanu, Dan (Dan)" , DIEGO LOPEZ GARCIA Thread-Topic: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93 Thread-Index: AQHQjaDRAEUQzCWWZUivn8zkhCvIvJ167AoAgACewQCAAXoGAIAALJYQ Date: Fri, 15 May 2015 16:02:15 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657C156AA@dfweml701-chm> References: <4A95BA014132FF49AE685FAB4B9F17F657C11DC6@dfweml701-chm> <3AF7BE6A-DD17-4C1C-9F31-42C6D2AB99B5@telefonica.com> <9904FB1B0159DA42B0B887B7FA8119CA5CA2E131@AZ-FFEXMB04.global.avaya.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.47.138.20] Content-Type: multipart/related; boundary="_004_4A95BA014132FF49AE685FAB4B9F17F657C156AAdfweml701chm_"; type="multipart/alternative" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "i2nsf@ietf.org" , Kathleen Moriarty Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93 X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2015 16:03:05 -0000 --_004_4A95BA014132FF49AE685FAB4B9F17F657C156AAdfweml701chm_ Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657C156AAdfweml701chm_" --_000_4A95BA014132FF49AE685FAB4B9F17F657C156AAdfweml701chm_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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 m= odels and software interfaces for specifying, representing, querying, monit= oring, and controlling NSFs. Management of NSFs should include communicatin= g, querying, and changing the configuration of NSFs by one or more manageme= nt 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 aspe= cts of NSFs such as device or network provisioning are out of scope. This s= hould include an information model and a set of data models and software in= terfaces for specifying, representing, querying, monitoring, and controllin= g 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: i2nsf@ietf.org; Kathleen Moriarty; Linda Dunbar Subject: RE: [I2nsf] Further Narrowing the I2NSF scope: the new charter for= IETF 93 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 mana= ge security policies for physical and virtual distributed security function= s that may be running on different premises. In order to address the above challenges, vNSF devices may include two func= tional 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 u= ntouched) by my edits: There are two layers of interfaces envisioned in the I2NSF approach: - Security Policies facing security functions (I2NSF Capability La= yer) - Security Policies facing clients (I2NSF Service 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 l= ike to propose. I'm certainly for consensus, and would like to help agree on the charter as= ap; I just don't understand what in my edits made people think that it is n= ow too focused on policy, given the existing starting text. regards, John Dr. John Strassner, Ph.D. CTO, Software Laboratory, CRD [logo.gif] Futurewei Technologies US R&D Center 2330 Central Expressway Building A, office A2-2143 Santa Clara, California 95050 Office: +1.408.330.4923 Email: john.sc.strassner@huawei.com From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Romascanu, Dan (Da= n) Sent: Thursday, May 14, 2015 12:34 AM To: DIEGO LOPEZ GARCIA; John Strassner Cc: i2nsf@ietf.org; Kathleen Moriarty; Linda Dunbar Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new charter for= IETF 93 (speaking as contributor) I agree with Diego's observation. I also agree and like many of the edits p= roposed by John, but I do not believe that the scope should be focused arou= nd policies. Policies may be the right paradigm at certain layers, but they= are not the only method for interoperable access and management of NSFs. T= he work should not IMO exclude policy, but neither should make of it the ce= ntral (or exclusive) focus. Regards, Dan From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of DIEGO LOPEZ GARCIA Sent: Thursday, May 14, 2015 1:06 AM To: John Strassner Cc: i2nsf@ietf.org; Kathleen Moriarty; Linda Dunbar Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new charter for= IETF 93 Importance: High 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 th= e term "policy" in the document. The text talks about policy at two many la= yers and can become misleading and difficult to be understood by the commun= ity. I'd leave the primary goal definition as: "The primary goal of I2NSF is to define an extensible framework for managin= g 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 furth= er development for a later stage. Be goode, On 13 May 2015, at 19:18 , John Strassner > wrote: Dear Linda, First, thank you for pulling together these changes. The charter developmen= t has progressed nicely. Second, attached is a word document with my edits and suggestions for consi= deration by the working group. Despite the large number of edits and commen= ts, I am very supportive of I2NSF being made a working group, and would lik= e to volunteer to work on its deliverables. My edits and comments are to ad= dress 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: john.sc.strassner@huawei.com From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Thursday, May 07, 2015 8:53 AM To: i2nsf@ietf.org; Kathleen Moriarty Cc: i2rs@ietf.org; dots@ietf.org; netmod@ietf.org Subject: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IET= F 93 Thanks to I2NSF contributors for the good progresses made since IETF92 sid= e 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 I= nterface 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 t= he Capability Interface. The thinking logic is: Once the Capability Interfa= ce is completed, we will see more clearly the work for Service interface. E= ven if Capability layer alone is standardized, it is a giant leap forward i= n building blocks for Service Provider to automate their Security Controlle= r that can utilize NSF by multiple vendors Here is the narrower scoped I2NSF charter. Your comments and suggestions ar= e greatly appreciated. CC'ed to DOTS, I2RS, and Netmod groups for wider rev= iew. Enterprises, residential, and mobile customers are increasingly consuming n= etwork functions, especially network security related functions that are no= t 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 i= nterface to express, monitor, and manage security policies to security func= tions deployed at different premises, it becomes virtually impossible for s= ecurity service providers to automate the service offering utilizing securi= ty functions by multiple vendors. The ultimate goal of I2NSF is to enable enterprises to utilize security fun= ctions not hosted on their own premises but instead hosted in service provi= der domain, to establish how to communicate desired security policies to NS= F 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 La= yer) - Security Policies facing clients (I2NSF Service Layer) The I2NSF Capability Layer specifies the functional security policies, whic= h 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 poli= cies 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 represen= ted 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 p= olicies between Controller and NSFs. The capability registry is to make it feasible to categorize network securi= ty functions provided by different vendors based on security policy provisi= oning capability without any need to standardize security functions themsel= ves. Standard provisioning capability interface is an essential building b= lock for Security Service Provider to automate their Security Controllers t= hat can utilize NSF by multiple vendors. This layer will leverage the exist= ing 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 clien= ts and demonstrating the feasibility of them being translated to the Capabi= lity Layer policies. Since different security vendors support different features & functions on = their devices, I2NSF will focus on flow based security functions that provi= de 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 Base= d Security functions include deep packet inspection, packet/flow/stream fil= tering or pattern matching and remediation, etc. Similar to I2RS focusing on the interface to RIB/FIB even though most route= rs 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 I2N= SF interfaces. I2NSF WG Deliverables include: - Use Case document. - Framework Document. - Requirement for extensions (if there are any) to existing protoc= ols 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 ab= ove Information Model. - IANA registry consideration for flow based security function pol= icy provisioning capability. - (Optionally) Applicability Statements on how to use I2RS, Netco= nf, and NETMOD to carry the content of the specified information/data model= s. [The WG may decide that the Use cases, Framework, and Requirement are Infor= mational 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 W= G 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 com= municate with external SDOs like ETSI NFV and will encourage open source co= de development related to the WG scope in organizations like ONF, OpenStack= , ODL, and OpenNFV. Cheers, Linda Dunbar __________________________________________= _____ I2nsf mailing list I2nsf@ietf.org 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: diego.r.lopez@telefonica.com Tel: +34 913 129 041 Mobile: +34 682 051 091 ---------------------------------- ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o= copia sin autorizaci=F3n puede estar prohibida en virtud de la legislaci= =F3n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo = comunique inmediatamente por esta misma v=EDa y proceda a su destrucci=F3n. The information contained in this transmission is privileged and confidenti= al 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 co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, div= ulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o pode estar proibida em virtude= da legisla=E7=E3o vigente. Se recebeu esta mensagem por erro, rogamos-lhe = que nos o comunique imediatamente por esta mesma via e proceda a sua destru= i=E7=E3o --_000_4A95BA014132FF49AE685FAB4B9F17F657C156AAdfweml701chm_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

 <= /p>

John,

 <= /p>

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

 <= /p>

“The primary goal o= f 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 commun= icating, querying, and changing the configuration of NSFs by one or more ma= nagement entities”

 

 

Do you think the followin= g 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. T= his should include an information model and a set of data models and softwa= re interfaces for specifying, representing, querying, monitoring, and contr= olling security policy aspects of NSFs by one or more management entities.

 <= /p>

 <= /p>

Linda

From: John Str= assner
Sent: Friday, May 15, 2015 1:07 AM
To: Romascanu, Dan (Dan); DIEGO LOPEZ GARCIA
Cc: i2nsf@ietf.org; Kathleen Moriarty; Linda Dunbar
Subject: RE: [I2nsf] Further Narrowing the I2NSF scope: the new char= ter for IETF 93

 

I’m confused.<= /o:p>

 <= /p>

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

 <= /p>

“…Thes= e trends require a standard interface to express, monitor, and manage secur= ity 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 func= tional layers:
- Security Service and Policy Layer
- Capability (or Functional) Layer”

 <= /p>

This is from the first tw= o paragraphs.

 <= /p>

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

 <= /p>

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

-       = ;   Security Policies facing security functions (I2NSF = Capability Layer)

-       = ;   Security Policies facing clients (I2NSF Service Lay= er)

 <= /p>

Therefore, please explain= what “overuse of the term policy” means (Diego), and why you b= elieve that my edits “focused around policies” (Dan). I would a= lso like to understand what “alternative mechanisms” to policy you woul= d like to propose.

 <= /p>

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

 <= /p>

 <= /p>

regards,<= /p>

John

 

Dr. John Strassner, Ph.D.

CTO, Software Laboratory, C= RD

 

Futurewei Technologies=

US R&D Center=

2330 Central Expressway Building A, office A2-2143

Santa Clara, California&n= bsp;  95050

  Office:  +1.408.330.4923

  Email:   jo= hn.sc.strassner@huawei.com

 

 

 <= /p>

From: I2nsf [<= a href=3D"mailto:i2nsf-bounces@ietf.org">mailto:i2nsf-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Thursday, May 14, 2015 12:34 AM
To: DIEGO LOPEZ GARCIA; John Strassner
Cc: i2nsf@ietf.org; Kathleen M= oriarty; Linda Dunbar
Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new char= ter for IETF 93

 

(speaking as contributor)=

 <= /p>

I agree with Diego’= s observation. I also agree and like many of the edits proposed by John, bu= t 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 shou= ld not IMO exclude policy, but neither should make of it the central (or ex= clusive) focus.

 <= /p>

Regards,

 <= /p>

Dan

 <= /p>

 <= /p>

From: I2nsf [<= a href=3D"mailto:i2nsf-bounces@ietf.org">mailto:i2nsf-bounces@ietf.org] On Behalf Of DIEGO LOPEZ GARCIA
Sent: Thursday, May 14, 2015 1:06 AM
To: John Strassner
Cc: i2nsf@ietf.org; Kathleen M= oriarty; Linda Dunbar
Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new char= ter for IETF 93
Importance: High

 

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 difficu= lt to be understood by the community. I'd leave the primary goal definition as:

 

"The primary goal of I2NSF is to define an exte= nsible 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 d= ocuments, and let further development for a later stage.

 

Be goode,

 

On 13 May 2015, at 19:18 , John Strassner <John.sc.Strassner@huawei.com&= gt; wrote:

 

Dear Linda,

 

First, thank you for pull= ing together these changes. The charter development has progressed nicely.<= /span>

 

Second, attached is a wor= d document with my edits and suggestions for consideration by the working g= roup. 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

 <= o:p>

Dr. John Strassner, Ph.D.

CTO, Software Laboratory, C= RD

<image001.gif>

 

Futurewei Technologies=

US R&D Center

2330 Central Expressway Building A, office A2-2143

Santa Clara, California&n= bsp;  95050

  Office:  +1.408.330.4923

  Email:   john.sc.strassner@huawei.com=

 <= o:p>

 <= o:p>

 

From: I2nsf [ma= ilto:i2nsf-bounces@ietf.org] On Behalf Of <= /span>Linda Dunbar
Sent: Thursday, Ma= y 07, 2015 8:53 AM
To: i2nsf@ietf.org;= Kathleen Moriarty
Cc: i2rs@ietf.org; dots@ietf.org; netmod@ietf.org
Subject: [I2nsf] F= urther Narrowing the I2NSF scope: the new charter for IETF 93

 

Thanks to I2NSF contributors for the go= od progresses made since  IETF92 side meetings. Among the two I2NSF in= terfaces,  i.e. the client facing Service Interface and the NSF facing Capability Interface, the work to be done at the Capability Interfa= ce becomes very clear and concrete. But the Service Interface is still a li= ttle vague.

 

The feedback from last IETF side meetin= gs 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 Se= rvice Provider to automate their Security Controller that can utilize NSF by multiple vendors

 

Here is the narrower scoped I2NSF chart= er. Your comments and suggestions are greatly appreciated. CC’ed to D= OTS, I2RS, and Netmod groups for wider review.

 

 

 

Enterprises, residential, and mobile cu= stomers are increasingly consuming network functions, especially network se= curity related functions that are not running on their premises.  In addition, the European Telecommunications Standards Institute (ETSI) Ne= twork Function Virtualization (NFV) initiative creates new management chall= enges for security policies to be enforced by distributed, virtual, network= security functions (vNSF). Without standard interface to express, monitor, and manage security policies to se= curity functions deployed at different premises, it becomes virtually impos= sible for security service providers to automate the service offering utili= zing 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 perform= ance data or report out of NSF or vNSF.

 

There are two layers of interfaces:

-       &nb= sp;  Security Policies facing security functions (I2NSF Capability Layer)

-       &nb= sp;  Security Policies facing clients (I2NSF Service Layer)

 

The I2NSF Capability Layer specifies th= e functional security policies, which are translated from the client securi= ty policies, to security functions. I2NSF will NOT standardize security functions or devices. Instead, I2NSF is only to standardize the p= olicy provisioning to the security functions (not devices), in the form of = “Subject – Object – Function – Action” paradi= gm. 

 

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 se= curity expertise.

 

The concrete work at the L2NSF Capabili= ty Layer includes

-       &nb= sp;  The informational & data models for each category to be represented to vir= tual or physical network security functions,

-       &nb= sp;  The capability registry (IANA) of policy provisioning capability to flow based= security function, and

-       &nb= sp;  The proper secure communication channels to carry the security policies betwee= n Controller and NSFs.

The capability registry is to make it f= easible to categorize network security functions provided by different vend= ors based on security policy provisioning capability without any need to standardize security functions themselves.  Standard prov= isioning capability interface is an essential building block for Security S= ervice 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 faci= ng 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 suppor= t 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 oth= er security functions such as Authentication, Authorization, or Encryption)= . Exemplar services associated with Flow Based Security functions include d= eep packet inspection, packet/flow/stream filtering or pattern matching and remediation, etc.

 

Similar to I2RS focusing on the interfa= ce 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 protocol= s or data modeling languages for I2NSF interfaces.

I2NSF WG Deliverables include:

 

-       &nb= sp;   Use Case document.

-       &nb= sp;  Framework Document.

-       &nb= sp;  Requirement for extensions (if there are any) to existing protocols used by the WG.

-       &nb= sp;   Gap analysis of existing protocols and modeling languages

-       &nb= sp;  A single, unified, Information Model for expressing policies to the Flow Bas= ed Security Functions described above.

-       &nb= sp;  Corresponding Data Models (e.g. YANG models) derived from the above Information Model.

-       &nb= sp;  IANA registry consideration for flow based security function policy provisionin= g capability.

-       &nb= sp;   (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 Info= rmational documents or simply reference documents during the lifetime of the WG. The = framework, that describes the functional components and the I2NSF work item= s, is to make I2NSF work more organized.]

 

Suggested Milestones<= /p>

  - Use Case Document:  Chart= er 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 &#= 43; 10 months to WG Document

  - All Early Drafts to IESG: 10 m= onths

 

[decision point – +10 months]=  

  - Data Models: Charter += ; 9 Months to WG Document

  - Applicability Statements: 10 m= onths to WG Document

  - Data Models and Applicability = Statements to IESG  - 16 months

 

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

 

 

Cheers,

Linda Dunbar

<i2nsf charter-jcs-20150512.docx>_______________________________= ________________
I2nsf mailing list
I2nsf@ietf.o= rg
https://www.ietf.org/mailman/lis= tinfo/i2nsf

 

--
"Esta vez no fallaremos, Doctor Infierno"

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

e-mail: diego.r.lopez@telef= onica.com
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------

 

 


Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o copia sin autorizaci=F3n puede e= star prohibida en virtud de la legislaci=F3n vigente. Si ha recibido este m= ensaje por error, le rogamos que nos lo comunique inmediatamente por esta m= isma v=EDa y proceda a su destrucci=F3n.

The information contained in this transmission is privileged and confidenti= al 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 y= ou have received this transmission in error, do not read it. Please immedia= tely 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=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, divulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o p= ode estar proibida em virtude da legisla=E7=E3o vigente. Se recebeu esta me= nsagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mes= ma via e proceda a sua destrui=E7=E3o

--_000_4A95BA014132FF49AE685FAB4B9F17F657C156AAdfweml701chm_-- --_004_4A95BA014132FF49AE685FAB4B9F17F657C156AAdfweml701chm_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif"; size=2669; creation-date="Fri, 15 May 2015 16:02:15 GMT"; modification-date="Fri, 15 May 2015 16:02:15 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhMgAyAPf/AO3b2elrUvbKwuNBIPa0g/GUa8WJguZWOfGjk8zMzKguI7Ozs/Hx8e+Pe6ZE OeZcQvvi3f39/eXl5et5YnNzc8lGNvj4+NU5I+6JdfS3qudZPfvl4OSimoyMjOlpTOx3VPSkdvnH lODg4JSUlKOjo/W4rBsbG+jo6NSDe9HR0fOfc9bW1p4uIvPj4f729ODAvP77+rkxJMuVj/749u6N e/nUzVNTU/jOxfGZhNRKOHh4eNnZ2e+Tgfa5ieM/IP3w7sQ0JOhhRuRAKcLCwjs7OzIyMuM8IOVR MelmTPb29uVNMUBAQPKuoQoKCvv7+xQUFCoqKktLS+WNgfr6+vrVxNZ4bvKpmZiYmPW9spcrH++L ZcGAeSMjI+ZRNPjRyPCXhfbBt7u7u/rd1vzq5803JK6urvWuf/nZ0uRGLeM9JfOlefa7mmNjY/fG vei7t9k7Iut3Xvrf2eRKKoaGhuREK/308vT09OVPL+2Gcv3y72xsbPOrnGhoaPrg25ycnP3v7PbF u7RGO6qqqlxcXO23sOZPNPGejfSoefv49t89Ifny8fjKtO2CXupxWO29uLdrY/XBuYGBgfzp4eyB av76+fOzpv75+Pbs6+tzYO3t7fjBjvCYifOwot3d3adLQe2Cbfzs6Prs6/bZ1eA+IeQ9JcbGxu/B u/Onm+S+uuhkR+M/H+VKL+yupeM8IvW7r+x7V/CPaP37+/Gdiex9Z9A5Jfra1O2FbtarpvnTzPfI v+x/WudcP+RHJ9w7IeVLMONDIudfRedXP+RCK//9/PnX0Pzt6v/+/fzu6/KXbvnQv+ZUN/nw7+x2 W967t+6cj+zGwvbQy/Pn5u+HYvfCr/Otl+M+I/OvnuvRzueAcPWwi/vt7PCMZ/zr6OhgQ/a/tvTW 0uNFI7BgV68vI+NEK+NELNxVQOydkelkRPnXyfa8o/vo5P3u5vWpfuZPOfa1kvSwn7pya757c+LG wuXIxf/8/OfNyuzLyPS0qOM7I+pxXvK9tepwT+NAIONCIAAAAP///yH5BAEAAP8ALAAAAAAyADIA QAj/AP8JHEiwoMBh6rydckHQmKRFkiwZM0ixosBin/o1mCHwz4R+/fgZaSVs1YFUoIxN24ZMBYiX KpDBSjawTwA6WIZZvOGDH78BIIPu2iDgSNCQPmjMECZE2DhyaNDMMnaKVCsjRvgdDfCH4KMs4mKQ ufBm1CwBM7B4ABr0C71GIMHAgAvOVZ4DR8FhiFPMSrejIJU0IBjhEoDD367Ze2bKEaFKTBDwqKHT YB1Om5hUKoEFUK4buGr1gQAhDiWLqFOrXm3ChB2BQ/wN+qfD35IRFJ5w2RHF35AkSSwsaTIk0xN/ UCT8u+LPnx6BYaA0icKHjR4GV55YWP0vToB+Poyk/0HTZZcXgTDWqCGgKYQmAocWTeQuEMKdn0cR wNjwHaTIVkKswgQMcKTiwT4IJvjOP9xM4IswaRjhwwANMDRQFVWg9c8xs/ikFWBg4IJXUIZQ0kVQ v0xSBxyABaUMJ/VZ0UglAlFiQBYsKBADEGP1MkpPvtCwwQ8ZBIEBDH0wtEEdtXSBAS6UYAFXiwN4 qIwAFrWwRRZcchkOKsvQJ1Af5uRwAS20kJEDIZZQ1JoEdliwgD98SMDFEicINIc/I/yThAk2dOCP HxEwNwdtTRBhQikMLFGEBHz4Q8I/FlQawQja0UdPJQdUkwYdSvDQpkDHqKAGO2aYscY6YhpkDEcD Df9jC0jhjVfILg3Q848kyIBgRg+a9ACfClQQBAMMqp2hRFBB1CCQLL/QKh6oB9xADw6vMCKNFtxK w0gDYvwDwx7KoJFGK5/kUdEePrEVFBx14KJBUPyER8omlGjQxQEa9NvvYG0EQ8e5WYF0BCgUzcBu u4DJQQwgdwDGwwxyhIeVEZjU0YCEHx51AAQFOSAOj+U4A3KRPgFmxRh/gbQHDC2Dg8MMQbT4yycg tzFJUEcE8E80DmShI48X+OgDMEwUUwMe0fZDwz+y9FMLPRjI0Yc6RvWzyx6gnIEBLy2GpMomBcXy QjwODN1jIj/21EgNuhY0DAwI3DHA3Xh7yA8vASD/EG5Fl8DTJZcshAUEEDmwcgxqxhCDR08+RD7K KIn08sYF+py2Wh2XhNmqQZaEoo3mFXEBRRIClfKEHhIUYYNy/3TwhB8CnVDEEx38s8ITRAi0Ahcm RCKQICZQsBwXTSTfxAkkmLAd8npQQIENztmJp0CC0k4EnZFw4c8CFtjwRBlP8HGCCVEIOmlvg0Si gw6R2OFHpvQNQwwGwbSzCi4EUZIOMuxwBxVI9zmLGOMeXagVGgqBhB8chAq+IkAPeqAqdRWwIgiI lgLLYw2duEANh2BPCEIAn2xI4oK1QIA6BnKMj4BnWoXQADNmYAx0FEAFh0iVGQ6hggLQZCBguEcd /1JDjz2A5A6VmAglZtWPAfgAQOTZhRiGQQ1GaKEAyMhiAWCxjWL9wwV4WIUQ2nEGi7igAR3rxwTU hYWsDQArQligK2Bgi3184BW6yOMrPiALdQkACWK8ygCcRRFAMCwoGrjBP3gADpA4cVr6QcIuunGO c6QiFeeAQw0sIQtfDAwrWklFVwzCCQ+5y2X/sEXTqhQeURUCDb5QQiFm+YA25CEfQoiQhFyEMIOA IhimlJgxZgEYCrmADkbARxrSQAo0uEIdwcBKTwCDgFEJpAWhEEgdOpQywMDBBZNoGki+QAm71csH qwADMXiBH8AcwRWViQMi/hGIGFRACtD4hyV4IP+HbjLLBYwMin5G1I8D1AAMYetHKsDwjz+UgC5B +EfadkSLNwTgHjPoAwZ+ccou/KASjexHBmDgAZCk4hicaNEuOGEMMfAgYiD5xRFS8Y9b4GhkPRpF qCCgDkOcCCRygMAZImatnc3iH4Y4SiPAkAcwTAkwqngAyGrKJbUVrW1waEMdAMGMfvxCDHVoBATo YQhD/OML/TjCF+IACgTMi0o+AcYGCKIIGbCgcDta2yjqFYQ9GAMCGbBQTeYYB1vIAa4eCkAuLIII AMwDFW5whCNMAYnKggELlaAMRergihKAoQ1tyEUuQAsIQAgAFytETT0c4InWeiIQgaiAbHPwhjf/ 0GAMFYGBAIDBDzkoQQldUAa/dvEAYDwAGw7M0lcGlyNxoOAb3PkBFoCRiOpa7nK0YEVlUqMIeRjg EVtoRjQuOANRcABDHBDFdi/IXu7sYAcREEgSEiABJ+ygE06oXQIyMZBOpGA7DEgB7KYgghUwQCAW WAF+/8GAHaTgwU7IxAoE8gTnpc4fbJCACYgAuz316R+RSJ4JGJCEIjRhwnPyRxTyS4HvLaAJXBjB AsoAvuw8zx+tMcFxWHenPP3Dw/8YgT/C8A8TQCECIvAHESxAhCIIwh8dSEETKGCB3uTYyCeY33ZM wIVKWSA2bLAdFBIQ3xaHgXxPeEITTKDkf5QBSjlPEEQE2LDmIuzgH4OQVAScMIX8Ymo7RSDCa/6R gNX9QwR8MEHyijCEFbjOx/9ong4ioIcn2CB1UDDBpASygCWoec0nEEQRthMQADs= --_004_4A95BA014132FF49AE685FAB4B9F17F657C156AAdfweml701chm_-- From nobody Fri May 15 09:20:50 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E2321A03AA for ; Fri, 15 May 2015 09:20:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.92 X-Spam-Level: X-Spam-Status: No, score=-4.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k9OzvWUO9ABB for ; Fri, 15 May 2015 09:20:37 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3772E1A1B2E for ; Fri, 15 May 2015 09:20:37 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtoFAJQbVlWHCzIm/2dsb2JhbABZA4JFISlUXgaFIa05AQEBAQEBBpMyBhkBBoV5AoE5TAEBAQEBAYELhCIBAQEBAwEBAQIBDAgBCggBNAEBBwMGBQ4CAgEIDQQEAQEGAQEBAhYBBgcCBQ8BAQUJAQIJFAkIAgQBDQQBBgIGBg6ICgEMp3+vKAEBAQEBAQEBAQEBAQEBAQEBAQEBARcEhhKEIoEChCIRASAGBwkJAgYFAQQGAQICAgMIgwaBFgWGZIUNBoYbT4NLAV2CSoJEAYJiPoMngnELix+DWCNhfAkkHIFSbwEBAYEJOYEBAQEB X-IronPort-AV: E=Sophos;i="5.13,434,1427774400"; d="gif'147?scan'147,208,217,147";a="116666619" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by co300216-co-outbound.net.avaya.com with ESMTP; 15 May 2015 12:20:33 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 15 May 2015 12:20:32 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0174.001; Fri, 15 May 2015 18:20:31 +0200 From: "Romascanu, Dan (Dan)" To: Linda Dunbar , John Strassner , DIEGO LOPEZ GARCIA Thread-Topic: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93 Thread-Index: AdCI3eREWnYgWx+c3k2SduRLi+ubTgEwhD0wAApA4QAAIoN/AAAgQqQwABDrgIAABKUPAA== Date: Fri, 15 May 2015 16:20:30 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5CA3090D@AZ-FFEXMB04.global.avaya.com> References: <4A95BA014132FF49AE685FAB4B9F17F657C11DC6@dfweml701-chm> <3AF7BE6A-DD17-4C1C-9F31-42C6D2AB99B5@telefonica.com> <9904FB1B0159DA42B0B887B7FA8119CA5CA2E131@AZ-FFEXMB04.global.avaya.com> <4A95BA014132FF49AE685FAB4B9F17F657C156AA@dfweml701-chm> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657C156AA@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.48] Content-Type: multipart/related; boundary="_004_9904FB1B0159DA42B0B887B7FA8119CA5CA3090DAZFFEXMB04globa_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Cc: "i2nsf@ietf.org" , Kathleen Moriarty Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93 X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2015 16:20:48 -0000 --_004_9904FB1B0159DA42B0B887B7FA8119CA5CA3090DAZFFEXMB04globa_ Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA5CA3090DAZFFEXMB04globa_" --_000_9904FB1B0159DA42B0B887B7FA8119CA5CA3090DAZFFEXMB04globa_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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 a= spects of NSFs such as device or network provisioning are out of scope. Thi= s should include an information model and a set of data models and software= interfaces for specifying, representing, querying, monitoring, and control= ling security functions including the security policy aspects of NSFs by on= e or more management entities. Regards, Dan From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Friday, May 15, 2015 7:02 PM To: John Strassner; Romascanu, Dan (Dan); DIEGO LOPEZ GARCIA Cc: i2nsf@ietf.org; Kathleen Moriarty Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new charter for= IETF 93 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 m= odels and software interfaces for specifying, representing, querying, monit= oring, and controlling NSFs. Management of NSFs should include communicatin= g, querying, and changing the configuration of NSFs by one or more manageme= nt 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 aspe= cts of NSFs such as device or network provisioning are out of scope. This s= hould include an information model and a set of data models and software in= terfaces for specifying, representing, querying, monitoring, and controllin= g 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: i2nsf@ietf.org; Kathleen Moriarty; Linda Dunbar Subject: RE: [I2nsf] Further Narrowing the I2NSF scope: the new charter for= IETF 93 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 mana= ge security policies for physical and virtual distributed security function= s that may be running on different premises. In order to address the above challenges, vNSF devices may include two func= tional 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 u= ntouched) by my edits: There are two layers of interfaces envisioned in the I2NSF approach: - Security Policies facing security functions (I2NSF Capability La= yer) - Security Policies facing clients (I2NSF Service 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 l= ike to propose. I'm certainly for consensus, and would like to help agree on the charter as= ap; I just don't understand what in my edits made people think that it is n= ow too focused on policy, given the existing starting text. regards, John Dr. John Strassner, Ph.D. CTO, Software Laboratory, CRD [logo.gif] Futurewei Technologies US R&D Center 2330 Central Expressway Building A, office A2-2143 Santa Clara, California 95050 Office: +1.408.330.4923 Email: john.sc.strassner@huawei.com From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Romascanu, Dan (Da= n) Sent: Thursday, May 14, 2015 12:34 AM To: DIEGO LOPEZ GARCIA; John Strassner Cc: i2nsf@ietf.org; Kathleen Moriarty; Linda Dunbar Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new charter for= IETF 93 (speaking as contributor) I agree with Diego's observation. I also agree and like many of the edits p= roposed by John, but I do not believe that the scope should be focused arou= nd policies. Policies may be the right paradigm at certain layers, but they= are not the only method for interoperable access and management of NSFs. T= he work should not IMO exclude policy, but neither should make of it the ce= ntral (or exclusive) focus. Regards, Dan From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of DIEGO LOPEZ GARCIA Sent: Thursday, May 14, 2015 1:06 AM To: John Strassner Cc: i2nsf@ietf.org; Kathleen Moriarty; Linda Dunbar Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new charter for= IETF 93 Importance: High 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 th= e term "policy" in the document. The text talks about policy at two many la= yers and can become misleading and difficult to be understood by the commun= ity. I'd leave the primary goal definition as: "The primary goal of I2NSF is to define an extensible framework for managin= g 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 furth= er development for a later stage. Be goode, On 13 May 2015, at 19:18 , John Strassner > wrote: Dear Linda, First, thank you for pulling together these changes. The charter developmen= t has progressed nicely. Second, attached is a word document with my edits and suggestions for consi= deration by the working group. Despite the large number of edits and commen= ts, I am very supportive of I2NSF being made a working group, and would lik= e to volunteer to work on its deliverables. My edits and comments are to ad= dress 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: john.sc.strassner@huawei.com From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Thursday, May 07, 2015 8:53 AM To: i2nsf@ietf.org; Kathleen Moriarty Cc: i2rs@ietf.org; dots@ietf.org; netmod@ietf.org Subject: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IET= F 93 Thanks to I2NSF contributors for the good progresses made since IETF92 sid= e 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 I= nterface 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 t= he Capability Interface. The thinking logic is: Once the Capability Interfa= ce is completed, we will see more clearly the work for Service interface. E= ven if Capability layer alone is standardized, it is a giant leap forward i= n building blocks for Service Provider to automate their Security Controlle= r that can utilize NSF by multiple vendors Here is the narrower scoped I2NSF charter. Your comments and suggestions ar= e greatly appreciated. CC'ed to DOTS, I2RS, and Netmod groups for wider rev= iew. Enterprises, residential, and mobile customers are increasingly consuming n= etwork functions, especially network security related functions that are no= t 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 i= nterface to express, monitor, and manage security policies to security func= tions deployed at different premises, it becomes virtually impossible for s= ecurity service providers to automate the service offering utilizing securi= ty functions by multiple vendors. The ultimate goal of I2NSF is to enable enterprises to utilize security fun= ctions not hosted on their own premises but instead hosted in service provi= der domain, to establish how to communicate desired security policies to NS= F 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 La= yer) - Security Policies facing clients (I2NSF Service Layer) The I2NSF Capability Layer specifies the functional security policies, whic= h 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 poli= cies 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 represen= ted 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 p= olicies between Controller and NSFs. The capability registry is to make it feasible to categorize network securi= ty functions provided by different vendors based on security policy provisi= oning capability without any need to standardize security functions themsel= ves. Standard provisioning capability interface is an essential building b= lock for Security Service Provider to automate their Security Controllers t= hat can utilize NSF by multiple vendors. This layer will leverage the exist= ing 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 clien= ts and demonstrating the feasibility of them being translated to the Capabi= lity Layer policies. Since different security vendors support different features & functions on = their devices, I2NSF will focus on flow based security functions that provi= de 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 Base= d Security functions include deep packet inspection, packet/flow/stream fil= tering or pattern matching and remediation, etc. Similar to I2RS focusing on the interface to RIB/FIB even though most route= rs 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 I2N= SF interfaces. I2NSF WG Deliverables include: - Use Case document. - Framework Document. - Requirement for extensions (if there are any) to existing protoc= ols 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 ab= ove Information Model. - IANA registry consideration for flow based security function pol= icy provisioning capability. - (Optionally) Applicability Statements on how to use I2RS, Netco= nf, and NETMOD to carry the content of the specified information/data model= s. [The WG may decide that the Use cases, Framework, and Requirement are Infor= mational 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 W= G 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 com= municate with external SDOs like ETSI NFV and will encourage open source co= de development related to the WG scope in organizations like ONF, OpenStack= , ODL, and OpenNFV. Cheers, Linda Dunbar __________________________________________= _____ I2nsf mailing list I2nsf@ietf.org 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: diego.r.lopez@telefonica.com Tel: +34 913 129 041 Mobile: +34 682 051 091 ---------------------------------- ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o= copia sin autorizaci=F3n puede estar prohibida en virtud de la legislaci= =F3n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo = comunique inmediatamente por esta misma v=EDa y proceda a su destrucci=F3n. The information contained in this transmission is privileged and confidenti= al 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 co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, div= ulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o pode estar proibida em virtude= da legisla=E7=E3o vigente. Se recebeu esta mensagem por erro, rogamos-lhe = que nos o comunique imediatamente por esta mesma via e proceda a sua destru= i=E7=E3o --_000_9904FB1B0159DA42B0B887B7FA8119CA5CA3090DAZFFEXMB04globa_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Linda,

 <= /p>

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

 <= /p>

I suggest:

 <= /p>

The primary goal of I2NSF is t= o define a set of interfaces and data models for security functions provisi= oning and monitoring aspects of NSFs. Other aspects of NSFs such as device or network provisioning are out of sc= ope. 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 en= tities.

 <= /p>

Regards,

 <= /p>

Dan

 <= /p>

 <= /p>

From: I2nsf [m= ailto:i2nsf-bounces@ietf.org] On Behalf Of Linda Dunbar
Sent: Friday, May 15, 2015 7:02 PM
To: John Strassner; Romascanu, Dan (Dan); DIEGO LOPEZ GARCIA
Cc: i2nsf@ietf.org; Kathleen Moriarty
Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new char= ter for IETF 93

 

 <= /p>

John,

 <= /p>

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

 <= /p>

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

 

 

Do you think the followin= g describes what you want?

 

The primary goal of I2NSF is t= o define a set of interfaces and data models for security policy provisioni= ng and monitoring aspects of NSFs. Other aspects of NSFs such as device or network provisioning are out of scope. T= his should include an information model and a set of data models and softwa= re interfaces for specifying, representing, querying, monitoring, and contr= olling security policy aspects of NSFs by one or more management entities.

 <= /p>

 <= /p>

Linda

From: John Str= assner
Sent: Friday, May 15, 2015 1:07 AM
To: Romascanu, Dan (Dan); DIEGO LOPEZ GARCIA
Cc: i2nsf@ietf.org; Kathleen M= oriarty; Linda Dunbar
Subject: RE: [I2nsf] Further Narrowing the I2NSF scope: the new char= ter for IETF 93

 

I’m confused.<= /o:p>

 <= /p>

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

 <= /p>

“…Thes= e trends require a standard interface to express, monitor, and manage secur= ity 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 func= tional layers:
- Security Service and Policy Layer
- Capability (or Functional) Layer”

 <= /p>

This is from the first tw= o paragraphs.

 <= /p>

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

 <= /p>

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

-       = ;   Security Policies facing s= ecurity functions (I2NSF Capability Layer)

-       = ;   Security Policies facing c= lients (I2NSF Service Layer)

 <= /p>

Therefore, please explain= what “overuse of the term policy” means (Diego), and why you b= elieve that my edits “focused around policies” (Dan). I would a= lso like to understand what “alternative mechanisms” to policy you woul= d like to propose.

 <= /p>

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

 <= /p>

 <= /p>

regards,<= /p>

John

 

Dr. John Strassner, Ph.D.

CTO, Software Laboratory, C= RD

 

Futurewei Technologies=

US R&D Center=

2330 Central Expressway Building A, office A2-2143

Santa Clara, California&n= bsp;  95050

  Office:  +1.408.330.4923

  Email:   jo= hn.sc.strassner@huawei.com

 

 

 <= /p>

From: I2nsf [<= a href=3D"mailto:i2nsf-bounces@ietf.org">mailto:i2nsf-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Thursday, May 14, 2015 12:34 AM
To: DIEGO LOPEZ GARCIA; John Strassner
Cc: i2nsf@ietf.org; Kathleen M= oriarty; Linda Dunbar
Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new char= ter for IETF 93

 

(speaking as contributor)=

 <= /p>

I agree with Diego’= s observation. I also agree and like many of the edits proposed by John, bu= t 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 shou= ld not IMO exclude policy, but neither should make of it the central (or ex= clusive) focus.

 <= /p>

Regards,

 <= /p>

Dan

 <= /p>

 <= /p>

From: I2nsf [<= a href=3D"mailto:i2nsf-bounces@ietf.org">mailto:i2nsf-bounces@ietf.org] On Behalf Of DIEGO LOPEZ GARCIA
Sent: Thursday, May 14, 2015 1:06 AM
To: John Strassner
Cc: i2nsf@ietf.org; Kathleen M= oriarty; Linda Dunbar
Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new char= ter for IETF 93
Importance: High

 

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 difficu= lt to be understood by the community. I'd leave the primary goal definition as:

 

"The primary goal of I2NSF is to define an exte= nsible 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 d= ocuments, and let further development for a later stage.

 

Be goode,

 

On 13 May 2015, at 19:18 , John Strassner <John.sc.Strassner@huawei.com&= gt; wrote:

 

Dear Linda,

 

First, thank you for pull= ing together these changes. The charter development has progressed nicely.<= /span>

 

Second, attached is a wor= d document with my edits and suggestions for consideration by the working g= roup. 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

 <= o:p>

Dr. John Strassner, Ph.D.

CTO, Software Laboratory, C= RD

<image001.gif>

 

Futurewei Technologies=

US R&D Center

2330 Central Expressway Building A, office A2-2143

Santa Clara, California&n= bsp;  95050

  Office:  +1.408.330.4923

  Email:   john.sc.strassner@huawei.com=

 <= o:p>

 <= o:p>

 

From: I2nsf [ma= ilto:i2nsf-bounces@ietf.org] On Behalf Of <= /span>Linda Dunbar
Sent: Thursday, Ma= y 07, 2015 8:53 AM
To: i2nsf@ietf.org;= Kathleen Moriarty
Cc: i2rs@ietf.org; dots@ietf.org; netmod@ietf.org
Subject: [I2nsf] F= urther Narrowing the I2NSF scope: the new charter for IETF 93

 

Thanks to I2NSF contributors for the go= od progresses made since  IETF92 side meetings. Among the two I2NSF in= terfaces,  i.e. the client facing Service Interface and the NSF facing Capability Interface, the work to be done at the Capability Interfa= ce becomes very clear and concrete. But the Service Interface is still a li= ttle vague.

 

The feedback from last IETF side meetin= gs 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 Se= rvice Provider to automate their Security Controller that can utilize NSF by multiple vendors

 

Here is the narrower scoped I2NSF chart= er. Your comments and suggestions are greatly appreciated. CC’ed to D= OTS, I2RS, and Netmod groups for wider review.

 

 

 

Enterprises, residential, and mobile cu= stomers are increasingly consuming network functions, especially network se= curity related functions that are not running on their premises.  In addition, the European Telecommunications Standards Institute (ETSI) Ne= twork Function Virtualization (NFV) initiative creates new management chall= enges for security policies to be enforced by distributed, virtual, network= security functions (vNSF). Without standard interface to express, monitor, and manage security policies to se= curity functions deployed at different premises, it becomes virtually impos= sible for security service providers to automate the service offering utili= zing 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 perform= ance data or report out of NSF or vNSF.

 

There are two layers of interfaces:

-<= span style=3D"font-size:7.0pt">       &n= bsp;  Security Policies facing security functions (I2NSF Capability Layer)

-<= span style=3D"font-size:7.0pt">       &n= bsp;  Security Policies facing clients (I2NSF Service Layer)

 

The I2NSF Capability Layer specifies th= e functional security policies, which are translated from the client securi= ty policies, to security functions. I2NSF will NOT standardize security functions or devices. Instead, I2NSF is only to standardize the p= olicy provisioning to the security functions (not devices), in the form of = “Subject – Object – Function – Action” paradi= gm. 

 

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 se= curity expertise.

 

The concrete work at the L2NSF Capabili= ty Layer includes

-<= span style=3D"font-size:7.0pt">       &n= bsp;  The informational & data models for each category to be represented to vir= tual or physical network security functions,

-<= span style=3D"font-size:7.0pt">       &n= bsp;  The capability registry (IANA) of policy provisioning capability to flow based= security function, and

-<= span style=3D"font-size:7.0pt">       &n= bsp;  The proper secure communication channels to carry the security policies betwee= n Controller and NSFs.

The capability registry is to make it f= easible to categorize network security functions provided by different vend= ors based on security policy provisioning capability without any need to standardize security functions themselves.  Standard prov= isioning capability interface is an essential building block for Security S= ervice 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 faci= ng 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 suppor= t 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 oth= er security functions such as Authentication, Authorization, or Encryption)= . Exemplar services associated with Flow Based Security functions include d= eep packet inspection, packet/flow/stream filtering or pattern matching and remediation, etc.

 

Similar to I2RS focusing on the interfa= ce 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 protocol= s or data modeling languages for I2NSF interfaces.

I2NSF WG Deliverables include:

 

-<= span style=3D"font-size:7.0pt">       &n= bsp;   Use Case document.

-<= span style=3D"font-size:7.0pt">       &n= bsp;  Framework Document.

-<= span style=3D"font-size:7.0pt">       &n= bsp;  Requirement for extensions (if there are any) to existing protocols used by the WG.

-<= span style=3D"font-size:7.0pt">       &n= bsp;   Gap analysis of existing protocols and modeling languages

-<= span style=3D"font-size:7.0pt">       &n= bsp;  A single, unified, Information Model for expressing policies to the Flow Bas= ed Security Functions described above.

-<= span style=3D"font-size:7.0pt">       &n= bsp;  Corresponding Data Models (e.g. YANG models) derived from the above Information Model.

-<= span style=3D"font-size:7.0pt">       &n= bsp;  IANA registry consideration for flow based security function policy provisionin= g capability.

-<= span style=3D"font-size:7.0pt">       &n= bsp;   (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 Info= rmational documents or simply reference documents during the lifetime of the WG. The = framework, that describes the functional components and the I2NSF work item= s, is to make I2NSF work more organized.]

 

Suggested Milestones<= /p>

  - Use Case Document:  Chart= er 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 &#= 43; 10 months to WG Document

  - All Early Drafts to IESG: 10 m= onths

 

[decision point – +10 months]=  

  - Data Models: Charter += ; 9 Months to WG Document

  - Applicability Statements: 10 m= onths to WG Document

  - Data Models and Applicability = Statements to IESG  - 16 months

 

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

 

 

Cheers,

Linda Dunbar

<i2nsf charter-jcs-20150512.docx>_______________________________= ________________
I2nsf mailing list
I2nsf@ietf.o= rg
https://www.ietf.org/mailman/lis= tinfo/i2nsf

 

--
"Esta vez no fallaremos, Doctor Infierno"

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

e-mail: diego.r.lopez@telef= onica.com
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------

 

 


Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o copia sin autorizaci=F3n puede e= star prohibida en virtud de la legislaci=F3n vigente. Si ha recibido este m= ensaje por error, le rogamos que nos lo comunique inmediatamente por esta m= isma v=EDa y proceda a su destrucci=F3n.

The information contained in this transmission is privileged and confidenti= al 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 y= ou have received this transmission in error, do not read it. Please immedia= tely 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=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, divulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o p= ode estar proibida em virtude da legisla=E7=E3o vigente. Se recebeu esta me= nsagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mes= ma via e proceda a sua destrui=E7=E3o

--_000_9904FB1B0159DA42B0B887B7FA8119CA5CA3090DAZFFEXMB04globa_-- --_004_9904FB1B0159DA42B0B887B7FA8119CA5CA3090DAZFFEXMB04globa_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif"; size=2669; creation-date="Fri, 15 May 2015 16:20:30 GMT"; modification-date="Fri, 15 May 2015 16:20:30 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhMgAyAPf/AO3b2elrUvbKwuNBIPa0g/GUa8WJguZWOfGjk8zMzKguI7Ozs/Hx8e+Pe6ZE OeZcQvvi3f39/eXl5et5YnNzc8lGNvj4+NU5I+6JdfS3qudZPfvl4OSimoyMjOlpTOx3VPSkdvnH lODg4JSUlKOjo/W4rBsbG+jo6NSDe9HR0fOfc9bW1p4uIvPj4f729ODAvP77+rkxJMuVj/749u6N e/nUzVNTU/jOxfGZhNRKOHh4eNnZ2e+Tgfa5ieM/IP3w7sQ0JOhhRuRAKcLCwjs7OzIyMuM8IOVR MelmTPb29uVNMUBAQPKuoQoKCvv7+xQUFCoqKktLS+WNgfr6+vrVxNZ4bvKpmZiYmPW9spcrH++L ZcGAeSMjI+ZRNPjRyPCXhfbBt7u7u/rd1vzq5803JK6urvWuf/nZ0uRGLeM9JfOlefa7mmNjY/fG vei7t9k7Iut3Xvrf2eRKKoaGhuREK/308vT09OVPL+2Gcv3y72xsbPOrnGhoaPrg25ycnP3v7PbF u7RGO6qqqlxcXO23sOZPNPGejfSoefv49t89Ifny8fjKtO2CXupxWO29uLdrY/XBuYGBgfzp4eyB av76+fOzpv75+Pbs6+tzYO3t7fjBjvCYifOwot3d3adLQe2Cbfzs6Prs6/bZ1eA+IeQ9JcbGxu/B u/Onm+S+uuhkR+M/H+VKL+yupeM8IvW7r+x7V/CPaP37+/Gdiex9Z9A5Jfra1O2FbtarpvnTzPfI v+x/WudcP+RHJ9w7IeVLMONDIudfRedXP+RCK//9/PnX0Pzt6v/+/fzu6/KXbvnQv+ZUN/nw7+x2 W967t+6cj+zGwvbQy/Pn5u+HYvfCr/Otl+M+I/OvnuvRzueAcPWwi/vt7PCMZ/zr6OhgQ/a/tvTW 0uNFI7BgV68vI+NEK+NELNxVQOydkelkRPnXyfa8o/vo5P3u5vWpfuZPOfa1kvSwn7pya757c+LG wuXIxf/8/OfNyuzLyPS0qOM7I+pxXvK9tepwT+NAIONCIAAAAP///yH5BAEAAP8ALAAAAAAyADIA QAj/AP8JHEiwoMBh6rydckHQmKRFkiwZM0ixosBin/o1mCHwz4R+/fgZaSVs1YFUoIxN24ZMBYiX KpDBSjawTwA6WIZZvOGDH78BIIPu2iDgSNCQPmjMECZE2DhyaNDMMnaKVCsjRvgdDfCH4KMs4mKQ ufBm1CwBM7B4ABr0C71GIMHAgAvOVZ4DR8FhiFPMSrejIJU0IBjhEoDD367Ze2bKEaFKTBDwqKHT YB1Om5hUKoEFUK4buGr1gQAhDiWLqFOrXm3ChB2BQ/wN+qfD35IRFJ5w2RHF35AkSSwsaTIk0xN/ UCT8u+LPnx6BYaA0icKHjR4GV55YWP0vToB+Poyk/0HTZZcXgTDWqCGgKYQmAocWTeQuEMKdn0cR wNjwHaTIVkKswgQMcKTiwT4IJvjOP9xM4IswaRjhwwANMDRQFVWg9c8xs/ikFWBg4IJXUIZQ0kVQ v0xSBxyABaUMJ/VZ0UglAlFiQBYsKBADEGP1MkpPvtCwwQ8ZBIEBDH0wtEEdtXSBAS6UYAFXiwN4 qIwAFrWwRRZcchkOKsvQJ1Af5uRwAS20kJEDIZZQ1JoEdliwgD98SMDFEicINIc/I/yThAk2dOCP HxEwNwdtTRBhQikMLFGEBHz4Q8I/FlQawQja0UdPJQdUkwYdSvDQpkDHqKAGO2aYscY6YhpkDEcD Df9jC0jhjVfILg3Q848kyIBgRg+a9ACfClQQBAMMqp2hRFBB1CCQLL/QKh6oB9xADw6vMCKNFtxK w0gDYvwDwx7KoJFGK5/kUdEePrEVFBx14KJBUPyER8omlGjQxQEa9NvvYG0EQ8e5WYF0BCgUzcBu u4DJQQwgdwDGwwxyhIeVEZjU0YCEHx51AAQFOSAOj+U4A3KRPgFmxRh/gbQHDC2Dg8MMQbT4yycg tzFJUEcE8E80DmShI48X+OgDMEwUUwMe0fZDwz+y9FMLPRjI0Yc6RvWzyx6gnIEBLy2GpMomBcXy QjwODN1jIj/21EgNuhY0DAwI3DHA3Xh7yA8vASD/EG5Fl8DTJZcshAUEEDmwcgxqxhCDR08+RD7K KIn08sYF+py2Wh2XhNmqQZaEoo3mFXEBRRIClfKEHhIUYYNy/3TwhB8CnVDEEx38s8ITRAi0Ahcm RCKQICZQsBwXTSTfxAkkmLAd8npQQIENztmJp0CC0k4EnZFw4c8CFtjwRBlP8HGCCVEIOmlvg0Si gw6R2OFHpvQNQwwGwbSzCi4EUZIOMuxwBxVI9zmLGOMeXagVGgqBhB8chAq+IkAPeqAqdRWwIgiI lgLLYw2duEANh2BPCEIAn2xI4oK1QIA6BnKMj4BnWoXQADNmYAx0FEAFh0iVGQ6hggLQZCBguEcd /1JDjz2A5A6VmAglZtWPAfgAQOTZhRiGQQ1GaKEAyMhiAWCxjWL9wwV4WIUQ2nEGi7igAR3rxwTU hYWsDQArQligK2Bgi3184BW6yOMrPiALdQkACWK8ygCcRRFAMCwoGrjBP3gADpA4cVr6QcIuunGO c6QiFeeAQw0sIQtfDAwrWklFVwzCCQ+5y2X/sEXTqhQeURUCDb5QQiFm+YA25CEfQoiQhFyEMIOA IhimlJgxZgEYCrmADkbARxrSQAo0uEIdwcBKTwCDgFEJpAWhEEgdOpQywMDBBZNoGki+QAm71csH qwADMXiBH8AcwRWViQMi/hGIGFRACtD4hyV4IP+HbjLLBYwMin5G1I8D1AAMYetHKsDwjz+UgC5B +EfadkSLNwTgHjPoAwZ+ccou/KASjexHBmDgAZCk4hicaNEuOGEMMfAgYiD5xRFS8Y9b4GhkPRpF qCCgDkOcCCRygMAZImatnc3iH4Y4SiPAkAcwTAkwqngAyGrKJbUVrW1waEMdAMGMfvxCDHVoBATo YQhD/OML/TjCF+IACgTMi0o+AcYGCKIIGbCgcDta2yjqFYQ9GAMCGbBQTeYYB1vIAa4eCkAuLIII AMwDFW5whCNMAYnKggELlaAMRergihKAoQ1tyEUuQAsIQAgAFytETT0c4InWeiIQgaiAbHPwhjf/ 0GAMFYGBAIDBDzkoQQldUAa/dvEAYDwAGw7M0lcGlyNxoOAb3PkBFoCRiOpa7nK0YEVlUqMIeRjg EVtoRjQuOANRcABDHBDFdi/IXu7sYAcREEgSEiABJ+ygE06oXQIyMZBOpGA7DEgB7KYgghUwQCAW WAF+/8GAHaTgwU7IxAoE8gTnpc4fbJCACYgAuz316R+RSJ4JGJCEIjRhwnPyRxTyS4HvLaAJXBjB AsoAvuw8zx+tMcFxWHenPP3Dw/8YgT/C8A8TQCECIvAHESxAhCIIwh8dSEETKGCB3uTYyCeY33ZM wIVKWSA2bLAdFBIQ3xaHgXxPeEITTKDkf5QBSjlPEEQE2LDmIuzgH4OQVAScMIX8Ymo7RSDCa/6R gNX9QwR8MEHyijCEFbjOx/9ong4ioIcn2CB1UDDBpASygCWoec0nEEQRthMQADs= --_004_9904FB1B0159DA42B0B887B7FA8119CA5CA3090DAZFFEXMB04globa_-- From nobody Fri May 15 09:41:59 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45EEE1A010E for ; Fri, 15 May 2015 09:41:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.62 X-Spam-Level: X-Spam-Status: No, score=-0.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uzYvMQElUZ6O for ; Fri, 15 May 2015 09:41:46 -0700 (PDT) Received: from smtpvbsrv1.mitre.org (smtpvbsrv1.mitre.org [198.49.146.234]) by ietfa.amsl.com (Postfix) with ESMTP id 3252B1A3BA7 for ; Fri, 15 May 2015 09:41:41 -0700 (PDT) Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C15D9B2E27C; Fri, 15 May 2015 12:41:40 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpvbsrv1.mitre.org (Postfix) with ESMTP id C1F86B2E276; Fri, 15 May 2015 12:41:19 -0400 (EDT) Received: from imshyb01.MITRE.ORG (129.83.29.2) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.3.224.2; Fri, 15 May 2015 12:41:19 -0400 Received: from imshyb02.MITRE.ORG (129.83.29.3) by imshyb01.MITRE.ORG (129.83.29.2) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Fri, 15 May 2015 12:41:18 -0400 Received: from na01-bl2-obe.outbound.protection.outlook.com (10.140.19.249) by imshyb02.MITRE.ORG (129.83.29.3) with Microsoft SMTP Server (TLS) id 15.0.1044.25 via Frontend Transport; Fri, 15 May 2015 12:41:18 -0400 Received: from CY1PR09MB0922.namprd09.prod.outlook.com (10.163.89.140) by CY1PR09MB0922.namprd09.prod.outlook.com (10.163.89.140) with Microsoft SMTP Server (TLS) id 15.1.160.19; Fri, 15 May 2015 16:41:15 +0000 Received: from CY1PR09MB0922.namprd09.prod.outlook.com ([10.163.89.140]) by CY1PR09MB0922.namprd09.prod.outlook.com ([10.163.89.140]) with mapi id 15.01.0160.009; Fri, 15 May 2015 16:41:15 +0000 From: "Natale, Bob" To: "Romascanu, Dan (Dan)" , Linda Dunbar , John Strassner , DIEGO LOPEZ GARCIA Thread-Topic: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93 Thread-Index: AdCI3eREQdBVQ8yORRe/7nCVEnyK2QEwhD0wAApA4QAAE9hnAAAvQMMAABTJW4AAAKMrAAAAcnbg Date: Fri, 15 May 2015 16:41:14 +0000 Message-ID: References: <4A95BA014132FF49AE685FAB4B9F17F657C11DC6@dfweml701-chm> <3AF7BE6A-DD17-4C1C-9F31-42C6D2AB99B5@telefonica.com> <9904FB1B0159DA42B0B887B7FA8119CA5CA2E131@AZ-FFEXMB04.global.avaya.com> <4A95BA014132FF49AE685FAB4B9F17F657C156AA@dfweml701-chm> <9904FB1B0159DA42B0B887B7FA8119CA5CA3090D@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5CA3090D@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: avaya.com; dkim=none (message not signed) header.d=none; x-originating-ip: [192.80.55.87] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR09MB0922; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:CY1PR09MB0922; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0922; x-forefront-prvs: 0577AD41D6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(25724002)(24454002)(15404003)(40134004)(43234003)(377454003)(252514010)(99286002)(93886004)(77096005)(102836002)(15975445007)(19300405004)(19617315012)(19627595001)(5001770100001)(189998001)(5001960100002)(19609705001)(50986999)(54356999)(76176999)(99936001)(19580405001)(19580395003)(46102003)(5890100001)(66066001)(86362001)(19613025002)(19625215002)(87936001)(2656002)(33656002)(16236675004)(17760045003)(81156007)(77156002)(62966003)(92566002)(18206015028)(122556002)(40100003)(2950100001)(74316001)(2900100001)(76576001)(7099028)(7059030)(579004)(559001)(19615165003); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR09MB0922; H:CY1PR09MB0922.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; Content-Type: multipart/related; boundary="_004_CY1PR09MB0922EA24176686A991AB75E9A8C70CY1PR09MB0922namp_"; type="multipart/alternative" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 May 2015 16:41:14.9963 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c620dc48-1d50-4952-8b39-df4d54d74d82 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0922 X-OriginatorOrg: mitre.org Archived-At: Cc: "i2nsf@ietf.org" , Kathleen Moriarty Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93 X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2015 16:41:58 -0000 --_004_CY1PR09MB0922EA24176686A991AB75E9A8C70CY1PR09MB0922namp_ Content-Type: multipart/alternative; boundary="_000_CY1PR09MB0922EA24176686A991AB75E9A8C70CY1PR09MB0922namp_" --_000_CY1PR09MB0922EA24176686A991AB75E9A8C70CY1PR09MB0922namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable - I liked Linda's version ... consider it a sensible adaptation of John's v= ersion. - 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 s= chool" 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-bas= ed provisioning (as a subset of intent-driven policy-based network manageme= nt). Clearly, there is still some time on the tenure clock for device-type-= specific-protocol-driven provisioning, and maybe that's where this work sho= uld focus. But I, personally, would rather see it buy into the FMO and cont= ribute per Linda's and John's compromise. >From the sidelines, BobN From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Romascanu, Dan (Da= n) Sent: Friday, May 15, 2015 12:21 PM To: Linda Dunbar; John Strassner; DIEGO LOPEZ GARCIA Cc: i2nsf@ietf.org; Kathleen Moriarty Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new charter for= IETF 93 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 a= spects of NSFs such as device or network provisioning are out of scope. Thi= s should include an information model and a set of data models and software= interfaces for specifying, representing, querying, monitoring, and control= ling security functions including the security policy aspects of NSFs by on= e or more management entities. Regards, Dan From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Friday, May 15, 2015 7:02 PM To: John Strassner; Romascanu, Dan (Dan); DIEGO LOPEZ GARCIA Cc: i2nsf@ietf.org; Kathleen Moriarty Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new charter for= IETF 93 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 m= odels and software interfaces for specifying, representing, querying, monit= oring, and controlling NSFs. Management of NSFs should include communicatin= g, querying, and changing the configuration of NSFs by one or more manageme= nt 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 aspe= cts of NSFs such as device or network provisioning are out of scope. This s= hould include an information model and a set of data models and software in= terfaces for specifying, representing, querying, monitoring, and controllin= g 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: i2nsf@ietf.org; Kathleen Moriarty; Linda Dunbar Subject: RE: [I2nsf] Further Narrowing the I2NSF scope: the new charter for= IETF 93 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 mana= ge security policies for physical and virtual distributed security function= s that may be running on different premises. In order to address the above challenges, vNSF devices may include two func= tional 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 u= ntouched) by my edits: There are two layers of interfaces envisioned in the I2NSF approach: - Security Policies facing security functions (I2NSF Capability La= yer) - Security Policies facing clients (I2NSF Service 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 l= ike to propose. I'm certainly for consensus, and would like to help agree on the charter as= ap; I just don't understand what in my edits made people think that it is n= ow too focused on policy, given the existing starting text. regards, John Dr. John Strassner, Ph.D. CTO, Software Laboratory, CRD [logo.gif] Futurewei Technologies US R&D Center 2330 Central Expressway Building A, office A2-2143 Santa Clara, California 95050 Office: +1.408.330.4923 Email: john.sc.strassner@huawei.com From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Romascanu, Dan (Da= n) Sent: Thursday, May 14, 2015 12:34 AM To: DIEGO LOPEZ GARCIA; John Strassner Cc: i2nsf@ietf.org; Kathleen Moriarty; Linda Dunbar Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new charter for= IETF 93 (speaking as contributor) I agree with Diego's observation. I also agree and like many of the edits p= roposed by John, but I do not believe that the scope should be focused arou= nd policies. Policies may be the right paradigm at certain layers, but they= are not the only method for interoperable access and management of NSFs. T= he work should not IMO exclude policy, but neither should make of it the ce= ntral (or exclusive) focus. Regards, Dan From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of DIEGO LOPEZ GARCIA Sent: Thursday, May 14, 2015 1:06 AM To: John Strassner Cc: i2nsf@ietf.org; Kathleen Moriarty; Linda Dunbar Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new charter for= IETF 93 Importance: High 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 th= e term "policy" in the document. The text talks about policy at two many la= yers and can become misleading and difficult to be understood by the commun= ity. I'd leave the primary goal definition as: "The primary goal of I2NSF is to define an extensible framework for managin= g 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 furth= er development for a later stage. Be goode, On 13 May 2015, at 19:18 , John Strassner > wrote: Dear Linda, First, thank you for pulling together these changes. The charter developmen= t has progressed nicely. Second, attached is a word document with my edits and suggestions for consi= deration by the working group. Despite the large number of edits and commen= ts, I am very supportive of I2NSF being made a working group, and would lik= e to volunteer to work on its deliverables. My edits and comments are to ad= dress 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: john.sc.strassner@huawei.com From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Thursday, May 07, 2015 8:53 AM To: i2nsf@ietf.org; Kathleen Moriarty Cc: i2rs@ietf.org; dots@ietf.org; netmod@ietf.org Subject: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IET= F 93 Thanks to I2NSF contributors for the good progresses made since IETF92 sid= e 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 I= nterface 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 t= he Capability Interface. The thinking logic is: Once the Capability Interfa= ce is completed, we will see more clearly the work for Service interface. E= ven if Capability layer alone is standardized, it is a giant leap forward i= n building blocks for Service Provider to automate their Security Controlle= r that can utilize NSF by multiple vendors Here is the narrower scoped I2NSF charter. Your comments and suggestions ar= e greatly appreciated. CC'ed to DOTS, I2RS, and Netmod groups for wider rev= iew. Enterprises, residential, and mobile customers are increasingly consuming n= etwork functions, especially network security related functions that are no= t 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 i= nterface to express, monitor, and manage security policies to security func= tions deployed at different premises, it becomes virtually impossible for s= ecurity service providers to automate the service offering utilizing securi= ty functions by multiple vendors. The ultimate goal of I2NSF is to enable enterprises to utilize security fun= ctions not hosted on their own premises but instead hosted in service provi= der domain, to establish how to communicate desired security policies to NS= F 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 La= yer) - Security Policies facing clients (I2NSF Service Layer) The I2NSF Capability Layer specifies the functional security policies, whic= h 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 poli= cies 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 represen= ted 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 p= olicies between Controller and NSFs. The capability registry is to make it feasible to categorize network securi= ty functions provided by different vendors based on security policy provisi= oning capability without any need to standardize security functions themsel= ves. Standard provisioning capability interface is an essential building b= lock for Security Service Provider to automate their Security Controllers t= hat can utilize NSF by multiple vendors. This layer will leverage the exist= ing 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 clien= ts and demonstrating the feasibility of them being translated to the Capabi= lity Layer policies. Since different security vendors support different features & functions on = their devices, I2NSF will focus on flow based security functions that provi= de 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 Base= d Security functions include deep packet inspection, packet/flow/stream fil= tering or pattern matching and remediation, etc. Similar to I2RS focusing on the interface to RIB/FIB even though most route= rs 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 I2N= SF interfaces. I2NSF WG Deliverables include: - Use Case document. - Framework Document. - Requirement for extensions (if there are any) to existing protoc= ols 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 ab= ove Information Model. - IANA registry consideration for flow based security function pol= icy provisioning capability. - (Optionally) Applicability Statements on how to use I2RS, Netco= nf, and NETMOD to carry the content of the specified information/data model= s. [The WG may decide that the Use cases, Framework, and Requirement are Infor= mational 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 W= G 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 com= municate with external SDOs like ETSI NFV and will encourage open source co= de development related to the WG scope in organizations like ONF, OpenStack= , ODL, and OpenNFV. Cheers, Linda Dunbar __________________________________________= _____ I2nsf mailing list I2nsf@ietf.org 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: diego.r.lopez@telefonica.com Tel: +34 913 129 041 Mobile: +34 682 051 091 ---------------------------------- ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o= copia sin autorizaci=F3n puede estar prohibida en virtud de la legislaci= =F3n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo = comunique inmediatamente por esta misma v=EDa y proceda a su destrucci=F3n. The information contained in this transmission is privileged and confidenti= al 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 co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, div= ulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o pode estar proibida em virtude= da legisla=E7=E3o vigente. Se recebeu esta mensagem por erro, rogamos-lhe = que nos o comunique imediatamente por esta mesma via e proceda a sua destru= i=E7=E3o --_000_CY1PR09MB0922EA24176686A991AB75E9A8C70CY1PR09MB0922namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

- 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 a= nd services … the plus side of “old school” is often R= 20;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 fut= ure mode of operation (FMO) – and that will be intent-driven policy-b= ased provisioning (as a subset of intent-driven policy-based network management). Clearly, there is still some time on the tenure clock for dev= ice-type-specific-protocol-driven provisioning, and maybe that’s wher= e this work should focus. But I, personally, would rather see it buy into t= he FMO and contribute per Linda’s and John’s compromise.

 

From the sidelines,

BobN

 

From: I2nsf [mailto:i2nsf-bounces@ie= tf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Friday, May 15, 2015 12:21 PM
To: Linda Dunbar; John Strassner; DIEGO LOPEZ GARCIA
Cc: i2nsf@ietf.org; Kathleen Moriarty
Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new char= ter for IETF 93

 

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 provision= ing and monitoring aspects of NSFs. Other aspects of NSFs such as device or network provisioning are out of scope. T= his should include an information model and a set of data models and softwa= re interfaces for specifying, representing, querying, monitoring, and contr= olling security functions including the security policy aspects of NSFs by one or more management entities.

 

Regards,

 

Dan

 

 

From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Linda Dunbar
Sent: Friday, May 15, 2015 7:02 PM
To: John Strassner; Romascanu, Dan (Dan); DIEGO LOPEZ GARCIA
Cc: i2nsf@ietf.org; Kathleen M= oriarty
Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new char= ter for IETF 93

 

 

John,

 

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

 

“The primary goal o= f 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 commun= icating, querying, and changing the configuration of NSFs by one or more ma= nagement 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. T= his should include an information model and a set of data models and softwa= re interfaces for specifying, representing, querying, monitoring, and contr= olling 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: i2nsf@ietf.org; Kathleen M= oriarty; Linda Dunbar
Subject: RE: [I2nsf] Further Narrowing the I2NSF scope: the new char= ter for IETF 93

 

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 req= uire 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 func= tional layers:
- Security Service and Policy Layer
- Capability (or Functional) Layer”<= /p>

 

This is from the first two paragraphs= .

 

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

 

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

-       = ;   Security Policies facing security functions (I2NSF = Capability Layer)

-       = ;   Security Policies facing clients (I2NSF Service Lay= er)

 

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 woul= d like to propose.

 

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

 

 

regards,

John

 

Dr. John Strassner, Ph.D.

CTO, Software Laboratory, CRD

3D"logo=

 

Futurewei Technologies<= /span>

US R&D Center

2330 Central Expressway
Building A, office A2-2143

Santa Clara, California   9= 5050

  Office:  +1.408.330.4923

  Email:   jo= hn.sc.strassner@huawei.com

 

 

 

From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Thursday, May 14, 2015 12:34 AM
To: DIEGO LOPEZ GARCIA; John Strassner
Cc: i2nsf@ietf.org; Kathleen M= oriarty; Linda Dunbar
Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new char= ter for IETF 93

 

(speaking as contributor)<= /span>

 

I agree with Diego’s observatio= n. I also agree and like many of the edits proposed by John, but I do not b= elieve 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 shou= ld not IMO exclude policy, but neither should make of it the central (or ex= clusive) focus.

 

Regards,

 

Dan

 

 

From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of DIEGO LOPEZ GARCIA
Sent: Thursday, May 14, 2015 1:06 AM
To: John Strassner
Cc: i2nsf@ietf.org; Kathleen M= oriarty; Linda Dunbar
Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new char= ter for IETF 93
Importance: High

 

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 difficu= lt to be understood by the community. I'd leave the primary goal definition as:

 

"The primary goal of I2NSF is to define an exte= nsible 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 d= ocuments, and let further development for a later stage.

 

Be goode,

 

On 13 May 2015, at 19:18 , John Strassner <John.sc.Strassner@huawei.com&= gt; wrote:

 

Dear Linda,=

 

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

 

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

 

Best regards,=

John

 

Dr. John Strassner, Ph.D.<= /o:p>

CTO, Software Laboratory, CRD

<image001.gif>

 

Futurewei Technologies<= span style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif">=

US R&D Center=

2330 Central Expressway
Building A, office A2-2143

Santa Clara, California   9= 5050

  Office:  +1.408.330.4923

  Email:   john.sc.strassner@huawei.com<= span style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif">=

 

 

 

From: I2nsf [ma= ilto:i2nsf-bounces@ietf.org] On Behalf Of <= /span>Linda Dunbar
Sent: Thursday, Ma= y 07, 2015 8:53 AM
To: i2nsf@ietf.org;= Kathleen Moriarty
Cc: i2rs@ietf.org; dots@ietf.org; netmod@ietf.org
Subject: [I2nsf] F= urther Narrowing the I2NSF scope: the new charter for IETF 93<= /o:p>

 

Thanks to I2NSF contributors for the good progresse= s made since  IETF92 side meetings. Among the two I2NSF interfaces, &n= bsp;i.e. the client facing Service Interface and the NSF facing Capability Interface, the work to be done at the Capability Interfa= ce becomes very clear and concrete. But the Service Interface is still a li= ttle vague.

 

The feedback from last IETF side meetings was "= ;the scope is too big for one IETF WG". Therefore, we are leaning towa= rds 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 Se= rvice Provider to automate their Security Controller that can utilize NSF by multiple vendors

 

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

 

 

 

Enterprises, residential, and mobile customers are = increasingly consuming network functions, especially network security relat= ed functions that are not running on their premises.  In addition, the European Telecommunications Standards Institute (ETSI) Ne= twork Function Virtualization (NFV) initiative creates new management chall= enges for security policies to be enforced by distributed, virtual, network= security functions (vNSF). Without standard interface to express, monitor, and manage security policies to se= curity functions deployed at different premises, it becomes virtually impos= sible for security service providers to automate the service offering utili= zing 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 perform= ance 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 p= olicy provisioning to the security functions (not devices), in the form of = “Subject – Object – Function – Action” paradi= gm. 

 

The I2NSF Service Layer is for clients to express a= nd monitor security policies for their specific flows, which is usually bas= ed on customers’ logical networks, addresses and context. I2NSF Service Layer can also be security expectation or loose sec= urity requirement, especially for customers who don’t have the securi= ty expertise.

 

The concrete work at the L2NSF Capability Layer inc= ludes

-          The informational & data models for each category to be represented to vir= tual 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 betwee= n Controller and NSFs.

The capability registry is to make it feasible to c= ategorize network security functions provided by different vendors based on= security policy provisioning capability without any need to standardize security functions themselves.  Standard prov= isioning capability interface is an essential building block for Security S= ervice 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 fea= sibility 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 s= ecurity functions that provide treatment to packets/flows, such as IPS/IDS, Web filter, and flow filter. (They are different from oth= er security functions such as Authentication, Authorization, or Encryption)= . Exemplar services associated with Flow Based Security functions include d= eep packet inspection, packet/flow/stream filtering or pattern matching and remediation, etc.

 

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

 

It is a non-goal to create new protocols or data mo= deling 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 Bas= ed 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 provisionin= g 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 do= cuments or simply reference documents during the lifetime of the WG. The = framework, that describes the functional components and the I2NSF work item= s, 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:&= nbsp; Charter time + 6 months to WG document

  - Info model: Charter time + 7 months to= WG Document

  - IANA registry consideration + 10 month= s to WG Document

  - All Early Drafts to IESG: 10 months

 

[decision point – +10 months] <= /o:p>

  - Data Models: Charter + 9 Months t= o WG Document

  - Applicability Statements: 10 months to WG = Document

  - Data Models and Applicability Statements t= o IESG  - 16 months

 

The WG will work closely with I2RS, Netconf and Net= mod 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

<i2nsf charter-jcs-20150512.docx>_______________________________= ________________
I2nsf mailing list
I2nsf@ietf.o= rg
https://www.ietf.org/mailman/lis= tinfo/i2nsf

 

--
"Esta vez no fallaremos, Doctor Infierno"

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

e-mail: diego.r.lopez@telef= onica.com
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------

 

 


Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o copia sin autorizaci=F3n puede e= star prohibida en virtud de la legislaci=F3n vigente. Si ha recibido este m= ensaje por error, le rogamos que nos lo comunique inmediatamente por esta m= isma v=EDa y proceda a su destrucci=F3n.

The information contained in this transmission is privileged and confidenti= al 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 y= ou have received this transmission in error, do not read it. Please immedia= tely 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=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, divulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o p= ode estar proibida em virtude da legisla=E7=E3o vigente. Se recebeu esta me= nsagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mes= ma via e proceda a sua destrui=E7=E3o

--_000_CY1PR09MB0922EA24176686A991AB75E9A8C70CY1PR09MB0922namp_-- --_004_CY1PR09MB0922EA24176686A991AB75E9A8C70CY1PR09MB0922namp_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif"; size=2669; creation-date="Fri, 15 May 2015 16:41:14 GMT"; modification-date="Fri, 15 May 2015 16:41:14 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhMgAyAPf/AO3b2elrUvbKwuNBIPa0g/GUa8WJguZWOfGjk8zMzKguI7Ozs/Hx8e+Pe6ZE OeZcQvvi3f39/eXl5et5YnNzc8lGNvj4+NU5I+6JdfS3qudZPfvl4OSimoyMjOlpTOx3VPSkdvnH lODg4JSUlKOjo/W4rBsbG+jo6NSDe9HR0fOfc9bW1p4uIvPj4f729ODAvP77+rkxJMuVj/749u6N e/nUzVNTU/jOxfGZhNRKOHh4eNnZ2e+Tgfa5ieM/IP3w7sQ0JOhhRuRAKcLCwjs7OzIyMuM8IOVR MelmTPb29uVNMUBAQPKuoQoKCvv7+xQUFCoqKktLS+WNgfr6+vrVxNZ4bvKpmZiYmPW9spcrH++L ZcGAeSMjI+ZRNPjRyPCXhfbBt7u7u/rd1vzq5803JK6urvWuf/nZ0uRGLeM9JfOlefa7mmNjY/fG vei7t9k7Iut3Xvrf2eRKKoaGhuREK/308vT09OVPL+2Gcv3y72xsbPOrnGhoaPrg25ycnP3v7PbF u7RGO6qqqlxcXO23sOZPNPGejfSoefv49t89Ifny8fjKtO2CXupxWO29uLdrY/XBuYGBgfzp4eyB av76+fOzpv75+Pbs6+tzYO3t7fjBjvCYifOwot3d3adLQe2Cbfzs6Prs6/bZ1eA+IeQ9JcbGxu/B u/Onm+S+uuhkR+M/H+VKL+yupeM8IvW7r+x7V/CPaP37+/Gdiex9Z9A5Jfra1O2FbtarpvnTzPfI v+x/WudcP+RHJ9w7IeVLMONDIudfRedXP+RCK//9/PnX0Pzt6v/+/fzu6/KXbvnQv+ZUN/nw7+x2 W967t+6cj+zGwvbQy/Pn5u+HYvfCr/Otl+M+I/OvnuvRzueAcPWwi/vt7PCMZ/zr6OhgQ/a/tvTW 0uNFI7BgV68vI+NEK+NELNxVQOydkelkRPnXyfa8o/vo5P3u5vWpfuZPOfa1kvSwn7pya757c+LG wuXIxf/8/OfNyuzLyPS0qOM7I+pxXvK9tepwT+NAIONCIAAAAP///yH5BAEAAP8ALAAAAAAyADIA QAj/AP8JHEiwoMBh6rydckHQmKRFkiwZM0ixosBin/o1mCHwz4R+/fgZaSVs1YFUoIxN24ZMBYiX KpDBSjawTwA6WIZZvOGDH78BIIPu2iDgSNCQPmjMECZE2DhyaNDMMnaKVCsjRvgdDfCH4KMs4mKQ ufBm1CwBM7B4ABr0C71GIMHAgAvOVZ4DR8FhiFPMSrejIJU0IBjhEoDD367Ze2bKEaFKTBDwqKHT YB1Om5hUKoEFUK4buGr1gQAhDiWLqFOrXm3ChB2BQ/wN+qfD35IRFJ5w2RHF35AkSSwsaTIk0xN/ UCT8u+LPnx6BYaA0icKHjR4GV55YWP0vToB+Poyk/0HTZZcXgTDWqCGgKYQmAocWTeQuEMKdn0cR wNjwHaTIVkKswgQMcKTiwT4IJvjOP9xM4IswaRjhwwANMDRQFVWg9c8xs/ikFWBg4IJXUIZQ0kVQ v0xSBxyABaUMJ/VZ0UglAlFiQBYsKBADEGP1MkpPvtCwwQ8ZBIEBDH0wtEEdtXSBAS6UYAFXiwN4 qIwAFrWwRRZcchkOKsvQJ1Af5uRwAS20kJEDIZZQ1JoEdliwgD98SMDFEicINIc/I/yThAk2dOCP HxEwNwdtTRBhQikMLFGEBHz4Q8I/FlQawQja0UdPJQdUkwYdSvDQpkDHqKAGO2aYscY6YhpkDEcD Df9jC0jhjVfILg3Q848kyIBgRg+a9ACfClQQBAMMqp2hRFBB1CCQLL/QKh6oB9xADw6vMCKNFtxK w0gDYvwDwx7KoJFGK5/kUdEePrEVFBx14KJBUPyER8omlGjQxQEa9NvvYG0EQ8e5WYF0BCgUzcBu u4DJQQwgdwDGwwxyhIeVEZjU0YCEHx51AAQFOSAOj+U4A3KRPgFmxRh/gbQHDC2Dg8MMQbT4yycg tzFJUEcE8E80DmShI48X+OgDMEwUUwMe0fZDwz+y9FMLPRjI0Yc6RvWzyx6gnIEBLy2GpMomBcXy QjwODN1jIj/21EgNuhY0DAwI3DHA3Xh7yA8vASD/EG5Fl8DTJZcshAUEEDmwcgxqxhCDR08+RD7K KIn08sYF+py2Wh2XhNmqQZaEoo3mFXEBRRIClfKEHhIUYYNy/3TwhB8CnVDEEx38s8ITRAi0Ahcm RCKQICZQsBwXTSTfxAkkmLAd8npQQIENztmJp0CC0k4EnZFw4c8CFtjwRBlP8HGCCVEIOmlvg0Si gw6R2OFHpvQNQwwGwbSzCi4EUZIOMuxwBxVI9zmLGOMeXagVGgqBhB8chAq+IkAPeqAqdRWwIgiI lgLLYw2duEANh2BPCEIAn2xI4oK1QIA6BnKMj4BnWoXQADNmYAx0FEAFh0iVGQ6hggLQZCBguEcd /1JDjz2A5A6VmAglZtWPAfgAQOTZhRiGQQ1GaKEAyMhiAWCxjWL9wwV4WIUQ2nEGi7igAR3rxwTU hYWsDQArQligK2Bgi3184BW6yOMrPiALdQkACWK8ygCcRRFAMCwoGrjBP3gADpA4cVr6QcIuunGO c6QiFeeAQw0sIQtfDAwrWklFVwzCCQ+5y2X/sEXTqhQeURUCDb5QQiFm+YA25CEfQoiQhFyEMIOA IhimlJgxZgEYCrmADkbARxrSQAo0uEIdwcBKTwCDgFEJpAWhEEgdOpQywMDBBZNoGki+QAm71csH qwADMXiBH8AcwRWViQMi/hGIGFRACtD4hyV4IP+HbjLLBYwMin5G1I8D1AAMYetHKsDwjz+UgC5B +EfadkSLNwTgHjPoAwZ+ccou/KASjexHBmDgAZCk4hicaNEuOGEMMfAgYiD5xRFS8Y9b4GhkPRpF qCCgDkOcCCRygMAZImatnc3iH4Y4SiPAkAcwTAkwqngAyGrKJbUVrW1waEMdAMGMfvxCDHVoBATo YQhD/OML/TjCF+IACgTMi0o+AcYGCKIIGbCgcDta2yjqFYQ9GAMCGbBQTeYYB1vIAa4eCkAuLIII AMwDFW5whCNMAYnKggELlaAMRergihKAoQ1tyEUuQAsIQAgAFytETT0c4InWeiIQgaiAbHPwhjf/ 0GAMFYGBAIDBDzkoQQldUAa/dvEAYDwAGw7M0lcGlyNxoOAb3PkBFoCRiOpa7nK0YEVlUqMIeRjg EVtoRjQuOANRcABDHBDFdi/IXu7sYAcREEgSEiABJ+ygE06oXQIyMZBOpGA7DEgB7KYgghUwQCAW WAF+/8GAHaTgwU7IxAoE8gTnpc4fbJCACYgAuz316R+RSJ4JGJCEIjRhwnPyRxTyS4HvLaAJXBjB AsoAvuw8zx+tMcFxWHenPP3Dw/8YgT/C8A8TQCECIvAHESxAhCIIwh8dSEETKGCB3uTYyCeY33ZM wIVKWSA2bLAdFBIQ3xaHgXxPeEITTKDkf5QBSjlPEEQE2LDmIuzgH4OQVAScMIX8Ymo7RSDCa/6R gNX9QwR8MEHyijCEFbjOx/9ong4ioIcn2CB1UDDBpASygCWoec0nEEQRthMQADs= --_004_CY1PR09MB0922EA24176686A991AB75E9A8C70CY1PR09MB0922namp_-- From nobody Fri May 15 09:55:20 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB2981A702A for ; Fri, 15 May 2015 09:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.621 X-Spam-Level: X-Spam-Status: No, score=-0.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQqo_45ah64z for ; Fri, 15 May 2015 09:55:10 -0700 (PDT) Received: from smtptc.telefonica.com (smtptc.telefonica.com [195.76.34.108]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C347F1A1BC8 for ; Fri, 15 May 2015 09:55:08 -0700 (PDT) Received: from smtptc.telefonica.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 68CCA37032A; Fri, 15 May 2015 18:55:06 +0200 (CEST) Received-SPF: PermError (tgtim3c01.telefonica.com: domain of diego.r.lopez@telefonica.com uses mechanism not recognized by this client) identity=MAILFROM; client-ip=10.92.4.9; envelope-from=diego.r.lopez@telefonica.com; helo=ESTGVMSP101.EUROPE.telefonica.corp) Received: from ESTGVMSP101.EUROPE.telefonica.corp (unknown [10.92.4.9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtptc.telefonica.com (Postfix) with ESMTPS id 439DD370313; Fri, 15 May 2015 18:55:06 +0200 (CEST) Received: from emea01-db3-obe.outbound.protection.outlook.com (10.92.5.139) by tls.telefonica.com (10.92.6.49) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 15 May 2015 18:55:05 +0200 Received: from DB4PR06MB0623.eurprd06.prod.outlook.com (25.161.13.141) by DB4PR06MB078.eurprd06.prod.outlook.com (10.242.155.22) with Microsoft SMTP Server (TLS) id 15.1.166.22; Fri, 15 May 2015 16:55:04 +0000 Received: from DB4PR06MB0624.eurprd06.prod.outlook.com (25.161.13.142) by DB4PR06MB0623.eurprd06.prod.outlook.com (25.161.13.141) with Microsoft SMTP Server (TLS) id 15.1.160.19; Fri, 15 May 2015 16:55:02 +0000 Received: from DB4PR06MB0624.eurprd06.prod.outlook.com ([25.161.13.142]) by DB4PR06MB0624.eurprd06.prod.outlook.com ([25.161.13.142]) with mapi id 15.01.0160.009; Fri, 15 May 2015 16:55:02 +0000 From: DIEGO LOPEZ GARCIA To: "Natale, Bob" Thread-Topic: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93 Thread-Index: AdCI3eREQdBVQ8yORRe/7nCVEnyK2QEwhD0wAApA4QAAE9hnAAAvQMMAABTJW4AAAKMrAAAAcnbgAAC/woA= Date: Fri, 15 May 2015 16:55:02 +0000 Message-ID: References: <4A95BA014132FF49AE685FAB4B9F17F657C11DC6@dfweml701-chm> <3AF7BE6A-DD17-4C1C-9F31-42C6D2AB99B5@telefonica.com> <9904FB1B0159DA42B0B887B7FA8119CA5CA2E131@AZ-FFEXMB04.global.avaya.com> <4A95BA014132FF49AE685FAB4B9F17F657C156AA@dfweml701-chm> <9904FB1B0159DA42B0B887B7FA8119CA5CA3090D@AZ-FFEXMB04.global.avaya.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: mitre.org; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [79.149.124.236] x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:DB4PR06MB0623; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:DB4PR06MB078; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:DB4PR06MB0623; BCL:0; PCL:0; RULEID:; SRVR:DB4PR06MB0623; x-forefront-prvs: 0577AD41D6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(40134004)(43234003)(377454003)(252514010)(93886004)(102836002)(15975445007)(19617315012)(189998001)(5001960100002)(110136002)(82746002)(50986999)(54356999)(76176999)(19580405001)(19580395003)(83716003)(46102003)(5890100001)(66066001)(86362001)(87936001)(2656002)(33656002)(16236675004)(77156002)(62966003)(36756003)(92566002)(122556002)(40100003)(2950100001)(2900100001)(7059030)(104396002)(579004)(559001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR06MB0623; H:DB4PR06MB0624.eurprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_B3982F8B58ED4196A57C13DC21CF4431telefonicacom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 May 2015 16:55:02.0569 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR06MB0623 X-OriginatorOrg: telefonica.com X-TM-AS-MML: No Archived-At: Cc: "i2nsf@ietf.org" , "Romascanu, Dan \(Dan\)" , John Strassner , Kathleen Moriarty , Linda Dunbar Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93 X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2015 16:55:20 -0000 --_000_B3982F8B58ED4196A57C13DC21CF4431telefonicacom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable 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-formin= g 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 with= in the community. I'd advocate for starting focused on a few concrete, shor= t-term goals, and move forward as we show results and a clear path from the= m to the higher-order mode of operation. Be goode, On 15 May 2015, at 18:41 , Natale, Bob > wrote: - I liked Linda=92s version =85 consider it a sensible adaptation of John= =92s version. - I would furthermore like to see this work explicitly connected with SUPA = for the policy dimension. - I understand Dan=92s perspective, but feel that it reflects an =93old sch= ool=94 way of managing network resources and services =85 the plus side of = =93old school=94 is often =93tried and true=94, so I don=92t mean it in a p= ejorative way =85 however, industry MUST move to a higher-order mode of ope= ration =96 the new future mode of operation (FMO) =96 and that will be inte= nt-driven policy-based provisioning (as a subset of intent-driven policy-ba= sed network management). Clearly, there is still some time on the tenure cl= ock for device-type-specific-protocol-driven provisioning, and maybe that= =92s where this work should focus. But I, personally, would rather see it b= uy into the FMO and contribute per Linda=92s and John=92s compromise. >From the sidelines, BobN From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Romascanu, Dan (Da= n) Sent: Friday, May 15, 2015 12:21 PM To: Linda Dunbar; John Strassner; DIEGO LOPEZ GARCIA Cc: i2nsf@ietf.org; Kathleen Moriarty Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new charter for= IETF 93 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 a= spects of NSFs such as device or network provisioning are out of scope. Thi= s should include an information model and a set of data models and software= interfaces for specifying, representing, querying, monitoring, and control= ling security functions including the security policy aspects of NSFs by on= e or more management entities. Regards, Dan From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Friday, May 15, 2015 7:02 PM To: John Strassner; Romascanu, Dan (Dan); DIEGO LOPEZ GARCIA Cc: i2nsf@ietf.org; Kathleen Moriarty Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new charter for= IETF 93 John, Maybe the wording =93policy framework=94 in your suggested charter makes pe= ople think that the scope is too big. =93The primary goal of I2NSF is to define an extensible policy framework fo= r managing NSFs. This should include an information model and a set of data= models and software interfaces for specifying, representing, querying, mon= itoring, and controlling NSFs. Management of NSFs should include communicat= ing, querying, and changing the configuration of NSFs by one or more manage= ment entities=94 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 aspe= cts of NSFs such as device or network provisioning are out of scope. This s= hould include an information model and a set of data models and software in= terfaces for specifying, representing, querying, monitoring, and controllin= g 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: i2nsf@ietf.org; Kathleen Moriarty; Linda Dunbar Subject: RE: [I2nsf] Further Narrowing the I2NSF scope: the new charter for= IETF 93 I=92m confused. If we go to the info page for I2NSF (https://www.ietf.org/mailman/listinfo/= I2NSF), we find, and = I quote: =93=85These trends require a standard interface to express, monitor, and ma= nage security policies for physical and virtual distributed security functi= ons that may be running on different premises. In order to address the above challenges, vNSF devices may include two func= tional layers: - Security Service and Policy Layer - Capability (or Functional) Layer=94 This is from the first two paragraphs. Note also that in the charter, the following lines were there before (and u= ntouched) by my edits: There are two layers of interfaces envisioned in the I2NSF approach: - Security Policies facing security functions (I2NSF Capability La= yer) - Security Policies facing clients (I2NSF Service Layer) Therefore, please explain what =93overuse of the term policy=94 means (Dieg= o), and why you believe that my edits =93focused around policies=94 (Dan). = I would also like to understand what =93alternative mechanisms=94 to policy= you would like to propose. I=92m certainly for consensus, and would like to help agree on the charter = asap; I just don=92t understand what in my edits made people think that it = is now too focused on policy, given the existing starting text. 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: john.sc.strassner@huawei.com From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Romascanu, Dan (Da= n) Sent: Thursday, May 14, 2015 12:34 AM To: DIEGO LOPEZ GARCIA; John Strassner Cc: i2nsf@ietf.org; Kathleen Moriarty; Linda Dunbar Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new charter for= IETF 93 (speaking as contributor) I agree with Diego=92s observation. I also agree and like many of the edits= proposed by John, but I do not believe that the scope should be focused ar= ound policies. Policies may be the right paradigm at certain layers, but th= ey 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:i2nsf-bounces@ietf.org] On Behalf Of DIEGO LOPEZ GARCIA Sent: Thursday, May 14, 2015 1:06 AM To: John Strassner Cc: i2nsf@ietf.org; Kathleen Moriarty; Linda Dunbar Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new charter for= IETF 93 Importance: High 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 th= e term "policy" in the document. The text talks about policy at two many la= yers and can become misleading and difficult to be understood by the commun= ity. I'd leave the primary goal definition as: "The primary goal of I2NSF is to define an extensible framework for managin= g 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 furth= er development for a later stage. Be goode, On 13 May 2015, at 19:18 , John Strassner > wrote: Dear Linda, First, thank you for pulling together these changes. The charter developmen= t has progressed nicely. Second, attached is a word document with my edits and suggestions for consi= deration by the working group. Despite the large number of edits and commen= ts, I am very supportive of I2NSF being made a working group, and would lik= e to volunteer to work on its deliverables. My edits and comments are to ad= dress 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: john.sc.strassner@huawei.com From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Thursday, May 07, 2015 8:53 AM To: i2nsf@ietf.org; Kathleen Moriarty Cc: i2rs@ietf.org; dots@ietf.org; netmod@ietf.org Subject: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IET= F 93 Thanks to I2NSF contributors for the good progresses made since IETF92 sid= e 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 I= nterface 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 t= he Capability Interface. The thinking logic is: Once the Capability Interfa= ce is completed, we will see more clearly the work for Service interface. E= ven if Capability layer alone is standardized, it is a giant leap forward i= n building blocks for Service Provider to automate their Security Controlle= r that can utilize NSF by multiple vendors Here is the narrower scoped I2NSF charter. Your comments and suggestions ar= e greatly appreciated. CC=92ed to DOTS, I2RS, and Netmod groups for wider r= eview. Enterprises, residential, and mobile customers are increasingly consuming n= etwork functions, especially network security related functions that are no= t 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 i= nterface to express, monitor, and manage security policies to security func= tions deployed at different premises, it becomes virtually impossible for s= ecurity service providers to automate the service offering utilizing securi= ty functions by multiple vendors. The ultimate goal of I2NSF is to enable enterprises to utilize security fun= ctions not hosted on their own premises but instead hosted in service provi= der domain, to establish how to communicate desired security policies to NS= F 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 La= yer) - Security Policies facing clients (I2NSF Service Layer) The I2NSF Capability Layer specifies the functional security policies, whic= h 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 =93Subject =96 Object =96 Function =96 Action=94 = paradigm. The I2NSF Service Layer is for clients to express and monitor security poli= cies for their specific flows, which is usually based on customers=92 logic= al networks, addresses and context. I2NSF Service Layer can also be securit= y expectation or loose security requirement, especially for customers who d= on=92t have the security expertise. The concrete work at the L2NSF Capability Layer includes - The informational & data models for each category to be represen= ted 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 p= olicies between Controller and NSFs. The capability registry is to make it feasible to categorize network securi= ty functions provided by different vendors based on security policy provisi= oning capability without any need to standardize security functions themsel= ves. Standard provisioning capability interface is an essential building b= lock for Security Service Provider to automate their Security Controllers t= hat can utilize NSF by multiple vendors. This layer will leverage the exist= ing 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 clien= ts and demonstrating the feasibility of them being translated to the Capabi= lity Layer policies. Since different security vendors support different features & functions on = their devices, I2NSF will focus on flow based security functions that provi= de 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 Base= d Security functions include deep packet inspection, packet/flow/stream fil= tering or pattern matching and remediation, etc. Similar to I2RS focusing on the interface to RIB/FIB even though most route= rs provide far more functions than RIB/FIB, the I2NSF focused functions can= be a portion of features supported by vendors=92 specific devices. It is a non-goal to create new protocols or data modeling languages for I2N= SF interfaces. I2NSF WG Deliverables include: - Use Case document. - Framework Document. - Requirement for extensions (if there are any) to existing protoc= ols 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 ab= ove Information Model. - IANA registry consideration for flow based security function pol= icy provisioning capability. - (Optionally) Applicability Statements on how to use I2RS, Netco= nf, and NETMOD to carry the content of the specified information/data model= s. [The WG may decide that the Use cases, Framework, and Requirement are Infor= mational 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 W= G 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 =96 +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 com= municate with external SDOs like ETSI NFV and will encourage open source co= de development related to the WG scope in organizations like ONF, OpenStack= , ODL, and OpenNFV. Cheers, Linda Dunbar __________________________________________= _____ I2nsf mailing list I2nsf@ietf.org 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: diego.r.lopez@telefonica.com Tel: +34 913 129 041 Mobile: +34 682 051 091 ---------------------------------- ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o= copia sin autorizaci=F3n puede estar prohibida en virtud de la legislaci= =F3n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo = comunique inmediatamente por esta misma v=EDa y proceda a su destrucci=F3n. The information contained in this transmission is privileged and confidenti= al 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 co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, div= ulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o pode estar proibida em virtude= da legisla=E7=E3o vigente. Se recebeu esta mensagem por erro, rogamos-lhe = que nos o comunique imediatamente por esta mesma via e proceda a sua destru= i=E7=E3o -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego.r.lopez@telefonica.com Tel: +34 913 129 041 Mobile: +34 682 051 091 ---------------------------------- ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o= copia sin autorizaci=F3n puede estar prohibida en virtud de la legislaci= =F3n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo = comunique inmediatamente por esta misma v=EDa y proceda a su destrucci=F3n. The information contained in this transmission is privileged and confidenti= al 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 co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, div= ulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o pode estar proibida em virtude= da legisla=E7=E3o vigente. Se recebeu esta mensagem por erro, rogamos-lhe = que nos o comunique imediatamente por esta mesma via e proceda a sua destru= i=E7=E3o --_000_B3982F8B58ED4196A57C13DC21CF4431telefonicacom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <41C0F6BA979F914DA9CF485658BCE707@eurprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable 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 accusatio= ns 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 cou= ld be "orchestration") that may mislead many within the community= . I'd advocate for starting focused on a few concrete, short-term goals, an= d 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 <RNATALE@mitre.org> wrote:

-= I liked Linda=92s version =85 consider it a sensible adaptation of John=92= s version.
&= nbsp;
-= I would furthermore like to see this work explicitly connected with SUPA f= or the policy dimension.
&= nbsp;
-= I understand Dan=92s perspective, but feel that it reflects an =93old scho= ol=94 way of managing network resources and services =85 the plus side of = =93old school=94 is often =93tried and true=94, so I don=92t mean it in a pejorative way =85 however, industry MUST move to a= higher-order mode of operation =96 the new future mode of operation (FMO) = =96 and that will be intent-driven policy-based provisioning (as a subset o= f intent-driven policy-based network management). Clearly, there is still some time on the tenure clock for device-type-spec= ific-protocol-driven provisioning, and maybe that=92s where this work shoul= d focus. But I, personally, would rather see it buy into the FMO and contri= bute per Linda=92s and John=92s compromise.
&= nbsp;
F= rom the sidelines,
B= obN
&= nbsp;
From:=  I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Romascanu,= Dan (Dan)
Sent: Friday, May = 15, 2015 12:21 PM
To: Linda Dunbar; = John Strassner; DIEGO LOPEZ GARCIA
Cc: i2nsf@ietf.org; Kathleen Moriarty
Subject: Re: [I2ns= f] Further Narrowing the I2NSF scope: the new charter for IETF 93
 
Hi Linda,
 
I believe that your wording still is too much policy-focus= ed. An interface from an enterprise to NSFs can be or can be not policy bas= ed. 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 m= odels for security functions provisioning and monitoring aspects of NSFs. O= ther aspects of NSFs such as device or network provisioning are out of scope. This should include an informati= on model and a set of data models and software interfaces for specifying, r= epresenting, querying, monitoring, and controlling security functions inclu= ding the security policy aspects of NSFs by one or more management entities.
 
Regards,
 
Dan
 
 
From:<= /span> I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Linda Dunb= ar
Sent: Friday, May = 15, 2015 7:02 PM
To: John Strassner= ; Romascanu, Dan (Dan); DIEGO LOPEZ GARCIA
Cc: i2= nsf@ietf.org; Kathleen Moriarty
Subject: Re: [I2ns= f] Further Narrowing the I2NSF scope: the new charter for IETF 93
 
 
John,
 
Maybe the wording =93policy framework=94 in your suggested= charter makes people think that the scope is too big.
 
=93The primary goal of I2NSF is to define an extensible policy framework fo= r managing NSFs. This should include an information model and a set of data= models and software interfaces for specifying, representing, querying, mon= itoring, and controlling NSFs. Management of NSFs should include communicating, querying, and changing the configura= tion of NSFs by one or more management entities=94
 
 
Do you think the following describes what you want?
 
The primary goal of I2NSF is to define a set of interfaces and data m= odels for security policy provisioning and monitoring aspects of NSFs. Othe= r 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, repr= esenting, querying, monitoring, and controlling security policy aspects of = NSFs by one or more management entities.
 
 
Linda
From:<= /span> John Strassner 
Sent: Friday, May = 15, 2015 1:07 AM
To: Romascanu, Dan= (Dan); DIEGO LOPEZ GARCIA
Cc: i2= nsf@ietf.org; Kathleen Moriarty; Linda Dunbar
Subject: RE: [I2ns= f] Further Narrowing the I2NSF scope: the new charter for IETF 93
 
I=92m confused.
 
If we go to the info page for I2NSF (https://www.ietf.org/mailma= n/listinfo/I2NSF), we find, and I quote:
 
=93=85These trends require a standard interface to = express, monitor, and manage security policies for physical and virtual dis= tributed security functions that may be running on different premises. =

In order to address the above challenges, vNSF devices may include two func= tional layers: 
- Security Service and Policy Layer&n= bsp;
- Capability (or Functional) Layer=94
 
This is from the first two paragraphs.
 
Note also that in the charter, the following lines were th= ere before (and untouched) by my edits:
 
There are two layers of interfaces envisioned in the I2NSF approach:
-          Security Policies facing s= ecurity functions (I2NSF Capability Layer)
-          Security Policies facing c= lients (I2NSF Service Layer)
 
Therefore, please explain what =93overuse of the term poli= cy=94 means (Diego), and why you believe that my edits =93focused around po= licies=94 (Dan). I would also like to understand what =93alternative mechanisms=94 to policy you would like to propose.
 
I=92m certainly for consensus, and would like to help agre= e on the charter asap; I just don=92t understand what in my edits made peop= le think that it is now too focused on policy, given the existing starting text.
 
 
regards,
John
 
Dr. John Strassner, Ph.D.
CTO, Software Laboratory, CRD

<image001.gif>

 
Futurewei Technologies
US R&D Center
2330 Central Expressway
Building A, office A2-2143
Santa Clara, California   95050=
  Of= fice:  +1.408.330.4923
  Em= ail:   john.sc.strassner@huawei.com
 
 
 
From:<= /span> I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Romascanu,= Dan (Dan)
Sent: Thursday, Ma= y 14, 2015 12:34 AM
To: DIEGO LOPEZ GA= RCIA; John Strassner
Cc: i2= nsf@ietf.org; Kathleen Moriarty; Linda Dunbar
Subject: Re: [I2ns= f] Further Narrowing the I2NSF scope: the new charter for IETF 93
 
(speaking as contributor)
 
I agree with Diego=92s observation. I also agree and like = many of the edits proposed by John, but I do not believe that the scope sho= uld be focused around policies. Policies may be the right paradigm at certain layers, but they are not the only met= hod for interoperable access and management of NSFs. The work should not IM= O exclude policy, but neither should make of it the central (or exclusive) = focus.
 
Regards,
 
Dan
 
 
From:<= /span> I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of DIEGO LOPE= Z GARCIA
Sent: Thursday, Ma= y 14, 2015 1:06 AM
To: John Strassner=
Cc: i2= nsf@ietf.org; Kathleen Moriarty; Linda Dunbar
Subject: Re: [I2ns= f] Further Narrowing the I2NSF scope: the new charter for IETF 93
Importance: High
 
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 th= e term "policy" in the document. The text talks about policy at t= wo 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 ma= naging NSFs" 
 
and consistently talk about "configuration", "management&quo= t; or "control" (the three terms have pros and cons...) when deal= ing with the Capability Layer, that I understand is the main goal of the pr= oposed charter.
 
I see policies more associated to the Service Layer, for which I think the = charter could consider some initial, informational documents, and let furth= er development for a later stage.
 
Be goode,
 
On 13 May 2015, at 19:18 , John Strassner <Joh= n.sc.Strassner@huawei.com> wrote:

 

Dear Linda,
 
First, thank you for pulling together these changes. The c= harter development has progressed nicely.
 
Second, attached is a word document with my edits and sugg= estions 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 o= n 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

<image001.gif>

 
Futurewei Technologies
US R&D Center
2330 Central Expressway
Building A, office A2-2143
Santa Clara, California   95050<= /div>
  Of= fice:  +1.408.330.4923
 
 
 
From:<= /span> I2nsf [mailto:i2nsf-bounces@i= etf.org] On= Behalf Of Linda Dunbar
Sent: Thursday, Ma= y 07, 2015 8:53 AM
To: i2nsf@ietf.org; Kathleen Moriarty Cc: i2rs@ietf.org; dots= @ietf.org; netmod@ietf.org
Subject: [I2nsf] F= urther Narrowing the I2NSF scope: the new charter for IETF 93
 
Thanks t= o I2NSF contributors for the good progresses made since  IETF92 side m= eetings. Among the two I2NSF interfaces,  i.e. the client facing Servi= ce Interface and the NSF facing Capability Interface, the work to be done at the Capability Interface becomes very clear and con= crete. But the Service Interface is still a little vague.=
 
The feed= back from last IETF side meetings was "the scope is too big for one IE= TF 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 t= he work for Service interface. Even if Capability layer alone is standardiz= ed, it is a giant leap forward in building blocks for Service Provider to a= utomate their Security Controller that can utilize NSF by multiple vendors
 
Here is = the narrower scoped I2NSF charter. Your comments and suggestions are greatl= y appreciated. CC=92ed to DOTS, I2RS, and Netmod groups for wider review.
 
 
 
Enterpri= ses, residential, and mobile customers are increasingly consuming network f= unctions, especially network security related functions that are not runnin= g on their premises.  In addition, the European Telecommunications Standards Institute (ETSI) Network Functio= n Virtualization (NFV) initiative creates new management challenges for sec= urity policies to be enforced by distributed, virtual, network security fun= ctions (vNSF). Without standard interface to express, monitor, and manage security policies to security fu= nctions deployed at different premises, it becomes virtually impossible for= security service providers to automate the service offering utilizing secu= rity functions by multiple vendors.
 
The ulti= mate goal of I2NSF is to enable enterprises to utilize security functions n= ot hosted on their own premises but instead hosted in service provider doma= in, to establish how to communicate desired security policies to NSF and how to get performance data or report= out of NSF or vNSF.
 
There ar= e two layers of interfaces:
-=        &= nbsp;  Security Polic= ies facing security functions (I2NSF Capability Layer)
-=        &= nbsp;  Security Polic= ies facing clients (I2NSF Service Layer)
 
The I2NS= F Capability Layer specifies the functional security policies, which are tr= anslated from the client security policies, to security functions. I2NSF wi= ll 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 =93Subject =96 Obje= ct =96 Function =96 Action=94 paradigm. 
 
The I2NS= F Service Layer is for clients to express and monitor security policies for= their specific flows, which is usually based on customers=92 logical netwo= rks, addresses and context. I2NSF Service Layer can also be security expectation or loose security requirement, espe= cially for customers who don=92t have the security expertise.
 
The conc= rete work at the L2NSF Capability Layer includes
-=        &= nbsp;  The informatio= nal & data models for each category to be represented to virtual or physical network securit= y functions,
-=        &= nbsp;  The capability= registry (IANA) of policy provisioning capability to flow based security function, and
-=        &= nbsp;  The proper sec= ure communication channels to carry the security policies between Controller and NSFs.<= /o:p>
The capa= bility registry is to make it feasible to categorize network security funct= ions provided by different vendors based on security policy provisioning ca= pability without any need to standardize security functions themselves.  Standard provisioning capability inte= rface is an essential building block for Security Service Provider to autom= ate their Security Controllers that can utilize NSF by multiple vendors. Th= is 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 informat= ional drafts showing sample APIs or/and RESTful interfaces to clients and demonstrating the feasibility of them be= ing translated to the Capability Layer policies.
 
Since di= fferent security vendors support different features & functions on thei= r devices, I2NSF will focus on flow based security functions that provide t= reatment to packets/flows, such as IPS/IDS, Web filter, and flow filter. (They are different from other security funct= ions such as Authentication, Authorization, or Encryption). Exemplar servic= es associated with Flow Based Security functions include deep packet inspec= tion, packet/flow/stream filtering or pattern matching and remediation, etc.
 
Similar = to I2RS focusing on the interface to RIB/FIB even though most routers provi= de far more functions than RIB/FIB, the I2NSF focused functions can be a po= rtion of features supported by vendors=92 specific devices.
 
It is a = non-goal to create new protocols or data modeling languages for I2NSF inter= faces.
I2NSF WG= Deliverables include:
 
-=        &= nbsp;   Use Case= document.
-=        &= nbsp;  Framework Docu= ment.
-=        &= nbsp;  Requirement fo= r extensions (if there are any) to existing protocols used by the WG.
-=        &= nbsp;   Gap anal= ysis of existing protocols and modeling languages
-=        &= nbsp;  A single, unif= ied, Information Model for expressing policies to the Flow Based Security Functions describ= ed above.
-=        &= nbsp;  Corresponding = Data Models (e.g. YANG models) derived from the above Information Model.
-=        &= nbsp;  IANA registry = consideration for flow based security function policy provisioning capability.
-=        &= nbsp;   (Optiona= lly) Applicability Statements on how to use I2RS, Netconf, and NETMOD to carry the content of the specif= ied information/data models.
 
[The WG may decide that the Use cases, Fram= ework, and Requirement are Informational documents or simply reference docu= ments during the lifetime of the WG.&= nbsp;The framework, that describes the functional components and the I2NSF work ite= ms, is to make I2NSF work more organized.]
 
Suggeste= d 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 month= s 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
 
[decisio= n point =96 +10 months] 
 &n= bsp;- Data Models: Charter + 9 Months to WG Document<= /div>
  -= Applicability Statements: 10 months to WG Document
  -= Data Models and Applicability Statements to IESG  - 16 months
 
The WG w= ill work closely with I2RS, Netconf and Netmod WGs. The WG will communicate= with external SDOs like ETSI NFV and will encourage open source code devel= opment related to the WG scope in organizations like ONF, OpenStack, ODL, and OpenNFV.
 
 
Cheers,<= o:p>
Linda Du= nbar
<i2nsf char= ter-jcs-20150512.docx>_______________________________________________ I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf
 
 
 

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o copia sin autorizaci=F3n puede e= star prohibida en virtud de la legislaci=F3n vigente. Si ha recibido este m= ensaje por error, le rogamos que nos lo comunique inmediatamente por esta m= isma v=EDa y proceda a su destrucci=F3n.

The information contained in this transmission is privileged and confidenti= al 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 y= ou have received this transmission in error, do not read it. Please immedia= tely 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=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, divulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o p= ode estar proibida em virtude da legisla=E7=E3o vigente. Se recebeu esta me= nsagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mes= ma via e proceda a sua destrui=E7=E3o

--
"Esta vez no fallaremos, Doctor Infierno"

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

e-mail: diego.r.lopez@telefonica.com
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------



Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o copia sin autorizaci=F3n puede e= star prohibida en virtud de la legislaci=F3n vigente. Si ha recibido este m= ensaje por error, le rogamos que nos lo comunique inmediatamente por esta m= isma v=EDa y proceda a su destrucci=F3n.

The information contained in this transmission is privileged and confidenti= al 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 y= ou have received this transmission in error, do not read it. Please immedia= tely 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=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, divulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o p= ode estar proibida em virtude da legisla=E7=E3o vigente. Se recebeu esta me= nsagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mes= ma via e proceda a sua destrui=E7=E3o
 --_000_B3982F8B58ED4196A57C13DC21CF4431telefonicacom_-- From nobody Fri May 15 21:55:13 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D747F1B2A08 for ; Fri, 15 May 2015 21:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.221 X-Spam-Level: X-Spam-Status: No, score=-2.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y91nJMs4Jfcp for ; Fri, 15 May 2015 21:55:00 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C317C1B2A02 for ; Fri, 15 May 2015 21:54:58 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BWC19260; Sat, 16 May 2015 04:54:56 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.218.25.35) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 16 May 2015 05:54:55 +0100 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.83]) by SJCEML702-CHM.china.huawei.com ([169.254.4.88]) with mapi id 14.03.0158.001; Fri, 15 May 2015 21:54:47 -0700 From: John Strassner To: Linda Dunbar , "Romascanu, Dan (Dan)" , DIEGO LOPEZ GARCIA , "John Strassner" Thread-Topic: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93 Thread-Index: AdCI3eREQdBVQ8yORRe/7nCVEnyK2QEwhD0wAApA4QAAIoN/AAAgQqQwACPHeoAACjcXsA== Date: Sat, 16 May 2015 04:54:46 +0000 Message-ID: References: <4A95BA014132FF49AE685FAB4B9F17F657C11DC6@dfweml701-chm> <3AF7BE6A-DD17-4C1C-9F31-42C6D2AB99B5@telefonica.com> <9904FB1B0159DA42B0B887B7FA8119CA5CA2E131@AZ-FFEXMB04.global.avaya.com> <4A95BA014132FF49AE685FAB4B9F17F657C156AA@dfweml701-chm> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657C156AA@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.47.151.88] Content-Type: multipart/related; boundary="_004_B818037A70EDCC4A86113DA25EC02098200B581FSJCEML701CHMchi_"; type="multipart/alternative" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "i2nsf@ietf.org" , Kathleen Moriarty Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93 X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2015 04:55:12 -0000 --_004_B818037A70EDCC4A86113DA25EC02098200B581FSJCEML701CHMchi_ Content-Type: multipart/alternative; boundary="_000_B818037A70EDCC4A86113DA25EC02098200B581FSJCEML701CHMchi_" --_000_B818037A70EDCC4A86113DA25EC02098200B581FSJCEML701CHMchi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Linda, While this is good speculation, I think we need Diego and Dan to clarify wh= at 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 s= oftware interfaces and data models, for monitoring and controlling the phys= ical and/or virtual policy provisioning and monitoring security aspects of = NSFs. Other aspects of NSFs, such as device or network provisioning, are ou= t of scope. This should include an information model and a set of data mode= ls and software interfaces for Monitoring and control of physical and/or vi= rtual NSFs should include the use of policies to specifying, representing, = querying, monitoring, and controlling the security policy aspects of NSFs b= y one or more management entities. However, I think that this runs the risk of de-emphasizing policy to the po= int that the WG runs the risk of not fully utilizing the capabilities and p= ower of policy management to scale and manage NSFs regards, John Dr. John Strassner, Ph.D. CTO, Software Laboratory, CRD [logo.gif] Futurewei Technologies US R&D Center 2330 Central Expressway Building A, office A2-2143 Santa Clara, California 95050 Office: +1.408.330.4923 Email: john.sc.strassner@huawei.com From: Linda Dunbar Sent: Friday, May 15, 2015 9:02 AM To: John Strassner; Romascanu, Dan (Dan); DIEGO LOPEZ GARCIA Cc: i2nsf@ietf.org; Kathleen Moriarty Subject: RE: [I2nsf] Further Narrowing the I2NSF scope: the new charter for= IETF 93 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 m= odels and software interfaces for specifying, representing, querying, monit= oring, and controlling NSFs. Management of NSFs should include communicatin= g, querying, and changing the configuration of NSFs by one or more manageme= nt 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 aspe= cts of NSFs such as device or network provisioning are out of scope. This s= hould include an information model and a set of data models and software in= terfaces for specifying, representing, querying, monitoring, and controllin= g 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: i2nsf@ietf.org; Kathleen Moriarty; Linda Dunbar Subject: RE: [I2nsf] Further Narrowing the I2NSF scope: the new charter for= IETF 93 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 mana= ge security policies for physical and virtual distributed security function= s that may be running on different premises. In order to address the above challenges, vNSF devices may include two func= tional 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 u= ntouched) by my edits: There are two layers of interfaces envisioned in the I2NSF approach: - Security Policies facing security functions (I2NSF Capability La= yer) - Security Policies facing clients (I2NSF Service 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 l= ike to propose. I'm certainly for consensus, and would like to help agree on the charter as= ap; I just don't understand what in my edits made people think that it is n= ow too focused on policy, given the existing starting text. regards, John Dr. John Strassner, Ph.D. CTO, Software Laboratory, CRD [logo.gif] Futurewei Technologies US R&D Center 2330 Central Expressway Building A, office A2-2143 Santa Clara, California 95050 Office: +1.408.330.4923 Email: john.sc.strassner@huawei.com From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Romascanu, Dan (Da= n) Sent: Thursday, May 14, 2015 12:34 AM To: DIEGO LOPEZ GARCIA; John Strassner Cc: i2nsf@ietf.org; Kathleen Moriarty; Linda Dunbar Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new charter for= IETF 93 (speaking as contributor) I agree with Diego's observation. I also agree and like many of the edits p= roposed by John, but I do not believe that the scope should be focused arou= nd policies. Policies may be the right paradigm at certain layers, but they= are not the only method for interoperable access and management of NSFs. T= he work should not IMO exclude policy, but neither should make of it the ce= ntral (or exclusive) focus. Regards, Dan From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of DIEGO LOPEZ GARCIA Sent: Thursday, May 14, 2015 1:06 AM To: John Strassner Cc: i2nsf@ietf.org; Kathleen Moriarty; Linda Dunbar Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new charter for= IETF 93 Importance: High 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 th= e term "policy" in the document. The text talks about policy at two many la= yers and can become misleading and difficult to be understood by the commun= ity. I'd leave the primary goal definition as: "The primary goal of I2NSF is to define an extensible framework for managin= g 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 furth= er development for a later stage. Be goode, On 13 May 2015, at 19:18 , John Strassner > wrote: Dear Linda, First, thank you for pulling together these changes. The charter developmen= t has progressed nicely. Second, attached is a word document with my edits and suggestions for consi= deration by the working group. Despite the large number of edits and commen= ts, I am very supportive of I2NSF being made a working group, and would lik= e to volunteer to work on its deliverables. My edits and comments are to ad= dress 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: john.sc.strassner@huawei.com From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Thursday, May 07, 2015 8:53 AM To: i2nsf@ietf.org; Kathleen Moriarty Cc: i2rs@ietf.org; dots@ietf.org; netmod@ietf.org Subject: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IET= F 93 Thanks to I2NSF contributors for the good progresses made since IETF92 sid= e 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 I= nterface 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 t= he Capability Interface. The thinking logic is: Once the Capability Interfa= ce is completed, we will see more clearly the work for Service interface. E= ven if Capability layer alone is standardized, it is a giant leap forward i= n building blocks for Service Provider to automate their Security Controlle= r that can utilize NSF by multiple vendors Here is the narrower scoped I2NSF charter. Your comments and suggestions ar= e greatly appreciated. CC'ed to DOTS, I2RS, and Netmod groups for wider rev= iew. Enterprises, residential, and mobile customers are increasingly consuming n= etwork functions, especially network security related functions that are no= t 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 i= nterface to express, monitor, and manage security policies to security func= tions deployed at different premises, it becomes virtually impossible for s= ecurity service providers to automate the service offering utilizing securi= ty functions by multiple vendors. The ultimate goal of I2NSF is to enable enterprises to utilize security fun= ctions not hosted on their own premises but instead hosted in service provi= der domain, to establish how to communicate desired security policies to NS= F 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 La= yer) - Security Policies facing clients (I2NSF Service Layer) The I2NSF Capability Layer specifies the functional security policies, whic= h 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 poli= cies 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 represen= ted 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 p= olicies between Controller and NSFs. The capability registry is to make it feasible to categorize network securi= ty functions provided by different vendors based on security policy provisi= oning capability without any need to standardize security functions themsel= ves. Standard provisioning capability interface is an essential building b= lock for Security Service Provider to automate their Security Controllers t= hat can utilize NSF by multiple vendors. This layer will leverage the exist= ing 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 clien= ts and demonstrating the feasibility of them being translated to the Capabi= lity Layer policies. Since different security vendors support different features & functions on = their devices, I2NSF will focus on flow based security functions that provi= de 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 Base= d Security functions include deep packet inspection, packet/flow/stream fil= tering or pattern matching and remediation, etc. Similar to I2RS focusing on the interface to RIB/FIB even though most route= rs 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 I2N= SF interfaces. I2NSF WG Deliverables include: - Use Case document. - Framework Document. - Requirement for extensions (if there are any) to existing protoc= ols 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 ab= ove Information Model. - IANA registry consideration for flow based security function pol= icy provisioning capability. - (Optionally) Applicability Statements on how to use I2RS, Netco= nf, and NETMOD to carry the content of the specified information/data model= s. [The WG may decide that the Use cases, Framework, and Requirement are Infor= mational 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 W= G 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 com= municate with external SDOs like ETSI NFV and will encourage open source co= de development related to the WG scope in organizations like ONF, OpenStack= , ODL, and OpenNFV. Cheers, Linda Dunbar __________________________________________= _____ I2nsf mailing list I2nsf@ietf.org 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: diego.r.lopez@telefonica.com Tel: +34 913 129 041 Mobile: +34 682 051 091 ---------------------------------- ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o= copia sin autorizaci=F3n puede estar prohibida en virtud de la legislaci= =F3n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo = comunique inmediatamente por esta misma v=EDa y proceda a su destrucci=F3n. The information contained in this transmission is privileged and confidenti= al 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 co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, div= ulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o pode estar proibida em virtude= da legisla=E7=E3o vigente. Se recebeu esta mensagem por erro, rogamos-lhe = que nos o comunique imediatamente por esta mesma via e proceda a sua destru= i=E7=E3o --_000_B818037A70EDCC4A86113DA25EC02098200B581FSJCEML701CHMchi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Linda,

 <= /p>

While this is good specul= ation, I think we need Diego and Dan to clarify what they really meant. Oth= erwise, we run the risk of guessing.

 <= /p>

With respect to your sugg= estion, I think the following is closer:

 <= /p>

The primary goal of I2NSF is to = define an information model, and a set of software = interfaces and data models, for moni= toring and controlling the physical and/or virtual policy provisioning and monitoring security aspects of NSFs. Other a= spects of NSFs, such as device or network provisioning, are out of scope. T= his should include an information model and a set of data models and softwa= re interfaces for = Monitoring and control of physical and/or virtual NSFs should include the u= se of policies to = specifying, representing, querying, monitoring, and controlling the = = security p= olicy aspects of NSFs by one or more management entities.

 <= /p>

However, I think that thi= s 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

 <= /p>

regards,<= /p>

John

 

Dr. John Strassner, Ph.D.

CTO, Software Laboratory, C= RD

3D"logo.gif"=

 

Futurewei Technologies=

US R&D Center=

2330 Central Expressway Building A, office A2-2143

Santa Clara, California&n= bsp;  95050

  Office:  +1.408.330.4923

  Email:   john.sc.strassner@huawei.com

 

 

 <= /p>

From: Linda Du= nbar
Sent: Friday, May 15, 2015 9:02 AM
To: John Strassner; Romascanu, Dan (Dan); DIEGO LOPEZ GARCIA
Cc: i2nsf@ietf.org; Kathleen Moriarty
Subject: RE: [I2nsf] Further Narrowing the I2NSF scope: the new char= ter for IETF 93

 

 <= /p>

John,

 <= /p>

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

 <= /p>

“The primary goal o= f 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 commun= icating, querying, and changing the configuration of NSFs by one or more ma= nagement entities”

 

 

Do you think the followin= g 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. T= his should include an information model and a set of data models and softwa= re interfaces for specifying, representing, querying, monitoring, and contr= olling security policy aspects of NSFs by one or more management entities.

 <= /p>

 <= /p>

Linda

From: John Str= assner
Sent: Friday, May 15, 2015 1:07 AM
To: Romascanu, Dan (Dan); DIEGO LOPEZ GARCIA
Cc: i2nsf@ietf.org; Kathleen Moriarty; Linda Dunbar
Subject: RE: [I2nsf] Further Narrowing the I2NSF scope: the new char= ter for IETF 93

 

I’m confused.<= /o:p>

 <= /p>

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

 <= /p>

“…Thes= e trends require a standard interface to express, monitor, and manage secur= ity 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 func= tional layers:
- Security Service and Policy Layer
- Capability (or Functional) Layer”

 <= /p>

This is from the first tw= o paragraphs.

 <= /p>

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

 <= /p>

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

-       = ;   Security Policies facing security functions (I2NSF = Capability Layer)

-       = ;   Security Policies facing clients (I2NSF Service Lay= er)

 <= /p>

Therefore, please explain= what “overuse of the term policy” means (Diego), and why you b= elieve that my edits “focused around policies” (Dan). I would a= lso like to understand what “alternative mechanisms” to policy you woul= d like to propose.

 <= /p>

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

 <= /p>

 <= /p>

regards,<= /p>

John

 

Dr. John Strassner, Ph.D.

CTO, Software Laboratory, C= RD

 

Futurewei Technologies=

US R&D Center=

2330 Central Expressway Building A, office A2-2143

Santa Clara, California&n= bsp;  95050

  Office:  +1.408.330.4923

  Email:   jo= hn.sc.strassner@huawei.com

 

 

 <= /p>

From: I2nsf [<= a href=3D"mailto:i2nsf-bounces@ietf.org">mailto:i2nsf-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Thursday, May 14, 2015 12:34 AM
To: DIEGO LOPEZ GARCIA; John Strassner
Cc: i2nsf@ietf.org; Kathleen M= oriarty; Linda Dunbar
Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new char= ter for IETF 93

 

(speaking as contributor)=

 <= /p>

I agree with Diego’= s observation. I also agree and like many of the edits proposed by John, bu= t 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 shou= ld not IMO exclude policy, but neither should make of it the central (or ex= clusive) focus.

 <= /p>

Regards,

 <= /p>

Dan

 <= /p>

 <= /p>

From: I2nsf [<= a href=3D"mailto:i2nsf-bounces@ietf.org">mailto:i2nsf-bounces@ietf.org] On Behalf Of DIEGO LOPEZ GARCIA
Sent: Thursday, May 14, 2015 1:06 AM
To: John Strassner
Cc: i2nsf@ietf.org; Kathleen M= oriarty; Linda Dunbar
Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new char= ter for IETF 93
Importance: High

 

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 difficu= lt to be understood by the community. I'd leave the primary goal definition as:

 

"The primary goal of I2NSF is to define an exte= nsible 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 d= ocuments, and let further development for a later stage.

 

Be goode,

 

On 13 May 2015, at 19:18 , John Strassner <John.sc.Strassner@huawei.com&= gt; wrote:

 

Dear Linda,

 

First, thank you for pull= ing together these changes. The charter development has progressed nicely.<= /span>

 

Second, attached is a wor= d document with my edits and suggestions for consideration by the working g= roup. 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

 <= o:p>

Dr. John Strassner, Ph.D.

CTO, Software Laboratory, C= RD

<image001.gif>

 

Futurewei Technologies=

US R&D Center

2330 Central Expressway Building A, office A2-2143

Santa Clara, California&n= bsp;  95050

  Office:  +1.408.330.4923

  Email:   john.sc.strassner@huawei.com=

 <= o:p>

 <= o:p>

 

From: I2nsf [ma= ilto:i2nsf-bounces@ietf.org] On Behalf Of <= /span>Linda Dunbar
Sent: Thursday, Ma= y 07, 2015 8:53 AM
To: i2nsf@ietf.org;= Kathleen Moriarty
Cc: i2rs@ietf.org; dots@ietf.org; netmod@ietf.org
Subject: [I2nsf] F= urther Narrowing the I2NSF scope: the new charter for IETF 93

 

Thanks to I2NSF contributors for the go= od progresses made since  IETF92 side meetings. Among the two I2NSF in= terfaces,  i.e. the client facing Service Interface and the NSF facing Capability Interface, the work to be done at the Capability Interfa= ce becomes very clear and concrete. But the Service Interface is still a li= ttle vague.

 

The feedback from last IETF side meetin= gs 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 Se= rvice Provider to automate their Security Controller that can utilize NSF by multiple vendors

 

Here is the narrower scoped I2NSF chart= er. Your comments and suggestions are greatly appreciated. CC’ed to D= OTS, I2RS, and Netmod groups for wider review.

 

 

 

Enterprises, residential, and mobile cu= stomers are increasingly consuming network functions, especially network se= curity related functions that are not running on their premises.  In addition, the European Telecommunications Standards Institute (ETSI) Ne= twork Function Virtualization (NFV) initiative creates new management chall= enges for security policies to be enforced by distributed, virtual, network= security functions (vNSF). Without standard interface to express, monitor, and manage security policies to se= curity functions deployed at different premises, it becomes virtually impos= sible for security service providers to automate the service offering utili= zing 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 perform= ance data or report out of NSF or vNSF.

 

There are two layers of interfaces:

-       &nb= sp;  Security Policies facing security functions (I2NSF Capability Layer)

-       &nb= sp;  Security Policies facing clients (I2NSF Service Layer)

 

The I2NSF Capability Layer specifies th= e functional security policies, which are translated from the client securi= ty policies, to security functions. I2NSF will NOT standardize security functions or devices. Instead, I2NSF is only to standardize the p= olicy provisioning to the security functions (not devices), in the form of = “Subject – Object – Function – Action” paradi= gm. 

 

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 se= curity expertise.

 

The concrete work at the L2NSF Capabili= ty Layer includes

-       &nb= sp;  The informational & data models for each category to be represented to vir= tual or physical network security functions,

-       &nb= sp;  The capability registry (IANA) of policy provisioning capability to flow based= security function, and

-       &nb= sp;  The proper secure communication channels to carry the security policies betwee= n Controller and NSFs.

The capability registry is to make it f= easible to categorize network security functions provided by different vend= ors based on security policy provisioning capability without any need to standardize security functions themselves.  Standard prov= isioning capability interface is an essential building block for Security S= ervice 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 faci= ng 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 suppor= t 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 oth= er security functions such as Authentication, Authorization, or Encryption)= . Exemplar services associated with Flow Based Security functions include d= eep packet inspection, packet/flow/stream filtering or pattern matching and remediation, etc.

 

Similar to I2RS focusing on the interfa= ce 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 protocol= s or data modeling languages for I2NSF interfaces.

I2NSF WG Deliverables include:

 

-       &nb= sp;   Use Case document.

-       &nb= sp;  Framework Document.

-       &nb= sp;  Requirement for extensions (if there are any) to existing protocols used by the WG.

-       &nb= sp;   Gap analysis of existing protocols and modeling languages

-       &nb= sp;  A single, unified, Information Model for expressing policies to the Flow Bas= ed Security Functions described above.

-       &nb= sp;  Corresponding Data Models (e.g. YANG models) derived from the above Information Model.

-       &nb= sp;  IANA registry consideration for flow based security function policy provisionin= g capability.

-       &nb= sp;   (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 Info= rmational documents or simply reference documents during the lifetime of the WG. The = framework, that describes the functional components and the I2NSF work item= s, is to make I2NSF work more organized.]

 

Suggested Milestones<= /p>

  - Use Case Document:  Chart= er 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 &#= 43; 10 months to WG Document

  - All Early Drafts to IESG: 10 m= onths

 

[decision point – +10 months]=  

  - Data Models: Charter += ; 9 Months to WG Document

  - Applicability Statements: 10 m= onths to WG Document

  - Data Models and Applicability = Statements to IESG  - 16 months

 

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

 

 

Cheers,

Linda Dunbar

<i2nsf charter-jcs-20150512.docx>_= ______________________________________________
I2nsf mailing list
I2nsf@ietf.o= rg
https://www.ietf.org/mailman/lis= tinfo/i2nsf

 

--
"Esta vez no fallaremos, Doctor Infierno"

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

e-mail: diego.r.lopez@telef= onica.com
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------

 

 


Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o copia sin autorizaci=F3n puede e= star prohibida en virtud de la legislaci=F3n vigente. Si ha recibido este m= ensaje por error, le rogamos que nos lo comunique inmediatamente por esta m= isma v=EDa y proceda a su destrucci=F3n.

The information contained in this transmission is privileged and confidenti= al 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 y= ou have received this transmission in error, do not read it. Please immedia= tely 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=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, divulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o p= ode estar proibida em virtude da legisla=E7=E3o vigente. Se recebeu esta me= nsagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mes= ma via e proceda a sua destrui=E7=E3o

--_000_B818037A70EDCC4A86113DA25EC02098200B581FSJCEML701CHMchi_-- --_004_B818037A70EDCC4A86113DA25EC02098200B581FSJCEML701CHMchi_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif"; size=2669; creation-date="Sat, 16 May 2015 04:54:45 GMT"; modification-date="Sat, 16 May 2015 04:54:45 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhMgAyAPf/AO3b2elrUvbKwuNBIPa0g/GUa8WJguZWOfGjk8zMzKguI7Ozs/Hx8e+Pe6ZE OeZcQvvi3f39/eXl5et5YnNzc8lGNvj4+NU5I+6JdfS3qudZPfvl4OSimoyMjOlpTOx3VPSkdvnH lODg4JSUlKOjo/W4rBsbG+jo6NSDe9HR0fOfc9bW1p4uIvPj4f729ODAvP77+rkxJMuVj/749u6N e/nUzVNTU/jOxfGZhNRKOHh4eNnZ2e+Tgfa5ieM/IP3w7sQ0JOhhRuRAKcLCwjs7OzIyMuM8IOVR MelmTPb29uVNMUBAQPKuoQoKCvv7+xQUFCoqKktLS+WNgfr6+vrVxNZ4bvKpmZiYmPW9spcrH++L ZcGAeSMjI+ZRNPjRyPCXhfbBt7u7u/rd1vzq5803JK6urvWuf/nZ0uRGLeM9JfOlefa7mmNjY/fG vei7t9k7Iut3Xvrf2eRKKoaGhuREK/308vT09OVPL+2Gcv3y72xsbPOrnGhoaPrg25ycnP3v7PbF u7RGO6qqqlxcXO23sOZPNPGejfSoefv49t89Ifny8fjKtO2CXupxWO29uLdrY/XBuYGBgfzp4eyB av76+fOzpv75+Pbs6+tzYO3t7fjBjvCYifOwot3d3adLQe2Cbfzs6Prs6/bZ1eA+IeQ9JcbGxu/B u/Onm+S+uuhkR+M/H+VKL+yupeM8IvW7r+x7V/CPaP37+/Gdiex9Z9A5Jfra1O2FbtarpvnTzPfI v+x/WudcP+RHJ9w7IeVLMONDIudfRedXP+RCK//9/PnX0Pzt6v/+/fzu6/KXbvnQv+ZUN/nw7+x2 W967t+6cj+zGwvbQy/Pn5u+HYvfCr/Otl+M+I/OvnuvRzueAcPWwi/vt7PCMZ/zr6OhgQ/a/tvTW 0uNFI7BgV68vI+NEK+NELNxVQOydkelkRPnXyfa8o/vo5P3u5vWpfuZPOfa1kvSwn7pya757c+LG wuXIxf/8/OfNyuzLyPS0qOM7I+pxXvK9tepwT+NAIONCIAAAAP///yH5BAEAAP8ALAAAAAAyADIA QAj/AP8JHEiwoMBh6rydckHQmKRFkiwZM0ixosBin/o1mCHwz4R+/fgZaSVs1YFUoIxN24ZMBYiX KpDBSjawTwA6WIZZvOGDH78BIIPu2iDgSNCQPmjMECZE2DhyaNDMMnaKVCsjRvgdDfCH4KMs4mKQ ufBm1CwBM7B4ABr0C71GIMHAgAvOVZ4DR8FhiFPMSrejIJU0IBjhEoDD367Ze2bKEaFKTBDwqKHT YB1Om5hUKoEFUK4buGr1gQAhDiWLqFOrXm3ChB2BQ/wN+qfD35IRFJ5w2RHF35AkSSwsaTIk0xN/ UCT8u+LPnx6BYaA0icKHjR4GV55YWP0vToB+Poyk/0HTZZcXgTDWqCGgKYQmAocWTeQuEMKdn0cR wNjwHaTIVkKswgQMcKTiwT4IJvjOP9xM4IswaRjhwwANMDRQFVWg9c8xs/ikFWBg4IJXUIZQ0kVQ v0xSBxyABaUMJ/VZ0UglAlFiQBYsKBADEGP1MkpPvtCwwQ8ZBIEBDH0wtEEdtXSBAS6UYAFXiwN4 qIwAFrWwRRZcchkOKsvQJ1Af5uRwAS20kJEDIZZQ1JoEdliwgD98SMDFEicINIc/I/yThAk2dOCP HxEwNwdtTRBhQikMLFGEBHz4Q8I/FlQawQja0UdPJQdUkwYdSvDQpkDHqKAGO2aYscY6YhpkDEcD Df9jC0jhjVfILg3Q848kyIBgRg+a9ACfClQQBAMMqp2hRFBB1CCQLL/QKh6oB9xADw6vMCKNFtxK w0gDYvwDwx7KoJFGK5/kUdEePrEVFBx14KJBUPyER8omlGjQxQEa9NvvYG0EQ8e5WYF0BCgUzcBu u4DJQQwgdwDGwwxyhIeVEZjU0YCEHx51AAQFOSAOj+U4A3KRPgFmxRh/gbQHDC2Dg8MMQbT4yycg tzFJUEcE8E80DmShI48X+OgDMEwUUwMe0fZDwz+y9FMLPRjI0Yc6RvWzyx6gnIEBLy2GpMomBcXy QjwODN1jIj/21EgNuhY0DAwI3DHA3Xh7yA8vASD/EG5Fl8DTJZcshAUEEDmwcgxqxhCDR08+RD7K KIn08sYF+py2Wh2XhNmqQZaEoo3mFXEBRRIClfKEHhIUYYNy/3TwhB8CnVDEEx38s8ITRAi0Ahcm RCKQICZQsBwXTSTfxAkkmLAd8npQQIENztmJp0CC0k4EnZFw4c8CFtjwRBlP8HGCCVEIOmlvg0Si gw6R2OFHpvQNQwwGwbSzCi4EUZIOMuxwBxVI9zmLGOMeXagVGgqBhB8chAq+IkAPeqAqdRWwIgiI lgLLYw2duEANh2BPCEIAn2xI4oK1QIA6BnKMj4BnWoXQADNmYAx0FEAFh0iVGQ6hggLQZCBguEcd /1JDjz2A5A6VmAglZtWPAfgAQOTZhRiGQQ1GaKEAyMhiAWCxjWL9wwV4WIUQ2nEGi7igAR3rxwTU hYWsDQArQligK2Bgi3184BW6yOMrPiALdQkACWK8ygCcRRFAMCwoGrjBP3gADpA4cVr6QcIuunGO c6QiFeeAQw0sIQtfDAwrWklFVwzCCQ+5y2X/sEXTqhQeURUCDb5QQiFm+YA25CEfQoiQhFyEMIOA IhimlJgxZgEYCrmADkbARxrSQAo0uEIdwcBKTwCDgFEJpAWhEEgdOpQywMDBBZNoGki+QAm71csH qwADMXiBH8AcwRWViQMi/hGIGFRACtD4hyV4IP+HbjLLBYwMin5G1I8D1AAMYetHKsDwjz+UgC5B +EfadkSLNwTgHjPoAwZ+ccou/KASjexHBmDgAZCk4hicaNEuOGEMMfAgYiD5xRFS8Y9b4GhkPRpF qCCgDkOcCCRygMAZImatnc3iH4Y4SiPAkAcwTAkwqngAyGrKJbUVrW1waEMdAMGMfvxCDHVoBATo YQhD/OML/TjCF+IACgTMi0o+AcYGCKIIGbCgcDta2yjqFYQ9GAMCGbBQTeYYB1vIAa4eCkAuLIII AMwDFW5whCNMAYnKggELlaAMRergihKAoQ1tyEUuQAsIQAgAFytETT0c4InWeiIQgaiAbHPwhjf/ 0GAMFYGBAIDBDzkoQQldUAa/dvEAYDwAGw7M0lcGlyNxoOAb3PkBFoCRiOpa7nK0YEVlUqMIeRjg EVtoRjQuOANRcABDHBDFdi/IXu7sYAcREEgSEiABJ+ygE06oXQIyMZBOpGA7DEgB7KYgghUwQCAW WAF+/8GAHaTgwU7IxAoE8gTnpc4fbJCACYgAuz316R+RSJ4JGJCEIjRhwnPyRxTyS4HvLaAJXBjB AsoAvuw8zx+tMcFxWHenPP3Dw/8YgT/C8A8TQCECIvAHESxAhCIIwh8dSEETKGCB3uTYyCeY33ZM wIVKWSA2bLAdFBIQ3xaHgXxPeEITTKDkf5QBSjlPEEQE2LDmIuzgH4OQVAScMIX8Ymo7RSDCa/6R gNX9QwR8MEHyijCEFbjOx/9ong4ioIcn2CB1UDDBpASygCWoec0nEEQRthMQADs= --_004_B818037A70EDCC4A86113DA25EC02098200B581FSJCEML701CHMchi_-- From nobody Sat May 16 01:00:28 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B93A91AD0BF for ; Sat, 16 May 2015 01:00:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.92 X-Spam-Level: X-Spam-Status: No, score=-4.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OwmmOdGsXqa4 for ; Sat, 16 May 2015 01:00:16 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FF3C1AD0BC for ; Sat, 16 May 2015 01:00:16 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApkFALj3VlXGmAcV/2dsb2JhbABZA4JFISpUXgaFIa05AQEBAwaTMwYZAQaFeQKBLUwBAQEBAQGBC4QiAQEBAQMBAQECAQwIAQoIATQBAQcDBgUOAgIBCA0EBAEBBgEBAQIWAQYHAgUPAQEFCQECCRQJCAIEAQ0EAQYCBgYOiAoBDKd3rwIBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBIYShCKBAoQiEQECHgYHCQkCBgUBBAYBAgICAwiDBoEWBYZjhQ4Ghh5Qg1ABXYJKgkQBgmI+gyqCcQuLI4NYI2F8CSQcgVJvAQEBgQk5gQEBAQE X-IronPort-AV: E=Sophos;i="5.13,439,1427774400"; d="gif'147?scan'147,208,217,147";a="120845265" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 16 May 2015 04:00:11 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 16 May 2015 04:00:10 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0174.001; Sat, 16 May 2015 10:00:09 +0200 From: "Romascanu, Dan (Dan)" To: John Strassner , Linda Dunbar , DIEGO LOPEZ GARCIA Thread-Topic: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93 Thread-Index: AdCI3eREWnYgWx+c3k2SduRLi+ubTgEwhD0wAApA4QAAIoN/AAAgQqQwABDrgIAAJ419AAAB/XeQ Date: Sat, 16 May 2015 08:00:09 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5CA30E4D@AZ-FFEXMB04.global.avaya.com> References: <4A95BA014132FF49AE685FAB4B9F17F657C11DC6@dfweml701-chm> <3AF7BE6A-DD17-4C1C-9F31-42C6D2AB99B5@telefonica.com> <9904FB1B0159DA42B0B887B7FA8119CA5CA2E131@AZ-FFEXMB04.global.avaya.com> <4A95BA014132FF49AE685FAB4B9F17F657C156AA@dfweml701-chm> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.47] Content-Type: multipart/related; boundary="_004_9904FB1B0159DA42B0B887B7FA8119CA5CA30E4DAZFFEXMB04globa_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Cc: "i2nsf@ietf.org" , Kathleen Moriarty Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93 X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2015 08:00:27 -0000 --_004_9904FB1B0159DA42B0B887B7FA8119CA5CA30E4DAZFFEXMB04globa_ Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA5CA30E4DAZFFEXMB04globa_" --_000_9904FB1B0159DA42B0B887B7FA8119CA5CA30E4DAZFFEXMB04globa_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I am fine with John's wording here. In order to avoid the risk of de-emphas= izing 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:John.sc.Strassner@huawei.com] Sent: Saturday, May 16, 2015 7:55 AM To: Linda Dunbar; Romascanu, Dan (Dan); DIEGO LOPEZ GARCIA; John Strassner Cc: i2nsf@ietf.org; Kathleen Moriarty Subject: RE: [I2nsf] Further Narrowing the I2NSF scope: the new charter for= IETF 93 Hi Linda, While this is good speculation, I think we need Diego and Dan to clarify wh= at 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 s= oftware interfaces and data models, for monitoring and controlling the phys= ical and/or virtual policy provisioning and monitoring security aspects of = NSFs. Other aspects of NSFs, such as device or network provisioning, are ou= t of scope. This should include an information model and a set of data mode= ls and software interfaces for Monitoring and control of physical and/or vi= rtual NSFs should include the use of policies to specifying, representing, = querying, monitoring, and controlling the security policy aspects of NSFs b= y one or more management entities. However, I think that this runs the risk of de-emphasizing policy to the po= int that the WG runs the risk of not fully utilizing the capabilities and p= ower of policy management to scale and manage NSFs regards, John Dr. John Strassner, Ph.D. CTO, Software Laboratory, CRD [logo.gif] Futurewei Technologies US R&D Center 2330 Central Expressway Building A, office A2-2143 Santa Clara, California 95050 Office: +1.408.330.4923 Email: john.sc.strassner@huawei.com From: Linda Dunbar Sent: Friday, May 15, 2015 9:02 AM To: John Strassner; Romascanu, Dan (Dan); DIEGO LOPEZ GARCIA Cc: i2nsf@ietf.org; Kathleen Moriarty Subject: RE: [I2nsf] Further Narrowing the I2NSF scope: the new charter for= IETF 93 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 m= odels and software interfaces for specifying, representing, querying, monit= oring, and controlling NSFs. Management of NSFs should include communicatin= g, querying, and changing the configuration of NSFs by one or more manageme= nt 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 aspe= cts of NSFs such as device or network provisioning are out of scope. This s= hould include an information model and a set of data models and software in= terfaces for specifying, representing, querying, monitoring, and controllin= g 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: i2nsf@ietf.org; Kathleen Moriarty; Linda Dunbar Subject: RE: [I2nsf] Further Narrowing the I2NSF scope: the new charter for= IETF 93 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 mana= ge security policies for physical and virtual distributed security function= s that may be running on different premises. In order to address the above challenges, vNSF devices may include two func= tional 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 u= ntouched) by my edits: There are two layers of interfaces envisioned in the I2NSF approach: - Security Policies facing security functions (I2NSF Capability La= yer) - Security Policies facing clients (I2NSF Service 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 l= ike to propose. I'm certainly for consensus, and would like to help agree on the charter as= ap; I just don't understand what in my edits made people think that it is n= ow too focused on policy, given the existing starting text. regards, John Dr. John Strassner, Ph.D. CTO, Software Laboratory, CRD [logo.gif] Futurewei Technologies US R&D Center 2330 Central Expressway Building A, office A2-2143 Santa Clara, California 95050 Office: +1.408.330.4923 Email: john.sc.strassner@huawei.com From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Romascanu, Dan (Da= n) Sent: Thursday, May 14, 2015 12:34 AM To: DIEGO LOPEZ GARCIA; John Strassner Cc: i2nsf@ietf.org; Kathleen Moriarty; Linda Dunbar Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new charter for= IETF 93 (speaking as contributor) I agree with Diego's observation. I also agree and like many of the edits p= roposed by John, but I do not believe that the scope should be focused arou= nd policies. Policies may be the right paradigm at certain layers, but they= are not the only method for interoperable access and management of NSFs. T= he work should not IMO exclude policy, but neither should make of it the ce= ntral (or exclusive) focus. Regards, Dan From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of DIEGO LOPEZ GARCIA Sent: Thursday, May 14, 2015 1:06 AM To: John Strassner Cc: i2nsf@ietf.org; Kathleen Moriarty; Linda Dunbar Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new charter for= IETF 93 Importance: High 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 th= e term "policy" in the document. The text talks about policy at two many la= yers and can become misleading and difficult to be understood by the commun= ity. I'd leave the primary goal definition as: "The primary goal of I2NSF is to define an extensible framework for managin= g 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 furth= er development for a later stage. Be goode, On 13 May 2015, at 19:18 , John Strassner > wrote: Dear Linda, First, thank you for pulling together these changes. The charter developmen= t has progressed nicely. Second, attached is a word document with my edits and suggestions for consi= deration by the working group. Despite the large number of edits and commen= ts, I am very supportive of I2NSF being made a working group, and would lik= e to volunteer to work on its deliverables. My edits and comments are to ad= dress 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: john.sc.strassner@huawei.com From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Thursday, May 07, 2015 8:53 AM To: i2nsf@ietf.org; Kathleen Moriarty Cc: i2rs@ietf.org; dots@ietf.org; netmod@ietf.org Subject: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IET= F 93 Thanks to I2NSF contributors for the good progresses made since IETF92 sid= e 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 I= nterface 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 t= he Capability Interface. The thinking logic is: Once the Capability Interfa= ce is completed, we will see more clearly the work for Service interface. E= ven if Capability layer alone is standardized, it is a giant leap forward i= n building blocks for Service Provider to automate their Security Controlle= r that can utilize NSF by multiple vendors Here is the narrower scoped I2NSF charter. Your comments and suggestions ar= e greatly appreciated. CC'ed to DOTS, I2RS, and Netmod groups for wider rev= iew. Enterprises, residential, and mobile customers are increasingly consuming n= etwork functions, especially network security related functions that are no= t 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 i= nterface to express, monitor, and manage security policies to security func= tions deployed at different premises, it becomes virtually impossible for s= ecurity service providers to automate the service offering utilizing securi= ty functions by multiple vendors. The ultimate goal of I2NSF is to enable enterprises to utilize security fun= ctions not hosted on their own premises but instead hosted in service provi= der domain, to establish how to communicate desired security policies to NS= F 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 La= yer) - Security Policies facing clients (I2NSF Service Layer) The I2NSF Capability Layer specifies the functional security policies, whic= h 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 poli= cies 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 represen= ted 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 p= olicies between Controller and NSFs. The capability registry is to make it feasible to categorize network securi= ty functions provided by different vendors based on security policy provisi= oning capability without any need to standardize security functions themsel= ves. Standard provisioning capability interface is an essential building b= lock for Security Service Provider to automate their Security Controllers t= hat can utilize NSF by multiple vendors. This layer will leverage the exist= ing 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 clien= ts and demonstrating the feasibility of them being translated to the Capabi= lity Layer policies. Since different security vendors support different features & functions on = their devices, I2NSF will focus on flow based security functions that provi= de 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 Base= d Security functions include deep packet inspection, packet/flow/stream fil= tering or pattern matching and remediation, etc. Similar to I2RS focusing on the interface to RIB/FIB even though most route= rs 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 I2N= SF interfaces. I2NSF WG Deliverables include: - Use Case document. - Framework Document. - Requirement for extensions (if there are any) to existing protoc= ols 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 ab= ove Information Model. - IANA registry consideration for flow based security function pol= icy provisioning capability. - (Optionally) Applicability Statements on how to use I2RS, Netco= nf, and NETMOD to carry the content of the specified information/data model= s. [The WG may decide that the Use cases, Framework, and Requirement are Infor= mational 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 W= G 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 com= municate with external SDOs like ETSI NFV and will encourage open source co= de development related to the WG scope in organizations like ONF, OpenStack= , ODL, and OpenNFV. Cheers, Linda Dunbar __________________________________________= _____ I2nsf mailing list I2nsf@ietf.org 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: diego.r.lopez@telefonica.com Tel: +34 913 129 041 Mobile: +34 682 051 091 ---------------------------------- ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o= copia sin autorizaci=F3n puede estar prohibida en virtud de la legislaci= =F3n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo = comunique inmediatamente por esta misma v=EDa y proceda a su destrucci=F3n. The information contained in this transmission is privileged and confidenti= al 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 co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, div= ulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o pode estar proibida em virtude= da legisla=E7=E3o vigente. Se recebeu esta mensagem por erro, rogamos-lhe = que nos o comunique imediatamente por esta mesma via e proceda a sua destru= i=E7=E3o --_000_9904FB1B0159DA42B0B887B7FA8119CA5CA30E4DAZFFEXMB04globa_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 <= /p>

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:

 <= /p>

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

 <= /p>

Regards,

 <= /p>

Dan

 <= /p>

From: John Str= assner [mailto:John.sc.Strassner@huawei.com]
Sent: Saturday, May 16, 2015 7:55 AM
To: Linda Dunbar; Romascanu, Dan (Dan); DIEGO LOPEZ GARCIA; John Str= assner
Cc: i2nsf@ietf.org; Kathleen Moriarty
Subject: RE: [I2nsf] Further Narrowing the I2NSF scope: the new char= ter for IETF 93

 

Hi Linda,

 <= /p>

While this is good specul= ation, I think we need Diego and Dan to clarify what they really meant. Oth= erwise, we run the risk of guessing.

 <= /p>

With respect to your sugg= estion, I think the following is closer:

 <= /p>

The primary goal of I2NSF is t= o define an information model, and a set of software = interfaces and data models, for moni= toring and controlling the physical and/or virtual policy provisioning and monitoring security aspects of NSFs. Other a= spects of NSFs, such as device or network provisioning, are out of scope. T= his should include an information model and a set of data models and softwa= re interfaces for = Monitoring and control of physical and/or virtual NSFs should include the u= se of policies to = specifying, representing, querying, monitoring, and controlling the = = security p= olicy aspects of NSFs by one or more management entities.

 <= /p>

However, I think that thi= s 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

 <= /p>

regards,<= /p>

John

 

Dr. John Strassner, Ph.D.

CTO, Software Laboratory, C= RD

3D"logo.gif"=

 

Futurewei Technologies=

US R&D Center=

2330 Central Expressway Building A, office A2-2143

Santa Clara, California&n= bsp;  95050

  Office:  +1.408.330.4923

  Email:   jo= hn.sc.strassner@huawei.com

 

 

 <= /p>

From: Linda Du= nbar
Sent: Friday, May 15, 2015 9:02 AM
To: John Strassner; Romascanu, Dan (Dan); DIEGO LOPEZ GARCIA
Cc: i2nsf@ietf.org; Kathleen M= oriarty
Subject: RE: [I2nsf] Further Narrowing the I2NSF scope: the new char= ter for IETF 93

 

 <= /p>

John,

 <= /p>

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

 <= /p>

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

 

 

Do you think the followin= g describes what you want?

 

The primary goal of I2NSF is t= o define a set of interfaces and data models for security policy provisioni= ng and monitoring aspects of NSFs. Other aspects of NSFs such as device or network provisioning are out of scope. T= his should include an information model and a set of data models and softwa= re interfaces for specifying, representing, querying, monitoring, and contr= olling security policy aspects of NSFs by one or more management entities.

 <= /p>

 <= /p>

Linda

From: John Str= assner
Sent: Friday, May 15, 2015 1:07 AM
To: Romascanu, Dan (Dan); DIEGO LOPEZ GARCIA
Cc: i2nsf@ietf.org; Kathleen M= oriarty; Linda Dunbar
Subject: RE: [I2nsf] Further Narrowing the I2NSF scope: the new char= ter for IETF 93

 

I’m confused.<= /o:p>

 <= /p>

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

 <= /p>

“…Thes= e trends require a standard interface to express, monitor, and manage secur= ity 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 func= tional layers:
- Security Service and Policy Layer
- Capability (or Functional) Layer”

 <= /p>

This is from the first tw= o paragraphs.

 <= /p>

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

 <= /p>

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

-       = ;   Security Policies facing s= ecurity functions (I2NSF Capability Layer)

-       = ;   Security Policies facing c= lients (I2NSF Service Layer)

 <= /p>

Therefore, please explain= what “overuse of the term policy” means (Diego), and why you b= elieve that my edits “focused around policies” (Dan). I would a= lso like to understand what “alternative mechanisms” to policy you woul= d like to propose.

 <= /p>

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

 <= /p>

 <= /p>

regards,<= /p>

John

 

Dr. John Strassner, Ph.D.

CTO, Software Laboratory, C= RD

 

Futurewei Technologies=

US R&D Center=

2330 Central Expressway Building A, office A2-2143

Santa Clara, California&n= bsp;  95050

  Office:  +1.408.330.4923

  Email:   jo= hn.sc.strassner@huawei.com

 

 

 <= /p>

From: I2nsf [<= a href=3D"mailto:i2nsf-bounces@ietf.org">mailto:i2nsf-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Thursday, May 14, 2015 12:34 AM
To: DIEGO LOPEZ GARCIA; John Strassner
Cc: i2nsf@ietf.org; Kathleen M= oriarty; Linda Dunbar
Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new char= ter for IETF 93

 

(speaking as contributor)=

 <= /p>

I agree with Diego’= s observation. I also agree and like many of the edits proposed by John, bu= t 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 shou= ld not IMO exclude policy, but neither should make of it the central (or ex= clusive) focus.

 <= /p>

Regards,

 <= /p>

Dan

 <= /p>

 <= /p>

From: I2nsf [<= a href=3D"mailto:i2nsf-bounces@ietf.org">mailto:i2nsf-bounces@ietf.org] On Behalf Of DIEGO LOPEZ GARCIA
Sent: Thursday, May 14, 2015 1:06 AM
To: John Strassner
Cc: i2nsf@ietf.org; Kathleen M= oriarty; Linda Dunbar
Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new char= ter for IETF 93
Importance: High

 

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 difficu= lt to be understood by the community. I'd leave the primary goal definition as:

 

"The primary goal of I2NSF is to define an exte= nsible 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 d= ocuments, and let further development for a later stage.

 

Be goode,

 

On 13 May 2015, at 19:18 , John Strassner <John.sc.Strassner@huawei.com&= gt; wrote:

 

Dear Linda,

 

First, thank you for pull= ing together these changes. The charter development has progressed nicely.<= /span>

 

Second, attached is a wor= d document with my edits and suggestions for consideration by the working g= roup. 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

 <= o:p>

Dr. John Strassner, Ph.D.

CTO, Software Laboratory, C= RD

<image001.gif>

 

Futurewei Technologies=

US R&D Center

2330 Central Expressway Building A, office A2-2143

Santa Clara, California&n= bsp;  95050

  Office:  +1.408.330.4923

  Email:   john.sc.strassner@huawei.com=

 <= o:p>

 <= o:p>

 

From: I2nsf [ma= ilto:i2nsf-bounces@ietf.org] On Behalf Of <= /span>Linda Dunbar
Sent: Thursday, Ma= y 07, 2015 8:53 AM
To: i2nsf@ietf.org;= Kathleen Moriarty
Cc: i2rs@ietf.org; dots@ietf.org; netmod@ietf.org
Subject: [I2nsf] F= urther Narrowing the I2NSF scope: the new charter for IETF 93

 

Thanks to I2NSF contributors for the go= od progresses made since  IETF92 side meetings. Among the two I2NSF in= terfaces,  i.e. the client facing Service Interface and the NSF facing Capability Interface, the work to be done at the Capability Interfa= ce becomes very clear and concrete. But the Service Interface is still a li= ttle vague.

 

The feedback from last IETF side meetin= gs 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 Se= rvice Provider to automate their Security Controller that can utilize NSF by multiple vendors

 

Here is the narrower scoped I2NSF chart= er. Your comments and suggestions are greatly appreciated. CC’ed to D= OTS, I2RS, and Netmod groups for wider review.

 

 

 

Enterprises, residential, and mobile cu= stomers are increasingly consuming network functions, especially network se= curity related functions that are not running on their premises.  In addition, the European Telecommunications Standards Institute (ETSI) Ne= twork Function Virtualization (NFV) initiative creates new management chall= enges for security policies to be enforced by distributed, virtual, network= security functions (vNSF). Without standard interface to express, monitor, and manage security policies to se= curity functions deployed at different premises, it becomes virtually impos= sible for security service providers to automate the service offering utili= zing 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 perform= ance data or report out of NSF or vNSF.

 

There are two layers of interfaces:

-<= span style=3D"font-size:7.0pt">       &n= bsp;  Security Policies facing security functions (I2NSF Capability Layer)

-<= span style=3D"font-size:7.0pt">       &n= bsp;  Security Policies facing clients (I2NSF Service Layer)

 

The I2NSF Capability Layer specifies th= e functional security policies, which are translated from the client securi= ty policies, to security functions. I2NSF will NOT standardize security functions or devices. Instead, I2NSF is only to standardize the p= olicy provisioning to the security functions (not devices), in the form of = “Subject – Object – Function – Action” paradi= gm. 

 

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 se= curity expertise.

 

The concrete work at the L2NSF Capabili= ty Layer includes

-<= span style=3D"font-size:7.0pt">       &n= bsp;  The informational & data models for each category to be represented to vir= tual or physical network security functions,

-<= span style=3D"font-size:7.0pt">       &n= bsp;  The capability registry (IANA) of policy provisioning capability to flow based= security function, and

-<= span style=3D"font-size:7.0pt">       &n= bsp;  The proper secure communication channels to carry the security policies betwee= n Controller and NSFs.

The capability registry is to make it f= easible to categorize network security functions provided by different vend= ors based on security policy provisioning capability without any need to standardize security functions themselves.  Standard prov= isioning capability interface is an essential building block for Security S= ervice 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 faci= ng 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 suppor= t 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 oth= er security functions such as Authentication, Authorization, or Encryption)= . Exemplar services associated with Flow Based Security functions include d= eep packet inspection, packet/flow/stream filtering or pattern matching and remediation, etc.

 

Similar to I2RS focusing on the interfa= ce 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 protocol= s or data modeling languages for I2NSF interfaces.

I2NSF WG Deliverables include:

 

-<= span style=3D"font-size:7.0pt">       &n= bsp;   Use Case document.

-<= span style=3D"font-size:7.0pt">       &n= bsp;  Framework Document.

-<= span style=3D"font-size:7.0pt">       &n= bsp;  Requirement for extensions (if there are any) to existing protocols used by the WG.

-<= span style=3D"font-size:7.0pt">       &n= bsp;   Gap analysis of existing protocols and modeling languages

-<= span style=3D"font-size:7.0pt">       &n= bsp;  A single, unified, Information Model for expressing policies to the Flow Bas= ed Security Functions described above.

-<= span style=3D"font-size:7.0pt">       &n= bsp;  Corresponding Data Models (e.g. YANG models) derived from the above Information Model.

-<= span style=3D"font-size:7.0pt">       &n= bsp;  IANA registry consideration for flow based security function policy provisionin= g capability.

-<= span style=3D"font-size:7.0pt">       &n= bsp;   (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 Info= rmational documents or simply reference documents during the lifetime of the WG. The = framework, that describes the functional components and the I2NSF work item= s, is to make I2NSF work more organized.]

 

Suggested Milestones<= /p>

  - Use Case Document:  Chart= er 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 &#= 43; 10 months to WG Document

  - All Early Drafts to IESG: 10 m= onths

 

[decision point – +10 months]=  

  - Data Models: Charter += ; 9 Months to WG Document

  - Applicability Statements: 10 m= onths to WG Document

  - Data Models and Applicability = Statements to IESG  - 16 months

 

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

 

 

Cheers,

Linda Dunbar

<i2nsf charter-jcs-20150512.docx>_______________________________= ________________
I2nsf mailing list
I2nsf@ietf.o= rg
https://www.ietf.org/mailman/lis= tinfo/i2nsf

 

--
"Esta vez no fallaremos, Doctor Infierno"

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

e-mail: diego.r.lopez@telef= onica.com
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------

 

 


Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o copia sin autorizaci=F3n puede e= star prohibida en virtud de la legislaci=F3n vigente. Si ha recibido este m= ensaje por error, le rogamos que nos lo comunique inmediatamente por esta m= isma v=EDa y proceda a su destrucci=F3n.

The information contained in this transmission is privileged and confidenti= al 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 y= ou have received this transmission in error, do not read it. Please immedia= tely 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=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, divulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o p= ode estar proibida em virtude da legisla=E7=E3o vigente. Se recebeu esta me= nsagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mes= ma via e proceda a sua destrui=E7=E3o

--_000_9904FB1B0159DA42B0B887B7FA8119CA5CA30E4DAZFFEXMB04globa_-- --_004_9904FB1B0159DA42B0B887B7FA8119CA5CA30E4DAZFFEXMB04globa_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif"; size=2669; creation-date="Sat, 16 May 2015 08:00:07 GMT"; modification-date="Sat, 16 May 2015 08:00:07 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhMgAyAPf/AO3b2elrUvbKwuNBIPa0g/GUa8WJguZWOfGjk8zMzKguI7Ozs/Hx8e+Pe6ZE OeZcQvvi3f39/eXl5et5YnNzc8lGNvj4+NU5I+6JdfS3qudZPfvl4OSimoyMjOlpTOx3VPSkdvnH lODg4JSUlKOjo/W4rBsbG+jo6NSDe9HR0fOfc9bW1p4uIvPj4f729ODAvP77+rkxJMuVj/749u6N e/nUzVNTU/jOxfGZhNRKOHh4eNnZ2e+Tgfa5ieM/IP3w7sQ0JOhhRuRAKcLCwjs7OzIyMuM8IOVR MelmTPb29uVNMUBAQPKuoQoKCvv7+xQUFCoqKktLS+WNgfr6+vrVxNZ4bvKpmZiYmPW9spcrH++L ZcGAeSMjI+ZRNPjRyPCXhfbBt7u7u/rd1vzq5803JK6urvWuf/nZ0uRGLeM9JfOlefa7mmNjY/fG vei7t9k7Iut3Xvrf2eRKKoaGhuREK/308vT09OVPL+2Gcv3y72xsbPOrnGhoaPrg25ycnP3v7PbF u7RGO6qqqlxcXO23sOZPNPGejfSoefv49t89Ifny8fjKtO2CXupxWO29uLdrY/XBuYGBgfzp4eyB av76+fOzpv75+Pbs6+tzYO3t7fjBjvCYifOwot3d3adLQe2Cbfzs6Prs6/bZ1eA+IeQ9JcbGxu/B u/Onm+S+uuhkR+M/H+VKL+yupeM8IvW7r+x7V/CPaP37+/Gdiex9Z9A5Jfra1O2FbtarpvnTzPfI v+x/WudcP+RHJ9w7IeVLMONDIudfRedXP+RCK//9/PnX0Pzt6v/+/fzu6/KXbvnQv+ZUN/nw7+x2 W967t+6cj+zGwvbQy/Pn5u+HYvfCr/Otl+M+I/OvnuvRzueAcPWwi/vt7PCMZ/zr6OhgQ/a/tvTW 0uNFI7BgV68vI+NEK+NELNxVQOydkelkRPnXyfa8o/vo5P3u5vWpfuZPOfa1kvSwn7pya757c+LG wuXIxf/8/OfNyuzLyPS0qOM7I+pxXvK9tepwT+NAIONCIAAAAP///yH5BAEAAP8ALAAAAAAyADIA QAj/AP8JHEiwoMBh6rydckHQmKRFkiwZM0ixosBin/o1mCHwz4R+/fgZaSVs1YFUoIxN24ZMBYiX KpDBSjawTwA6WIZZvOGDH78BIIPu2iDgSNCQPmjMECZE2DhyaNDMMnaKVCsjRvgdDfCH4KMs4mKQ ufBm1CwBM7B4ABr0C71GIMHAgAvOVZ4DR8FhiFPMSrejIJU0IBjhEoDD367Ze2bKEaFKTBDwqKHT YB1Om5hUKoEFUK4buGr1gQAhDiWLqFOrXm3ChB2BQ/wN+qfD35IRFJ5w2RHF35AkSSwsaTIk0xN/ UCT8u+LPnx6BYaA0icKHjR4GV55YWP0vToB+Poyk/0HTZZcXgTDWqCGgKYQmAocWTeQuEMKdn0cR wNjwHaTIVkKswgQMcKTiwT4IJvjOP9xM4IswaRjhwwANMDRQFVWg9c8xs/ikFWBg4IJXUIZQ0kVQ v0xSBxyABaUMJ/VZ0UglAlFiQBYsKBADEGP1MkpPvtCwwQ8ZBIEBDH0wtEEdtXSBAS6UYAFXiwN4 qIwAFrWwRRZcchkOKsvQJ1Af5uRwAS20kJEDIZZQ1JoEdliwgD98SMDFEicINIc/I/yThAk2dOCP HxEwNwdtTRBhQikMLFGEBHz4Q8I/FlQawQja0UdPJQdUkwYdSvDQpkDHqKAGO2aYscY6YhpkDEcD Df9jC0jhjVfILg3Q848kyIBgRg+a9ACfClQQBAMMqp2hRFBB1CCQLL/QKh6oB9xADw6vMCKNFtxK w0gDYvwDwx7KoJFGK5/kUdEePrEVFBx14KJBUPyER8omlGjQxQEa9NvvYG0EQ8e5WYF0BCgUzcBu u4DJQQwgdwDGwwxyhIeVEZjU0YCEHx51AAQFOSAOj+U4A3KRPgFmxRh/gbQHDC2Dg8MMQbT4yycg tzFJUEcE8E80DmShI48X+OgDMEwUUwMe0fZDwz+y9FMLPRjI0Yc6RvWzyx6gnIEBLy2GpMomBcXy QjwODN1jIj/21EgNuhY0DAwI3DHA3Xh7yA8vASD/EG5Fl8DTJZcshAUEEDmwcgxqxhCDR08+RD7K KIn08sYF+py2Wh2XhNmqQZaEoo3mFXEBRRIClfKEHhIUYYNy/3TwhB8CnVDEEx38s8ITRAi0Ahcm RCKQICZQsBwXTSTfxAkkmLAd8npQQIENztmJp0CC0k4EnZFw4c8CFtjwRBlP8HGCCVEIOmlvg0Si gw6R2OFHpvQNQwwGwbSzCi4EUZIOMuxwBxVI9zmLGOMeXagVGgqBhB8chAq+IkAPeqAqdRWwIgiI lgLLYw2duEANh2BPCEIAn2xI4oK1QIA6BnKMj4BnWoXQADNmYAx0FEAFh0iVGQ6hggLQZCBguEcd /1JDjz2A5A6VmAglZtWPAfgAQOTZhRiGQQ1GaKEAyMhiAWCxjWL9wwV4WIUQ2nEGi7igAR3rxwTU hYWsDQArQligK2Bgi3184BW6yOMrPiALdQkACWK8ygCcRRFAMCwoGrjBP3gADpA4cVr6QcIuunGO c6QiFeeAQw0sIQtfDAwrWklFVwzCCQ+5y2X/sEXTqhQeURUCDb5QQiFm+YA25CEfQoiQhFyEMIOA IhimlJgxZgEYCrmADkbARxrSQAo0uEIdwcBKTwCDgFEJpAWhEEgdOpQywMDBBZNoGki+QAm71csH qwADMXiBH8AcwRWViQMi/hGIGFRACtD4hyV4IP+HbjLLBYwMin5G1I8D1AAMYetHKsDwjz+UgC5B +EfadkSLNwTgHjPoAwZ+ccou/KASjexHBmDgAZCk4hicaNEuOGEMMfAgYiD5xRFS8Y9b4GhkPRpF qCCgDkOcCCRygMAZImatnc3iH4Y4SiPAkAcwTAkwqngAyGrKJbUVrW1waEMdAMGMfvxCDHVoBATo YQhD/OML/TjCF+IACgTMi0o+AcYGCKIIGbCgcDta2yjqFYQ9GAMCGbBQTeYYB1vIAa4eCkAuLIII AMwDFW5whCNMAYnKggELlaAMRergihKAoQ1tyEUuQAsIQAgAFytETT0c4InWeiIQgaiAbHPwhjf/ 0GAMFYGBAIDBDzkoQQldUAa/dvEAYDwAGw7M0lcGlyNxoOAb3PkBFoCRiOpa7nK0YEVlUqMIeRjg EVtoRjQuOANRcABDHBDFdi/IXu7sYAcREEgSEiABJ+ygE06oXQIyMZBOpGA7DEgB7KYgghUwQCAW WAF+/8GAHaTgwU7IxAoE8gTnpc4fbJCACYgAuz316R+RSJ4JGJCEIjRhwnPyRxTyS4HvLaAJXBjB AsoAvuw8zx+tMcFxWHenPP3Dw/8YgT/C8A8TQCECIvAHESxAhCIIwh8dSEETKGCB3uTYyCeY33ZM wIVKWSA2bLAdFBIQ3xaHgXxPeEITTKDkf5QBSjlPEEQE2LDmIuzgH4OQVAScMIX8Ymo7RSDCa/6R gNX9QwR8MEHyijCEFbjOx/9ong4ioIcn2CB1UDDBpASygCWoec0nEEQRthMQADs= --_004_9904FB1B0159DA42B0B887B7FA8119CA5CA30E4DAZFFEXMB04globa_-- From nobody Sat May 16 01:01:54 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB4551B2A98 for ; Sat, 16 May 2015 01:01:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.621 X-Spam-Level: X-Spam-Status: No, score=-0.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AbHyoRuKT1lJ for ; Sat, 16 May 2015 01:01:44 -0700 (PDT) Received: from smtptc.telefonica.com (smtptc.telefonica.com [195.76.34.108]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBF071AD0BF for ; Sat, 16 May 2015 01:01:42 -0700 (PDT) Received: from smtptc.telefonica.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 4324F602A5; Sat, 16 May 2015 10:01:40 +0200 (CEST) Received: from ESTGVMSP104.EUROPE.telefonica.corp (unknown [10.92.4.9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtptc.telefonica.com (Postfix) with ESMTPS id 1E8EA602EB; Sat, 16 May 2015 10:01:40 +0200 (CEST) Received: from emea01-am1-obe.outbound.protection.outlook.com (10.92.5.139) by tls.telefonica.com (10.93.6.50) with Microsoft SMTP Server (TLS) id 14.3.195.1; Sat, 16 May 2015 10:01:38 +0200 Received: from DB4PR06MB0623.eurprd06.prod.outlook.com (25.161.13.141) by DB4PR06MB0909.eurprd06.prod.outlook.com (25.161.250.141) with Microsoft SMTP Server (TLS) id 15.1.166.22; Sat, 16 May 2015 08:01:34 +0000 Received: from DB4PR06MB0624.eurprd06.prod.outlook.com (25.161.13.142) by DB4PR06MB0623.eurprd06.prod.outlook.com (25.161.13.141) with Microsoft SMTP Server (TLS) id 15.1.160.19; Sat, 16 May 2015 08:01:33 +0000 Received: from DB4PR06MB0624.eurprd06.prod.outlook.com ([25.161.13.142]) by DB4PR06MB0624.eurprd06.prod.outlook.com ([25.161.13.142]) with mapi id 15.01.0160.009; Sat, 16 May 2015 08:01:33 +0000 From: DIEGO LOPEZ GARCIA To: "Romascanu, Dan (Dan)" Thread-Topic: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93 Thread-Index: AdCI3eREQdBVQ8yORRe/7nCVEnyK2QEwhD0wAApA4QAAE9hnAAAvQMMAABTJW4AAGvrWAAAGeXWAAAAMXgA= Date: Sat, 16 May 2015 08:01:33 +0000 Message-ID: <290EEBA8-08F4-4D99-8FA0-8C2C0A8C55E6@telefonica.com> References: <4A95BA014132FF49AE685FAB4B9F17F657C11DC6@dfweml701-chm> <3AF7BE6A-DD17-4C1C-9F31-42C6D2AB99B5@telefonica.com> <9904FB1B0159DA42B0B887B7FA8119CA5CA2E131@AZ-FFEXMB04.global.avaya.com> <4A95BA014132FF49AE685FAB4B9F17F657C156AA@dfweml701-chm> <9904FB1B0159DA42B0B887B7FA8119CA5CA30E4D@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5CA30E4D@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: avaya.com; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [195.76.232.154] x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:DB4PR06MB0623; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:DB4PR06MB0909; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:DB4PR06MB0623; BCL:0; PCL:0; RULEID:; SRVR:DB4PR06MB0623; x-forefront-prvs: 057859F9C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(252514010)(43234003)(40134004)(51444003)(24454002)(83716003)(15975445007)(102836002)(92566002)(46102003)(19580405001)(19580395003)(82746002)(2656002)(2950100001)(2900100001)(87936001)(93886004)(33656002)(5890100001)(40100003)(16236675004)(19617315012)(36756003)(110136002)(5001960100002)(5001920100001)(122556002)(189998001)(86362001)(77156002)(62966003)(66066001)(76176999)(50986999)(54356999)(7059030)(104396002)(559001)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR06MB0623; H:DB4PR06MB0624.eurprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_290EEBA808F44D998FA08C2C0A8C55E6telefonicacom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 May 2015 08:01:33.4129 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR06MB0623 X-OriginatorOrg: telefonica.com X-TM-AS-MML: No Archived-At: Cc: "i2nsf@ietf.org" , John Strassner , Kathleen Moriarty , Linda Dunbar Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93 X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2015 08:01:52 -0000 --_000_290EEBA808F44D998FA08C2C0A8C55E6telefonicacom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I can only say +1 to Dan's suggestion... On 16 May 2015, at 10:00 , Romascanu, Dan (Dan) > wrote: Hi, I am fine with John=92s wording here. In order to avoid the risk of de-emph= asizing policy (which I believe is an important aspect, but not the exclusi= ve 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:John.sc.Strassner@huawei.com] Sent: Saturday, May 16, 2015 7:55 AM To: Linda Dunbar; Romascanu, Dan (Dan); DIEGO LOPEZ GARCIA; John Strassner Cc: i2nsf@ietf.org; Kathleen Moriarty Subject: RE: [I2nsf] Further Narrowing the I2NSF scope: the new charter for= IETF 93 Hi Linda, While this is good speculation, I think we need Diego and Dan to clarify wh= at 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 s= oftwareinterfaces and data models, for monitoring and controlling the physi= cal and/or virtualpolicy provisioning and monitoring security aspects of NS= Fs. 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 virt= ual NSFs should include the use of policies to specifying, representing, qu= erying, 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 po= int that the WG runs the risk of not fully utilizing the capabilities and p= ower of policy management to scale and manage NSFs 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: john.sc.strassner@huawei.com From: Linda Dunbar Sent: Friday, May 15, 2015 9:02 AM To: John Strassner; Romascanu, Dan (Dan); DIEGO LOPEZ GARCIA Cc: i2nsf@ietf.org; Kathleen Moriarty Subject: RE: [I2nsf] Further Narrowing the I2NSF scope: the new charter for= IETF 93 John, Maybe the wording =93policy framework=94 in your suggested charter makes pe= ople think that the scope is too big. =93The primary goal of I2NSF is to define an extensible policy framework fo= r managing NSFs. This should include an information model and a set of data= models and software interfaces for specifying, representing, querying, mon= itoring, and controlling NSFs. Management of NSFs should include communicat= ing, querying, and changing the configuration of NSFs by one or more manage= ment entities=94 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 aspe= cts of NSFs such as device or network provisioning are out of scope. This s= hould include an information model and a set of data models and software in= terfaces for specifying, representing, querying, monitoring, and controllin= g 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: i2nsf@ietf.org; Kathleen Moriarty; Linda Dunbar Subject: RE: [I2nsf] Further Narrowing the I2NSF scope: the new charter for= IETF 93 I=92m confused. If we go to the info page for I2NSF (https://www.ietf.org/mailman/listinfo/= I2NSF), we find, and = I quote: =93=85These trends require a standard interface to express, monitor, and ma= nage security policies for physical and virtual distributed security functi= ons that may be running on different premises. In order to address the above challenges, vNSF devices may include two func= tional layers: - Security Service and Policy Layer - Capability (or Functional) Layer=94 This is from the first two paragraphs. Note also that in the charter, the following lines were there before (and u= ntouched) by my edits: There are two layers of interfaces envisioned in the I2NSF approach: - Security Policies facing security functions (I2NSF Capability La= yer) - Security Policies facing clients (I2NSF Service Layer) Therefore, please explain what =93overuse of the term policy=94 means (Dieg= o), and why you believe that my edits =93focused around policies=94 (Dan). = I would also like to understand what =93alternative mechanisms=94 to policy= you would like to propose. I=92m certainly for consensus, and would like to help agree on the charter = asap; I just don=92t understand what in my edits made people think that it = is now too focused on policy, given the existing starting text. 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: john.sc.strassner@huawei.com From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Romascanu, Dan (Da= n) Sent: Thursday, May 14, 2015 12:34 AM To: DIEGO LOPEZ GARCIA; John Strassner Cc: i2nsf@ietf.org; Kathleen Moriarty; Linda Dunbar Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new charter for= IETF 93 (speaking as contributor) I agree with Diego=92s observation. I also agree and like many of the edits= proposed by John, but I do not believe that the scope should be focused ar= ound policies. Policies may be the right paradigm at certain layers, but th= ey 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:i2nsf-bounces@ietf.org] On Behalf Of DIEGO LOPEZ GARCIA Sent: Thursday, May 14, 2015 1:06 AM To: John Strassner Cc: i2nsf@ietf.org; Kathleen Moriarty; Linda Dunbar Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new charter for= IETF 93 Importance: High 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 th= e term "policy" in the document. The text talks about policy at two many la= yers and can become misleading and difficult to be understood by the commun= ity. I'd leave the primary goal definition as: "The primary goal of I2NSF is to define an extensible framework for managin= g 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 furth= er development for a later stage. Be goode, On 13 May 2015, at 19:18 , John Strassner > wrote: Dear Linda, First, thank you for pulling together these changes. The charter developmen= t has progressed nicely. Second, attached is a word document with my edits and suggestions for consi= deration by the working group. Despite the large number of edits and commen= ts, I am very supportive of I2NSF being made a working group, and would lik= e to volunteer to work on its deliverables. My edits and comments are to ad= dress 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: john.sc.strassner@huawei.com From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Thursday, May 07, 2015 8:53 AM To: i2nsf@ietf.org; Kathleen Moriarty Cc: i2rs@ietf.org; dots@ietf.org; netmod@ietf.org Subject: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IET= F 93 Thanks to I2NSF contributors for the good progresses made since IETF92 sid= e 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 I= nterface 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 t= he Capability Interface. The thinking logic is: Once the Capability Interfa= ce is completed, we will see more clearly the work for Service interface. E= ven if Capability layer alone is standardized, it is a giant leap forward i= n building blocks for Service Provider to automate their Security Controlle= r that can utilize NSF by multiple vendors Here is the narrower scoped I2NSF charter. Your comments and suggestions ar= e greatly appreciated. CC=92ed to DOTS, I2RS, and Netmod groups for wider r= eview. Enterprises, residential, and mobile customers are increasingly consuming n= etwork functions, especially network security related functions that are no= t 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 i= nterface to express, monitor, and manage security policies to security func= tions deployed at different premises, it becomes virtually impossible for s= ecurity service providers to automate the service offering utilizing securi= ty functions by multiple vendors. The ultimate goal of I2NSF is to enable enterprises to utilize security fun= ctions not hosted on their own premises but instead hosted in service provi= der domain, to establish how to communicate desired security policies to NS= F 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 La= yer) - Security Policies facing clients (I2NSF Service Layer) The I2NSF Capability Layer specifies the functional security policies, whic= h 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 =93Subject =96 Object =96 Function =96 Action=94 = paradigm. The I2NSF Service Layer is for clients to express and monitor security poli= cies for their specific flows, which is usually based on customers=92 logic= al networks, addresses and context. I2NSF Service Layer can also be securit= y expectation or loose security requirement, especially for customers who d= on=92t have the security expertise. The concrete work at the L2NSF Capability Layer includes - The informational & data models for each category to be represen= ted 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 p= olicies between Controller and NSFs. The capability registry is to make it feasible to categorize network securi= ty functions provided by different vendors based on security policy provisi= oning capability without any need to standardize security functions themsel= ves. Standard provisioning capability interface is an essential building b= lock for Security Service Provider to automate their Security Controllers t= hat can utilize NSF by multiple vendors. This layer will leverage the exist= ing 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 clien= ts and demonstrating the feasibility of them being translated to the Capabi= lity Layer policies. Since different security vendors support different features & functions on = their devices, I2NSF will focus on flow based security functions that provi= de 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 Base= d Security functions include deep packet inspection, packet/flow/stream fil= tering or pattern matching and remediation, etc. Similar to I2RS focusing on the interface to RIB/FIB even though most route= rs provide far more functions than RIB/FIB, the I2NSF focused functions can= be a portion of features supported by vendors=92 specific devices. It is a non-goal to create new protocols or data modeling languages for I2N= SF interfaces. I2NSF WG Deliverables include: - Use Case document. - Framework Document. - Requirement for extensions (if there are any) to existing protoc= ols 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 ab= ove Information Model. - IANA registry consideration for flow based security function pol= icy provisioning capability. - (Optionally) Applicability Statements on how to use I2RS, Netco= nf, and NETMOD to carry the content of the specified information/data model= s. [The WG may decide that the Use cases, Framework, and Requirement are Infor= mational 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 W= G 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 =96 +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 com= municate with external SDOs like ETSI NFV and will encourage open source co= de development related to the WG scope in organizations like ONF, OpenStack= , ODL, and OpenNFV. Cheers, Linda Dunbar __________________________________________= _____ I2nsf mailing list I2nsf@ietf.org 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: diego.r.lopez@telefonica.com Tel: +34 913 129 041 Mobile: +34 682 051 091 ---------------------------------- ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o= copia sin autorizaci=F3n puede estar prohibida en virtud de la legislaci= =F3n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo = comunique inmediatamente por esta misma v=EDa y proceda a su destrucci=F3n. The information contained in this transmission is privileged and confidenti= al 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 co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, div= ulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o pode estar proibida em virtude= da legisla=E7=E3o vigente. Se recebeu esta mensagem por erro, rogamos-lhe = que nos o comunique imediatamente por esta mesma via e proceda a sua destru= i=E7=E3o -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego.r.lopez@telefonica.com Tel: +34 913 129 041 Mobile: +34 682 051 091 ---------------------------------- ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o= copia sin autorizaci=F3n puede estar prohibida en virtud de la legislaci= =F3n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo = comunique inmediatamente por esta misma v=EDa y proceda a su destrucci=F3n. The information contained in this transmission is privileged and confidenti= al 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 co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, div= ulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o pode estar proibida em virtude= da legisla=E7=E3o vigente. Se recebeu esta mensagem por erro, rogamos-lhe = que nos o comunique imediatamente por esta mesma via e proceda a sua destru= i=E7=E3o --_000_290EEBA808F44D998FA08C2C0A8C55E6telefonicacom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <5634F9EE69219147ADD0160C4D599EFF@eurprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable I can only say +1 to Dan's suggestion...

On 16 May 2015, at 10:00 , Romascanu, Dan (Dan) <dromasca@avaya.com> wrote:

Hi,
 
I am fine with John=92s wording here. In order to avoid th= e risk of de-emphasizing policy (which I believe is an important aspect, bu= t 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:<= /span> John Strassner [mailto:John.sc.Strassner@huawei.com] 
Sent: Saturday, Ma= y 16, 2015 7:55 AM
To: Linda Dunbar; = Romascanu, Dan (Dan); DIEGO LOPEZ GARCIA; John Strassner
Cc: i2= nsf@ietf.org; Kathleen Moriarty
Subject: RE: [I2ns= f] Further Narrowing the I2NSF scope: the new charter for IETF 93
 
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 guessi= ng.
 
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 monit= oring and controlling the physical and/or virtualpolicy provisioning and moni= toring s= ecurity aspects of NSFs. Other aspects of NSFs, such = as device or network provisioning, are out of scope. = This sh= ould include an information model and a set of data models and software int= erfaces for Monitorin= g and control of physical and/or virtual NSFs should include the use of poli= cies to spec= ifying, representing, querying, monitoring, and controlling = ;the secur= ity policy<= span style=3D"font-size: 10pt; font-family: Consolas; color: rgb(31, 73, 12= 5);"> 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 c= apabilities and power of policy management to scale and manage NSFs
 
regards,
John
 
Dr. John Strassner, Ph.D.
CTO, Software Laboratory, CRD

<image001.gif>

 
Futurewei Technologies
US R&D Center
2330 Central Expressway
Building A, office A2-2143
Santa Clara, California   95050=
  Of= fice:  +1.408.330.4923
  Em= ail:   john.sc.strassner@huawei.com
 
 
 
From:<= /span> Linda Dunbar 
Sent: Friday, May = 15, 2015 9:02 AM
To: John Strassner= ; Romascanu, Dan (Dan); DIEGO LOPEZ GARCIA
Cc: i2= nsf@ietf.org; Kathleen Moriarty
Subject: RE: [I2ns= f] Further Narrowing the I2NSF scope: the new charter for IETF 93
 
 
John,
 
Maybe the wording =93policy framework=94 in your suggested= charter makes people think that the scope is too big.
 
=93The primary goal of I2NSF is to define an extensible policy framework fo= r managing NSFs. This should include an information model and a set of data= models and software interfaces for specifying, representing, querying, mon= itoring, and controlling NSFs. Management of NSFs should include communicating, querying, and changing the configura= tion of NSFs by one or more management entities=94
 
 
Do you think the following describes what you want?
 
The primary goal of I2NSF is to define a set of interfaces and data m= odels for security policy provisioning and monitoring aspects of NSFs. Othe= r 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, repr= esenting, querying, monitoring, and controlling security policy aspects of = NSFs by one or more management entities.
 
 
Linda
From:<= /span> John Strassner 
Sent: Friday, May = 15, 2015 1:07 AM
To: Romascanu, Dan= (Dan); DIEGO LOPEZ GARCIA
Cc: i2= nsf@ietf.org; Kathleen Moriarty; Linda Dunbar
Subject: RE: [I2ns= f] Further Narrowing the I2NSF scope: the new charter for IETF 93
 
I=92m confused.
 
If we go to the info page for I2NSF (https://www.ietf.org/mailma= n/listinfo/I2NSF), we find, and I quote:
 
=93=85These trends require a standard interface to = express, monitor, and manage security policies for physical and virtual dis= tributed security functions that may be running on different premises. =

In order to address the above challenges, vNSF devices may include two func= tional layers: 
- Security Service and Policy Layer&n= bsp;
- Capability (or Functional) Layer=94
 
This is from the first two paragraphs.
 
Note also that in the charter, the following lines were th= ere before (and untouched) by my edits:
 
There are two layers of interfaces envisioned in the I2NSF approach:
-          S= ecurity Policies facing security functions (I2NSF Capability Layer)
-          S= ecurity Policies facing clients (I2NSF Service Layer)
 
Therefore, please explain what =93overuse of the term poli= cy=94 means (Diego), and why you believe that my edits =93focused around po= licies=94 (Dan). I would also like to understand what =93alternative mechanisms=94 to policy you would like to propose.
 
I=92m certainly for consensus, and would like to help agre= e on the charter asap; I just don=92t understand what in my edits made peop= le think that it is now too focused on policy, given the existing starting text.
 
 
regards,
John
 
Dr. John Strassner, Ph.D.
CTO, Software Laboratory, CRD

<image001.gif>

 
Futurewei Technologies
US R&D Center
2330 Central Expressway
Building A, office A2-2143
Santa Clara, California   95050=
  Of= fice:  +1.408.330.4923
  Em= ail:   john.sc.strassner@huawei.com
 
 
 
From:<= /span> I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Romascanu,= Dan (Dan)
Sent: Thursday, Ma= y 14, 2015 12:34 AM
To: DIEGO LOPEZ GA= RCIA; John Strassner
Cc: i2= nsf@ietf.org; Kathleen Moriarty; Linda Dunbar
Subject: Re: [I2ns= f] Further Narrowing the I2NSF scope: the new charter for IETF 93
 
(speaking as contributor)
 
I agree with Diego=92s observation. I also agree and like = many of the edits proposed by John, but I do not believe that the scope sho= uld be focused around policies. Policies may be the right paradigm at certain layers, but they are not the only met= hod for interoperable access and management of NSFs. The work should not IM= O exclude policy, but neither should make of it the central (or exclusive) = focus.
 
Regards,
 
Dan
 
 
From:<= /span> I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of DIEGO LOPE= Z GARCIA
Sent: Thursday, Ma= y 14, 2015 1:06 AM
To: John Strassner=
Cc: i2= nsf@ietf.org; Kathleen Moriarty; Linda Dunbar
Subject: Re: [I2ns= f] Further Narrowing the I2NSF scope: the new charter for IETF 93
Importance: High
 
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 th= e term "policy" in the document. The text talks about policy at t= wo 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 ma= naging NSFs" 
 
and consistently talk about "configuration", "management&quo= t; or "control" (the three terms have pros and cons...) when deal= ing with the Capability Layer, that I understand is the main goal of the pr= oposed charter.
 
I see policies more associated to the Service Layer, for which I think the = charter could consider some initial, informational documents, and let furth= er development for a later stage.
 
Be goode,
 
On 13 May 2015, at 19:18 , John Strassner <Joh= n.sc.Strassner@huawei.com> wrote:

 

Dear Linda,
 
First, thank you for pulling together these changes. The c= harter development has progressed nicely.
 
Second, attached is a word document with my edits and sugg= estions 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 o= n 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

<image001.gif>

 
Futurewei Technologies
US R&D Center
2330 Central Expressway
Building A, office A2-2143
Santa Clara, California   95050<= /div>
  Of= fice:  +1.408.330.4923
 
 
 
From:<= /span> I2nsf [mailto:i2nsf-bounces@i= etf.org] On= Behalf Of Linda Dunbar
Sent: Thursday, Ma= y 07, 2015 8:53 AM
To: i2nsf@ietf.org; Kathleen Moriarty Cc: i2rs@ietf.org; dots= @ietf.org; netmod@ietf.org
Subject: [I2nsf] F= urther Narrowing the I2NSF scope: the new charter for IETF 93
 
Thanks t= o I2NSF contributors for the good progresses made since  IETF92 side m= eetings. Among the two I2NSF interfaces,  i.e. the client facing Servi= ce Interface and the NSF facing Capability Interface, the work to be done at the Capability Interface becomes very clear and con= crete. But the Service Interface is still a little vague.=
 
The feed= back from last IETF side meetings was "the scope is too big for one IE= TF 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 t= he work for Service interface. Even if Capability layer alone is standardiz= ed, it is a giant leap forward in building blocks for Service Provider to a= utomate their Security Controller that can utilize NSF by multiple vendors
 
Here is = the narrower scoped I2NSF charter. Your comments and suggestions are greatl= y appreciated. CC=92ed to DOTS, I2RS, and Netmod groups for wider review.
 
 
 
Enterpri= ses, residential, and mobile customers are increasingly consuming network f= unctions, especially network security related functions that are not runnin= g on their premises.  In addition, the European Telecommunications Standards Institute (ETSI) Network Functio= n Virtualization (NFV) initiative creates new management challenges for sec= urity policies to be enforced by distributed, virtual, network security fun= ctions (vNSF). Without standard interface to express, monitor, and manage security policies to security fu= nctions deployed at different premises, it becomes virtually impossible for= security service providers to automate the service offering utilizing secu= rity functions by multiple vendors.
 
The ulti= mate goal of I2NSF is to enable enterprises to utilize security functions n= ot hosted on their own premises but instead hosted in service provider doma= in, to establish how to communicate desired security policies to NSF and how to get performance data or report= out of NSF or vNSF.
 
There ar= e two layers of interfaces:
-=        &= nbsp;  Security Polic= ies facing security functions (I2NSF Capability Layer)
-=        &= nbsp;  Security Polic= ies facing clients (I2NSF Service Layer)
 
The I2NS= F Capability Layer specifies the functional security policies, which are tr= anslated from the client security policies, to security functions. I2NSF wi= ll 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 =93Subject =96 Obje= ct =96 Function =96 Action=94 paradigm. 
 
The I2NS= F Service Layer is for clients to express and monitor security policies for= their specific flows, which is usually based on customers=92 logical netwo= rks, addresses and context. I2NSF Service Layer can also be security expectation or loose security requirement, espe= cially for customers who don=92t have the security expertise.
 
The conc= rete work at the L2NSF Capability Layer includes
-=        &= nbsp;  The informatio= nal & data models for each category to be represented to virtual or physical network securit= y functions,
-=        &= nbsp;  The capability= registry (IANA) of policy provisioning capability to flow based security function, and
-=        &= nbsp;  The proper sec= ure communication channels to carry the security policies between Controller and NSFs.<= /o:p>
The capa= bility registry is to make it feasible to categorize network security funct= ions provided by different vendors based on security policy provisioning ca= pability without any need to standardize security functions themselves.  Standard provisioning capability inte= rface is an essential building block for Security Service Provider to autom= ate their Security Controllers that can utilize NSF by multiple vendors. Th= is 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 informat= ional drafts showing sample APIs or/and RESTful interfaces to clients and demonstrating the feasibility of them be= ing translated to the Capability Layer policies.
 
Since di= fferent security vendors support different features & functions on thei= r devices, I2NSF will focus on flow based security functions that provide t= reatment to packets/flows, such as IPS/IDS, Web filter, and flow filter. (They are different from other security funct= ions such as Authentication, Authorization, or Encryption). Exemplar servic= es associated with Flow Based Security functions include deep packet inspec= tion, packet/flow/stream filtering or pattern matching and remediation, etc.
 
Similar = to I2RS focusing on the interface to RIB/FIB even though most routers provi= de far more functions than RIB/FIB, the I2NSF focused functions can be a po= rtion of features supported by vendors=92 specific devices.
 
It is a = non-goal to create new protocols or data modeling languages for I2NSF inter= faces.
I2NSF WG= Deliverables include:
 
-=        &= nbsp;   Use Case= document.
-=        &= nbsp;  Framework Docu= ment.
-=        &= nbsp;  Requirement fo= r extensions (if there are any) to existing protocols used by the WG.
-=        &= nbsp;   Gap anal= ysis of existing protocols and modeling languages
-=        &= nbsp;  A single, unif= ied, Information Model for expressing policies to the Flow Based Security Functions describ= ed above.
-=        &= nbsp;  Corresponding = Data Models (e.g. YANG models) derived from the above Information Model.
-=        &= nbsp;  IANA registry = consideration for flow based security function policy provisioning capability.
-=        &= nbsp;   (Optiona= lly) Applicability Statements on how to use I2RS, Netconf, and NETMOD to carry the content of the specif= ied information/data models.
 
[The WG may decide that the Use cases, Fram= ework, and Requirement are Informational documents or simply reference docu= ments during the lifetime of the WG.&= nbsp;The framework, that describes the functional components and the I2NSF work ite= ms, is to make I2NSF work more organized.]
 
Suggeste= d 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 month= s 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
 
[decisio= n point =96 +10 months] 
 &n= bsp;- Data Models: Charter + 9 Months to WG Document<= /div>
  -= Applicability Statements: 10 months to WG Document
  -= Data Models and Applicability Statements to IESG  - 16 months
 
The WG w= ill work closely with I2RS, Netconf and Netmod WGs. The WG will communicate= with external SDOs like ETSI NFV and will encourage open source code devel= opment related to the WG scope in organizations like ONF, OpenStack, ODL, and OpenNFV.
 
 
Cheers,<= o:p>
Linda Du= nbar
<i2nsf char= ter-jcs-20150512.docx>_______________________________________________ I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf
 
 
 

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o copia sin autorizaci=F3n puede e= star prohibida en virtud de la legislaci=F3n vigente. Si ha recibido este m= ensaje por error, le rogamos que nos lo comunique inmediatamente por esta m= isma v=EDa y proceda a su destrucci=F3n.

The information contained in this transmission is privileged and confidenti= al 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 y= ou have received this transmission in error, do not read it. Please immedia= tely 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=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, divulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o p= ode estar proibida em virtude da legisla=E7=E3o vigente. Se recebeu esta me= nsagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mes= ma via e proceda a sua destrui=E7=E3o

--
"Esta vez no fallaremos, Doctor Infierno"

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

e-mail: diego.r.lopez@telefonica.com
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------



Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o copia sin autorizaci=F3n puede e= star prohibida en virtud de la legislaci=F3n vigente. Si ha recibido este m= ensaje por error, le rogamos que nos lo comunique inmediatamente por esta m= isma v=EDa y proceda a su destrucci=F3n.

The information contained in this transmission is privileged and confidenti= al 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 y= ou have received this transmission in error, do not read it. Please immedia= tely 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=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, divulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o p= ode estar proibida em virtude da legisla=E7=E3o vigente. Se recebeu esta me= nsagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mes= ma via e proceda a sua destrui=E7=E3o
 --_000_290EEBA808F44D998FA08C2C0A8C55E6telefonicacom_-- From nobody Mon May 18 11:48:25 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51C321B2A0D for ; Mon, 18 May 2015 11:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ClDhWJKd6Yn for ; Mon, 18 May 2015 11:48:19 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48A6F1B29D3 for ; Mon, 18 May 2015 11:48:16 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BSR59683; Mon, 18 May 2015 18:48:13 +0000 (GMT) Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 18 May 2015 19:48:12 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml702-chm ([10.193.5.72]) with mapi id 14.03.0158.001; Mon, 18 May 2015 11:47:58 -0700 From: Linda Dunbar To: "i2nsf@ietf.org" Thread-Topic: Revised Narrower scoped I2NSF charter Thread-Index: AdCRmyiKiZeg0kFYSvW3DBEM9L/fbw== Date: Mon, 18 May 2015 18:47:58 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657C2DC55@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.233] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657C2DC55dfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "Romascanu, Dan \(Dan\)" , Joseph Salowey , Kathleen Moriarty Subject: [I2nsf] Revised Narrower scoped I2NSF charter X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2015 18:48:24 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F657C2DC55dfweml701chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks to many people contributions to I2NSF charter. Here is the revised o= ne. Please provide comments and suggestions if your suggested changes haven= 't been properly addressed. Network security functions (NSFs) are provided and consumed in increasingly= diverse environments. Users of NSFs could consume network security service= s hosted by one or more providers, which may be their own enterprise, servi= ce providers, or a combination of both. Likewise, service providers of NSFs= may offer their customers network security services that consist of multip= le security products and/or functions from different vendors. NSFs may be p= rovided by physical and/or virtualized infrastructure. Without standard int= erfaces to express, monitor, and control security policies that govern the = behavior of NSFs, it becomes virtually impossible for security service prov= iders to automate their service offerings that utilize different security f= unctions from multiple vendors. The primary goal of I2NSF is to define an information model, a set of soft= ware interfaces and data models for controlling and monitoring aspects of N= SFs (both physical and virtual). Other aspects of NSFs such as device or ne= twork provisioning and configuration are out of scope. Controlling and moni= toring of NSFs should include the use of policies to specify, query, monito= r, and control the NSFs by one or more management entities. Since different= security vendors support different features and functions on their devices= , I2NSF will focus on flow based NSFs that provide treatment to packets/flo= ws, such as IPS/IDS, Web filtering, flow filtering, deep packet inspection,= or pattern matching and remediation. There are two layers of interfaces envisioned in the I2NSF approach: * I2NSF Capabilities Layer * I2NSF Services Layer The I2NSF Capability Layer specifies the functional security policies, whic= h are translated from the entity defining the goal of the security policy i= nto a form that can be implemented, and are used to monitor and control the= behavior of NSFs. I2NSF will NOT standardize NSFs or devices. Instead, I2N= SF will only standardize the controlling and monitoring aspects of the NSFs= (not devices). An exemplar controlling of flow-based NSFs is "Subject - Ob= ject - Function - Action". The I2NSF Service Layer is for clients to express and monitor security poli= cies for their specific flows, which is usually based on application and cl= ient specific logical networks requirements and context. The concrete work at the I2NSF Capability Layer includes - An information model that defines concepts required for standard= izing the controlling and monitoring of NSFs, - A set of YANG data models, derived from the above information mo= del, which enables the controlling and monitoring of virtual and/or physica= l NSFs, - The capability registry (IANA) that enables the characteristics = and behavior of NSFs to be specified using a vendor-neutral vocabulary with= out requiring the NSFs themselves to be standardized; the registry enables = various mechanisms, including policy rules, to be used to match monitor and= control functions to the needs of an application and/or environment, and - The proper secure communication channels to carry the controllin= g and monitoring information between the management entity (or entities) an= d the NSFs being controlled. Standard interfaces for monitoring and controlling the behavior of NSFs ar= e essential building blocks for Security Service Providers to automate the = use of different NSFs from multiple vendors by their Security management en= tities. This layer will leverage the existing protocols and data models def= ined 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 data models, APIs, and/or RESTful inter= faces to clients and demonstrating the feasibility of them being translated= to the Capability Layer policies. It is a non-goal to create new protocols or data modeling languages for I2N= SF interfaces. I2NSF WG Deliverables include: - Use Case document. - Framework Document. - Requirement for extensions (if there are any) to existing protoc= ols used by the WG. - Gap analysis of existing protocols and modeling languages for s= pecifying, querying, monitoring, and controlling NSFs. - A single, unified, Information Model for controlling and monitor= ing flow-based NSFs. - Corresponding YANG Data Models derived from the above Informatio= n Model. - IANA registry consideration for flow based NSFs controlling and = monitoring capability. - (Optionally) Document describing how capabilities are used to mo= nitor and control flow-based NSFs. - (Optionally) Applicability Statements on how to use I2RS, Netcon= f, and NETMOD to carry the content of the specified information/data models= . [The WG may decide that the Use cases, Framework, and Requirement are Infor= mational documents or simply reference documents during the lifetime of the= WG.] 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 + 8 months to W= G document - Info model: Charter time + 8 months to WG Document - IANA registry consideration + 12 months to WG Document - All Early Drafts to IESG: 18 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 - 18 months The WG will work closely with I2RS, Netconf and Netmod WGs. The WG will com= municate with external SDOs like ETSI NFV and will encourage open source co= de development related to the WG scope in organizations like ONF, OpenStack= , ODL, and OpenNFV. Cheers, Linda --_000_4A95BA014132FF49AE685FAB4B9F17F657C2DC55dfweml701chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks to many people contributions to I2NSF charter= . Here is the revised one. Please provide comments and suggestions if your = suggested changes haven’t been properly addressed.

 

 <= /p>

 =

Network security functio= ns (NSFs) are provided and consumed in increasingly diverse environments. U= sers 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 o= f NSFs may offer their customers network security services that consist of = multiple security products and/or functions from different vendors. NSFs ma= y be provided by physical and/or virtualized infrastructure. Without standard interfaces to express, monito= r, and control security policies that govern the behavior of NSFs, it becom= es virtually impossible for security service providers to automate their se= rvice offerings that utilize different security functions from multiple vendors.

 =

The primary goal of I2NS= F is to define an information model,  a set of software interfaces and= data models for controlling and monitoring aspects of NSFs (both physical = and virtual). Other aspects of NSFs such as device or network provisioning and configuration are out of scope. Cont= rolling and monitoring of NSFs should include the use of policies to specif= y, query, monitor, and control the NSFs by one or more management entities. Since different security vendors support different features and func= tions on their devices, I2NSF will focus on flow based NSFs that provide tr= eatment to packets/flows, such as IPS/IDS, Web filtering, flow filtering, d= eep packet inspection, or pattern matching and remediation.

 =

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

·       I2NSF Capabiliti= es Layer

·       I2NSF Services L= ayer

 =

The I2NSF Capability Lay= er specifies the functional security policies, which are translated from th= e entity defining the goal of the security policy into a form that can be i= mplemented, and are used to monitor and control the behavior of NSFs. I2NSF will NOT standardize NSFs or devic= es. Instead, I2NSF will only standardize the controlling and monitoring asp= ects of the NSFs (not devices). An exemplar controlling of flow-based NSFs = is “Subject – Object – Function – Action”. 

 =

The I2NSF Service Layer is for clients to express an= d monitor security policies for their specific flows, which is usually base= d on application and client specific logical networks requirements and cont= ext.

 

The concrete work at the I2NSF Capability Layer incl= udes

-  &= nbsp;       An information model that defines concepts r= equired for standardizing the controlling and monitoring of NSFs,

-  &= nbsp;       A set of YANG data models, derived from the = above information model, which enables the controlling and monitoring of vi= rtual and/or physical NSFs,

-  &= nbsp;       The capability registry (IANA) that enables = the characteristics and behavior of NSFs to be specified using a vendor-neu= tral vocabulary without requiring the NSFs themselves to be standardized; t= he registry enables various mechanisms, including policy rules, to be used to match monitor and control functions = to the needs of an application and/or environment, and

-  &= nbsp;       The proper secure communication channels to = carry the controlling and monitoring information between the management ent= ity (or entities) and the NSFs being controlled.

 

 Standard interfaces for monitoring and control= ling the behavior of NSFs are essential building blocks for Security Servic= e Providers to automate the use of different NSFs from multiple vendors by = their Security management entities. 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. H= owever, I2NSF can have informational drafts showing sample data models, API= s, and/or RESTful interfaces to clients and demonstrating the feasibility of them being translated to the Capabili= ty Layer policies.

 =

It is a non-goal to create new protocols or data mod= eling languages for I2NSF interfaces.

I2NSF WG Deliverables include:

 

-       = ;   Use Case document.

-       = ;   Framework Document.

-       = ;   Requirement for extensions (if there are any) to ex= isting protocols used by the WG.

-       = ;    Gap analysis of existing protocols and modeli= ng languages for specifying, querying, monitoring, and controlling NSFs.

-       = ;   A single, unified, Information Model for controllin= g and monitoring flow-based NSFs.

-       = ;   Corresponding YANG Data Models derived from the abo= ve Information Model.

-       = ;   IANA registry consideration for flow based NSFs con= trolling and monitoring capability.

-       = ;   (Optionally) Document describing how capabilities a= re used to monitor and control flow-based NSFs.

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

 

[The W= G may decide that the Use cases, Framework, and Requirement are Information= al documents or simply reference documents during the lifetime of the WG.]

 

Suggested Milestones

  - Use Case Document:  Charter time += 1 month to WG Document

  - Framework: Charter time + 4 months to W= G Document

  - Requirements for extensions to protocols:&n= bsp; Charter time + 8 months to WG document

  - Info model: Charter time + 8 months to = WG Document

  - IANA registry consideration + 12 months= to WG Document

  - All Early Drafts to IESG: 18 months

 

[decision point – +10 months]  <= /o:p>

  - Data Models: Charter + 9 Months to= WG Document

  - Applicability Statements: 10 months to WG D= ocument

  - Data Models and Applicability Statements to= IESG  - 18 months

 

The WG will work closely with I2RS, Netconf and Netm= od WGs. The WG will communicate with external SDOs like ETSI NFV and will e= ncourage open source code development related to the WG scope in organizati= ons like ONF, OpenStack, ODL, and OpenNFV.

 <= /p>

 

Cheers,

 

Linda

--_000_4A95BA014132FF49AE685FAB4B9F17F657C2DC55dfweml701chm_-- From nobody Mon May 18 12:03:47 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5E5C1B2A46 for ; Mon, 18 May 2015 12:03:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1yjOH4s5AMtD for ; Mon, 18 May 2015 12:03:44 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 134971B2A6C for ; Mon, 18 May 2015 12:02:56 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BWF65329; Mon, 18 May 2015 19:02:54 +0000 (GMT) Received: from DFWEML704-CHM.china.huawei.com (10.193.5.141) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 18 May 2015 20:02:53 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml704-chm ([10.193.5.141]) with mapi id 14.03.0158.001; Mon, 18 May 2015 12:02:45 -0700 From: Linda Dunbar To: "i2nsf@ietf.org" Thread-Topic: Please provide the list of CONFLICTS you wish to avoid for our I2NSF IETF93 BOF session request? Thread-Index: AdCRnTjRCqZ/Ok6ITjiXUys4+3smrw== Date: Mon, 18 May 2015 19:02:44 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657C2DC77@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.233] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657C2DC77dfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [I2nsf] Please provide the list of CONFLICTS you wish to avoid for our I2NSF IETF93 BOF session request? X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2015 19:03:47 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F657C2DC77dfweml701chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear I2NSF Contributors: We plan to make a request for WG Forming BOF at IETF93. Could you please pr= ovide the list conflicts that you wish to avoid for our I2NSF BOF at IETF93= ? Thanks, Linda --_000_4A95BA014132FF49AE685FAB4B9F17F657C2DC77dfweml701chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear I2NSF Contributors:

 

We plan to make a request for WG Forming BOF at IETF= 93. Could you please provide the list conflicts that you wish to avoid for = our I2NSF BOF at IETF93?

 

Thanks, Linda

 

--_000_4A95BA014132FF49AE685FAB4B9F17F657C2DC77dfweml701chm_-- From nobody Mon May 18 13:41:39 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F42A1A90C4; Mon, 18 May 2015 13:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rbr0nKVn29tm; Mon, 18 May 2015 13:41:34 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C67C1A00B0; Mon, 18 May 2015 13:41:31 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BWF70470; Mon, 18 May 2015 20:41:29 +0000 (GMT) Received: from DFWEML706-CHM.china.huawei.com (10.193.5.225) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 18 May 2015 21:41:27 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml706-chm ([10.193.5.225]) with mapi id 14.03.0158.001; Mon, 18 May 2015 13:41:25 -0700 From: Linda Dunbar To: Kathleen Moriarty , "agenda@ietf.org Agenda" Thread-Topic: I2NSF BOF Session request for IETF 93 Thread-Index: AdCRqwEuoOogAn2PRUW8xnLuMfAqVg== Date: Mon, 18 May 2015 20:41:24 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657C2DD1E@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.233] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657C2DD1Edfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "i2nsf@ietf.org" , Stephen Farrell Subject: [I2nsf] I2NSF BOF Session request for IETF 93 X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2015 20:41:37 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F657C2DD1Edfweml701chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Kathleen, We would like to request a WG forming BOF for I2NSF at IETF93. Here are the= details of the request: * BOF's full name and acronym in brackets: Interface to Network Securi= ty Functions (I2NSF) * AREA under which Working Group or BOF appears: Security * Chair(s) Name(s) and e-mail address(es): TBD * Agenda (to be adjusted) o Use cases & Problem space o Packet-Based Paradigm For Interfaces To NSFs o Capability interface Information model o Gap Analysis o Framework o Charter discussion: http://www.ietf.org/mail-archive/web/i2nsf/current/= msg00391.html * Full Description of BOF In a nutshell, I2NSF wants to define interfaces to the flow based network s= ecurity functions hosted by service providers at different premises. Network security functions (NSFs) are provided and consumed in increasingly= diverse environments. Users of NSFs could consume network security service= s hosted by one or more providers, which may be their own enterprise, servi= ce providers, or a combination of both. Likewise, service providers of NSFs= may offer their customers network security services that consist of multip= le security products and/or functions from different vendors. NSFs may be p= rovided by physical and/or virtualized infrastructure. Without standard int= erfaces to express, monitor, and control security policies that govern the = behavior of NSFs, it becomes virtually impossible for security service prov= iders to automate their service offerings that utilize different security f= unctions from multiple vendors. The primary goal of I2NSF is to define an information model, a set of soft= ware interfaces and data models for controlling and monitoring aspects of N= SFs (both physical and virtual). Other aspects of NSFs such as device or ne= twork provisioning and configuration are out of scope. Controlling and moni= toring of NSFs should include the use of policies to specify, query, monito= r, and control the NSFs by one or more management entities. Since different= security vendors support different features and functions on their devices= , I2NSF will focus on flow based NSFs that provide treatment to packets/flo= ws, such as IPS/IDS, Web filtering, flow filtering, deep packet inspection,= or pattern matching and remediation. * CONFLICTS you wish to avoid, please be as specific as possible: SACM, SAAS, nfvrg, SFC, NVO3, TRILL, ... * Expected Attendance (figures from the previous IETF meeting are inclu= ded in the message that is sent when scheduling opens): 60 * Special requests: * Number of sessions: 1 * Length of sessions: * 2 hours Hope you can guide us through the process. Thank you very much. Linda Dunbar --_000_4A95BA014132FF49AE685FAB4B9F17F657C2DD1Edfweml701chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Kathleen,

 

We would like to request a WG forming BOF for I2NSF = at IETF93. Here are the details of the request:

 

  • BOF's full name and acronym in brackets:  Interface to Net= work Security Functions (I2NSF)
  • AREA under which Working Group or BOF appears: Security
  • Chair(s) Name(s) and e-mail address(es): TBD<= /li>
  • Agenda (to be adjusted)

o   Use cases & Prob= lem space

o   Packet-Based Paradig= m For Interfaces To NSFs

o   Capability interface= Information model

o   Gap Analysis

o   Framework=

o   Charter discussion: http://www.ietf.org/mail-archive/web/i2nsf/current/msg00391.html

 =

  • Full Description of BOF

In a nutshell, I2NSF want= s to define interfaces to the flow based network security functions hosted by se= rvice providers at different premises.

<= o:p> 

Network security functions (NSFs) are provided and consumed in increasin= gly diverse environments. Users of NSFs could consume network security serv= ices hosted by one or more providers, which may be their own enterprise, service providers, or a combination of = both. Likewise, service providers of NSFs may offer their customers network= security services that consist of multiple security products and/or functi= ons from different vendors. NSFs may be provided by physical and/or virtualized infrastructure. Without sta= ndard interfaces to express, monitor, and control security policies that go= vern the behavior of NSFs, it becomes virtually impossible for security ser= vice providers to automate their service offerings that utilize different security functions from multiple = vendors.

 

The primary goal of I2NSF is to define an information model,  a set= of software interfaces and data models for controlling and monitoring aspe= cts of NSFs (both physical and virtual). Other aspects of NSFs such as device or network provisioning and configuration a= re out of scope. Controlling and monitoring of NSFs should include the use = of policies to specify, query, monitor, and control the NSFs by one or more= management entities. Since different security vendors support different features and func= tions on their devices, I2NSF will focus on flow based NSFs that provide tr= eatment to packets/flows, such as IPS/IDS, Web filtering, flow filtering, d= eep packet inspection, or pattern matching and remediation.

 

  • CONFLICTS you wish to avoid, please be as specific as possible:=

SACM, SAAS, nfvrg, SFC, NVO3, TRILL, …

  • Expected Attendance (figures from the previous IETF meeting are= included in the message that is sent when scheduling opens): 60=
  • Special requests:
  • Number of sessions: 1
  • Length of sessions:
    • 2 hours

 

Hope you can guide us through the process.

 

Thank you very much.

 

Linda Dunbar

--_000_4A95BA014132FF49AE685FAB4B9F17F657C2DD1Edfweml701chm_-- From nobody Mon May 18 13:44:54 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A465C1B29C7; Mon, 18 May 2015 13:44:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lcrrsxk9bcdN; Mon, 18 May 2015 13:44:51 -0700 (PDT) Received: from mail-qc0-x22d.google.com (mail-qc0-x22d.google.com [IPv6:2607:f8b0:400d:c01::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27F591B29C2; Mon, 18 May 2015 13:44:51 -0700 (PDT) Received: by qcir1 with SMTP id r1so29078524qci.3; Mon, 18 May 2015 13:44:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=JTE8WUlfS1OZQM/OpiAHC7KEXqdXmyMR2ZDRc2Sf7QQ=; b=YAyDNqb07ZWZjUg4Ir3qTCiD75oR4H9NoIwzXGBnuR1AtexzNqUthZpjnNT3mUkRkq Sj1aPrK3VeFh6Vjq1fLfxOQ2cUsnWRJVEwQMHuoiehrR4naL7TRkkdrELDoyX/GP5iP5 cjryGr22LHLnR1rEAttvCwqOnRmWVSHqZvQOU3EX/UgICHVuBLJNknGwRwzMUdGvFtWd Vsyfb2ZiZKPn7Heb8iC1Ku5YqN4LASOkay/q2NQuU1KMi5bYU5x9OYGRmwNZMjFOc6ec 2aqzk3krGftdT+AlumNBD+/xHNAC7PnBzyL2vBS8KB9xSpIq44AIAGrWLnPjlODDiprW ARuA== X-Received: by 10.55.55.74 with SMTP id e71mr28393233qka.65.1431981890310; Mon, 18 May 2015 13:44:50 -0700 (PDT) Received: from [10.159.140.205] (mobile-166-172-186-119.mycingular.net. [166.172.186.119]) by mx.google.com with ESMTPSA id 93sm7772287qkx.38.2015.05.18.13.44.48 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 18 May 2015 13:44:49 -0700 (PDT) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: multipart/alternative; boundary=Apple-Mail-0DD16893-7C67-496D-9B9B-F9361BF9969C Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (11D257) In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657C2DD1E@dfweml701-chm> Date: Mon, 18 May 2015 16:44:49 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <4A95BA014132FF49AE685FAB4B9F17F657C2DD1E@dfweml701-chm> To: Linda Dunbar Archived-At: Cc: "i2nsf@ietf.org" , "agenda@ietf.org Agenda" , Stephen Farrell Subject: Re: [I2nsf] I2NSF BOF Session request for IETF 93 X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2015 20:44:53 -0000 --Apple-Mail-0DD16893-7C67-496D-9B9B-F9361BF9969C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Linda, Could you please add this to the wiki? I'm about to fly to Lima, so I would= n't be able to get to it for a bit. Thank you, Kathleen Sent from my iPhone > On May 18, 2015, at 4:41 PM, Linda Dunbar wrote:= >=20 > Kathleen, > =20 > We would like to request a WG forming BOF for I2NSF at IETF93. Here are th= e details of the request: > =20 > BOF's full name and acronym in brackets: Interface to Network Security Fu= nctions (I2NSF) > AREA under which Working Group or BOF appears: Security > Chair(s) Name(s) and e-mail address(es): TBD > Agenda (to be adjusted) > o Use cases & Problem space > o Packet-Based Paradigm For Interfaces To NSFs > o Capability interface Information model > o Gap Analysis > o Framework > o Charter discussion: http://www.ietf.org/mail-archive/web/i2nsf/current= /msg00391.html > =20 > Full Description of BOF > In a nutshell, I2NSF wants to define interfaces to the flow based network s= ecurity functions hosted by service providers at different premises. > =20 > Network security functions (NSFs) are provided and consumed in increasingl= y diverse environments. Users of NSFs could consume network security service= s hosted by one or more providers, which may be their own enterprise, servic= e providers, or a combination of both. Likewise, service providers of NSFs m= ay offer their customers network security services that consist of multiple s= ecurity products and/or functions from different vendors. NSFs may be provid= ed by physical and/or virtualized infrastructure. Without standard interface= s to express, monitor, and control security policies that govern the behavio= r of NSFs, it becomes virtually impossible for security service providers to= automate their service offerings that utilize different security functions f= rom multiple vendors. > =20 > The primary goal of I2NSF is to define an information model, a set of sof= tware interfaces and data models for controlling and monitoring aspects of N= SFs (both physical and virtual). Other aspects of NSFs such as device or net= work provisioning and configuration are out of scope. Controlling and monito= ring of NSFs should include the use of policies to specify, query, monitor, a= nd control the NSFs by one or more management entities. Since different secu= rity vendors support different features and functions on their devices, I2NS= F will focus on flow based NSFs that provide treatment to packets/flows, suc= h as IPS/IDS, Web filtering, flow filtering, deep packet inspection, or patt= ern matching and remediation. > =20 > CONFLICTS you wish to avoid, please be as specific as possible: > SACM, SAAS, nfvrg, SFC, NVO3, TRILL, =E2=80=A6 > Expected Attendance (figures from the previous IETF meeting are included i= n the message that is sent when scheduling opens): 60 > Special requests: > Number of sessions: 1 > Length of sessions: > 2 hours > =20 > Hope you can guide us through the process. > =20 > Thank you very much. > =20 > Linda Dunbar --Apple-Mail-0DD16893-7C67-496D-9B9B-F9361BF9969C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Linda,

Could y= ou please add this to the wiki?  I'm about to fly to Lima, so I wouldn'= t be able to get to it for a bit.

Thank you,
<= div>Kathleen

Sent from my iPhone
=

Kathleen,

 

We would like to request a WG forming BOF for I2NSF a= t IETF93. Here are the details of the request:

 

  • BOF's full name and acronym in brackets:  Interface to Netwo= rk Security Functions (I2NSF)
  • AREA under which Working Group or BOF appears: Security
  • Chair(s) Name(s) and e-mail address(es): TBD
  • Agenda (to be adjusted)

= o   Use cases & Pr= oblem space

= o   Packet-Based Parad= igm For Interfaces To NSFs

= o   Capability interfa= ce Information model

= o   Gap Analysis<= /o:p>

= o   Framework

o   Charter discussion= : http://www.ietf.org/mail-archive/web/i2nsf/current/msg00391.html=

 <= /p>

  • Full Description of BOF

In a nutshell, I2NSF wants= to define interfaces to the flow based network security functions hosted by ser= vice providers at different premises.

 

Network security functions (NSFs) are provided and consumed in increasingl= y diverse environments. Users of NSFs could consume network security service= s hosted by one or more providers, which may be their own enterprise, service providers, or a combination of b= oth. Likewise, service providers of NSFs may offer their customers network s= ecurity services that consist of multiple security products and/or functions= from different vendors. NSFs may be provided by physical and/or virtualized infrastructure. Without stan= dard interfaces to express, monitor, and control security policies that gove= rn the behavior of NSFs, it becomes virtually impossible for security servic= e providers to automate their service offerings that utilize different security functions from multiple v= endors.

 

The primary goal of I2NSF is to define an information model,  a set o= f software interfaces and data models for controlling and monitoring aspects= of NSFs (both physical and virtual). Other aspects of NSFs such as device or network provisioning and configuration ar= e out of scope. Controlling and monitoring of NSFs should include the use of= policies to specify, query, monitor, and control the NSFs by one or more ma= nagement entities. Since different security vendors support different features and funct= ions on their devices, I2NSF will focus on flow based NSFs that provide trea= tment to packets/flows, such as IPS/IDS, Web filtering, flow filtering, deep= packet inspection, or pattern matching and remediation.

 

  • CONFLICTS you wish to avoid, please be as specific as possible:

SACM, SAAS, nfvrg, SFC, NVO3, TRILL, =E2=80=A6

  • Expected Attendance (figures from the previous IETF meeting are i= ncluded in the message that is sent when scheduling opens): 60
  • Special requests:
  • Number of sessions: 1
  • Length of sessions:
    • 2 hours

 

Hope you can guide us through the process.

 

Thank you very much.

 

Linda Dunbar

= --Apple-Mail-0DD16893-7C67-496D-9B9B-F9361BF9969C-- From nobody Mon May 18 14:27:18 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF6811A9177; Mon, 18 May 2015 14:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ulY0txDdtAuZ; Mon, 18 May 2015 14:27:14 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1E241A6F27; Mon, 18 May 2015 14:27:13 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BWF72707; Mon, 18 May 2015 21:27:12 +0000 (GMT) Received: from DFWEML706-CHM.china.huawei.com (10.193.5.225) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 18 May 2015 22:27:11 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml706-chm ([10.193.5.225]) with mapi id 14.03.0158.001; Mon, 18 May 2015 14:27:01 -0700 From: Linda Dunbar To: Kathleen Moriarty Thread-Topic: [I2nsf] I2NSF BOF Session request for IETF 93 Thread-Index: AdCRqwEuoOogAn2PRUW8xnLuMfAqVgAOyaeAAA6PaRA= Date: Mon, 18 May 2015 21:27:00 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657C2DD55@dfweml701-chm> References: <4A95BA014132FF49AE685FAB4B9F17F657C2DD1E@dfweml701-chm> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.233] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657C2DD55dfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "i2nsf@ietf.org" , "agenda@ietf.org Agenda" , Stephen Farrell Subject: Re: [I2nsf] I2NSF BOF Session request for IETF 93 X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2015 21:27:17 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F657C2DD55dfweml701chm_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 S2F0aGxlZW4sDQoNClRoYW5rcy4NCkkgaGF2ZSBhZGRlZCB3aGF0IHdlIGhhdmUgdG8gdGhlIElF VEY5MyBCT0Ygd2lraS4gTGV0IG1lIGtub3cgaWYgYW55IGNoYW5nZXMgYXJlIG5lZWRlZDogaHR0 cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvYm9mL3RyYWMvd2lraS9XaWtpU3RhcnQNCg0KDQpIYXZl IGEgZ29vZCB0cmlwIHRvIExpbWEuIExvb2tpbmcgZm9yd2FyZCB0byB0YWxraW5nIHRvIHlvdSBt b3JlIG9uIHRoZSBJMk5TRiBCT0YgcHJlcGFyYXRpb24gd2hlbiB5b3UgY29tZSBiYWNrLg0KDQoN CkxpbmRhDQoNCkZyb206IEkybnNmIFttYWlsdG86aTJuc2YtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIEthdGhsZWVuIE1vcmlhcnR5DQpTZW50OiBNb25kYXksIE1heSAxOCwgMjAxNSAz OjQ1IFBNDQpUbzogTGluZGEgRHVuYmFyDQpDYzogaTJuc2ZAaWV0Zi5vcmc7IGFnZW5kYUBpZXRm Lm9yZyBBZ2VuZGE7IFN0ZXBoZW4gRmFycmVsbA0KU3ViamVjdDogUmU6IFtJMm5zZl0gSTJOU0Yg Qk9GIFNlc3Npb24gcmVxdWVzdCBmb3IgSUVURiA5Mw0KDQpMaW5kYSwNCg0KQ291bGQgeW91IHBs ZWFzZSBhZGQgdGhpcyB0byB0aGUgd2lraT8gIEknbSBhYm91dCB0byBmbHkgdG8gTGltYSwgc28g SSB3b3VsZG4ndCBiZSBhYmxlIHRvIGdldCB0byBpdCBmb3IgYSBiaXQuDQoNClRoYW5rIHlvdSwN CkthdGhsZWVuDQoNClNlbnQgZnJvbSBteSBpUGhvbmUNCg0KT24gTWF5IDE4LCAyMDE1LCBhdCA0 OjQxIFBNLCBMaW5kYSBEdW5iYXIgPGxpbmRhLmR1bmJhckBodWF3ZWkuY29tPG1haWx0bzpsaW5k YS5kdW5iYXJAaHVhd2VpLmNvbT4+IHdyb3RlOg0KS2F0aGxlZW4sDQoNCldlIHdvdWxkIGxpa2Ug dG8gcmVxdWVzdCBhIFdHIGZvcm1pbmcgQk9GIGZvciBJMk5TRiBhdCBJRVRGOTMuIEhlcmUgYXJl IHRoZSBkZXRhaWxzIG9mIHRoZSByZXF1ZXN0Og0KDQoNCiAgKiAgIEJPRidzIGZ1bGwgbmFtZSBh bmQgYWNyb255bSBpbiBicmFja2V0czogIEludGVyZmFjZSB0byBOZXR3b3JrIFNlY3VyaXR5IEZ1 bmN0aW9ucyAoSTJOU0YpDQogICogICBBUkVBIHVuZGVyIHdoaWNoIFdvcmtpbmcgR3JvdXAgb3Ig Qk9GIGFwcGVhcnM6IFNlY3VyaXR5DQogICogICBDaGFpcihzKSBOYW1lKHMpIGFuZCBlLW1haWwg YWRkcmVzcyhlcyk6IFRCRA0KICAqICAgQWdlbmRhICh0byBiZSBhZGp1c3RlZCkNCg0KbyAgIFVz ZSBjYXNlcyAmIFByb2JsZW0gc3BhY2UNCg0KbyAgIFBhY2tldC1CYXNlZCBQYXJhZGlnbSBGb3Ig SW50ZXJmYWNlcyBUbyBOU0ZzDQoNCm8gICBDYXBhYmlsaXR5IGludGVyZmFjZSBJbmZvcm1hdGlv biBtb2RlbA0KDQpvICAgR2FwIEFuYWx5c2lzDQoNCm8gICBGcmFtZXdvcmsNCg0KbyAgIENoYXJ0 ZXIgZGlzY3Vzc2lvbjogaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2kybnNm L2N1cnJlbnQvbXNnMDAzOTEuaHRtbA0KDQoNCg0KICAqICAgRnVsbCBEZXNjcmlwdGlvbiBvZiBC T0YNCkluIGEgbnV0c2hlbGwsIEkyTlNGIHdhbnRzIHRvIGRlZmluZSBpbnRlcmZhY2VzIHRvIHRo ZSBmbG93IGJhc2VkIG5ldHdvcmsgc2VjdXJpdHkgZnVuY3Rpb25zIGhvc3RlZCBieSBzZXJ2aWNl IHByb3ZpZGVycyBhdCBkaWZmZXJlbnQgcHJlbWlzZXMuDQoNCk5ldHdvcmsgc2VjdXJpdHkgZnVu Y3Rpb25zIChOU0ZzKSBhcmUgcHJvdmlkZWQgYW5kIGNvbnN1bWVkIGluIGluY3JlYXNpbmdseSBk aXZlcnNlIGVudmlyb25tZW50cy4gVXNlcnMgb2YgTlNGcyBjb3VsZCBjb25zdW1lIG5ldHdvcmsg c2VjdXJpdHkgc2VydmljZXMgaG9zdGVkIGJ5IG9uZSBvciBtb3JlIHByb3ZpZGVycywgd2hpY2gg bWF5IGJlIHRoZWlyIG93biBlbnRlcnByaXNlLCBzZXJ2aWNlIHByb3ZpZGVycywgb3IgYSBjb21i aW5hdGlvbiBvZiBib3RoLiBMaWtld2lzZSwgc2VydmljZSBwcm92aWRlcnMgb2YgTlNGcyBtYXkg b2ZmZXIgdGhlaXIgY3VzdG9tZXJzIG5ldHdvcmsgc2VjdXJpdHkgc2VydmljZXMgdGhhdCBjb25z aXN0IG9mIG11bHRpcGxlIHNlY3VyaXR5IHByb2R1Y3RzIGFuZC9vciBmdW5jdGlvbnMgZnJvbSBk aWZmZXJlbnQgdmVuZG9ycy4gTlNGcyBtYXkgYmUgcHJvdmlkZWQgYnkgcGh5c2ljYWwgYW5kL29y IHZpcnR1YWxpemVkIGluZnJhc3RydWN0dXJlLiBXaXRob3V0IHN0YW5kYXJkIGludGVyZmFjZXMg dG8gZXhwcmVzcywgbW9uaXRvciwgYW5kIGNvbnRyb2wgc2VjdXJpdHkgcG9saWNpZXMgdGhhdCBn b3Zlcm4gdGhlIGJlaGF2aW9yIG9mIE5TRnMsIGl0IGJlY29tZXMgdmlydHVhbGx5IGltcG9zc2li bGUgZm9yIHNlY3VyaXR5IHNlcnZpY2UgcHJvdmlkZXJzIHRvIGF1dG9tYXRlIHRoZWlyIHNlcnZp Y2Ugb2ZmZXJpbmdzIHRoYXQgdXRpbGl6ZSBkaWZmZXJlbnQgc2VjdXJpdHkgZnVuY3Rpb25zIGZy b20gbXVsdGlwbGUgdmVuZG9ycy4NCg0KDQpUaGUgcHJpbWFyeSBnb2FsIG9mIEkyTlNGIGlzIHRv IGRlZmluZSBhbiBpbmZvcm1hdGlvbiBtb2RlbCwgIGEgc2V0IG9mIHNvZnR3YXJlIGludGVyZmFj ZXMgYW5kIGRhdGEgbW9kZWxzIGZvciBjb250cm9sbGluZyBhbmQgbW9uaXRvcmluZyBhc3BlY3Rz IG9mIE5TRnMgKGJvdGggcGh5c2ljYWwgYW5kIHZpcnR1YWwpLiBPdGhlciBhc3BlY3RzIG9mIE5T RnMgc3VjaCBhcyBkZXZpY2Ugb3IgbmV0d29yayBwcm92aXNpb25pbmcgYW5kIGNvbmZpZ3VyYXRp b24gYXJlIG91dCBvZiBzY29wZS4gQ29udHJvbGxpbmcgYW5kIG1vbml0b3Jpbmcgb2YgTlNGcyBz aG91bGQgaW5jbHVkZSB0aGUgdXNlIG9mIHBvbGljaWVzIHRvIHNwZWNpZnksIHF1ZXJ5LCBtb25p dG9yLCBhbmQgY29udHJvbCB0aGUgTlNGcyBieSBvbmUgb3IgbW9yZSBtYW5hZ2VtZW50IGVudGl0 aWVzLiBTaW5jZSBkaWZmZXJlbnQgc2VjdXJpdHkgdmVuZG9ycyBzdXBwb3J0IGRpZmZlcmVudCBm ZWF0dXJlcyBhbmQgZnVuY3Rpb25zIG9uIHRoZWlyIGRldmljZXMsIEkyTlNGIHdpbGwgZm9jdXMg b24gZmxvdyBiYXNlZCBOU0ZzIHRoYXQgcHJvdmlkZSB0cmVhdG1lbnQgdG8gcGFja2V0cy9mbG93 cywgc3VjaCBhcyBJUFMvSURTLCBXZWIgZmlsdGVyaW5nLCBmbG93IGZpbHRlcmluZywgZGVlcCBw YWNrZXQgaW5zcGVjdGlvbiwgb3IgcGF0dGVybiBtYXRjaGluZyBhbmQgcmVtZWRpYXRpb24uDQoN Cg0KICAqICAgQ09ORkxJQ1RTIHlvdSB3aXNoIHRvIGF2b2lkLCBwbGVhc2UgYmUgYXMgc3BlY2lm aWMgYXMgcG9zc2libGU6DQpTQUNNLCBTQUFTLCBuZnZyZywgU0ZDLCBOVk8zLCBUUklMTCwg4oCm DQoNCiAgKiAgIEV4cGVjdGVkIEF0dGVuZGFuY2UgKGZpZ3VyZXMgZnJvbSB0aGUgcHJldmlvdXMg SUVURiBtZWV0aW5nIGFyZSBpbmNsdWRlZCBpbiB0aGUgbWVzc2FnZSB0aGF0IGlzIHNlbnQgd2hl biBzY2hlZHVsaW5nIG9wZW5zKTogNjANCiAgKiAgIFNwZWNpYWwgcmVxdWVzdHM6DQogICogICBO dW1iZXIgb2Ygc2Vzc2lvbnM6IDENCiAgKiAgIExlbmd0aCBvZiBzZXNzaW9uczoNCg0KICAgICAq ICAgMiBob3Vycw0KDQpIb3BlIHlvdSBjYW4gZ3VpZGUgdXMgdGhyb3VnaCB0aGUgcHJvY2Vzcy4N Cg0KVGhhbmsgeW91IHZlcnkgbXVjaC4NCg0KTGluZGEgRHVuYmFyDQo= --_000_4A95BA014132FF49AE685FAB4B9F17F657C2DD55dfweml701chm_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QFNpbVN1biI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlZlcmRhbmE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0K LyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5N c29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCmE6bGlu aywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJs dWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlw ZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsN Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNv TGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5 OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRv bTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCnNw YW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWls U3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGlu IDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K LyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6Mzc3NzAyNTY1 Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxMjc0MTUzMjU4O30NCkBsaXN0IGwwOmxldmVsMQ0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K CW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDox LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3IjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBs MDpsZXZlbDMNCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjA7DQoJbXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Oi07DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseToiVmVyZGFuYSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OkFyaWFsO30N CkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDps ZXZlbDUNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21z by1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtdGFi LXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjQuMGlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwx DQoJe21zby1saXN0LWlkOjQyMzQ5ODMyNDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE1NjU0 Njg2NjY7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMg0K CXttc28tbGlzdC1pZDo0NTM3OTUwMTI7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjg4MjY4NDQ3 Njt9DQpAbGlzdCBsMjpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzDQoJe21z by1saXN0LWlkOjUyMjQ4MTczMzsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE4ODMyMjYwMjY7 fQ0KQGxpc3QgbDM6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNA0KCXttc28t bGlzdC1pZDoxODcxMTQwNDczOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxMDQ4NzQyNzM2O30N CkBsaXN0IGw0OmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWwyDQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1z by1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIjt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9t OjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZh dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86 aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9 InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkthdGhsZWVuLCA8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlRoYW5rcy4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkkgaGF2ZSBhZGRl ZCB3aGF0IHdlIGhhdmUgdG8gdGhlIElFVEY5MyBCT0Ygd2lraS4gTGV0IG1lIGtub3cgaWYgYW55 IGNoYW5nZXMgYXJlIG5lZWRlZDoNCjxhIGhyZWY9Imh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3Jn L2JvZi90cmFjL3dpa2kvV2lraVN0YXJ0Ij5odHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9ib2Yv dHJhYy93aWtpL1dpa2lTdGFydDwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5IYXZlIGEgZ29vZCB0cmlwIHRvIExpbWEuIExvb2tp bmcgZm9yd2FyZCB0byB0YWxraW5nIHRvIHlvdSBtb3JlIG9uIHRoZSBJMk5TRiBCT0YgcHJlcGFy YXRpb24gd2hlbiB5b3UgY29tZSBiYWNrLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+TGluZGE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBJMm5zZiBbbWFpbHRvOmky bnNmLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkthdGhsZWVuIE1vcmlh cnR5PGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgTWF5IDE4LCAyMDE1IDM6NDUgUE08YnI+DQo8 Yj5Ubzo8L2I+IExpbmRhIER1bmJhcjxicj4NCjxiPkNjOjwvYj4gaTJuc2ZAaWV0Zi5vcmc7IGFn ZW5kYUBpZXRmLm9yZyBBZ2VuZGE7IFN0ZXBoZW4gRmFycmVsbDxicj4NCjxiPlN1YmplY3Q6PC9i PiBSZTogW0kybnNmXSBJMk5TRiBCT0YgU2Vzc2lvbiByZXF1ZXN0IGZvciBJRVRGIDkzPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkxpbmRhLDxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Db3Vs ZCB5b3UgcGxlYXNlIGFkZCB0aGlzIHRvIHRoZSB3aWtpPyAmbmJzcDtJJ20gYWJvdXQgdG8gZmx5 IHRvIExpbWEsIHNvIEkgd291bGRuJ3QgYmUgYWJsZSB0byBnZXQgdG8gaXQgZm9yIGEgYml0Ljxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFu ayB5b3UsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5LYXRobGVlbjxicj4NCjxicj4NClNlbnQgZnJvbSBteSBpUGhvbmU8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+PGJyPg0KT24gTWF5IDE4LCAyMDE1LCBhdCA0OjQxIFBNLCBMaW5kYSBEdW5iYXIg Jmx0OzxhIGhyZWY9Im1haWx0bzpsaW5kYS5kdW5iYXJAaHVhd2VpLmNvbSI+bGluZGEuZHVuYmFy QGh1YXdlaS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+S2F0aGxlZW4sIDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5XZSB3b3VsZCBsaWtlIHRvIHJlcXVlc3QgYSBXRyBmb3JtaW5nIEJPRiBmb3IgSTJOU0YgYXQg SUVURjkzLiBIZXJlIGFyZSB0aGUgZGV0YWlscyBvZiB0aGUgcmVxdWVzdDo8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHVsIHR5cGU9 ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjpibGFjazttc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBs ZXZlbDEgbGZvMyI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Qk9GJ3MgZnVsbCBuYW1l IGFuZCBhY3JvbnltIGluIGJyYWNrZXRzOiAmbmJzcDtJbnRlcmZhY2UgdG8gTmV0d29yayBTZWN1 cml0eSBGdW5jdGlvbnMgKEkyTlNGKTwvc3Bhbj48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJjb2xvcjpibGFjazttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMyI+DQo8c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+QVJFQSB1bmRlciB3aGljaCBXb3JraW5nIEdyb3VwIG9yIEJP RiBhcHBlYXJzOiBTZWN1cml0eTwvc3Bhbj48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJjb2xvcjpibGFjazttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMyI+DQo8c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+Q2hhaXIocykgTmFtZShzKSBhbmQgZS1tYWlsIGFkZHJlc3MoZXMp OiBUQkQ8L3NwYW4+PG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i Y29sb3I6YmxhY2s7bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzMiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjVwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPkFnZW5kYSAodG8gYmUgYWRqdXN0ZWQpPC9zcGFuPjxvOnA+PC9vOnA+PC9saT48L3VsPg0K PHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoxLjBpbjt0ZXh0LWluZGVu dDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwyIGxmbzMiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPm88c3BhbiBzdHlsZT0iZm9u dDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOw0KPC9zcGFu Pjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj5Vc2UgY2FzZXMgJmFtcDsgUHJvYmxlbSBzcGFjZTwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MS4waW47dGV4dC1p bmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMiBsZm8zIj4NCjwhW2lmICFzdXBwb3J0TGlz dHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj5vPHNwYW4gc3R5bGU9 ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsNCjwv c3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibGFjayI+UGFja2V0LUJhc2VkIFBhcmFkaWdtIEZvciBJbnRlcmZhY2VzIFRvIE5TRnM8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdp bi1sZWZ0OjEuMGluO3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDIgbGZvMyI+ DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Okln bm9yZSI+bzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OyI+Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkNhcGFiaWxpdHkgaW50ZXJmYWNlIEluZm9y bWF0aW9uIG1vZGVsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJh Z3JhcGgiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzttYXJnaW4tbGVmdDoxLjBpbjt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAg bGV2ZWwyIGxmbzMiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxzcGFuIHN0eWxl PSJtc28tbGlzdDpJZ25vcmUiPm88c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5k aWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFu YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5HYXAgQW5hbHlzaXM8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdp bi1sZWZ0OjEuMGluO3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDIgbGZvMyI+ DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Okln bm9yZSI+bzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OyI+Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkZyYW1ld29yazwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4w aW47dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMiBsZm8zIj4NCjwhW2lmICFz dXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj5vPHNw YW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsm bmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjpibGFjayI+Q2hhcnRlciBkaXNjdXNzaW9uOg0KPC9zcGFuPjxhIGhyZWY9 Imh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9pMm5zZi9jdXJyZW50L21zZzAw MzkxLmh0bWwiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9pMm5zZi9jdXJy ZW50L21zZzAwMzkxLmh0bWw8L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBh cmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N Cjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6Ymxh Y2s7bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNv LWxpc3Q6bDAgbGV2ZWwxIGxmbzMiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250 LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZ1bGwg RGVzY3JpcHRpb24gb2YgQk9GPC9zcGFuPjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkluIGEgbnV0c2hlbGwsIEkyTlNG IHdhbnRzIHRvIDxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4NCmRlZmlu ZSBpbnRlcmZhY2VzIHRvIHRoZSBmbG93IGJhc2VkIG5ldHdvcmsgc2VjdXJpdHkgZnVuY3Rpb25z IGhvc3RlZCBieSBzZXJ2aWNlIHByb3ZpZGVycyBhdCBkaWZmZXJlbnQgcHJlbWlzZXMuDQo8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWlseTomcXVvdDtW ZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPk5ldHdvcmsgc2VjdXJpdHkgZnVu Y3Rpb25zIChOU0ZzKSBhcmUgcHJvdmlkZWQgYW5kIGNvbnN1bWVkIGluIGluY3JlYXNpbmdseSBk aXZlcnNlIGVudmlyb25tZW50cy4gVXNlcnMgb2YgTlNGcyBjb3VsZCBjb25zdW1lIG5ldHdvcmsg c2VjdXJpdHkgc2VydmljZXMgaG9zdGVkIGJ5IG9uZSBvciBtb3JlIHByb3ZpZGVycywNCiB3aGlj aCBtYXkgYmUgdGhlaXIgb3duIGVudGVycHJpc2UsIHNlcnZpY2UgcHJvdmlkZXJzLCBvciBhIGNv bWJpbmF0aW9uIG9mIGJvdGguIExpa2V3aXNlLCBzZXJ2aWNlIHByb3ZpZGVycyBvZiBOU0ZzIG1h eSBvZmZlciB0aGVpciBjdXN0b21lcnMgbmV0d29yayBzZWN1cml0eSBzZXJ2aWNlcyB0aGF0IGNv bnNpc3Qgb2YgbXVsdGlwbGUgc2VjdXJpdHkgcHJvZHVjdHMgYW5kL29yIGZ1bmN0aW9ucyBmcm9t IGRpZmZlcmVudCB2ZW5kb3JzLiBOU0ZzDQogbWF5IGJlIHByb3ZpZGVkIGJ5IHBoeXNpY2FsIGFu ZC9vciB2aXJ0dWFsaXplZCBpbmZyYXN0cnVjdHVyZS4gV2l0aG91dCBzdGFuZGFyZCBpbnRlcmZh Y2VzIHRvIGV4cHJlc3MsIG1vbml0b3IsIGFuZCBjb250cm9sIHNlY3VyaXR5IHBvbGljaWVzIHRo YXQgZ292ZXJuIHRoZSBiZWhhdmlvciBvZiBOU0ZzLCBpdCBiZWNvbWVzIHZpcnR1YWxseSBpbXBv c3NpYmxlIGZvciBzZWN1cml0eSBzZXJ2aWNlIHByb3ZpZGVycyB0byBhdXRvbWF0ZSB0aGVpcg0K IHNlcnZpY2Ugb2ZmZXJpbmdzIHRoYXQgdXRpbGl6ZSBkaWZmZXJlbnQgc2VjdXJpdHkgZnVuY3Rp b25zIGZyb20gbXVsdGlwbGUgdmVuZG9ycy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTGlzdFBhcmFncmFwaCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250LWZh bWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlRoZSBwcmlt YXJ5IGdvYWwgb2YgSTJOU0YgaXMgdG8gZGVmaW5lIGFuIGluZm9ybWF0aW9uIG1vZGVsLCZuYnNw OyBhIHNldCBvZiBzb2Z0d2FyZSBpbnRlcmZhY2VzIGFuZCBkYXRhIG1vZGVscyBmb3IgY29udHJv bGxpbmcgYW5kIG1vbml0b3JpbmcgYXNwZWN0cyBvZiBOU0ZzIChib3RoIHBoeXNpY2FsIGFuZCB2 aXJ0dWFsKS4gT3RoZXINCiBhc3BlY3RzIG9mIE5TRnMgc3VjaCBhcyBkZXZpY2Ugb3IgbmV0d29y ayBwcm92aXNpb25pbmcgYW5kIGNvbmZpZ3VyYXRpb24gYXJlIG91dCBvZiBzY29wZS4gQ29udHJv bGxpbmcgYW5kIG1vbml0b3Jpbmcgb2YgTlNGcyBzaG91bGQgaW5jbHVkZSB0aGUgdXNlIG9mIHBv bGljaWVzIHRvIHNwZWNpZnksIHF1ZXJ5LCBtb25pdG9yLCBhbmQgY29udHJvbCB0aGUgTlNGcyBi eSBvbmUgb3IgbW9yZSBtYW5hZ2VtZW50IGVudGl0aWVzLg0KPC9zcGFuPlNpbmNlIGRpZmZlcmVu dCBzZWN1cml0eSB2ZW5kb3JzIHN1cHBvcnQgZGlmZmVyZW50IGZlYXR1cmVzIGFuZCBmdW5jdGlv bnMgb24gdGhlaXIgZGV2aWNlcywgSTJOU0Ygd2lsbCBmb2N1cyBvbiBmbG93IGJhc2VkIE5TRnMg dGhhdCBwcm92aWRlIHRyZWF0bWVudCB0byBwYWNrZXRzL2Zsb3dzLCBzdWNoIGFzIElQUy9JRFMs IFdlYiBmaWx0ZXJpbmcsIGZsb3cgZmlsdGVyaW5nLCBkZWVwIHBhY2tldCBpbnNwZWN0aW9uLCBv ciBwYXR0ZXJuDQogbWF0Y2hpbmcgYW5kIHJlbWVkaWF0aW9uLiA8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8dWwg dHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOmJsYWNrO21z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0 OmwwIGxldmVsMSBsZm8zIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5DT05GTElDVFMg eW91IHdpc2ggdG8gYXZvaWQsIHBsZWFzZSBiZSBhcyBzcGVjaWZpYyBhcyBwb3NzaWJsZTo8L3Nw YW4+PG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxl ZnQ6LjVpbiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+U0FDTSwg U0FBUywgbmZ2cmcsIFNGQywgTlZPMywgVFJJTEwsIOKApjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N Cjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6Ymxh Y2s7bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNv LWxpc3Q6bDAgbGV2ZWwxIGxmbzMiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250 LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkV4cGVj dGVkIEF0dGVuZGFuY2UgKGZpZ3VyZXMgZnJvbSB0aGUgcHJldmlvdXMgSUVURiBtZWV0aW5nIGFy ZSBpbmNsdWRlZCBpbiB0aGUgbWVzc2FnZSB0aGF0IGlzIHNlbnQgd2hlbiBzY2hlZHVsaW5nIG9w ZW5zKTogNjA8L3NwYW4+PG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iY29sb3I6YmxhY2s7bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzMiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjVwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPlNwZWNpYWwgcmVxdWVzdHM6PC9zcGFuPjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOmJsYWNrO21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8zIj4NCjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5OdW1iZXIgb2Ygc2Vzc2lvbnM6IDE8L3NwYW4+PG86cD48 L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6YmxhY2s7bXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAg bGV2ZWwxIGxmbzMiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWlseTom cXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkxlbmd0aCBvZiBzZXNz aW9uczoNCjwvc3Bhbj48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjx1bCB0eXBlPSJkaXNjIj4NCjx1 bCB0eXBlPSJjaXJjbGUiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjpibGFj azttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28t bGlzdDpsMCBsZXZlbDIgbGZvMyI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+MiBob3Vy czwvc3Bhbj48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhvcGUgeW91IGNh biBndWlkZSB1cyB0aHJvdWdoIHRoZSBwcm9jZXNzLiA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ VGhhbmsgeW91IHZlcnkgbXVjaC4gPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkxpbmRhIER1bmJh cjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_4A95BA014132FF49AE685FAB4B9F17F657C2DD55dfweml701chm_-- From nobody Mon May 18 15:39:17 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8F631A86F6 for ; Mon, 18 May 2015 15:39:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.512 X-Spam-Level: X-Spam-Status: No, score=-4.512 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MANY_SPAN_IN_TEXT=2.399, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xfF41YBe00gg for ; Mon, 18 May 2015 15:39:10 -0700 (PDT) Received: from mxe02.gs.com (mxe02.gs.com [199.99.47.104]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB2041A7018 for ; Mon, 18 May 2015 15:39:09 -0700 (PDT) Received: from pps.filterd (gsppabdp01sd.idz.gs.com [127.0.0.1]) by gsppabdp01sd.idz.gs.com (8.14.5/8.14.5) with SMTP id t4IMPHiQ006267; Mon, 18 May 2015 18:38:48 -0400 Received: from gsppabdp04nd.inz.gs.com ([10.204.43.243]) by gsppabdp01sd.idz.gs.com with ESMTP id 1ufqxc8n9p-1; Mon, 18 May 2015 18:38:48 -0400 Received: from pps.filterd (gsppabdp04nd.inz.gs.com [127.0.0.1]) by gsppabdp04nd.inz.gs.com (8.14.5/8.14.5) with SMTP id t4IMMcYH027519; Mon, 18 May 2015 18:38:58 -0400 Received: from gshcbdp12ex.firmwide.corp.gs.com (gshcbdp12ex.firmwide.corp.gs.com [10.135.172.21]) by gsppabdp04nd.inz.gs.com with ESMTP id 1ufg9f4gk9-1; Mon, 18 May 2015 18:38:58 -0400 Received: from GSCMAMP19EX.firmwide.corp.gs.com ([139.172.38.36]) by gshcbdp12ex.firmwide.corp.gs.com ([10.135.172.21]) with mapi; Mon, 18 May 2015 18:38:37 -0400 From: "Zarny, Myo" To: "'Linda Dunbar'" , "'i2nsf@ietf.org'" Date: Mon, 18 May 2015 18:38:56 -0400 Thread-Topic: Revised Narrower scoped I2NSF charter Thread-Index: AdCRmyiKiZeg0kFYSvW3DBEM9L/fbwABv3fQ Message-ID: References: <4A95BA014132FF49AE685FAB4B9F17F657C2DC55@dfweml701-chm> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657C2DC55@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-retentionstamp: Firmwide Content-Type: multipart/alternative; boundary="_000_A3233753A4B65F43BCA1B64DA99A9C230721AABDCCGSCMAMP19EXfi_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-05-18_04:2015-05-18,2015-05-18,1970-01-01 signatures=0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-05-18_04:2015-05-18,2015-05-18,1970-01-01 signatures=0 Archived-At: Cc: "'Romascanu, Dan \(Dan\)'" , 'Joseph Salowey' , 'Kathleen Moriarty' Subject: Re: [I2nsf] Revised Narrower scoped I2NSF charter X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2015 22:39:15 -0000 --_000_A3233753A4B65F43BCA1B64DA99A9C230721AABDCCGSCMAMP19EXfi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Linda, Please see my comments/edits below. (Just to clarify: I read that the Servi= ce Layer is out of scope, correct? I don't see anything related to SL in th= e book of work. I've tried to make that clear.) Myo From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: 18 May 2015 2:48 PM To: i2nsf@ietf.org Cc: Romascanu, Dan (Dan); Joseph Salowey; Kathleen Moriarty Subject: [I2nsf] Revised Narrower scoped I2NSF charter Thanks to many people contributions to I2NSF charter. Here is the revised o= ne. Please provide comments and suggestions if your suggested changes haven= 't been properly addressed. Network security functions (NSFs) are provided and consumed in increasingly= diverse environments. Users of NSFs could consume network security service= s hosted by one or more providers, which may be their own enterprise, servi= ce providers, or a combination of both. Likewise, service providers of NSFs= may offer their customers network security services that consist of multip= le security products and/or functions from different vendors. NSFs may be p= rovided by physical and/or virtualized infrastructure. Without standard int= erfaces to express, monitor, and control security policies that govern the = behavior of NSFs, it becomes virtually impossible for security service prov= iders to automate their service offerings that utilize different security f= unctions from multiple vendors. The primary goal of I2NSF is to define an information model, a set of soft= ware interfaces and data models for controlling and monitoring aspects of N= SFs (both physical and virtual). Other aspects of NSFs such as device or ne= twork provisioning and configuration are out of scope. Controlling and moni= toring of NSFs should include the use of policies to specify, query, monito= r, and control the NSFs by one or more management entities. Since different= security vendors support different features and functions on their devices= , I2NSF will focus on flow-based NSFs that provide treatment to packets/flo= ws, such as IPS/IDS, Web filtering, flow filtering, deep packet inspection,= or pattern matching and remediation. There are two layers of interfaces envisioned in the I2NSF approach: * I2NSF Capabilities Capability Layer * I2NSF Services Service Layer [MZ: I personally prefer "Capabilities Layer" and "Services Layer" or even= "Service Abstraction Layer." But I'll go with what's entrenched in the car= rier space.] The I2NSF Capability Layer specifies the functional security policies, whic= h are translated from the entity defining the goal of the security policy i= nto a form that can be implemented, and are used to monitor and control the= behavior of NSFs. I2NSF will NOT standardize NSFs or devices. Instead, I2N= SF will only standardize only the controlling control and monitoring aspect= s of the NSFs (not devices). An exemplar controlling of flow-based NSFs is = "Subject - Object - Function - Action". [MZ]: The I2NSF Capability Layer specifies how to control and monitor NSFs= at an implementational level. (I2NSF will NOT work on any other aspects of= NSFs. Nor will I2NSF at this stage specify how to derive control and monit= oring capabilities from higher level security policies for the Capability L= ayer.) A sample Capability Layer construct for controlling NSFs is "subject= -object-function-action". [MZ: I personally don't think we should add "subject-object-function-action= " in the charter. I'll defer to others on this.] The I2NSF Service Layer is for clients to express and monitor security poli= cies for their specific flows, which is usually based on application and cl= ient specific logical networks requirements and context. [MZ]: The I2NSF Service Layer defines how security policies may be expresse= d and monitored. The Service Layer is out of scope for this phase of I2NSF'= s work. However, I2NSF will provide a forum for information drafts on data = models, APIs, etc. that demonstrate how service layer policies may be trans= lated to Capability Layer functions. The concrete work at the I2NSF Capability Layer includes development of: - An information model that defines concepts required for standard= izing the controlling and monitoring of NSFs, - A set of YANG data models, derived from the above information mo= del, which enables the controlling and monitoring of virtual and/or physica= l NSFs, - The capability An IANA capabilities registry (IANA) that specifi= es the characteristics and behaviors of NSFs using a vendor-neutral vocabul= ary. enables the characteristics and behavior of NSFs to be specified using a ve= ndor-neutral vocabulary without requiring the NSFs themselves to be standar= dized; the registry enables various mechanisms, including policy rules, to = be used to match monitor and control functions to the needs of an applicati= on and/or environment, and - The proper secure communication channels to carry the controllin= g control and monitoring information between the NSFs and their management = entity (or entities). and the NSFs being controlled. Standard interfaces for monitoring and controlling the behavior of NSFs are= essential building blocks for Security Service Providers to automate the u= se of different NSFs from multiple vendors by their Security management ent= ities. This layer will leverage the existing protocols and data models defi= ned 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 data models, APIs, and/or RESTful inter= faces to clients and demonstrating the feasibility of them being translated= to the Capability Layer policies. [MZ: See above.] It is a non-goal not a goal of I2NSF to create new protocols or data modeli= ng languages for I2NSF interfaces. The I2NSF WG's deliverables include: - Use Cases document. - Framework Document. - Requirements for extensions (if there are any) to existing proto= cols used by the WG. - Gap analysis of existing protocols and modeling languages for sp= ecifying, querying, monitoring, and controlling NSFs. - A single, unified, Information Model for controlling and monitor= ing flow-based NSFs. - Corresponding YANG Data Models derived from the above Informatio= n Model. - IANA registry consideration for flow-based NSFs controlling and = monitoring capability capabilities. - (Optionally) Document describing how capabilities are used to mo= nitor and control flow-based NSFs. - (Optionally) Applicability Statements on how to use I2RS, Netcon= f, and NETMOD to carry the content of the specified information/data models= . [The WG may decide that the Use cases, Framework, and Requirements are Info= rmational documents or simply reference documents during the lifetime of th= e WG.] Suggested Milestones - Use Cases Document: Charter time + 1 month to WG Document - Framework: Charter time + 4 months to WG Document - Requirements for extensions to protocols: Charter time + 8 months to W= G document - Info model: Charter time + 8 months to WG Document - IANA registry consideration + 12 months to WG Document - All Early Drafts to IESG: 18 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 - 18 months The WG will work closely with I2RS, Netconf and Netmod WGs. The WG will com= municate with external SDOs like ETSI NFV and will encourage open source co= de development related to the WG scope in organizations like ONF, OpenStack= , ODL, and OpenNFV OPNFV. Cheers, Linda --_000_A3233753A4B65F43BCA1B64DA99A9C230721AABDCCGSCMAMP19EXfi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Linda,

 

Please see my comments/edits below. (Just to clari= fy: I read that the Service Layer is out of scope, correct? I don’t s= ee anything related to SL in the book of work. I’ve tried to make tha= t clear.)

 

Myo

 

From: I2nsf [mailto:i2nsf-bounces@ietf.org] On = Behalf Of Linda Dunbar
Sent: 18 May 2015 2:48 PM
To: i2nsf@ietf.org
Cc: Romascanu, Dan (Dan); Joseph Salowey; Kathle= en Moriarty
Subject: [I2nsf] Revised Narrower scoped I2NSF charte= r

 

Thanks to many people contributions to I2NSF charter. Here is the revised= one. Please provide comments and suggestions if your suggested changes hav= en’t been properly addressed.

 

 

 

Network security functions (NSFs) are provided and consume= d 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 of NSFs may offer their customers network security services that = consist of multiple security products and/or functions from different vendo= rs. NSFs may be provided by physical and/or virtualized infrastructure. Wit= hout standard interfaces to express, monitor, and control security policies= that govern the behavior of NSFs, it becomes virtually impossible for secu= rity service providers to automate their service offerings that utilize dif= ferent security functions from multiple vendors.

 

The primary goal of I2NSF is to define an informat= ion model,  a set of software interfaces and data models for controlli= ng and monitoring aspects of NSFs (both physical and virtual). Other aspect= s of NSFs such as device or network provisioning and configuration are out = of scope. Controlling and monitoring of NSFs should include the use of poli= cies to specify, query, monitor, and control the NSFs by one or more manage= ment entities. Since different security vendors support different fe= atures and functions on their devices, I2NSF will focus on flow-based NSFs that provide treatment to packets/flo= ws, such as IPS/IDS, Web filtering, flow filtering, deep packet inspection,= or pattern matching and remediation.

 

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

&mi= ddot;    &= nbsp;    I2NSF Capabilities Capabil= ity Layer

·         = I2NSF Services Se= rvice Layer

[MZ:  I personally prefer “Capa= bilities Layer” and “Services Layer” or even “Servi= ce Abstraction Layer.” But I’ll go with what’s entrenched= in the carrier space.]

 

The I2NSF Capab= ility Layer specifies the functional security p= olicies, which are translated from the entity defining the goal of the secu= rity policy into a form that can be implemented, and are used to monitor an= d control the behavior of NSFs. I2NSF will NOT standardize NSFs or devices. In= stead, I2NSF will only standardize only <= /span>the = controlling control and monitoring aspects = of the NSFs (not devices). An exemplar controlling of flow-based NSFs is &#= 8220;Subject – Object – Function – Action”.  <= o:p>

 

[MZ]:  The I2NSF Capability Layer spec= ifies how to control and monitor NSFs at an implementational level. (I2NSF = will NOT work on any other aspects of NSFs. Nor will I2NSF at this stage sp= ecify how to derive control and monitoring capabilities from higher level s= ecurity policies for the Capability Layer.) A sample Capability Layer const= ruct for controlling NSFs is “subject-object-function-action”.<= o:p>

 

[MZ: I personally do= n’t think we should add “subject-object-function-action” = in the charter. I’ll defer to others on this.]

<= p class=3DMsoNormal> <= /p>

The I2NSF Service Lay= er is for clients to express and monitor security policies for their specif= ic flows, which is usually based on application and client specific logical= networks requirements and context.

[MZ]: The I2NSF Service Layer defines how securit= y policies may be expressed and monitored. The Service Layer is out of scop= e for this phase of I2NSF’s work. However, I2NSF will provide a forum= for information drafts on data models, APIs, etc. that demonstrate how ser= vice layer policies may be translated to Capability Layer functions.

&nbs= p;

The conc= rete work at the I2NSF Capability Layer includes development of:<= /p>

-          <= /span>An information model that defines concepts required for sta= ndardizing the controlling and = monitoring of NSFs,

-&nbs= p;         A set of YANG data models, derived from the above information model<= s>, which enables the controlling and monitor= ing of virtual and/or physical NSFs,

-  = ;        = The capability An IANA capabilities registry (IANA) that specifies the characteristics and behaviors of NSFs= using a vendor-neutral vocabulary.

enables the characteristics and behavior of NSFs= to be specified using a vendor-neutral vocabulary without requiring the NS= Fs themselves to be standardized; = the registry enables various mechanisms, including policy rules, to be u= sed to match monitor and control functions to the needs of an application a= nd/or environment, and

<= ![if !supportLists]>-    =       The proper se= cure communication channels to carry the c= ontrolling control and moni= toring information between the NSFs and their management entity (or entities= ). an= d the NSFs being controlled.

 <= /o:p>

Standard interface= s for monitoring and controlling the behavior of NSFs are essential buildin= g blocks for Security Service Providers to automate the use of different NS= Fs from multiple vendors by their Security management entities. This layer = will leverage the existing protocols and data models defined by I2RS, Netco= nf, and NETMOD.

 

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

[MZ:  See above.]

 

It is a non-goal not a goal of I2NSF= to create new protocols or data modeling languages for I2NSF interf= aces.

 

The I2NSF WG’s deliverables include:

 

-         = Use Cases doc= ument.

-&nbs= p;         = Framework Document.

-          Requirements for extension= s (if there are any) to existing protocols used by the WG.

-   &nb= sp;      Gap analysis of e= xisting protocols and modeling languages for specifying, querying, monitori= ng, and controlling NSFs.

-          A single, unified, Information Model for controlling an= d monitoring flow-based NSFs.

-          Corresponding YANG Data Models derived from the above= Information Model.

-          IANA registry consideration for flow-based NSFs controlling and monitoring capability capabilities.

- &= nbsp;        (Op= tionally) Document describing how capabilities are used to monitor and cont= rol flow-based NSFs.

-          (Optionally) Applicability Statements on how to use I2RS, Netc= onf, and NETMOD to carry the content of the specified information/data mode= ls.

&nbs= p;

[The WG may decide that the Use cases, Framework, and Requiremen= ts = are Informational documents or simply reference documents during the lifeti= me of the WG.]

 

Suggested Milestones

  - Use Cases Document= :  Charter time + 1 month to WG Document

  - Framework: Charter time + 4 month= s to WG Document

  - Requirements for extensions to protocols:  Charter time += 8 months to WG document

  - Info model: Charter time + 8 months to WG Document

  - IANA re= gistry consideration + 12 months to WG Document

  - All Early Drafts to IESG: 18 mo= nths

&nb= sp;

[decision poin= t – +10 months] 

  - Data Models: Charter + 9 Months to WG Documen= t

  - Ap= plicability Statements: 10 months to WG Document

  - Data Models and Applicability = Statements to IESG  - 18 months

 

The WG will work closely with I2RS, Netconf and Netmod WG= s. The WG will communicate with external SDOs like ETSI NFV and will encour= age open source code development related to the WG scope in organizations l= ike ONF, OpenStack, ODL, and OpenNFV OP= NFV.

 

 

Cheers,

 

Li= nda

= --_000_A3233753A4B65F43BCA1B64DA99A9C230721AABDCCGSCMAMP19EXfi_-- From nobody Tue May 19 08:59:27 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FBBC1AC3CE for ; Tue, 19 May 2015 08:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OPc6BWUjWzNk for ; Tue, 19 May 2015 08:59:24 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63BB61ACED8 for ; Tue, 19 May 2015 08:59:08 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BWG74019; Tue, 19 May 2015 15:59:06 +0000 (GMT) Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 19 May 2015 16:59:03 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml705-chm ([10.193.5.142]) with mapi id 14.03.0158.001; Tue, 19 May 2015 08:59:00 -0700 From: Linda Dunbar To: "i2nsf@ietf.org" Thread-Topic: I2NSF Interim meetings to prepare for IETF 93 BOF Thread-Index: AdCSTLfYdk4DE/RRSdOFa4L0qLG8Bw== Date: Tue, 19 May 2015 15:58:59 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657C406D3@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.233] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657C406D3dfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [I2nsf] I2NSF Interim meetings to prepare for IETF 93 BOF X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 15:59:25 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F657C406D3dfweml701chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In order to get ready for a successful I2NSF BOF at IETF93, we plan have a = couple of interim meetings to discuss the following items: 1. Reach consensus on the I2NSF charter 2. Go through the use case drafts, and make sure duplicated contents = are removed or merged 3. Go through the problem statement draft, and make sure it is consis= tent with the narrower scoped I2NSF charter. 4. Go through the framework draft, and make sure it is consistent wit= h the narrower scoped I2NSF charter. 5. Go through the capability draft Since the authors of #2 & #5 are based in Asia and other people are spread = US/EU, we will have two separate I2NSF interims, one geared towards the peo= ple in Asia and others towards people in US/EU. Interim #1: May 26 2:30pm for the Item #1 & #3 & #4 listed above Interim #2: June 2nd or 3rd for the Item #2 & #5 above. I will send out meeting conference bridges soon. Cheers, Linda --_000_4A95BA014132FF49AE685FAB4B9F17F657C406D3dfweml701chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In order to get ready for a successful I2NSF BOF at = IETF93, we plan have a couple of interim meetings to discuss the following = items:

 

1.     &= nbsp; Reach consensus on the I2NSF charter

2.     &= nbsp; Go through the use case drafts, and make sure dupli= cated contents are removed or merged

3.     &= nbsp; Go through the problem statement draft, and make su= re it is consistent with the narrower scoped I2NSF charter.

4.     &= nbsp; Go through the framework draft, and make sure it is= consistent with the narrower scoped I2NSF charter.

5.     &= nbsp; Go through the capability draft

 

Since the authors of #2 & #5 are based in Asia a= nd other people are spread US/EU, we will have two separate I2NSF interims,= one geared towards the people in Asia and others towards people in US/EU.

 

Interim #1: May 26 2:30pm  for the Item #1 &= ; #3 & #4 listed above

 

Interim #2: June 2nd or 3rd fo= r the Item #2 & #5 above.

 

I will send out mee= ting conference bridges soon.

 

Cheers,

 

Linda

 

--_000_4A95BA014132FF49AE685FAB4B9F17F657C406D3dfweml701chm_-- From nobody Tue May 19 14:47:43 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDA381A90B8 for ; Tue, 19 May 2015 14:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZetPeuOi0NXZ for ; Tue, 19 May 2015 14:47:40 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38A7C1ACCD8 for ; Tue, 19 May 2015 14:47:38 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BWG92835; Tue, 19 May 2015 21:47:36 +0000 (GMT) Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 19 May 2015 22:47:33 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml702-chm ([10.193.5.72]) with mapi id 14.03.0158.001; Tue, 19 May 2015 14:47:25 -0700 From: Linda Dunbar To: "Romascanu, Dan (Dan)" , "'Joseph Salowey'" , "'DIEGO LOPEZ GARCIA'" , John Strassner , Susan Hares , "Zarny, Myo" , "i2nsf@ietf.org" Thread-Topic: Interim Meeting to reach consensus on I2NSF charter, and discuss if the problem & framework drafts reflect the updated I2NSF charter Thread-Index: AdCSfWPp26bik8y7TtGAxr7qFzwsDQ== Date: Tue, 19 May 2015 21:47:24 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657C42988@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.233] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657C42988dfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [I2nsf] Interim Meeting to reach consensus on I2NSF charter, and discuss if the problem & framework drafts reflect the updated I2NSF charter X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 21:47:41 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F657C42988dfweml701chm_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable When: Tuesday, May 26, 2015 1:30 PM-3:00 PM (UTC-06:00) Central Time (US & = Canada). Where: conference bridge Note: The GMT offset above does not reflect daylight saving time adjustment= s. *~*~*~*~*~*~*~*~*~* In order to get ready for a successful I2NSF BOF at IETF93, we plan have a = couple of interim meetings to discuss the following items: * Reach consensus on the I2NSF charter * Go through the problem statement draft, and make sure it is consist= ent with the narrower scoped I2NSF charter. * Go through the framework draft, and make sure it is consistent with= the narrower scoped I2NSF charter. Conference bridge will be sent out shortly. Linda --_000_4A95BA014132FF49AE685FAB4B9F17F657C42988dfweml701chm_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
When: Tuesday, May 26, 2015 1:30 PM-3:00 PM (UTC-06:00) Central Time (= US & Canada).
Where: conference bridge
 
Note: The GMT offset above does not reflect daylight saving time adjus= tments.
 
*~*~*~*~*~*~*~*~*~*
 
In order to get ready for a successful I2NSF BOF at IETF93, we plan ha= ve a couple of interim meetings to discuss the following items:
 
  • Reach consensus on the I2NSF charter
  • Go through the problem sta= tement draft, and make sure it is consistent with the narrower scoped I2NSF= charter.
  • Go through the framework draft, and make sure it is cons= istent with the narrower scoped I2NSF charter.
 
 
Conference bridge will be sent out shortly.
 
Linda
 
 --_000_4A95BA014132FF49AE685FAB4B9F17F657C42988dfweml701chm_ Content-Type: text/calendar; charset="utf-8"; method=REQUEST Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSDQpNRVRIT0Q6UkVRVUVTVA0KUFJPRElEOk1pY3Jvc29mdCBFeGNoYW5n ZSBTZXJ2ZXIgMjAxMA0KVkVSU0lPTjoyLjANCkJFR0lOOlZUSU1FWk9ORQ0KVFpJRDpDZW50cmFs IFN0YW5kYXJkIFRpbWUNCkJFR0lOOlNUQU5EQVJEDQpEVFNUQVJUOjE2MDEwMTAxVDAyMDAwMA0K VFpPRkZTRVRGUk9NOi0wNTAwDQpUWk9GRlNFVFRPOi0wNjAwDQpSUlVMRTpGUkVRPVlFQVJMWTtJ TlRFUlZBTD0xO0JZREFZPTFTVTtCWU1PTlRIPTExDQpFTkQ6U1RBTkRBUkQNCkJFR0lOOkRBWUxJ R0hUDQpEVFNUQVJUOjE2MDEwMTAxVDAyMDAwMA0KVFpPRkZTRVRGUk9NOi0wNjAwDQpUWk9GRlNF VFRPOi0wNTAwDQpSUlVMRTpGUkVRPVlFQVJMWTtJTlRFUlZBTD0xO0JZREFZPTJTVTtCWU1PTlRI PTMNCkVORDpEQVlMSUdIVA0KRU5EOlZUSU1FWk9ORQ0KQkVHSU46VkVWRU5UDQpPUkdBTklaRVI7 Q049TGluZGEgRHVuYmFyOk1BSUxUTzpsaW5kYS5kdW5iYXJAaHVhd2VpLmNvbQ0KQVRURU5ERUU7 Uk9MRT1SRVEtUEFSVElDSVBBTlQ7UEFSVFNUQVQ9TkVFRFMtQUNUSU9OO1JTVlA9VFJVRTtDTj0i Um9tYXNjYW51LA0KICBEYW4gKERhbikiOk1BSUxUTzpkcm9tYXNjYUBhdmF5YS5jb20NCkFUVEVO REVFO1JPTEU9UkVRLVBBUlRJQ0lQQU5UO1BBUlRTVEFUPU5FRURTLUFDVElPTjtSU1ZQPVRSVUU7 Q049J0pvc2VwaCBTYQ0KIGxvd2V5JzpNQUlMVE86am9lQHNhbG93ZXkubmV0DQpBVFRFTkRFRTtS T0xFPVJFUS1QQVJUSUNJUEFOVDtQQVJUU1RBVD1ORUVEUy1BQ1RJT047UlNWUD1UUlVFO0NOPSdE SUVHTyBMT1ANCiBFWiBHQVJDSUEnOk1BSUxUTzpkaWVnby5yLmxvcGV6QHRlbGVmb25pY2EuY29t DQpBVFRFTkRFRTtST0xFPVJFUS1QQVJUSUNJUEFOVDtQQVJUU1RBVD1ORUVEUy1BQ1RJT047UlNW UD1UUlVFO0NOPUpvaG4gU3RyYXMNCiBzbmVyOk1BSUxUTzpKb2huLnNjLlN0cmFzc25lckBodWF3 ZWkuY29tDQpBVFRFTkRFRTtST0xFPVJFUS1QQVJUSUNJUEFOVDtQQVJUU1RBVD1ORUVEUy1BQ1RJ T047UlNWUD1UUlVFO0NOPVN1c2FuIEhhcmUNCiBzOk1BSUxUTzpzaGFyZXNAbmR6aC5jb20NCkFU VEVOREVFO1JPTEU9UkVRLVBBUlRJQ0lQQU5UO1BBUlRTVEFUPU5FRURTLUFDVElPTjtSU1ZQPVRS VUU7Q049Ilphcm55LCBNeW8iDQogOk1BSUxUTzpNeW8uWmFybnlAZ3MuY29tDQpBVFRFTkRFRTtS T0xFPVJFUS1QQVJUSUNJUEFOVDtQQVJUU1RBVD1ORUVEUy1BQ1RJT047UlNWUD1UUlVFO0NOPWky bnNmQGlldGYNCiAub3JnOk1BSUxUTzppMm5zZkBpZXRmLm9yZw0KREVTQ1JJUFRJT047TEFOR1VB R0U9ZW4tVVM6V2hlbjogVHVlc2RheVwsIE1heSAyNlwsIDIwMTUgMTozMCBQTS0zOjAwIFBNIChV DQogVEMtMDY6MDApIENlbnRyYWwgVGltZSAoVVMgJiBDYW5hZGEpLlxuV2hlcmU6IGNvbmZlcmVu Y2UgYnJpZGdlXG5cbk5vdGU6IFQNCiBoZSBHTVQgb2Zmc2V0IGFib3ZlIGRvZXMgbm90IHJlZmxl Y3QgZGF5bGlnaHQgc2F2aW5nIHRpbWUgYWRqdXN0bWVudHMuXG5cbg0KICp+Kn4qfip+Kn4qfip+ Kn4qfipcblxuSW4gb3JkZXIgdG8gZ2V0IHJlYWR5IGZvciBhIHN1Y2Nlc3NmdWwgSTJOU0YgQk9G IGF0DQogIElFVEY5M1wsIHdlIHBsYW4gaGF2ZSBhIGNvdXBsZSBvZiBpbnRlcmltIG1lZXRpbmdz IHRvIGRpc2N1c3MgdGhlIGZvbGxvd2kNCiBuZyBpdGVtczpcblxu4oCiICAgICAgIFJlYWNoIGNv bnNlbnN1cyBvbiB0aGUgSTJOU0YgY2hhcnRlclxu4oCiICAgICAgIEdvIA0KIHRocm91Z2ggdGhl IHByb2JsZW0gc3RhdGVtZW50IGRyYWZ0XCwgYW5kIG1ha2Ugc3VyZSBpdCBpcyBjb25zaXN0ZW50 IHdpdGggDQogdGhlIG5hcnJvd2VyIHNjb3BlZCBJMk5TRiBjaGFydGVyLlxu4oCiICAgICAgIEdv IHRocm91Z2ggdGhlIGZyYW1ld29yayBkcmENCiBmdFwsIGFuZCBtYWtlIHN1cmUgaXQgaXMgY29u c2lzdGVudCB3aXRoIHRoZSBuYXJyb3dlciBzY29wZWQgSTJOU0YgY2hhcnRlcg0KIC5cblxuXG5D b25mZXJlbmNlIGJyaWRnZSB3aWxsIGJlIHNlbnQgb3V0IHNob3J0bHkuXG5cbkxpbmRhXG5cbg0K U1VNTUFSWTtMQU5HVUFHRT1lbi1VUzpJbnRlcmltIE1lZXRpbmcgdG8gcmVhY2ggY29uc2Vuc3Vz IG9uICBJMk5TRiBjaGFydGVyDQogXCwgYW5kIGRpc2N1c3MgaWYgIHRoZSBwcm9ibGVtICYgZnJh bWV3b3JrIGRyYWZ0cyByZWZsZWN0IHRoZSB1cGRhdGVkIEkyTlMNCiBGIGNoYXJ0ZXINCkRUU1RB UlQ7VFpJRD1DZW50cmFsIFN0YW5kYXJkIFRpbWU6MjAxNTA1MjZUMTMzMDAwDQpEVEVORDtUWklE PUNlbnRyYWwgU3RhbmRhcmQgVGltZToyMDE1MDUyNlQxNTAwMDANClVJRDowNDAwMDAwMDgyMDBF MDAwNzRDNUI3MTAxQTgyRTAwODAwMDAwMDAwRTA2OUZGMzU0RTkyRDAwMTAwMDAwMDAwMDAwMDAw MA0KIDAxMDAwMDAwMEFDRDc1MDQzODFBNDc4NDJCMDYwMTdGNThDMUJFNDYxDQpDTEFTUzpQVUJM SUMNClBSSU9SSVRZOjUNCkRUU1RBTVA6MjAxNTA1MTlUMjE0NzIzWg0KVFJBTlNQOk9QQVFVRQ0K U1RBVFVTOkNPTkZJUk1FRA0KU0VRVUVOQ0U6MA0KTE9DQVRJT047TEFOR1VBR0U9ZW4tVVM6Y29u ZmVyZW5jZSBicmlkZ2UNClgtTUlDUk9TT0ZULUNETy1BUFBULVNFUVVFTkNFOjANClgtTUlDUk9T T0ZULUNETy1PV05FUkFQUFRJRDoyMzQwNTE1NTENClgtTUlDUk9TT0ZULUNETy1CVVNZU1RBVFVT OlRFTlRBVElWRQ0KWC1NSUNST1NPRlQtQ0RPLUlOVEVOREVEU1RBVFVTOkJVU1kNClgtTUlDUk9T T0ZULUNETy1BTExEQVlFVkVOVDpGQUxTRQ0KWC1NSUNST1NPRlQtQ0RPLUlNUE9SVEFOQ0U6MQ0K WC1NSUNST1NPRlQtQ0RPLUlOU1RUWVBFOjANClgtTUlDUk9TT0ZULURJU0FMTE9XLUNPVU5URVI6 RkFMU0UNCkJFR0lOOlZBTEFSTQ0KQUNUSU9OOkRJU1BMQVkNCkRFU0NSSVBUSU9OOlJFTUlOREVS DQpUUklHR0VSO1JFTEFURUQ9U1RBUlQ6LVBUMTVNDQpFTkQ6VkFMQVJNDQpFTkQ6VkVWRU5UDQpF TkQ6VkNBTEVOREFSDQo= --_000_4A95BA014132FF49AE685FAB4B9F17F657C42988dfweml701chm_-- From nobody Tue May 19 18:20:52 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F3A51B2AD2 for ; Tue, 19 May 2015 18:20:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.09 X-Spam-Level: X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WKxBOpXfDuWA for ; Tue, 19 May 2015 18:20:42 -0700 (PDT) Received: from smtpjc.telefonica.com (smtpjc.telefonica.com [81.47.204.76]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8AE31ACEA4 for ; Tue, 19 May 2015 18:20:41 -0700 (PDT) Received: from smtpjc.telefonica.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 85D562D02BF; Wed, 20 May 2015 03:20:38 +0200 (CEST) Received: from ESTGVMSP108.EUROPE.telefonica.corp (unknown [10.92.4.9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtpjc.telefonica.com (Postfix) with ESMTPS id 6C6302D026F; Wed, 20 May 2015 03:20:38 +0200 (CEST) Received: from emea01-am1-obe.outbound.protection.outlook.com (10.92.5.139) by tls.telefonica.com (10.93.6.52) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 20 May 2015 03:20:38 +0200 Received: from DB4PR06MB0624.eurprd06.prod.outlook.com (25.161.13.142) by DB4PR06MB0623.eurprd06.prod.outlook.com (25.161.13.141) with Microsoft SMTP Server (TLS) id 15.1.166.22; Wed, 20 May 2015 01:20:35 +0000 Received: from DB4PR06MB0624.eurprd06.prod.outlook.com ([25.161.13.142]) by DB4PR06MB0624.eurprd06.prod.outlook.com ([25.161.13.142]) with mapi id 15.01.0166.017; Wed, 20 May 2015 01:20:35 +0000 From: DIEGO LOPEZ GARCIA To: "Zarny, Myo" Thread-Topic: [I2nsf] Revised Narrower scoped I2NSF charter Thread-Index: AdCRmyiKiZeg0kFYSvW3DBEM9L/fbwABv3fQAD5CJwA= Date: Wed, 20 May 2015 01:20:34 +0000 Message-ID: References: <4A95BA014132FF49AE685FAB4B9F17F657C2DC55@dfweml701-chm> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=diego.r.lopez@telefonica.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [121.58.104.2] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB4PR06MB0623; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:DB4PR06MB0623; BCL:0; PCL:0; RULEID:; SRVR:DB4PR06MB0623; x-forefront-prvs: 0582641F53 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(15404003)(24454002)(377454003)(252514010)(199003)(189002)(2900100001)(102836002)(92566002)(2950100001)(82746002)(19580405001)(46102003)(15975445007)(122556002)(40100003)(68736005)(83716003)(77156002)(62966003)(5001860100001)(5001830100001)(50986999)(76176999)(110136002)(5001960100002)(54356999)(189998001)(4001540100001)(97736004)(101416001)(81156007)(19617315012)(16236675004)(106356001)(87936001)(2656002)(105586002)(86362001)(561944003)(33656002)(19580395003)(66066001)(36756003)(64706001)(7059030)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR06MB0623; H:DB4PR06MB0624.eurprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: telefonica.com does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_DDECF571ACB843899F56ECCD7FE0D39Ctelefonicacom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 May 2015 01:20:34.6159 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR06MB0623 X-OriginatorOrg: telefonica.com X-TM-AS-MML: No Archived-At: Cc: "i2nsf@ietf.org" , "Romascanu, Dan \(Dan\)" , Joseph Salowey , Kathleen Moriarty , Linda Dunbar Subject: Re: [I2nsf] Revised Narrower scoped I2NSF charter X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 01:20:48 -0000 --_000_DDECF571ACB843899F56ECCD7FE0D39Ctelefonicacom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, I support Myo's changes, including the proposal of not adding the "subject-= object-function-action=94 in the charter. Be goode, On 19 May 2015, at 06:38 , Zarny, Myo > wrote: Hi Linda, Please see my comments/edits below. (Just to clarify: I read that the Servi= ce Layer is out of scope, correct? I don=92t see anything related to SL in = the book of work. I=92ve tried to make that clear.) Myo From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: 18 May 2015 2:48 PM To: i2nsf@ietf.org Cc: Romascanu, Dan (Dan); Joseph Salowey; Kathleen Moriarty Subject: [I2nsf] Revised Narrower scoped I2NSF charter Thanks to many people contributions to I2NSF charter. Here is the revised o= ne. Please provide comments and suggestions if your suggested changes haven= =92t been properly addressed. Network security functions (NSFs) are provided and consumed in increasingly= diverse environments. Users of NSFs could consume network security service= s hosted by one or more providers, which may be their own enterprise, servi= ce providers, or a combination of both. Likewise, service providers of NSFs= may offer their customers network security services that consist of multip= le security products and/or functions from different vendors. NSFs may be p= rovided by physical and/or virtualized infrastructure. Without standard int= erfaces to express, monitor, and control security policies that govern the = behavior of NSFs, it becomes virtually impossible for security service prov= iders to automate their service offerings that utilize different security f= unctions from multiple vendors. The primary goal of I2NSF is to define an information model, a set of soft= ware interfaces and data models for controlling and monitoring aspects of N= SFs (both physical and virtual). Other aspects of NSFs such as device or ne= twork provisioning and configuration are out of scope. Controlling and moni= toring of NSFs should include the use of policies to specify, query, monito= r, and control the NSFs by one or more management entities. Since different= security vendors support different features and functions on their devices= , I2NSF will focus on flow-based NSFs that provide treatment to packets/flo= ws, such as IPS/IDS, Web filtering, flow filtering, deep packet inspection,= or pattern matching and remediation. There are two layers of interfaces envisioned in the I2NSF approach: =95 I2NSF Capabilities Capability Layer =95 I2NSF Services Service Layer [MZ: I personally prefer =93Capabilities Layer=94 and =93Services Layer=94= or even =93Service Abstraction Layer.=94 But I=92ll go with what=92s entre= nched in the carrier space.] The I2NSF Capability Layer specifies the functional security policies, whic= h are translated from the entity defining the goal of the security policy i= nto a form that can be implemented, and are used to monitor and control the= behavior of NSFs. I2NSF will NOT standardize NSFs or devices. Instead, I2N= SF will onlystandardize only the controlling control and monitoring aspects= of the NSFs (not devices). An exemplar controlling of flow-based NSFs is = =93Subject =96 Object =96 Function =96 Action=94. [MZ]: The I2NSF Capability Layer specifies how to control and monitor NSFs= at an implementational level. (I2NSF will NOT work on any other aspects of= NSFs. Nor will I2NSF at this stage specify how to derive control and monit= oring capabilities from higher level security policies for the Capability L= ayer.) A sample Capability Layer construct for controlling NSFs is =93subje= ct-object-function-action=94. [MZ: I personally don=92t think we should add =93subject-object-function-ac= tion=94 in the charter. I=92ll defer to others on this.] The I2NSF Service Layer is for clients to express and monitor security poli= cies for their specific flows, which is usually based on application and cl= ient specific logical networks requirements and context. [MZ]: The I2NSF Service Layer defines how security policies may be expresse= d and monitored. The Service Layer is out of scope for this phase of I2NSF= =92s work. However, I2NSF will provide a forum for information drafts on da= ta models, APIs, etc. that demonstrate how service layer policies may be tr= anslated to Capability Layer functions. The concrete work at the I2NSF Capability Layer includes development of: - An information model that defines concepts required for standard= izing the controlling and monitoring of NSFs, - A set of YANG data models, derived from the above information mo= del, which enables the controlling and monitoring of virtual and/or physica= l NSFs, - The capability An IANA capabilities registry (IANA) that specifi= es the characteristics and behaviors of NSFs using a vendor-neutral vocabul= ary. enables the characteristics and behavior of NSFs to be specified using a ve= ndor-neutral vocabulary without requiring the NSFs themselves to be standar= dized; the registry enables various mechanisms, including policy rules, to = be used to match monitor and control functions to the needs of an applicati= on and/or environment, and - The proper secure communication channels to carry the controllin= g control and monitoring information between the NSFs and their management = entity (or entities). and the NSFs being controlled. Standard interfaces for monitoring and controlling the behavior of NSFs are= essential building blocks for Security Service Providers to automate the u= se of different NSFs from multiple vendors by their Security management ent= ities. This layer will leverage the existing protocols and data models defi= ned 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 data models, APIs, and/or RESTful inter= faces to clients and demonstrating the feasibility of them being translated= to the Capability Layer policies. [MZ: See above.] It is a non-goal not a goal of I2NSF to create new protocols or data modeli= ng languages for I2NSF interfaces. The I2NSF WG=92s deliverables include: - Use Cases document. - Framework Document. - Requirements for extensions (if there are any) to existing proto= cols used by the WG. - Gap analysis of existing protocols and modeling languages for sp= ecifying, querying, monitoring, and controlling NSFs. - A single, unified, Information Model for controlling and monitor= ing flow-based NSFs. - Corresponding YANG Data Models derived from the above Informatio= n Model. - IANA registry consideration for flow-based NSFs controlling and = monitoring capability capabilities. - (Optionally) Document describing how capabilities are used to mo= nitor and control flow-based NSFs. - (Optionally) Applicability Statements on how to use I2RS, Netcon= f, and NETMOD to carry the content of the specified information/data models= . [The WG may decide that the Use cases, Framework, and Requirements are Info= rmational documents or simply reference documents during the lifetime of th= e WG.] Suggested Milestones - Use Cases Document: Charter time + 1 month to WG Document - Framework: Charter time + 4 months to WG Document - Requirements for extensions to protocols: Charter time + 8 months to W= G document - Info model: Charter time + 8 months to WG Document - IANA registry consideration + 12 months to WG Document - All Early Drafts to IESG: 18 months [decision point =96 +10 months] - Data Models: Charter + 9 Months to WG Document - Applicability Statements: 10 months to WG Document - Data Models and Applicability Statements to IESG - 18 months The WG will work closely with I2RS, Netconf and Netmod WGs. The WG will com= municate with external SDOs like ETSI NFV and will encourage open source co= de development related to the WG scope in organizations like ONF, OpenStack= , ODL, and OpenNFV OPNFV. Cheers, Linda _______________________________________________ I2nsf mailing list I2nsf@ietf.org 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: diego.r.lopez@telefonica.com Tel: +34 913 129 041 Mobile: +34 682 051 091 ---------------------------------- ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o= copia sin autorizaci=F3n puede estar prohibida en virtud de la legislaci= =F3n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo = comunique inmediatamente por esta misma v=EDa y proceda a su destrucci=F3n. The information contained in this transmission is privileged and confidenti= al 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 co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, div= ulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o pode estar proibida em virtude= da legisla=E7=E3o vigente. Se recebeu esta mensagem por erro, rogamos-lhe = que nos o comunique imediatamente por esta mesma via e proceda a sua destru= i=E7=E3o --_000_DDECF571ACB843899F56ECCD7FE0D39Ctelefonicacom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <4FC55F2837163F468DD0F3BB9C8F6AF0@eurprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Hi,

I support Myo's changes, including the proposal of not adding the &quo= t;subject-object-function-action=94 in the charter.

Be goode,

On 19 May 2015, at 06:38 , Zarny, Myo <Myo.Zarny@gs.com> wrote:

Hi Linda,
 
Please see my comments/edits below= . (Just to clarify: I read that the Service Layer is out of scope, correct?= I don=92t see anything related to SL in the book of work. I=92ve tried to = make that clear.)
 
Myo
 
From:<= /span> I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Linda Dunb= ar
Sent: 18 May 2015 = 2:48 PM
To: i2= nsf@ietf.org
Cc: Romascanu, Dan= (Dan); Joseph Salowey; Kathleen Moriarty
Subject: [I2nsf] R= evised Narrower scoped I2NSF charter
 
Thanks to many people contributions to I2NSF charter. Here is the revised o= ne. Please provide comments and suggestions if your suggested changes haven= =92t been properly addressed.
 
 
 
Network security functions (NSFs) are provided and consume= d 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 of NSFs may offer their= customers network security services that consist of multiple security prod= ucts and/or functions from different vendors. NSFs may be provided by physi= cal and/or virtualized infrastructure. Without standard interfaces to express, monitor, and control security poli= cies that govern the behavior of NSFs, it becomes virtually impossible for = security service providers to automate their service offerings that utilize= different security functions from multiple vendors.
 
The primary goal of I2NSF is to define an information mode= l,  a set of software interfaces and data models for controlling and m= onitoring aspects of NSFs (both physical and virtual). Other aspects of NSF= s such as device or network provisioning and configuration are out of scope. Controlling and monitoring of NSFs sho= uld include the use of policies to specify, query, monitor, and control the= NSFs by one or more management entities. Since different security vendors support different features and functions on their devices= , I2NSF will focus on flow-ba= sed NSFs that provide treatment to packets/flows, such as IPS/IDS, Web filt= ering, flow filtering, deep packet inspection, or pattern matching and remediation.
 
There are two layers of interfaces envisioned in the I2NSF= approach:
=B7     &= nbsp;   = I2NSF&= nbsp;Capabilities Capability Layer
=B7     &= nbsp;   = I2NSF&= nbsp;Services Service=  Layer
[MZ:  I personally prefer =93= Capabilities Layer=94 and =93Services Layer=94 or even =93Service Abstracti= on Layer.=94 But I=92ll go with what=92s entrenched in the carrier space.]<= o:p>
 
The <= /span>I2NSF Capability Layer specifies the functional security policies, which are = translated from the entity defining the goal of the security policy into a form that can be implemented, and are used to monit= or and control the behavior of NSFs. I2NSF will NOT standardize NSFs or devices. Instead, I2NSF will onlystand= ardize only = ;the&n= bsp;controlling=  = control and monitoring aspects of the NSFs (not devices). An exemplar controlling of f= low-based NSFs is =93Subject =96 Object =96 Function =96 Action=94. 
 
[MZ]:  The I2NSF Capability Lay= er specifies how to control and monitor NSFs at an implementational level. = (I2NSF will NOT work on any other aspects of NSFs. Nor will I2NSF at this s= tage specify how to derive control and monitoring capabilities from higher level security policies for the Capabi= lity Layer.) A sample Capability Layer construct for controlling NSFs is = =93subject-object-function-action=94.
 
[MZ: I personally don=92t think we= should add =93subject-object-function-action=94 in the charter. I=92ll def= er to others on this.]
 
The I2NSF Service Layer is for clients to express and monitor security p= olicies for their specific flows, which is usually based on application and= client specific logical networks requirements and context.
[MZ]: The I2NSF Service Layer define= s how security policies may be expressed and monitored. The Service Layer i= s out of scope for this phase of I2NSF=92s work. However, I2NSF will provid= e a forum for information drafts on data models, APIs, etc. that demonstrate how service layer policies may be= translated to Capability Layer functions.
 
The concrete work at the I2NSF Capability Layer includes d= evelopment of:
-         = ; An= information model that defines concepts required for standardizing the controlling and monitoring of NSFs,
-         = ; A = set of YANG data models, derived from the above information model, which enables the controlling and monitoring of virtual a= nd/or physical NSFs,
-     = ;     The capability An IANA capabilities registry (IANA) that specifies the characteristics and behaviors of NSFs using a vendor-neutral vocabular= y.
enables the characteristics and b= ehavior of NSFs to be specified using a vendor-neutral vocabulary without r= equiring the NSFs themselves to be standardized; <= s>the registry enables various mechanisms, including policy rules, to be used to= match monitor and control functions to the needs of an application and/or = environment, and
-         = ; Th= e proper secure communication channels to carry the&= nbsp;controlling control <= /span>and monitoring information between = the NSFs and their managem= ent entity (or entities). and the NSFs being controlled.
 
Standard interfaces for monitoring and controlling the behavior of NSFs are= essential building blocks for Security Service Providers to automate the u= se of different NSFs from multiple vendors by their Security management ent= ities. This layer will leverage the existing protocols and data models defined by I2RS, Netconf, and NETMO= D.
 
For the I2NSF Service Layer, it i= s out of the scope for I2NSF (at least for now) to standardize the interfac= e facing clients. However, I2NSF can have informational drafts showing samp= le data models, APIs, and/or RESTful interfaces to clients and demonstrating the feasibility of them being tran= slated to the Capability Layer policies.
[MZ:  See above.]<= /span>
 
It is a non-goal not a goal of I2= NSF to create new protocols or data modeling languages for I2NSF interfaces.=
 
The I2NSF WG=92= s deliverables include:
 
-          Use Cases document.
-          Framework Document.
-          Requirements = ;for extensions (if there are any) to existing protocols used by the WG.
-          Gap analysis of existing p= rotocols and modeling languages for specifying, querying, monitoring, and controlling N= SFs.
-          A single, unified, Informa= tion Model for controlling and monitoring flow-based NSFs.
-          Corresponding YANG Data Mo= dels derived from the above Information Model.
-          IANA registry consideratio= n for flow-based NSFs controlling and monitoring = ;capability capabilities.
-          (Optionally) Document desc= ribing how capabilities are used to monitor and control flow-based NSFs.
-          (Optionally) Applicability= Statements on how to use I2RS, Netconf, and NETMOD to carry the content of the specif= ied information/data models.
 
[The WG may decide that the Use cases, Framework, and Requirements are Informational documents or simply reference documents during the lifetime of the WG.]
 
Suggested Milestones
  - Use Cases Document:  Charter time + = 1 month to WG Document
  - Framework: Charter time + 4 months to WG Document
  - Requirements for extensions to protocols:  Charter time += 8 months to WG document
  - Info model: Charter time + 8 months to WG Document<= /div>
  - IANA registry consideration + 12 months to WG Document
  - All Early Drafts to IESG: 18 months
 
[decision point =96 +10 months] 
  - Data Models: Charter + 9 Months to WG Document=
  - Applicability Statements: 10 months to WG Document
  - Data Models and Applicability Statements to IESG  - 18 months=
 
The WG will work closely with I2RS, Netconf and Netmod WGs. The WG will com= municate with external SDOs like ETSI NFV and will encourage open source co= de development related to the WG scope in organizations like ONF, OpenStack= , ODL, and OpenNFV OPNFV.
 
 
Cheers,
 
Linda
_______________________________________________
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2n= sf

--
"Esta vez no fallaremos, Doctor Infierno"

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

e-mail: diego.r.lopez@telefonica.com
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------



Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o copia sin autorizaci=F3n puede e= star prohibida en virtud de la legislaci=F3n vigente. Si ha recibido este m= ensaje por error, le rogamos que nos lo comunique inmediatamente por esta m= isma v=EDa y proceda a su destrucci=F3n.

The information contained in this transmission is privileged and confidenti= al 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 y= ou have received this transmission in error, do not read it. Please immedia= tely 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=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, divulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o p= ode estar proibida em virtude da legisla=E7=E3o vigente. Se recebeu esta me= nsagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mes= ma via e proceda a sua destrui=E7=E3o
 --_000_DDECF571ACB843899F56ECCD7FE0D39Ctelefonicacom_-- From nobody Wed May 20 09:17:17 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F6861A88B6 for ; Wed, 20 May 2015 09:17:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.811 X-Spam-Level: X-Spam-Status: No, score=-1.811 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MANY_SPAN_IN_TEXT=2.399, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9I2nldSoBgIy for ; Wed, 20 May 2015 09:17:09 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C62B81A1A00 for ; Wed, 20 May 2015 09:17:08 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BST77986; Wed, 20 May 2015 16:17:07 +0000 (GMT) Received: from DFWEML706-CHM.china.huawei.com (10.193.5.225) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 20 May 2015 17:17:06 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml706-chm ([10.193.5.225]) with mapi id 14.03.0158.001; Wed, 20 May 2015 09:16:57 -0700 From: Linda Dunbar To: "Zarny, Myo" , "'i2nsf@ietf.org'" Thread-Topic: Revised Narrower scoped I2NSF charter Thread-Index: AdCRmyiKiZeg0kFYSvW3DBEM9L/fbwABv3fQAF00wKA= Date: Wed, 20 May 2015 16:16:56 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657C451FA@dfweml701-chm> References: <4A95BA014132FF49AE685FAB4B9F17F657C2DC55@dfweml701-chm> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.233] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657C451FAdfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "'Romascanu, Dan \(Dan\)'" , 'Joseph Salowey' , 'Kathleen Moriarty' , Susan Hares Subject: Re: [I2nsf] Revised Narrower scoped I2NSF charter X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 16:17:16 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F657C451FAdfweml701chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Myo, Thanks for the wording change. Your wording: The I2NSF Capability Layer specifies how to control and monitor NSFs at an = implementational level. (I2NSF will NOT work on any other aspects of NSFs Is it Ok to say "The I2NSF Capability Layer specifies how to control and mo= nitor NSFs at interface level"? "Implementation level" can have very different connotation for engineers wh= o implement features on devices, many IETF participants are implementers. Thanks, Linda From: Zarny, Myo [mailto:Myo.Zarny@gs.com] Sent: Monday, May 18, 2015 5:39 PM To: Linda Dunbar; 'i2nsf@ietf.org' Cc: 'Romascanu, Dan (Dan)'; 'Joseph Salowey'; 'Kathleen Moriarty' Subject: RE: Revised Narrower scoped I2NSF charter Hi Linda, Please see my comments/edits below. (Just to clarify: I read that the Servi= ce Layer is out of scope, correct? I don't see anything related to SL in th= e book of work. I've tried to make that clear.) Myo From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: 18 May 2015 2:48 PM To: i2nsf@ietf.org Cc: Romascanu, Dan (Dan); Joseph Salowey; Kathleen Moriarty Subject: [I2nsf] Revised Narrower scoped I2NSF charter Thanks to many people contributions to I2NSF charter. Here is the revised o= ne. Please provide comments and suggestions if your suggested changes haven= 't been properly addressed. Network security functions (NSFs) are provided and consumed in increasingly= diverse environments. Users of NSFs could consume network security service= s hosted by one or more providers, which may be their own enterprise, servi= ce providers, or a combination of both. Likewise, service providers of NSFs= may offer their customers network security services that consist of multip= le security products and/or functions from different vendors. NSFs may be p= rovided by physical and/or virtualized infrastructure. Without standard int= erfaces to express, monitor, and control security policies that govern the = behavior of NSFs, it becomes virtually impossible for security service prov= iders to automate their service offerings that utilize different security f= unctions from multiple vendors. The primary goal of I2NSF is to define an information model, a set of soft= ware interfaces and data models for controlling and monitoring aspects of N= SFs (both physical and virtual). Other aspects of NSFs such as device or ne= twork provisioning and configuration are out of scope. Controlling and moni= toring of NSFs should include the use of policies to specify, query, monito= r, and control the NSFs by one or more management entities. Since different= security vendors support different features and functions on their devices= , I2NSF will focus on flow-based NSFs that provide treatment to packets/flo= ws, such as IPS/IDS, Web filtering, flow filtering, deep packet inspection,= or pattern matching and remediation. There are two layers of interfaces envisioned in the I2NSF approach: * I2NSF Capabilities Capability Layer * I2NSF Services Service Layer [MZ: I personally prefer "Capabilities Layer" and "Services Layer" or even= "Service Abstraction Layer." But I'll go with what's entrenched in the car= rier space.] The I2NSF Capability Layer specifies the functional security policies, whic= h are translated from the entity defining the goal of the security policy i= nto a form that can be implemented, and are used to monitor and control the= behavior of NSFs. I2NSF will NOT standardize NSFs or devices. Instead, I2N= SF will only standardize only the controlling control and monitoring aspect= s of the NSFs (not devices). An exemplar controlling of flow-based NSFs is = "Subject - Object - Function - Action". [MZ]: The I2NSF Capability Layer specifies how to control and monitor NSFs= at an implementational level. (I2NSF will NOT work on any other aspects of= NSFs. Nor will I2NSF at this stage specify how to derive control and monit= oring capabilities from higher level security policies for the Capability L= ayer.) A sample Capability Layer construct for controlling NSFs is "subject= -object-function-action". [MZ: I personally don't think we should add "subject-object-function-action= " in the charter. I'll defer to others on this.] The I2NSF Service Layer is for clients to express and monitor security poli= cies for their specific flows, which is usually based on application and cl= ient specific logical networks requirements and context. [MZ]: The I2NSF Service Layer defines how security policies may be expresse= d and monitored. The Service Layer is out of scope for this phase of I2NSF'= s work. However, I2NSF will provide a forum for information drafts on data = models, APIs, etc. that demonstrate how service layer policies may be trans= lated to Capability Layer functions. The concrete work at the I2NSF Capability Layer includes development of: - An information model that defines concepts required for standard= izing the controlling and monitoring of NSFs, - A set of YANG data models, derived from the above information mo= del, which enables the controlling and monitoring of virtual and/or physica= l NSFs, - The capability An IANA capabilities registry (IANA) that specifi= es the characteristics and behaviors of NSFs using a vendor-neutral vocabul= ary. enables the characteristics and behavior of NSFs to be specified using a ve= ndor-neutral vocabulary without requiring the NSFs themselves to be standar= dized; the registry enables various mechanisms, including policy rules, to = be used to match monitor and control functions to the needs of an applicati= on and/or environment, and - The proper secure communication channels to carry the controllin= g control and monitoring information between the NSFs and their management = entity (or entities). and the NSFs being controlled. Standard interfaces for monitoring and controlling the behavior of NSFs are= essential building blocks for Security Service Providers to automate the u= se of different NSFs from multiple vendors by their Security management ent= ities. This layer will leverage the existing protocols and data models defi= ned 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 data models, APIs, and/or RESTful inter= faces to clients and demonstrating the feasibility of them being translated= to the Capability Layer policies. [MZ: See above.] It is a non-goal not a goal of I2NSF to create new protocols or data modeli= ng languages for I2NSF interfaces. The I2NSF WG's deliverables include: - Use Cases document. - Framework Document. - Requirements for extensions (if there are any) to existing proto= cols used by the WG. - Gap analysis of existing protocols and modeling languages for sp= ecifying, querying, monitoring, and controlling NSFs. - A single, unified, Information Model for controlling and monitor= ing flow-based NSFs. - Corresponding YANG Data Models derived from the above Informatio= n Model. - IANA registry consideration for flow-based NSFs controlling and = monitoring capability capabilities. - (Optionally) Document describing how capabilities are used to mo= nitor and control flow-based NSFs. - (Optionally) Applicability Statements on how to use I2RS, Netcon= f, and NETMOD to carry the content of the specified information/data models= . [The WG may decide that the Use cases, Framework, and Requirements are Info= rmational documents or simply reference documents during the lifetime of th= e WG.] Suggested Milestones - Use Cases Document: Charter time + 1 month to WG Document - Framework: Charter time + 4 months to WG Document - Requirements for extensions to protocols: Charter time + 8 months to W= G document - Info model: Charter time + 8 months to WG Document - IANA registry consideration + 12 months to WG Document - All Early Drafts to IESG: 18 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 - 18 months The WG will work closely with I2RS, Netconf and Netmod WGs. The WG will com= municate with external SDOs like ETSI NFV and will encourage open source co= de development related to the WG scope in organizations like ONF, OpenStack= , ODL, and OpenNFV OPNFV. Cheers, Linda --_000_4A95BA014132FF49AE685FAB4B9F17F657C451FAdfweml701chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Myo,

 

Thanks for the wording= change.

 

Your wording:

The I2NSF Capability Layer specifies how to control and monitor NSFs a= t an implementational level. (I2NSF will NOT work on any other aspects of N= SFs

 

Is it Ok to say “= ;The I2NSF Capability Layer specifies ho= w to control and monitor NSFs at interface level”?

 

“Implementation = level” can have very different connotation for engineers who implemen= t features on devices, many IETF participants are implementers.

 

Thanks, Linda

 

From: Zarny, M= yo [mailto:Myo.Zarny@gs.com]
Sent: Monday, May 18, 2015 5:39 PM
To: Linda Dunbar; 'i2nsf@ietf.org'
Cc: 'Romascanu, Dan (Dan)'; 'Joseph Salowey'; 'Kathleen Moriarty' Subject: RE: Revised Narrower scoped I2NSF charter=

 

Hi Linda,

 

Please see my comments= /edits below. (Just to clarify: I read that the Service Layer is out of sco= pe, correct? I don’t see anything related to SL in the book of work. = I’ve tried to make that clear.)

 

Myo<= /p>

 

From: I2nsf [mailto:= i2nsf-bounces@ietf.org] On Behalf Of Linda Dunbar
Sent: 18 May 2015 2:48 PM
To: i2nsf@ietf.org
Cc: Romascanu, Dan (Dan); Joseph Salowey; Kathleen Moriarty
Subject: [I2nsf] Revised Narrower scoped I2NSF charter

 

Thanks to many people con= tributions to I2NSF charter. Here is the revised one. Please provide commen= ts and suggestions if your suggested changes haven’t been properly ad= dressed.

 

 

 

Network security functions (NSFs) are provided and consumed in increasin= gly diverse environments. Users of NSFs could consume network security serv= ices hosted by one or more providers, which may be their own enterprise, service providers, or a combination of = both. Likewise, service providers of NSFs may offer their customers network= security services that consist of multiple security products and/or functi= ons from different vendors. NSFs may be provided by physical and/or virtualized infrastructure. Without sta= ndard interfaces to express, monitor, and control security policies that go= vern the behavior of NSFs, it becomes virtually impossible for security ser= vice providers to automate their service offerings that utilize different security functions from multiple = vendors.

 

The primary goal of I2NSF is to define an information model,  a set= of software interfaces and data models for controlling and monitoring aspe= cts of NSFs (both physical and virtual). Other aspects of NSFs such as device or network provisioning and configuration a= re out of scope. Controlling and monitoring of NSFs should include the use = of policies to specify, query, monitor, and control the NSFs by one or more= management entities. Since different security vendors support different features and func= tions on their devices, I2NSF will focus on flow-based NSFs that provide treatment to packets/flows, such as IPS/= IDS, Web filtering, flow filtering, deep packet inspection, or pattern matching and remediation.

 

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

·       I2NSF = Capabilities Capability Layer

·       I2NSF = Services Service Layer

[MZ:  I personally prefer “Capabilities Layer” and &#= 8220;Services Layer” or even “Service Abstraction Layer.”= But I’ll go with what’s entrenched in the carrier space.]=

 

The I2NSF Capability Layer specifies the functional= security policies, which are translated from the entity defining the goal = of the security policy into a form that can be implemented, and are used to= monitor and control the behavior of NSFs. I2NSF will NOT standardize NSFs or devices. Instead, I2NSF will only standardize only the controlling control and monitoring aspects of the NSFs (not = devices). An exemplar controlling of flow-based NSFs is “Subject R= 11; Object – Function – Action”. 

 

[MZ]:  The I2NSF Capability Layer specifies how to control and mo= nitor NSFs at an implementational level. (I2NSF will NOT work on any other = aspects of NSFs. Nor will I2NSF at this stage specify how to derive control and monitoring capabilities from higher leve= l security policies for the Capability Layer.) A sample Capability Layer co= nstruct for controlling NSFs is “subject-object-function-action”= ;.

 

[MZ: I personally don’t think we should add “subject-objec= t-function-action” in the charter. I’ll defer to others on this= .]

 

The I2NSF Service Laye= r is for clients to express and monitor security policies for their specifi= c flows, which is usually based on application and client specific logical = networks requirements and context.=

[MZ]: The I2NSF Service Layer defines how security policies may be exp= ressed and monitored. The Service Layer is out of scope for this phase of I= 2NSF’s work. However, I2NSF will provide a forum for information drafts on data models, APIs, etc. that demonstrate= how service layer policies may be translated to Capability Layer functions= .

 

The concrete work at the = I2NSF Capability Layer includes development of:

-  &= nbsp;       An information model that defines concepts r= equired for standardizing the controlling<= /span> and monitoring of NSFs,

-  &= nbsp;       A set of YANG data models, derived from the = above information model, which enables the= controlling and monitoring of virtual and/or physical NSFs,

-  = ;        The capabil= ity An IANA capabilities registry (IANA) that specifies the characteristics and= behaviors of NSFs using a vendor-neutral vocabulary.

enables the characteristics and behavior of NSFs to be specified = using a vendor-neutral vocabulary without requiring the NSFs themselves to = be standardized; the registry enables various mechanisms, including policy rules, to be u= sed to match monitor and control functions to the needs of an application a= nd/or environment, and

-  &= nbsp;       The proper secure communication channels to = carry the controlling control and monitoring information between the= NSFs and their management entity (or ent= ities). and the NSFs being controlled. =

 

Standard interfaces for m= onitoring and controlling the behavior of NSFs are essential building block= s for Security Service Providers to automate the use of different NSFs from= multiple vendors by their Security management entities. This layer will leverage the existing protocols and d= ata models defined by I2RS, Netconf, and NETMOD.

 

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

[MZ:  See above.]

 

It is a non-goal not a goa= l of I2NSF to create new protocols or data modeling languages for I2NSF interfa= ces.

 

The I2NSF WG’s deliverables include:

 

-       = ;   Use Cases docu= ment.

-       = ;   Framework Document.

-       = ;   Requirements f= or extensions (if there are any) to existing protocols used by the WG.

-       = ;   Gap analysis of existing protocols and modeling lan= guages for specifying, querying, monitoring, and controlling NSFs.

-       = ;   A single, unified, Information Model for controllin= g and monitoring flow-based NSFs.

-       = ;   Corresponding YANG Data Models derived from the abo= ve Information Model.

-       = ;   IANA registry consideration for flow-based NSFs controlling and monitoring capability capabilities.

-       = ;   (Optionally) Document describing how capabilities a= re used to monitor and control flow-based NSFs.

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

 

[The WG may decide that the Use cases, Framework, and = Requirements are Informational documents or simply reference documents during the lifet= ime of the WG.]

 

Suggested Milestones=

  - Use Cases Document:  Charter time + 1 month t= o WG Document

  - Framework: Chart= er time + 4 months to WG Document

  - Requirements for= extensions to protocols:  Charter time + 8 months to WG document<= o:p>

  - Info model: Char= ter time + 8 months to WG Document

  - IANA registry co= nsideration + 12 months to WG Document

  - All Early Drafts= to IESG: 18 months

 

[decision point – &= #43;10 months] 

  - Data Models= : Charter + 9 Months to WG Document

  - Applicability St= atements: 10 months to WG Document

  - Data Models and = Applicability Statements to IESG  - 18 months

 

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

 

 

Cheers,

 

Linda

--_000_4A95BA014132FF49AE685FAB4B9F17F657C451FAdfweml701chm_-- From nobody Wed May 20 15:05:42 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E09BF1A92E3 for ; Wed, 20 May 2015 15:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5oVHmojXWo4b for ; Wed, 20 May 2015 15:05:40 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A77C1A92E2 for ; Wed, 20 May 2015 15:05:40 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BWI10168; Wed, 20 May 2015 22:05:38 +0000 (GMT) Received: from DFWEML704-CHM.china.huawei.com (10.193.5.141) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 20 May 2015 23:04:11 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml704-chm ([10.193.5.141]) with mapi id 14.03.0158.001; Wed, 20 May 2015 15:04:00 -0700 From: Linda Dunbar To: "'i2nsf@ietf.org'" Thread-Topic: what is the right definition for "flow-based security functions"? Thread-Index: AdCTSOAZAKP3vYkfS66+IVXr9x5X6A== Date: Wed, 20 May 2015 22:04:00 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657C45450@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.233] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657C45450dfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [I2nsf] what is the right definition for "flow-based security functions"? X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 22:05:42 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F657C45450dfweml701chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Do people agree on this definition for "flow-based security function"? "A security function that performs actions or invokes function calls for th= e communications between origination and termination entities." Thanks, Linda --_000_4A95BA014132FF49AE685FAB4B9F17F657C45450dfweml701chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Do people agree on this definition for “flow-b= ased security function”?

 

“A security function that performs actions or = invokes function calls for the communications between origination and termi= nation entities.”

 

Thanks, Linda

 

--_000_4A95BA014132FF49AE685FAB4B9F17F657C45450dfweml701chm_-- From nobody Wed May 20 19:33:38 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A2B21ACE76 for ; Wed, 20 May 2015 19:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.09 X-Spam-Level: X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HYg_bV66Gt5x for ; Wed, 20 May 2015 19:33:33 -0700 (PDT) Received: from smtptc.telefonica.com (smtptc.telefonica.com [195.76.34.108]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1255A1ACE78 for ; Wed, 20 May 2015 19:33:32 -0700 (PDT) Received: from smtptc.telefonica.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C80483703E8; Thu, 21 May 2015 04:33:29 +0200 (CEST) Received-SPF: PermError (tgtim3c01.telefonica.com: domain of diego.r.lopez@telefonica.com uses mechanism not recognized by this client) identity=MAILFROM; client-ip=10.92.4.9; envelope-from=diego.r.lopez@telefonica.com; helo=ESTGVMSP104.EUROPE.telefonica.corp) Received: from ESTGVMSP104.EUROPE.telefonica.corp (unknown [10.92.4.9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtptc.telefonica.com (Postfix) with ESMTPS id AD83B3703D4; Thu, 21 May 2015 04:33:29 +0200 (CEST) Received: from emea01-am1-obe.outbound.protection.outlook.com (10.92.5.139) by tls.telefonica.com (10.93.6.50) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 21 May 2015 04:33:28 +0200 Received: from DB4PR06MB0624.eurprd06.prod.outlook.com (25.161.13.142) by DB4PR06MB0624.eurprd06.prod.outlook.com (25.161.13.142) with Microsoft SMTP Server (TLS) id 15.1.166.22; Thu, 21 May 2015 02:33:28 +0000 Received: from DB4PR06MB0624.eurprd06.prod.outlook.com ([25.161.13.142]) by DB4PR06MB0624.eurprd06.prod.outlook.com ([25.161.13.142]) with mapi id 15.01.0166.017; Thu, 21 May 2015 02:33:28 +0000 From: DIEGO LOPEZ GARCIA To: Linda Dunbar Thread-Topic: [I2nsf] what is the right definition for "flow-based security functions"? Thread-Index: AdCTSOAZAKP3vYkfS66+IVXr9x5X6AAJafWA Date: Thu, 21 May 2015 02:33:27 +0000 Message-ID: References: <4A95BA014132FF49AE685FAB4B9F17F657C45450@dfweml701-chm> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657C45450@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=diego.r.lopez@telefonica.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [121.58.104.2] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB4PR06MB0624; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:DB4PR06MB0624; BCL:0; PCL:0; RULEID:; SRVR:DB4PR06MB0624; x-forefront-prvs: 0583A86C08 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(164054003)(199003)(252514010)(24454002)(189002)(4001540100001)(81156007)(97736004)(82746002)(5001960100002)(189998001)(110136002)(36756003)(105586002)(106356001)(2950100001)(16236675004)(2900100001)(19580405001)(19580395003)(102836002)(2420400003)(15975445007)(68736005)(7110500001)(19617315012)(83716003)(50986999)(76176999)(54356999)(33656002)(87936001)(62966003)(46102003)(77156002)(5001920100001)(5001860100001)(101416001)(64706001)(5001830100001)(66066001)(2656002)(122556002)(92566002)(40100003)(86362001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR06MB0624; H:DB4PR06MB0624.eurprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: telefonica.com does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_F643787617EA4824ABA9328C98400E48telefonicacom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 May 2015 02:33:27.3831 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR06MB0624 X-OriginatorOrg: telefonica.com X-TM-AS-MML: No Archived-At: Cc: "i2nsf@ietf.org" Subject: Re: [I2nsf] what is the right definition for "flow-based security functions"? X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 02:33:37 -0000 --_000_F643787617EA4824ABA9328C98400E48telefonicacom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hmmm, I'd prefer a more detailed definition, in the style of: "A function that manages network flows (sequences of packets from a source = node to a destination node characterized by specific parameters) according = to a policy intended for enforcing security properties" If the definition of a network flow is clear, we could omit what goes betw= een parenthesis... Be goode, On 21 May 2015, at 06:04 , Linda Dunbar > wrote: Do people agree on this definition for =93flow-based security function=94? =93A security function that performs actions or invokes function calls for = the communications between origination and termination entities.=94 Thanks, Linda _______________________________________________ I2nsf mailing list I2nsf@ietf.org 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: diego.r.lopez@telefonica.com Tel: +34 913 129 041 Mobile: +34 682 051 091 ---------------------------------- ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o= copia sin autorizaci=F3n puede estar prohibida en virtud de la legislaci= =F3n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo = comunique inmediatamente por esta misma v=EDa y proceda a su destrucci=F3n. The information contained in this transmission is privileged and confidenti= al 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 co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, div= ulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o pode estar proibida em virtude= da legisla=E7=E3o vigente. Se recebeu esta mensagem por erro, rogamos-lhe = que nos o comunique imediatamente por esta mesma via e proceda a sua destru= i=E7=E3o --_000_F643787617EA4824ABA9328C98400E48telefonicacom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <66C6595B59B91146A0E03E472504C145@eurprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Hmmm, I'd prefer a more detailed definition, in the style of:

"A function that manages network flows (sequences of packets from&= nbsp;a source node to a destination node character= ized by specific parameters) according to a policy intended for enforcing s= ecurity properties"
If the defi= nition of a network flow  is clear, we could omit what goes between pa= renthesis...

Be goode,
On 21 May 2015, at 06:04 , Linda Dunbar <linda.dunbar@huawei.com> wrote:

 
Do people agree on this definition for =93flow-based security function=94?<= o:p>
 
=93A security function that performs actions or invokes function calls for = the communications between origination and termination entities.=94
 
Thanks, Linda
 
_______________________________________________
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2n= sf

--
"Esta vez no fallaremos, Doctor Infierno"

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

e-mail: diego.r.lopez@telef= onica.com
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------



Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o copia sin autorizaci=F3n puede e= star prohibida en virtud de la legislaci=F3n vigente. Si ha recibido este m= ensaje por error, le rogamos que nos lo comunique inmediatamente por esta m= isma v=EDa y proceda a su destrucci=F3n.

The information contained in this transmission is privileged and confidenti= al 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 y= ou have received this transmission in error, do not read it. Please immedia= tely 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=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, divulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o p= ode estar proibida em virtude da legisla=E7=E3o vigente. Se recebeu esta me= nsagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mes= ma via e proceda a sua destrui=E7=E3o
 --_000_F643787617EA4824ABA9328C98400E48telefonicacom_-- From nobody Wed May 20 19:41:26 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA9EE1ACE89 for ; Wed, 20 May 2015 19:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k2kN0nJ7UlbW for ; Wed, 20 May 2015 19:41:20 -0700 (PDT) Received: from smtptc.telefonica.com (smtptc.telefonica.com [195.76.34.108]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A96DD1ACE36 for ; Wed, 20 May 2015 19:41:19 -0700 (PDT) Received: from smtptc.telefonica.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 6EE0C88076; Thu, 21 May 2015 04:41:17 +0200 (CEST) Received: from ESTGVMSP101.EUROPE.telefonica.corp (unknown [10.92.4.9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtptc.telefonica.com (Postfix) with ESMTPS id 5382F88074; Thu, 21 May 2015 04:41:17 +0200 (CEST) Received: from emea01-db3-obe.outbound.protection.outlook.com (10.92.5.139) by tls.telefonica.com (10.92.6.49) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 21 May 2015 04:41:16 +0200 Received: from DB4PR06MB0624.eurprd06.prod.outlook.com (25.161.13.142) by DB4PR06MB0623.eurprd06.prod.outlook.com (25.161.13.141) with Microsoft SMTP Server (TLS) id 15.1.166.22; Thu, 21 May 2015 02:41:15 +0000 Received: from DB4PR06MB0624.eurprd06.prod.outlook.com ([25.161.13.142]) by DB4PR06MB0624.eurprd06.prod.outlook.com ([25.161.13.142]) with mapi id 15.01.0166.017; Thu, 21 May 2015 02:41:15 +0000 From: DIEGO LOPEZ GARCIA To: Linda Dunbar Thread-Topic: [I2nsf] what is the right definition for "flow-based security functions"? Thread-Index: AdCTSOAZAKP3vYkfS66+IVXr9x5X6AAJr7KA Date: Thu, 21 May 2015 02:41:15 +0000 Message-ID: <0DDB3384-5964-40F3-AC77-89D277C60B5C@telefonica.com> References: <4A95BA014132FF49AE685FAB4B9F17F657C45450@dfweml701-chm> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657C45450@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=diego.r.lopez@telefonica.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [121.58.104.2] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB4PR06MB0623; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:DB4PR06MB0623; BCL:0; PCL:0; RULEID:; SRVR:DB4PR06MB0623; x-forefront-prvs: 0583A86C08 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(252514010)(199003)(189002)(164054003)(24454002)(106356001)(87936001)(19617315012)(16236675004)(2656002)(105586002)(81156007)(97736004)(101416001)(4001540100001)(64706001)(19580395003)(66066001)(36756003)(33656002)(86362001)(19580405001)(82746002)(122556002)(68736005)(83716003)(40100003)(46102003)(2420400003)(102836002)(15975445007)(2900100001)(2950100001)(92566002)(50986999)(189998001)(76176999)(54356999)(110136002)(5001830100001)(7110500001)(62966003)(5001860100001)(5001960100002)(77156002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR06MB0623; H:DB4PR06MB0624.eurprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: telefonica.com does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_0DDB3384596440F3AC7789D277C60B5Ctelefonicacom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 May 2015 02:41:15.4452 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR06MB0623 X-OriginatorOrg: telefonica.com X-TM-AS-MML: No Archived-At: Cc: "i2nsf@ietf.org" Subject: Re: [I2nsf] what is the right definition for "flow-based security functions"? X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 02:41:23 -0000 --_000_0DDB3384596440F3AC7789D277C60B5Ctelefonicacom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hmmm, I'd prefer a more detailed definition, in the style of: "A function that manages network flows (sequences of packets from a source = node to a destination node characterized by specific parameters) according = to a policy intended for enforcing security properties" If the definition of a network flow is clear, we could omit what goes betw= een parenthesis... Be goode, On 21 May 2015, at 06:04 , Linda Dunbar > wrote: Do people agree on this definition for =93flow-based security function=94? =93A security function that performs actions or invokes function calls for = the communications between origination and termination entities.=94 Thanks, Linda _______________________________________________ I2nsf mailing list I2nsf@ietf.org 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: diego.r.lopez@telefonica.com Tel: +34 913 129 041 Mobile: +34 682 051 091 ---------------------------------- ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o= copia sin autorizaci=F3n puede estar prohibida en virtud de la legislaci= =F3n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo = comunique inmediatamente por esta misma v=EDa y proceda a su destrucci=F3n. The information contained in this transmission is privileged and confidenti= al 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 co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, div= ulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o pode estar proibida em virtude= da legisla=E7=E3o vigente. Se recebeu esta mensagem por erro, rogamos-lhe = que nos o comunique imediatamente por esta mesma via e proceda a sua destru= i=E7=E3o --_000_0DDB3384596440F3AC7789D277C60B5Ctelefonicacom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <0B2A9DEAE3DD7748820A35EC184F10B5@eurprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Hmmm, I'd prefer a more detailed definition, in the style of:

"A function that manages network flows (sequences of packets from&= nbsp;a source node to a destination node character= ized by specific parameters) according to a policy intended for enforcing s= ecurity properties"
If the defi= nition of a network flow  is clear, we could omit what goes between pa= renthesis...

Be goode,
On 21 May 2015, at 06:04 , Linda Dunbar <linda.dunbar@huawei.com> wrote:

 
Do people agree on this definition for =93flow-based security function=94?<= o:p>
 
=93A security function that performs actions or invokes function calls for = the communications between origination and termination entities.=94
 
Thanks, Linda
 
_______________________________________________
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2n= sf

--
"Esta vez no fallaremos, Doctor Infierno"

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

e-mail: diego.r.lopez@telef= onica.com
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------



Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o copia sin autorizaci=F3n puede e= star prohibida en virtud de la legislaci=F3n vigente. Si ha recibido este m= ensaje por error, le rogamos que nos lo comunique inmediatamente por esta m= isma v=EDa y proceda a su destrucci=F3n.

The information contained in this transmission is privileged and confidenti= al 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 y= ou have received this transmission in error, do not read it. Please immedia= tely 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=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, divulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o p= ode estar proibida em virtude da legisla=E7=E3o vigente. Se recebeu esta me= nsagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mes= ma via e proceda a sua destrui=E7=E3o
 --_000_0DDB3384596440F3AC7789D277C60B5Ctelefonicacom_-- From nobody Thu May 21 04:05:08 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE6381ACDB9 for ; Thu, 21 May 2015 04:05:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xe706xIh0cGK for ; Thu, 21 May 2015 04:04:59 -0700 (PDT) Received: from smtp.fortinet.com (smtp.fortinet.com [208.91.113.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 045861ACD9A for ; Thu, 21 May 2015 04:04:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=fortinet.com; s=20131225; c=relaxed/relaxed; h=from:to:cc:subject:thread-topic:thread-index:date:message-id:references:in-reply-to:accept-language:content-language:x-ms-has-attach:x-ms-tnef-correlator:content-type:mime-version; bh=YUdbtTqvMJLIGXCaVSlDHsxyMDpjDpo9be/mkJ+bZ74=; b=fB3T1n7BoQfHmEFWgytTpia5L+U0LDXQU7HhhmUm0KNNF9Rw8jreXEm3VAQmK+yux5pIXheszN3Xu+GICXNF06vt2HObJ1d5ee7oUDkFGksm0B0WEUYdQn5sZJGZewKraSWEchPEr2ucdwdZvDKOUXl4hGz22vH9QkaFI81w980P0HiEc/hgMeJ96DxZ4q9TJ+/FOE7FggwcmNAHsELU/WG4Ny704SVlJTsLyJqfAYJxvRk4vJVDP+9TO0XvaMWwMCouSImKe3NEfqk6SQC+oqSzS1BtK2gBS53FDz1qZm3FGBLaDkeasVjps+YO7UBpLooB2CUB+d/Mz6UMt1mmhA== Received: from mail.fortinet.com ([192.168.221.214]) by smtp.fortinet.com with ESMTP id t4LB4tCX001021-t4LB4tCZ001021 (version=TLSv1.0 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 21 May 2015 04:04:55 -0700 Received: from FGT-EXCH-MBX211.fortinet-us.com ([192.168.221.211]) by FGT-EXCH-CAS214.fortinet-us.com ([192.168.221.214]) with mapi id 14.03.0224.002; Thu, 21 May 2015 04:04:54 -0700 From: Edward Lopez To: DIEGO LOPEZ GARCIA Thread-Topic: [I2nsf] what is the right definition for "flow-based security functions"? Thread-Index: AQHQk26NJSEzThimf0imN5BQjlYt0Z2GRRKg Date: Thu, 21 May 2015 11:04:54 +0000 Message-ID: References: <4A95BA014132FF49AE685FAB4B9F17F657C45450@dfweml701-chm>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_B24CA6643F2B4F7F9806651659399C9Efortinetcom_" MIME-Version: 1.0 Archived-At: Cc: "i2nsf@ietf.org" , Linda Dunbar Subject: Re: [I2nsf] what is the right definition for "flow-based security functions"? X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 11:05:07 -0000 --_000_B24CA6643F2B4F7F9806651659399C9Efortinetcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable In network security, flow-based security also means that packets are insp= ected in the order they are received, and without modification to the pac= ket due to the inspection process (MAC rewrites, TTL decrement action, ev= en NAT would be outside the inspection process). Proxy-based security functions can buffer, and defragment packets, as wel= l as perform content rewrites. Ed Lopez Sent from my iPhone ... Sorry for any auto-correct errors On May 20, 2015, at 10:33 PM, DIEGO LOPEZ GARCIA > wrote: Hmmm, I'd prefer a more detailed definition, in the style of: "A function that manages network flows (sequences of packets from a sourc= e node to a destination node characterized by specific parameters) accord= ing to a policy intended for enforcing security properties" If the definition of a network flow is clear, we could omit what goes be= tween parenthesis... Be goode, On 21 May 2015, at 06:04 , Linda Dunbar > wrote: Do people agree on this definition for =93flow-based security function=94= ? =93A security function that performs actions or invokes function calls fo= r the communications between origination and termination entities.=94 Thanks, Linda _______________________________________________ I2nsf mailing list I2nsf@ietf.org 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: diego.r.lopez@telefonica.com= Tel: +34 913 129 041 Mobile: +34 682 051 091 ---------------------------------- ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, = puede contener informaci=F3n privilegiada o confidencial y es para uso ex= clusivo de la persona o entidad de destino. Si no es usted. el destinatar= io indicado, queda notificado de que la lectura, utilizaci=F3n, divulgaci= =F3n y/o copia sin autorizaci=F3n puede estar prohibida en virtud de la l= egislaci=F3n vigente. Si ha recibido este mensaje por error, le rogamos q= ue nos lo comunique inmediatamente por esta misma v=EDa y proceda a su de= strucci=F3n. The information contained in this transmission is privileged and confiden= tial information intended only for the use of the individual or entity na= med above. If the reader of this message is not the intended recipient, y= ou are hereby notified that any dissemination, distribution or copying of= this communication is strictly prohibited. If you have received this tra= nsmission in error, do not read it. Please immediately reply to the sende= r that you have received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1r= io, pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para us= o exclusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria= o destinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3= o, divulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o pode estar proibida em= virtude da legisla=E7=E3o vigente. Se recebeu esta mensagem por erro, ro= gamos-lhe que nos o comunique imediatamente por esta mesma via e proceda = a sua destrui=E7=E3o _______________________________________________ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf *** Please note that this message and any attachments may contain confid= ential and proprietary material and information and are intended only for the us= e of the intended recipient(s). If you are not the intended recipient, you are= hereby notified that any review, use, disclosure, dissemination, distribution or= copying of this message and any attachments is strictly prohibited. If you have r= eceived this email in error, please immediately notify the sender and destroy thi= s e-mail and any attachments and all copies, whether electronic or printed. Please also note that any views, opinions, conclusions or commitments exp= ressed in this message are those of the individual sender and do not necessarily= reflect the views of Fortinet, Inc., its affiliates, and emails are not binding o= n Fortinet and only a writing manually signed by Fortinet's General Counsel= can be a binding commitment of Fortinet to Fortinet's customers or partners. Tha= nk you. *** --_000_B24CA6643F2B4F7F9806651659399C9Efortinetcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
In network security, flow-based security also means that packets are= inspected in the order they are received, and without modification to th= e packet due to the inspection process (MAC rewrites, TTL decrement actio= n, even NAT would be outside the inspection process).

Proxy-based security functions can buffer, and defragment packets, a= s well as perform content rewrites. 

Ed Lopez

Sent from my iPhone ... Sorry for any auto-correct errors

On May 20, 2015, at 10:33 PM, DIEGO LOPEZ GARCIA <diego.r.lopez@telefonica.com> wrote:
Hmmm, I'd prefer a more detailed definition, in the style of:

"A function that manages network flows (sequences of packets f= rom a source node to a destination node cha= racterized by specific parameters) according to a policy intended for enf= orcing security properties"
If the de= finition of a network flow  is clear, we could omit what goes betwee= n parenthesis...

Be goode,=

On 21 May 2015, at 06:04 , Linda Dunbar <linda.dunbar@huawei.com> wrote:

 
Do people agree on this definition for =93flow-based security function=94= ?
 
=93A security function that performs actions or invokes function calls fo= r the communications between origination and termination entities.=94
 
Thanks, Linda
 
_______________________________________________
I2nsf mailing list
I2nsf@ietf.org
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: diego.r.lopez@tel= efonica.com
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------



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

The information contained in this transmission is privileged and confiden= tial information intended only for the use of the individual or entity na= med above. If the reader of this message is not the intended recipient, y= ou 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 imm= ediately 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=E1r= io, pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para us= o exclusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria= o destinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, divulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o= pode estar proibida em virtude da legisla=E7=E3o vigente. Se recebeu est= a mensagem por erro, rogamos-lhe que nos o comunique imediatamente por es= ta mesma via e proceda a sua destrui=E7=E3o
_______________________________________________
I2nsf mailing list
I2nsf@ietf.org
https://www= .ietf.org/mailman/listinfo/i2nsf

*** Please note that this message and any attachments may contain confid= ential and proprietary material and information and are intended only for the us= e of the intended recipient(s). If you are not the intended recipient, you are= hereby notified that any review, use, disclosure, dissemination, distribution or= copying of this message and any attachments is strictly prohibited. If you have r= eceived this email in error, please immediately notify the sender and destroy thi= s e-mail and any attachments and all copies, whether electronic or printed. Please also note that any views, opinions, conclusions or commitments exp= ressed in this message are those of the individual sender and do not necessarily= reflect the views of Fortinet, Inc., its affiliates, and emails are not binding o= n Fortinet and only a writing manually signed by Fortinet's General Counsel= can be a binding commitment of Fortinet to Fortinet's customers or partners. Tha= nk you. ***
--_000_B24CA6643F2B4F7F9806651659399C9Efortinetcom_-- From nobody Thu May 21 06:36:13 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F7731AC3E4 for ; Thu, 21 May 2015 06:36:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.512 X-Spam-Level: X-Spam-Status: No, score=-4.512 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MANY_SPAN_IN_TEXT=2.399, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O79bIBT5d12z for ; Thu, 21 May 2015 06:36:03 -0700 (PDT) Received: from mxe02.gs.com (mxe02.gs.com [199.99.47.104]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1262B1A1B27 for ; Thu, 21 May 2015 06:36:01 -0700 (PDT) Received: from pps.filterd (gsppabdp02sd.idz.gs.com [127.0.0.1]) by gsppabdp02sd.idz.gs.com (8.14.5/8.14.5) with SMTP id t4LDWRa7014183; Thu, 21 May 2015 09:35:26 -0400 Received: from gsppacdp05nd.inz.gs.com ([10.205.68.213]) by gsppabdp02sd.idz.gs.com with ESMTP id 1uhfwg0kvn-1; Thu, 21 May 2015 09:35:26 -0400 Received: from pps.filterd (gsppacdp05nd.inz.gs.com [127.0.0.1]) by gsppacdp05nd.inz.gs.com (8.14.5/8.14.5) with SMTP id t4LDY3AU003468; Thu, 21 May 2015 09:35:15 -0400 Received: from gshcbdp13ex.firmwide.corp.gs.com (gshcbdp13ex.firmwide.corp.gs.com [10.135.172.22]) by gsppacdp05nd.inz.gs.com with ESMTP id 1uhg8dr2yy-1; Thu, 21 May 2015 09:35:15 -0400 Received: from GSCMAMP19EX.firmwide.corp.gs.com ([139.172.38.36]) by gshcbdp13ex.firmwide.corp.gs.com ([10.135.172.22]) with mapi; Thu, 21 May 2015 09:35:15 -0400 From: "Zarny, Myo" To: "'Linda Dunbar'" , "'i2nsf@ietf.org'" Date: Thu, 21 May 2015 09:35:13 -0400 Thread-Topic: Revised Narrower scoped I2NSF charter Thread-Index: AdCRmyiKiZeg0kFYSvW3DBEM9L/fbwABv3fQAF00wKAALL6acA== Message-ID: References: <4A95BA014132FF49AE685FAB4B9F17F657C2DC55@dfweml701-chm> <4A95BA014132FF49AE685FAB4B9F17F657C451FA@dfweml701-chm> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657C451FA@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-retentionstamp: Firmwide Content-Type: multipart/alternative; boundary="_000_A3233753A4B65F43BCA1B64DA99A9C230721AAC00EGSCMAMP19EXfi_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-05-21_05:2015-05-20,2015-05-21,1970-01-01 signatures=0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-05-21_05:2015-05-20,2015-05-21,1970-01-01 signatures=0 Archived-At: Cc: "'Romascanu, Dan \(Dan\)'" , 'Joseph Salowey' , 'Kathleen Moriarty' , 'Susan Hares' Subject: Re: [I2nsf] Revised Narrower scoped I2NSF charter X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 13:36:13 -0000 --_000_A3233753A4B65F43BCA1B64DA99A9C230721AAC00EGSCMAMP19EXfi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I see. I suppose "at an interface level" is fine if it's already a widely-u= nderstood/agreed-upon term by the majority of IETF participants/vendors. At= least to me, an enterprise user of technology, the term is vague; I suspec= t many others like me will find the same as well. You'll need to add a few = more sentences to explain what it means to people like me. How about "at a functional level"? If that doesn't work-say, because the te= rm "functional" already has some pre-established definition in the vendor s= pace-I'll defer to those from the vendor side to come up with a more precis= e term/language. Myo From: Linda Dunbar [mailto:linda.dunbar@huawei.com] Sent: 20 May 2015 12:17 PM To: Zarny, Myo [Tech]; 'i2nsf@ietf.org' Cc: 'Romascanu, Dan (Dan)'; 'Joseph Salowey'; 'Kathleen Moriarty'; Susan Ha= res Subject: RE: Revised Narrower scoped I2NSF charter Myo, Thanks for the wording change. Your wording: The I2NSF Capability Layer specifies how to control and monitor NSFs at an = implementational level. (I2NSF will NOT work on any other aspects of NSFs Is it Ok to say "The I2NSF Capability Layer specifies how to control and mo= nitor NSFs at interface level"? "Implementation level" can have very different connotation for engineers wh= o implement features on devices, many IETF participants are implementers. Thanks, Linda From: Zarny, Myo [mailto:Myo.Zarny@gs.com] Sent: Monday, May 18, 2015 5:39 PM To: Linda Dunbar; 'i2nsf@ietf.org' Cc: 'Romascanu, Dan (Dan)'; 'Joseph Salowey'; 'Kathleen Moriarty' Subject: RE: Revised Narrower scoped I2NSF charter Hi Linda, Please see my comments/edits below. (Just to clarify: I read that the Servi= ce Layer is out of scope, correct? I don't see anything related to SL in th= e book of work. I've tried to make that clear.) Myo From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: 18 May 2015 2:48 PM To: i2nsf@ietf.org Cc: Romascanu, Dan (Dan); Joseph Salowey; Kathleen Moriarty Subject: [I2nsf] Revised Narrower scoped I2NSF charter Thanks to many people contributions to I2NSF charter. Here is the revised o= ne. Please provide comments and suggestions if your suggested changes haven= 't been properly addressed. Network security functions (NSFs) are provided and consumed in increasingly= diverse environments. Users of NSFs could consume network security service= s hosted by one or more providers, which may be their own enterprise, servi= ce providers, or a combination of both. Likewise, service providers of NSFs= may offer their customers network security services that consist of multip= le security products and/or functions from different vendors. NSFs may be p= rovided by physical and/or virtualized infrastructure. Without standard int= erfaces to express, monitor, and control security policies that govern the = behavior of NSFs, it becomes virtually impossible for security service prov= iders to automate their service offerings that utilize different security f= unctions from multiple vendors. The primary goal of I2NSF is to define an information model, a set of soft= ware interfaces and data models for controlling and monitoring aspects of N= SFs (both physical and virtual). Other aspects of NSFs such as device or ne= twork provisioning and configuration are out of scope. Controlling and moni= toring of NSFs should include the use of policies to specify, query, monito= r, and control the NSFs by one or more management entities. Since different= security vendors support different features and functions on their devices= , I2NSF will focus on flow-based NSFs that provide treatment to packets/flo= ws, such as IPS/IDS, Web filtering, flow filtering, deep packet inspection,= or pattern matching and remediation. There are two layers of interfaces envisioned in the I2NSF approach: * I2NSF Capabilities Capability Layer * I2NSF Services Service Layer [MZ: I personally prefer "Capabilities Layer" and "Services Layer" or even= "Service Abstraction Layer." But I'll go with what's entrenched in the car= rier space.] The I2NSF Capability Layer specifies the functional security policies, whic= h are translated from the entity defining the goal of the security policy i= nto a form that can be implemented, and are used to monitor and control the= behavior of NSFs. I2NSF will NOT standardize NSFs or devices. Instead, I2N= SF will only standardize only the controlling control and monitoring aspect= s of the NSFs (not devices). An exemplar controlling of flow-based NSFs is = "Subject - Object - Function - Action". [MZ]: The I2NSF Capability Layer specifies how to control and monitor NSFs= at an implementational level. (I2NSF will NOT work on any other aspects of= NSFs. Nor will I2NSF at this stage specify how to derive control and monit= oring capabilities from higher level security policies for the Capability L= ayer.) A sample Capability Layer construct for controlling NSFs is "subject= -object-function-action". [MZ: I personally don't think we should add "subject-object-function-action= " in the charter. I'll defer to others on this.] The I2NSF Service Layer is for clients to express and monitor security poli= cies for their specific flows, which is usually based on application and cl= ient specific logical networks requirements and context. [MZ]: The I2NSF Service Layer defines how security policies may be expresse= d and monitored. The Service Layer is out of scope for this phase of I2NSF'= s work. However, I2NSF will provide a forum for information drafts on data = models, APIs, etc. that demonstrate how service layer policies may be trans= lated to Capability Layer functions. The concrete work at the I2NSF Capability Layer includes development of: - An information model that defines concepts required for standard= izing the controlling and monitoring of NSFs, - A set of YANG data models, derived from the above information mo= del, which enables the controlling and monitoring of virtual and/or physica= l NSFs, - The capability An IANA capabilities registry (IANA) that specifi= es the characteristics and behaviors of NSFs using a vendor-neutral vocabul= ary. enables the characteristics and behavior of NSFs to be specified using a ve= ndor-neutral vocabulary without requiring the NSFs themselves to be standar= dized; the registry enables various mechanisms, including policy rules, to = be used to match monitor and control functions to the needs of an applicati= on and/or environment, and - The proper secure communication channels to carry the controllin= g control and monitoring information between the NSFs and their management = entity (or entities). and the NSFs being controlled. Standard interfaces for monitoring and controlling the behavior of NSFs are= essential building blocks for Security Service Providers to automate the u= se of different NSFs from multiple vendors by their Security management ent= ities. This layer will leverage the existing protocols and data models defi= ned 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 data models, APIs, and/or RESTful inter= faces to clients and demonstrating the feasibility of them being translated= to the Capability Layer policies. [MZ: See above.] It is a non-goal not a goal of I2NSF to create new protocols or data modeli= ng languages for I2NSF interfaces. The I2NSF WG's deliverables include: - Use Cases document. - Framework Document. - Requirements for extensions (if there are any) to existing proto= cols used by the WG. - Gap analysis of existing protocols and modeling languages for sp= ecifying, querying, monitoring, and controlling NSFs. - A single, unified, Information Model for controlling and monitor= ing flow-based NSFs. - Corresponding YANG Data Models derived from the above Informatio= n Model. - IANA registry consideration for flow-based NSFs controlling and = monitoring capability capabilities. - (Optionally) Document describing how capabilities are used to mo= nitor and control flow-based NSFs. - (Optionally) Applicability Statements on how to use I2RS, Netcon= f, and NETMOD to carry the content of the specified information/data models= . [The WG may decide that the Use cases, Framework, and Requirements are Info= rmational documents or simply reference documents during the lifetime of th= e WG.] Suggested Milestones - Use Cases Document: Charter time + 1 month to WG Document - Framework: Charter time + 4 months to WG Document - Requirements for extensions to protocols: Charter time + 8 months to W= G document - Info model: Charter time + 8 months to WG Document - IANA registry consideration + 12 months to WG Document - All Early Drafts to IESG: 18 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 - 18 months The WG will work closely with I2RS, Netconf and Netmod WGs. The WG will com= municate with external SDOs like ETSI NFV and will encourage open source co= de development related to the WG scope in organizations like ONF, OpenStack= , ODL, and OpenNFV OPNFV. Cheers, Linda --_000_A3233753A4B65F43BCA1B64DA99A9C230721AAC00EGSCMAMP19EXfi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I see. I suppose “at an interface level” is fine = if it’s already a widely-understood/agreed-upon term by the majority = of IETF participants/vendors. At least to me, an enterprise user of technol= ogy, the term is vague; I suspect many others like me will find the same as= well. You’ll need to add a few more sentences to explain what it mea= ns to people like me.

 

How about “at a functional level”? If th= at doesn’t work—say, because the term “functional” = already has some pre-established definition in the vendor space—IR= 17;ll defer to those from the vendor side to come up with a more precise te= rm/language.

 

Myo

 

From: Linda Dunbar [mailto:linda.dunbar@huawei.= com]
Sent: 20 May 2015 12:17 PM
To: Zarny, Myo [Tech];= 'i2nsf@ietf.org'
Cc: 'Romascanu, Dan (Dan)'; 'Joseph Salowey'; '= Kathleen Moriarty'; Susan Hares
Subject: RE: Revised Narrower sco= ped I2NSF charter

 

Myo,

=

 

Thanks for the wording change.

 

Your wording:

The I2NSF Capability Layer specifies how to control and monitor N= SFs at an implementational level. (I2NSF will NOT work on any other aspects= of NSFs

 

Is it Ok t= o say “The I2NSF Capability Layer = specifies how to control and monitor NSFs = at interface level”?<= /span>

 

“Implementation levelR= 21; can have very different connotation for engineers who implement feature= s on devices, many IETF participants are implementers.

 

Thanks, Linda

<= o:p> 

From: Zarny, Myo [mailto:My= o.Zarny@gs.com]
Sent: Monday, May 18, 2015 5:39 PM
To:= Linda Dunbar; 'i2nsf@ietf.org'
Cc: 'Romascanu, Dan (Dan)'; '= Joseph Salowey'; 'Kathleen Moriarty'
Subject: RE: Revised Narrowe= r scoped I2NSF charter

 

Hi Linda,

 

Please see my comments/edits bel= ow. (Just to clarify: I read that the Service Layer is out of scope, correc= t? I don’t see anything related to SL in the book of work. I’ve= tried to make that clear.)

 

Myo

 

From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Beh= alf Of Linda Dunbar
Sent: 18 May 2015 2:48 PM
To: <= a href=3D"mailto:i2nsf@ietf.org">i2nsf@ietf.org
Cc: Romascanu= , Dan (Dan); Joseph Salowey; Kathleen Moriarty
Subject: [I2nsf] R= evised Narrower scoped I2NSF charter

 

Thanks to many people contribution= s to I2NSF charter. Here is the revised one. Please provide comments and su= ggestions if your suggested changes haven’t been properly addressed. =

 =

<= o:p> 

=  

Network security = functions (NSFs) are provided and consumed in increasingly diverse environm= ents. Users of NSFs could consume network security services hosted by one o= r more providers, which may be their own enterprise, service providers, or = a combination of both. Likewise, service providers of NSFs may offer their = customers network security services that consist of multiple security produ= cts and/or functions from different vendors. NSFs may be provided by physic= al and/or virtualized infrastructure. Without standard interfaces to expres= s, monitor, and control security policies that govern the behavior of NSFs,= it becomes virtually impossible for security service providers to automate= their service offerings that utilize different security functions from mul= tiple vendors.

 

The pr= imary goal of I2NSF is to define an information model,  a set of softw= are interfaces and data models for controlling and monitoring aspects of NS= Fs (both physical and virtual). Other aspects of NSFs such as device or net= work provisioning and configuration are out of scope. Controlling and monit= oring of NSFs should include the use of policies to specify, query, monitor= , and control the NSFs by one or more management entities. Since dif= ferent security vendors support different features and functions on their d= evices, I2NSF will focus on flow-based= NSFs that provide treatment to packets/flows, such as IPS/IDS, Web filteri= ng, flow filtering, deep packet inspection, or pattern matching and remedia= tion.

 

There are two layers o= f interfaces envisioned in the I2NSF approach:

·         I2NSF Capabilities= Capability Layer

·  =        I2NSF Services= Service Layer

<= p class=3DMsoNormal style=3D'margin-left:1.0in'>[MZ:  I personally prefer “Capabilities Layer” and R= 20;Services Layer” or even “Service Abstraction Layer.” B= ut I’ll go with what’s entrenched in the carrier space.]

 

The I2NSF Capa= bility Layer specifies the functional security = policies, which are translated from the entity defining the goal of the sec= urity policy into a form that can be implemented, and are used to monitor a= nd control the behavior of NSFs. I2NSF will NOT standardize NSFs or devices. I= nstead, I2NSF will only standardize only = the controlling control and monitoring aspects= of the NSFs (not devices). An exemplar controlling of flow-based NSFs is &= #8220;Subject – Object – Function – Action”.  =

<= span style=3D'color:#1F497D'> 

[MZ]:  Th= e I2NSF Capability Layer specifies how to control and monitor NSFs at an im= plementational level. (I2NSF will NOT work on any other aspects of NSFs. No= r will I2NSF at this stage specify how to derive control and monitoring cap= abilities from higher level security policies for the Capability Layer.) A = sample Capability Layer construct for controlling NSFs is “subject-ob= ject-function-action”.

 

[MZ: I personally don’t think we should add “subject= -object-function-action” in the charter. I’ll defer to others o= n this.]

 

The I2NSF Service Layer is for client= s to express and monitor security policies for their specific flows, which = is usually based on application and client specific logical networks requir= ements and context.

=

[MZ]: The I2NSF Service Layer defines how security policies may be expr= essed and monitored. The Service Layer is out of scope for this phase of I2= NSF’s work. However, I2NSF will provide a forum for information draft= s on data models, APIs, etc. that demonstrate how service layer policies ma= y be translated to Capability Layer functions.

 

Th= e concrete work at the I2NSF Capability Layer includes development of:<= /o:p>

-          An information model that defines concepts required f= or standardizing the controlling and monitoring of NSFs,

=

<= span style=3D'mso-list:Ignore'>-, which enables the controlling and m= onitoring of virtual and/or physical NSFs,

-&nbs= p;         The capability An IANA capabilities registry (IANA) that= specifies the characteristics and behaviors = of NSFs using a vendor-neutral vocabulary.

enables the characteristics and behavior = of NSFs to be specified using a vendor-neutral vocabulary without requiring= the NSFs themselves to be standardized; the registry enables various mechanisms, including policy rules, = to be used to match monitor and control functions to the needs of an applic= ation and/or environment, and

-   = ;       The pr= oper secure communication channels to carry the controlling control a= nd monitoring information between the NSFs an= d their management entity (or e= ntities). and the NSFs being controlled. =

 

Standard = interfaces for monitoring and controlling the behavior of NSFs are essentia= l building blocks for Security Service Providers to automate the use of dif= ferent NSFs from multiple vendors by their Security management entities. Th= is layer will leverage the existing protocols and data models defined by I2= RS, 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 sampl= e data models, APIs, and/or RESTful interfaces to clients and demonstrating= the feasibility of them being translated to the Capability Layer policies.=

[MZ:  See above.]

=

 

It is a non-goal not a goal of I2NSF to create new protocols or = data modeling languages for I2NSF interfaces.

 =

The I2NSF WG̵= 7;s deliverables include:

 

-          Use Cases document= .

- &n= bsp;        Fram= ework Document.

-          Requirements for extensions (i= f there are any) to existing protocols used by the WG.

-    &= nbsp;     Gap analysis of exist= ing protocols and modeling languages for specifying, querying, monitoring, = and controlling NSFs.

-          A single, unified, Information Model for controlling and moni= toring flow-based NSFs.

-          <= /span>Corresponding YANG Data Models derived from the above Infor= mation Model.

<= span style=3D'mso-list:Ignore'>--based NSFs controlling and monitoring capability capabilities.

-  &= nbsp;       (Optional= ly) Document describing how capabilities are used to monitor and control fl= ow-based NSFs.

= -[The WG may decide that the Use cases, Framework, and Requirements are = Informational documents or simply reference documents during the lifetime o= f the WG.]

 

Suggested Milestones

  - Use Cases Document:=   Charter time + 1 month to WG Document

  - Framework: Charter time + 4 month= s to WG Document

  - Requirements for extensions to protocols:  Charter time = + 8 months to WG document

  - Info model: Charter time + 8 months to WG Document

  - IANA= registry consideration + 12 months to WG Document

  - All Early Drafts to IESG:= 18 months

<= o:p> 

[decis= ion point – +10 months] 

  - Data Models: Charter + 9 Months to W= G Document

&= nbsp; - Applicability Statements: 10 months to WG Document

  - Data Models and App= licability Statements to IESG  - 18 months

 

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

 

 

Cheers,

 

Linda

= --_000_A3233753A4B65F43BCA1B64DA99A9C230721AAC00EGSCMAMP19EXfi_-- From nobody Thu May 21 09:46:30 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 445701A8956 for ; Thu, 21 May 2015 09:46:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.811 X-Spam-Level: X-Spam-Status: No, score=-1.811 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MANY_SPAN_IN_TEXT=2.399, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fWJ2Pf0P-vm5 for ; Thu, 21 May 2015 09:46:22 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 728411A8961 for ; Thu, 21 May 2015 09:46:21 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BSU89018; Thu, 21 May 2015 16:46:19 +0000 (GMT) Received: from DFWEML706-CHM.china.huawei.com (10.193.5.225) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 21 May 2015 17:46:17 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml706-chm ([10.193.5.225]) with mapi id 14.03.0158.001; Thu, 21 May 2015 09:46:06 -0700 From: Linda Dunbar To: "Zarny, Myo" , "'i2nsf@ietf.org'" Thread-Topic: Revised Narrower scoped I2NSF charter Thread-Index: AdCRmyiKiZeg0kFYSvW3DBEM9L/fbwABv3fQAF00wKAALL6acAAG3PKA Date: Thu, 21 May 2015 16:46:06 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657C46A8D@dfweml701-chm> References: <4A95BA014132FF49AE685FAB4B9F17F657C2DC55@dfweml701-chm> <4A95BA014132FF49AE685FAB4B9F17F657C451FA@dfweml701-chm> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.233] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657C46A8Ddfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "'Romascanu, Dan \(Dan\)'" , 'Joseph Salowey' , 'Kathleen Moriarty' , 'Susan Hares' Subject: Re: [I2nsf] Revised Narrower scoped I2NSF charter X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 16:46:29 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F657C46A8Ddfweml701chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Myo, Good suggestion. We will use "at functional level". "The I2NSF capability layer specifies how to control and monitor NSFs at fu= nctional level." Thanks, Linda From: Zarny, Myo [mailto:Myo.Zarny@gs.com] Sent: Thursday, May 21, 2015 8:35 AM To: Linda Dunbar; 'i2nsf@ietf.org' Cc: 'Romascanu, Dan (Dan)'; 'Joseph Salowey'; 'Kathleen Moriarty'; 'Susan H= ares' Subject: RE: Revised Narrower scoped I2NSF charter I see. I suppose "at an interface level" is fine if it's already a widely-u= nderstood/agreed-upon term by the majority of IETF participants/vendors. At= least to me, an enterprise user of technology, the term is vague; I suspec= t many others like me will find the same as well. You'll need to add a few = more sentences to explain what it means to people like me. How about "at a functional level"? If that doesn't work-say, because the te= rm "functional" already has some pre-established definition in the vendor s= pace-I'll defer to those from the vendor side to come up with a more precis= e term/language. Myo From: Linda Dunbar [mailto:linda.dunbar@huawei.com] Sent: 20 May 2015 12:17 PM To: Zarny, Myo [Tech]; 'i2nsf@ietf.org' Cc: 'Romascanu, Dan (Dan)'; 'Joseph Salowey'; 'Kathleen Moriarty'; Susan Ha= res Subject: RE: Revised Narrower scoped I2NSF charter Myo, Thanks for the wording change. Your wording: The I2NSF Capability Layer specifies how to control and monitor NSFs at an = implementational level. (I2NSF will NOT work on any other aspects of NSFs Is it Ok to say "The I2NSF Capability Layer specifies how to control and mo= nitor NSFs at interface level"? "Implementation level" can have very different connotation for engineers wh= o implement features on devices, many IETF participants are implementers. Thanks, Linda From: Zarny, Myo [mailto:Myo.Zarny@gs.com] Sent: Monday, May 18, 2015 5:39 PM To: Linda Dunbar; 'i2nsf@ietf.org' Cc: 'Romascanu, Dan (Dan)'; 'Joseph Salowey'; 'Kathleen Moriarty' Subject: RE: Revised Narrower scoped I2NSF charter Hi Linda, Please see my comments/edits below. (Just to clarify: I read that the Servi= ce Layer is out of scope, correct? I don't see anything related to SL in th= e book of work. I've tried to make that clear.) Myo From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: 18 May 2015 2:48 PM To: i2nsf@ietf.org Cc: Romascanu, Dan (Dan); Joseph Salowey; Kathleen Moriarty Subject: [I2nsf] Revised Narrower scoped I2NSF charter Thanks to many people contributions to I2NSF charter. Here is the revised o= ne. Please provide comments and suggestions if your suggested changes haven= 't been properly addressed. Network security functions (NSFs) are provided and consumed in increasingly= diverse environments. Users of NSFs could consume network security service= s hosted by one or more providers, which may be their own enterprise, servi= ce providers, or a combination of both. Likewise, service providers of NSFs= may offer their customers network security services that consist of multip= le security products and/or functions from different vendors. NSFs may be p= rovided by physical and/or virtualized infrastructure. Without standard int= erfaces to express, monitor, and control security policies that govern the = behavior of NSFs, it becomes virtually impossible for security service prov= iders to automate their service offerings that utilize different security f= unctions from multiple vendors. The primary goal of I2NSF is to define an information model, a set of soft= ware interfaces and data models for controlling and monitoring aspects of N= SFs (both physical and virtual). Other aspects of NSFs such as device or ne= twork provisioning and configuration are out of scope. Controlling and moni= toring of NSFs should include the use of policies to specify, query, monito= r, and control the NSFs by one or more management entities. Since different= security vendors support different features and functions on their devices= , I2NSF will focus on flow-based NSFs that provide treatment to packets/flo= ws, such as IPS/IDS, Web filtering, flow filtering, deep packet inspection,= or pattern matching and remediation. There are two layers of interfaces envisioned in the I2NSF approach: * I2NSF Capabilities Capability Layer * I2NSF Services Service Layer [MZ: I personally prefer "Capabilities Layer" and "Services Layer" or even= "Service Abstraction Layer." But I'll go with what's entrenched in the car= rier space.] The I2NSF Capability Layer specifies the functional security policies, whic= h are translated from the entity defining the goal of the security policy i= nto a form that can be implemented, and are used to monitor and control the= behavior of NSFs. I2NSF will NOT standardize NSFs or devices. Instead, I2N= SF will only standardize only the controlling control and monitoring aspect= s of the NSFs (not devices). An exemplar controlling of flow-based NSFs is = "Subject - Object - Function - Action". [MZ]: The I2NSF Capability Layer specifies how to control and monitor NSFs= at an implementational level. (I2NSF will NOT work on any other aspects of= NSFs. Nor will I2NSF at this stage specify how to derive control and monit= oring capabilities from higher level security policies for the Capability L= ayer.) A sample Capability Layer construct for controlling NSFs is "subject= -object-function-action". [MZ: I personally don't think we should add "subject-object-function-action= " in the charter. I'll defer to others on this.] The I2NSF Service Layer is for clients to express and monitor security poli= cies for their specific flows, which is usually based on application and cl= ient specific logical networks requirements and context. [MZ]: The I2NSF Service Layer defines how security policies may be expresse= d and monitored. The Service Layer is out of scope for this phase of I2NSF'= s work. However, I2NSF will provide a forum for information drafts on data = models, APIs, etc. that demonstrate how service layer policies may be trans= lated to Capability Layer functions. The concrete work at the I2NSF Capability Layer includes development of: - An information model that defines concepts required for standard= izing the controlling and monitoring of NSFs, - A set of YANG data models, derived from the above information mo= del, which enables the controlling and monitoring of virtual and/or physica= l NSFs, - The capability An IANA capabilities registry (IANA) that specifi= es the characteristics and behaviors of NSFs using a vendor-neutral vocabul= ary. enables the characteristics and behavior of NSFs to be specified using a ve= ndor-neutral vocabulary without requiring the NSFs themselves to be standar= dized; the registry enables various mechanisms, including policy rules, to = be used to match monitor and control functions to the needs of an applicati= on and/or environment, and - The proper secure communication channels to carry the controllin= g control and monitoring information between the NSFs and their management = entity (or entities). and the NSFs being controlled. Standard interfaces for monitoring and controlling the behavior of NSFs are= essential building blocks for Security Service Providers to automate the u= se of different NSFs from multiple vendors by their Security management ent= ities. This layer will leverage the existing protocols and data models defi= ned 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 data models, APIs, and/or RESTful inter= faces to clients and demonstrating the feasibility of them being translated= to the Capability Layer policies. [MZ: See above.] It is a non-goal not a goal of I2NSF to create new protocols or data modeli= ng languages for I2NSF interfaces. The I2NSF WG's deliverables include: - Use Cases document. - Framework Document. - Requirements for extensions (if there are any) to existing proto= cols used by the WG. - Gap analysis of existing protocols and modeling languages for sp= ecifying, querying, monitoring, and controlling NSFs. - A single, unified, Information Model for controlling and monitor= ing flow-based NSFs. - Corresponding YANG Data Models derived from the above Informatio= n Model. - IANA registry consideration for flow-based NSFs controlling and = monitoring capability capabilities. - (Optionally) Document describing how capabilities are used to mo= nitor and control flow-based NSFs. - (Optionally) Applicability Statements on how to use I2RS, Netcon= f, and NETMOD to carry the content of the specified information/data models= . [The WG may decide that the Use cases, Framework, and Requirements are Info= rmational documents or simply reference documents during the lifetime of th= e WG.] Suggested Milestones - Use Cases Document: Charter time + 1 month to WG Document - Framework: Charter time + 4 months to WG Document - Requirements for extensions to protocols: Charter time + 8 months to W= G document - Info model: Charter time + 8 months to WG Document - IANA registry consideration + 12 months to WG Document - All Early Drafts to IESG: 18 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 - 18 months The WG will work closely with I2RS, Netconf and Netmod WGs. The WG will com= municate with external SDOs like ETSI NFV and will encourage open source co= de development related to the WG scope in organizations like ONF, OpenStack= , ODL, and OpenNFV OPNFV. Cheers, Linda --_000_4A95BA014132FF49AE685FAB4B9F17F657C46A8Ddfweml701chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Myo,

Good suggestion. We wi= ll use “at functional level”.

 

“The I2NSF capabil= ity layer specifies how to control and monitor NSFs at functional level.= 221; 

 =

Thanks, Linda

 

From: Zarny, M= yo [mailto:Myo.Zarny@gs.com]
Sent: Thursday, May 21, 2015 8:35 AM
To: Linda Dunbar; 'i2nsf@ietf.org'
Cc: 'Romascanu, Dan (Dan)'; 'Joseph Salowey'; 'Kathleen Moriarty'; '= Susan Hares'
Subject: RE: Revised Narrower scoped I2NSF charter=

 

I see. I suppose ̶= 0;at an interface level” is fine if it’s already a widely-under= stood/agreed-upon term by the majority of IETF participants/vendors. At lea= st to me, an enterprise user of technology, the term is vague; I suspect many others like me will find the same as well. You’= ;ll need to add a few more sentences to explain what it means to people lik= e me.

 

How about “at a = functional level”? If that doesn’t work—say, because the = term “functional” already has some pre-established definition i= n the vendor space—I’ll defer to those from the vendor side to = come up with a more precise term/language.

 

Myo<= /p>

 

From: Linda Dunbar [mailto:linda.dunbar@huawei.com]
Sent: 20 May 2015 12:17 PM
To: Zarny, Myo [Tech]; 'i2nsf@ietf.org'
Cc: 'Romascanu, Dan (Dan)'; 'Joseph Salowey'; 'Kathleen Moriarty'; S= usan Hares
Subject: RE: Revised Narrower scoped I2NSF charter=

 

Myo,

 

Thanks for the wording change.

 

Your wording:

The I2NSF Capability Layer specifies how to control and monitor NSFs = at an implementational level. (I2NSF will NOT work on any other aspects of = NSFs

 

Is it Ok to say “The I2NSF Ca= pability Layer specifies how to control and monitor NSFs at interface level”?

 

“Implementation level” can have very different connotation= for engineers who implement features on devices, many IETF participants ar= e implementers.

 

Thanks, Linda

 

From: Zarny, Myo [mailto:M= yo.Zarny@gs.com]
Sent: Monday, May 18, 2015 5:39 PM
To: Linda Dunbar; 'i2nsf@ietf.org'
Cc: 'Romascanu, Dan (Dan)'; 'Joseph Salowey'; 'Kathleen Moriarty' Subject: RE: Revised Narrower scoped I2NSF charter=

 

Hi Linda,

 

Please see my comments/edits below. (Just to clarify: I read that the = Service Layer is out of scope, correct? I don’t see anything related = to SL in the book of work. I’ve tried to make that clear.)

 

Myo

 

From: I2nsf [mailto= :i2nsf-bounces@ietf.org] On Behalf Of Linda Dunbar
Sent: 18 May 2015 2:48 PM
To: i2nsf@ietf.org
Cc: Romascanu, Dan (Dan); Joseph Salowey; Kathleen Moriarty
Subject: [I2nsf] Revised Narrower scoped I2NSF charter

 

Thanks to many people co= ntributions to I2NSF charter. Here is the revised one. Please provide comme= nts and suggestions if your suggested changes haven’t been properly a= ddressed.

 

 

 

Network security functions (NSFs) are provided and consumed in increasi= ngly diverse environments. Users of NSFs could consume network security ser= vices hosted by one or more providers, which may be their own enterprise, service providers, or a combination of = both. Likewise, service providers of NSFs may offer their customers network= security services that consist of multiple security products and/or functi= ons from different vendors. NSFs may be provided by physical and/or virtualized infrastructure. Without sta= ndard interfaces to express, monitor, and control security policies that go= vern the behavior of NSFs, it becomes virtually impossible for security ser= vice providers to automate their service offerings that utilize different security functions from multiple = vendors.

 

The primary goal of I2NSF is to define an information model,  a se= t of software interfaces and data models for controlling and monitoring asp= ects of NSFs (both physical and virtual). Other aspects of NSFs such as device or network provisioning and configuration a= re out of scope. Controlling and monitoring of NSFs should include the use = of policies to specify, query, monitor, and control the NSFs by one or more= management entities. Since different security vendors support different features and func= tions on their devices, I2NSF will focus on flow-based NSFs that provide treatment to packets/flows, such as IPS/= IDS, Web filtering, flow filtering, deep packet inspection, or pattern matching and remediation.

 

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

·       I2NSF = Capabilities Capability Layer

·       I2NSF = Services Service Layer

[MZ:  I personally prefer “Capabilities Layer” and &= #8220;Services Layer” or even “Service Abstraction Layer.”= ; But I’ll go with what’s entrenched in the carrier space.]

 

The I2NSF Capability Layer specifies the functional= security policies, which are translated from the entity defining the goal = of the security policy into a form that can be implemented, and are used to= monitor and control the behavior of NSFs. I2NSF will NOT standardize NSFs or devices. Instead, I2NSF will only standardize only the controlling control and monitoring aspects of the NSFs (not = devices). An exemplar controlling of flow-based NSFs is “Subject R= 11; Object – Function – Action”. 

 

[MZ]:  The I2NSF Capability Layer specifies how to control and m= onitor NSFs at an implementational level. (I2NSF will NOT work on any other= aspects of NSFs. Nor will I2NSF at this stage specify how to derive control and monitoring capabilities from higher leve= l security policies for the Capability Layer.) A sample Capability Layer co= nstruct for controlling NSFs is “subject-object-function-action”= ;.

 

[MZ: I personally don’t think we should add “subject-obje= ct-function-action” in the charter. I’ll defer to others on thi= s.]

 

The I2NSF Service Lay= er is for clients to express and monitor security policies for their specif= ic flows, which is usually based on application and client specific logical= networks requirements and context.

[MZ]: The I2NSF Service Layer defines how security policies may be ex= pressed and monitored. The Service Layer is out of scope for this phase of = I2NSF’s work. However, I2NSF will provide a forum for information drafts on data models, APIs, etc. that demonstrate= how service layer policies may be translated to Capability Layer functions= .

 

The concrete work at the= I2NSF Capability Layer includes development of:

-  &= nbsp;       An information model that defines concepts r= equired for standardizing the controlling<= /span> and monitoring of NSFs,

-  &= nbsp;       A set of YANG data models, derived from the = above information model, which enables the= controlling and monitoring of virtual and/or physical NSFs,

-  = ;        The capabil= ity An IANA capabilities registry (IANA) that specifies the characteristics and= behaviors of NSFs using a vendor-neutral vocabulary.

enables the characteristics and behavior of NSFs to be specified = using a vendor-neutral vocabulary without requiring the NSFs themselves to = be standardized; the registry enables various mechanisms, including policy rules, to be u= sed to match monitor and control functions to the needs of an application a= nd/or environment, and

-  &= nbsp;       The proper secure communication channels to = carry the controlling control and monitoring information between the= NSFs and their management entity (or ent= ities). and the NSFs being controlled. =

 

Standard interfaces for = monitoring and controlling the behavior of NSFs are essential building bloc= ks for Security Service Providers to automate the use of different NSFs fro= m multiple vendors by their Security management entities. This layer will leverage the existing protocols and d= ata 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 data models, APIs, and/or RESTful interfaces to clients and demonst= rating the feasibility of them being translated to the Capability Layer pol= icies.

[MZ:  See above.]

 

It is a non-goal not a go= al of I2NSF to create new protocols or data modeling languages for I2NSF interfa= ces.

 

The I2NSF WG’s deliverables include:

 

-       = ;   Use Cases docu= ment.

-       = ;   Framework Document.

-       = ;   Requirements f= or extensions (if there are any) to existing protocols used by the WG.

-       = ;   Gap analysis of existing protocols and modeling lan= guages for specifying, querying, monitoring, and controlling NSFs.

-       = ;   A single, unified, Information Model for controllin= g and monitoring flow-based NSFs.

-       = ;   Corresponding YANG Data Models derived from the abo= ve Information Model.

-       = ;   IANA registry consideration for flow-based NSFs controlling and monitoring capability capabilities.

-       = ;   (Optionally) Document describing how capabilities a= re used to monitor and control flow-based NSFs.

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

 

[The WG may decide that the Use cases, Framework, and= Requirements are Informational documents or simply reference documents during the lifet= ime of the WG.]

 

Suggested Milestones

  - Use Cases Document:  Charter time + 1 month = to WG Document

  - Framework: Char= ter time + 4 months to WG Document

  - Requirements fo= r extensions to protocols:  Charter time + 8 months to WG document=

  - Info model: Cha= rter time + 8 months to WG Document

  - IANA registry c= onsideration + 12 months to WG Document

  - All Early Draft= s to IESG: 18 months

 

[decision point – = +10 months] 

  - Data Model= s: Charter + 9 Months to WG Document

  - Applicability S= tatements: 10 months to WG Document

  - Data Models and= Applicability Statements to IESG  - 18 months

 

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

 

 

Cheers,

 

Linda

--_000_4A95BA014132FF49AE685FAB4B9F17F657C46A8Ddfweml701chm_-- From nobody Thu May 21 10:01:15 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E1AE1A0063 for ; Thu, 21 May 2015 10:01:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tt3Zdi_KpKUC for ; Thu, 21 May 2015 10:01:10 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 487831A0056 for ; Thu, 21 May 2015 10:01:09 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BSU89943; Thu, 21 May 2015 17:01:07 +0000 (GMT) Received: from DFWEML704-CHM.china.huawei.com (10.193.5.141) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 21 May 2015 18:01:05 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml704-chm ([10.193.5.141]) with mapi id 14.03.0158.001; Thu, 21 May 2015 10:00:56 -0700 From: Linda Dunbar To: "'i2nsf@ietf.org'" Thread-Topic: Clean version of the narrower scoped I2NSF charter Thread-Index: AdCT57NeSF4gRyJcT1WxD+XVE/wsWw== Date: Thu, 21 May 2015 17:00:55 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657C46AD8@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.233] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657C46AD8dfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [I2nsf] Clean version of the narrower scoped I2NSF charter X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 17:01:14 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F657C46AD8dfweml701chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Network security functions (NSFs) are provided and consumed in increasingly= diverse environments. Users of NSFs could consume network security service= s hosted by one or more providers, which may be their own enterprise, servi= ce providers, or a combination of both. Likewise, service providers of NSFs= may offer their customers network security services that consist of multip= le security products and/or functions from different vendors. NSFs may be p= rovided by physical and/or virtualized infrastructure. Without standard int= erfaces to express, monitor, and control security policies that govern the = behavior of NSFs, it becomes virtually impossible for security service prov= iders to automate their service offerings that utilize different security f= unctions from multiple vendors. The primary goal of I2NSF is to define an information model, a set of soft= ware interfaces and data models for controlling and monitoring aspects of N= SFs (both physical and virtual). Other aspects of NSFs such as device or ne= twork provisioning and configuration are out of scope. Controlling and moni= toring of NSFs should include the use of policies to specify, query, monito= r, and control the NSFs by one or more management entities. Since different= security vendors support different features and functions on their devices= , I2NSF will focus on flow-based NSFs that provide treatment to packets/flo= ws, such as IPS/IDS, Web filtering, flow filtering, deep packet inspection,= or pattern matching and remediation. There are two layers of interfaces envisioned in the I2NSF approach: * I2NSF Capability Layer * I2NSF Service Layer The I2NSF capability layer specifies how to control and monitor NSFs at fun= ctional level. (I2NSF will NOT work on any other aspects of NSFs including= standardizing NSFs or devices. Nor will I2NSF at this stage specify how t= o derive control and monitoring capabilities from higher level security pol= icies for the Capability layer). I2NSF will only standardize the security = policies related to the control and monitoring of the NSFs. A sample capab= ility layer construct for controlling NSFs is "subject-object-function-acti= on". The I2NSF Service Layer defines how clients' security policies may be expre= ssed and monitored. The Service Layer is out of scope for this phase of I2N= SF's work. However, I2NSF will provide a forum for information drafts on da= ta models, APIs, etc. that demonstrate how service layer policies may be tr= anslated to Capability Layer functions. The concrete work at the I2NSF Capability Layer includes development of - An information model that defines concepts required for standard= izing the control and monitoring of NSFs, - A set of YANG data models, derived from the above information mo= del. - The capability registry (IANA) that enables the characteristics = and behavior of NSFs to be specified using a vendor-neutral vocabulary with= out requiring the NSFs themselves to be standardized; the registry enables = various mechanisms, including policy rules, to be used to match monitor and= control functions to the needs of an application and/or environment, and - The proper secure communication channels to carry the controllin= g and monitoring information between the NSFs and their management entity (= or entities). Standard interfaces for monitoring and controlling the behavior of NSFs ar= e essential building blocks for Security Service Providers to automate the = use of different NSFs from multiple vendors by their Security management en= tities. This layer will leverage the existing protocols and data models def= ined by I2RS, Netconf, and NETMOD. It is a non-goal to create new protocols or data modeling languages for I2N= SF interfaces. The I2NSF WG's deliverables include: - Use Cases document. - Framework Document. - Requirements for extensions (if any) to existing protocols used = by the WG. - Gap analysis of existing protocols and modeling languages for s= pecifying, querying, monitoring, and controlling NSFs. - A single, unified, Information Model for controlling and monitor= ing flow-based NSFs. - Corresponding YANG Data Models derived from the above Informatio= n Model. - IANA registry consideration for flow-based NSFs controlling and = monitoring capabilities. - (Optionally) Document describing how capabilities are used to mo= nitor and control flow-based NSFs. - (Optionally) Applicability Statements on how to use I2RS, Netcon= f, and NETMOD to carry the content of the specified information/data models= . [The WG may decide that the Use cases, Framework, and Requirement are Infor= mational documents or simply reference documents during the lifetime of the= WG.] Suggested Milestones - Use Cases Document: Charter time + 1 month to WG Document - Framework: Charter time + 4 months to WG Document - Requirements for extensions to protocols: Charter time + 8 months to W= G document - Info model: Charter time + 8 months to WG Document - IANA registry consideration + 12 months to WG Document - All Early Drafts to IESG: 18 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 - 18 months The WG will work closely with I2RS, Netconf and Netmod WGs. The WG will com= municate with external SDOs like ETSI NFV and will encourage open source co= de development related to the WG scope in organizations like ONF, OpenStack= , ODL, and OPNFV. --_000_4A95BA014132FF49AE685FAB4B9F17F657C46AD8dfweml701chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Network security functio= ns (NSFs) are provided and consumed in increasingly diverse environments. U= sers 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 o= f NSFs may offer their customers network security services that consist of = multiple security products and/or functions from different vendors. NSFs ma= y be provided by physical and/or virtualized infrastructure. Without standard interfaces to express, monito= r, and control security policies that govern the behavior of NSFs, it becom= es virtually impossible for security service providers to automate their se= rvice offerings that utilize different security functions from multiple vendors.

 =

The primary goal of I2NS= F is to define an information model,  a set of software interfaces and= data models for controlling and monitoring aspects of NSFs (both physical = and virtual). Other aspects of NSFs such as device or network provisioning and configuration are out of scope. Cont= rolling and monitoring of NSFs should include the use of policies to specif= y, query, monitor, and control the NSFs by one or more management entities. Since different security vendors support different features and func= tions on their devices, I2NSF will focus on flow-based NSFs that provide tr= eatment to packets/flows, such as IPS/IDS, Web filtering, flow filtering, d= eep packet inspection, or pattern matching and remediation.

 =

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

·       I2NSF Capability= Layer

·       I2NSF Service La= yer

 =

The I2NSF capability lay= er specifies how to control and monitor NSFs at functional level.  (I2= NSF will NOT work on any other aspects of NSFs including standardizing NSFs= or devices.  Nor will I2NSF at this stage specify how to derive control and monitoring capabilities from higher leve= l security policies for the Capability layer).  I2NSF will only standa= rdize the security policies related to the control and monitoring of the NS= Fs.  A sample capability layer construct for controlling NSFs is “subject-object-function-action”.

 =

The I2NSF Service Layer = defines how clients’ security policies may be expressed and monitored= . The Service Layer is out of scope for this phase of I2NSF’s work. H= owever, I2NSF will provide a forum for information drafts on data models, APIs, etc. that demonstrate how service layer polic= ies may be translated to Capability Layer functions.

 

The concrete work at the I2NSF Capability Layer incl= udes development of

-  &= nbsp;       An information model that defines concepts r= equired for standardizing the control  and monitoring of NSFs,

-  &= nbsp;       A set of YANG data models, derived from the = above information model.

-  &= nbsp;       The capability registry (IANA) that enables = the characteristics and behavior of NSFs to be specified using a vendor-neu= tral vocabulary without requiring the NSFs themselves to be standardized; t= he registry enables various mechanisms, including policy rules, to be used to match monitor and control functions = to the needs of an application and/or environment, and

-  &= nbsp;       The proper secure communication channels to = carry the controlling and monitoring information between the NSFs and their= management entity (or entities).

 

 Standard interfaces for monitoring and control= ling the behavior of NSFs are essential building blocks for Security Servic= e Providers to automate the use of different NSFs from multiple vendors by = their Security management entities. This layer will leverage the existing protocols and data models defined by I2RS= , Netconf, and NETMOD.

 

It is a non-goal to create new protocols or data mod= eling languages for I2NSF interfaces.

The I2NSF WG’s deliverables include:

 

-       = ;   Use Cases document.

-       = ;   Framework Document.

-       = ;   Requirements for extensions (if any) to existing pr= otocols used by the WG.

-       = ;    Gap analysis of existing protocols and modeli= ng languages for specifying, querying, monitoring, and controlling NSFs.

-       = ;   A single, unified, Information Model for controllin= g and monitoring flow-based NSFs.

-       = ;   Corresponding YANG Data Models derived from the abo= ve Information Model.

-       = ;   IANA registry consideration for flow-based NSFs con= trolling and monitoring capabilities.

-       = ;   (Optionally) Document describing how capabilities a= re used to monitor and control flow-based NSFs.

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

 

[The W= G may decide that the Use cases, Framework, and Requirement are Information= al documents or simply reference documents during the lifetime of the WG.]

 

Suggested Milestones

  - Use Cases Document:  Charter time += ; 1 month to WG Document

  - Framework: Charter time + 4 months to W= G Document

  - Requirements for extensions to protocols:&n= bsp; Charter time + 8 months to WG document

  - Info model: Charter time + 8 months to = WG Document

  - IANA registry consideration + 12 months= to WG Document

  - All Early Drafts to IESG: 18 months

 

[decision point – +10 months]  <= /o:p>

  - Data Models: Charter + 9 Months to= WG Document

  - Applicability Statements: 10 months to WG D= ocument

  - Data Models and Applicability Statements to= IESG  - 18 months

 

The WG will work closely with I2RS, Netconf and Netm= od WGs. The WG will communicate with external SDOs like ETSI NFV and will e= ncourage open source code development related to the WG scope in organizati= ons like ONF, OpenStack, ODL, and OPNFV.

 

--_000_4A95BA014132FF49AE685FAB4B9F17F657C46AD8dfweml701chm_-- From nobody Thu May 21 10:30:29 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A61E61A00BE for ; Thu, 21 May 2015 10:30:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.81 X-Spam-Level: X-Spam-Status: No, score=-2.81 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2dcw6pv8zYbV for ; Thu, 21 May 2015 10:30:26 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18EC51A0121 for ; Thu, 21 May 2015 10:30:16 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BSU91621; Thu, 21 May 2015 17:30:15 +0000 (GMT) Received: from DFWEML703-CHM.china.huawei.com (10.193.5.130) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 21 May 2015 18:30:14 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml703-chm ([10.193.5.130]) with mapi id 14.03.0158.001; Thu, 21 May 2015 10:30:04 -0700 From: Linda Dunbar To: "'i2nsf@ietf.org'" Thread-Topic: Definition for "Network Security Functions" Thread-Index: AdCT68W6aC/heUYRRaG527iXhQCbpw== Date: Thu, 21 May 2015 17:30:04 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657C46B24@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.233] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657C46B24dfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [I2nsf] Definition for "Network Security Functions" X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 17:30:27 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F657C46B24dfweml701chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Anyone object using this definition for "Network Security Functions"? "functions to ensure the communications in and out of network as well as to= deter and detect the unwanted communication from negatively impacting the = network and its attached entities." Thanks, Linda --_000_4A95BA014132FF49AE685FAB4B9F17F657C46B24dfweml701chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Anyone object using this definition for “Netwo= rk Security Functions”?

 

“functions to ensur= e the communications in and out of network as well as to deter and detect t= he unwanted communication from negatively impacting the network and its att= ached entities.”

 

Thanks,

 

Linda=

 

--_000_4A95BA014132FF49AE685FAB4B9F17F657C46B24dfweml701chm_-- From nobody Thu May 21 10:35:44 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4645A1A0046 for ; Thu, 21 May 2015 10:35:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g22s4r6d-tkP for ; Thu, 21 May 2015 10:35:38 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFEFE1A0019 for ; Thu, 21 May 2015 10:35:37 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEGAOEWXlWHCzIm/2dsb2JhbABcgkUhKlReBrEDAQEBAQEBBplWAoFKTAEBAQEBAYELhCIBAQEBAxIbRxUCAQgNBAQBAQsWBwcyFAkIAQEEARIIGogKAaNPrmUBAQEBAQEBAwEBAQEBAQEBAQEBF4YWhCKBAoRUNwGDF4EWBZA+gjyTDY8XI4N4b4FGgQEBAQE X-IronPort-AV: E=Sophos;i="5.13,470,1427774400"; d="scan'208,217";a="121673173" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 21 May 2015 13:35:35 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 21 May 2015 13:35:34 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.03.0174.001; Thu, 21 May 2015 19:35:33 +0200 From: "Romascanu, Dan (Dan)" To: Linda Dunbar , "'i2nsf@ietf.org'" Thread-Topic: Clean version of the narrower scoped I2NSF charter Thread-Index: AdCT57NeSF4gRyJcT1WxD+XVE/wsWwABGH1w Date: Thu, 21 May 2015 17:35:33 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5CA369D5@AZ-FFEXMB04.global.avaya.com> References: <4A95BA014132FF49AE685FAB4B9F17F657C46AD8@dfweml701-chm> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657C46AD8@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.47] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA5CA369D5AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: Subject: Re: [I2nsf] Clean version of the narrower scoped I2NSF charter X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 17:35:43 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5CA369D5AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This looks good to me. One thing based on a comment made by Kathleen earlier in the process. The I= ESG is not very sympathetic nowadays on the WGs spending resources on progr= essing use cases documents to RFC. Same applies I think to the gap analysis= , which is more a help tool while we define the scope of work. Maybe it's b= etter to mark those deliverables in brackets with the note (the WG will dec= ide if to proceed as RFC). Thanks for progressing this, Linda! Regards, Dan From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Thursday, May 21, 2015 8:01 PM To: 'i2nsf@ietf.org' Subject: [I2nsf] Clean version of the narrower scoped I2NSF charter Network security functions (NSFs) are provided and consumed in increasingly= diverse environments. Users of NSFs could consume network security service= s hosted by one or more providers, which may be their own enterprise, servi= ce providers, or a combination of both. Likewise, service providers of NSFs= may offer their customers network security services that consist of multip= le security products and/or functions from different vendors. NSFs may be p= rovided by physical and/or virtualized infrastructure. Without standard int= erfaces to express, monitor, and control security policies that govern the = behavior of NSFs, it becomes virtually impossible for security service prov= iders to automate their service offerings that utilize different security f= unctions from multiple vendors. The primary goal of I2NSF is to define an information model, a set of soft= ware interfaces and data models for controlling and monitoring aspects of N= SFs (both physical and virtual). Other aspects of NSFs such as device or ne= twork provisioning and configuration are out of scope. Controlling and moni= toring of NSFs should include the use of policies to specify, query, monito= r, and control the NSFs by one or more management entities. Since different= security vendors support different features and functions on their devices= , I2NSF will focus on flow-based NSFs that provide treatment to packets/flo= ws, such as IPS/IDS, Web filtering, flow filtering, deep packet inspection,= or pattern matching and remediation. There are two layers of interfaces envisioned in the I2NSF approach: * I2NSF Capability Layer * I2NSF Service Layer The I2NSF capability layer specifies how to control and monitor NSFs at fun= ctional level. (I2NSF will NOT work on any other aspects of NSFs including= standardizing NSFs or devices. Nor will I2NSF at this stage specify how t= o derive control and monitoring capabilities from higher level security pol= icies for the Capability layer). I2NSF will only standardize the security = policies related to the control and monitoring of the NSFs. A sample capab= ility layer construct for controlling NSFs is "subject-object-function-acti= on". The I2NSF Service Layer defines how clients' security policies may be expre= ssed and monitored. The Service Layer is out of scope for this phase of I2N= SF's work. However, I2NSF will provide a forum for information drafts on da= ta models, APIs, etc. that demonstrate how service layer policies may be tr= anslated to Capability Layer functions. The concrete work at the I2NSF Capability Layer includes development of - An information model that defines concepts required for standard= izing the control and monitoring of NSFs, - A set of YANG data models, derived from the above information mo= del. - The capability registry (IANA) that enables the characteristics = and behavior of NSFs to be specified using a vendor-neutral vocabulary with= out requiring the NSFs themselves to be standardized; the registry enables = various mechanisms, including policy rules, to be used to match monitor and= control functions to the needs of an application and/or environment, and - The proper secure communication channels to carry the controllin= g and monitoring information between the NSFs and their management entity (= or entities). Standard interfaces for monitoring and controlling the behavior of NSFs ar= e essential building blocks for Security Service Providers to automate the = use of different NSFs from multiple vendors by their Security management en= tities. This layer will leverage the existing protocols and data models def= ined by I2RS, Netconf, and NETMOD. It is a non-goal to create new protocols or data modeling languages for I2N= SF interfaces. The I2NSF WG's deliverables include: - Use Cases document. - Framework Document. - Requirements for extensions (if any) to existing protocols used = by the WG. - Gap analysis of existing protocols and modeling languages for s= pecifying, querying, monitoring, and controlling NSFs. - A single, unified, Information Model for controlling and monitor= ing flow-based NSFs. - Corresponding YANG Data Models derived from the above Informatio= n Model. - IANA registry consideration for flow-based NSFs controlling and = monitoring capabilities. - (Optionally) Document describing how capabilities are used to mo= nitor and control flow-based NSFs. - (Optionally) Applicability Statements on how to use I2RS, Netcon= f, and NETMOD to carry the content of the specified information/data models= . [The WG may decide that the Use cases, Framework, and Requirement are Infor= mational documents or simply reference documents during the lifetime of the= WG.] Suggested Milestones - Use Cases Document: Charter time + 1 month to WG Document - Framework: Charter time + 4 months to WG Document - Requirements for extensions to protocols: Charter time + 8 months to W= G document - Info model: Charter time + 8 months to WG Document - IANA registry consideration + 12 months to WG Document - All Early Drafts to IESG: 18 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 - 18 months The WG will work closely with I2RS, Netconf and Netmod WGs. The WG will com= municate with external SDOs like ETSI NFV and will encourage open source co= de development related to the WG scope in organizations like ONF, OpenStack= , ODL, and OPNFV. --_000_9904FB1B0159DA42B0B887B7FA8119CA5CA369D5AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This looks good to me.=

 

One thing based on a c= omment made by Kathleen earlier in the process. The IESG is not very sympat= hetic nowadays on the WGs spending resources on progressing use cases docum= ents to RFC. Same applies I think to the gap analysis, which is more a help tool while we define the scope of w= ork. Maybe it’s better to mark those deliverables in brackets with th= e note (the WG will decide if to proceed as RFC).

 

Thanks for progressing= this, Linda!

 

Regards,

 

Dan<= /p>

 

From: I2nsf [m= ailto:i2nsf-bounces@ietf.org] On Behalf Of Linda Dunbar
Sent: Thursday, May 21, 2015 8:01 PM
To: 'i2nsf@ietf.org'
Subject: [I2nsf] Clean version of the narrower scoped I2NSF charter<= o:p>

 

 

Network security functio= ns (NSFs) are provided and consumed in increasingly diverse environments. U= sers 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 o= f NSFs may offer their customers network security services that consist of = multiple security products and/or functions from different vendors. NSFs ma= y be provided by physical and/or virtualized infrastructure. Without standard interfaces to express, monito= r, and control security policies that govern the behavior of NSFs, it becom= es virtually impossible for security service providers to automate their se= rvice offerings that utilize different security functions from multiple vendors.

 =

The primary goal of I2NS= F is to define an information model,  a set of software interfaces and= data models for controlling and monitoring aspects of NSFs (both physical = and virtual). Other aspects of NSFs such as device or network provisioning and configuration are out of scope. Cont= rolling and monitoring of NSFs should include the use of policies to specif= y, query, monitor, and control the NSFs by one or more management entities. Since different security vendors support different features and func= tions on their devices, I2NSF will focus on flow-based NSFs that provide tr= eatment to packets/flows, such as IPS/IDS, Web filtering, flow filtering, d= eep packet inspection, or pattern matching and remediation.

 =

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

·         I2NSF Capability Layer

·         I2NSF Service Layer

 =

The I2NSF capability lay= er specifies how to control and monitor NSFs at functional level.  (I2= NSF will NOT work on any other aspects of NSFs including standardizing NSFs= or devices.  Nor will I2NSF at this stage specify how to derive control and monitoring capabilities from higher leve= l security policies for the Capability layer).  I2NSF will only standa= rdize the security policies related to the control and monitoring of the NS= Fs.  A sample capability layer construct for controlling NSFs is “subject-object-function-action”.

 =

The I2NSF Service Layer = defines how clients’ security policies may be expressed and monitored= . The Service Layer is out of scope for this phase of I2NSF’s work. H= owever, I2NSF will provide a forum for information drafts on data models, APIs, etc. that demonstrate how service layer polic= ies may be translated to Capability Layer functions.

 

The concrete work at the I2NSF Capability Layer incl= udes development of

-  &= nbsp;       An information mode= l that defines concepts required for standardizing the control  and mo= nitoring of NSFs,

-  &= nbsp;       A set of YANG data = models, derived from the above information model.

-  &= nbsp;       The capability regi= stry (IANA) that enables the characteristics and behavior of NSFs to be spe= cified using a vendor-neutral vocabulary without requiring the NSFs themsel= ves to be standardized; the registry enables various mechanisms, including policy rules, to be used to match mo= nitor and control functions to the needs of an application and/or environme= nt, and

-  &= nbsp;       The proper secure c= ommunication channels to carry the controlling and monitoring information b= etween the NSFs and their management entity (or entities).

 

 Standard interfaces for monitoring and control= ling the behavior of NSFs are essential building blocks for Security Servic= e Providers to automate the use of different NSFs from multiple vendors by = their Security management entities. This layer will leverage the existing protocols and data models defined by I2RS= , Netconf, and NETMOD.

 

It is a non-goal to create new protocols or data mod= eling languages for I2NSF interfaces.

The I2NSF WG’s deliverables include:

 

-       = ;   Use Cases document. <= /o:p>

-       = ;   Framework Document.

-       = ;   Requirements for extension= s (if any) to existing protocols used by the WG.

-       = ;    Gap analysis of exis= ting protocols and modeling languages for specifying, querying, monitoring,= and controlling NSFs.

-       = ;   A single, unified, Informa= tion Model for controlling and monitoring flow-based NSFs.

-       = ;   Corresponding YANG Data Mo= dels derived from the above Information Model.

-       = ;   IANA registry consideratio= n for flow-based NSFs controlling and monitoring capabilities.

-       = ;   (Optionally) Document desc= ribing how capabilities are used to monitor and control flow-based NSFs.

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

 

[The W= G may decide that the Use cases, Framework, and Requirement are Information= al documents or simply reference documents during the lifetime of the WG.]

 

Suggested Milestones

  - Use Cases Document:  Charter time += ; 1 month to WG Document

  - Framework: Charter time + 4 months to W= G Document

  - Requirements for extensions to protocols:&n= bsp; Charter time + 8 months to WG document

  - Info model: Charter time + 8 months to = WG Document

  - IANA registry consideration + 12 months= to WG Document

  - All Early Drafts to IESG: 18 months

 

[decision point – +10 months]  <= /o:p>

  - Data Models: Charter + 9 Months to= WG Document

  - Applicability Statements: 10 months to WG D= ocument

  - Data Models and Applicability Statements to= IESG  - 18 months

 

The WG will work closely with I2RS, Netconf and Netm= od WGs. The WG will communicate with external SDOs like ETSI NFV and will e= ncourage open source code development related to the WG scope in organizati= ons like ONF, OpenStack, ODL, and OPNFV.

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA5CA369D5AZFFEXMB04globa_-- From nobody Thu May 21 10:52:35 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D4371A026F for ; Thu, 21 May 2015 10:52:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pcPNHibMmyQ8 for ; Thu, 21 May 2015 10:52:30 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 183D71A000B for ; Thu, 21 May 2015 10:52:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id EB4486092B; Thu, 21 May 2015 13:52:27 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 4gKPXD0jORvg; Thu, 21 May 2015 13:52:17 -0400 (EDT) Received: from lx120e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 2F710607FD; Thu, 21 May 2015 13:52:15 -0400 (EDT) Message-ID: <555E1B3E.2090606@htt-consult.com> Date: Thu, 21 May 2015 13:51:58 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Linda Dunbar , "i2nsf@ietf.org" References: <4A95BA014132FF49AE685FAB4B9F17F657C2DC55@dfweml701-chm> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657C2DC55@dfweml701-chm> Content-Type: multipart/alternative; boundary="------------080408080300040207030801" Archived-At: Cc: "Romascanu, Dan \(Dan\)" , Joseph Salowey , Kathleen Moriarty Subject: Re: [I2nsf] Revised Narrower scoped I2NSF charter X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 17:52:34 -0000 This is a multi-part message in MIME format. --------------080408080300040207030801 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit I suspect I am missing something here. I can't improve on the text; amny have worked hard at the content. The capability data models will tend to define the Services layer, so I have a hard time separating them. Narrowing the scope might be a good short-term approach and we can revisit this as the data models evolve. On 05/18/2015 02:47 PM, Linda Dunbar wrote: > > Thanks to many people contributions to I2NSF charter. Here is the > revised one. Please provide comments and suggestions if your suggested > changes haven’t been properly addressed. > > Network security functions (NSFs) are 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 of NSFs may offer their customers network security > services that consist of multiple security products and/or functions > from different vendors. NSFs may be provided by physical and/or > virtualized infrastructure. Without standard interfaces to express, > monitor, and control security policies that govern the behavior of > NSFs, it becomes virtually impossible for security service providers > to automate their service offerings that utilize different security > functions from multiple vendors. > > The primary goal of I2NSF is to define an information model, a set of > software interfaces and data models for controlling and monitoring > aspects of NSFs (both physical and virtual). Other aspects of NSFs > such as device or network provisioning and configuration are out of > scope. Controlling and monitoring of NSFs should include the use of > policies to specify, query, monitor, and control the NSFs by one or > more management entities. Since different security vendors support > different features and functions on their devices, I2NSF will focus on > flow based NSFs that provide treatment to packets/flows, such as > IPS/IDS, Web filtering, flow filtering, deep packet inspection, or > pattern matching and remediation. > > There are two layers of interfaces envisioned in the I2NSF approach: > > ·I2NSF Capabilities Layer > > ·I2NSF Services Layer > > The I2NSF Capability Layer specifies the functional security policies, > which are translated from the entity defining the goal of the security > policy into a form that can be implemented, and are used to monitor > and control the behavior of NSFs. I2NSF will NOT standardize NSFs or > devices. Instead, I2NSF will only standardize the controlling and > monitoring aspects of the NSFs (not devices). An exemplar controlling > of flow-based NSFs is “Subject – Object – Function – Action”. > > The I2NSF Service Layer is for clients to express and monitor security > policies for their specific flows, which is usually based on > application and client specific logical networks requirements and context. > > The concrete work at the I2NSF Capability Layer includes > > -An information model that defines concepts required for standardizing > the controlling and monitoring of NSFs, > > -A set of YANG data models, derived from the above information model, > which enables the controlling and monitoring of virtual and/or > physical NSFs, > > -The capability registry (IANA) that enables the characteristics and > behavior of NSFs to be specified using a vendor-neutral vocabulary > without requiring the NSFs themselves to be standardized; the registry > enables various mechanisms, including policy rules, to be used to > match monitor and control functions to the needs of an application > and/or environment, and > > -The proper secure communication channels to carry the controlling and > monitoring information between the management entity (or entities) and > the NSFs being controlled. > > Standard interfaces for monitoring and controlling the behavior of > NSFs are essential building blocks for Security Service Providers to > automate the use of different NSFs from multiple vendors by their > Security management entities. 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 data models, APIs, > and/or RESTful interfaces to clients and demonstrating the feasibility > of them being translated to the Capability Layer policies. > > 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 for > specifying, querying, monitoring, and controlling NSFs. > > -A single, unified, Information Model for controlling and monitoring > flow-based NSFs. > > -Corresponding YANG Data Models derived from the above Information Model. > > -IANA registry consideration for flow based NSFs controlling and > monitoring capability. > > -(Optionally) Document describing how capabilities are used to monitor > and control flow-based NSFs. > > -(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.] > > 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 + 8 months > to WG document > > - Info model: Charter time + 8 months to WG Document > > - IANA registry consideration + 12 months to WG Document > > - All Early Drafts to IESG: 18 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 - 18 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 > > > > _______________________________________________ > I2nsf mailing list > I2nsf@ietf.org > https://www.ietf.org/mailman/listinfo/i2nsf --------------080408080300040207030801 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit I suspect I am missing something here.  I can't improve on the text; amny have worked hard at the content.

The capability data models will tend to define the Services layer, so I have a hard time separating them.  Narrowing the scope might be a good short-term approach and we can revisit this as the data models evolve.

On 05/18/2015 02:47 PM, Linda Dunbar wrote:

Thanks to many people contributions to I2NSF charter. Here is the revised one. Please provide comments and suggestions if your suggested changes haven’t been properly addressed.

 

 

 

Network security functions (NSFs) are 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 of NSFs may offer their customers network security services that consist of multiple security products and/or functions from different vendors. NSFs may be provided by physical and/or virtualized infrastructure. Without standard interfaces to express, monitor, and control security policies that govern the behavior of NSFs, it becomes virtually impossible for security service providers to automate their service offerings that utilize different security functions from multiple vendors.

 

The primary goal of I2NSF is to define an information model,  a set of software interfaces and data models for controlling and monitoring aspects of NSFs (both physical and virtual). Other aspects of NSFs such as device or network provisioning and configuration are out of scope. Controlling and monitoring of NSFs should include the use of policies to specify, query, monitor, and control the NSFs by one or more management entities. Since different security vendors support different features and functions on their devices, I2NSF will focus on flow based NSFs that provide treatment to packets/flows, such as IPS/IDS, Web filtering, flow filtering, deep packet inspection, or pattern matching and remediation.

 

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

·       I2NSF Capabilities Layer

·       I2NSF Services Layer

 

The I2NSF Capability Layer specifies the functional security policies, which are translated from the entity defining the goal of the security policy into a form that can be implemented, and are used to monitor and control the behavior of NSFs. I2NSF will NOT standardize NSFs or devices. Instead, I2NSF will only standardize the controlling and monitoring aspects of the NSFs (not devices). An exemplar controlling of flow-based NSFs is “Subject – Object – Function – Action”. 

 

The I2NSF Service Layer is for clients to express and monitor security policies for their specific flows, which is usually based on application and client specific logical networks requirements and context.

 

The concrete work at the I2NSF Capability Layer includes

-          An information model that defines concepts required for standardizing the controlling and monitoring of NSFs,

-          A set of YANG data models, derived from the above information model, which enables the controlling and monitoring of virtual and/or physical NSFs,

-          The capability registry (IANA) that enables the characteristics and behavior of NSFs to be specified using a vendor-neutral vocabulary without requiring the NSFs themselves to be standardized; the registry enables various mechanisms, including policy rules, to be used to match monitor and control functions to the needs of an application and/or environment, and

-          The proper secure communication channels to carry the controlling and monitoring information between the management entity (or entities) and the NSFs being controlled.

 

 Standard interfaces for monitoring and controlling the behavior of NSFs are essential building blocks for Security Service Providers to automate the use of different NSFs from multiple vendors by their Security management entities. 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 data models, APIs, and/or RESTful interfaces to clients and demonstrating the feasibility of them being translated to the Capability Layer policies.

 

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 for specifying, querying, monitoring, and controlling NSFs.

-          A single, unified, Information Model for controlling and monitoring flow-based NSFs.

-          Corresponding YANG Data Models derived from the above Information Model.

-          IANA registry consideration for flow based NSFs controlling and monitoring capability.

-          (Optionally) Document describing how capabilities are used to monitor and control flow-based NSFs.

-          (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.]

 

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 + 8 months to WG document

  - Info model: Charter time + 8 months to WG Document

  - IANA registry consideration + 12 months to WG Document

  - All Early Drafts to IESG: 18 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  - 18 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 



_______________________________________________
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

--------------080408080300040207030801-- From nobody Thu May 21 15:16:55 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD0271A90DD for ; Thu, 21 May 2015 15:16:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oUIRWQ-mjaji for ; Thu, 21 May 2015 15:16:48 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B92F1A90DC for ; Thu, 21 May 2015 15:16:47 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BSV04717; Thu, 21 May 2015 22:16:45 +0000 (GMT) Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 21 May 2015 23:16:45 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml705-chm ([10.193.5.142]) with mapi id 14.03.0158.001; Thu, 21 May 2015 15:16:37 -0700 From: Linda Dunbar To: "Romascanu, Dan (Dan)" , "'i2nsf@ietf.org'" Thread-Topic: Clean version of the narrower scoped I2NSF charter Thread-Index: AdCT57NeSF4gRyJcT1WxD+XVE/wsWwABGH1wAAnqKKA= Date: Thu, 21 May 2015 22:16:37 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657C46CDD@dfweml701-chm> References: <4A95BA014132FF49AE685FAB4B9F17F657C46AD8@dfweml701-chm> <9904FB1B0159DA42B0B887B7FA8119CA5CA369D5@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5CA369D5@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.233] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657C46CDDdfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [I2nsf] Clean version of the narrower scoped I2NSF charter X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 22:16:54 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F657C46CDDdfweml701chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The version posted has this statement: [The WG may decide that the Use cases, Framework, and Requirement are Infor= mational documents or simply reference documents during the lifetime of the= WG.] Is it good enough? Linda From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] Sent: Thursday, May 21, 2015 12:36 PM To: Linda Dunbar; 'i2nsf@ietf.org' Subject: RE: Clean version of the narrower scoped I2NSF charter This looks good to me. One thing based on a comment made by Kathleen earlier in the process. The I= ESG is not very sympathetic nowadays on the WGs spending resources on progr= essing use cases documents to RFC. Same applies I think to the gap analysis= , which is more a help tool while we define the scope of work. Maybe it's b= etter to mark those deliverables in brackets with the note (the WG will dec= ide if to proceed as RFC). Thanks for progressing this, Linda! Regards, Dan From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Thursday, May 21, 2015 8:01 PM To: 'i2nsf@ietf.org' Subject: [I2nsf] Clean version of the narrower scoped I2NSF charter Network security functions (NSFs) are provided and consumed in increasingly= diverse environments. Users of NSFs could consume network security service= s hosted by one or more providers, which may be their own enterprise, servi= ce providers, or a combination of both. Likewise, service providers of NSFs= may offer their customers network security services that consist of multip= le security products and/or functions from different vendors. NSFs may be p= rovided by physical and/or virtualized infrastructure. Without standard int= erfaces to express, monitor, and control security policies that govern the = behavior of NSFs, it becomes virtually impossible for security service prov= iders to automate their service offerings that utilize different security f= unctions from multiple vendors. The primary goal of I2NSF is to define an information model, a set of soft= ware interfaces and data models for controlling and monitoring aspects of N= SFs (both physical and virtual). Other aspects of NSFs such as device or ne= twork provisioning and configuration are out of scope. Controlling and moni= toring of NSFs should include the use of policies to specify, query, monito= r, and control the NSFs by one or more management entities. Since different= security vendors support different features and functions on their devices= , I2NSF will focus on flow-based NSFs that provide treatment to packets/flo= ws, such as IPS/IDS, Web filtering, flow filtering, deep packet inspection,= or pattern matching and remediation. There are two layers of interfaces envisioned in the I2NSF approach: * I2NSF Capability Layer * I2NSF Service Layer The I2NSF capability layer specifies how to control and monitor NSFs at fun= ctional level. (I2NSF will NOT work on any other aspects of NSFs including= standardizing NSFs or devices. Nor will I2NSF at this stage specify how t= o derive control and monitoring capabilities from higher level security pol= icies for the Capability layer). I2NSF will only standardize the security = policies related to the control and monitoring of the NSFs. A sample capab= ility layer construct for controlling NSFs is "subject-object-function-acti= on". The I2NSF Service Layer defines how clients' security policies may be expre= ssed and monitored. The Service Layer is out of scope for this phase of I2N= SF's work. However, I2NSF will provide a forum for information drafts on da= ta models, APIs, etc. that demonstrate how service layer policies may be tr= anslated to Capability Layer functions. The concrete work at the I2NSF Capability Layer includes development of - An information model that defines concepts required for standard= izing the control and monitoring of NSFs, - A set of YANG data models, derived from the above information mo= del. - The capability registry (IANA) that enables the characteristics = and behavior of NSFs to be specified using a vendor-neutral vocabulary with= out requiring the NSFs themselves to be standardized; the registry enables = various mechanisms, including policy rules, to be used to match monitor and= control functions to the needs of an application and/or environment, and - The proper secure communication channels to carry the controllin= g and monitoring information between the NSFs and their management entity (= or entities). Standard interfaces for monitoring and controlling the behavior of NSFs ar= e essential building blocks for Security Service Providers to automate the = use of different NSFs from multiple vendors by their Security management en= tities. This layer will leverage the existing protocols and data models def= ined by I2RS, Netconf, and NETMOD. It is a non-goal to create new protocols or data modeling languages for I2N= SF interfaces. The I2NSF WG's deliverables include: - Use Cases document. - Framework Document. - Requirements for extensions (if any) to existing protocols used = by the WG. - Gap analysis of existing protocols and modeling languages for s= pecifying, querying, monitoring, and controlling NSFs. - A single, unified, Information Model for controlling and monitor= ing flow-based NSFs. - Corresponding YANG Data Models derived from the above Informatio= n Model. - IANA registry consideration for flow-based NSFs controlling and = monitoring capabilities. - (Optionally) Document describing how capabilities are used to mo= nitor and control flow-based NSFs. - (Optionally) Applicability Statements on how to use I2RS, Netcon= f, and NETMOD to carry the content of the specified information/data models= . [The WG may decide that the Use cases, Framework, and Requirement are Infor= mational documents or simply reference documents during the lifetime of the= WG.] Suggested Milestones - Use Cases Document: Charter time + 1 month to WG Document - Framework: Charter time + 4 months to WG Document - Requirements for extensions to protocols: Charter time + 8 months to W= G document - Info model: Charter time + 8 months to WG Document - IANA registry consideration + 12 months to WG Document - All Early Drafts to IESG: 18 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 - 18 months The WG will work closely with I2RS, Netconf and Netmod WGs. The WG will com= municate with external SDOs like ETSI NFV and will encourage open source co= de development related to the WG scope in organizations like ONF, OpenStack= , ODL, and OPNFV. --_000_4A95BA014132FF49AE685FAB4B9F17F657C46CDDdfweml701chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The version posted has= this statement:

 

[The WG may decide that = the Use cases, Framework, and Requirement are Informational documents or si= mply reference documents during the lifetime of the WG.]

 

Is it good enough?

 

Linda

From: Romascan= u, Dan (Dan) [mailto:dromasca@avaya.com]
Sent: Thursday, May 21, 2015 12:36 PM
To: Linda Dunbar; 'i2nsf@ietf.org'
Subject: RE: Clean version of the narrower scoped I2NSF charter=

 

This looks good to me.=

 

One thing based on a c= omment made by Kathleen earlier in the process. The IESG is not very sympat= hetic nowadays on the WGs spending resources on progressing use cases docum= ents to RFC. Same applies I think to the gap analysis, which is more a help tool while we define the scope of w= ork. Maybe it’s better to mark those deliverables in brackets with th= e note (the WG will decide if to proceed as RFC).

 

Thanks for progressing= this, Linda!

 

Regards,

 

Dan<= /p>

 

 

From: I2nsf [<= a href=3D"mailto:i2nsf-bounces@ietf.org">mailto:i2nsf-bounces@ietf.org] On Behalf Of Linda Dunbar
Sent: Thursday, May 21, 2015 8:01 PM
To: 'i2nsf@ietf.org'
Subject: [I2nsf] Clean version of the narrower scoped I2NSF charter<= o:p>

 

 

Network security functio= ns (NSFs) are provided and consumed in increasingly diverse environments. U= sers 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 o= f NSFs may offer their customers network security services that consist of = multiple security products and/or functions from different vendors. NSFs ma= y be provided by physical and/or virtualized infrastructure. Without standard interfaces to express, monito= r, and control security policies that govern the behavior of NSFs, it becom= es virtually impossible for security service providers to automate their se= rvice offerings that utilize different security functions from multiple vendors.

 =

The primary goal of I2NS= F is to define an information model,  a set of software interfaces and= data models for controlling and monitoring aspects of NSFs (both physical = and virtual). Other aspects of NSFs such as device or network provisioning and configuration are out of scope. Cont= rolling and monitoring of NSFs should include the use of policies to specif= y, query, monitor, and control the NSFs by one or more management entities. Since different security vendors support different features and func= tions on their devices, I2NSF will focus on flow-based NSFs that provide tr= eatment to packets/flows, such as IPS/IDS, Web filtering, flow filtering, d= eep packet inspection, or pattern matching and remediation.

 =

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

·       I2NSF Capability= Layer

·       I2NSF Service La= yer

 =

The I2NSF capability lay= er specifies how to control and monitor NSFs at functional level.  (I2= NSF will NOT work on any other aspects of NSFs including standardizing NSFs= or devices.  Nor will I2NSF at this stage specify how to derive control and monitoring capabilities from higher leve= l security policies for the Capability layer).  I2NSF will only standa= rdize the security policies related to the control and monitoring of the NS= Fs.  A sample capability layer construct for controlling NSFs is “subject-object-function-action”.

 =

The I2NSF Service Layer = defines how clients’ security policies may be expressed and monitored= . The Service Layer is out of scope for this phase of I2NSF’s work. H= owever, I2NSF will provide a forum for information drafts on data models, APIs, etc. that demonstrate how service layer polic= ies may be translated to Capability Layer functions.

 

The concrete work at the I2NSF Capability Layer incl= udes development of

-  &= nbsp;       An information model that defines concepts r= equired for standardizing the control  and monitoring of NSFs,

-  &= nbsp;       A set of YANG data models, derived from the = above information model.

-  &= nbsp;       The capability registry (IANA) that enables = the characteristics and behavior of NSFs to be specified using a vendor-neu= tral vocabulary without requiring the NSFs themselves to be standardized; t= he registry enables various mechanisms, including policy rules, to be used to match monitor and control functions = to the needs of an application and/or environment, and

-  &= nbsp;       The proper secure communication channels to = carry the controlling and monitoring information between the NSFs and their= management entity (or entities).

 

 Standard interfaces for monitoring and control= ling the behavior of NSFs are essential building blocks for Security Servic= e Providers to automate the use of different NSFs from multiple vendors by = their Security management entities. This layer will leverage the existing protocols and data models defined by I2RS= , Netconf, and NETMOD.

 

It is a non-goal to create new protocols or data mod= eling languages for I2NSF interfaces.

The I2NSF WG’s deliverables include:

 

-       = ;   Use Cases document.

-       = ;   Framework Document.

-       = ;   Requirements for extensions (if any) to existing pr= otocols used by the WG.

-       = ;    Gap analysis of existing protocols and modeli= ng languages for specifying, querying, monitoring, and controlling NSFs.

-       = ;   A single, unified, Information Model for controllin= g and monitoring flow-based NSFs.

-       = ;   Corresponding YANG Data Models derived from the abo= ve Information Model.

-       = ;   IANA registry consideration for flow-based NSFs con= trolling and monitoring capabilities.

-       = ;   (Optionally) Document describing how capabilities a= re used to monitor and control flow-based NSFs.

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

 

[The W= G may decide that the Use cases, Framework, and Requirement are Information= al documents or simply reference documents during the lifetime of the WG.]

 

Suggested Milestones

  - Use Cases Document:  Charter time += ; 1 month to WG Document

  - Framework: Charter time + 4 months to W= G Document

  - Requirements for extensions to protocols:&n= bsp; Charter time + 8 months to WG document

  - Info model: Charter time + 8 months to = WG Document

  - IANA registry consideration + 12 months= to WG Document

  - All Early Drafts to IESG: 18 months

 

[decision point – +10 months]  <= /o:p>

  - Data Models: Charter + 9 Months to= WG Document

  - Applicability Statements: 10 months to WG D= ocument

  - Data Models and Applicability Statements to= IESG  - 18 months

 

The WG will work closely with I2RS, Netconf and Netm= od WGs. The WG will communicate with external SDOs like ETSI NFV and will e= ncourage open source code development related to the WG scope in organizati= ons like ONF, OpenStack, ODL, and OPNFV.

 

--_000_4A95BA014132FF49AE685FAB4B9F17F657C46CDDdfweml701chm_-- From nobody Thu May 21 15:32:36 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C7751A8784 for ; Thu, 21 May 2015 15:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m1ueuVcQwF47 for ; Thu, 21 May 2015 15:32:32 -0700 (PDT) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AEA11A0191 for ; Thu, 21 May 2015 15:32:31 -0700 (PDT) Received: by lbbuc2 with SMTP id uc2so793065lbb.2 for ; Thu, 21 May 2015 15:32:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=U6o7hZqlRvSlOH5THpXE6x/Z6lQQOmNzE81SI1q/aE8=; b=kZh3RjWR9V3rOEWRSmNKS+9RBCH0c3RtkgNnckY23b7VeEj5wWp/cqr8g7ERQ1177x 5ZNeP7+NzN1yXZKNtGAHYR+EaCrFoZYJ2NqeFKG/h55nS7Gd/gGc/njtv6TekoMg3Wrt F6Kka5L2SiLu2vv3gsYlcgflrP1q1weUBkzp1/D6H/qGc1EnNtJXHZOIOecSvlHLzOMF hrsRYJ68nxh2Qh4WKY9KqP7om84n5qT8vWZ2Iu6PeUY7RSC8NFlO6kJWEqHEeo7L9rFI YCAVhcT7jh7lYjqZUsbd2MjwwNaDzHT3N3AODaQ9GuHkDrV4VqHahC+hpnVQAX1fOwrM cqiw== MIME-Version: 1.0 X-Received: by 10.153.6.36 with SMTP id cr4mr4088469lad.56.1432247549637; Thu, 21 May 2015 15:32:29 -0700 (PDT) Received: by 10.112.11.199 with HTTP; Thu, 21 May 2015 15:32:29 -0700 (PDT) In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657C46CDD@dfweml701-chm> References: <4A95BA014132FF49AE685FAB4B9F17F657C46AD8@dfweml701-chm> <9904FB1B0159DA42B0B887B7FA8119CA5CA369D5@AZ-FFEXMB04.global.avaya.com> <4A95BA014132FF49AE685FAB4B9F17F657C46CDD@dfweml701-chm> Date: Thu, 21 May 2015 18:32:29 -0400 Message-ID: From: Kathleen Moriarty To: Linda Dunbar Content-Type: multipart/alternative; boundary=001a11348c386d3bfa05169f1eeb Archived-At: Cc: "i2nsf@ietf.org" , "Romascanu, Dan \(Dan\)" Subject: Re: [I2nsf] Clean version of the narrower scoped I2NSF charter X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 22:32:35 -0000 --001a11348c386d3bfa05169f1eeb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, May 21, 2015 at 6:16 PM, Linda Dunbar wrote: > The version posted has this statement: > > > > [The WG may decide that the Use cases, Framework, and Requirement are > Informational documents or simply reference documents during the lifetime > of the WG.] > > > > Is it good enough? > That is helpful, thank you. It's good to not waste too much time on these types of documents so the work can start. Kathleen > > > Linda > > *From:* Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > *Sent:* Thursday, May 21, 2015 12:36 PM > *To:* Linda Dunbar; 'i2nsf@ietf.org' > *Subject:* RE: Clean version of the narrower scoped I2NSF charter > > > > This looks good to me. > > > > One thing based on a comment made by Kathleen earlier in the process. The > IESG is not very sympathetic nowadays on the WGs spending resources on > progressing use cases documents to RFC. Same applies I think to the gap > analysis, which is more a help tool while we define the scope of work. > Maybe it=E2=80=99s better to mark those deliverables in brackets with the= note (the > WG will decide if to proceed as RFC). > > > > Thanks for progressing this, Linda! > > > > Regards, > > > > Dan > > > > > > *From:* I2nsf [mailto:i2nsf-bounces@ietf.org ] *O= n > Behalf Of *Linda Dunbar > *Sent:* Thursday, May 21, 2015 8:01 PM > *To:* 'i2nsf@ietf.org' > *Subject:* [I2nsf] Clean version of the narrower scoped I2NSF charter > > > > > > Network security functions (NSFs) are 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, servic= e > providers of NSFs may offer their customers network security services tha= t > consist of multiple security products and/or functions from different > vendors. NSFs may be provided by physical and/or virtualized > infrastructure. Without standard interfaces to express, monitor, and > control security policies that govern the behavior of NSFs, it becomes > virtually impossible for security service providers to automate their > service offerings that utilize different security functions from multiple > vendors. > > > > The primary goal of I2NSF is to define an information model, a set of > software interfaces and data models for controlling and monitoring aspect= s > of NSFs (both physical and virtual). Other aspects of NSFs such as device > or network provisioning and configuration are out of scope. Controlling a= nd > monitoring of NSFs should include the use of policies to specify, query, > monitor, and control the NSFs by one or more management entities. Since > different security vendors support different features and functions on > their devices, I2NSF will focus on flow-based NSFs that provide treatment > to packets/flows, such as IPS/IDS, Web filtering, flow filtering, deep > packet inspection, or pattern matching and remediation. > > > > There are two layers of interfaces envisioned in the I2NSF approach: > > =C2=B7 I2NSF Capability Layer > > =C2=B7 I2NSF Service Layer > > > > The I2NSF capability layer specifies how to control and monitor NSFs at > functional level. (I2NSF will NOT work on any other aspects of NSFs > including standardizing NSFs or devices. Nor will I2NSF at this stage > specify how to derive control and monitoring capabilities from higher lev= el > security policies for the Capability layer). I2NSF will only standardize > the security policies related to the control and monitoring of the NSFs. = A > sample capability layer construct for controlling NSFs is > =E2=80=9Csubject-object-function-action=E2=80=9D. > > > > The I2NSF Service Layer defines how clients=E2=80=99 security policies ma= y be > expressed and monitored. The Service Layer is out of scope for this phase > of I2NSF=E2=80=99s work. However, I2NSF will provide a forum for informat= ion drafts > on data models, APIs, etc. that demonstrate how service layer policies ma= y > be translated to Capability Layer functions. > > > > The concrete work at the I2NSF Capability Layer includes development of > > - An information model that defines concepts required for > standardizing the control and monitoring of NSFs, > > - A set of YANG data models, derived from the above information > model. > > - The capability registry (IANA) that enables the > characteristics and behavior of NSFs to be specified using a vendor-neutr= al > vocabulary without requiring the NSFs themselves to be standardized; the > registry enables various mechanisms, including policy rules, to be used t= o > match monitor and control functions to the needs of an application and/or > environment, and > > - The proper secure communication channels to carry the > controlling and monitoring information between the NSFs and their > management entity (or entities). > > > > Standard interfaces for monitoring and controlling the behavior of NSFs > are essential building blocks for Security Service Providers to automate > the use of different NSFs from multiple vendors by their Security > management entities. This layer will leverage the existing protocols and > data models defined by I2RS, Netconf, and NETMOD. > > > > It is a non-goal to create new protocols or data modeling languages for > I2NSF interfaces. > > The I2NSF WG=E2=80=99s deliverables include: > > > > - Use Cases document. > > - Framework Document. > > - Requirements for extensions (if any) to existing protocols > used by the WG. > > - Gap analysis of existing protocols and modeling languages for > specifying, querying, monitoring, and controlling NSFs. > > - A single, unified, Information Model for controlling and > monitoring flow-based NSFs. > > - Corresponding YANG Data Models derived from the above > Information Model. > > - IANA registry consideration for flow-based NSFs controlling > and monitoring capabilities. > > - (Optionally) Document describing how capabilities are used to > monitor and control flow-based NSFs. > > - (Optionally) Applicability Statements on how to use I2RS, > Netconf, and NETMOD to carry the content of the specified information/dat= a > 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.] > > > > Suggested Milestones > > - Use Cases Document: Charter time + 1 month to WG Document > > - Framework: Charter time + 4 months to WG Document > > - Requirements for extensions to protocols: Charter time + 8 months to > WG document > > - Info model: Charter time + 8 months to WG Document > > - IANA registry consideration + 12 months to WG Document > > - All Early Drafts to IESG: 18 months > > > > [decision point =E2=80=93 +10 months] > > - Data Models: Charter + 9 Months to WG Document > > - Applicability Statements: 10 months to WG Document > > - Data Models and Applicability Statements to IESG - 18 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 sour= ce > code development related to the WG scope in organizations like ONF, > OpenStack, ODL, and OPNFV. > > > > _______________________________________________ > I2nsf mailing list > I2nsf@ietf.org > https://www.ietf.org/mailman/listinfo/i2nsf > > --=20 Best regards, Kathleen --001a11348c386d3bfa05169f1eeb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, May 21, 2015 at 6:16 PM, Linda Dunbar <linda.dunbar@huaw= ei.com> wrote:

The version posted has= this statement:

=C2=A0

[The WG may decide that = the Use cases, Framework, and Requirement are Informational documents or si= mply reference documents during the lifetime of the WG.]

=C2=A0

Is it good enou= gh?


That is helpful,= thank you.=C2=A0 It's good to not waste too much time on these types o= f documents so the work can start.

Kathleen
<= div>=C2=A0

=C2=A0

Linda

From: Romascan= u, Dan (Dan) [mailto:dromasca@avaya.com]
Sent: Thursday, May 21, 2015 12:36 PM
To: Linda Dunbar; 'i2nsf@ietf.org'
Subject: RE: Clean version of the narrower scoped I2NSF charter

=C2=A0

This looks good to me.=

=C2=A0

One thing based on a c= omment made by Kathleen earlier in the process. The IESG is not very sympat= hetic nowadays on the WGs spending resources on progressing use cases docum= ents to RFC. Same applies I think to the gap analysis, which is more a help tool while we define the scope of w= ork. Maybe it=E2=80=99s better to mark those deliverables in brackets with = the note (the WG will decide if to proceed as RFC).

=C2=A0

Thanks for progressing= this, Linda!

=C2=A0

Regards,=

=C2=A0

Dan

=C2=A0

=C2=A0

From: I2nsf [<= a href=3D"mailto:i2nsf-bounces@ietf.org" target=3D"_blank">mailto:i2nsf-bou= nces@ietf.org] On Behalf Of Linda Dunbar
Sent: Thursday, May 21, 2015 8:01 PM
To: 'i2nsf@i= etf.org'
Subject: [I2nsf] Clean version of the narrower scoped I2NSF charter<= u>

=C2=A0

=C2=A0

Network security functio= ns (NSFs) are provided and consumed in increasingly diverse environments. U= sers 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 o= f NSFs may offer their customers network security services that consist of = multiple security products and/or functions from different vendors. NSFs ma= y be provided by physical and/or virtualized infrastructure. Without standard interfaces to express, monito= r, and control security policies that govern the behavior of NSFs, it becom= es virtually impossible for security service providers to automate their se= rvice offerings that utilize different security functions from multiple vendors.

=C2=A0

The primary goal of I2NS= F is to define an information model,=C2=A0 a set of software interfaces and= data models for controlling and monitoring aspects of NSFs (both physical = and virtual). Other aspects of NSFs such as device or network provisioning and configuration are out of scope. Cont= rolling and monitoring of NSFs should include the use of policies to specif= y, query, monitor, and control the NSFs by one or more management entities. Since different security vendors support different features and func= tions on their devices, I2NSF will focus on flow-based NSFs that provide tr= eatment to packets/flows, such as IPS/IDS, Web filtering, flow filtering, d= eep packet inspection, or pattern matching and remediation.

=C2=A0

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

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 I2NSF Capability La= yer

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 I2NSF Service Layer=

=C2=A0

The I2NSF capability lay= er specifies how to control and monitor NSFs at functional level.=C2=A0 (I2= NSF will NOT work on any other aspects of NSFs including standardizing NSFs= or devices.=C2=A0 Nor will I2NSF at this stage specify how to derive control and monitoring capabilities from higher leve= l security policies for the Capability layer).=C2=A0 I2NSF will only standa= rdize the security policies related to the control and monitoring of the NS= Fs.=C2=A0 A sample capability layer construct for controlling NSFs is =E2=80=9Csubject-object-function-action=E2=80=9D. =

=C2=A0

The I2NSF Service Layer = defines how clients=E2=80=99 security policies may be expressed and monitor= ed. The Service Layer is out of scope for this phase of I2NSF=E2=80=99s wor= k. However, I2NSF will provide a forum for information drafts on data models, APIs, etc. that demonstrate how service layer polic= ies may be translated to Capability Layer functions.

=C2=A0

The concrete work at the I2NSF Capability Layer incl= udes development of

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 An information model that defines concepts requ= ired for standardizing the control=C2=A0 and monitoring of NSFs,

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 A set of YANG data models, derived from the abo= ve information model.

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 The capability registry (IANA) that enables the= characteristics and behavior of NSFs to be specified using a vendor-neutra= l vocabulary without requiring the NSFs themselves to be standardized; the = registry enables various mechanisms, including policy rules, to be used to match monitor and control functions = to the needs of an application and/or environment, and

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 The proper secure communication channels to car= ry the controlling and monitoring information between the NSFs and their ma= nagement entity (or entities).

=C2=A0

=C2=A0Standard interfaces for monitoring and control= ling the behavior of NSFs are essential building blocks for Security Servic= e Providers to automate the use of different NSFs from multiple vendors by = their Security management entities. This layer will leverage the existing protocols and data models defined by I2RS= , Netconf, and NETMOD.

=C2=A0

It is a non-goal to create new protocols or data mod= eling languages for I2NSF interfaces.

The I2NSF WG=E2=80=99s deliverables include:<= u>

=C2=A0

-=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Use Cases document.

-=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Framework Document.

-=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Requirements for extensions (if any) to existing proto= cols used by the WG.

-=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0Gap analysis of existing protocols and modeling = languages for specifying, querying, monitoring, and controlling NSFs.

-=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 A single, unified, Information Model for controlling a= nd monitoring flow-based NSFs.

-=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Corresponding YANG Data Models derived from the above = Information Model.

-=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 IANA registry consideration for flow-based NSFs contro= lling and monitoring capabilities.

-=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (Optionally) Document describing how capabilities are = used to monitor and control flow-based NSFs.

-=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (Optionally) Applicability Statements on how to use I2= RS, Netconf, and NETMOD to carry the content of the specified information/d= ata models.

=C2=A0

[The W= G may decide that the Use cases, Framework, and Requirement are Information= al documents or simply reference documents during the lifetime of the WG.]

=C2=A0

Suggested Milestones

=C2=A0 - Use Cases Document:=C2=A0 Charter time + 1 = month to WG Document

=C2=A0 - Framework: Charter time + 4 months to WG Do= cument

=C2=A0 - Requirements for extensions to protocols:= =C2=A0 Charter time + 8 months to WG document

=C2=A0 - Info model: Charter time + 8 months to WG D= ocument

=C2=A0 - IANA registry consideration + 12 months to = WG Document

=C2=A0 - All Early Drafts to IESG: 18 months<= u>

=C2=A0

[decision point =E2=80=93 +10 months]=C2=A0 <= u>

=C2=A0=C2=A0- Data Models: Charter + 9 Months to WG = Document

=C2=A0 - Applicability Statements: 10 months to WG D= ocument

=C2=A0 - Data Models and Applicability Statements to= IESG=C2=A0 - 18 months

=C2=A0

The WG will work closely with I2RS, Netconf and Netm= od WGs. The WG will communicate with external SDOs like ETSI NFV and will e= ncourage open source code development related to the WG scope in organizati= ons like ONF, OpenStack, ODL, and OPNFV.

=C2=A0


_______________________________________________
I2nsf mailing list
I2nsf@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/i2nsf




--

Best regards,
Ka= thleen
--001a11348c386d3bfa05169f1eeb-- From nobody Thu May 21 15:42:58 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3E861A87B1 for ; Thu, 21 May 2015 15:42:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TPVpbnXMnzNX for ; Thu, 21 May 2015 15:42:53 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 357071A90DC for ; Thu, 21 May 2015 15:42:53 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BWJ26419; Thu, 21 May 2015 22:42:51 +0000 (GMT) Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 21 May 2015 23:42:50 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml705-chm ([10.193.5.142]) with mapi id 14.03.0158.001; Thu, 21 May 2015 15:42:39 -0700 From: Linda Dunbar To: "'i2nsf@ietf.org'" Thread-Topic: updated I2NSF problem statement to reflect the narrower scoped charter Thread-Index: AQHQlBdwcaMbS56nSk+pGJr4g/BqUg== Date: Thu, 21 May 2015 22:42:39 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657C46D13@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.134.154] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [I2nsf] updated I2NSF problem statement to reflect the narrower scoped charter X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 22:42:57 -0000 V2UgdXBkYXRlZCB0aGUgSTJOU0YgcHJvYmxlbSBzdGF0ZW1lbnQgdG8gcmVmbGVjdCB0aGUgbmFy cm93ZXIgc2NvcGVkIGNoYXJ0ZXIuIA0KDQpUaGUgcHJpbWFyeSBpc3N1ZXMgYW5kIGNoYWxsZW5n ZXMgZmFjaW5nIE5TRnMgaG9zdGVkIGJ5IGRpZmZlcmVudCBkb21haW5zIGFyZToNCg0KICAgICAg My4xLiBDaGFsbGVuZ2VzIEZhY2luZyBTZWN1cml0eSBTZXJ2aWNlIFByb3ZpZGVycy4uLi4uLi4u Li4uLi4uNQ0KICAgICAgICAgMy4xLjEuIERpdmVyc2UgdHlwZXMgb2YgU2VjdXJpdHkgRnVuY3Rp b25zLi4uLi4uLi4uLi4uLi4uLi4uNQ0KICAgICAgICAgMy4xLjIuIE5vIFN0YW5kYXJkIENoYXJh Y3Rlcml6YXRpb24gb2YgTlNGcy4uLi4uLi4uLi4uLi4uLi4uNg0KICAgICAgICAgMy4xLjMuIE1v cmUgRGlzdHJpYnV0ZWQgTlNGcyBhbmQgdk5TRnMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uNw0KICAg ICAgICAgMy4xLjQuIE1vcmUgRGVtYW5kIHRvIENvbnRyb2wgTlNGcyBEeW5hbWljYWxseS4uLi4u Li4uLi4uLi4uNw0KICAgICAgICAgMy4xLjUuIERpdmVyc2UgSW50ZXJmYWNlcyB0byBDb250cm9s IGFuZCBNb25pdG9yIE5TRnMuLi4uLi4uNw0KICAgICAgICAgMy4xLjYuIExhY2sgb2YgbWVjaGFu aXNtIHRvIG1vbml0b3IgdGhlIGJlaGF2aW9yIG9mIE5TRnMuLi4uOA0KICAgICAgMy4yLiBDaGFs bGVuZ2VzIEZhY2luZyBDdXN0b21lcnMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uOA0K ICAgICAgICAgMy4yLjEuIE5lZWQgdG8gaW50ZWdyYXRlIG9uLXByZW1pc2VzIE5TRnMgd2l0aCBS ZW1vdGUgTlNGcy4uOA0KICAgICAgICAgMy4yLjIuIFRvZGF5J3MgUG9saWN5IEV4cHJlc3Npb25z IGFyZSBWZW5kb3JzIFNwZWNpZmljLi4uLi4uOQ0KICAgICAgICAgMy4yLjMuIERpZmZpY3VsdHkg dG8gTW9uaXRvciB0aGUgRXhlY3V0aW9uIG9mIERlc2lyZWQgUG9saWNpZXMNCiAgICAgICAgIC4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u MTANCiAgICAgIDMuMy4gRGlmZmljdWx0eSB0byBWYWxpZGF0ZSBQb2xpY2llcyBhY3Jvc3MgTXVs dGlwbGUgRG9tYWlucy4uMTANCiAgICAgIDMuNC4gTGFjayBvZiBTdGFuZGFyZCBJbnRlcmZhY2Ug dG8gSW5qZWN0IEZlZWRiYWNrIHRvIE5TRi4uLi4uMTENCg0KWW91ciBjb21tZW50cyBhbmQgc3Vn Z2VzdGlvbnMgYXJlIGhpZ2hseSBhcHByZWNpYXRlZC4gDQoNCkxpbmRhDQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzpp bnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogVGh1cnNkYXksIE1heSAyMSwgMjAxNSA1 OjM3IFBNDQpUbzogTW9oYW1lZCBCb3VjYWRhaXI7IFNoYWliYWwgQ2hha3JhYmFydHk7IExpbmRh IER1bmJhcjsgQ2hyaXN0aWFuIEphY3F1ZW5ldDsgTXlvIFphcm55OyBDaHJpc3RpYW4gSmFjcXVl bmV0OyBNeW8gWmFybnk7IFNoYWliYWwgQ2hha3JhYmFydHk7IExpbmRhIER1bmJhcjsgTW9oYW1l ZCBCb3VjYWRhaXINClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQt ZHVuYmFyLWkybnNmLXByb2JsZW0tc3RhdGVtZW50LTA0LnR4dA0KDQoNCkEgbmV3IHZlcnNpb24g b2YgSS1ELCBkcmFmdC1kdW5iYXItaTJuc2YtcHJvYmxlbS1zdGF0ZW1lbnQtMDQudHh0DQpoYXMg YmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IExpbmRhIER1bmJhciBhbmQgcG9zdGVkIHRv IHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFmdC1kdW5iYXItaTJuc2YtcHJvYmxl bS1zdGF0ZW1lbnQNClJldmlzaW9uOgkwNA0KVGl0bGU6CQlJbnRlcmZhY2UgdG8gTmV0d29yayBT ZWN1cml0eSBGdW5jdGlvbnMgKEkyTlNGKSBQcm9ibGVtIFN0YXRlbWVudA0KRG9jdW1lbnQgZGF0 ZToJMjAxNS0wNS0yMQ0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOgkJMjAN ClVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJh ZnQtZHVuYmFyLWkybnNmLXByb2JsZW0tc3RhdGVtZW50LTA0LnR4dA0KU3RhdHVzOiAgICAgICAg IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWR1bmJhci1pMm5zZi1wcm9i bGVtLXN0YXRlbWVudC8NCkh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtZHVuYmFyLWkybnNmLXByb2JsZW0tc3RhdGVtZW50LTA0DQpEaWZmOiAgICAgICAg ICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWR1bmJhci1pMm5zZi1w cm9ibGVtLXN0YXRlbWVudC0wNA0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQgZGVzY3Jp YmVzIHRoZSBtb3RpdmF0aW9uIGFuZCB0aGUgcHJvYmxlbSBzdGF0ZW1lbnQgZm9yDQogICBJbnRl cmZhY2UgdG8gTmV0d29yayBTZWN1cml0eSBGdW5jdGlvbnMgKEkyTlNGKS4NCg0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIA0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3Vw bGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxp emVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0K VGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From nobody Thu May 21 18:24:28 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 108B61A8840 for ; Thu, 21 May 2015 18:24:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sqnaqVb0GI8A for ; Thu, 21 May 2015 18:24:23 -0700 (PDT) Received: from smtptc.telefonica.com (smtptc.telefonica.com [195.76.34.108]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB0E31A88B9 for ; Thu, 21 May 2015 18:24:22 -0700 (PDT) Received: from smtptc.telefonica.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C31E03A01FE; Fri, 22 May 2015 03:24:19 +0200 (CEST) Received: from ESTGVMSP101.EUROPE.telefonica.corp (unknown [10.92.4.9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtptc.telefonica.com (Postfix) with ESMTPS id AB2413A01FA; Fri, 22 May 2015 03:24:19 +0200 (CEST) Received: from emea01-am1-obe.outbound.protection.outlook.com (10.92.5.139) by tls.telefonica.com (10.92.6.49) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 22 May 2015 03:24:18 +0200 Received: from DB4PR06MB0621.eurprd06.prod.outlook.com (25.161.13.139) by DB4PR06MB0718.eurprd06.prod.outlook.com (25.161.14.142) with Microsoft SMTP Server (TLS) id 15.1.166.22; Fri, 22 May 2015 01:24:18 +0000 Received: from DB4PR06MB0624.eurprd06.prod.outlook.com (25.161.13.142) by DB4PR06MB0621.eurprd06.prod.outlook.com (25.161.13.139) with Microsoft SMTP Server (TLS) id 15.1.166.22; Fri, 22 May 2015 01:24:17 +0000 Received: from DB4PR06MB0624.eurprd06.prod.outlook.com ([25.161.13.142]) by DB4PR06MB0624.eurprd06.prod.outlook.com ([25.161.13.142]) with mapi id 15.01.0166.017; Fri, 22 May 2015 01:24:17 +0000 From: DIEGO LOPEZ GARCIA To: Linda Dunbar Thread-Topic: [I2nsf] Definition for "Network Security Functions" Thread-Index: AdCT68W6aC/heUYRRaG527iXhQCbpwAQj5CA Date: Fri, 22 May 2015 01:24:16 +0000 Message-ID: <52667987-C3D9-41D2-9237-6D849EC99E5F@telefonica.com> References: <4A95BA014132FF49AE685FAB4B9F17F657C46B24@dfweml701-chm> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657C46B24@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=diego.r.lopez@telefonica.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [121.58.104.2] x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:DB4PR06MB0621; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:DB4PR06MB0718; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(520002)(5005006)(3002001); SRVR:DB4PR06MB0621; BCL:0; PCL:0; RULEID:; SRVR:DB4PR06MB0621; x-forefront-prvs: 058441C12A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(164054003)(24454002)(189002)(199003)(252514010)(86362001)(46102003)(87936001)(33656002)(64706001)(76176999)(54356999)(2656002)(50986999)(5001860100001)(92566002)(2950100001)(101416001)(16236675004)(19617315012)(66066001)(36756003)(7110500001)(68736005)(15975445007)(105586002)(110136002)(102836002)(2420400003)(5001960100002)(189998001)(77156002)(40100003)(122556002)(62966003)(19580405001)(97736004)(82746002)(19580395003)(81156007)(5890100001)(4001540100001)(83716003)(106356001)(2900100001)(5001830100001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR06MB0621; H:DB4PR06MB0624.eurprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: telefonica.com does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_52667987C3D941D292376D849EC99E5Ftelefonicacom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 May 2015 01:24:16.0160 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR06MB0621 X-OriginatorOrg: telefonica.com X-TM-AS-MML: No Archived-At: Cc: "i2nsf@ietf.org" Subject: Re: [I2nsf] Definition for "Network Security Functions" X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 01:24:27 -0000 --_000_52667987C3D941D292376D849EC99E5Ftelefonicacom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, What about something more detailed: "functions to ensure integrity, confidentiality and availability of network= communications, to detect unwanted activity, and to deter it or at least m= itigate its effects on the network" On 22 May 2015, at 01:30 , Linda Dunbar > wrote: Anyone object using this definition for =93Network Security Functions=94? =93functions to ensure the communications in and out of network as well as = to deter and detect the unwanted communication from negatively impacting th= e network and its attached entities.=94 Thanks, Linda _______________________________________________ I2nsf mailing list I2nsf@ietf.org 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: diego.r.lopez@telefonica.com Tel: +34 913 129 041 Mobile: +34 682 051 091 ---------------------------------- ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o= copia sin autorizaci=F3n puede estar prohibida en virtud de la legislaci= =F3n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo = comunique inmediatamente por esta misma v=EDa y proceda a su destrucci=F3n. The information contained in this transmission is privileged and confidenti= al 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 co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, div= ulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o pode estar proibida em virtude= da legisla=E7=E3o vigente. Se recebeu esta mensagem por erro, rogamos-lhe = que nos o comunique imediatamente por esta mesma via e proceda a sua destru= i=E7=E3o --_000_52667987C3D941D292376D849EC99E5Ftelefonicacom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <0B402CD71ADC8442AC613DF024257699@eurprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Hi,

What about something more detailed:

"functions to ensure integrity, confidentiality and availability = of network communications, to detect unwanted activity, and to deter it or = at least mitigate its effects on the network"


On 22 May 2015, at 01:30 , Linda Dunbar <linda.dunbar@huawei.com> wrote:

Anyone object using this definition for =93Network Security Functions=94?
 
=93functions to ensure the communications in and out of network as well as = to deter and detect the unwanted communication from negatively impacting th= e network and its attached entities.=94
 
Thanks,
 
Linda
 
_______________________________________________
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2n= sf

--
"Esta vez no fallaremos, Doctor Infierno"

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

e-mail: diego.r.lopez@telefonica.com
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------



Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o copia sin autorizaci=F3n puede e= star prohibida en virtud de la legislaci=F3n vigente. Si ha recibido este m= ensaje por error, le rogamos que nos lo comunique inmediatamente por esta m= isma v=EDa y proceda a su destrucci=F3n.

The information contained in this transmission is privileged and confidenti= al 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 y= ou have received this transmission in error, do not read it. Please immedia= tely 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=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, divulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o p= ode estar proibida em virtude da legisla=E7=E3o vigente. Se recebeu esta me= nsagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mes= ma via e proceda a sua destrui=E7=E3o
 --_000_52667987C3D941D292376D849EC99E5Ftelefonicacom_-- From nobody Fri May 22 02:25:01 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B47741B2AA1 for ; Fri, 22 May 2015 02:24:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DHNQHeUn_494 for ; Fri, 22 May 2015 02:24:54 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB5701B2A9E for ; Fri, 22 May 2015 02:24:53 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am8FAEL1XlXGmAcV/2dsb2JhbABcgkUhKlReBrEOAQEBAQEBBplWAoE7TAEBAQEBAYELhCIBAQEBAxIbRxUCAQgNBAQBAQsWAQYHMhQJCAEBBAESCBqICgGkJa5tAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4YWhCKBAoRUNwGDF4EWBZBBgjyTF48aI4N4b4FGgQEBAQE X-IronPort-AV: E=Sophos;i="5.13,474,1427774400"; d="scan'208,217";a="103694726" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by de307622-de-outbound.net.avaya.com with ESMTP; 22 May 2015 05:24:50 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 22 May 2015 05:24:49 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.03.0174.001; Fri, 22 May 2015 11:24:48 +0200 From: "Romascanu, Dan (Dan)" To: Linda Dunbar , "'i2nsf@ietf.org'" Thread-Topic: Clean version of the narrower scoped I2NSF charter Thread-Index: AdCT57NeSF4gRyJcT1WxD+XVE/wsWwABGH1wAAnqKKAAF1QkIA== Date: Fri, 22 May 2015 09:24:48 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5CA376B9@AZ-FFEXMB04.global.avaya.com> References: <4A95BA014132FF49AE685FAB4B9F17F657C46AD8@dfweml701-chm> <9904FB1B0159DA42B0B887B7FA8119CA5CA369D5@AZ-FFEXMB04.global.avaya.com> <4A95BA014132FF49AE685FAB4B9F17F657C46CDD@dfweml701-chm> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657C46CDD@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.47] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA5CA376B9AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: Subject: Re: [I2nsf] Clean version of the narrower scoped I2NSF charter X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 09:24:59 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5CA376B9AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I missed this, sorry. Sure - this is fine. Thanks and Regards, Dan From: Linda Dunbar [mailto:linda.dunbar@huawei.com] Sent: Friday, May 22, 2015 1:17 AM To: Romascanu, Dan (Dan); 'i2nsf@ietf.org' Subject: RE: Clean version of the narrower scoped I2NSF charter The version posted has this statement: [The WG may decide that the Use cases, Framework, and Requirement are Infor= mational documents or simply reference documents during the lifetime of the= WG.] Is it good enough? Linda From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] Sent: Thursday, May 21, 2015 12:36 PM To: Linda Dunbar; 'i2nsf@ietf.org' Subject: RE: Clean version of the narrower scoped I2NSF charter This looks good to me. One thing based on a comment made by Kathleen earlier in the process. The I= ESG is not very sympathetic nowadays on the WGs spending resources on progr= essing use cases documents to RFC. Same applies I think to the gap analysis= , which is more a help tool while we define the scope of work. Maybe it's b= etter to mark those deliverables in brackets with the note (the WG will dec= ide if to proceed as RFC). Thanks for progressing this, Linda! Regards, Dan From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Thursday, May 21, 2015 8:01 PM To: 'i2nsf@ietf.org' Subject: [I2nsf] Clean version of the narrower scoped I2NSF charter Network security functions (NSFs) are provided and consumed in increasingly= diverse environments. Users of NSFs could consume network security service= s hosted by one or more providers, which may be their own enterprise, servi= ce providers, or a combination of both. Likewise, service providers of NSFs= may offer their customers network security services that consist of multip= le security products and/or functions from different vendors. NSFs may be p= rovided by physical and/or virtualized infrastructure. Without standard int= erfaces to express, monitor, and control security policies that govern the = behavior of NSFs, it becomes virtually impossible for security service prov= iders to automate their service offerings that utilize different security f= unctions from multiple vendors. The primary goal of I2NSF is to define an information model, a set of soft= ware interfaces and data models for controlling and monitoring aspects of N= SFs (both physical and virtual). Other aspects of NSFs such as device or ne= twork provisioning and configuration are out of scope. Controlling and moni= toring of NSFs should include the use of policies to specify, query, monito= r, and control the NSFs by one or more management entities. Since different= security vendors support different features and functions on their devices= , I2NSF will focus on flow-based NSFs that provide treatment to packets/flo= ws, such as IPS/IDS, Web filtering, flow filtering, deep packet inspection,= or pattern matching and remediation. There are two layers of interfaces envisioned in the I2NSF approach: * I2NSF Capability Layer * I2NSF Service Layer The I2NSF capability layer specifies how to control and monitor NSFs at fun= ctional level. (I2NSF will NOT work on any other aspects of NSFs including= standardizing NSFs or devices. Nor will I2NSF at this stage specify how t= o derive control and monitoring capabilities from higher level security pol= icies for the Capability layer). I2NSF will only standardize the security = policies related to the control and monitoring of the NSFs. A sample capab= ility layer construct for controlling NSFs is "subject-object-function-acti= on". The I2NSF Service Layer defines how clients' security policies may be expre= ssed and monitored. The Service Layer is out of scope for this phase of I2N= SF's work. However, I2NSF will provide a forum for information drafts on da= ta models, APIs, etc. that demonstrate how service layer policies may be tr= anslated to Capability Layer functions. The concrete work at the I2NSF Capability Layer includes development of - An information model that defines concepts required for standard= izing the control and monitoring of NSFs, - A set of YANG data models, derived from the above information mo= del. - The capability registry (IANA) that enables the characteristics = and behavior of NSFs to be specified using a vendor-neutral vocabulary with= out requiring the NSFs themselves to be standardized; the registry enables = various mechanisms, including policy rules, to be used to match monitor and= control functions to the needs of an application and/or environment, and - The proper secure communication channels to carry the controllin= g and monitoring information between the NSFs and their management entity (= or entities). Standard interfaces for monitoring and controlling the behavior of NSFs ar= e essential building blocks for Security Service Providers to automate the = use of different NSFs from multiple vendors by their Security management en= tities. This layer will leverage the existing protocols and data models def= ined by I2RS, Netconf, and NETMOD. It is a non-goal to create new protocols or data modeling languages for I2N= SF interfaces. The I2NSF WG's deliverables include: - Use Cases document. - Framework Document. - Requirements for extensions (if any) to existing protocols used = by the WG. - Gap analysis of existing protocols and modeling languages for s= pecifying, querying, monitoring, and controlling NSFs. - A single, unified, Information Model for controlling and monitor= ing flow-based NSFs. - Corresponding YANG Data Models derived from the above Informatio= n Model. - IANA registry consideration for flow-based NSFs controlling and = monitoring capabilities. - (Optionally) Document describing how capabilities are used to mo= nitor and control flow-based NSFs. - (Optionally) Applicability Statements on how to use I2RS, Netcon= f, and NETMOD to carry the content of the specified information/data models= . [The WG may decide that the Use cases, Framework, and Requirement are Infor= mational documents or simply reference documents during the lifetime of the= WG.] Suggested Milestones - Use Cases Document: Charter time + 1 month to WG Document - Framework: Charter time + 4 months to WG Document - Requirements for extensions to protocols: Charter time + 8 months to W= G document - Info model: Charter time + 8 months to WG Document - IANA registry consideration + 12 months to WG Document - All Early Drafts to IESG: 18 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 - 18 months The WG will work closely with I2RS, Netconf and Netmod WGs. The WG will com= municate with external SDOs like ETSI NFV and will encourage open source co= de development related to the WG scope in organizations like ONF, OpenStack= , ODL, and OPNFV. --_000_9904FB1B0159DA42B0B887B7FA8119CA5CA376B9AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I missed this, sorry. = Sure – this is fine.

 

Thanks and Regards,

 

Dan<= /p>

 

 

From: Linda Du= nbar [mailto:linda.dunbar@huawei.com]
Sent: Friday, May 22, 2015 1:17 AM
To: Romascanu, Dan (Dan); 'i2nsf@ietf.org'
Subject: RE: Clean version of the narrower scoped I2NSF charter=

 

The version posted has= this statement:

 

[The WG may decide that = the Use cases, Framework, and Requirement are Informational documents or si= mply reference documents during the lifetime of the WG.]

 

Is it good enough?

 

Linda

From: Romascan= u, Dan (Dan) [mailto:dromasca@avaya.c= om]
Sent: Thursday, May 21, 2015 12:36 PM
To: Linda Dunbar; 'i2nsf@ietf.org'
Subject: RE: Clean version of the narrower scoped I2NSF charter=

 

This looks good to me.=

 

One thing based on a c= omment made by Kathleen earlier in the process. The IESG is not very sympat= hetic nowadays on the WGs spending resources on progressing use cases docum= ents to RFC. Same applies I think to the gap analysis, which is more a help tool while we define the scope of w= ork. Maybe it’s better to mark those deliverables in brackets with th= e note (the WG will decide if to proceed as RFC).

 

Thanks for progressing= this, Linda!

 

Regards,

 

Dan<= /p>

 

 

From: I2nsf [<= a href=3D"mailto:i2nsf-bounces@ietf.org">mailto:i2nsf-bounces@ietf.org] On Behalf Of Linda Dunbar
Sent: Thursday, May 21, 2015 8:01 PM
To: 'i2nsf@ietf.org'
Subject: [I2nsf] Clean version of the narrower scoped I2NSF charter<= o:p>

 

 

Network security functio= ns (NSFs) are provided and consumed in increasingly diverse environments. U= sers 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 o= f NSFs may offer their customers network security services that consist of = multiple security products and/or functions from different vendors. NSFs ma= y be provided by physical and/or virtualized infrastructure. Without standard interfaces to express, monito= r, and control security policies that govern the behavior of NSFs, it becom= es virtually impossible for security service providers to automate their se= rvice offerings that utilize different security functions from multiple vendors.

 =

The primary goal of I2NS= F is to define an information model,  a set of software interfaces and= data models for controlling and monitoring aspects of NSFs (both physical = and virtual). Other aspects of NSFs such as device or network provisioning and configuration are out of scope. Cont= rolling and monitoring of NSFs should include the use of policies to specif= y, query, monitor, and control the NSFs by one or more management entities. Since different security vendors support different features and func= tions on their devices, I2NSF will focus on flow-based NSFs that provide tr= eatment to packets/flows, such as IPS/IDS, Web filtering, flow filtering, d= eep packet inspection, or pattern matching and remediation.

 =

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

·         I2NSF Capability Layer

·         I2NSF Service Layer

 =

The I2NSF capability lay= er specifies how to control and monitor NSFs at functional level.  (I2= NSF will NOT work on any other aspects of NSFs including standardizing NSFs= or devices.  Nor will I2NSF at this stage specify how to derive control and monitoring capabilities from higher leve= l security policies for the Capability layer).  I2NSF will only standa= rdize the security policies related to the control and monitoring of the NS= Fs.  A sample capability layer construct for controlling NSFs is “subject-object-function-action”.

 =

The I2NSF Service Layer = defines how clients’ security policies may be expressed and monitored= . The Service Layer is out of scope for this phase of I2NSF’s work. H= owever, I2NSF will provide a forum for information drafts on data models, APIs, etc. that demonstrate how service layer polic= ies may be translated to Capability Layer functions.

 

The concrete work at the I2NSF Capability Layer incl= udes development of

-  &= nbsp;       An information mode= l that defines concepts required for standardizing the control  and mo= nitoring of NSFs,

-  &= nbsp;       A set of YANG data = models, derived from the above information model.

-  &= nbsp;       The capability regi= stry (IANA) that enables the characteristics and behavior of NSFs to be spe= cified using a vendor-neutral vocabulary without requiring the NSFs themsel= ves to be standardized; the registry enables various mechanisms, including policy rules, to be used to match mo= nitor and control functions to the needs of an application and/or environme= nt, and

-  &= nbsp;       The proper secure c= ommunication channels to carry the controlling and monitoring information b= etween the NSFs and their management entity (or entities).

 

 Standard interfaces for monitoring and control= ling the behavior of NSFs are essential building blocks for Security Servic= e Providers to automate the use of different NSFs from multiple vendors by = their Security management entities. This layer will leverage the existing protocols and data models defined by I2RS= , Netconf, and NETMOD.

 

It is a non-goal to create new protocols or data mod= eling languages for I2NSF interfaces.

The I2NSF WG’s deliverables include:

 

-       = ;   Use Cases document. <= /o:p>

-       = ;   Framework Document.

-       = ;   Requirements for extension= s (if any) to existing protocols used by the WG.

-       = ;    Gap analysis of exis= ting protocols and modeling languages for specifying, querying, monitoring,= and controlling NSFs.

-       = ;   A single, unified, Informa= tion Model for controlling and monitoring flow-based NSFs.

-       = ;   Corresponding YANG Data Mo= dels derived from the above Information Model.

-       = ;   IANA registry consideratio= n for flow-based NSFs controlling and monitoring capabilities.

-       = ;   (Optionally) Document desc= ribing how capabilities are used to monitor and control flow-based NSFs.

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

 

[The W= G may decide that the Use cases, Framework, and Requirement are Information= al documents or simply reference documents during the lifetime of the WG.]

 

Suggested Milestones

  - Use Cases Document:  Charter time += ; 1 month to WG Document

  - Framework: Charter time + 4 months to W= G Document

  - Requirements for extensions to protocols:&n= bsp; Charter time + 8 months to WG document

  - Info model: Charter time + 8 months to = WG Document

  - IANA registry consideration + 12 months= to WG Document

  - All Early Drafts to IESG: 18 months

 

[decision point – +10 months]  <= /o:p>

  - Data Models: Charter + 9 Months to= WG Document

  - Applicability Statements: 10 months to WG D= ocument

  - Data Models and Applicability Statements to= IESG  - 18 months

 

The WG will work closely with I2RS, Netconf and Netm= od WGs. The WG will communicate with external SDOs like ETSI NFV and will e= ncourage open source code development related to the WG scope in organizati= ons like ONF, OpenStack, ODL, and OPNFV.

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA5CA376B9AZFFEXMB04globa_-- From nobody Fri May 22 11:46:33 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBC061A0439 for ; Fri, 22 May 2015 11:46:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.81 X-Spam-Level: X-Spam-Status: No, score=-2.81 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Xg1pSaykZfJ for ; Fri, 22 May 2015 11:46:28 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 358BD1A039F for ; Fri, 22 May 2015 11:46:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id C63FE60810; Fri, 22 May 2015 14:46:26 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ALNsHlin-Hhs; Fri, 22 May 2015 14:46:21 -0400 (EDT) Received: from lx120e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 9FD8C6038A; Fri, 22 May 2015 14:46:19 -0400 (EDT) Message-ID: <555F797A.2030201@htt-consult.com> Date: Fri, 22 May 2015 14:46:18 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Linda Dunbar , "'i2nsf@ietf.org'" References: <4A95BA014132FF49AE685FAB4B9F17F657C46B24@dfweml701-chm> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657C46B24@dfweml701-chm> Content-Type: multipart/alternative; boundary="------------080108080406060201050703" Archived-At: Subject: Re: [I2nsf] Definition for "Network Security Functions" X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 18:46:32 -0000 This is a multi-part message in MIME format. --------------080108080406060201050703 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit As I look at this, I suddenly realize why I was having problems with "Network Security Functions". That is, i2nsf is not about "Network Security Functions", which include securing network datagrams from outsiders. WRT i2nsf usage of "Network Security Functions", I believe it is limited to Network protection security. Your definition does pretty much say that. I am having just a little problem with the grammer here. So I might say: "functions to deter and detect unwanted communications from negatively impacting the authorized communicatons in and out of a network amd ots attached entities." But I am not sure that is right also. I think I am missing a point here. On 05/21/2015 01:30 PM, Linda Dunbar wrote: > > Anyone object using this definition for “Network Security Functions”? > > “functions to ensure the communications in and out of network as well > as to deter and detect the unwanted communication from negatively > impacting the network and its attached entities.” > > Thanks, > > Linda** > > > > _______________________________________________ > I2nsf mailing list > I2nsf@ietf.org > https://www.ietf.org/mailman/listinfo/i2nsf --------------080108080406060201050703 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit As I look at this, I suddenly realize why I was having problems with "Network Security Functions".  That is, i2nsf is not about "Network Security Functions", which include securing network datagrams from outsiders.  WRT i2nsf usage of "Network Security Functions", I believe it is limited to Network protection security.  Your definition does pretty much say that.  I am having just a little problem with the grammer here.  So I might say:

"functions to deter and detect unwanted communications from negatively impacting the authorized communicatons in and out of a network amd ots attached entities."

But I am not sure that is right also.  I think I am missing a point here.

On 05/21/2015 01:30 PM, Linda Dunbar wrote:

Anyone object using this definition for “Network Security Functions”?

 

“functions to ensure the communications in and out of network as well as to deter and detect the unwanted communication from negatively impacting the network and its attached entities.”

 

Thanks,

 

Linda

 



_______________________________________________
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

--------------080108080406060201050703-- From nobody Fri May 22 11:48:48 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BE131A000A for ; Fri, 22 May 2015 11:48:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AEz5zP9bnthA for ; Fri, 22 May 2015 11:48:45 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 077771A0004 for ; Fri, 22 May 2015 11:48:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 79A5560933; Fri, 22 May 2015 14:48:43 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id CWc2TayG2-xM; Fri, 22 May 2015 14:48:36 -0400 (EDT) Received: from lx120e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id DB6E16038A; Fri, 22 May 2015 14:48:35 -0400 (EDT) Message-ID: <555F7A02.5080803@htt-consult.com> Date: Fri, 22 May 2015 14:48:34 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: DIEGO LOPEZ GARCIA , Linda Dunbar References: <4A95BA014132FF49AE685FAB4B9F17F657C46B24@dfweml701-chm> <52667987-C3D9-41D2-9237-6D849EC99E5F@telefonica.com> In-Reply-To: <52667987-C3D9-41D2-9237-6D849EC99E5F@telefonica.com> Content-Type: multipart/alternative; boundary="------------090208030201020005080900" Archived-At: Cc: "i2nsf@ietf.org" Subject: Re: [I2nsf] Definition for "Network Security Functions" X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 18:48:47 -0000 This is a multi-part message in MIME format. --------------090208030201020005080900 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit I like this better, but for the last part. What is 'it'? I personally have problems figuring out pronouns; others might as well. I think it needs to be explicitly expanded to "and deter unwanted activity of at least..." On 05/21/2015 09:24 PM, DIEGO LOPEZ GARCIA wrote: > Hi, > > What about something more detailed: > > "functions to ensure integrity, confidentiality and availability of > network communications, to detect unwanted activity, and to deter it > or at least mitigate its effects on the network" > > > On 22 May 2015, at 01:30 , Linda Dunbar > wrote: > >> Anyone object using this definition for “Network Security Functions”? >> “functions to ensure the communications in and out of network as well >> as to deter and detect the unwanted communication from negatively >> impacting the network and its attached entities.” >> Thanks, >> Linda** >> _______________________________________________ >> I2nsf mailing list >> I2nsf@ietf.org >> 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: diego.r.lopez@telefonica.com > 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 > > > _______________________________________________ > I2nsf mailing list > I2nsf@ietf.org > https://www.ietf.org/mailman/listinfo/i2nsf --------------090208030201020005080900 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit I like this better, but for the last part.  What is 'it'?  I personally have problems figuring out pronouns; others might as well.  I think it needs to be explicitly expanded to

"and deter unwanted activity of at least..."

On 05/21/2015 09:24 PM, DIEGO LOPEZ GARCIA wrote:
Hi,

What about something more detailed:

"functions to ensure integrity, confidentiality and availability of network communications, to detect unwanted activity, and to deter it or at least mitigate its effects on the network"


On 22 May 2015, at 01:30 , Linda Dunbar <linda.dunbar@huawei.com> wrote:

Anyone object using this definition for “Network Security Functions”?
 
“functions to ensure the communications in and out of network as well as to deter and detect the unwanted communication from negatively impacting the network and its attached entities.”
 
Thanks,
 
Linda
 
_______________________________________________
I2nsf mailing list
I2nsf@ietf.org
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: diego.r.lopez@telefonica.com
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
 

_______________________________________________
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

--------------090208030201020005080900-- From nobody Fri May 22 11:50:11 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E92C1A000B for ; Fri, 22 May 2015 11:50:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9rlpJZF7E4Xn for ; Fri, 22 May 2015 11:49:58 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2F971A0019 for ; Fri, 22 May 2015 11:49:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 7445A6038A; Fri, 22 May 2015 14:49:55 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id xXUKlUAqvip1; Fri, 22 May 2015 14:49:44 -0400 (EDT) Received: from lx120e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 9CAF860810; Fri, 22 May 2015 14:49:43 -0400 (EDT) Message-ID: <555F7A46.6050006@htt-consult.com> Date: Fri, 22 May 2015 14:49:42 -0400 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Kathleen Moriarty , Linda Dunbar References: <4A95BA014132FF49AE685FAB4B9F17F657C46AD8@dfweml701-chm> <9904FB1B0159DA42B0B887B7FA8119CA5CA369D5@AZ-FFEXMB04.global.avaya.com> <4A95BA014132FF49AE685FAB4B9F17F657C46CDD@dfweml701-chm> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050608030200050400020409" Archived-At: Cc: "i2nsf@ietf.org" , "Romascanu, Dan \(Dan\)" Subject: Re: [I2nsf] Clean version of the narrower scoped I2NSF charter X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 18:50:01 -0000 This is a multi-part message in MIME format. --------------050608030200050400020409 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit +1 On 05/21/2015 06:32 PM, Kathleen Moriarty wrote: > > > On Thu, May 21, 2015 at 6:16 PM, Linda Dunbar > wrote: > > The version posted has this statement: > > [The WG may decide that the Use cases, Framework, and Requirement > are Informational documents or simply reference documents during > the lifetime of the WG.] > > Is it good enough? > > > That is helpful, thank you. It's good to not waste too much time on > these types of documents so the work can start. > > Kathleen > > Linda > > *From:*Romascanu, Dan (Dan) [mailto:dromasca@avaya.com > ] > *Sent:* Thursday, May 21, 2015 12:36 PM > *To:* Linda Dunbar; 'i2nsf@ietf.org ' > *Subject:* RE: Clean version of the narrower scoped I2NSF charter > > This looks good to me. > > One thing based on a comment made by Kathleen earlier in the > process. The IESG is not very sympathetic nowadays on the WGs > spending resources on progressing use cases documents to RFC. Same > applies I think to the gap analysis, which is more a help tool > while we define the scope of work. Maybe it’s better to mark those > deliverables in brackets with the note (the WG will decide if to > proceed as RFC). > > Thanks for progressing this, Linda! > > Regards, > > Dan > > *From:*I2nsf [mailto:i2nsf-bounces@ietf.org] *On Behalf Of *Linda > Dunbar > *Sent:* Thursday, May 21, 2015 8:01 PM > *To:* 'i2nsf@ietf.org ' > *Subject:* [I2nsf] Clean version of the narrower scoped I2NSF charter > > Network security functions (NSFs) are 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 of NSFs may offer their > customers network security services that consist of multiple > security products and/or functions from different vendors. NSFs > may be provided by physical and/or virtualized infrastructure. > Without standard interfaces to express, monitor, and control > security policies that govern the behavior of NSFs, it becomes > virtually impossible for security service providers to automate > their service offerings that utilize different security functions > from multiple vendors. > > The primary goal of I2NSF is to define an information model, a > set of software interfaces and data models for controlling and > monitoring aspects of NSFs (both physical and virtual). Other > aspects of NSFs such as device or network provisioning and > configuration are out of scope. Controlling and monitoring of NSFs > should include the use of policies to specify, query, monitor, and > control the NSFs by one or more management entities. Since > different security vendors support different features and > functions on their devices, I2NSF will focus on flow-based NSFs > that provide treatment to packets/flows, such as IPS/IDS, Web > filtering, flow filtering, deep packet inspection, or pattern > matching and remediation. > > There are two layers of interfaces envisioned in the I2NSF approach: > > ·I2NSF Capability Layer > > ·I2NSF Service Layer > > The I2NSF capability layer specifies how to control and monitor > NSFs at functional level. (I2NSF will NOT work on any other > aspects of NSFs including standardizing NSFs or devices. Nor will > I2NSF at this stage specify how to derive control and monitoring > capabilities from higher level security policies for the > Capability layer). I2NSF will only standardize the security > policies related to the control and monitoring of the NSFs. A > sample capability layer construct for controlling NSFs is > “subject-object-function-action”. > > The I2NSF Service Layer defines how clients’ security policies may > be expressed and monitored. The Service Layer is out of scope for > this phase of I2NSF’s work. However, I2NSF will provide a forum > for information drafts on data models, APIs, etc. that demonstrate > how service layer policies may be translated to Capability Layer > functions. > > The concrete work at the I2NSF Capability Layer includes > development of > > -An information model that defines concepts required for > standardizing the control and monitoring of NSFs, > > -A set of YANG data models, derived from the above information model. > > -The capability registry (IANA) that enables the characteristics > and behavior of NSFs to be specified using a vendor-neutral > vocabulary without requiring the NSFs themselves to be > standardized; the registry enables various mechanisms, including > policy rules, to be used to match monitor and control functions to > the needs of an application and/or environment, and > > -The proper secure communication channels to carry the controlling > and monitoring information between the NSFs and their management > entity (or entities). > > Standard interfaces for monitoring and controlling the behavior > of NSFs are essential building blocks for Security Service > Providers to automate the use of different NSFs from multiple > vendors by their Security management entities. This layer will > leverage the existing protocols and data models defined by I2RS, > Netconf, and NETMOD. > > It is a non-goal to create new protocols or data modeling > languages for I2NSF interfaces. > > The I2NSF WG’s deliverables include: > > -Use Cases document. > > -Framework Document. > > -Requirements for extensions (if any) to existing protocols used > by the WG. > > - Gap analysis of existing protocols and modeling languages for > specifying, querying, monitoring, and controlling NSFs. > > -A single, unified, Information Model for controlling and > monitoring flow-based NSFs. > > -Corresponding YANG Data Models derived from the above Information > Model. > > -IANA registry consideration for flow-based NSFs controlling and > monitoring capabilities. > > -(Optionally) Document describing how capabilities are used to > monitor and control flow-based NSFs. > > -(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.] > > Suggested Milestones > > - Use Cases Document: Charter time + 1 month to WG Document > > - Framework: Charter time + 4 months to WG Document > > - Requirements for extensions to protocols: Charter time + 8 > months to WG document > > - Info model: Charter time + 8 months to WG Document > > - IANA registry consideration + 12 months to WG Document > > - All Early Drafts to IESG: 18 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 - 18 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 OPNFV. > > > _______________________________________________ > I2nsf mailing list > I2nsf@ietf.org > https://www.ietf.org/mailman/listinfo/i2nsf > > > > > -- > > Best regards, > Kathleen > > > _______________________________________________ > I2nsf mailing list > I2nsf@ietf.org > https://www.ietf.org/mailman/listinfo/i2nsf --------------050608030200050400020409 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit +1



On 05/21/2015 06:32 PM, Kathleen Moriarty wrote:


On Thu, May 21, 2015 at 6:16 PM, Linda Dunbar <linda.dunbar@huawei.com> wrote:

The version posted has this statement:

 

[The WG may decide that the Use cases, Framework, and Requirement are Informational documents or simply reference documents during the lifetime of the WG.]

 

Is it good enough?


That is helpful, thank you.  It's good to not waste too much time on these types of documents so the work can start.

Kathleen
 

 

Linda

From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]
Sent: Thursday, May 21, 2015 12:36 PM
To: Linda Dunbar; 'i2nsf@ietf.org'
Subject: RE: Clean version of the narrower scoped I2NSF charter

 

This looks good to me.

 

One thing based on a comment made by Kathleen earlier in the process. The IESG is not very sympathetic nowadays on the WGs spending resources on progressing use cases documents to RFC. Same applies I think to the gap analysis, which is more a help tool while we define the scope of work. Maybe it’s better to mark those deliverables in brackets with the note (the WG will decide if to proceed as RFC).

 

Thanks for progressing this, Linda!

 

Regards,

 

Dan

 

 

From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Linda Dunbar
Sent: Thursday, May 21, 2015 8:01 PM
To: 'i2nsf@ietf.org'
Subject: [I2nsf] Clean version of the narrower scoped I2NSF charter

 

 

Network security functions (NSFs) are 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 of NSFs may offer their customers network security services that consist of multiple security products and/or functions from different vendors. NSFs may be provided by physical and/or virtualized infrastructure. Without standard interfaces to express, monitor, and control security policies that govern the behavior of NSFs, it becomes virtually impossible for security service providers to automate their service offerings that utilize different security functions from multiple vendors.

 

The primary goal of I2NSF is to define an information model,  a set of software interfaces and data models for controlling and monitoring aspects of NSFs (both physical and virtual). Other aspects of NSFs such as device or network provisioning and configuration are out of scope. Controlling and monitoring of NSFs should include the use of policies to specify, query, monitor, and control the NSFs by one or more management entities. Since different security vendors support different features and functions on their devices, I2NSF will focus on flow-based NSFs that provide treatment to packets/flows, such as IPS/IDS, Web filtering, flow filtering, deep packet inspection, or pattern matching and remediation.

 

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

·       I2NSF Capability Layer

·       I2NSF Service Layer

 

The I2NSF capability layer specifies how to control and monitor NSFs at functional level.  (I2NSF will NOT work on any other aspects of NSFs including standardizing NSFs or devices.  Nor will I2NSF at this stage specify how to derive control and monitoring capabilities from higher level security policies for the Capability layer).  I2NSF will only standardize the security policies related to the control and monitoring of the NSFs.  A sample capability layer construct for controlling NSFs is “subject-object-function-action”.

 

The I2NSF Service Layer defines how clients’ security policies may be expressed and monitored. The Service Layer is out of scope for this phase of I2NSF’s work. However, I2NSF will provide a forum for information drafts on data models, APIs, etc. that demonstrate how service layer policies may be translated to Capability Layer functions.

 

The concrete work at the I2NSF Capability Layer includes development of

-          An information model that defines concepts required for standardizing the control  and monitoring of NSFs,

-          A set of YANG data models, derived from the above information model.

-          The capability registry (IANA) that enables the characteristics and behavior of NSFs to be specified using a vendor-neutral vocabulary without requiring the NSFs themselves to be standardized; the registry enables various mechanisms, including policy rules, to be used to match monitor and control functions to the needs of an application and/or environment, and

-          The proper secure communication channels to carry the controlling and monitoring information between the NSFs and their management entity (or entities).

 

 Standard interfaces for monitoring and controlling the behavior of NSFs are essential building blocks for Security Service Providers to automate the use of different NSFs from multiple vendors by their Security management entities. This layer will leverage the existing protocols and data models defined by I2RS, Netconf, and NETMOD.

 

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

The I2NSF WG’s deliverables include:

 

-          Use Cases document.

-          Framework Document.

-          Requirements for extensions (if any) to existing protocols used by the WG.

-           Gap analysis of existing protocols and modeling languages for specifying, querying, monitoring, and controlling NSFs.

-          A single, unified, Information Model for controlling and monitoring flow-based NSFs.

-          Corresponding YANG Data Models derived from the above Information Model.

-          IANA registry consideration for flow-based NSFs controlling and monitoring capabilities.

-          (Optionally) Document describing how capabilities are used to monitor and control flow-based NSFs.

-          (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.]

 

Suggested Milestones

  - Use Cases Document:  Charter time + 1 month to WG Document

  - Framework: Charter time + 4 months to WG Document

  - Requirements for extensions to protocols:  Charter time + 8 months to WG document

  - Info model: Charter time + 8 months to WG Document

  - IANA registry consideration + 12 months to WG Document

  - All Early Drafts to IESG: 18 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  - 18 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 OPNFV.

 


_______________________________________________
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf




--

Best regards,
Kathleen


_______________________________________________
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

--------------050608030200050400020409-- From nobody Sat May 23 05:57:34 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD8951ACDEC for ; Sat, 23 May 2015 05:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rE9ugKHjC5Su for ; Sat, 23 May 2015 05:57:28 -0700 (PDT) Received: from smtptc.telefonica.com (smtptc.telefonica.com [195.76.34.108]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D14881ACDF6 for ; Sat, 23 May 2015 05:57:24 -0700 (PDT) Received: from smtptc.telefonica.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id ADA36880BB; Sat, 23 May 2015 14:57:21 +0200 (CEST) Received: from ESTGVMSP113.EUROPE.telefonica.corp (unknown [10.92.4.9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtptc.telefonica.com (Postfix) with ESMTPS id 9C64E8803E; Sat, 23 May 2015 14:57:21 +0200 (CEST) Received: from emea01-db3-obe.outbound.protection.outlook.com (10.92.5.139) by tls.telefonica.com (10.92.6.55) with Microsoft SMTP Server (TLS) id 14.3.195.1; Sat, 23 May 2015 14:57:20 +0200 Received: from DB4PR06MB0624.eurprd06.prod.outlook.com (25.161.13.142) by DB4PR06MB0623.eurprd06.prod.outlook.com (25.161.13.141) with Microsoft SMTP Server (TLS) id 15.1.166.22; Sat, 23 May 2015 12:57:19 +0000 Received: from DB4PR06MB0624.eurprd06.prod.outlook.com ([25.161.13.142]) by DB4PR06MB0624.eurprd06.prod.outlook.com ([25.161.13.142]) with mapi id 15.01.0166.017; Sat, 23 May 2015 12:57:19 +0000 From: DIEGO LOPEZ GARCIA To: Robert Moskowitz Thread-Topic: [I2nsf] Definition for "Network Security Functions" Thread-Index: AdCT68W6aC/heUYRRaG527iXhQCbpwAQj5CAACR46wAAJgXjgA== Date: Sat, 23 May 2015 12:57:18 +0000 Message-ID: References: <4A95BA014132FF49AE685FAB4B9F17F657C46B24@dfweml701-chm> <52667987-C3D9-41D2-9237-6D849EC99E5F@telefonica.com> <555F7A02.5080803@htt-consult.com> In-Reply-To: <555F7A02.5080803@htt-consult.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=diego.r.lopez@telefonica.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [124.127.168.171] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB4PR06MB0623; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(520002)(3002001); SRVR:DB4PR06MB0623; BCL:0; PCL:0; RULEID:; SRVR:DB4PR06MB0623; x-forefront-prvs: 0585417D7B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(164054003)(24454002)(40134004)(25724002)(377454003)(252514010)(199003)(479174004)(189002)(2900100001)(50986999)(7110500001)(189998001)(76176999)(54356999)(15975445007)(102836002)(92566002)(5890100001)(2950100001)(77156002)(5001960100002)(4001540100001)(62966003)(68736005)(5001860100001)(97736004)(81156007)(110136002)(5001830100001)(2420400003)(101416001)(19617315012)(16236675004)(106356001)(87936001)(2656002)(105586002)(19580405001)(86362001)(64706001)(83716003)(46102003)(40100003)(66066001)(33656002)(122556002)(36756003)(19580395003)(82746002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR06MB0623; H:DB4PR06MB0624.eurprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: telefonica.com does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_F77D3A3FB4E647A786C8856817136121telefonicacom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 May 2015 12:57:18.7247 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR06MB0623 X-OriginatorOrg: telefonica.com X-TM-AS-MML: No Archived-At: Cc: "i2nsf@ietf.org" , Linda Dunbar Subject: Re: [I2nsf] Definition for "Network Security Functions" X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2015 12:57:33 -0000 --_000_F77D3A3FB4E647A786C8856817136121telefonicacom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Nothing to object. Avoiding pronouns in composed sentences was one of the g= uidelines I remember from a paper on how to write scientific documentation.= .. Be goode, On 23 May 2015, at 02:48 , Robert Moskowitz > wrote: I like this better, but for the last part. What is 'it'? I personally hav= e problems figuring out pronouns; others might as well. I think it needs t= o be explicitly expanded to "and deter unwanted activity of at least..." On 05/21/2015 09:24 PM, DIEGO LOPEZ GARCIA wrote: Hi, What about something more detailed: "functions to ensure integrity, confidentiality and availability of network= communications, to detect unwanted activity, and to deter it or at least m= itigate its effects on the network" On 22 May 2015, at 01:30 , Linda Dunbar > wrote: Anyone object using this definition for =93Network Security Functions=94? =93functions to ensure the communications in and out of network as well as = to deter and detect the unwanted communication from negatively impacting th= e network and its attached entities.=94 Thanks, Linda _______________________________________________ I2nsf mailing list I2nsf@ietf.org 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: diego.r.lopez@telefonica.com Tel: +34 913 129 041 Mobile: +34 682 051 091 ---------------------------------- ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o= copia sin autorizaci=F3n puede estar prohibida en virtud de la legislaci= =F3n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo = comunique inmediatamente por esta misma v=EDa y proceda a su destrucci=F3n. The information contained in this transmission is privileged and confidenti= al 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 co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, div= ulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o pode estar proibida em virtude= da legisla=E7=E3o vigente. Se recebeu esta mensagem por erro, rogamos-lhe = que nos o comunique imediatamente por esta mesma via e proceda a sua destru= i=E7=E3o _______________________________________________ I2nsf mailing list I2nsf@ietf.org 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: diego.r.lopez@telefonica.com Tel: +34 913 129 041 Mobile: +34 682 051 091 ---------------------------------- ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o= copia sin autorizaci=F3n puede estar prohibida en virtud de la legislaci= =F3n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo = comunique inmediatamente por esta misma v=EDa y proceda a su destrucci=F3n. The information contained in this transmission is privileged and confidenti= al 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 co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, div= ulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o pode estar proibida em virtude= da legisla=E7=E3o vigente. Se recebeu esta mensagem por erro, rogamos-lhe = que nos o comunique imediatamente por esta mesma via e proceda a sua destru= i=E7=E3o --_000_F77D3A3FB4E647A786C8856817136121telefonicacom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Nothing to object. Avoiding pronouns in composed sentences was one of the g= uidelines I remember from a paper on how to write scientific documentation.= ..

Be goode,

On 23 May 2015, at 02:48 , Robert Moskowitz <rgm-ietf@htt-consult.com> wrote:

I like this better, but for the l= ast part.  What is 'it'?  I personally have problems figuring out= pronouns; others might as well.  I think it needs to be explicitly ex= panded to

"and deter unwanted activity of at least..."

On 05/21/2015 09:24 PM, DIEGO LOPEZ GARCIA w= rote:
Hi,

What about something more detailed:

"functions to ensure integrity, confidentiality and availability = of network communications, to detect unwanted activity, and to deter it or = at least mitigate its effects on the network"


On 22 May 2015, at 01:30 , Linda Dunbar <linda.dunbar@huawei.com> w= rote:

Anyone object using this definition for =93Network Security Functions=94?
 
=93functions to ensure the communications in and out of network as well as = to deter and detect the unwanted communication from negatively impacting th= e network and its attached entities.=94
 
Thanks,
 
Linda
 
_______________________________________________
I2nsf mailing list
I2nsf@ietf.org
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: diego.r.lopez@telefonica.com
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------



Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o copia sin autorizaci=F3n puede e= star prohibida en virtud de la legislaci=F3n vigente. Si ha recibido este m= ensaje por error, le rogamos que nos lo comunique inmediatamente por esta m= isma v=EDa y proceda a su destrucci=F3n.

The information contained in this transmission is privileged and confidenti= al 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 y= ou have received this transmission in error, do not read it. Please immedia= tely 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=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, divulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o p= ode estar proibida em virtude da legisla=E7=E3o vigente. Se recebeu esta me= nsagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mes= ma via e proceda a sua destrui=E7=E3o


_______________________________________________
I2nsf mailing list
I2nsf@=
ietf.org
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.lo= pez/

e-mail: diego.r.lopez@telefonica.com
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------



Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o copia sin autorizaci=F3n puede e= star prohibida en virtud de la legislaci=F3n vigente. Si ha recibido este m= ensaje por error, le rogamos que nos lo comunique inmediatamente por esta m= isma v=EDa y proceda a su destrucci=F3n.

The information contained in this transmission is privileged and confidenti= al 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 y= ou have received this transmission in error, do not read it. Please immedia= tely 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=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, divulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o p= ode estar proibida em virtude da legisla=E7=E3o vigente. Se recebeu esta me= nsagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mes= ma via e proceda a sua destrui=E7=E3o
 --_000_F77D3A3FB4E647A786C8856817136121telefonicacom_-- From nobody Sun May 24 20:26:37 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8C801A894C for ; Sun, 24 May 2015 20:26:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DlHStRoqMvTa for ; Sun, 24 May 2015 20:26:32 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 360451A894B for ; Sun, 24 May 2015 20:26:32 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BSX40854; Mon, 25 May 2015 03:26:30 +0000 (GMT) Received: from SZXEMA411-HUB.china.huawei.com (10.82.72.70) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 25 May 2015 04:26:29 +0100 Received: from SZXEMA502-MBS.china.huawei.com ([169.254.4.143]) by szxema411-hub.china.huawei.com ([10.82.72.70]) with mapi id 14.03.0158.001; Mon, 25 May 2015 11:26:22 +0800 From: "Xialiang (Frank)" To: "i2nsf@ietf.org" Thread-Topic: New Version Notification for draft-xia-i2nsf-capability-interface-im-01.txt Thread-Index: AQHQlphEgSOfVMKh10aiqbJpotmI/Z2MA3yQ Date: Mon, 25 May 2015 03:26:21 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.135.43.91] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [I2nsf] New Version Notification for draft-xia-i2nsf-capability-interface-im-01.txt X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 May 2015 03:26:36 -0000 SGkgYWxsOg0KV2Ugc3VibWl0IGEgbmV3IHZlcnNpb24gZHJhZnQgb2YgSTJOU0YgY2FwYWJpbGl0 eSBpbnRlcmZhY2UsIHdoaWNoIG1haW5seSBpbmNsdWRlIHRoZSBmb2xsb3dpbmcgdXBkYXRlczoN CjEuIHdlIGhhdmUgYSBuZXcgY28tYXV0aG9yOiBOaWNvbGFzIEJPVVRIT1JTIGZyb20gUW9zbW9z Ow0KMi4gd2UgaW50cm9kdWNlIHRoZSBwYWNrZXQtYmFzZWQgcGFyYWRpZ20gaW50byB0aGUgZHJh ZnQgdG8gY2xhcmlmeSB0aGUgTlNGJ3MgZnVuY3Rpb24gcHJvY2VzcyBtb3JlIGNsZWFybHk7DQoz LiBiYXNlZCBvbiB0aGUgcGFja2V0LWJhc2VkIHBhcmFkaWdtLCB3ZSByZS1kZXNpZ25lZCB0aGUg SU0gZm9yIHRoZSBJMk5TRiBjYXBhYmlsaXR5IGludGVyZmFjZSBhbmQgbW9kaWZ5IHRoZSByZWxh dGVkIGRlc2NyaXB0aW9uOw0KNC4gd2UgYWxzbyBnYXZlIHNvbWUgY2F0ZWdvcmljYWwgZXhhbXBs ZXMgb2YgdGhlIE5TRiBjYXBhYmlsaXRpZXMgZnJvbSB0aGUgcGVyc3BlY3RpdmUgb2Ygc3ViamVj dC1vYmplY3QtYWN0aW9uLWZ1bmN0aW9uLg0KDQpZb3VyIGNvbW1lbnRzIGFyZSBhcHByZWNpYXRl ZCENCg0KQi5SLg0KRnJhbmsNCg0KLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0K5Y+R5Lu25Lq6OiBp bnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmdd IA0K5Y+R6YCB5pe26Ze0OiAyMDE15bm0NeaciDI15pelIDExOjEwDQrmlLbku7bkuro6IERhY2hl bmcgWmhhbmc7IERhQ2hlbmcgWmhhbmc7IFhpYWxpYW5nIChGcmFuayk7IE5pY29sYXMgQm91dGhv cnM7IE5pY29sYXMgQk9VVEhPUlM7IFhpYWxpYW5nIChGcmFuaykNCuS4u+mimDogTmV3IFZlcnNp b24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC14aWEtaTJuc2YtY2FwYWJpbGl0eS1pbnRlcmZhY2Ut aW0tMDEudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXhpYS1pMm5zZi1jYXBh YmlsaXR5LWludGVyZmFjZS1pbS0wMS50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0 ZWQgYnkgTGlhbmcgWGlhIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFt ZToJCWRyYWZ0LXhpYS1pMm5zZi1jYXBhYmlsaXR5LWludGVyZmFjZS1pbQ0KUmV2aXNpb246CTAx DQpUaXRsZToJCUluZm9ybWF0aW9uIE1vZGVsIG9mIEludGVyZmFjZSB0byBOZXR3b3JrIFNlY3Vy aXR5IEZ1bmN0aW9ucyBDYXBhYmlsaXR5IEludGVyZmFjZQ0KRG9jdW1lbnQgZGF0ZToJMjAxNS0w NS0yNQ0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOgkJMTcNClVSTDogICAg ICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQteGlhLWky bnNmLWNhcGFiaWxpdHktaW50ZXJmYWNlLWltLTAxLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXhpYS1pMm5zZi1jYXBhYmlsaXR5LWlu dGVyZmFjZS1pbS8NCkh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQteGlhLWkybnNmLWNhcGFiaWxpdHktaW50ZXJmYWNlLWltLTAxDQpEaWZmOiAgICAgICAg ICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXhpYS1pMm5zZi1jYXBh YmlsaXR5LWludGVyZmFjZS1pbS0wMQ0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZHJhZnQgaXMgZm9j dXNlZCBvbiB0aGUgbm9ydGgtYm91bmQgaW50ZXJmYWNlIG9mIE5TRnMgKE5ldHdvcmsNCiAgIFNl Y3VyaXR5IEZ1bmN0aW9ucykgYW5kIHByb3Bvc2VzIGFuIGluZm9ybWF0aW9uIG1vZGVsIGZvcg0K ICAgY29uZmlndXJpbmcgdmFyaW91cyBraW5kcyBOU0Ygc2VjdXJpdHkgZnVuY3Rpb25zLCBiYXNl ZCBvbiB0aGUNCiAgIHBhY2tldC1iYXNlZCBwYXJhZGlnbS4gVGhlIFlhbmcgc3RydWN0dXJlIGFu ZCB1c2UgZXhhbXBsZXMgYXJlIGFsc28NCiAgIHByZXNlbnRlZCB0byBjbGFyaWZ5IGhvdyB0byB1 c2UgdGhlIGluZm9ybWF0aW9uIG1vZGVsLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoN Cg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20g dGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlm ZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlh dA0KDQo= From nobody Mon May 25 11:26:08 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76C481A8F4D for ; Fri, 22 May 2015 20:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.225 X-Spam-Level: X-Spam-Status: No, score=0.225 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n30n_u8qqwUO for ; Fri, 22 May 2015 20:37:05 -0700 (PDT) Received: from pacdcmhout01.cable.comcast.com (PACDCMHOUT01.cable.comcast.com [68.87.31.167]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D55A61A8F4A for ; Fri, 22 May 2015 20:37:04 -0700 (PDT) X-AuditID: 44571fa7-f79216d000002c77-d2-555ff5df912e Received: from PACDCEXHUB03.cable.comcast.com (dlpemail-wc-2p.sys.comcast.net [24.40.12.145]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by pacdcmhout01.cable.comcast.com (SMTP Gateway) with SMTP id B3.7A.11383.FD5FF555; Fri, 22 May 2015 23:37:03 -0400 (EDT) Received: from PACDCEXMB13.cable.comcast.com ([169.254.5.13]) by PACDCEXHUB03.cable.comcast.com ([fe80::7da6:458a:eadf:dadb%16]) with mapi id 14.03.0181.006; Fri, 22 May 2015 23:37:03 -0400 From: "Toy, Mehmet" To: list Thread-Topic: can you comment on the I2NSF problem space? Thread-Index: AQHQlMY9ogK9G31MQkCd9vVIuVR/wZ2I1zhg Date: Sat, 23 May 2015 03:37:01 +0000 Message-ID: References: <4A95BA014132FF49AE685FAB4B9F17F657C49A05@dfweml701-chm> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657C49A05@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.40.1.141] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrHIsWRmVeSWpSXmKPExsUiocEzUff+1/hQg+m3zCy+/vzBavHo/AN2 i3t3/7Fa/L56itGBxePgyjnsHkuW/GTyaP0u6vGk/RhrAEsUl01Kak5mWWqRvl0CV8aVGYeZ Cj6oVSzcJ9/A+EG1i5GTQ0LARKLn2xZmCFtM4sK99WxdjFwcQgLbmCSebprECuEcZJS40tnI AlLFJmAkMe/IVTBbREBS4vnPv+wgRcwC7xglOs5/ZwdJCAtYSDT+XscMUWQpcf/mDyCbA8g2 kti/3wMkzCKgKrF5yyVGEJtXIERi7/sWsFYhAReJVYuegs3nFHCV+PXsFZjNCHTd91NrmEBs ZgFxiVtP5jNBXC0gsWTPeagPRCVePv7HCmHLSzQ1TWcHWcssoCmxfpc+RKuixJTuh+wQawUl Ts58wgJRLi5x+MgO1gmM4rOQbJiF0D0LSfcsJN0LGFlWMcoVJCanJOdm5JeWGBjqJScm5aTq JefnJicWl4DoTYzAWHQJl1++g/HeC6dDjAIcjEo8vEzAGBViTSwrrsw9xCjBwawkwuv6DijE m5JYWZValB9fVJqTWnyIUZqDRUmc98iv2FAhgfTEktTs1NSC1CKYLBMHp1QDo/u9gyFHSjce velbUVeyaeOaxVUaV6Ujf+z93q7d9i5jX6JlzcIp653L9p7Ker7nsM2XGMem1hbxz5cFnCqO 8f3jfv+25VRM1XGpFCYtl9Yb0xWY7vgHqp464en16VT39z0XtC995swP/Nh/f2OcJJN0oG/O WnPz44tLbph3bG1kCP++4aPpPSWW4oxEQy3mouJEALRo/XjBAgAA Archived-At: X-Mailman-Approved-At: Mon, 25 May 2015 11:26:06 -0700 Cc: "Romascanu, Dan \(Dan\) \(dromasca@avaya.com\)" , "Hongwen Zhang \(hongwen.zhang@wedgenetworks.com\)" , "Schell, Richard C \(richard.schell@verizon.com\)" Subject: Re: [I2nsf] can you comment on the I2NSF problem space? X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2015 03:37:09 -0000 TGluZGEsDQpBIGNvdXBsZSBjb21tZW50czoNCjEuICBJbiAzLjQsICJUb2RheSB0aGVyZSBpcyBu byBzdGFuZGFyZCBpbnRlcmZhY2UgdG8gZXhjaGFuZ2Ugc2VjdXJpdHkgcHJvZmlsZXMNCiAgICAg YmV0d2VlbiBvcmdhbml6YXRpb25zLiIgIE9wZW4gQ2xvdWQgQ29ubmVjdCBBcmNoaXRlY3R1cmUg bWFkZSBhbiBhdHRlbXB0IHRvIGRlc2NyaWJlIHRoZSBpbnRlcmZhY2UgYW5kIGl0cyBhc3NvY2lh dGVkIGF0dHJpYnV0ZXMuIEZ1cnRoZXIgd29yayBpcyBiZWluZyBkb25lIGJ5IE9DQyBUZWNobmlj YWwgQ29tbWl0dGVlLiAgWW91IG1pZ2h0IHJlZmVyZW5jZSB0aGUgT0NDIEFyY2guIERvY3VtZW50 Lg0KIDIuICBJbiA0LCAiSTJOU0YgQ2FwYWJpbGl0eSBMYXllcg0KICAgICAgICAgICAgICAgLSBJ Mk5TRiBTZXJ2aWNlIExheWVyIi4gDQpDYXBhYmlsaXR5IExheWVyIHNvdW5kcyBsaWtlIE9BTSBs YXllci4gU2hvdWxkIHlvdSByZXBsYWNlIENhcGFiaWxpdHkgTGF5ZXIgd2l0aCBPQU0gTGF5ZXI/ DQozLiAgICBpbiA2LjQsIHlvdSBjYW4gbWVudGlvbiBPQ0MuIE9DQyBUQyBpcyBhbHNvIHdvcmtp bmcgb24gU0VDYWFTLg0KSG9uZ3dlbiBtaWdodCBiZSBhYmxlIHRvIHBvaW50IHlvdSBhIHRvIGEg ZG9jdW1lbnQgdGhhdCBoZSBpcyB3b3JraW5nIG9uLg0KDQpUaGFua3MNCk1laG1ldA0KDQoNCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBMaW5kYSBEdW5iYXIgDQpTZW50OiBUaHVy c2RheSwgTWF5IDIxLCAyMDE1IDU6NDMgUE0NClRvOiAnaTJuc2ZAaWV0Zi5vcmcnDQpTdWJqZWN0 OiB1cGRhdGVkIEkyTlNGIHByb2JsZW0gc3RhdGVtZW50IHRvIHJlZmxlY3QgdGhlIG5hcnJvd2Vy IHNjb3BlZCBjaGFydGVyDQoNCldlIHVwZGF0ZWQgdGhlIEkyTlNGIHByb2JsZW0gc3RhdGVtZW50 IHRvIHJlZmxlY3QgdGhlIG5hcnJvd2VyIHNjb3BlZCBjaGFydGVyLiANCg0KVGhlIHByaW1hcnkg aXNzdWVzIGFuZCBjaGFsbGVuZ2VzIGZhY2luZyBOU0ZzIGhvc3RlZCBieSBkaWZmZXJlbnQgZG9t YWlucyBhcmU6DQoNCiAgICAgIDMuMS4gQ2hhbGxlbmdlcyBGYWNpbmcgU2VjdXJpdHkgU2Vydmlj ZSBQcm92aWRlcnMuLi4uLi4uLi4uLi4uLjUNCiAgICAgICAgIDMuMS4xLiBEaXZlcnNlIHR5cGVz IG9mIFNlY3VyaXR5IEZ1bmN0aW9ucy4uLi4uLi4uLi4uLi4uLi4uLjUNCiAgICAgICAgIDMuMS4y LiBObyBTdGFuZGFyZCBDaGFyYWN0ZXJpemF0aW9uIG9mIE5TRnMuLi4uLi4uLi4uLi4uLi4uLjYN CiAgICAgICAgIDMuMS4zLiBNb3JlIERpc3RyaWJ1dGVkIE5TRnMgYW5kIHZOU0ZzLi4uLi4uLi4u Li4uLi4uLi4uLi4uLjcNCiAgICAgICAgIDMuMS40LiBNb3JlIERlbWFuZCB0byBDb250cm9sIE5T RnMgRHluYW1pY2FsbHkuLi4uLi4uLi4uLi4uLjcNCiAgICAgICAgIDMuMS41LiBEaXZlcnNlIElu dGVyZmFjZXMgdG8gQ29udHJvbCBhbmQgTW9uaXRvciBOU0ZzLi4uLi4uLjcNCiAgICAgICAgIDMu MS42LiBMYWNrIG9mIG1lY2hhbmlzbSB0byBtb25pdG9yIHRoZSBiZWhhdmlvciBvZiBOU0ZzLi4u LjgNCiAgICAgIDMuMi4gQ2hhbGxlbmdlcyBGYWNpbmcgQ3VzdG9tZXJzLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLjgNCiAgICAgICAgIDMuMi4xLiBOZWVkIHRvIGludGVncmF0ZSBvbi1w cmVtaXNlcyBOU0ZzIHdpdGggUmVtb3RlIE5TRnMuLjgNCiAgICAgICAgIDMuMi4yLiBUb2RheSdz IFBvbGljeSBFeHByZXNzaW9ucyBhcmUgVmVuZG9ycyBTcGVjaWZpYy4uLi4uLjkNCiAgICAgICAg IDMuMi4zLiBEaWZmaWN1bHR5IHRvIE1vbml0b3IgdGhlIEV4ZWN1dGlvbiBvZiBEZXNpcmVkIFBv bGljaWVzDQogICAgICAgICAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLjEwDQogICAgICAzLjMuIERpZmZpY3VsdHkgdG8gVmFsaWRhdGUg UG9saWNpZXMgYWNyb3NzIE11bHRpcGxlIERvbWFpbnMuLjEwDQogICAgICAzLjQuIExhY2sgb2Yg U3RhbmRhcmQgSW50ZXJmYWNlIHRvIEluamVjdCBGZWVkYmFjayB0byBOU0YuLi4uLjExDQoNCllv dXIgY29tbWVudHMgYW5kIHN1Z2dlc3Rpb25zIGFyZSBoaWdobHkgYXBwcmVjaWF0ZWQuIA0KDQpM aW5kYQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRz QGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IFRodXJz ZGF5LCBNYXkgMjEsIDIwMTUgNTozNyBQTQ0KVG86IE1vaGFtZWQgQm91Y2FkYWlyOyBTaGFpYmFs IENoYWtyYWJhcnR5OyBMaW5kYSBEdW5iYXI7IENocmlzdGlhbiBKYWNxdWVuZXQ7IE15byBaYXJu eTsgQ2hyaXN0aWFuIEphY3F1ZW5ldDsgTXlvIFphcm55OyBTaGFpYmFsIENoYWtyYWJhcnR5OyBM aW5kYSBEdW5iYXI7IE1vaGFtZWQgQm91Y2FkYWlyDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3Rp ZmljYXRpb24gZm9yIGRyYWZ0LWR1bmJhci1pMm5zZi1wcm9ibGVtLXN0YXRlbWVudC0wNC50eHQN Cg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtZHVuYmFyLWkybnNmLXByb2JsZW0tc3Rh dGVtZW50LTA0LnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBMaW5kYSBE dW5iYXIgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOgkJZHJhZnQt ZHVuYmFyLWkybnNmLXByb2JsZW0tc3RhdGVtZW50DQpSZXZpc2lvbjoJMDQNClRpdGxlOgkJSW50 ZXJmYWNlIHRvIE5ldHdvcmsgU2VjdXJpdHkgRnVuY3Rpb25zIChJMk5TRikgUHJvYmxlbSBTdGF0 ZW1lbnQNCkRvY3VtZW50IGRhdGU6CTIwMTUtMDUtMjENCkdyb3VwOgkJSW5kaXZpZHVhbCBTdWJt aXNzaW9uDQpQYWdlczoJCTIwDQpVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcv aW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWR1bmJhci1pMm5zZi1wcm9ibGVtLXN0YXRlbWVudC0wNC50 eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1kdW5iYXItaTJuc2YtcHJvYmxlbS1zdGF0ZW1lbnQvDQpIdG1saXplZDogICAgICAgaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWR1bmJhci1pMm5zZi1wcm9ibGVtLXN0YXRlbWVu dC0wNA0KRGlmZjogICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1k cmFmdC1kdW5iYXItaTJuc2YtcHJvYmxlbS1zdGF0ZW1lbnQtMDQNCg0KQWJzdHJhY3Q6DQogICBU aGlzIGRvY3VtZW50IGRlc2NyaWJlcyB0aGUgbW90aXZhdGlvbiBhbmQgdGhlIHByb2JsZW0gc3Rh dGVtZW50IGZvcg0KICAgSW50ZXJmYWNlIHRvIE5ldHdvcmsgU2VjdXJpdHkgRnVuY3Rpb25zIChJ Mk5TRikuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0 IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNz aW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQg dG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From nobody Mon May 25 12:03:58 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 020A41A0404 for ; Mon, 25 May 2015 12:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.09 X-Spam-Level: X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8NxuXUt9CYnt for ; Mon, 25 May 2015 12:03:52 -0700 (PDT) Received: from smtptc.telefonica.com (smtptc.telefonica.com [195.76.34.108]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B82B1A1B0B for ; Mon, 25 May 2015 12:03:51 -0700 (PDT) Received: from smtptc.telefonica.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 835503A023B; Mon, 25 May 2015 21:03:48 +0200 (CEST) Received: from ESTGVMSP102.EUROPE.telefonica.corp (unknown [10.92.4.9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtptc.telefonica.com (Postfix) with ESMTPS id 733AC3A0233; Mon, 25 May 2015 21:03:48 +0200 (CEST) Received: from emea01-am1-obe.outbound.protection.outlook.com (10.92.5.139) by tls.telefonica.com (10.93.6.49) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 25 May 2015 21:03:47 +0200 Received: from DB4PR06MB0624.eurprd06.prod.outlook.com (25.161.13.142) by DB4PR06MB0624.eurprd06.prod.outlook.com (25.161.13.142) with Microsoft SMTP Server (TLS) id 15.1.172.22; Mon, 25 May 2015 19:03:46 +0000 Received: from DB4PR06MB0624.eurprd06.prod.outlook.com ([25.161.13.142]) by DB4PR06MB0624.eurprd06.prod.outlook.com ([25.161.13.142]) with mapi id 15.01.0172.012; Mon, 25 May 2015 19:03:46 +0000 From: DIEGO LOPEZ GARCIA To: Linda Dunbar Thread-Topic: [I2nsf] updated I2NSF problem statement to reflect the narrower scoped charter Thread-Index: AQHQlBdwcaMbS56nSk+pGJr4g/BqUp2NEtyA Date: Mon, 25 May 2015 19:03:45 +0000 Message-ID: References: <4A95BA014132FF49AE685FAB4B9F17F657C46D13@dfweml701-chm> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657C46D13@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=diego.r.lopez@telefonica.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [83.54.132.127] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB4PR06MB0624; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(520002)(3002001); SRVR:DB4PR06MB0624; BCL:0; PCL:0; RULEID:; SRVR:DB4PR06MB0624; x-forefront-prvs: 058707456E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(199003)(13464003)(252514010)(377424004)(24454002)(377454003)(189002)(19580395003)(19580405001)(33656002)(14971765001)(54356999)(76176999)(101416001)(50986999)(86362001)(2656002)(87936001)(66066001)(64706001)(105586002)(15975445007)(102836002)(68736005)(2420400003)(97736004)(4001540100001)(81156007)(2900100001)(2950100001)(106356001)(46102003)(106116001)(40100003)(62966003)(122556002)(77156002)(19617315012)(189998001)(7110500001)(5001830100001)(83716003)(5001960100002)(82746002)(5001860100001)(110136002)(92566002)(36756003)(16601075003)(16236675004)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR06MB0624; H:DB4PR06MB0624.eurprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: telefonica.com does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_ED635796DF4B4E8DB7CC81CCC9B48807telefonicacom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 May 2015 19:03:45.6269 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR06MB0624 X-OriginatorOrg: telefonica.com X-TM-AS-MML: No Archived-At: Cc: "i2nsf@ietf.org" Subject: Re: [I2nsf] updated I2NSF problem statement to reflect the narrower scoped charter X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 May 2015 19:03:57 -0000 --_000_ED635796DF4B4E8DB7CC81CCC9B48807telefonicacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, As we discussed recently, I'd say that: 1.- It is important to address multi-tenancy of the interfaces to control a= nd monitor NSFs. First, because service providers may well require to have = several operational units to make this control and monitoring, especially w= hen they become distributed and virtualized. Second, service providers may = find a value in offering a (mediated) interface to control and monitoring N= SFs to their customers. This could certainly be part of 3.1.5... 2.- In what relates to 3.2.1, rather than distinguishing between "on-premis= es" and "remote", I'd talk about a consistent integration of NSFs, independ= ently of their location and their implementation mechanisms. Be goode, On 22 May 2015, at 24:42 , Linda Dunbar > wrote: We updated the I2NSF problem statement to reflect the narrower scoped chart= er. The primary issues and challenges facing NSFs hosted by different domains a= re: 3.1. Challenges Facing Security Service Providers..............5 3.1.1. Diverse types of Security Functions..................5 3.1.2. No Standard Characterization of NSFs.................6 3.1.3. More Distributed NSFs and vNSFs......................7 3.1.4. More Demand to Control NSFs Dynamically..............7 3.1.5. Diverse Interfaces to Control and Monitor NSFs.......7 3.1.6. Lack of mechanism to monitor the behavior of NSFs....8 3.2. Challenges Facing Customers...............................8 3.2.1. Need to integrate on-premises NSFs with Remote NSFs..8 3.2.2. Today's Policy Expressions are Vendors Specific......9 3.2.3. Difficulty to Monitor the Execution of Desired Policies ...........................................................10 3.3. Difficulty to Validate Policies across Multiple Domains..10 3.4. Lack of Standard Interface to Inject Feedback to NSF.....11 Your comments and suggestions are highly appreciated. Linda -----Original Message----- From: internet-drafts@ietf.org [mailto:int= ernet-drafts@ietf.org] Sent: Thursday, May 21, 2015 5:37 PM To: Mohamed Boucadair; Shaibal Chakrabarty; Linda Dunbar; Christian Jacquen= et; Myo Zarny; Christian Jacquenet; Myo Zarny; Shaibal Chakrabarty; Linda D= unbar; Mohamed Boucadair Subject: New Version Notification for draft-dunbar-i2nsf-problem-statement-= 04.txt A new version of I-D, draft-dunbar-i2nsf-problem-statement-04.txt has been successfully submitted by Linda Dunbar and posted to the IETF repo= sitory. Name: draft-dunbar-i2nsf-problem-statement Revision: 04 Title: Interface to Network Security Functions (I2NSF) Problem Statement Document date: 2015-05-21 Group: Individual Submission Pages: 20 URL: https://www.ietf.org/internet-drafts/draft-dunbar-i2nsf-pro= blem-statement-04.txt Status: https://datatracker.ietf.org/doc/draft-dunbar-i2nsf-problem= -statement/ Htmlized: https://tools.ietf.org/html/draft-dunbar-i2nsf-problem-stat= ement-04 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-dunbar-i2nsf-prob= lem-statement-04 Abstract: This document describes the motivation and the problem statement for Interface to Network Security Functions (I2NSF). Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ I2nsf mailing list I2nsf@ietf.org 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: diego.r.lopez@telefonica.com Tel: +34 913 129 041 Mobile: +34 682 051 091 ---------------------------------- ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=C3=B3n privilegiada o confidencial y es para uso exc= lusivo de la persona o entidad de destino. Si no es usted. el destinatario = indicado, queda notificado de que la lectura, utilizaci=C3=B3n, divulgaci= =C3=B3n y/o copia sin autorizaci=C3=B3n puede estar prohibida en virtud de = la legislaci=C3=B3n vigente. Si ha recibido este mensaje por error, le roga= mos que nos lo comunique inmediatamente por esta misma v=C3=ADa y proceda a= su destrucci=C3=B3n. The information contained in this transmission is privileged and confidenti= al 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 co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=C3=A1= rio, pode conter informa=C3=A7=C3=A3o privilegiada ou confidencial e =C3=A9= para uso exclusivo da pessoa ou entidade de destino. Se n=C3=A3o =C3=A9 vo= ssa senhoria o destinat=C3=A1rio indicado, fica notificado de que a leitura= , utiliza=C3=A7=C3=A3o, divulga=C3=A7=C3=A3o e/ou c=C3=B3pia sem autoriza= =C3=A7=C3=A3o pode estar proibida em virtude da legisla=C3=A7=C3=A3o vigent= e. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imedi= atamente por esta mesma via e proceda a sua destrui=C3=A7=C3=A3o --_000_ED635796DF4B4E8DB7CC81CCC9B48807telefonicacom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: quoted-printable Hi,

As we discussed recently, I'd say that:

1.- It is important to address multi-tenancy of the interfaces to cont= rol and monitor NSFs. First, because service providers may well require to = have several operational units to make this control and monitoring, especia= lly when they become distributed and virtualized. Second, service providers may find a value in offering a = (mediated) interface to control and monitoring NSFs to their customers. Thi= s could certainly be part of 3.1.5...

2.- In what relates to 3.2.1, rather than distinguishing between "= ;on-premises" and "remote", I'd talk about a consistent inte= gration of NSFs, independently of their location and their implementation m= echanisms.

Be goode,

On 22 May 2015, at 24:42 , Linda Dunbar <linda.dunbar@huawei.com> wrote:

We updated the I2NSF problem statement to reflect= the narrower scoped charter.

The primary issues and challenges facing NSFs hosted by different domains a= re:

     3.1. Challenges Facing Security Service Provi= ders..............5
        3.1.1. Diverse types of Sec= urity Functions..................5
        3.1.2. No Standard Characte= rization of NSFs.................6
        3.1.3. More Distributed NSF= s and vNSFs......................7
        3.1.4. More Demand to Contr= ol NSFs Dynamically..............7
        3.1.5. Diverse Interfaces t= o Control and Monitor NSFs.......7
        3.1.6. Lack of mechanism to= monitor the behavior of NSFs....8
     3.2. Challenges Facing Customers.............= ..................8
        3.2.1. Need to integrate on= -premises NSFs with Remote NSFs..8
        3.2.2. Today's Policy Expre= ssions are Vendors Specific......9
        3.2.3. Difficulty to Monito= r the Execution of Desired Policies
        ...........................= ................................10
     3.3. Difficulty to Validate Policies across M= ultiple Domains..10
     3.4. Lack of Standard Interface to Inject Fee= dback to NSF.....11

Your comments and suggestions are highly appreciated.

Linda

-----Original Message-----
From: internet-drafts@ietf.org<= /a> [mailto:internet-drafts@iet= f.org]
Sent: Thursday, May 21, 2015 5:37 PM
To: Mohamed Boucadair; Shaibal Chakrabarty; Linda Dunbar; Christian Jacquen= et; Myo Zarny; Christian Jacquenet; Myo Zarny; Shaibal Chakrabarty; Linda D= unbar; Mohamed Boucadair
Subject: New Version Notification for draft-dunbar-i2nsf-problem-statement-= 04.txt


A new version of I-D, draft-dunbar-i2nsf-problem-statement-04.txt
has been successfully submitted by Linda Dunbar and posted to the IETF repo= sitory.

Name: draft-dunbar-i2n= sf-problem-statement
Revision: 0= 4
Title: Interface to Ne= twork Security Functions (I2NSF) Problem Statement
Document date: 2015-05-21
Group: Individual Subm= ission
Pages: 20
URL:            https://www.ietf.org/internet-drafts/draft-dunbar-i2nsf-probl= em-statement-04.txt
Status:         https://dat= atracker.ietf.org/doc/draft-dunbar-i2nsf-problem-statement/
Htmlized:       https://tools.ietf.org/h= tml/draft-dunbar-i2nsf-problem-statement-04
Diff:           https://www.ietf.org/rfcdiff?url2=3Ddraft-dunbar-i2nsf-problem-statem= ent-04

Abstract:
  This document describes the motivation and the problem statemen= t for
  Interface to Network Security Functions (I2NSF).




Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

_______________________________________________
I2nsf mailing list
I2nsf@ietf.org
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.lo= pez/

e-mail: diego.r.lopez@telefonica.com
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------



Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=C3=B3n privilegiada o confidencial y es para uso exc= lusivo de la persona o entidad de destino. Si no es usted. el destinatario = indicado, queda notificado de que la lectura, utilizaci=C3=B3n, divulgaci=C3=B3n y/o copia sin autorizaci=C3=B3= n puede estar prohibida en virtud de la legislaci=C3=B3n vigente. Si ha rec= ibido este mensaje por error, le rogamos que nos lo comunique inmediatament= e por esta misma v=C3=ADa y proceda a su destrucci=C3=B3n.

The information contained in this transmission is privileged and confidenti= al 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 y= ou have received this transmission in error, do not read it. Please immedia= tely 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=C3=A1= rio, pode conter informa=C3=A7=C3=A3o privilegiada ou confidencial e =C3=A9= para uso exclusivo da pessoa ou entidade de destino. Se n=C3=A3o =C3=A9 vo= ssa senhoria o destinat=C3=A1rio indicado, fica notificado de que a leitura, utiliza=C3=A7=C3=A3o, divulga=C3=A7=C3=A3o e/ou c=C3=B3pia sem au= toriza=C3=A7=C3=A3o pode estar proibida em virtude da legisla=C3=A7=C3=A3o = vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique= imediatamente por esta mesma via e proceda a sua destrui=C3=A7=C3=A3o
 --_000_ED635796DF4B4E8DB7CC81CCC9B48807telefonicacom_-- From nobody Mon May 25 15:42:17 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE2BA1A9235 for ; Mon, 25 May 2015 15:42:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.349 X-Spam-Level: X-Spam-Status: No, score=-0.349 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SPwqBP1rVjdg for ; Mon, 25 May 2015 15:42:15 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5C1D1A9170 for ; Mon, 25 May 2015 15:42:14 -0700 (PDT) Received: by wifw1 with SMTP id w1so10212819wif.0 for ; Mon, 25 May 2015 15:42:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=1bKA5kAxXyuzyycdmRk9kRkn8pj/Exjfx+DHwbJ10i0=; b=lkodK8JBPXIWIkHlfiie3cpPIIntWFrwKQONjlJlSbE44AB828+vq3IiHnQclqQlOT qq5MQmXOESZ4K703iK8LO1/HOERFnk9Tn3cjIoyZ/nb1xqfPIMdcjseApR87WoKaba9m LjynB4LPRq2I3Io09TrVb8gIVDldXN4pwPfCqpdYpwsywd5QSjAbsTP1Q05cBiaNMHA6 A6+4rGF7PDDR7qWxm71lCJQBVvYYB5v6RTRLrCH+LaqM6u+TKZ4QXVKHhgYQxsSKFupS Qo096IAy95L5VojuTEE5yb5J0gNLNdAGB2t6+D7/O3Jx/7ahLfIFdyyzHfXTqhAGX6pJ Gbiw== MIME-Version: 1.0 X-Received: by 10.181.6.37 with SMTP id cr5mr34805303wid.18.1432593733376; Mon, 25 May 2015 15:42:13 -0700 (PDT) Received: by 10.28.227.193 with HTTP; Mon, 25 May 2015 15:42:13 -0700 (PDT) Date: Mon, 25 May 2015 17:42:13 -0500 Message-ID: From: Alexey Gorbunov To: "i2nsf@ietf.org" , Linda Dunbar Content-Type: multipart/alternative; boundary=001a1136012e95de250516efb841 Archived-At: Subject: [I2nsf] Definition for "Network Security Functions" X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 May 2015 22:42:16 -0000 --001a1136012e95de250516efb841 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi All I agree with Diego definition: "functions to ensure integrity, confidentiality and availability of network communications, to detect unwanted activity, and to deter it or at least mitigate its effects on the network" >From my point of view that covers all cases of network security function. Regarding Flow-based network security function: =E2=80=9C A function that inspects network flows according to a policy inte= nded for enforcing security properties. Flow-based security also means that packets are inspected in the order they are received, and without modification to the packet due to the inspection process (MAC rewrites, TTL decrement action; even NAT would be outside the inspection process). I'm not sure if it's valuable to inspect packet without modification. There are cases when it's more preferable to inspect and apply policy after NAT. This is common practice and it must be a good reason to change it. Br, Alexey Gorbunov Telco Cloud and Security Architect at Nokia CCIE R&S 41088 --001a1136012e95de250516efb841 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi All

I agree with Diego definition:= =C2=A0
"functions to ensure integrity, confidentiality and a= vailability of network communications, to detect unwanted activity, and to = deter it or at least mitigate its effects on the network"
=

From my point of view that covers all cases of n= etwork security function.

Regarding Flow-= based network security function:

=E2=80=9C A func= tion that inspects network flows according to a policy intended for enforci= ng security properties.=C2=A0 Flow-based security also means that packets a= re inspected in the order they are received, and without modification to th= e packet due to the inspection process (MAC rewrites, TTL decrement action;= even NAT would be outside the inspection process).

I'm not sure if it's valuable =C2=A0to inspect pack= et without modification. There are cases when it's more preferab= le to inspect and apply policy after NAT.=C2=A0 This is common practice and= it must be a good reason to change it.=C2=A0

=
Br, Alexey Gorbunov
Telco Cloud and Security Architec= t at Nokia
CCIE R&S 41088
=C2=A0

= =C2=A0



<= /div> --001a1136012e95de250516efb841-- From nobody Mon May 25 19:55:55 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58D371A8915 for ; Mon, 25 May 2015 19:55:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K-KRgDltx1ih for ; Mon, 25 May 2015 19:55:51 -0700 (PDT) Received: from smtpvbsrv1.mitre.org (smtpvbsrv1.mitre.org [198.49.146.234]) by ietfa.amsl.com (Postfix) with ESMTP id 20C771A88DB for ; Mon, 25 May 2015 19:55:51 -0700 (PDT) Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id A6DA7B2E676; Mon, 25 May 2015 22:55:50 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpvbsrv1.mitre.org (Postfix) with ESMTP id 99E6CB2E675; Mon, 25 May 2015 22:55:50 -0400 (EDT) Received: from imshyb01.MITRE.ORG (129.83.29.2) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server (TLS) id 14.3.224.2; Mon, 25 May 2015 22:55:47 -0400 Received: from imshyb01.MITRE.ORG (129.83.29.2) by imshyb01.MITRE.ORG (129.83.29.2) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Mon, 25 May 2015 22:55:47 -0400 Received: from na01-by2-obe.outbound.protection.outlook.com (10.140.19.249) by imshyb01.MITRE.ORG (129.83.29.2) with Microsoft SMTP Server (TLS) id 15.0.1044.25 via Frontend Transport; Mon, 25 May 2015 22:55:47 -0400 Received: from CY1PR09MB0922.namprd09.prod.outlook.com (10.163.89.140) by CY1PR09MB0923.namprd09.prod.outlook.com (10.163.89.141) with Microsoft SMTP Server (TLS) id 15.1.172.22; Tue, 26 May 2015 02:55:44 +0000 Received: from CY1PR09MB0922.namprd09.prod.outlook.com ([10.163.89.140]) by CY1PR09MB0922.namprd09.prod.outlook.com ([10.163.89.140]) with mapi id 15.01.0172.012; Tue, 26 May 2015 02:55:44 +0000 From: "Natale, Bob" To: Alexey Gorbunov , Linda Dunbar Thread-Topic: [I2nsf] Definition for "Network Security Functions" Thread-Index: AQHQlzwQjFMyTwgT3E+wFBdaduFWyJ2NjW9Q Date: Tue, 26 May 2015 02:55:43 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=RNATALE@mitre.org; x-originating-ip: [192.80.55.89] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR09MB0923; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(520002)(3002001); SRVR:CY1PR09MB0923; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0923; x-forefront-prvs: 0588B2BD96 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(53754006)(377454003)(189002)(199003)(77096005)(2900100001)(76576001)(2420400003)(5001960100002)(15975445007)(2950100001)(102836002)(46102003)(86362001)(5001860100001)(5001830100001)(92566002)(33656002)(62966003)(122556002)(40100003)(2656002)(74316001)(87936001)(77156002)(189998001)(7110500001)(16236675004)(64706001)(105586002)(4001540100001)(81156007)(66066001)(76176999)(54356999)(50986999)(19300405004)(99286002)(19625215002)(97736004)(5001770100001)(106356001)(68736005)(106116001)(19580405001)(19580395003)(101416001); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR09MB0923; H:CY1PR09MB0922.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: mitre.org does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_CY1PR09MB09223E27D885E71B74421D24A8CC0CY1PR09MB0922namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 May 2015 02:55:43.9166 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c620dc48-1d50-4952-8b39-df4d54d74d82 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0923 X-OriginatorOrg: mitre.org Archived-At: Cc: "i2nsf@ietf.org" Subject: Re: [I2nsf] Definition for "Network Security Functions" X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 02:55:53 -0000 --_000_CY1PR09MB09223E27D885E71B74421D24A8CC0CY1PR09MB0922namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 R2l2ZW4gYWdyZWVtZW50IGFyb3VuZCBEaWVnb+KAmXMgZGVmaW5pdGlvbiwgSSBiZWxpZXZlIGl0 IGlzIHN1ZmZpY2llbnQgdG8gc2F5IOKAnEZ1bmN0aW9ucyB0byBlbnN1cmUgdGhlIGNvbmZpZGVu dGlhbGl0eSwgaW50ZWdyaXR5LCBhbmQgYXZhaWxhYmxlIG9mIG5ldHdvcmsgY29tbXVuaWNhdGlv bnMu4oCdIChQdXR0aW5nICB0aGUgQ0lBIGluIHRoZSB0cmFkaXRpb25hbCBvcmRlci4pIFRoZSBz ZWNvbmQgcGFydCAo4oCcdG8gZGV0ZWN0IHVud2FudGVkIGFjdGl2aXR5LCBhbmQgdG8gZGV0ZXIg aXQgb3IgYXQgbGVhc3QgbWl0aWdhdGUgaXRzIGVmZmVjdHMgb24gdGhlIG5ldHdvcmvigJ0pIGFk ZHMgbm90aGluZyB0aGF0IGlzIG5vdCBhbHJlYWR5IGluY2x1ZGVkIGluIHRoZSBmaXJzdCBwYXJ0 IGJ1dCBpbXBsaWNpdGx5IChieSBvbWlzc2lvbikgZXhjbHVkZXMgc29tZSBmdW5jdGlvbnMgKGUu Zy4sIHByZXZlbnRpdmUgZnVuY3Rpb25zKSB0aGF0IGFyZSAobm9ybWFsbHkpIGluY2x1ZGVkLg0K DQpCeSBleHRlbnNpb24sIEkgd291bGQgYWxzbyBzYXkgdGhhdCB0aGUgZGVmaW5pdGlvbiBwZXIg YWJvdmUgZXh0ZW5kcyB0byB0aGUgcmVzb3VyY2VzIChkZXZpY2VzLCBhcHBsaWNhdGlvbnMsIHNl cnZpY2VzKSBuZWNlc3NhcnkgdG8gc3VwcG9ydCBuZXR3b3JrIGNvbW11bmljYXRpb25zIOKApiBz aW5jZSBhIHZpb2xhdGlvbiBvZiBzZWN1cml0eSB0aGVyZSBoYXMgYSBwb3RlbnRpYWwgIHVuZGVz aXJlZCBlZmZlY3QgaW4gdGhlIG5ldHdvcmsgdHJhZmZpYy4NCg0KU28sIEkgbWlnaHQgc3VnZ2Vz dCBhbiBleHRlbnNpb24gb2YgdGhlIGRlZmluaXRpb24gdG8g4oCcRnVuY3Rpb25zIHRvIGVuc3Vy ZSB0aGUgY29uZmlkZW50aWFsaXR5LCBpbnRlZ3JpdHksIGFuZCBhdmFpbGFiaWxpdHkgb2YgbmV0 d29yayBjb21tdW5pY2F0aW9ucyBhbmQgdGhlIHJlc291cmNlcyB1c2VkIHRvIHN1cHBvcnQgbmV0 d29yayBjb21tdW5pY2F0aW9ucy7igJ0g4oCmPw0KDQpBdmFudGksDQpCb2JODQoNCkZyb206IEky bnNmIFttYWlsdG86aTJuc2YtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFsZXhleSBH b3JidW5vdg0KU2VudDogTW9uZGF5LCBNYXkgMjUsIDIwMTUgNjo0MiBQTQ0KVG86IGkybnNmQGll dGYub3JnOyBMaW5kYSBEdW5iYXINClN1YmplY3Q6IFtJMm5zZl0gRGVmaW5pdGlvbiBmb3IgIk5l dHdvcmsgU2VjdXJpdHkgRnVuY3Rpb25zIg0KDQpIaSBBbGwNCg0KSSBhZ3JlZSB3aXRoIERpZWdv IGRlZmluaXRpb246DQoiZnVuY3Rpb25zIHRvIGVuc3VyZSBpbnRlZ3JpdHksIGNvbmZpZGVudGlh bGl0eSBhbmQgYXZhaWxhYmlsaXR5IG9mIG5ldHdvcmsgY29tbXVuaWNhdGlvbnMsIHRvIGRldGVj dCB1bndhbnRlZCBhY3Rpdml0eSwgYW5kIHRvIGRldGVyIGl0IG9yIGF0IGxlYXN0IG1pdGlnYXRl IGl0cyBlZmZlY3RzIG9uIHRoZSBuZXR3b3JrIg0KDQpGcm9tIG15IHBvaW50IG9mIHZpZXcgdGhh dCBjb3ZlcnMgYWxsIGNhc2VzIG9mIG5ldHdvcmsgc2VjdXJpdHkgZnVuY3Rpb24uDQoNClJlZ2Fy ZGluZyBGbG93LWJhc2VkIG5ldHdvcmsgc2VjdXJpdHkgZnVuY3Rpb246DQoNCuKAnCBBIGZ1bmN0 aW9uIHRoYXQgaW5zcGVjdHMgbmV0d29yayBmbG93cyBhY2NvcmRpbmcgdG8gYSBwb2xpY3kgaW50 ZW5kZWQgZm9yIGVuZm9yY2luZyBzZWN1cml0eSBwcm9wZXJ0aWVzLiAgRmxvdy1iYXNlZCBzZWN1 cml0eSBhbHNvIG1lYW5zIHRoYXQgcGFja2V0cyBhcmUgaW5zcGVjdGVkIGluIHRoZSBvcmRlciB0 aGV5IGFyZSByZWNlaXZlZCwgYW5kIHdpdGhvdXQgbW9kaWZpY2F0aW9uIHRvIHRoZSBwYWNrZXQg ZHVlIHRvIHRoZSBpbnNwZWN0aW9uIHByb2Nlc3MgKE1BQyByZXdyaXRlcywgVFRMIGRlY3JlbWVu dCBhY3Rpb247IGV2ZW4gTkFUIHdvdWxkIGJlIG91dHNpZGUgdGhlIGluc3BlY3Rpb24gcHJvY2Vz cykuDQoNCkknbSBub3Qgc3VyZSBpZiBpdCdzIHZhbHVhYmxlICB0byBpbnNwZWN0IHBhY2tldCB3 aXRob3V0IG1vZGlmaWNhdGlvbi4gVGhlcmUgYXJlIGNhc2VzIHdoZW4gaXQncyBtb3JlIHByZWZl cmFibGUgdG8gaW5zcGVjdCBhbmQgYXBwbHkgcG9saWN5IGFmdGVyIE5BVC4gIFRoaXMgaXMgY29t bW9uIHByYWN0aWNlIGFuZCBpdCBtdXN0IGJlIGEgZ29vZCByZWFzb24gdG8gY2hhbmdlIGl0Lg0K DQpCciwgQWxleGV5IEdvcmJ1bm92DQpUZWxjbyBDbG91ZCBhbmQgU2VjdXJpdHkgQXJjaGl0ZWN0 IGF0IE5va2lhDQpDQ0lFIFImUyA0MTA4OA0KDQoNCg0KDQoNCg== --_000_CY1PR09MB09223E27D885E71B74421D24A8CC0CY1PR09MB0922namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBz cGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxl MTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6Izk5MzMwMDsNCglmb250LXdlaWdodDpub3JtYWw7DQoJ Zm9udC1zdHlsZTpub3JtYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw b3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBp biAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJl ZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0i ZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwv aGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj OTkzMzAwIj5HaXZlbiBhZ3JlZW1lbnQgYXJvdW5kIERpZWdv4oCZcyBkZWZpbml0aW9uLCBJIGJl bGlldmUgaXQgaXMgc3VmZmljaWVudCB0byBzYXkg4oCcRnVuY3Rpb25zIHRvIGVuc3VyZSB0aGUg Y29uZmlkZW50aWFsaXR5LCBpbnRlZ3JpdHksIGFuZCBhdmFpbGFibGUgb2YgbmV0d29yayBjb21t dW5pY2F0aW9ucy7igJ0gKFB1dHRpbmcmbmJzcDsNCiB0aGUgQ0lBIGluIHRoZSB0cmFkaXRpb25h bCBvcmRlci4pIFRoZSBzZWNvbmQgcGFydCAo4oCcdG8gZGV0ZWN0IHVud2FudGVkIGFjdGl2aXR5 LCBhbmQgdG8gZGV0ZXIgaXQgb3IgYXQgbGVhc3QgbWl0aWdhdGUgaXRzIGVmZmVjdHMgb24gdGhl IG5ldHdvcmvigJ0pIGFkZHMgbm90aGluZyB0aGF0IGlzIG5vdCBhbHJlYWR5IGluY2x1ZGVkIGlu IHRoZSBmaXJzdCBwYXJ0IGJ1dCBpbXBsaWNpdGx5IChieSBvbWlzc2lvbikgZXhjbHVkZXMgc29t ZSBmdW5jdGlvbnMNCiAoZS5nLiwgcHJldmVudGl2ZSBmdW5jdGlvbnMpIHRoYXQgYXJlIChub3Jt YWxseSkgaW5jbHVkZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojOTkzMzAwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiM5OTMzMDAiPkJ5IGV4dGVuc2lvbiwgSSB3b3VsZCBhbHNvIHNheSB0 aGF0IHRoZSBkZWZpbml0aW9uIHBlciBhYm92ZSBleHRlbmRzIHRvIHRoZSByZXNvdXJjZXMgKGRl dmljZXMsIGFwcGxpY2F0aW9ucywgc2VydmljZXMpIG5lY2Vzc2FyeSB0byBzdXBwb3J0IG5ldHdv cmsgY29tbXVuaWNhdGlvbnMg4oCmIHNpbmNlIGEgdmlvbGF0aW9uDQogb2Ygc2VjdXJpdHkgdGhl cmUgaGFzIGEgcG90ZW50aWFsICZuYnNwO3VuZGVzaXJlZCBlZmZlY3QgaW4gdGhlIG5ldHdvcmsg dHJhZmZpYy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiM5OTMzMDAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6Izk5MzMwMCI+U28sIEkgbWlnaHQgc3VnZ2VzdCBhbiBleHRlbnNpb24gb2YgdGhl IGRlZmluaXRpb24gdG8g4oCcRnVuY3Rpb25zIHRvIGVuc3VyZSB0aGUgY29uZmlkZW50aWFsaXR5 LCBpbnRlZ3JpdHksIGFuZCBhdmFpbGFiaWxpdHkgb2YgbmV0d29yayBjb21tdW5pY2F0aW9ucyBh bmQgdGhlIHJlc291cmNlcyB1c2VkIHRvDQogc3VwcG9ydCBuZXR3b3JrIGNvbW11bmljYXRpb25z LuKAnSDigKY/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojOTkzMzAwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiM5OTMzMDAiPkF2YW50aSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiM5OTMzMDAiPkJvYk48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM5OTMzMDAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IEkybnNmIFttYWlsdG86aTJuc2YtYm91bmNlc0BpZXRm Lm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+QWxleGV5IEdvcmJ1bm92PGJyPg0KPGI+U2VudDo8 L2I+IE1vbmRheSwgTWF5IDI1LCAyMDE1IDY6NDIgUE08YnI+DQo8Yj5Ubzo8L2I+IGkybnNmQGll dGYub3JnOyBMaW5kYSBEdW5iYXI8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW0kybnNmXSBEZWZpbml0 aW9uIGZvciAmcXVvdDtOZXR3b3JrIFNlY3VyaXR5IEZ1bmN0aW9ucyZxdW90OzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIEFsbDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhZ3JlZSB3aXRoIERpZWdvIGRlZmluaXRpb246Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m cXVvdDtmdW5jdGlvbnMgdG8gZW5zdXJlIGludGVncml0eSwgY29uZmlkZW50aWFsaXR5IGFuZCBh dmFpbGFiaWxpdHkgb2YgbmV0d29yayBjb21tdW5pY2F0aW9ucywgdG8gZGV0ZWN0IHVud2FudGVk IGFjdGl2aXR5LCBhbmQgdG8gZGV0ZXIgaXQgb3IgYXQgbGVhc3QgbWl0aWdhdGUgaXRzIGVmZmVj dHMgb24gdGhlIG5ldHdvcmsmcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+RnJvbSBteSBwb2ludCBvZiB2aWV3IHRoYXQgY292ZXJzIGFs bCBjYXNlcyBvZiBuZXR3b3JrIHNlY3VyaXR5IGZ1bmN0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlZ2FyZGluZyBGbG93LWJhc2VkIG5ldHdvcmsg c2VjdXJpdHkgZnVuY3Rpb246PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj7igJwgQSBmdW5jdGlvbiB0aGF0IGluc3BlY3RzIG5ldHdvcmsgZmxvd3MgYWNjb3Jk aW5nIHRvIGEgcG9saWN5IGludGVuZGVkIGZvciBlbmZvcmNpbmcgc2VjdXJpdHkgcHJvcGVydGll cy4mbmJzcDsgRmxvdy1iYXNlZCBzZWN1cml0eSBhbHNvIG1lYW5zIHRoYXQgcGFja2V0cyBhcmUg aW5zcGVjdGVkIGluIHRoZSBvcmRlciB0aGV5IGFyZSByZWNlaXZlZCwgYW5kIHdpdGhvdXQgbW9k aWZpY2F0aW9uIHRvIHRoZSBwYWNrZXQNCiBkdWUgdG8gdGhlIGluc3BlY3Rpb24gcHJvY2VzcyAo TUFDIHJld3JpdGVzLCBUVEwgZGVjcmVtZW50IGFjdGlvbjsgZXZlbiBOQVQgd291bGQgYmUgb3V0 c2lkZSB0aGUgaW5zcGVjdGlvbiBwcm9jZXNzKS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSdtIG5vdCBzdXJlIGlmIGl0J3MgdmFsdWFibGUg Jm5ic3A7dG8gaW5zcGVjdCBwYWNrZXQgd2l0aG91dCBtb2RpZmljYXRpb24uIFRoZXJlIGFyZSBj YXNlcyB3aGVuIGl0J3MgbW9yZSBwcmVmZXJhYmxlIHRvIGluc3BlY3QgYW5kIGFwcGx5IHBvbGlj eSBhZnRlciBOQVQuJm5ic3A7IFRoaXMgaXMgY29tbW9uIHByYWN0aWNlIGFuZCBpdCBtdXN0IGJl IGEgZ29vZCByZWFzb24gdG8gY2hhbmdlIGl0LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CciwgQWxleGV5IEdvcmJ1bm92PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UZWxjbyBDbG91 ZCBhbmQgU2VjdXJpdHkgQXJjaGl0ZWN0IGF0IE5va2lhPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DQ0lFIFImYW1wO1MgNDEwODg8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_CY1PR09MB09223E27D885E71B74421D24A8CC0CY1PR09MB0922namp_-- From nobody Mon May 25 20:02:01 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1DAD1AC3CE for ; Mon, 25 May 2015 20:01:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.351 X-Spam-Level: ** X-Spam-Status: No, score=2.351 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DEcHeON-jogh for ; Mon, 25 May 2015 20:01:56 -0700 (PDT) Received: from out4133-130.mail.aliyun.com (out4133-130.mail.aliyun.com [42.120.133.130]) by ietfa.amsl.com (Postfix) with ESMTP id 354051AC3CC for ; Mon, 25 May 2015 20:01:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1432609315; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=gSdbJeq6eZYYP1Wfd5TlWHfFh0mtM4eEu1p5QGZFfiY=; b=lAlhXnXB7L4xpRD/+x7X6x5GtF+8zFPrqYoqjxqoj1VCWVGk7xYKNvr7OCKESuAgCDnuiAdOAUyRnfOZn4UA6dLnCBJ0CA7UKmJt4iIqHrB9sTEbVZL/z31z8kSjSJjrZbcwclwvFsllzQU2odaY0WbztNiR4URwFGgU0u7FtKI= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R871e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=r41g06005; MF=dacheng.zdc@alibaba-inc.com; PH=DS; RN=4; RT=4; SR=0; Received: from 10.62.53.210(mailfrom:dacheng.zdc@alibaba-inc.com ip:182.92.253.23) by smtp.aliyun-inc.com(127.0.0.1); Tue, 26 May 2015 11:01:52 +0800 User-Agent: Microsoft-MacOutlook/14.5.0.150423 Date: Tue, 26 May 2015 11:01:46 +0800 From: "Dacheng Zhang" To: "Natale, Bob" , Alexey Gorbunov , Linda Dunbar Message-ID: Thread-Topic: [I2nsf] Definition for "Network Security Functions" Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3515482912_6035730" Archived-At: Cc: "i2nsf@ietf.org" Subject: Re: [I2nsf] Definition for "Network Security Functions" X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 03:01:59 -0000 > ´ËÓʼþʹÓà MIME ¸ñʽ¡£ÓÉÓÚÓʼþÔĶÁ³ÌÐò²»ÄÜʶ±ð ´Ë¸ñʽ£¬Òò´Ë£¬¿ÉÄÜÎÞ·¨Ê¶±ð¸ÃÓʼþµÄ·Ö²¿»ò²¿·ÖÄÚÈÝ¡£ --B_3515482912_6035730 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: quoted-printable =B7=A2=BC=FE=C8=CB: "Natale, Bob" =C8=D5=C6=DA: 2015=C4=EA5=D4=C226=C8=D5 =D0=C7=C6=DA=B6=FE =C9=CF=CE=E710:55 =D6=C1: Alexey Gorbunov , Linda Dunbar =B3=AD=CB=CD: "i2nsf@ietf.org" =D6=F7=CC=E2: Re: [I2nsf] Definition for "Network Security Functions" Given agreement around Diego=A1=AFs definition, I believe it is sufficient to s= ay =A1=B0Functions to ensure the confidentiality, integrity, and available of network communications.=A1=B1 (Putting the CIA in the traditional order.) The second part (=A1=B0to detect unwanted activity, and to deter it or at least mitigate its effects on the network=A1=B1) adds nothing that is not already included in the first part but implicitly (by omission) excludes some functions (e.g., preventive functions) that are (normally) included. Dacheng:// I think CIA cannot really take place of the second part. The CIA is about ensuring data =A1=AEsecurely' transported over the network. The second part is about detecting the improper content in the data or improper signaling which may affect the normal operators of network systems. =20 =20 By extension, I would also say that the definition per above extends to the resources (devices, applications, services) necessary to support network communications =A1=AD since a violation of security there has a potential undesired effect in the network traffic. =20 So, I might suggest an extension of the definition to =A1=B0Functions to ensure the confidentiality, integrity, and availability of network communications and the resources used to support network communications.=A1=B1 =A1=AD? =20 Avanti, BobN =20 From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Alexey Gorbunov Sent: Monday, May 25, 2015 6:42 PM To: i2nsf@ietf.org; Linda Dunbar Subject: [I2nsf] Definition for "Network Security Functions" =20 Hi All =20 I agree with Diego definition: "functions to ensure integrity, confidentiality and availability of network communications, to detect unwanted activity, and to deter it or at least mitigate its effects on the network" =20 >From my point of view that covers all cases of network security function. =20 Regarding Flow-based network security function: =20 =A1=B0 A function that inspects network flows according to a policy intended fo= r enforcing security properties. Flow-based security also means that packets are inspected in the order they are received, and without modification to the packet due to the inspection process (MAC rewrites, TTL decrement action; even NAT would be outside the inspection process). =20 I'm not sure if it's valuable to inspect packet without modification. Ther= e are cases when it's more preferable to inspect and apply policy after NAT. This is common practice and it must be a good reason to change it. =20 Br, Alexey Gorbunov Telco Cloud and Security Architect at Nokia CCIE R&S 41088 =20 =20 =20 =20 =20 _______________________________________________ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf --B_3515482912_6035730 Content-type: text/html; charset="GB2312" Content-transfer-encoding: quoted-printable


=B7=A2=BC=FE=C8=CB: "Natale, Bob" <RNATALE@mitre.org>
=C8=D5= =C6=DA: 2015=C4=EA5=D4=C226=C8=D5 =D0=C7=C6=DA=B6=FE =C9=CF=CE=E710:55
=D6=C1: Alexey Gorbunov <alexey.gorbunov82@gmail.com>, Linda Dunbar <linda.dunbar@huawei.com>
=B3=AD=CB=CD: "i2nsf@ietf.org= " <i2nsf@ietf.org>
=D6=F7=CC=E2: Re: [I2nsf] Definition for "Network Securit= y Functions"

Given agreement around Di= ego’s definition, I believe it is sufficient to say “Functions t= o ensure the confidentiality, integrity, and available of network communicat= ions.” (Putting  the CIA in the traditional order.) The second part (“to detect unwan= ted activity, and to deter it or at least mitigate its effects on the networ= k”) adds nothing that is not already included in the first part but im= plicitly (by omission) excludes some functions (e.g., preventive functions) that are (normally) included.


Dacheng:// I think CIA cannot really= take place of the second part. The CIA is about ensuring data ‘secure= ly' transported over the network. The second part is about detecting the imp= roper content in the data or improper signaling which may affect the normal = operators of network systems. 


=


 
=

 

By extension, I would als= o say that the definition per above extends to the resources (devices, appli= cations, services) necessary to support network communications … since= a violation of security there has a potential  undesired effect in the network tr= affic.

 

So, I might suggest an extension of the definition to “F= unctions to ensure the confidentiality, integrity, and availability of netwo= rk communications and the resources used to support network communications.” …?

 

Avanti,<= /span>

BobN

&= nbsp;

From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Alexey Gorbunov
Sent: Monday, May 25, 2015 6:= 42 PM
To: i2nsf@ietf.org; Lind= a Dunbar
Subject: [I2nsf] Definition for "Network Security Functio= ns"

 

Hi All

 <= /o:p>

I agree with Diego definition: = ;

"functions to ensure integri= ty, confidentiality and availability of network communications, to detect un= wanted activity, and to deter it or at least mitigate its effects on the net= work"

 

From my point of view that covers all cases of = network security function.

 

Regarding Flow-based network se= curity function:

 

“ A function that inspects network f= lows according to a policy intended for enforcing security properties. = Flow-based security also means that packets are inspected in the order they= are received, and without modification to the packet due to the inspection process (MAC rewrites, TTL decrement action; even NA= T would be outside the inspection process).

 

I'm not s= ure if it's valuable  to inspect packet without modification. There are= cases when it's more preferable to inspect and apply policy after NAT. = ; This is common practice and it must be a good reason to change it. 

 

Br, Alexey Gorbunov

Telco Cloud and Security Architect at Nokia

=

CCIE R&S 41088

 

 

 

 

<= p class=3D"MsoNormal"> 

_______________________________________________ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org/= mailman/listinfo/i2nsf --B_3515482912_6035730-- From nobody Mon May 25 20:43:04 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0986F1A0021 for ; Mon, 25 May 2015 20:43:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.159 X-Spam-Level: X-Spam-Status: No, score=-0.159 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RtS9U91iDqZM for ; Mon, 25 May 2015 20:42:59 -0700 (PDT) Received: from smtpvbsrv1.mitre.org (smtpvbsrv1.mitre.org [198.49.146.234]) by ietfa.amsl.com (Postfix) with ESMTP id 935DE1A001C for ; Mon, 25 May 2015 20:42:59 -0700 (PDT) Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id D31FA52E197; Mon, 25 May 2015 23:42:58 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpvbsrv1.mitre.org (Postfix) with ESMTP id C3F7952E196; Mon, 25 May 2015 23:42:58 -0400 (EDT) Received: from imshyb01.MITRE.ORG (129.83.29.2) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server (TLS) id 14.3.224.2; Mon, 25 May 2015 23:42:58 -0400 Received: from imshyb02.MITRE.ORG (129.83.29.3) by imshyb01.MITRE.ORG (129.83.29.2) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Mon, 25 May 2015 23:42:58 -0400 Received: from na01-bn1-obe.outbound.protection.outlook.com (10.140.19.249) by imshyb02.MITRE.ORG (129.83.29.3) with Microsoft SMTP Server (TLS) id 15.0.1044.25 via Frontend Transport; Mon, 25 May 2015 23:42:58 -0400 Received: from CY1PR09MB0922.namprd09.prod.outlook.com (10.163.89.140) by CY1PR09MB0921.namprd09.prod.outlook.com (10.163.89.14) with Microsoft SMTP Server (TLS) id 15.1.172.22; Tue, 26 May 2015 03:42:55 +0000 Received: from CY1PR09MB0922.namprd09.prod.outlook.com ([10.163.89.140]) by CY1PR09MB0922.namprd09.prod.outlook.com ([10.163.89.140]) with mapi id 15.01.0172.012; Tue, 26 May 2015 03:42:54 +0000 From: "Natale, Bob" To: Dacheng Zhang , Alexey Gorbunov , Linda Dunbar Thread-Topic: [I2nsf] Definition for "Network Security Functions" Thread-Index: AQHQl2BNaC/heUYRRaG527iXhQCbp52Nm6sA Date: Tue, 26 May 2015 03:42:54 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=RNATALE@mitre.org; x-originating-ip: [192.80.55.89] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR09MB0921; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(520002)(3002001); SRVR:CY1PR09MB0921; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0921; x-forefront-prvs: 0588B2BD96 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(377454003)(53754006)(199003)(189002)(19625215002)(54356999)(40100003)(5001960100002)(122556002)(76176999)(19300405004)(87936001)(92566002)(16236675004)(33656002)(105586002)(2656002)(86362001)(5001860100001)(16234385003)(5001830100001)(76576001)(64706001)(101416001)(2900100001)(77096005)(102836002)(2950100001)(2420400003)(19617315012)(15975445007)(62966003)(77156002)(99286002)(50986999)(66066001)(46102003)(7110500001)(97736004)(189998001)(5001770100001)(81156007)(106116001)(68736005)(4001540100001)(74316001)(19580405001)(106356001)(19580395003); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR09MB0921; H:CY1PR09MB0922.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: mitre.org does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_CY1PR09MB09224CE45FD393D98576F2CCA8CC0CY1PR09MB0922namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 May 2015 03:42:54.4546 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c620dc48-1d50-4952-8b39-df4d54d74d82 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0921 X-OriginatorOrg: mitre.org Archived-At: Cc: "i2nsf@ietf.org" Subject: Re: [I2nsf] Definition for "Network Security Functions" X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 03:43:02 -0000 --_000_CY1PR09MB09224CE45FD393D98576F2CCA8CC0CY1PR09MB0922namp_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgRGFjaGVuZywNCg0KSSBndWVzcyBpdCBkZXBlbmRzIG9uIHdoYXQgc291cmNlcyB5b3UgcmVs eSBvbiBmb3IgdGhlIHVuZGVybHlpbmcgZGVmaW5pdGlvbnMuIEkgcmVmZXJlbmNlZCBOSVNUIFNw ZWNpYWwgUHVibGljYXRpb24gODAwLTUzIFJldmlzaW9uIDQsIFNlY3VyaXR5IGFuZCBQcml2YWN5 IENvbnRyb2xzIGZvciBGZWRlcmFsIEluZm9ybWF0aW9uIFN5c3RlbXMgYW5kIE9yZ2FuaXphdGlv bnMuIFdoaWxlIHRoZXJlIGFyZSBudW1lcm91cyBleGlzdGVuY2UgcHJvb2ZzIGluIDgwMC01MyB0 byByZWZ1dGUgeW91ciBhc3NlcnRpb24gYmVsb3cgd2l0aCByZXNwZWN0IHRvIGRldGVjdGlvbiwg SSB3b3VsZCBqdXN0IHBvaW50IHRvIHRoZSBkZWZpbml0aW9uIG9mIEFDLTQsIEluZm9ybWF0aW9u IEZsb3cgRW5mb3JjZW1lbnQsIGluIEFwcGVuZGl4IEYsIFNlY3VyaXR5IENvbnRyb2wgQ2F0YWxv ZywgZXNwZWNpYWxseSBlbmhhbmNlbWVudCBjbGF1c2VzICgzKSBhbmQgKDE1KS4gQXMgSSBzYWlk LCB0aGVyZSBhcmUgbWFueSBvdGhlcnMuDQoNCk9mIGNvdXJzZSwgaXQgY291bGQgYmUgdGhhdCA4 MDAtNTMgaXMgbm90IGFuIGFjY2VwdGFibGUgc291cmNlIGZvciBmb3VuZGF0aW9uYWwgZGVmaW5p dGlvbnMgZm9yIEkyTlNGLg0KDQpBdmFudGksDQpCb2JODQoNCkZyb206IEkybnNmIFttYWlsdG86 aTJuc2YtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIERhY2hlbmcgWmhhbmcNClNlbnQ6 IE1vbmRheSwgTWF5IDI1LCAyMDE1IDExOjAyIFBNDQpUbzogTmF0YWxlLCBCb2I7IEFsZXhleSBH b3JidW5vdjsgTGluZGEgRHVuYmFyDQpDYzogaTJuc2ZAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBb STJuc2ZdIERlZmluaXRpb24gZm9yICJOZXR3b3JrIFNlY3VyaXR5IEZ1bmN0aW9ucyINCg0KDQoN CreivP7IyzogIk5hdGFsZSwgQm9iIiA8Uk5BVEFMRUBtaXRyZS5vcmc8bWFpbHRvOlJOQVRBTEVA bWl0cmUub3JnPj4NCsjVxto6IDIwMTXE6jXUwjI2yNUg0MfG2rb+IMnPzucxMDo1NQ0K1sE6IEFs ZXhleSBHb3JidW5vdiA8YWxleGV5LmdvcmJ1bm92ODJAZ21haWwuY29tPG1haWx0bzphbGV4ZXku Z29yYnVub3Y4MkBnbWFpbC5jb20+PiwgTGluZGEgRHVuYmFyIDxsaW5kYS5kdW5iYXJAaHVhd2Vp LmNvbTxtYWlsdG86bGluZGEuZHVuYmFyQGh1YXdlaS5jb20+Pg0Ks63LzTogImkybnNmQGlldGYu b3JnPG1haWx0bzppMm5zZkBpZXRmLm9yZz4iIDxpMm5zZkBpZXRmLm9yZzxtYWlsdG86aTJuc2ZA aWV0Zi5vcmc+Pg0K1vfM4jogUmU6IFtJMm5zZl0gRGVmaW5pdGlvbiBmb3IgIk5ldHdvcmsgU2Vj dXJpdHkgRnVuY3Rpb25zIg0KDQpHaXZlbiBhZ3JlZW1lbnQgYXJvdW5kIERpZWdvoa9zIGRlZmlu aXRpb24sIEkgYmVsaWV2ZSBpdCBpcyBzdWZmaWNpZW50IHRvIHNheSChsEZ1bmN0aW9ucyB0byBl bnN1cmUgdGhlIGNvbmZpZGVudGlhbGl0eSwgaW50ZWdyaXR5LCBhbmQgYXZhaWxhYmxlIG9mIG5l dHdvcmsgY29tbXVuaWNhdGlvbnMuobEgKFB1dHRpbmcgIHRoZSBDSUEgaW4gdGhlIHRyYWRpdGlv bmFsIG9yZGVyLikgVGhlIHNlY29uZCBwYXJ0ICihsHRvIGRldGVjdCB1bndhbnRlZCBhY3Rpdml0 eSwgYW5kIHRvIGRldGVyIGl0IG9yIGF0IGxlYXN0IG1pdGlnYXRlIGl0cyBlZmZlY3RzIG9uIHRo ZSBuZXR3b3JrobEpIGFkZHMgbm90aGluZyB0aGF0IGlzIG5vdCBhbHJlYWR5IGluY2x1ZGVkIGlu IHRoZSBmaXJzdCBwYXJ0IGJ1dCBpbXBsaWNpdGx5IChieSBvbWlzc2lvbikgZXhjbHVkZXMgc29t ZSBmdW5jdGlvbnMgKGUuZy4sIHByZXZlbnRpdmUgZnVuY3Rpb25zKSB0aGF0IGFyZSAobm9ybWFs bHkpIGluY2x1ZGVkLg0KDQpEYWNoZW5nOi8vIEkgdGhpbmsgQ0lBIGNhbm5vdCByZWFsbHkgdGFr ZSBwbGFjZSBvZiB0aGUgc2Vjb25kIHBhcnQuIFRoZSBDSUEgaXMgYWJvdXQgZW5zdXJpbmcgZGF0 YSChrnNlY3VyZWx5JyB0cmFuc3BvcnRlZCBvdmVyIHRoZSBuZXR3b3JrLiBUaGUgc2Vjb25kIHBh cnQgaXMgYWJvdXQgZGV0ZWN0aW5nIHRoZSBpbXByb3BlciBjb250ZW50IGluIHRoZSBkYXRhIG9y IGltcHJvcGVyIHNpZ25hbGluZyB3aGljaCBtYXkgYWZmZWN0IHRoZSBub3JtYWwgb3BlcmF0b3Jz IG9mIG5ldHdvcmsgc3lzdGVtcy4NCg0KDQoNCg0KDQoNCg0KQnkgZXh0ZW5zaW9uLCBJIHdvdWxk IGFsc28gc2F5IHRoYXQgdGhlIGRlZmluaXRpb24gcGVyIGFib3ZlIGV4dGVuZHMgdG8gdGhlIHJl c291cmNlcyAoZGV2aWNlcywgYXBwbGljYXRpb25zLCBzZXJ2aWNlcykgbmVjZXNzYXJ5IHRvIHN1 cHBvcnQgbmV0d29yayBjb21tdW5pY2F0aW9ucyChrSBzaW5jZSBhIHZpb2xhdGlvbiBvZiBzZWN1 cml0eSB0aGVyZSBoYXMgYSBwb3RlbnRpYWwgIHVuZGVzaXJlZCBlZmZlY3QgaW4gdGhlIG5ldHdv cmsgdHJhZmZpYy4NCg0KU28sIEkgbWlnaHQgc3VnZ2VzdCBhbiBleHRlbnNpb24gb2YgdGhlIGRl ZmluaXRpb24gdG8gobBGdW5jdGlvbnMgdG8gZW5zdXJlIHRoZSBjb25maWRlbnRpYWxpdHksIGlu dGVncml0eSwgYW5kIGF2YWlsYWJpbGl0eSBvZiBuZXR3b3JrIGNvbW11bmljYXRpb25zIGFuZCB0 aGUgcmVzb3VyY2VzIHVzZWQgdG8gc3VwcG9ydCBuZXR3b3JrIGNvbW11bmljYXRpb25zLqGxIKGt Pw0KDQpBdmFudGksDQpCb2JODQoNCkZyb206IEkybnNmIFttYWlsdG86aTJuc2YtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFsZXhleSBHb3JidW5vdg0KU2VudDogTW9uZGF5LCBNYXkg MjUsIDIwMTUgNjo0MiBQTQ0KVG86IGkybnNmQGlldGYub3JnPG1haWx0bzppMm5zZkBpZXRmLm9y Zz47IExpbmRhIER1bmJhcg0KU3ViamVjdDogW0kybnNmXSBEZWZpbml0aW9uIGZvciAiTmV0d29y ayBTZWN1cml0eSBGdW5jdGlvbnMiDQoNCkhpIEFsbA0KDQpJIGFncmVlIHdpdGggRGllZ28gZGVm aW5pdGlvbjoNCiJmdW5jdGlvbnMgdG8gZW5zdXJlIGludGVncml0eSwgY29uZmlkZW50aWFsaXR5 IGFuZCBhdmFpbGFiaWxpdHkgb2YgbmV0d29yayBjb21tdW5pY2F0aW9ucywgdG8gZGV0ZWN0IHVu d2FudGVkIGFjdGl2aXR5LCBhbmQgdG8gZGV0ZXIgaXQgb3IgYXQgbGVhc3QgbWl0aWdhdGUgaXRz IGVmZmVjdHMgb24gdGhlIG5ldHdvcmsiDQoNCkZyb20gbXkgcG9pbnQgb2YgdmlldyB0aGF0IGNv dmVycyBhbGwgY2FzZXMgb2YgbmV0d29yayBzZWN1cml0eSBmdW5jdGlvbi4NCg0KUmVnYXJkaW5n IEZsb3ctYmFzZWQgbmV0d29yayBzZWN1cml0eSBmdW5jdGlvbjoNCg0KobAgQSBmdW5jdGlvbiB0 aGF0IGluc3BlY3RzIG5ldHdvcmsgZmxvd3MgYWNjb3JkaW5nIHRvIGEgcG9saWN5IGludGVuZGVk IGZvciBlbmZvcmNpbmcgc2VjdXJpdHkgcHJvcGVydGllcy4gIEZsb3ctYmFzZWQgc2VjdXJpdHkg YWxzbyBtZWFucyB0aGF0IHBhY2tldHMgYXJlIGluc3BlY3RlZCBpbiB0aGUgb3JkZXIgdGhleSBh cmUgcmVjZWl2ZWQsIGFuZCB3aXRob3V0IG1vZGlmaWNhdGlvbiB0byB0aGUgcGFja2V0IGR1ZSB0 byB0aGUgaW5zcGVjdGlvbiBwcm9jZXNzIChNQUMgcmV3cml0ZXMsIFRUTCBkZWNyZW1lbnQgYWN0 aW9uOyBldmVuIE5BVCB3b3VsZCBiZSBvdXRzaWRlIHRoZSBpbnNwZWN0aW9uIHByb2Nlc3MpLg0K DQpJJ20gbm90IHN1cmUgaWYgaXQncyB2YWx1YWJsZSAgdG8gaW5zcGVjdCBwYWNrZXQgd2l0aG91 dCBtb2RpZmljYXRpb24uIFRoZXJlIGFyZSBjYXNlcyB3aGVuIGl0J3MgbW9yZSBwcmVmZXJhYmxl IHRvIGluc3BlY3QgYW5kIGFwcGx5IHBvbGljeSBhZnRlciBOQVQuICBUaGlzIGlzIGNvbW1vbiBw cmFjdGljZSBhbmQgaXQgbXVzdCBiZSBhIGdvb2QgcmVhc29uIHRvIGNoYW5nZSBpdC4NCg0KQnIs IEFsZXhleSBHb3JidW5vdg0KVGVsY28gQ2xvdWQgYW5kIFNlY3VyaXR5IEFyY2hpdGVjdCBhdCBO b2tpYQ0KQ0NJRSBSJlMgNDEwODgNCg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXyBJMm5zZiBtYWlsaW5nIGxpc3QgSTJuc2ZAaWV0Zi5vcmc8 bWFpbHRvOkkybnNmQGlldGYub3JnPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2kybnNmDQo= --_000_CY1PR09MB09224CE45FD393D98576F2CCA8CC0CY1PR09MB0922namp_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Dacheng,

 

I guess it depends on what = sources you rely on for the underlying definitions. I referenced NIST Speci= al Publication 800-53 Revision 4, Security and Privacy Controls for Federal Information Systems and Organizations. While = there are numerous existence proofs in 800-53 to refute your assertion belo= w with respect to detection, I would just point to the definition of AC-4, = Information Flow Enforcement, in Appendix F, Security Control Catalog, especially enhancement clauses (3) a= nd (15). As I said, there are many others.

 

Of course, it could be that= 800-53 is not an acceptable source for foundational definitions for I2NSF.=

 

Avanti,

BobN

 

From: I2nsf [mailto:i2nsf-bounces@ie= tf.org] On Behalf Of Dacheng Zhang
Sent: Monday, May 25, 2015 11:02 PM
To: Natale, Bob; Alexey Gorbunov; Linda Dunbar
Cc: i2nsf@ietf.org
Subject: Re: [I2nsf] Definition for "Network Security Functions= "

 

&n= bsp;

&n= bsp;

=B7=A2=BC=FE=C8=CB: "Natale, Bob" <RNATALE@mitre.org>
=C8=D5=C6=DA: 2015=C4=EA5=D4=C226=C8=D5 =D0=C7=C6=DA=B6=FE =C9=CF=CE=E710:55
=D6=C1: Alexey Gorbunov <alexey.gorbunov82@gmail.com>, Linda Dunbar <linda.dunbar@huawei.com>
=B3=AD=CB=CD: "i2nsf@ietf.= org" <i2nsf@ietf.org><= br> =D6=F7=CC=E2: Re: [I2nsf] Definition for "Network Security F= unctions"

 

Given agreement around Diego=A1=AFs definition, I beli= eve it is sufficient to say =A1=B0Functions to ensure the confidentiality, = integrity, and available of network communications.=A1=B1 (Putting  the CIA in the traditional order.) The second part (=A1=B0to detect unwant= ed activity, and to deter it or at least mitigate its effects on the networ= k=A1=B1) adds nothing that is not already included in the first part but im= plicitly (by omission) excludes some functions (e.g., preventive functions) that are (normally) included.

 

Dacheng:// I think CIA cannot really take place of the second p= art. The CIA is about ensuring data =A1=AEsecurely' transported over the network. T= he second part is about detecting the improper content in the data or impro= per signaling which may affect the normal operators of network systems.&nbs= p;

 

 

 

 

 

 

 

By extension, I would also say that the definition per= above extends to the resources (devices, applications, services) necessary= to support network communications =A1=AD since a violation of security there has a potential  undesired effect in the network tr= affic.

 

So, I might suggest an extension of the definition to = =A1=B0Functions to ensure the confidentiality, integrity, and availability = of network communications and the resources used to support network communications.=A1=B1 =A1=AD?

 

Avanti,<= /span>

BobN

 

From: I2nsf = [mailto:i2nsf-bounces@ietf.org] On Behalf Of Alexey Gorbunov
Sent: Monday, May 25, 2015 6:42 PM
To: i2nsf@ietf.org; Linda Dunb= ar
Subject: [I2nsf] Definition for "Network Security Functions&quo= t;

 =

Hi All=

 =

I agree with Diego defin= ition: 

"functions to ensur= e integrity, confidentiality and availability of network communications, to= detect unwanted activity, and to deter it or at least mitigate its effects= on the network"

 =

From my point of view th= at covers all cases of network security function.

 =

Regarding Flow-based net= work security function:

 =

=A1=B0 A function that i= nspects network flows according to a policy intended for enforcing security= properties.  Flow-based security also means that packets are inspecte= d in the order they are received, and without modification to the packet due to the inspection process (MAC rewrites, TT= L decrement action; even NAT would be outside the inspection process).=

 =

I'm not sure if it's val= uable  to inspect packet without modification. There are cases when it= 's more preferable to inspect and apply policy after NAT.  This is com= mon practice and it must be a good reason to change it. 

 =

Br, Alexey Gorbunov=

Telco Cloud and Security= Architect at Nokia

CCIE R&S 41088<= /o:p>

 =

 =

 

 =

 =

_______________________________________________ I2nsf mailing l= ist I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf

--_000_CY1PR09MB09224CE45FD393D98576F2CCA8CC0CY1PR09MB0922namp_-- From nobody Tue May 26 01:07:27 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4D6F1B2A36 for ; Tue, 26 May 2015 01:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xjHaqpMX9Oqv for ; Tue, 26 May 2015 01:07:19 -0700 (PDT) Received: from smtpjc.telefonica.com (smtpjc.telefonica.com [81.47.204.76]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E5F21B2A34 for ; Tue, 26 May 2015 01:07:17 -0700 (PDT) Received: from smtpjc.telefonica.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id F03B32D03D0; Tue, 26 May 2015 10:07:14 +0200 (CEST) Received-SPF: PermError (tgtimjc802.telefonica.com: domain of diego.r.lopez@telefonica.com uses mechanism not recognized by this client) identity=MAILFROM; client-ip=10.92.4.9; envelope-from=diego.r.lopez@telefonica.com; helo=ESTGVMSP111.EUROPE.telefonica.corp) Received: from ESTGVMSP111.EUROPE.telefonica.corp (unknown [10.92.4.9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtpjc.telefonica.com (Postfix) with ESMTPS id D16BC2D03B8; Tue, 26 May 2015 10:07:14 +0200 (CEST) Received: from emea01-am1-obe.outbound.protection.outlook.com (10.92.5.139) by tls.telefonica.com (10.92.6.54) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 26 May 2015 10:07:14 +0200 Received: from DB4PR06MB0624.eurprd06.prod.outlook.com (25.161.13.142) by DB4PR06MB0622.eurprd06.prod.outlook.com (25.161.13.140) with Microsoft SMTP Server (TLS) id 15.1.172.22; Tue, 26 May 2015 08:07:12 +0000 Received: from DB4PR06MB0624.eurprd06.prod.outlook.com ([25.161.13.142]) by DB4PR06MB0624.eurprd06.prod.outlook.com ([25.161.13.142]) with mapi id 15.01.0172.012; Tue, 26 May 2015 08:07:12 +0000 From: DIEGO LOPEZ GARCIA To: "Natale, Bob" Thread-Topic: [I2nsf] Definition for "Network Security Functions" Thread-Index: AQHQl2BNa4vNWv2L/0eeFKdse1pxfJ2NnVcAgABJ2AA= Date: Tue, 26 May 2015 08:07:11 +0000 Message-ID: <241A3C3B-E261-4E27-9BBD-B4925179C1F9@telefonica.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=diego.r.lopez@telefonica.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [83.49.236.188] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB4PR06MB0622; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(520002)(3002001); SRVR:DB4PR06MB0622; BCL:0; PCL:0; RULEID:; SRVR:DB4PR06MB0622; x-forefront-prvs: 0588B2BD96 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(189002)(53754006)(252514010)(199003)(377454003)(24454002)(110136002)(5001960100002)(189998001)(5001860100001)(5001830100001)(46102003)(33656002)(16236675004)(19580405001)(19580395003)(86362001)(64706001)(101416001)(66066001)(87936001)(83716003)(7110500001)(2656002)(76176999)(50986999)(54356999)(2420400003)(102836002)(15975445007)(16234385003)(122556002)(68736005)(40100003)(106116001)(105586002)(2950100001)(2900100001)(19617315012)(82746002)(77156002)(62966003)(106356001)(36756003)(92566002)(4001540100001)(97736004)(81156007)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR06MB0622; H:DB4PR06MB0624.eurprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: telefonica.com does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_241A3C3BE2614E279BBDB4925179C1F9telefonicacom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 May 2015 08:07:11.5210 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR06MB0622 X-OriginatorOrg: telefonica.com X-TM-AS-MML: No Archived-At: Cc: "i2nsf@ietf.org" , Alexey Gorbunov , Dacheng Zhang , Linda Dunbar Subject: Re: [I2nsf] Definition for "Network Security Functions" X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 08:07:25 -0000 --_000_241A3C3BE2614E279BBDB4925179C1F9telefonicacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQm9iLA0KDQpIYXZpbmcgc3BlbnQgbXkgcHJvZmVzc2lvbmFsIGxpZmUgdHJ5aW5nIHRvIGFw cGx5IGdvb2Qtb2xlIEZyaWFyIFdpbGxpYW0ncyByYXpvciwgSSBhZ3JlZSB0aGUgc2hvcnRlciB2 ZXJzaW9uIHlvdSBwcm9wb3NlIHdvdWxkIGJlIGNvcnJlY3QgYW5kIGNvbXBsZXRlLiBCdXQgYWNj b3JkaW5nIHRvIG15IGV4cGVyaWVuY2UgSSB0aGluayBpdCB3b3VsZCBiZSBnb29kIHRvIGxlYXZl IHRoZSBzZWNvbmQgcGFydCBhc2sgd2VsbCBpbiBvcmRlciB0byBhdm9pZCBtaXN1bmRlcnN0YW5k aW5ncyBsaWtlIHRoZSBjb25jZXJuIGV4cHJlc3NlZCBieSBEYWNoZW5nLg0KDQpUaGVyZSBpcyBh IHZhbHVlIGluIGJlaW5nIHNvbWVob3cgcmVkdW5kYW50IGlmIGl0IGlzIHRoZSBwcmljZSB5b3Ug cGF5IHRvIGF2b2lkIG1pc2NvbmNlcHRpb24uDQoNCkJlIGdvb2RlLA0KDQpPbiAyNiBNYXkgMjAx NSwgYXQgMDU6NDIgLCBOYXRhbGUsIEJvYiA8Uk5BVEFMRUBtaXRyZS5vcmc8bWFpbHRvOlJOQVRB TEVAbWl0cmUub3JnPj4gd3JvdGU6DQoNCkhpIERhY2hlbmcsDQoNCkkgZ3Vlc3MgaXQgZGVwZW5k cyBvbiB3aGF0IHNvdXJjZXMgeW91IHJlbHkgb24gZm9yIHRoZSB1bmRlcmx5aW5nIGRlZmluaXRp b25zLiBJIHJlZmVyZW5jZWQgTklTVCBTcGVjaWFsIFB1YmxpY2F0aW9uIDgwMC01MyBSZXZpc2lv biA0LCBTZWN1cml0eSBhbmQgUHJpdmFjeSBDb250cm9scyBmb3IgRmVkZXJhbCBJbmZvcm1hdGlv biBTeXN0ZW1zIGFuZCBPcmdhbml6YXRpb25zLiBXaGlsZSB0aGVyZSBhcmUgbnVtZXJvdXMgZXhp c3RlbmNlIHByb29mcyBpbiA4MDAtNTMgdG8gcmVmdXRlIHlvdXIgYXNzZXJ0aW9uIGJlbG93IHdp dGggcmVzcGVjdCB0byBkZXRlY3Rpb24sIEkgd291bGQganVzdCBwb2ludCB0byB0aGUgZGVmaW5p dGlvbiBvZiBBQy00LCBJbmZvcm1hdGlvbiBGbG93IEVuZm9yY2VtZW50LCBpbiBBcHBlbmRpeCBG LCBTZWN1cml0eSBDb250cm9sIENhdGFsb2csIGVzcGVjaWFsbHkgZW5oYW5jZW1lbnQgY2xhdXNl cyAoMykgYW5kICgxNSkuIEFzIEkgc2FpZCwgdGhlcmUgYXJlIG1hbnkgb3RoZXJzLg0KDQpPZiBj b3Vyc2UsIGl0IGNvdWxkIGJlIHRoYXQgODAwLTUzIGlzIG5vdCBhbiBhY2NlcHRhYmxlIHNvdXJj ZSBmb3IgZm91bmRhdGlvbmFsIGRlZmluaXRpb25zIGZvciBJMk5TRi4NCg0KQXZhbnRpLA0KQm9i Tg0KDQpGcm9tOiBJMm5zZiBbbWFpbHRvOmkybnNmLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBEYWNoZW5nIFpoYW5nDQpTZW50OiBNb25kYXksIE1heSAyNSwgMjAxNSAxMTowMiBQTQ0K VG86IE5hdGFsZSwgQm9iOyBBbGV4ZXkgR29yYnVub3Y7IExpbmRhIER1bmJhcg0KQ2M6IGkybnNm QGlldGYub3JnPG1haWx0bzppMm5zZkBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbSTJuc2ZdIERl ZmluaXRpb24gZm9yICJOZXR3b3JrIFNlY3VyaXR5IEZ1bmN0aW9ucyINCg0KDQoNCuWPkeS7tuS6 ujogIk5hdGFsZSwgQm9iIiA8Uk5BVEFMRUBtaXRyZS5vcmc8bWFpbHRvOlJOQVRBTEVAbWl0cmUu b3JnPj4NCuaXpeacnzogMjAxNeW5tDXmnIgyNuaXpSDmmJ/mnJ/kuowg5LiK5Y2IMTA6NTUNCuiH szogQWxleGV5IEdvcmJ1bm92IDxhbGV4ZXkuZ29yYnVub3Y4MkBnbWFpbC5jb208bWFpbHRvOmFs ZXhleS5nb3JidW5vdjgyQGdtYWlsLmNvbT4+LCBMaW5kYSBEdW5iYXIgPGxpbmRhLmR1bmJhckBo dWF3ZWkuY29tPG1haWx0bzpsaW5kYS5kdW5iYXJAaHVhd2VpLmNvbT4+DQrmioTpgIE6ICJpMm5z ZkBpZXRmLm9yZzxtYWlsdG86aTJuc2ZAaWV0Zi5vcmc+IiA8aTJuc2ZAaWV0Zi5vcmc8bWFpbHRv OmkybnNmQGlldGYub3JnPj4NCuS4u+mimDogUmU6IFtJMm5zZl0gRGVmaW5pdGlvbiBmb3IgIk5l dHdvcmsgU2VjdXJpdHkgRnVuY3Rpb25zIg0KDQpHaXZlbiBhZ3JlZW1lbnQgYXJvdW5kIERpZWdv 4oCZcyBkZWZpbml0aW9uLCBJIGJlbGlldmUgaXQgaXMgc3VmZmljaWVudCB0byBzYXkg4oCcRnVu Y3Rpb25zIHRvIGVuc3VyZSB0aGUgY29uZmlkZW50aWFsaXR5LCBpbnRlZ3JpdHksIGFuZCBhdmFp bGFibGUgb2YgbmV0d29yayBjb21tdW5pY2F0aW9ucy7igJ0gKFB1dHRpbmcgIHRoZSBDSUEgaW4g dGhlIHRyYWRpdGlvbmFsIG9yZGVyLikgVGhlIHNlY29uZCBwYXJ0ICjigJx0byBkZXRlY3QgdW53 YW50ZWQgYWN0aXZpdHksIGFuZCB0byBkZXRlciBpdCBvciBhdCBsZWFzdCBtaXRpZ2F0ZSBpdHMg ZWZmZWN0cyBvbiB0aGUgbmV0d29ya+KAnSkgYWRkcyBub3RoaW5nIHRoYXQgaXMgbm90IGFscmVh ZHkgaW5jbHVkZWQgaW4gdGhlIGZpcnN0IHBhcnQgYnV0IGltcGxpY2l0bHkgKGJ5IG9taXNzaW9u KSBleGNsdWRlcyBzb21lIGZ1bmN0aW9ucyAoZS5nLiwgcHJldmVudGl2ZSBmdW5jdGlvbnMpIHRo YXQgYXJlIChub3JtYWxseSkgaW5jbHVkZWQuDQoNCkRhY2hlbmc6Ly8gSSB0aGluayBDSUEgY2Fu bm90IHJlYWxseSB0YWtlIHBsYWNlIG9mIHRoZSBzZWNvbmQgcGFydC4gVGhlIENJQSBpcyBhYm91 dCBlbnN1cmluZyBkYXRh4oCYc2VjdXJlbHknIHRyYW5zcG9ydGVkIG92ZXIgdGhlIG5ldHdvcmsu IFRoZSBzZWNvbmQgcGFydCBpcyBhYm91dCBkZXRlY3RpbmcgdGhlIGltcHJvcGVyIGNvbnRlbnQg aW4gdGhlIGRhdGEgb3IgaW1wcm9wZXIgc2lnbmFsaW5nIHdoaWNoIG1heSBhZmZlY3QgdGhlIG5v cm1hbCBvcGVyYXRvcnMgb2YgbmV0d29yayBzeXN0ZW1zLg0KDQoNCg0KDQoNCg0KDQpCeSBleHRl bnNpb24sIEkgd291bGQgYWxzbyBzYXkgdGhhdCB0aGUgZGVmaW5pdGlvbiBwZXIgYWJvdmUgZXh0 ZW5kcyB0byB0aGUgcmVzb3VyY2VzIChkZXZpY2VzLCBhcHBsaWNhdGlvbnMsIHNlcnZpY2VzKSBu ZWNlc3NhcnkgdG8gc3VwcG9ydCBuZXR3b3JrIGNvbW11bmljYXRpb25zIOKApiBzaW5jZSBhIHZp b2xhdGlvbiBvZiBzZWN1cml0eSB0aGVyZSBoYXMgYSBwb3RlbnRpYWwgIHVuZGVzaXJlZCBlZmZl Y3QgaW4gdGhlIG5ldHdvcmsgdHJhZmZpYy4NCg0KU28sIEkgbWlnaHQgc3VnZ2VzdCBhbiBleHRl bnNpb24gb2YgdGhlIGRlZmluaXRpb24gdG8g4oCcRnVuY3Rpb25zIHRvIGVuc3VyZSB0aGUgY29u ZmlkZW50aWFsaXR5LCBpbnRlZ3JpdHksIGFuZCBhdmFpbGFiaWxpdHkgb2YgbmV0d29yayBjb21t dW5pY2F0aW9ucyBhbmQgdGhlIHJlc291cmNlcyB1c2VkIHRvIHN1cHBvcnQgbmV0d29yayBjb21t dW5pY2F0aW9ucy7igJ0g4oCmPw0KDQpBdmFudGksDQpCb2JODQoNCkZyb206IEkybnNmIFttYWls dG86aTJuc2YtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFsZXhleSBHb3JidW5vdg0K U2VudDogTW9uZGF5LCBNYXkgMjUsIDIwMTUgNjo0MiBQTQ0KVG86IGkybnNmQGlldGYub3JnPG1h aWx0bzppMm5zZkBpZXRmLm9yZz47IExpbmRhIER1bmJhcg0KU3ViamVjdDogW0kybnNmXSBEZWZp bml0aW9uIGZvciAiTmV0d29yayBTZWN1cml0eSBGdW5jdGlvbnMiDQoNCkhpIEFsbA0KDQpJIGFn cmVlIHdpdGggRGllZ28gZGVmaW5pdGlvbjoNCiJmdW5jdGlvbnMgdG8gZW5zdXJlIGludGVncml0 eSwgY29uZmlkZW50aWFsaXR5IGFuZCBhdmFpbGFiaWxpdHkgb2YgbmV0d29yayBjb21tdW5pY2F0 aW9ucywgdG8gZGV0ZWN0IHVud2FudGVkIGFjdGl2aXR5LCBhbmQgdG8gZGV0ZXIgaXQgb3IgYXQg bGVhc3QgbWl0aWdhdGUgaXRzIGVmZmVjdHMgb24gdGhlIG5ldHdvcmsiDQoNCkZyb20gbXkgcG9p bnQgb2YgdmlldyB0aGF0IGNvdmVycyBhbGwgY2FzZXMgb2YgbmV0d29yayBzZWN1cml0eSBmdW5j dGlvbi4NCg0KUmVnYXJkaW5nIEZsb3ctYmFzZWQgbmV0d29yayBzZWN1cml0eSBmdW5jdGlvbjoN Cg0K4oCcIEEgZnVuY3Rpb24gdGhhdCBpbnNwZWN0cyBuZXR3b3JrIGZsb3dzIGFjY29yZGluZyB0 byBhIHBvbGljeSBpbnRlbmRlZCBmb3IgZW5mb3JjaW5nIHNlY3VyaXR5IHByb3BlcnRpZXMuICBG bG93LWJhc2VkIHNlY3VyaXR5IGFsc28gbWVhbnMgdGhhdCBwYWNrZXRzIGFyZSBpbnNwZWN0ZWQg aW4gdGhlIG9yZGVyIHRoZXkgYXJlIHJlY2VpdmVkLCBhbmQgd2l0aG91dCBtb2RpZmljYXRpb24g dG8gdGhlIHBhY2tldCBkdWUgdG8gdGhlIGluc3BlY3Rpb24gcHJvY2VzcyAoTUFDIHJld3JpdGVz LCBUVEwgZGVjcmVtZW50IGFjdGlvbjsgZXZlbiBOQVQgd291bGQgYmUgb3V0c2lkZSB0aGUgaW5z cGVjdGlvbiBwcm9jZXNzKS4NCg0KSSdtIG5vdCBzdXJlIGlmIGl0J3MgdmFsdWFibGUgIHRvIGlu c3BlY3QgcGFja2V0IHdpdGhvdXQgbW9kaWZpY2F0aW9uLiBUaGVyZSBhcmUgY2FzZXMgd2hlbiBp dCdzIG1vcmUgcHJlZmVyYWJsZSB0byBpbnNwZWN0IGFuZCBhcHBseSBwb2xpY3kgYWZ0ZXIgTkFU LiAgVGhpcyBpcyBjb21tb24gcHJhY3RpY2UgYW5kIGl0IG11c3QgYmUgYSBnb29kIHJlYXNvbiB0 byBjaGFuZ2UgaXQuDQoNCkJyLCBBbGV4ZXkgR29yYnVub3YNClRlbGNvIENsb3VkIGFuZCBTZWN1 cml0eSBBcmNoaXRlY3QgYXQgTm9raWENCkNDSUUgUiZTIDQxMDg4DQoNCg0KDQoNCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gSTJuc2YgbWFpbGluZyBs aXN0IEkybnNmQGlldGYub3JnPG1haWx0bzpJMm5zZkBpZXRmLm9yZz5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2kybnNmDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KSTJuc2YgbWFpbGluZyBsaXN0DQpJMm5zZkBpZXRmLm9yZzxt YWlsdG86STJuc2ZAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2kybnNmDQoNCi0tDQoiRXN0YSB2ZXogbm8gZmFsbGFyZW1vcywgRG9jdG9yIEluZmllcm5v Ig0KDQpEciBEaWVnbyBSLiBMb3Bleg0KVGVsZWZvbmljYSBJK0QNCmh0dHA6Ly9wZW9wbGUudGlk LmVzL2RpZWdvLmxvcGV6Lw0KDQplLW1haWw6IGRpZWdvLnIubG9wZXpAdGVsZWZvbmljYS5jb20N ClRlbDogICAgKzM0IDkxMyAxMjkgMDQxDQpNb2JpbGU6ICszNCA2ODIgMDUxIDA5MQ0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQoNCkVzdGUgbWVuc2FqZSB5IHN1cyBhZGp1bnRvcyBzZSBkaXJpZ2VuIGV4Y2x1 c2l2YW1lbnRlIGEgc3UgZGVzdGluYXRhcmlvLCBwdWVkZSBjb250ZW5lciBpbmZvcm1hY2nDs24g cHJpdmlsZWdpYWRhIG8gY29uZmlkZW5jaWFsIHkgZXMgcGFyYSB1c28gZXhjbHVzaXZvIGRlIGxh IHBlcnNvbmEgbyBlbnRpZGFkIGRlIGRlc3Rpbm8uIFNpIG5vIGVzIHVzdGVkLiBlbCBkZXN0aW5h dGFyaW8gaW5kaWNhZG8sIHF1ZWRhIG5vdGlmaWNhZG8gZGUgcXVlIGxhIGxlY3R1cmEsIHV0aWxp emFjacOzbiwgZGl2dWxnYWNpw7NuIHkvbyBjb3BpYSBzaW4gYXV0b3JpemFjacOzbiBwdWVkZSBl c3RhciBwcm9oaWJpZGEgZW4gdmlydHVkIGRlIGxhIGxlZ2lzbGFjacOzbiB2aWdlbnRlLiBTaSBo YSByZWNpYmlkbyBlc3RlIG1lbnNhamUgcG9yIGVycm9yLCBsZSByb2dhbW9zIHF1ZSBub3MgbG8g Y29tdW5pcXVlIGlubWVkaWF0YW1lbnRlIHBvciBlc3RhIG1pc21hIHbDrWEgeSBwcm9jZWRhIGEg c3UgZGVzdHJ1Y2Npw7NuLg0KDQpUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgdHJh bnNtaXNzaW9uIGlzIHByaXZpbGVnZWQgYW5kIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiBpbnRl bmRlZCBvbmx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSBuYW1lZCBh Ym92ZS4gSWYgdGhlIHJlYWRlciBvZiB0aGlzIG1lc3NhZ2UgaXMgbm90IHRoZSBpbnRlbmRlZCBy ZWNpcGllbnQsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IGRpc3NlbWluYXRpb24s IGRpc3RyaWJ1dGlvbiBvciBjb3B5aW5nIG9mIHRoaXMgY29tbXVuaWNhdGlvbiBpcyBzdHJpY3Rs eSBwcm9oaWJpdGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIHRyYW5zbWlzc2lvbiBpbiBl cnJvciwgZG8gbm90IHJlYWQgaXQuIFBsZWFzZSBpbW1lZGlhdGVseSByZXBseSB0byB0aGUgc2Vu ZGVyIHRoYXQgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yIGFu ZCB0aGVuIGRlbGV0ZSBpdC4NCg0KRXN0YSBtZW5zYWdlbSBlIHNldXMgYW5leG9zIHNlIGRpcmln ZW0gZXhjbHVzaXZhbWVudGUgYW8gc2V1IGRlc3RpbmF0w6FyaW8sIHBvZGUgY29udGVyIGluZm9y bWHDp8OjbyBwcml2aWxlZ2lhZGEgb3UgY29uZmlkZW5jaWFsIGUgw6kgcGFyYSB1c28gZXhjbHVz aXZvIGRhIHBlc3NvYSBvdSBlbnRpZGFkZSBkZSBkZXN0aW5vLiBTZSBuw6NvIMOpIHZvc3NhIHNl bmhvcmlhIG8gZGVzdGluYXTDoXJpbyBpbmRpY2FkbywgZmljYSBub3RpZmljYWRvIGRlIHF1ZSBh IGxlaXR1cmEsIHV0aWxpemHDp8OjbywgZGl2dWxnYcOnw6NvIGUvb3UgY8OzcGlhIHNlbSBhdXRv cml6YcOnw6NvIHBvZGUgZXN0YXIgcHJvaWJpZGEgZW0gdmlydHVkZSBkYSBsZWdpc2xhw6fDo28g dmlnZW50ZS4gU2UgcmVjZWJldSBlc3RhIG1lbnNhZ2VtIHBvciBlcnJvLCByb2dhbW9zLWxoZSBx dWUgbm9zIG8gY29tdW5pcXVlIGltZWRpYXRhbWVudGUgcG9yIGVzdGEgbWVzbWEgdmlhIGUgcHJv Y2VkYSBhIHN1YSBkZXN0cnVpw6fDo28NCg== --_000_241A3C3BE2614E279BBDB4925179C1F9telefonicacom_ Content-Type: text/html; charset="utf-8" Content-ID: <60492ED46DC7934CA52D490021BF156D@eurprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Hi Bob,

Having spent my professional life trying to apply good-ole Friar Willi= am's razor, I agree the shorter version you propose would be correct and co= mplete. But according to my experience I think it would be good to leave th= e second part ask well in order to avoid misunderstandings like the concern expressed by Dacheng.

There is a value in being somehow redundant if it is the price you pay= to avoid misconception.

Be goode,

On 26 May 2015, at 05:42 , Natale, Bob <RNATALE@mitre.org> wrote:

H= i Dacheng,
&= nbsp;
I= guess it depends on what sources you rely on for the underlying definition= s. I referenced NIST Special Publication 800-53 Revision 4, Security and Pr= ivacy Controls for Federal Information Systems and Organizations. While there are numerous existence proofs in 80= 0-53 to refute your assertion below with respect to detection, I would just= point to the definition of AC-4, Information Flow Enforcement, in Appendix= F, Security Control Catalog, especially enhancement clauses (3) and (15). As I said, there are many others.
&= nbsp;
O= f course, it could be that 800-53 is not an acceptable source for foundatio= nal definitions for I2NSF.
&= nbsp;
A= vanti,
B= obN
&= nbsp;
From:=  I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Dacheng Zh= ang
Sent: Monday, May = 25, 2015 11:02 PM
To: Natale, Bob; A= lexey Gorbunov; Linda Dunbar
Cc: i2nsf@ietf.org
Subject: Re: [I2ns= f] Definition for "Network Security Functions"<= /div>
 
 
 
=E5= =8F=91=E4=BB=B6=E4=BA=BA: = "Natale, Bob" <RNATALE@mitre.org>
=E6=97=A5=E6=9C=9F: 2015=E5=B9=B45=E6=9C=8826=E6=97=A5 =E6=98=9F= =E6=9C=9F=E4=BA=8C =E4=B8=8A=E5=8D=8810:55
=E8=87=B3: A= lexey Gorbunov <alexey.gorbunov82@gmail.c= om>, Linda Dunbar <linda.dunbar@h= uawei.com>
=E6=8A=84=E9=80=81: "i2nsf@ietf.org" <i2nsf@ietf.org>
=E4=B8=BB=E9=A2=98: Re: [I2nsf] Definition for "Network Security Functions"
 
G= iven agreement around Diego=E2=80=99s definition, I believe it is sufficien= t to say =E2=80=9CFunctions to ensure the confidentiality, integrity, and a= vailable of network communications.=E2=80=9D (Putting  the CIA in the traditional order.) The second part (=E2=80=9Cto detect unwante= d activity, and to deter it or at least mitigate its effects on the network= =E2=80=9D) adds nothing that is not already included in the first part but = implicitly (by omission) excludes some functions (e.g., preventive functions) that are (normally) included.
 
Dacheng:// I think = CIA cannot really take place of the second part. The CIA is about ensuring = data=E2=80=98securely' transported over the net= work. The second part is about detecting the improper content in the data or improper signaling which may affect the no= rmal operators of network systems. 
 
 
 
 
 
 
&= nbsp;
B= y extension, I would also say that the definition per above extends to the = resources (devices, applications, services) necessary to support network co= mmunications =E2=80=A6 since a violation of security there has a potential  undesired effect in the network traff= ic.
&= nbsp;
S= o, I might suggest an extension of the definition to =E2=80=9CFunctions to = ensure the confidentiality, integrity, and availability of network communic= ations and the resources used to support network communications.=E2=80=9D =E2=80=A6?
&= nbsp;
A= vanti,
B= obN
&= nbsp;
From:=  I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Alexey Gor= bunov
Sent: Monday, May = 25, 2015 6:42 PM
To: i2nsf@ietf.org; Linda Dunbar
Subject: [I2nsf] D= efinition for "Network Security Functions"
 
Hi All
 
I agree with Diego definition: 
"functions to ensure integrity, confidentiality and a= vailability of network communications, to detect unwanted activity, and to = deter it or at least mitigate its effects on the network"
 
From my point of view that covers all cases of network sec= urity function.
 
Regarding Flow-based network security function:=
 
=E2=80=9C A function that inspects network flows according= to a policy intended for enforcing security properties.  Flow-based s= ecurity also means that packets are inspected in the order they are receive= d, and without modification to the packet due to the inspection process (MAC rewrites, TTL decrement action; even NAT would= be outside the inspection process).
 
I'm not sure if it's valuable  to inspect packet with= out modification. There are cases when it's more preferable to inspect and = apply policy after NAT.  This is common practice and it must be a good= reason to change it. 
 
Br, Alexey Gorbunov
Telco Cloud and Security Architect at Nokia
CCIE R&S 41088
 
 
 
 
 
___________________= ____________________________ I2nsf mailing list I2nsf@ietf.orghttps://www.ietf.org/mailman/listinfo/i2n= sf
_______________________________________________
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/l= istinfo/i2nsf

--
"Esta vez no fallaremos, Doctor Infierno"

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

e-mail: diego.r.lopez@telefonica.com
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------



Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=C3=B3n privilegiada o confidencial y es para uso exc= lusivo de la persona o entidad de destino. Si no es usted. el destinatario = indicado, queda notificado de que la lectura, utilizaci=C3=B3n, divulgaci=C3=B3n y/o copia sin autorizaci=C3=B3= n puede estar prohibida en virtud de la legislaci=C3=B3n vigente. Si ha rec= ibido este mensaje por error, le rogamos que nos lo comunique inmediatament= e por esta misma v=C3=ADa y proceda a su destrucci=C3=B3n.

The information contained in this transmission is privileged and confidenti= al 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 y= ou have received this transmission in error, do not read it. Please immedia= tely 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=C3=A1= rio, pode conter informa=C3=A7=C3=A3o privilegiada ou confidencial e =C3=A9= para uso exclusivo da pessoa ou entidade de destino. Se n=C3=A3o =C3=A9 vo= ssa senhoria o destinat=C3=A1rio indicado, fica notificado de que a leitura, utiliza=C3=A7=C3=A3o, divulga=C3=A7=C3=A3o e/ou c=C3=B3pia sem au= toriza=C3=A7=C3=A3o pode estar proibida em virtude da legisla=C3=A7=C3=A3o = vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique= imediatamente por esta mesma via e proceda a sua destrui=C3=A7=C3=A3o
 --_000_241A3C3BE2614E279BBDB4925179C1F9telefonicacom_-- From nobody Tue May 26 01:24:24 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3F971A0373 for ; Tue, 26 May 2015 01:24:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A5RqffKnXSAa for ; Tue, 26 May 2015 01:24:21 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D028E1A039B for ; Tue, 26 May 2015 01:24:20 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlQFAHAtZFXGmAcV/2dsb2JhbABcgkUhKlReBoMZrXEBBplWAhyBJ0wBAQEBAQGBC4QiAQEBAQMSEQpcAgEIDQQEAQELHQMCAgIwFAkIAgQBEggaiAoBpFKKVaNVAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4YWhSSEVDcBgmgvgRYFkwiHBIwZjyEjgWaCEm+BRoEBAQEB X-IronPort-AV: E=Sophos;i="5.13,497,1427774400"; d="scan'208,217";a="122098226" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 26 May 2015 04:24:02 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 26 May 2015 04:24:01 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0174.001; Tue, 26 May 2015 10:24:00 +0200 From: "Romascanu, Dan (Dan)" To: Alexey Gorbunov , "i2nsf@ietf.org" , Linda Dunbar Thread-Topic: [I2nsf] Definition for "Network Security Functions" Thread-Index: AQHQlzwZJrE15RkWHEGPNCCtY969I52N6wYg Date: Tue, 26 May 2015 08:23:59 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5CA3ACBF@AZ-FFEXMB04.global.avaya.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.47] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA5CA3ACBFAZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: Subject: Re: [I2nsf] Definition for "Network Security Functions" X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 08:24:22 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5CA3ACBFAZFFEXMB04globa_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgbGlrZSB0aGUgZGVmaW5pdGlvbiBiZWNhdXNlIGl04oCZcyBjb25jaXNlIGFuZCBz ZWVtcyB0byBjb3ZlciBhIGxvdC4gSSBhbSBub3Qgc3VyZSBob3dldmVyIHdoYXQg4oCYZGV0ZXLi gJkgbWVhbnMgaW4gdGhpcyBjb250ZXh0LiBJbiBzb21lIGNhc2UgTlNGcyBkdWxseSBibG9jayBl ZmZlY3RzIG9mIHVud2FudGVkIGFjdGl2aXR5Lg0KDQpQZW5kaW5nIG9uIGNsYXJpZnlpbmcgd2hh dCDigJhkZXRlcuKAmSBtZWFucyBJIHN1Z2dlc3Q6DQoNCiJmdW5jdGlvbnMgdG8gZW5zdXJlIGlu dGVncml0eSwgY29uZmlkZW50aWFsaXR5IGFuZCBhdmFpbGFiaWxpdHkgb2YgbmV0d29yayBjb21t dW5pY2F0aW9ucywgdG8gZGV0ZWN0IHVud2FudGVkIGFjdGl2aXR5LCBhbmQgdG8gYmxvY2sgaXRb LCBkZXRlciBpdF0gb3IgYXQgbGVhc3QgbWl0aWdhdGUgaXRzIGVmZmVjdHMgb24gdGhlIG5ldHdv cmsiDQoNClJlZ2FyZHMsDQoNCkRhbg0KDQoNCkZyb206IEkybnNmIFttYWlsdG86aTJuc2YtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFsZXhleSBHb3JidW5vdg0KU2VudDogVHVlc2Rh eSwgTWF5IDI2LCAyMDE1IDE6NDIgQU0NClRvOiBpMm5zZkBpZXRmLm9yZzsgTGluZGEgRHVuYmFy DQpTdWJqZWN0OiBbSTJuc2ZdIERlZmluaXRpb24gZm9yICJOZXR3b3JrIFNlY3VyaXR5IEZ1bmN0 aW9ucyINCg0KSGkgQWxsDQoNCkkgYWdyZWUgd2l0aCBEaWVnbyBkZWZpbml0aW9uOg0KImZ1bmN0 aW9ucyB0byBlbnN1cmUgaW50ZWdyaXR5LCBjb25maWRlbnRpYWxpdHkgYW5kIGF2YWlsYWJpbGl0 eSBvZiBuZXR3b3JrIGNvbW11bmljYXRpb25zLCB0byBkZXRlY3QgdW53YW50ZWQgYWN0aXZpdHks IGFuZCB0byBkZXRlciBpdCBvciBhdCBsZWFzdCBtaXRpZ2F0ZSBpdHMgZWZmZWN0cyBvbiB0aGUg bmV0d29yayINCg0KRnJvbSBteSBwb2ludCBvZiB2aWV3IHRoYXQgY292ZXJzIGFsbCBjYXNlcyBv ZiBuZXR3b3JrIHNlY3VyaXR5IGZ1bmN0aW9uLg0KDQpSZWdhcmRpbmcgRmxvdy1iYXNlZCBuZXR3 b3JrIHNlY3VyaXR5IGZ1bmN0aW9uOg0KDQrigJwgQSBmdW5jdGlvbiB0aGF0IGluc3BlY3RzIG5l dHdvcmsgZmxvd3MgYWNjb3JkaW5nIHRvIGEgcG9saWN5IGludGVuZGVkIGZvciBlbmZvcmNpbmcg c2VjdXJpdHkgcHJvcGVydGllcy4gIEZsb3ctYmFzZWQgc2VjdXJpdHkgYWxzbyBtZWFucyB0aGF0 IHBhY2tldHMgYXJlIGluc3BlY3RlZCBpbiB0aGUgb3JkZXIgdGhleSBhcmUgcmVjZWl2ZWQsIGFu ZCB3aXRob3V0IG1vZGlmaWNhdGlvbiB0byB0aGUgcGFja2V0IGR1ZSB0byB0aGUgaW5zcGVjdGlv biBwcm9jZXNzIChNQUMgcmV3cml0ZXMsIFRUTCBkZWNyZW1lbnQgYWN0aW9uOyBldmVuIE5BVCB3 b3VsZCBiZSBvdXRzaWRlIHRoZSBpbnNwZWN0aW9uIHByb2Nlc3MpLg0KDQpJJ20gbm90IHN1cmUg aWYgaXQncyB2YWx1YWJsZSAgdG8gaW5zcGVjdCBwYWNrZXQgd2l0aG91dCBtb2RpZmljYXRpb24u IFRoZXJlIGFyZSBjYXNlcyB3aGVuIGl0J3MgbW9yZSBwcmVmZXJhYmxlIHRvIGluc3BlY3QgYW5k IGFwcGx5IHBvbGljeSBhZnRlciBOQVQuICBUaGlzIGlzIGNvbW1vbiBwcmFjdGljZSBhbmQgaXQg bXVzdCBiZSBhIGdvb2QgcmVhc29uIHRvIGNoYW5nZSBpdC4NCg0KQnIsIEFsZXhleSBHb3JidW5v dg0KVGVsY28gQ2xvdWQgYW5kIFNlY3VyaXR5IEFyY2hpdGVjdCBhdCBOb2tpYQ0KQ0NJRSBSJlMg NDEwODgNCg0KDQoNCg0KDQo= --_000_9904FB1B0159DA42B0B887B7FA8119CA5CA3ACBFAZFFEXMB04globa_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4w cHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+SSBsaWtlIHRoZSBkZWZpbml0aW9uIGJlY2F1c2UgaXTigJlzIGNvbmNpc2UgYW5kIHNl ZW1zIHRvIGNvdmVyIGEgbG90LiBJIGFtIG5vdCBzdXJlIGhvd2V2ZXIgd2hhdCDigJhkZXRlcuKA mSBtZWFucyBpbiB0aGlzIGNvbnRleHQuIEluIHNvbWUgY2FzZSBOU0ZzIGR1bGx5IGJsb2NrDQog ZWZmZWN0cyBvZiB1bndhbnRlZCBhY3Rpdml0eS4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5QZW5kaW5nIG9uIGNsYXJp Znlpbmcgd2hhdCDigJhkZXRlcuKAmSBtZWFucyBJIHN1Z2dlc3Q6DQo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+JnF1b3Q7ZnVuY3Rpb25zIHRvIGVuc3VyZSBpbnRlZ3JpdHksIGNvbmZpZGVudGlh bGl0eSBhbmQgYXZhaWxhYmlsaXR5IG9mIG5ldHdvcmsgY29tbXVuaWNhdGlvbnMsIHRvIGRldGVj dCB1bndhbnRlZCBhY3Rpdml0eSwgYW5kIHRvIGJsb2NrIGl0WywgZGV0ZXIgaXRdIG9yIGF0IGxl YXN0IG1pdGlnYXRlIGl0cyBlZmZlY3RzIG9uIHRoZSBuZXR3b3JrJnF1b3Q7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMs PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5EYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGlu ZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206 PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEkybnNmIFttYWlsdG86aTJu c2YtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+QWxleGV5IEdvcmJ1bm92 PGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIE1heSAyNiwgMjAxNSAxOjQyIEFNPGJyPg0KPGI+ VG86PC9iPiBpMm5zZkBpZXRmLm9yZzsgTGluZGEgRHVuYmFyPGJyPg0KPGI+U3ViamVjdDo8L2I+ IFtJMm5zZl0gRGVmaW5pdGlvbiBmb3IgJnF1b3Q7TmV0d29yayBTZWN1cml0eSBGdW5jdGlvbnMm cXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SGkgQWxsPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J IGFncmVlIHdpdGggRGllZ28gZGVmaW5pdGlvbjombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZxdW90O2Z1bmN0aW9ucyB0byBlbnN1cmUg aW50ZWdyaXR5LCBjb25maWRlbnRpYWxpdHkgYW5kIGF2YWlsYWJpbGl0eSBvZiBuZXR3b3JrIGNv bW11bmljYXRpb25zLCB0byBkZXRlY3QgdW53YW50ZWQgYWN0aXZpdHksIGFuZCB0byBkZXRlciBp dCBvciBhdCBsZWFzdCBtaXRpZ2F0ZSBpdHMgZWZmZWN0cyBvbiB0aGUgbmV0d29yayZxdW90Ozxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Gcm9t IG15IHBvaW50IG9mIHZpZXcgdGhhdCBjb3ZlcnMgYWxsIGNhc2VzIG9mIG5ldHdvcmsgc2VjdXJp dHkgZnVuY3Rpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+UmVnYXJkaW5nIEZsb3ctYmFzZWQgbmV0d29yayBzZWN1cml0eSBmdW5jdGlvbjo8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPuKAnCBBIGZ1bmN0aW9uIHRo YXQgaW5zcGVjdHMgbmV0d29yayBmbG93cyBhY2NvcmRpbmcgdG8gYSBwb2xpY3kgaW50ZW5kZWQg Zm9yIGVuZm9yY2luZyBzZWN1cml0eSBwcm9wZXJ0aWVzLiZuYnNwOyBGbG93LWJhc2VkIHNlY3Vy aXR5IGFsc28gbWVhbnMgdGhhdCBwYWNrZXRzIGFyZSBpbnNwZWN0ZWQgaW4gdGhlIG9yZGVyIHRo ZXkgYXJlIHJlY2VpdmVkLCBhbmQgd2l0aG91dCBtb2RpZmljYXRpb24gdG8gdGhlIHBhY2tldA0K IGR1ZSB0byB0aGUgaW5zcGVjdGlvbiBwcm9jZXNzIChNQUMgcmV3cml0ZXMsIFRUTCBkZWNyZW1l bnQgYWN0aW9uOyBldmVuIE5BVCB3b3VsZCBiZSBvdXRzaWRlIHRoZSBpbnNwZWN0aW9uIHByb2Nl c3MpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5JJ20gbm90IHN1cmUgaWYgaXQncyB2YWx1YWJsZSAmbmJzcDt0byBpbnNwZWN0IHBhY2tldCB3 aXRob3V0IG1vZGlmaWNhdGlvbi4gVGhlcmUgYXJlIGNhc2VzIHdoZW4gaXQncyBtb3JlIHByZWZl cmFibGUgdG8gaW5zcGVjdCBhbmQgYXBwbHkgcG9saWN5IGFmdGVyIE5BVC4mbmJzcDsgVGhpcyBp cyBjb21tb24gcHJhY3RpY2UgYW5kIGl0IG11c3QgYmUgYSBnb29kIHJlYXNvbiB0byBjaGFuZ2Ug aXQuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkJyLCBBbGV4ZXkgR29yYnVub3Y8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRlbGNvIENsb3VkIGFuZCBTZWN1cml0eSBBcmNoaXRlY3Qg YXQgTm9raWE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkNDSUUgUiZhbXA7UyA0MTA4ODxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_9904FB1B0159DA42B0B887B7FA8119CA5CA3ACBFAZFFEXMB04globa_-- From nobody Tue May 26 01:35:17 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDE811A1A48 for ; Tue, 26 May 2015 01:35:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h8cjYHGoKOZP for ; Tue, 26 May 2015 01:35:11 -0700 (PDT) Received: from smtptc.telefonica.com (smtptc.telefonica.com [195.76.34.108]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14C081A1A46 for ; Tue, 26 May 2015 01:35:10 -0700 (PDT) Received: from smtptc.telefonica.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 4AB213A0416; Tue, 26 May 2015 10:35:08 +0200 (CEST) Received-SPF: PermError (tgtim3c03.telefonica.com: domain of diego.r.lopez@telefonica.com uses mechanism not recognized by this client) identity=MAILFROM; client-ip=10.92.4.9; envelope-from=diego.r.lopez@telefonica.com; helo=ESTGVMSP104.EUROPE.telefonica.corp) Received: from ESTGVMSP104.EUROPE.telefonica.corp (unknown [10.92.4.9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtptc.telefonica.com (Postfix) with ESMTPS id 2EB783A03AA; Tue, 26 May 2015 10:35:08 +0200 (CEST) Received: from emea01-db3-obe.outbound.protection.outlook.com (10.92.5.139) by tls.telefonica.com (10.93.6.50) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 26 May 2015 10:35:07 +0200 Received: from DB4PR06MB0624.eurprd06.prod.outlook.com (25.161.13.142) by DB4PR06MB0623.eurprd06.prod.outlook.com (25.161.13.141) with Microsoft SMTP Server (TLS) id 15.1.172.22; Tue, 26 May 2015 08:35:06 +0000 Received: from DB4PR06MB0624.eurprd06.prod.outlook.com ([25.161.13.142]) by DB4PR06MB0624.eurprd06.prod.outlook.com ([25.161.13.142]) with mapi id 15.01.0172.012; Tue, 26 May 2015 08:35:06 +0000 From: DIEGO LOPEZ GARCIA To: "Romascanu, Dan (Dan)" Thread-Topic: [I2nsf] Definition for "Network Security Functions" Thread-Index: AQHQl41m97GpDfc8AEqJ3bOOiLAV/Z2N7qEA Date: Tue, 26 May 2015 08:35:05 +0000 Message-ID: <41298B1B-CFA5-44AD-B032-3493082BD80F@telefonica.com> References: <9904FB1B0159DA42B0B887B7FA8119CA5CA3ACBF@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5CA3ACBF@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=diego.r.lopez@telefonica.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [83.49.236.188] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB4PR06MB0623; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(520002)(3002001); SRVR:DB4PR06MB0623; BCL:0; PCL:0; RULEID:; SRVR:DB4PR06MB0623; x-forefront-prvs: 0588B2BD96 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(199003)(377454003)(53754006)(252514010)(189002)(24454002)(64706001)(16236675004)(2656002)(87936001)(66066001)(46102003)(19580405001)(82746002)(19580395003)(86362001)(5001860100001)(62966003)(77156002)(110136002)(101416001)(92566002)(5001960100002)(2900100001)(106356001)(2420400003)(102836002)(15975445007)(68736005)(106116001)(50986999)(76176999)(54356999)(2950100001)(122556002)(81156007)(33656002)(189998001)(97736004)(7110500001)(5001830100001)(4001540100001)(83716003)(36756003)(40100003)(105586002)(19617315012)(7059030)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR06MB0623; H:DB4PR06MB0624.eurprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: telefonica.com does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_41298B1BCFA544ADB0323493082BD80Ftelefonicacom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 May 2015 08:35:05.0630 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR06MB0623 X-OriginatorOrg: telefonica.com X-TM-AS-MML: No Archived-At: Cc: "i2nsf@ietf.org" , Alexey Gorbunov , Linda Dunbar Subject: Re: [I2nsf] Definition for "Network Security Functions" X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 08:35:16 -0000 --_000_41298B1BCFA544ADB0323493082BD80Ftelefonicacom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Dan, In the New Oxford American Dictionary, the second meaning of "deter" is "pr= eventing the occurrence of", so I think we could keep it. And remembering B= ob's comments on pronouns, the definition should look like: "functions to ensure integrity, confidentiality and availability of network= communications, to detect unwanted activity, and to deter this unwanted ac= tivity or at least mitigate its effects on the network" On 26 May 2015, at 10:23 , Romascanu, Dan (Dan) > wrote: Hi, I like the definition because it=92s concise and seems to cover a lot. I am= not sure however what =91deter=92 means in this context. In some case NSFs= dully block effects of unwanted activity. Pending on clarifying what =91deter=92 means I suggest: "functions to ensure integrity, confidentiality and availability of network= communications, to detect unwanted activity, and to block it[, deter it] o= r at least mitigate its effects on the network" Regards, Dan From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Alexey Gorbunov Sent: Tuesday, May 26, 2015 1:42 AM To: i2nsf@ietf.org; Linda Dunbar Subject: [I2nsf] Definition for "Network Security Functions" Hi All I agree with Diego definition: "functions to ensure integrity, confidentiality and availability of network= communications, to detect unwanted activity, and to deter it or at least m= itigate its effects on the network" >From my point of view that covers all cases of network security function. Regarding Flow-based network security function: =93 A function that inspects network flows according to a policy intended f= or enforcing security properties. Flow-based security also means that pack= ets are inspected in the order they are received, and without modification = to the packet due to the inspection process (MAC rewrites, TTL decrement ac= tion; even NAT would be outside the inspection process). I'm not sure if it's valuable to inspect packet without modification. Ther= e are cases when it's more preferable to inspect and apply policy after NAT= . This is common practice and it must be a good reason to change it. Br, Alexey Gorbunov Telco Cloud and Security Architect at Nokia CCIE R&S 41088 _______________________________________________ I2nsf mailing list I2nsf@ietf.org 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: diego.r.lopez@telefonica.com Tel: +34 913 129 041 Mobile: +34 682 051 091 ---------------------------------- ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o= copia sin autorizaci=F3n puede estar prohibida en virtud de la legislaci= =F3n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo = comunique inmediatamente por esta misma v=EDa y proceda a su destrucci=F3n. The information contained in this transmission is privileged and confidenti= al 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 co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, div= ulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o pode estar proibida em virtude= da legisla=E7=E3o vigente. Se recebeu esta mensagem por erro, rogamos-lhe = que nos o comunique imediatamente por esta mesma via e proceda a sua destru= i=E7=E3o --_000_41298B1BCFA544ADB0323493082BD80Ftelefonicacom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Hi Dan,

In the New Oxford American Dictionary, the second meaning of "det= er" is "preventing the occurrence of", so I think we could k= eep it. And remembering Bob's comments on pronouns, the definition should l= ook like:

"functions to ensure integrity, confidentiality and availability = of network communications, to detect unwanted activity, and to deter this u= nwanted activity or at least mitigate its effects on the network"

On 26 May 2015, at 10:23 , Romascanu, Dan (Dan) <dromasca@avaya.com> wrote:

Hi,
 
I like the definition because it=92s concise and seems to = cover a lot. I am not sure however what =91deter=92 means in this context. = In some case NSFs dully block effects of unwanted activity.
 
Pending on clarifying what =91deter=92 means I suggest:
 
"functions to ensure integrity, confidentiality and availability of ne= twork communications, to detect unwanted activity, and to block it[, deter = it] or at least mitigate its effects on the network"
 
Regards,
 
Dan
 
 
From:<= /span> I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Alexey Gor= bunov
Sent: Tuesday, May= 26, 2015 1:42 AM
To: i2= nsf@ietf.org; Linda Dunbar
Subject: [I2nsf] D= efinition for "Network Security Functions"
 
Hi All
 
I agree with Diego definition: 
"functions to ensure integrity, confidentiality and availability of ne= twork communications, to detect unwanted activity, and to deter it or at le= ast mitigate its effects on the network"
 
>From my point of view that covers all cases of network security function.
 
Regarding Flow-based network security function:
 
=93 A function that inspects network flows according to a policy intended f= or enforcing security properties.  Flow-based security also means that= packets are inspected in the order they are received, and without modifica= tion to the packet due to the inspection process (MAC rewrites, TTL decrement action; even NAT would be outside the= inspection process).
 
I'm not sure if it's valuable  to inspect packet without modification.= There are cases when it's more preferable to inspect and apply policy afte= r NAT.  This is common practice and it must be a good reason to change= it. 
 
Br, Alexey Gorbunov
Telco Cloud and Security Architect at Nokia
CCIE R&S 41088
 
 
 
 
 
_______________________________________________
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2n= sf

--
"Esta vez no fallaremos, Doctor Infierno"

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

e-mail: diego.r.lopez@telefonica.com
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------



Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o copia sin autorizaci=F3n puede e= star prohibida en virtud de la legislaci=F3n vigente. Si ha recibido este m= ensaje por error, le rogamos que nos lo comunique inmediatamente por esta m= isma v=EDa y proceda a su destrucci=F3n.

The information contained in this transmission is privileged and confidenti= al 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 y= ou have received this transmission in error, do not read it. Please immedia= tely 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=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, divulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o p= ode estar proibida em virtude da legisla=E7=E3o vigente. Se recebeu esta me= nsagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mes= ma via e proceda a sua destrui=E7=E3o
 --_000_41298B1BCFA544ADB0323493082BD80Ftelefonicacom_-- From nobody Tue May 26 01:37:35 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59A291A1A5A for ; Tue, 26 May 2015 01:37:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.92 X-Spam-Level: X-Spam-Status: No, score=-4.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id szgl5fMSFscf for ; Tue, 26 May 2015 01:37:28 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC2EE1A1A52 for ; Tue, 26 May 2015 01:37:28 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj8FAIwvZFXGmAcV/2dsb2JhbABcgkUhKlReBoUiq2gBBpM7GgEGhXoCgURMAQEBAQEBgQuEIgEBAQEDAQEBDxtBCxACAQgNBAQBAQsdBycCCRQJCAIEDgUIGogKAQykT64rAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4YWhSSELSctBAYBBgODDoEWBYZrhR+GfoQ1gk+CS4JpPoMzgnQLjxYjgV0JJByBUm8BAQGBAUKBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,497,1427774400"; d="scan'208,217";a="117911608" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by co300216-co-outbound.net.avaya.com with ESMTP; 26 May 2015 04:37:08 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 26 May 2015 04:37:08 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.03.0174.001; Tue, 26 May 2015 04:37:06 -0400 From: "Romascanu, Dan (Dan)" To: DIEGO LOPEZ GARCIA Thread-Topic: [I2nsf] Definition for "Network Security Functions" Thread-Index: AQHQl47iGvbmqNc7/k+Qry0SvdTSF52N7tIw Date: Tue, 26 May 2015 08:37:05 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5CA3ACF6@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA5CA3ACBF@AZ-FFEXMB04.global.avaya.com> <41298B1B-CFA5-44AD-B032-3493082BD80F@telefonica.com> In-Reply-To: <41298B1B-CFA5-44AD-B032-3493082BD80F@telefonica.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.48] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA5CA3ACF6AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: Cc: "i2nsf@ietf.org" , Alexey Gorbunov , Linda Dunbar Subject: Re: [I2nsf] Definition for "Network Security Functions" X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 08:37:33 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5CA3ACF6AZFFEXMB04globa_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I believe that we need to add block. Preventing is good, but when 'unwanted= activity' happens you need to limit it's spreading by dully blocking. Regards, Dan From: DIEGO LOPEZ GARCIA [mailto:diego.r.lopez@telefonica.com] Sent: Tuesday, May 26, 2015 11:35 AM To: Romascanu, Dan (Dan) Cc: Alexey Gorbunov; i2nsf@ietf.org; Linda Dunbar Subject: Re: [I2nsf] Definition for "Network Security Functions" Hi Dan, In the New Oxford American Dictionary, the second meaning of "deter" is "pr= eventing the occurrence of", so I think we could keep it. And remembering B= ob's comments on pronouns, the definition should look like: "functions to ensure integrity, confidentiality and availability of network= communications, to detect unwanted activity, and to deter this unwanted ac= tivity or at least mitigate its effects on the network" On 26 May 2015, at 10:23 , Romascanu, Dan (Dan) > wrote: Hi, I like the definition because it's concise and seems to cover a lot. I am n= ot sure however what 'deter' means in this context. In some case NSFs dully= block effects of unwanted activity. Pending on clarifying what 'deter' means I suggest: "functions to ensure integrity, confidentiality and availability of network= communications, to detect unwanted activity, and to block it[, deter it] o= r at least mitigate its effects on the network" Regards, Dan From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Alexey Gorbunov Sent: Tuesday, May 26, 2015 1:42 AM To: i2nsf@ietf.org; Linda Dunbar Subject: [I2nsf] Definition for "Network Security Functions" Hi All I agree with Diego definition: "functions to ensure integrity, confidentiality and availability of network= communications, to detect unwanted activity, and to deter it or at least m= itigate its effects on the network" >From my point of view that covers all cases of network security function. Regarding Flow-based network security function: " A function that inspects network flows according to a policy intended for= enforcing security properties. Flow-based security also means that packet= s are inspected in the order they are received, and without modification to= the packet due to the inspection process (MAC rewrites, TTL decrement acti= on; even NAT would be outside the inspection process). I'm not sure if it's valuable to inspect packet without modification. Ther= e are cases when it's more preferable to inspect and apply policy after NAT= . This is common practice and it must be a good reason to change it. Br, Alexey Gorbunov Telco Cloud and Security Architect at Nokia CCIE R&S 41088 _______________________________________________ I2nsf mailing list I2nsf@ietf.org 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: diego.r.lopez@telefonica.com Tel: +34 913 129 041 Mobile: +34 682 051 091 ---------------------------------- ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o= copia sin autorizaci=F3n puede estar prohibida en virtud de la legislaci= =F3n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo = comunique inmediatamente por esta misma v=EDa y proceda a su destrucci=F3n. The information contained in this transmission is privileged and confidenti= al 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 co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, div= ulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o pode estar proibida em virtude= da legisla=E7=E3o vigente. Se recebeu esta mensagem por erro, rogamos-lhe = que nos o comunique imediatamente por esta mesma via e proceda a sua destru= i=E7=E3o --_000_9904FB1B0159DA42B0B887B7FA8119CA5CA3ACF6AZFFEXMB04globa_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I believe that we need to= add block. Preventing is good, but when ‘unwanted activity’ ha= ppens you need to limit it’s spreading by dully blocking.

 <= /p>

Regards,

 <= /p>

Dan

 <= /p>

 <= /p>

From: DIEGO LO= PEZ GARCIA [mailto:diego.r.lopez@telefonica.com]
Sent: Tuesday, May 26, 2015 11:35 AM
To: Romascanu, Dan (Dan)
Cc: Alexey Gorbunov; i2nsf@ietf.org; Linda Dunbar
Subject: Re: [I2nsf] Definition for "Network Security Functions= "

 

Hi Dan,

 

In the New Oxford American Dictionary, the second me= aning of "deter" is "preventing the occurrence of", so = I think we could keep it. And remembering Bob's comments on pronouns, the d= efinition should look like:

 

"functions to ensure integrity, confidentiality= and availability of network communications, to detect unwanted activity, a= nd to deter this unwanted activity or at least mitigate its effects on the = network"

 

On 26 May 2015, at 10:23 , Romascanu, Dan (Dan) <= dromasca@avaya.com> wrote:



Hi,

 <= /p>

I like the definition bec= ause it’s concise and seems to cover a lot. I am not sure however wha= t ‘deter’ means in this context. In some case NSFs dully block effects of unwanted activity.

 <= /p>

Pending on clarifying wha= t ‘deter’ means I suggest:

 <= /p>

"functions to ensure integrity, confidentiality= and availability of network communications, to detect unwanted activity, a= nd to block it[, deter it] or at least mitigate its effects on the network&= quot;

 <= /p>

Regards,

 <= /p>

Dan

 <= /p>

 <= /p>

From: I2nsf [ma= ilto:i2nsf-bounces@ietf.org] On Behalf Of <= /span>Alexey Gorbunov
Sent: Tuesday, May= 26, 2015 1:42 AM
To: i2nsf@ietf.org;= Linda Dunbar
Subject: [I2nsf] D= efinition for "Network Security Functions"

 

Hi All

 

I agree with Diego definition: 

"functions to ensure integrity, confidentiality= and availability of network communications, to detect unwanted activity, a= nd to deter it or at least mitigate its effects on the network"

 

From my point of view that covers all cases of netwo= rk security function.

 

Regarding Flow-based network security function:=

 

“ A function that inspects network flows accor= ding to a policy intended for enforcing security properties.  Flow-bas= ed security also means that packets are inspected in the order they are rec= eived, and without modification to the packet due to the inspection process (MAC rewrites, TTL decrement action; even NA= T would be outside the inspection process).

 

I'm not sure if it's valuable  to inspect packe= t without modification. There are cases when it's more preferable to inspec= t and apply policy after NAT.  This is common practice and it must be = a good reason to change it. 

 

Br, Alexey Gorbunov

Telco Cloud and Security Architect at Nokia

CCIE R&S 41088

 

 

 <= /p>

 

 

________________________________________= _______
I2nsf mailing list
I2nsf@ietf.o= rg
https://www.ietf.org/mailman/lis= tinfo/i2nsf

 

--
"Esta vez no fallaremos, Doctor Infierno"

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

e-mail: diego.r.lopez@telef= onica.com
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------

 

 


Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o copia sin autorizaci=F3n puede e= star prohibida en virtud de la legislaci=F3n vigente. Si ha recibido este m= ensaje por error, le rogamos que nos lo comunique inmediatamente por esta m= isma v=EDa y proceda a su destrucci=F3n.

The information contained in this transmission is privileged and confidenti= al 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 y= ou have received this transmission in error, do not read it. Please immedia= tely 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=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, divulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o p= ode estar proibida em virtude da legisla=E7=E3o vigente. Se recebeu esta me= nsagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mes= ma via e proceda a sua destrui=E7=E3o

--_000_9904FB1B0159DA42B0B887B7FA8119CA5CA3ACF6AZFFEXMB04globa_-- From nobody Tue May 26 01:55:51 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90B721A1B95 for ; Tue, 26 May 2015 01:55:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.611 X-Spam-Level: X-Spam-Status: No, score=-0.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ekd8TBM_nHXO for ; Tue, 26 May 2015 01:55:45 -0700 (PDT) Received: from smtpjc.telefonica.com (smtpjc.telefonica.com [81.47.204.76]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8FB31A1B5C for ; Tue, 26 May 2015 01:55:44 -0700 (PDT) Received: from smtpjc.telefonica.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C98662F0258; Tue, 26 May 2015 10:55:41 +0200 (CEST) Received-SPF: PermError (tgtimjc803.telefonica.com: domain of diego.r.lopez@telefonica.com uses mechanism not recognized by this client) identity=MAILFROM; client-ip=10.92.4.9; envelope-from=diego.r.lopez@telefonica.com; helo=ESTGVMSP114.EUROPE.telefonica.corp) Received: from ESTGVMSP114.EUROPE.telefonica.corp (unknown [10.92.4.9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtpjc.telefonica.com (Postfix) with ESMTPS id ABFB72F0161; Tue, 26 May 2015 10:55:41 +0200 (CEST) Received: from emea01-db3-obe.outbound.protection.outlook.com (10.92.5.139) by tls.telefonica.com (10.93.6.55) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 26 May 2015 10:55:41 +0200 Received: from DB4PR06MB0624.eurprd06.prod.outlook.com (25.161.13.142) by DB4PR06MB0621.eurprd06.prod.outlook.com (25.161.13.139) with Microsoft SMTP Server (TLS) id 15.1.172.22; Tue, 26 May 2015 08:55:39 +0000 Received: from DB4PR06MB0624.eurprd06.prod.outlook.com ([25.161.13.142]) by DB4PR06MB0624.eurprd06.prod.outlook.com ([25.161.13.142]) with mapi id 15.01.0172.012; Tue, 26 May 2015 08:55:39 +0000 From: DIEGO LOPEZ GARCIA To: "Romascanu, Dan (Dan)" Thread-Topic: [I2nsf] Definition for "Network Security Functions" Thread-Index: AQHQl41m97GpDfc8AEqJ3bOOiLAV/Z2N7qEAgAAAjoCAAAUwgA== Date: Tue, 26 May 2015 08:55:38 +0000 Message-ID: <2F8716D8-6028-4464-AAE2-6AC1EA279AF7@telefonica.com> References: <9904FB1B0159DA42B0B887B7FA8119CA5CA3ACBF@AZ-FFEXMB04.global.avaya.com> <41298B1B-CFA5-44AD-B032-3493082BD80F@telefonica.com> <9904FB1B0159DA42B0B887B7FA8119CA5CA3ACF6@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5CA3ACF6@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=diego.r.lopez@telefonica.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [83.49.236.188] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB4PR06MB0621; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(520002)(3002001); SRVR:DB4PR06MB0621; BCL:0; PCL:0; RULEID:; SRVR:DB4PR06MB0621; x-forefront-prvs: 0588B2BD96 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(199003)(40134004)(377454003)(53754006)(252514010)(25724002)(189002)(62966003)(77156002)(4001540100001)(81156007)(97736004)(46102003)(86362001)(93886004)(36756003)(2950100001)(92566002)(7110500001)(2656002)(16236675004)(105586002)(2420400003)(102836002)(15975445007)(68736005)(2900100001)(87936001)(122556002)(5001830100001)(189998001)(5001960100002)(5001860100001)(64706001)(110136002)(40100003)(66066001)(106116001)(101416001)(33656002)(83716003)(50986999)(76176999)(54356999)(106356001)(19617315012)(19580395003)(19580405001)(82746002)(7059030)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR06MB0621; H:DB4PR06MB0624.eurprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: telefonica.com does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_2F8716D860284464AAE26AC1EA279AF7telefonicacom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 May 2015 08:55:38.1175 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR06MB0621 X-OriginatorOrg: telefonica.com X-TM-AS-MML: No Archived-At: Cc: "i2nsf@ietf.org" , Alexey Gorbunov , Linda Dunbar Subject: Re: [I2nsf] Definition for "Network Security Functions" X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 08:55:50 -0000 --_000_2F8716D860284464AAE26AC1EA279AF7telefonicacom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable So "to deter and block"? Nothing to object from may side... On 26 May 2015, at 10:37 , Romascanu, Dan (Dan) > wrote: I believe that we need to add block. Preventing is good, but when =91unwant= ed activity=92 happens you need to limit it=92s spreading by dully blocking= . Regards, Dan From: DIEGO LOPEZ GARCIA [mailto:diego.r.lopez@telefonica.com] Sent: Tuesday, May 26, 2015 11:35 AM To: Romascanu, Dan (Dan) Cc: Alexey Gorbunov; i2nsf@ietf.org; Linda Dunbar Subject: Re: [I2nsf] Definition for "Network Security Functions" Hi Dan, In the New Oxford American Dictionary, the second meaning of "deter" is "pr= eventing the occurrence of", so I think we could keep it. And remembering B= ob's comments on pronouns, the definition should look like: "functions to ensure integrity, confidentiality and availability of network= communications, to detect unwanted activity, and to deter this unwanted ac= tivity or at least mitigate its effects on the network" On 26 May 2015, at 10:23 , Romascanu, Dan (Dan) > wrote: Hi, I like the definition because it=92s concise and seems to cover a lot. I am= not sure however what =91deter=92 means in this context. In some case NSFs= dully block effects of unwanted activity. Pending on clarifying what =91deter=92 means I suggest: "functions to ensure integrity, confidentiality and availability of network= communications, to detect unwanted activity, and to block it[, deter it] o= r at least mitigate its effects on the network" Regards, Dan From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Alexey Gorbunov Sent: Tuesday, May 26, 2015 1:42 AM To: i2nsf@ietf.org; Linda Dunbar Subject: [I2nsf] Definition for "Network Security Functions" Hi All I agree with Diego definition: "functions to ensure integrity, confidentiality and availability of network= communications, to detect unwanted activity, and to deter it or at least m= itigate its effects on the network" >From my point of view that covers all cases of network security function. Regarding Flow-based network security function: =93 A function that inspects network flows according to a policy intended f= or enforcing security properties. Flow-based security also means that pack= ets are inspected in the order they are received, and without modification = to the packet due to the inspection process (MAC rewrites, TTL decrement ac= tion; even NAT would be outside the inspection process). I'm not sure if it's valuable to inspect packet without modification. Ther= e are cases when it's more preferable to inspect and apply policy after NAT= . This is common practice and it must be a good reason to change it. Br, Alexey Gorbunov Telco Cloud and Security Architect at Nokia CCIE R&S 41088 _______________________________________________ I2nsf mailing list I2nsf@ietf.org 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: diego.r.lopez@telefonica.com Tel: +34 913 129 041 Mobile: +34 682 051 091 ---------------------------------- ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o= copia sin autorizaci=F3n puede estar prohibida en virtud de la legislaci= =F3n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo = comunique inmediatamente por esta misma v=EDa y proceda a su destrucci=F3n. The information contained in this transmission is privileged and confidenti= al 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 co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, div= ulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o pode estar proibida em virtude= da legisla=E7=E3o vigente. Se recebeu esta mensagem por erro, rogamos-lhe = que nos o comunique imediatamente por esta mesma via e proceda a sua destru= i=E7=E3o -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego.r.lopez@telefonica.com Tel: +34 913 129 041 Mobile: +34 682 051 091 ---------------------------------- ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o= copia sin autorizaci=F3n puede estar prohibida en virtud de la legislaci= =F3n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo = comunique inmediatamente por esta misma v=EDa y proceda a su destrucci=F3n. The information contained in this transmission is privileged and confidenti= al 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 co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, div= ulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o pode estar proibida em virtude= da legisla=E7=E3o vigente. Se recebeu esta mensagem por erro, rogamos-lhe = que nos o comunique imediatamente por esta mesma via e proceda a sua destru= i=E7=E3o --_000_2F8716D860284464AAE26AC1EA279AF7telefonicacom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable So "to deter and block"? Nothing to object from may side...

On 26 May 2015, at 10:37 , Romascanu, Dan (Dan) <dromasca@avaya.com> wrote:

I believe that we need to add block. Preventing is good, b= ut when =91unwanted activity=92 happens you need to limit it=92s spreading = by dully blocking.
 
Regards,
 
Dan
 
 
From:<= /span> DIEGO LOPEZ GARCIA [mailto:diego.r.lopez@telefonica.com] 
Sent: Tuesday, May= 26, 2015 11:35 AM
To: Romascanu, Dan= (Dan)
Cc: Alexey Gorbuno= v; i2nsf@ietf= .org; Linda Dunbar
Subject: Re: [I2ns= f] Definition for "Network Security Functions"<= /div>
 
Hi Dan,
 
In the New Oxford American Dictionary, the second meaning of "deter&qu= ot; is "preventing the occurrence of", so I think we could keep i= t. And remembering Bob's comments on pronouns, the definition should look l= ike:
 
"functions to ensure integrity, confidentiality and availability of ne= twork communications, to detect unwanted activity, and to deter this unwant= ed activity or at least mitigate its effects on the network"
 
On 26 May 2015, at 10:23 , Romascanu, Dan (Dan) <dromasc= a@avaya.com> wrote:


Hi,
 
I like the definition because it=92s concise and seems to = cover a lot. I am not sure however what =91deter=92 means in this context. = In some case NSFs dully block effects of unwanted activity.
 
Pending on clarifying what =91deter=92 means I suggest:
 
"functions to ensure integrity, confidentiality and availability of ne= twork communications, to detect unwanted activity, and to block it[, deter = it] or at least mitigate its effects on the network"
 
Regards,
 
Dan
 
 
From:<= /span> I2nsf [mailto:i2nsf-bounces@i= etf.org] On= Behalf Of Alexey Gorbunov
Sent: Tuesday, May= 26, 2015 1:42 AM
To: i2nsf@ietf.org; Linda Dunbar
Subject: [I2nsf] D= efinition for "Network Security Functions"
 
Hi All
 
I agree with Diego definition: 
"functions to ensure integrity, confidentiality and availability of ne= twork communications, to detect unwanted activity, and to deter it or at le= ast mitigate its effects on the network"
 
>From my point of view that covers all cases of network security function.
 
Regarding Flow-based network security function:
 
=93 A function that inspects network flows according to a policy intended f= or enforcing security properties.  Flow-based security also means that= packets are inspected in the order they are received, and without modifica= tion to the packet due to the inspection process (MAC rewrites, TTL decrement action; even NAT would be outside the= inspection process).
 
I'm not sure if it's valuable  to inspect packet without modification.= There are cases when it's more preferable to inspect and apply policy afte= r NAT.  This is common practice and it must be a good reason to change= it. 
 
Br, Alexey Gorbunov
Telco Cloud and Security Architect at Nokia
CCIE R&S 41088
 
 
 
 
 
_______= ________________________________________
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf
 
 
 

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o copia sin autorizaci=F3n puede e= star prohibida en virtud de la legislaci=F3n vigente. Si ha recibido este m= ensaje por error, le rogamos que nos lo comunique inmediatamente por esta m= isma v=EDa y proceda a su destrucci=F3n.

The information contained in this transmission is privileged and confidenti= al 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 y= ou have received this transmission in error, do not read it. Please immedia= tely 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=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, divulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o p= ode estar proibida em virtude da legisla=E7=E3o vigente. Se recebeu esta me= nsagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mes= ma via e proceda a sua destrui=E7=E3o

--
"Esta vez no fallaremos, Doctor Infierno"

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

e-mail: diego.r.lopez@telefonica.com
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------



Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o copia sin autorizaci=F3n puede e= star prohibida en virtud de la legislaci=F3n vigente. Si ha recibido este m= ensaje por error, le rogamos que nos lo comunique inmediatamente por esta m= isma v=EDa y proceda a su destrucci=F3n.

The information contained in this transmission is privileged and confidenti= al 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 y= ou have received this transmission in error, do not read it. Please immedia= tely 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=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, divulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o p= ode estar proibida em virtude da legisla=E7=E3o vigente. Se recebeu esta me= nsagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mes= ma via e proceda a sua destrui=E7=E3o
 --_000_2F8716D860284464AAE26AC1EA279AF7telefonicacom_-- From nobody Tue May 26 02:02:39 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23AC11A1BFF for ; Tue, 26 May 2015 02:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.91 X-Spam-Level: X-Spam-Status: No, score=-4.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_HI=-5, T_FILL_THIS_FORM_SHORT=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y2RdOtv1gg_D for ; Tue, 26 May 2015 02:02:32 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94ED91A1BFE for ; Tue, 26 May 2015 02:02:32 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkAFAH41ZFWHCzIm/2dsb2JhbABcgkUhKlReBoUiq2gBBpMxCxkBBoV6AoFETAEBAQEBAYELhCIBAQEBAwEBAQ8bQQsQAgEIDQQEAQELFgEGBycCCRQJCAIEDgUIGogKAQykS64rAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4YWhSSELScfCAYEBgEGA4IkTR2BFgWGa4Ufhn6ENYJPgkuCaT6DM4J0C48WI4FdCSQcgVJvAQEBgQFCgQEBAQE X-IronPort-AV: E=Sophos;i="5.13,497,1427774400"; d="scan'208,217";a="117914089" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by co300216-co-outbound.net.avaya.com with ESMTP; 26 May 2015 05:02:30 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 26 May 2015 05:02:30 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.03.0174.001; Tue, 26 May 2015 11:02:28 +0200 From: "Romascanu, Dan (Dan)" To: DIEGO LOPEZ GARCIA Thread-Topic: [I2nsf] Definition for "Network Security Functions" Thread-Index: AQHQl47iGvbmqNc7/k+Qry0SvdTSF52N7tIwgABIlwD//764wA== Date: Tue, 26 May 2015 09:02:27 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5CA3AD97@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA5CA3ACBF@AZ-FFEXMB04.global.avaya.com> <41298B1B-CFA5-44AD-B032-3493082BD80F@telefonica.com> <9904FB1B0159DA42B0B887B7FA8119CA5CA3ACF6@AZ-FFEXMB04.global.avaya.com> <2F8716D8-6028-4464-AAE2-6AC1EA279AF7@telefonica.com> In-Reply-To: <2F8716D8-6028-4464-AAE2-6AC1EA279AF7@telefonica.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.48] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA5CA3AD97AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: Cc: "i2nsf@ietf.org" , Alexey Gorbunov , Linda Dunbar Subject: Re: [I2nsf] Definition for "Network Security Functions" X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 09:02:39 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5CA3AD97AZFFEXMB04globa_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable wfm Regards, Dan From: DIEGO LOPEZ GARCIA [mailto:diego.r.lopez@telefonica.com] Sent: Tuesday, May 26, 2015 11:56 AM To: Romascanu, Dan (Dan) Cc: Alexey Gorbunov; i2nsf@ietf.org; Linda Dunbar Subject: Re: [I2nsf] Definition for "Network Security Functions" So "to deter and block"? Nothing to object from may side... On 26 May 2015, at 10:37 , Romascanu, Dan (Dan) > wrote: I believe that we need to add block. Preventing is good, but when 'unwanted= activity' happens you need to limit it's spreading by dully blocking. Regards, Dan From: DIEGO LOPEZ GARCIA [mailto:diego.r.lopez@telefonica.com] Sent: Tuesday, May 26, 2015 11:35 AM To: Romascanu, Dan (Dan) Cc: Alexey Gorbunov; i2nsf@ietf.org; Linda Dunbar Subject: Re: [I2nsf] Definition for "Network Security Functions" Hi Dan, In the New Oxford American Dictionary, the second meaning of "deter" is "pr= eventing the occurrence of", so I think we could keep it. And remembering B= ob's comments on pronouns, the definition should look like: "functions to ensure integrity, confidentiality and availability of network= communications, to detect unwanted activity, and to deter this unwanted ac= tivity or at least mitigate its effects on the network" On 26 May 2015, at 10:23 , Romascanu, Dan (Dan) > wrote: Hi, I like the definition because it's concise and seems to cover a lot. I am n= ot sure however what 'deter' means in this context. In some case NSFs dully= block effects of unwanted activity. Pending on clarifying what 'deter' means I suggest: "functions to ensure integrity, confidentiality and availability of network= communications, to detect unwanted activity, and to block it[, deter it] o= r at least mitigate its effects on the network" Regards, Dan From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Alexey Gorbunov Sent: Tuesday, May 26, 2015 1:42 AM To: i2nsf@ietf.org; Linda Dunbar Subject: [I2nsf] Definition for "Network Security Functions" Hi All I agree with Diego definition: "functions to ensure integrity, confidentiality and availability of network= communications, to detect unwanted activity, and to deter it or at least m= itigate its effects on the network" >From my point of view that covers all cases of network security function. Regarding Flow-based network security function: " A function that inspects network flows according to a policy intended for= enforcing security properties. Flow-based security also means that packet= s are inspected in the order they are received, and without modification to= the packet due to the inspection process (MAC rewrites, TTL decrement acti= on; even NAT would be outside the inspection process). I'm not sure if it's valuable to inspect packet without modification. Ther= e are cases when it's more preferable to inspect and apply policy after NAT= . This is common practice and it must be a good reason to change it. Br, Alexey Gorbunov Telco Cloud and Security Architect at Nokia CCIE R&S 41088 _______________________________________________ I2nsf mailing list I2nsf@ietf.org 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: diego.r.lopez@telefonica.com Tel: +34 913 129 041 Mobile: +34 682 051 091 ---------------------------------- ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o= copia sin autorizaci=F3n puede estar prohibida en virtud de la legislaci= =F3n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo = comunique inmediatamente por esta misma v=EDa y proceda a su destrucci=F3n. The information contained in this transmission is privileged and confidenti= al 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 co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, div= ulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o pode estar proibida em virtude= da legisla=E7=E3o vigente. Se recebeu esta mensagem por erro, rogamos-lhe = que nos o comunique imediatamente por esta mesma via e proceda a sua destru= i=E7=E3o -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego.r.lopez@telefonica.com Tel: +34 913 129 041 Mobile: +34 682 051 091 ---------------------------------- ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o= copia sin autorizaci=F3n puede estar prohibida en virtud de la legislaci= =F3n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo = comunique inmediatamente por esta misma v=EDa y proceda a su destrucci=F3n. The information contained in this transmission is privileged and confidenti= al 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 co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, div= ulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o pode estar proibida em virtude= da legisla=E7=E3o vigente. Se recebeu esta mensagem por erro, rogamos-lhe = que nos o comunique imediatamente por esta mesma via e proceda a sua destru= i=E7=E3o --_000_9904FB1B0159DA42B0B887B7FA8119CA5CA3AD97AZFFEXMB04globa_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

wfm

 <= /p>

Regards,

 <= /p>

Dan

 <= /p>

 <= /p>

From: DIEGO LO= PEZ GARCIA [mailto:diego.r.lopez@telefonica.com]
Sent: Tuesday, May 26, 2015 11:56 AM
To: Romascanu, Dan (Dan)
Cc: Alexey Gorbunov; i2nsf@ietf.org; Linda Dunbar
Subject: Re: [I2nsf] Definition for "Network Security Functions= "

 

So "to deter and block"? Nothing to object= from may side...

 

On 26 May 2015, at 10:37 , Romascanu, Dan (Dan) <= dromasca@avaya.com> wrote:



I believe that we need to= add block. Preventing is good, but when ‘unwanted activity’ ha= ppens you need to limit it’s spreading by dully blocking.=

 <= /p>

Regards,

 <= /p>

Dan

 <= /p>

 <= /p>

From: DIEGO LOPEZ GARCIA [mailto:diego.r.lopez@telefonica.com] 
Sent: Tuesday, May= 26, 2015 11:35 AM
To: Romascanu, Dan= (Dan)
Cc: Alexey Gorbuno= v; i2nsf@ietf.org; Linda D= unbar
Subject: Re: [I2ns= f] Definition for "Network Security Functions"<= /p>

 

Hi Dan,

 

In the New Oxford American Dictionary, the second me= aning of "deter" is "preventing the occurrence of", so = I think we could keep it. And remembering Bob's comments on pronouns, the d= efinition should look like:

 

"functions to ensure integrity, confidentiality= and availability of network communications, to detect unwanted activity, a= nd to deter this unwanted activity or at least mitigate its effects on the = network"

 

On 26 May 2015, at 10:23 , Romascanu, Dan (Dan) <= dromasca= @avaya.com> wrote:




Hi,

 <= /p>

I like the definition bec= ause it’s concise and seems to cover a lot. I am not sure however wha= t ‘deter’ means in this context. In some case NSFs dully block effects of unwanted activity.

 <= /p>

Pending on clarifying wha= t ‘deter’ means I suggest:

 <= /p>

"functions to ensure integrity, confidentiality= and availability of network communications, to detect unwanted activity, a= nd to block it[, deter it] or at least mitigate its effects on the network&= quot;

 <= /p>

Regards,

 <= /p>

Dan

 <= /p>

 <= /p>

From: I2nsf [ma= ilto:i2nsf-bounces@ietf.org] On Behalf Of <= /span>Alexey Gorbunov
Sent: Tuesday, May= 26, 2015 1:42 AM
To: i2nsf@ietf.org;= Linda Dunbar
Subject: [I2nsf] D= efinition for "Network Security Functions"

 

Hi All

 

I agree with Diego definition: 

"functions to ensure integrity, confidentiality= and availability of network communications, to detect unwanted activity, a= nd to deter it or at least mitigate its effects on the network"

 

From my point of view that covers all cases of netwo= rk security function.

 

Regarding Flow-based network security function:=

 

“ A function that inspects network flows accor= ding to a policy intended for enforcing security properties.  Flow-bas= ed security also means that packets are inspected in the order they are rec= eived, and without modification to the packet due to the inspection process (MAC rewrites, TTL decrement action; even NA= T would be outside the inspection process).

 

I'm not sure if it's valuable  to inspect packe= t without modification. There are cases when it's more preferable to inspec= t and apply policy after NAT.  This is common practice and it must be = a good reason to change it. 

 

Br, Alexey Gorbunov

Telco Cloud and Security Architect at Nokia

CCIE R&S 41088

 

 

 <= /p>

 

 

________________________________________= _______
I2nsf mailing list
I2nsf@ietf.o= rg
https://www.ietf.org/mailman/lis= tinfo/i2nsf

 

--
"Esta vez no fallaremos, Doctor Infierno"

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

e-mail: diego.r.lopez@t= elefonica.com
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------

 

 


Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o copia sin autorizaci=F3n puede e= star prohibida en virtud de la legislaci=F3n vigente. Si ha recibido este m= ensaje por error, le rogamos que nos lo comunique inmediatamente por esta m= isma v=EDa y proceda a su destrucci=F3n.

The information contained in this transmission is privileged and confidenti= al 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 y= ou have received this transmission in error, do not read it. Please immedia= tely 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=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, divulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o p= ode estar proibida em virtude da legisla=E7=E3o vigente. Se recebeu esta me= nsagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mes= ma via e proceda a sua destrui=E7=E3o

 

--
"Esta vez no fallaremos, Doctor Infierno"

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

e-mail: diego.r.lopez@telef= onica.com
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------

 

 


Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o copia sin autorizaci=F3n puede e= star prohibida en virtud de la legislaci=F3n vigente. Si ha recibido este m= ensaje por error, le rogamos que nos lo comunique inmediatamente por esta m= isma v=EDa y proceda a su destrucci=F3n.

The information contained in this transmission is privileged and confidenti= al 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 y= ou have received this transmission in error, do not read it. Please immedia= tely 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=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, divulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o p= ode estar proibida em virtude da legisla=E7=E3o vigente. Se recebeu esta me= nsagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mes= ma via e proceda a sua destrui=E7=E3o

--_000_9904FB1B0159DA42B0B887B7FA8119CA5CA3AD97AZFFEXMB04globa_-- From nobody Tue May 26 02:13:56 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B8A71A6FFF for ; Tue, 26 May 2015 02:13:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.621 X-Spam-Level: X-Spam-Status: No, score=-0.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dlfBQWWxgEce for ; Tue, 26 May 2015 02:13:50 -0700 (PDT) Received: from smtptc.telefonica.com (smtptc.telefonica.com [195.76.34.108]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43B4F1A6FFE for ; Tue, 26 May 2015 02:13:48 -0700 (PDT) Received: from smtptc.telefonica.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 4396A3706C5; Tue, 26 May 2015 11:13:46 +0200 (CEST) Received-SPF: PermError (tgtim3c01.telefonica.com: domain of diego.r.lopez@telefonica.com uses mechanism not recognized by this client) identity=MAILFROM; client-ip=10.92.4.9; envelope-from=diego.r.lopez@telefonica.com; helo=ESTGVMSP103.EUROPE.telefonica.corp) Received: from ESTGVMSP103.EUROPE.telefonica.corp (unknown [10.92.4.9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtptc.telefonica.com (Postfix) with ESMTPS id 22D8F3706AE; Tue, 26 May 2015 11:13:46 +0200 (CEST) Received: from emea01-db3-obe.outbound.protection.outlook.com (10.92.5.139) by tls.telefonica.com (10.92.6.50) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 26 May 2015 11:13:45 +0200 Received: from DB4PR06MB0624.eurprd06.prod.outlook.com (25.161.13.142) by DB4PR06MB0621.eurprd06.prod.outlook.com (25.161.13.139) with Microsoft SMTP Server (TLS) id 15.1.172.22; Tue, 26 May 2015 09:13:43 +0000 Received: from DB4PR06MB0624.eurprd06.prod.outlook.com ([25.161.13.142]) by DB4PR06MB0624.eurprd06.prod.outlook.com ([25.161.13.142]) with mapi id 15.01.0172.012; Tue, 26 May 2015 09:13:43 +0000 From: DIEGO LOPEZ GARCIA To: "Romascanu, Dan (Dan)" Thread-Topic: [I2nsf] Definition for "Network Security Functions" Thread-Index: AQHQl41m97GpDfc8AEqJ3bOOiLAV/Z2N7qEAgAAAjoCAAAUwgIAAAeaAgAADJoA= Date: Tue, 26 May 2015 09:13:42 +0000 Message-ID: <76B3EEC8-27FE-4F9A-A9CA-41E726193F8D@telefonica.com> References: <9904FB1B0159DA42B0B887B7FA8119CA5CA3ACBF@AZ-FFEXMB04.global.avaya.com> <41298B1B-CFA5-44AD-B032-3493082BD80F@telefonica.com> <9904FB1B0159DA42B0B887B7FA8119CA5CA3ACF6@AZ-FFEXMB04.global.avaya.com> <2F8716D8-6028-4464-AAE2-6AC1EA279AF7@telefonica.com> <9904FB1B0159DA42B0B887B7FA8119CA5CA3AD97@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5CA3AD97@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=diego.r.lopez@telefonica.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [83.49.236.188] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB4PR06MB0621; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(520002)(3002001); SRVR:DB4PR06MB0621; BCL:0; PCL:0; RULEID:; SRVR:DB4PR06MB0621; x-forefront-prvs: 0588B2BD96 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(25724002)(189002)(40134004)(199003)(24454002)(252514010)(377454003)(53754006)(54356999)(76176999)(106356001)(101416001)(106116001)(33656002)(66066001)(50986999)(83716003)(19580395003)(19580405001)(82746002)(19617315012)(86362001)(93886004)(46102003)(36756003)(62966003)(77156002)(4001540100001)(97736004)(81156007)(189998001)(5001830100001)(87936001)(122556002)(40100003)(110136002)(5001960100002)(64706001)(5001860100001)(16236675004)(2656002)(2950100001)(92566002)(7110500001)(68736005)(15975445007)(2900100001)(2420400003)(105586002)(102836002)(7059030)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR06MB0621; H:DB4PR06MB0624.eurprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: telefonica.com does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_76B3EEC827FE4F9AA9CA41E726193F8Dtelefonicacom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 May 2015 09:13:42.2650 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR06MB0621 X-OriginatorOrg: telefonica.com X-TM-AS-MML: No Archived-At: Cc: "i2nsf@ietf.org" , Alexey Gorbunov , Linda Dunbar Subject: Re: [I2nsf] Definition for "Network Security Functions" X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 09:13:55 -0000 --_000_76B3EEC827FE4F9AA9CA41E726193F8Dtelefonicacom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable So, for the record, the definition we have now is as follows: "functions to ensure integrity, confidentiality and availability of network= communications, to detect unwanted activity, and to deter and block this u= nwanted activity or at least mitigate its effects on the network" Be goode, On 26 May 2015, at 11:02 , Romascanu, Dan (Dan) > wrote: wfm Regards, Dan From: DIEGO LOPEZ GARCIA [mailto:diego.r.lopez@telefonica.com] Sent: Tuesday, May 26, 2015 11:56 AM To: Romascanu, Dan (Dan) Cc: Alexey Gorbunov; i2nsf@ietf.org; Linda Dunbar Subject: Re: [I2nsf] Definition for "Network Security Functions" So "to deter and block"? Nothing to object from may side... On 26 May 2015, at 10:37 , Romascanu, Dan (Dan) > wrote: I believe that we need to add block. Preventing is good, but when =91unwant= ed activity=92 happens you need to limit it=92s spreading by dully blocking= . Regards, Dan From: DIEGO LOPEZ GARCIA [mailto:diego.r.lopez@telefonica.com] Sent: Tuesday, May 26, 2015 11:35 AM To: Romascanu, Dan (Dan) Cc: Alexey Gorbunov; i2nsf@ietf.org; Linda Dunbar Subject: Re: [I2nsf] Definition for "Network Security Functions" Hi Dan, In the New Oxford American Dictionary, the second meaning of "deter" is "pr= eventing the occurrence of", so I think we could keep it. And remembering B= ob's comments on pronouns, the definition should look like: "functions to ensure integrity, confidentiality and availability of network= communications, to detect unwanted activity, and to deter this unwanted ac= tivity or at least mitigate its effects on the network" On 26 May 2015, at 10:23 , Romascanu, Dan (Dan) > wrote: Hi, I like the definition because it=92s concise and seems to cover a lot. I am= not sure however what =91deter=92 means in this context. In some case NSFs= dully block effects of unwanted activity. Pending on clarifying what =91deter=92 means I suggest: "functions to ensure integrity, confidentiality and availability of network= communications, to detect unwanted activity, and to block it[, deter it] o= r at least mitigate its effects on the network" Regards, Dan From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Alexey Gorbunov Sent: Tuesday, May 26, 2015 1:42 AM To: i2nsf@ietf.org; Linda Dunbar Subject: [I2nsf] Definition for "Network Security Functions" Hi All I agree with Diego definition: "functions to ensure integrity, confidentiality and availability of network= communications, to detect unwanted activity, and to deter it or at least m= itigate its effects on the network" >From my point of view that covers all cases of network security function. Regarding Flow-based network security function: =93 A function that inspects network flows according to a policy intended f= or enforcing security properties. Flow-based security also means that pack= ets are inspected in the order they are received, and without modification = to the packet due to the inspection process (MAC rewrites, TTL decrement ac= tion; even NAT would be outside the inspection process). I'm not sure if it's valuable to inspect packet without modification. Ther= e are cases when it's more preferable to inspect and apply policy after NAT= . This is common practice and it must be a good reason to change it. Br, Alexey Gorbunov Telco Cloud and Security Architect at Nokia CCIE R&S 41088 _______________________________________________ I2nsf mailing list I2nsf@ietf.org 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: diego.r.lopez@telefonica.com Tel: +34 913 129 041 Mobile: +34 682 051 091 ---------------------------------- ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o= copia sin autorizaci=F3n puede estar prohibida en virtud de la legislaci= =F3n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo = comunique inmediatamente por esta misma v=EDa y proceda a su destrucci=F3n. The information contained in this transmission is privileged and confidenti= al 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 co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, div= ulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o pode estar proibida em virtude= da legisla=E7=E3o vigente. Se recebeu esta mensagem por erro, rogamos-lhe = que nos o comunique imediatamente por esta mesma via e proceda a sua destru= i=E7=E3o -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego.r.lopez@telefonica.com Tel: +34 913 129 041 Mobile: +34 682 051 091 ---------------------------------- ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o= copia sin autorizaci=F3n puede estar prohibida en virtud de la legislaci= =F3n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo = comunique inmediatamente por esta misma v=EDa y proceda a su destrucci=F3n. The information contained in this transmission is privileged and confidenti= al 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 co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, div= ulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o pode estar proibida em virtude= da legisla=E7=E3o vigente. Se recebeu esta mensagem por erro, rogamos-lhe = que nos o comunique imediatamente por esta mesma via e proceda a sua destru= i=E7=E3o -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego.r.lopez@telefonica.com Tel: +34 913 129 041 Mobile: +34 682 051 091 ---------------------------------- ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o= copia sin autorizaci=F3n puede estar prohibida en virtud de la legislaci= =F3n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo = comunique inmediatamente por esta misma v=EDa y proceda a su destrucci=F3n. The information contained in this transmission is privileged and confidenti= al 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 co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, div= ulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o pode estar proibida em virtude= da legisla=E7=E3o vigente. Se recebeu esta mensagem por erro, rogamos-lhe = que nos o comunique imediatamente por esta mesma via e proceda a sua destru= i=E7=E3o --_000_76B3EEC827FE4F9AA9CA41E726193F8Dtelefonicacom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <0CBC816A849DC84BA7D270D5E0AC5932@eurprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable So, for the record, the definition we have now is as follows:

"functions to ensure integrity, confidentiality and availability = of network communications, to detect unwanted activity, and to deter and bl= ock this unwanted activity or at least mitigate its effects on the network&= quot;

Be goode,

On 26 May 2015, at 11:02 , Romascanu, Dan (Dan) <dromasca@avaya.com> wrote:

wfm
 
Regards,
 
Dan
 
 
From:<= /span> DIEGO LOPEZ GARCIA [mailto:diego.r.lopez@telefonica.com] 
Sent: Tuesday, May= 26, 2015 11:56 AM
To: Romascanu, Dan= (Dan)
Cc: Alexey Gorbuno= v; i2nsf@ietf= .org; Linda Dunbar
Subject: Re: [I2ns= f] Definition for "Network Security Functions"<= /div>
 
So "to deter and block"? Nothing to object from may side...<= /o:p>
 
On 26 May 2015, at 10:37 , Romascanu, Dan (Dan) <dromasc= a@avaya.com> wrote:


I believe that we need to add block. Preventing is good, b= ut when =91unwanted activity=92 happens you need to limit it=92s spreading = by dully blocking.
 
Regards,
 
Dan
 
 
From:<= /span> DIEGO LOPEZ GARCIA [mai= lto:diego.r.lopez@telefonica.com] 
Sent: Tuesday, May= 26, 2015 11:35 AM
To: Romascanu, Dan= (Dan)
Cc: Alexey Gorbuno= v; i2nsf@ietf.org; Linda Dunbar
Subject: Re: [I2ns= f] Definition for "Network Security Functions"<= /div>
 
Hi Dan,
 
In the New Oxford American Dictionary, the second meaning of "deter&qu= ot; is "preventing the occurrence of", so I think we could keep i= t. And remembering Bob's comments on pronouns, the definition should look l= ike:
 
"functions to ensure integrity, confidentiality and availability of ne= twork communications, to detect unwanted activity, and to deter this unwant= ed activity or at least mitigate its effects on the network"
 
On 26 May 2015, at 10:23 , Romascanu, Dan (Dan) <dromasca@avaya.com> wrote:=



Hi,
 
I like the definition because it=92s concise and seems to = cover a lot. I am not sure however what =91deter=92 means in this context. = In some case NSFs dully block effects of unwanted activity.
 
Pending on clarifying what =91deter=92 means I suggest:
 
"functions to ensure integrity, confidentiality and availability of ne= twork communications, to detect unwanted activity, and to block it[, deter = it] or at least mitigate its effects on the network"
 
Regards,
 
Dan
 
 
From:<= /span> I2nsf [mailto:i2nsf-bounces@i= etf.org] On= Behalf Of Alexey Gorbunov
Sent: Tuesday, May= 26, 2015 1:42 AM
To: i2nsf@ietf.org; Linda Dunbar
Subject: [I2nsf] D= efinition for "Network Security Functions"
 
Hi All
 
I agree with Diego definition: 
"functions to ensure integrity, confidentiality and availability of ne= twork communications, to detect unwanted activity, and to deter it or at le= ast mitigate its effects on the network"
 
>From my point of view that covers all cases of network security function.
 
Regarding Flow-based network security function:
 
=93 A function that inspects network flows according to a policy intended f= or enforcing security properties.  Flow-based security also means that= packets are inspected in the order they are received, and without modifica= tion to the packet due to the inspection process (MAC rewrites, TTL decrement action; even NAT would be outside the= inspection process).
 
I'm not sure if it's valuable  to inspect packet without modification.= There are cases when it's more preferable to inspect and apply policy afte= r NAT.  This is common practice and it must be a good reason to change= it. 
 
Br, Alexey Gorbunov
Telco Cloud and Security Architect at Nokia
CCIE R&S 41088
 
 
 
 
 
_______= ________________________________________
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf
 
 
 

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o copia sin autorizaci=F3n puede e= star prohibida en virtud de la legislaci=F3n vigente. Si ha recibido este m= ensaje por error, le rogamos que nos lo comunique inmediatamente por esta m= isma v=EDa y proceda a su destrucci=F3n.

The information contained in this transmission is privileged and confidenti= al 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 y= ou have received this transmission in error, do not read it. Please immedia= tely 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=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, divulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o p= ode estar proibida em virtude da legisla=E7=E3o vigente. Se recebeu esta me= nsagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mes= ma via e proceda a sua destrui=E7=E3o
 
--
"Esta vez no fallaremos, Doctor Infierno"

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

e-mail: diego.r.lopez@telefonica.com
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------
 
 

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o copia sin autorizaci=F3n puede e= star prohibida en virtud de la legislaci=F3n vigente. Si ha recibido este m= ensaje por error, le rogamos que nos lo comunique inmediatamente por esta m= isma v=EDa y proceda a su destrucci=F3n.

The information contained in this transmission is privileged and confidenti= al 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 y= ou have received this transmission in error, do not read it. Please immedia= tely 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=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, divulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o p= ode estar proibida em virtude da legisla=E7=E3o vigente. Se recebeu esta me= nsagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mes= ma via e proceda a sua destrui=E7=E3o

--
"Esta vez no fallaremos, Doctor Infierno"

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

e-mail: diego.r.lopez@telefonica.com
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------



Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o copia sin autorizaci=F3n puede e= star prohibida en virtud de la legislaci=F3n vigente. Si ha recibido este m= ensaje por error, le rogamos que nos lo comunique inmediatamente por esta m= isma v=EDa y proceda a su destrucci=F3n.

The information contained in this transmission is privileged and confidenti= al 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 y= ou have received this transmission in error, do not read it. Please immedia= tely 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=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, divulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o p= ode estar proibida em virtude da legisla=E7=E3o vigente. Se recebeu esta me= nsagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mes= ma via e proceda a sua destrui=E7=E3o
 --_000_76B3EEC827FE4F9AA9CA41E726193F8Dtelefonicacom_-- From nobody Tue May 26 06:01:24 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 313001B2B86 for ; Tue, 26 May 2015 06:01:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Xn6jS0CYw3m for ; Tue, 26 May 2015 06:01:19 -0700 (PDT) Received: from smtpvbsrv1.mitre.org (smtpvbsrv1.mitre.org [198.49.146.234]) by ietfa.amsl.com (Postfix) with ESMTP id 52AB51B2B84 for ; Tue, 26 May 2015 06:01:19 -0700 (PDT) Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id DCD32B2E871; Tue, 26 May 2015 09:01:17 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpvbsrv1.mitre.org (Postfix) with ESMTP id CA018B2E879; Tue, 26 May 2015 09:01:17 -0400 (EDT) Received: from imshyb02.MITRE.ORG (129.83.29.3) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.3.224.2; Tue, 26 May 2015 09:01:17 -0400 Received: from imshyb01.MITRE.ORG (129.83.29.2) by imshyb02.MITRE.ORG (129.83.29.3) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Tue, 26 May 2015 09:01:16 -0400 Received: from na01-bn1-obe.outbound.protection.outlook.com (10.140.19.249) by imshyb01.MITRE.ORG (129.83.29.2) with Microsoft SMTP Server (TLS) id 15.0.1044.25 via Frontend Transport; Tue, 26 May 2015 09:01:16 -0400 Received: from CY1PR09MB0922.namprd09.prod.outlook.com (10.163.89.140) by CY1PR09MB0924.namprd09.prod.outlook.com (10.163.89.142) with Microsoft SMTP Server (TLS) id 15.1.172.22; Tue, 26 May 2015 13:01:12 +0000 Received: from CY1PR09MB0922.namprd09.prod.outlook.com ([10.163.89.140]) by CY1PR09MB0922.namprd09.prod.outlook.com ([10.163.89.140]) with mapi id 15.01.0172.012; Tue, 26 May 2015 13:01:12 +0000 From: "Natale, Bob" To: DIEGO LOPEZ GARCIA Thread-Topic: [I2nsf] Definition for "Network Security Functions" Thread-Index: AQHQl2BNaC/heUYRRaG527iXhQCbp52Nm6sAgABLg4CAAFIYYA== Date: Tue, 26 May 2015 13:01:11 +0000 Message-ID: References: <241A3C3B-E261-4E27-9BBD-B4925179C1F9@telefonica.com> In-Reply-To: <241A3C3B-E261-4E27-9BBD-B4925179C1F9@telefonica.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=RNATALE@mitre.org; x-originating-ip: [192.80.55.86] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR09MB0924; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(520002)(3002001); SRVR:CY1PR09MB0924; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0924; x-forefront-prvs: 0588B2BD96 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(53754006)(25724002)(252514010)(199003)(377454003)(189002)(40134004)(24454002)(5001960100002)(19300405004)(19625215002)(5001830100001)(16236675004)(5001860100001)(46102003)(4001540100001)(81156007)(106116001)(106356001)(102836002)(15975445007)(2420400003)(105586002)(97736004)(110136002)(99286002)(74316001)(7110500001)(189998001)(77096005)(76576001)(66066001)(50986999)(76176999)(54356999)(86362001)(101416001)(64706001)(77156002)(2900100001)(87936001)(40100003)(2656002)(92566002)(2950100001)(19580395003)(19580405001)(19617315012)(19609705001)(122556002)(33656002)(62966003)(68736005); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR09MB0924; H:CY1PR09MB0922.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: mitre.org does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_CY1PR09MB0922D2B703F55543F1EDC94DA8CC0CY1PR09MB0922namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 May 2015 13:01:11.6860 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c620dc48-1d50-4952-8b39-df4d54d74d82 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0924 X-OriginatorOrg: mitre.org Archived-At: Cc: "i2nsf@ietf.org" , Alexey Gorbunov , Dacheng Zhang , Linda Dunbar Subject: Re: [I2nsf] Definition for "Network Security Functions" X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 13:01:23 -0000 --_000_CY1PR09MB0922D2B703F55543F1EDC94DA8CC0CY1PR09MB0922namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWdyZWVkLg0KDQpBdmFudGksDQpCb2JODQoNCkZyb206IEkybnNmIFttYWlsdG86aTJuc2YtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIERJRUdPIExPUEVaIEdBUkNJQQ0KU2VudDogVHVl c2RheSwgTWF5IDI2LCAyMDE1IDQ6MDcgQU0NClRvOiBOYXRhbGUsIEJvYg0KQ2M6IGkybnNmQGll dGYub3JnOyBBbGV4ZXkgR29yYnVub3Y7IERhY2hlbmcgWmhhbmc7IExpbmRhIER1bmJhcg0KU3Vi amVjdDogUmU6IFtJMm5zZl0gRGVmaW5pdGlvbiBmb3IgIk5ldHdvcmsgU2VjdXJpdHkgRnVuY3Rp b25zIg0KDQpIaSBCb2IsDQoNCkhhdmluZyBzcGVudCBteSBwcm9mZXNzaW9uYWwgbGlmZSB0cnlp bmcgdG8gYXBwbHkgZ29vZC1vbGUgRnJpYXIgV2lsbGlhbSdzIHJhem9yLCBJIGFncmVlIHRoZSBz aG9ydGVyIHZlcnNpb24geW91IHByb3Bvc2Ugd291bGQgYmUgY29ycmVjdCBhbmQgY29tcGxldGUu IEJ1dCBhY2NvcmRpbmcgdG8gbXkgZXhwZXJpZW5jZSBJIHRoaW5rIGl0IHdvdWxkIGJlIGdvb2Qg dG8gbGVhdmUgdGhlIHNlY29uZCBwYXJ0IGFzayB3ZWxsIGluIG9yZGVyIHRvIGF2b2lkIG1pc3Vu ZGVyc3RhbmRpbmdzIGxpa2UgdGhlIGNvbmNlcm4gZXhwcmVzc2VkIGJ5IERhY2hlbmcuDQoNClRo ZXJlIGlzIGEgdmFsdWUgaW4gYmVpbmcgc29tZWhvdyByZWR1bmRhbnQgaWYgaXQgaXMgdGhlIHBy aWNlIHlvdSBwYXkgdG8gYXZvaWQgbWlzY29uY2VwdGlvbi4NCg0KQmUgZ29vZGUsDQoNCk9uIDI2 IE1heSAyMDE1LCBhdCAwNTo0MiAsIE5hdGFsZSwgQm9iIDxSTkFUQUxFQG1pdHJlLm9yZzxtYWls dG86Uk5BVEFMRUBtaXRyZS5vcmc+PiB3cm90ZToNCg0KDQpIaSBEYWNoZW5nLA0KDQpJIGd1ZXNz IGl0IGRlcGVuZHMgb24gd2hhdCBzb3VyY2VzIHlvdSByZWx5IG9uIGZvciB0aGUgdW5kZXJseWlu ZyBkZWZpbml0aW9ucy4gSSByZWZlcmVuY2VkIE5JU1QgU3BlY2lhbCBQdWJsaWNhdGlvbiA4MDAt NTMgUmV2aXNpb24gNCwgU2VjdXJpdHkgYW5kIFByaXZhY3kgQ29udHJvbHMgZm9yIEZlZGVyYWwg SW5mb3JtYXRpb24gU3lzdGVtcyBhbmQgT3JnYW5pemF0aW9ucy4gV2hpbGUgdGhlcmUgYXJlIG51 bWVyb3VzIGV4aXN0ZW5jZSBwcm9vZnMgaW4gODAwLTUzIHRvIHJlZnV0ZSB5b3VyIGFzc2VydGlv biBiZWxvdyB3aXRoIHJlc3BlY3QgdG8gZGV0ZWN0aW9uLCBJIHdvdWxkIGp1c3QgcG9pbnQgdG8g dGhlIGRlZmluaXRpb24gb2YgQUMtNCwgSW5mb3JtYXRpb24gRmxvdyBFbmZvcmNlbWVudCwgaW4g QXBwZW5kaXggRiwgU2VjdXJpdHkgQ29udHJvbCBDYXRhbG9nLCBlc3BlY2lhbGx5IGVuaGFuY2Vt ZW50IGNsYXVzZXMgKDMpIGFuZCAoMTUpLiBBcyBJIHNhaWQsIHRoZXJlIGFyZSBtYW55IG90aGVy cy4NCg0KT2YgY291cnNlLCBpdCBjb3VsZCBiZSB0aGF0IDgwMC01MyBpcyBub3QgYW4gYWNjZXB0 YWJsZSBzb3VyY2UgZm9yIGZvdW5kYXRpb25hbCBkZWZpbml0aW9ucyBmb3IgSTJOU0YuDQoNCkF2 YW50aSwNCkJvYk4NCg0KRnJvbTogSTJuc2YgW21haWx0bzppMm5zZi1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgRGFjaGVuZyBaaGFuZw0KU2VudDogTW9uZGF5LCBNYXkgMjUsIDIwMTUg MTE6MDIgUE0NClRvOiBOYXRhbGUsIEJvYjsgQWxleGV5IEdvcmJ1bm92OyBMaW5kYSBEdW5iYXIN CkNjOiBpMm5zZkBpZXRmLm9yZzxtYWlsdG86aTJuc2ZAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTog W0kybnNmXSBEZWZpbml0aW9uIGZvciAiTmV0d29yayBTZWN1cml0eSBGdW5jdGlvbnMiDQoNCg0K DQrlj5Hku7bkuro6ICJOYXRhbGUsIEJvYiIgPFJOQVRBTEVAbWl0cmUub3JnPG1haWx0bzpSTkFU QUxFQG1pdHJlLm9yZz4+DQrml6XmnJ86IDIwMTXlubQ15pyIMjbml6Ug5pif5pyf5LqMIOS4iuWN iDEwOjU1DQroh7M6IEFsZXhleSBHb3JidW5vdiA8YWxleGV5LmdvcmJ1bm92ODJAZ21haWwuY29t PG1haWx0bzphbGV4ZXkuZ29yYnVub3Y4MkBnbWFpbC5jb20+PiwgTGluZGEgRHVuYmFyIDxsaW5k YS5kdW5iYXJAaHVhd2VpLmNvbTxtYWlsdG86bGluZGEuZHVuYmFyQGh1YXdlaS5jb20+Pg0K5oqE 6YCBOiAiaTJuc2ZAaWV0Zi5vcmc8bWFpbHRvOmkybnNmQGlldGYub3JnPiIgPGkybnNmQGlldGYu b3JnPG1haWx0bzppMm5zZkBpZXRmLm9yZz4+DQrkuLvpopg6IFJlOiBbSTJuc2ZdIERlZmluaXRp b24gZm9yICJOZXR3b3JrIFNlY3VyaXR5IEZ1bmN0aW9ucyINCg0KR2l2ZW4gYWdyZWVtZW50IGFy b3VuZCBEaWVnb+KAmXMgZGVmaW5pdGlvbiwgSSBiZWxpZXZlIGl0IGlzIHN1ZmZpY2llbnQgdG8g c2F5IOKAnEZ1bmN0aW9ucyB0byBlbnN1cmUgdGhlIGNvbmZpZGVudGlhbGl0eSwgaW50ZWdyaXR5 LCBhbmQgYXZhaWxhYmxlIG9mIG5ldHdvcmsgY29tbXVuaWNhdGlvbnMu4oCdIChQdXR0aW5nICB0 aGUgQ0lBIGluIHRoZSB0cmFkaXRpb25hbCBvcmRlci4pIFRoZSBzZWNvbmQgcGFydCAo4oCcdG8g ZGV0ZWN0IHVud2FudGVkIGFjdGl2aXR5LCBhbmQgdG8gZGV0ZXIgaXQgb3IgYXQgbGVhc3QgbWl0 aWdhdGUgaXRzIGVmZmVjdHMgb24gdGhlIG5ldHdvcmvigJ0pIGFkZHMgbm90aGluZyB0aGF0IGlz IG5vdCBhbHJlYWR5IGluY2x1ZGVkIGluIHRoZSBmaXJzdCBwYXJ0IGJ1dCBpbXBsaWNpdGx5IChi eSBvbWlzc2lvbikgZXhjbHVkZXMgc29tZSBmdW5jdGlvbnMgKGUuZy4sIHByZXZlbnRpdmUgZnVu Y3Rpb25zKSB0aGF0IGFyZSAobm9ybWFsbHkpIGluY2x1ZGVkLg0KDQpEYWNoZW5nOi8vIEkgdGhp bmsgQ0lBIGNhbm5vdCByZWFsbHkgdGFrZSBwbGFjZSBvZiB0aGUgc2Vjb25kIHBhcnQuIFRoZSBD SUEgaXMgYWJvdXQgZW5zdXJpbmcgZGF0YeKAmHNlY3VyZWx5JyB0cmFuc3BvcnRlZCBvdmVyIHRo ZSBuZXR3b3JrLiBUaGUgc2Vjb25kIHBhcnQgaXMgYWJvdXQgZGV0ZWN0aW5nIHRoZSBpbXByb3Bl ciBjb250ZW50IGluIHRoZSBkYXRhIG9yIGltcHJvcGVyIHNpZ25hbGluZyB3aGljaCBtYXkgYWZm ZWN0IHRoZSBub3JtYWwgb3BlcmF0b3JzIG9mIG5ldHdvcmsgc3lzdGVtcy4NCg0KDQoNCg0KDQoN Cg0KQnkgZXh0ZW5zaW9uLCBJIHdvdWxkIGFsc28gc2F5IHRoYXQgdGhlIGRlZmluaXRpb24gcGVy IGFib3ZlIGV4dGVuZHMgdG8gdGhlIHJlc291cmNlcyAoZGV2aWNlcywgYXBwbGljYXRpb25zLCBz ZXJ2aWNlcykgbmVjZXNzYXJ5IHRvIHN1cHBvcnQgbmV0d29yayBjb21tdW5pY2F0aW9ucyDigKYg c2luY2UgYSB2aW9sYXRpb24gb2Ygc2VjdXJpdHkgdGhlcmUgaGFzIGEgcG90ZW50aWFsICB1bmRl c2lyZWQgZWZmZWN0IGluIHRoZSBuZXR3b3JrIHRyYWZmaWMuDQoNClNvLCBJIG1pZ2h0IHN1Z2dl c3QgYW4gZXh0ZW5zaW9uIG9mIHRoZSBkZWZpbml0aW9uIHRvIOKAnEZ1bmN0aW9ucyB0byBlbnN1 cmUgdGhlIGNvbmZpZGVudGlhbGl0eSwgaW50ZWdyaXR5LCBhbmQgYXZhaWxhYmlsaXR5IG9mIG5l dHdvcmsgY29tbXVuaWNhdGlvbnMgYW5kIHRoZSByZXNvdXJjZXMgdXNlZCB0byBzdXBwb3J0IG5l dHdvcmsgY29tbXVuaWNhdGlvbnMu4oCdIOKApj8NCg0KQXZhbnRpLA0KQm9iTg0KDQpGcm9tOiBJ Mm5zZiBbbWFpbHRvOmkybnNmLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBbGV4ZXkg R29yYnVub3YNClNlbnQ6IE1vbmRheSwgTWF5IDI1LCAyMDE1IDY6NDIgUE0NClRvOiBpMm5zZkBp ZXRmLm9yZzxtYWlsdG86aTJuc2ZAaWV0Zi5vcmc+OyBMaW5kYSBEdW5iYXINClN1YmplY3Q6IFtJ Mm5zZl0gRGVmaW5pdGlvbiBmb3IgIk5ldHdvcmsgU2VjdXJpdHkgRnVuY3Rpb25zIg0KDQpIaSBB bGwNCg0KSSBhZ3JlZSB3aXRoIERpZWdvIGRlZmluaXRpb246DQoiZnVuY3Rpb25zIHRvIGVuc3Vy ZSBpbnRlZ3JpdHksIGNvbmZpZGVudGlhbGl0eSBhbmQgYXZhaWxhYmlsaXR5IG9mIG5ldHdvcmsg Y29tbXVuaWNhdGlvbnMsIHRvIGRldGVjdCB1bndhbnRlZCBhY3Rpdml0eSwgYW5kIHRvIGRldGVy IGl0IG9yIGF0IGxlYXN0IG1pdGlnYXRlIGl0cyBlZmZlY3RzIG9uIHRoZSBuZXR3b3JrIg0KDQpG cm9tIG15IHBvaW50IG9mIHZpZXcgdGhhdCBjb3ZlcnMgYWxsIGNhc2VzIG9mIG5ldHdvcmsgc2Vj dXJpdHkgZnVuY3Rpb24uDQoNClJlZ2FyZGluZyBGbG93LWJhc2VkIG5ldHdvcmsgc2VjdXJpdHkg ZnVuY3Rpb246DQoNCuKAnCBBIGZ1bmN0aW9uIHRoYXQgaW5zcGVjdHMgbmV0d29yayBmbG93cyBh Y2NvcmRpbmcgdG8gYSBwb2xpY3kgaW50ZW5kZWQgZm9yIGVuZm9yY2luZyBzZWN1cml0eSBwcm9w ZXJ0aWVzLiAgRmxvdy1iYXNlZCBzZWN1cml0eSBhbHNvIG1lYW5zIHRoYXQgcGFja2V0cyBhcmUg aW5zcGVjdGVkIGluIHRoZSBvcmRlciB0aGV5IGFyZSByZWNlaXZlZCwgYW5kIHdpdGhvdXQgbW9k aWZpY2F0aW9uIHRvIHRoZSBwYWNrZXQgZHVlIHRvIHRoZSBpbnNwZWN0aW9uIHByb2Nlc3MgKE1B QyByZXdyaXRlcywgVFRMIGRlY3JlbWVudCBhY3Rpb247IGV2ZW4gTkFUIHdvdWxkIGJlIG91dHNp ZGUgdGhlIGluc3BlY3Rpb24gcHJvY2VzcykuDQoNCkknbSBub3Qgc3VyZSBpZiBpdCdzIHZhbHVh YmxlICB0byBpbnNwZWN0IHBhY2tldCB3aXRob3V0IG1vZGlmaWNhdGlvbi4gVGhlcmUgYXJlIGNh c2VzIHdoZW4gaXQncyBtb3JlIHByZWZlcmFibGUgdG8gaW5zcGVjdCBhbmQgYXBwbHkgcG9saWN5 IGFmdGVyIE5BVC4gIFRoaXMgaXMgY29tbW9uIHByYWN0aWNlIGFuZCBpdCBtdXN0IGJlIGEgZ29v ZCByZWFzb24gdG8gY2hhbmdlIGl0Lg0KDQpCciwgQWxleGV5IEdvcmJ1bm92DQpUZWxjbyBDbG91 ZCBhbmQgU2VjdXJpdHkgQXJjaGl0ZWN0IGF0IE5va2lhDQpDQ0lFIFImUyA0MTA4OA0KDQoNCg0K DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIEkybnNm IG1haWxpbmcgbGlzdCBJMm5zZkBpZXRmLm9yZzxtYWlsdG86STJuc2ZAaWV0Zi5vcmc+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pMm5zZg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkkybnNmIG1haWxpbmcgbGlzdA0KSTJuc2ZA aWV0Zi5vcmc8bWFpbHRvOkkybnNmQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9pMm5zZg0KDQotLQ0KIkVzdGEgdmV6IG5vIGZhbGxhcmVtb3MsIERvY3Rv ciBJbmZpZXJubyINCg0KRHIgRGllZ28gUi4gTG9wZXoNClRlbGVmb25pY2EgSStEDQpodHRwOi8v cGVvcGxlLnRpZC5lcy9kaWVnby5sb3Blei8NCg0KZS1tYWlsOiBkaWVnby5yLmxvcGV6QHRlbGVm b25pY2EuY29tPG1haWx0bzpkaWVnby5yLmxvcGV6QHRlbGVmb25pY2EuY29tPg0KVGVsOiAgICAr MzQgOTEzIDEyOSAwNDENCk1vYmlsZTogKzM0IDY4MiAwNTEgMDkxDQotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cg0KRXN0ZSBtZW5zYWplIHkgc3VzIGFkanVudG9zIHNlIGRpcmlnZW4gZXhjbHVzaXZhbWVudGUg YSBzdSBkZXN0aW5hdGFyaW8sIHB1ZWRlIGNvbnRlbmVyIGluZm9ybWFjacOzbiBwcml2aWxlZ2lh ZGEgbyBjb25maWRlbmNpYWwgeSBlcyBwYXJhIHVzbyBleGNsdXNpdm8gZGUgbGEgcGVyc29uYSBv IGVudGlkYWQgZGUgZGVzdGluby4gU2kgbm8gZXMgdXN0ZWQuIGVsIGRlc3RpbmF0YXJpbyBpbmRp Y2FkbywgcXVlZGEgbm90aWZpY2FkbyBkZSBxdWUgbGEgbGVjdHVyYSwgdXRpbGl6YWNpw7NuLCBk aXZ1bGdhY2nDs24geS9vIGNvcGlhIHNpbiBhdXRvcml6YWNpw7NuIHB1ZWRlIGVzdGFyIHByb2hp YmlkYSBlbiB2aXJ0dWQgZGUgbGEgbGVnaXNsYWNpw7NuIHZpZ2VudGUuIFNpIGhhIHJlY2liaWRv IGVzdGUgbWVuc2FqZSBwb3IgZXJyb3IsIGxlIHJvZ2Ftb3MgcXVlIG5vcyBsbyBjb211bmlxdWUg aW5tZWRpYXRhbWVudGUgcG9yIGVzdGEgbWlzbWEgdsOtYSB5IHByb2NlZGEgYSBzdSBkZXN0cnVj Y2nDs24uDQoNClRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyB0cmFuc21pc3Npb24g aXMgcHJpdmlsZWdlZCBhbmQgY29uZmlkZW50aWFsIGluZm9ybWF0aW9uIGludGVuZGVkIG9ubHkg Zm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IG5hbWVkIGFib3ZlLiBJZiB0 aGUgcmVhZGVyIG9mIHRoaXMgbWVzc2FnZSBpcyBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwg eW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0 aW9uIG9yIGNvcHlpbmcgb2YgdGhpcyBjb21tdW5pY2F0aW9uIGlzIHN0cmljdGx5IHByb2hpYml0 ZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgdHJhbnNtaXNzaW9uIGluIGVycm9yLCBkbyBu b3QgcmVhZCBpdC4gUGxlYXNlIGltbWVkaWF0ZWx5IHJlcGx5IHRvIHRoZSBzZW5kZXIgdGhhdCB5 b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IgYW5kIHRoZW4gZGVs ZXRlIGl0Lg0KDQpFc3RhIG1lbnNhZ2VtIGUgc2V1cyBhbmV4b3Mgc2UgZGlyaWdlbSBleGNsdXNp dmFtZW50ZSBhbyBzZXUgZGVzdGluYXTDoXJpbywgcG9kZSBjb250ZXIgaW5mb3JtYcOnw6NvIHBy aXZpbGVnaWFkYSBvdSBjb25maWRlbmNpYWwgZSDDqSBwYXJhIHVzbyBleGNsdXNpdm8gZGEgcGVz c29hIG91IGVudGlkYWRlIGRlIGRlc3Rpbm8uIFNlIG7Do28gw6kgdm9zc2Egc2VuaG9yaWEgbyBk ZXN0aW5hdMOhcmlvIGluZGljYWRvLCBmaWNhIG5vdGlmaWNhZG8gZGUgcXVlIGEgbGVpdHVyYSwg dXRpbGl6YcOnw6NvLCBkaXZ1bGdhw6fDo28gZS9vdSBjw7NwaWEgc2VtIGF1dG9yaXphw6fDo28g cG9kZSBlc3RhciBwcm9pYmlkYSBlbSB2aXJ0dWRlIGRhIGxlZ2lzbGHDp8OjbyB2aWdlbnRlLiBT ZSByZWNlYmV1IGVzdGEgbWVuc2FnZW0gcG9yIGVycm8sIHJvZ2Ftb3MtbGhlIHF1ZSBub3MgbyBj b211bmlxdWUgaW1lZGlhdGFtZW50ZSBwb3IgZXN0YSBtZXNtYSB2aWEgZSBwcm9jZWRhIGEgc3Vh IGRlc3RydWnDp8Ojbw0K --_000_CY1PR09MB0922D2B703F55543F1EDC94DA8CC0CY1PR09MB0922namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OlNpbVN1bjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpMdWNpZGFHcmFuZGU7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJcQFNpbVN1biI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAx IDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1h bCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlm O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uYXBwbGUtY29udmVy dGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFu LkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojOTkzMzAwOw0KCWZvbnQtd2VpZ2h0 Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0 aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4w aW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxl PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQi IGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+ DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNs YXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojOTkzMzAwIj5B Z3JlZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj OTkzMzAwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojOTkzMzAwIj5BdmFudGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojOTkzMzAwIj5Cb2JOPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM5OTMzMDAiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPiBJMm5zZiBbbWFpbHRvOmkybnNmLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5P biBCZWhhbGYgT2YgPC9iPkRJRUdPIExPUEVaIEdBUkNJQTxicj4NCjxiPlNlbnQ6PC9iPiBUdWVz ZGF5LCBNYXkgMjYsIDIwMTUgNDowNyBBTTxicj4NCjxiPlRvOjwvYj4gTmF0YWxlLCBCb2I8YnI+ DQo8Yj5DYzo8L2I+IGkybnNmQGlldGYub3JnOyBBbGV4ZXkgR29yYnVub3Y7IERhY2hlbmcgWmhh bmc7IExpbmRhIER1bmJhcjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0kybnNmXSBEZWZpbml0 aW9uIGZvciAmcXVvdDtOZXR3b3JrIFNlY3VyaXR5IEZ1bmN0aW9ucyZxdW90OzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIEJvYiwgPG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IYXZpbmcgc3BlbnQgbXkgcHJvZmVz c2lvbmFsIGxpZmUgdHJ5aW5nIHRvIGFwcGx5IGdvb2Qtb2xlIEZyaWFyIFdpbGxpYW0ncyByYXpv ciwgSSBhZ3JlZSB0aGUgc2hvcnRlciB2ZXJzaW9uIHlvdSBwcm9wb3NlIHdvdWxkIGJlIGNvcnJl Y3QgYW5kIGNvbXBsZXRlLiBCdXQgYWNjb3JkaW5nIHRvIG15IGV4cGVyaWVuY2UgSSB0aGluayBp dCB3b3VsZCBiZSBnb29kIHRvIGxlYXZlIHRoZSBzZWNvbmQgcGFydCBhc2sNCiB3ZWxsIGluIG9y ZGVyIHRvIGF2b2lkIG1pc3VuZGVyc3RhbmRpbmdzIGxpa2UgdGhlIGNvbmNlcm4gZXhwcmVzc2Vk IGJ5IERhY2hlbmcuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlRoZXJlIGlzIGEgdmFsdWUgaW4gYmVpbmcgc29tZWhvdyByZWR1bmRhbnQgaWYg aXQgaXMgdGhlIHByaWNlIHlvdSBwYXkgdG8gYXZvaWQgbWlzY29uY2VwdGlvbi48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmUgZ29vZGUsPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMjYg TWF5IDIwMTUsIGF0IDA1OjQyICwgTmF0YWxlLCBCb2IgJmx0OzxhIGhyZWY9Im1haWx0bzpSTkFU QUxFQG1pdHJlLm9yZyI+Uk5BVEFMRUBtaXRyZS5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286 cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojOTkzMzAw Ij5IaSBEYWNoZW5nLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izk5MzMwMCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojOTkzMzAwIj5JIGd1 ZXNzIGl0IGRlcGVuZHMgb24gd2hhdCBzb3VyY2VzIHlvdSByZWx5IG9uIGZvciB0aGUgdW5kZXJs eWluZyBkZWZpbml0aW9ucy4gSSByZWZlcmVuY2VkIE5JU1QgU3BlY2lhbCBQdWJsaWNhdGlvbiA4 MDAtNTMgUmV2aXNpb24gNCwgU2VjdXJpdHkgYW5kIFByaXZhY3kgQ29udHJvbHMgZm9yIEZlZGVy YWwNCiBJbmZvcm1hdGlvbiBTeXN0ZW1zIGFuZCBPcmdhbml6YXRpb25zLiBXaGlsZSB0aGVyZSBh cmUgbnVtZXJvdXMgZXhpc3RlbmNlIHByb29mcyBpbiA4MDAtNTMgdG8gcmVmdXRlIHlvdXIgYXNz ZXJ0aW9uIGJlbG93IHdpdGggcmVzcGVjdCB0byBkZXRlY3Rpb24sIEkgd291bGQganVzdCBwb2lu dCB0byB0aGUgZGVmaW5pdGlvbiBvZiBBQy00LCBJbmZvcm1hdGlvbiBGbG93IEVuZm9yY2VtZW50 LCBpbiBBcHBlbmRpeCBGLCBTZWN1cml0eSBDb250cm9sDQogQ2F0YWxvZywgZXNwZWNpYWxseSBl bmhhbmNlbWVudCBjbGF1c2VzICgzKSBhbmQgKDE1KS4gQXMgSSBzYWlkLCB0aGVyZSBhcmUgbWFu eSBvdGhlcnMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojOTkzMzAwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM5OTMzMDAiPk9mIGNvdXJz ZSwgaXQgY291bGQgYmUgdGhhdCA4MDAtNTMgaXMgbm90IGFuIGFjY2VwdGFibGUgc291cmNlIGZv ciBmb3VuZGF0aW9uYWwgZGVmaW5pdGlvbnMgZm9yIEkyTlNGLjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izk5MzMwMCI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6Izk5MzMwMCI+QXZhbnRpLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izk5MzMwMCI+Qm9iTjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojOTkzMzAwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUx RTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gY2xhc3M9 ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+STJuc2YNCiBbPGEgaHJlZj0ibWFpbHRvOmkybnNmLWJvdW5j ZXNAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjojOTU0RjcyIj5tYWlsdG86aTJuc2YtYm91 bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+XTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj48Yj5PbiBCZWhhbGYgT2Y8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPkRhY2hlbmcgWmhhbmc8YnI+DQo8Yj5TZW50Ojwv Yj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+TW9uZGF5 LCBNYXkgMjUsIDIwMTUgMTE6MDIgUE08YnI+DQo8Yj5Ubzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPk5hdGFsZSwgQm9iOyBBbGV4ZXkgR29yYnVu b3Y7IExpbmRhIER1bmJhcjxicj4NCjxiPkNjOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmkybnNmQGlldGYub3JnIj48 c3BhbiBzdHlsZT0iY29sb3I6Izk1NEY3MiI+aTJuc2ZAaWV0Zi5vcmc8L3NwYW4+PC9hPjxicj4N CjxiPlN1YmplY3Q6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj5SZTogW0kybnNmXSBEZWZpbml0aW9uIGZvciAmcXVvdDtOZXR3b3JrIFNlY3VyaXR5 IEZ1bmN0aW9ucyZxdW90Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4w cHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OlNpbVN1bjttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+5Y+R5Lu25Lq6PC9zcGFuPjwv Yj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZxdW90O05hdGFsZSwN CiBCb2ImcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpSTkFUQUxFQG1pdHJlLm9yZyI+PHNwYW4g c3R5bGU9ImNvbG9yOiM5NTRGNzIiPlJOQVRBTEVAbWl0cmUub3JnPC9zcGFuPjwvYT4mZ3Q7PGJy Pg0KPC9zcGFuPjxiPjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTpTaW1TdW47bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPuaXpeacnzwvc3Bh bj48L2I+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj46PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4yMDE1PC9zcGFu PjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpT aW1TdW47bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPuW5tDwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPjU8L3NwYW4+PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OlNpbVN1bjttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+5pyIPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+MjY8L3NwYW4+PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1bjttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+ 5pelPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5i c3A7PC9zcGFuPjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpTaW1TdW47bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPuaYn+acn+S6jDwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzwvc3Bh bj48c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 U2ltU3VuO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj7kuIrljYg8L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj4xMDo1NTxicj4NCjwvc3Bhbj48Yj48c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuO21zby1mYXJlYXN0LWxhbmd1YWdlOlpI LUNOIj7oh7M8L3NwYW4+PC9iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+OjxzcGFuIGNsYXNzPSJhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+QWxleGV5DQogR29yYnVub3YgJmx0OzxhIGhyZWY9Im1haWx0bzphbGV4ZXkuZ29yYnVub3Y4 MkBnbWFpbC5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjojOTU0RjcyIj5hbGV4ZXkuZ29yYnVub3Y4 MkBnbWFpbC5jb208L3NwYW4+PC9hPiZndDssIExpbmRhIER1bmJhciAmbHQ7PGEgaHJlZj0ibWFp bHRvOmxpbmRhLmR1bmJhckBodWF3ZWkuY29tIj48c3BhbiBzdHlsZT0iY29sb3I6Izk1NEY3MiI+ bGluZGEuZHVuYmFyQGh1YXdlaS5jb208L3NwYW4+PC9hPiZndDs8YnI+DQo8L3NwYW4+PGI+PHNw YW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1 bjttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+5oqE6YCBPC9zcGFuPjwvYj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPjo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZxdW90OzxhIGhyZWY9Im1haWx0bzppMm5z ZkBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOiM5NTRGNzIiPmkybnNmQGlldGYub3JnPC9z cGFuPjwvYT4mcXVvdDsNCiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmkybnNmQGlldGYub3JnIj48c3Bh biBzdHlsZT0iY29sb3I6Izk1NEY3MiI+aTJuc2ZAaWV0Zi5vcmc8L3NwYW4+PC9hPiZndDs8YnI+ DQo8L3NwYW4+PGI+PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OlNpbVN1bjttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+5Li76aKYPC9zcGFu PjwvYj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlJlOg0KIFtJMm5z Zl0gRGVmaW5pdGlvbiBmb3IgJnF1b3Q7TmV0d29yayBTZWN1cml0eSBGdW5jdGlvbnMmcXVvdDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTpTaW1TdW4iPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izk5MzMwMCI+R2l2ZW4gYWdy ZWVtZW50IGFyb3VuZCBEaWVnb+KAmXMgZGVmaW5pdGlvbiwgSSBiZWxpZXZlIGl0IGlzIHN1ZmZp Y2llbnQgdG8gc2F5IOKAnEZ1bmN0aW9ucyB0byBlbnN1cmUgdGhlIGNvbmZpZGVudGlhbGl0eSwg aW50ZWdyaXR5LCBhbmQgYXZhaWxhYmxlIG9mIG5ldHdvcmsgY29tbXVuaWNhdGlvbnMu4oCdIChQ dXR0aW5nJm5ic3A7DQogdGhlIENJQSBpbiB0aGUgdHJhZGl0aW9uYWwgb3JkZXIuKSBUaGUgc2Vj b25kIHBhcnQgKOKAnHRvIGRldGVjdCB1bndhbnRlZCBhY3Rpdml0eSwgYW5kIHRvIGRldGVyIGl0 IG9yIGF0IGxlYXN0IG1pdGlnYXRlIGl0cyBlZmZlY3RzIG9uIHRoZSBuZXR3b3Jr4oCdKSBhZGRz IG5vdGhpbmcgdGhhdCBpcyBub3QgYWxyZWFkeSBpbmNsdWRlZCBpbiB0aGUgZmlyc3QgcGFydCBi dXQgaW1wbGljaXRseSAoYnkgb21pc3Npb24pIGV4Y2x1ZGVzIHNvbWUgZnVuY3Rpb25zDQogKGUu Zy4sIHByZXZlbnRpdmUgZnVuY3Rpb25zKSB0aGF0IGFyZSAobm9ybWFsbHkpIGluY2x1ZGVkLjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OlNpbVN1biI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj5EYWNoZW5nOi8vIEkgdGhpbmsgQ0lBIGNhbm5vdCBy ZWFsbHkgdGFrZSBwbGFjZSBvZiB0aGUgc2Vjb25kIHBhcnQuIFRoZSBDSUEgaXMgYWJvdXQgZW5z dXJpbmcgZGF0YTwvc3Bhbj48c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6U2ltU3VuO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj7igJg8L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj5zZWN1 cmVseScNCiB0cmFuc3BvcnRlZCBvdmVyIHRoZSBuZXR3b3JrLiBUaGUgc2Vjb25kIHBhcnQgaXMg YWJvdXQgZGV0ZWN0aW5nIHRoZSBpbXByb3BlciBjb250ZW50IGluIHRoZSBkYXRhIG9yIGltcHJv cGVyIHNpZ25hbGluZyB3aGljaCBtYXkgYWZmZWN0IHRoZSBub3JtYWwgb3BlcmF0b3JzIG9mIG5l dHdvcmsgc3lzdGVtcy4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTpTaW1TdW4iPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 U2ltU3VuIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTpTaW1TdW4iPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6U2ltU3Vu Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM5OTMzMDAiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izk5 MzMwMCI+QnkgZXh0ZW5zaW9uLCBJIHdvdWxkIGFsc28gc2F5IHRoYXQgdGhlIGRlZmluaXRpb24g cGVyIGFib3ZlIGV4dGVuZHMgdG8gdGhlIHJlc291cmNlcyAoZGV2aWNlcywgYXBwbGljYXRpb25z LCBzZXJ2aWNlcykgbmVjZXNzYXJ5IHRvIHN1cHBvcnQgbmV0d29yayBjb21tdW5pY2F0aW9ucyDi gKYgc2luY2UgYSB2aW9sYXRpb24NCiBvZiBzZWN1cml0eSB0aGVyZSBoYXMgYSBwb3RlbnRpYWwg Jm5ic3A7dW5kZXNpcmVkIGVmZmVjdCBpbiB0aGUgbmV0d29yayB0cmFmZmljLjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izk5 MzMwMCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojOTkzMzAwIj5TbywgSSBtaWdodCBzdWdnZXN0IGFuIGV4dGVu c2lvbiBvZiB0aGUgZGVmaW5pdGlvbiB0byDigJxGdW5jdGlvbnMgdG8gZW5zdXJlIHRoZSBjb25m aWRlbnRpYWxpdHksIGludGVncml0eSwgYW5kIGF2YWlsYWJpbGl0eSBvZiBuZXR3b3JrIGNvbW11 bmljYXRpb25zIGFuZCB0aGUgcmVzb3VyY2VzIHVzZWQgdG8NCiBzdXBwb3J0IG5ldHdvcmsgY29t bXVuaWNhdGlvbnMu4oCdIOKApj88L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM5OTMzMDAiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izk5MzMw MCI+QXZhbnRpLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6Izk5MzMwMCI+Qm9iTjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izk5MzMwMCI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+STJuc2YNCiBbPGEgaHJlZj0ibWFpbHRvOmkybnNmLWJvdW5jZXNAaWV0Zi5v cmciPjxzcGFuIHN0eWxlPSJjb2xvcjojOTU0RjcyIj5tYWlsdG86aTJuc2YtYm91bmNlc0BpZXRm Lm9yZzwvc3Bhbj48L2E+XTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj48Yj5PbiBCZWhhbGYgT2Y8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+PC9iPkFsZXhleSBHb3JidW5vdjxicj4NCjxiPlNlbnQ6PC9iPjxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5Nb25kYXksIE1heSAy NSwgMjAxNSA2OjQyIFBNPGJyPg0KPGI+VG86PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86aTJuc2ZAaWV0Zi5vcmciPjxz cGFuIHN0eWxlPSJjb2xvcjojOTU0RjcyIj5pMm5zZkBpZXRmLm9yZzwvc3Bhbj48L2E+OyBMaW5k YSBEdW5iYXI8YnI+DQo8Yj5TdWJqZWN0OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVk LXNwYWNlIj4mbmJzcDs8L3NwYW4+W0kybnNmXSBEZWZpbml0aW9uIGZvciAmcXVvdDtOZXR3b3Jr IFNlY3VyaXR5IEZ1bmN0aW9ucyZxdW90Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIEFsbDxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SSBhZ3JlZSB3aXRoIERpZWdvIGRlZmluaXRpb246Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mcXVv dDtmdW5jdGlvbnMgdG8gZW5zdXJlIGludGVncml0eSwgY29uZmlkZW50aWFsaXR5IGFuZCBhdmFp bGFiaWxpdHkgb2YgbmV0d29yayBjb21tdW5pY2F0aW9ucywgdG8gZGV0ZWN0IHVud2FudGVkIGFj dGl2aXR5LCBhbmQgdG8gZGV0ZXIgaXQgb3IgYXQgbGVhc3QgbWl0aWdhdGUgaXRzIGVmZmVjdHMg b24gdGhlIG5ldHdvcmsmcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RnJvbSBteSBw b2ludCBvZiB2aWV3IHRoYXQgY292ZXJzIGFsbCBjYXNlcyBvZiBuZXR3b3JrIHNlY3VyaXR5IGZ1 bmN0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlZ2FyZGluZyBGbG93LWJhc2VkIG5ldHdvcmsg c2VjdXJpdHkgZnVuY3Rpb246PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj7igJwgQSBmdW5jdGlvbiB0aGF0 IGluc3BlY3RzIG5ldHdvcmsgZmxvd3MgYWNjb3JkaW5nIHRvIGEgcG9saWN5IGludGVuZGVkIGZv ciBlbmZvcmNpbmcgc2VjdXJpdHkgcHJvcGVydGllcy4mbmJzcDsgRmxvdy1iYXNlZCBzZWN1cml0 eSBhbHNvIG1lYW5zIHRoYXQgcGFja2V0cyBhcmUgaW5zcGVjdGVkIGluIHRoZSBvcmRlciB0aGV5 IGFyZSByZWNlaXZlZCwgYW5kIHdpdGhvdXQgbW9kaWZpY2F0aW9uIHRvIHRoZSBwYWNrZXQNCiBk dWUgdG8gdGhlIGluc3BlY3Rpb24gcHJvY2VzcyAoTUFDIHJld3JpdGVzLCBUVEwgZGVjcmVtZW50 IGFjdGlvbjsgZXZlbiBOQVQgd291bGQgYmUgb3V0c2lkZSB0aGUgaW5zcGVjdGlvbiBwcm9jZXNz KS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSdtIG5vdCBzdXJlIGlmIGl0J3MgdmFsdWFi bGUgJm5ic3A7dG8gaW5zcGVjdCBwYWNrZXQgd2l0aG91dCBtb2RpZmljYXRpb24uIFRoZXJlIGFy ZSBjYXNlcyB3aGVuIGl0J3MgbW9yZSBwcmVmZXJhYmxlIHRvIGluc3BlY3QgYW5kIGFwcGx5IHBv bGljeSBhZnRlciBOQVQuJm5ic3A7IFRoaXMgaXMgY29tbW9uIHByYWN0aWNlIGFuZCBpdCBtdXN0 IGJlIGEgZ29vZCByZWFzb24gdG8gY2hhbmdlIGl0LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5CciwgQWxleGV5IEdvcmJ1bm92PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UZWxjbyBDbG91ZCBhbmQgU2Vj dXJpdHkgQXJjaGl0ZWN0IGF0IE5va2lhPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DQ0lFIFImYW1wO1MgNDEwODg8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OlNpbVN1biI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18gSTJuc2YgbWFpbGluZyBsaXN0PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpJMm5zZkBpZXRmLm9yZyI+PHNwYW4g c3R5bGU9ImNvbG9yOiM5NTRGNzIiPkkybnNmQGlldGYub3JnPC9zcGFuPjwvYT48YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2kybnNmIj48c3BhbiBzdHlsZT0i Y29sb3I6Izk1NEY3MiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pMm5z Zjwvc3Bhbj48L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0x1 Y2lkYUdyYW5kZSZxdW90OyxzZXJpZiI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQpJMm5zZiBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWls dG86STJuc2ZAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjojOTU0RjcyIj5JMm5zZkBpZXRm Lm9yZzwvc3Bhbj48L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9pMm5zZiI+PHNwYW4gc3R5bGU9ImNvbG9yOiM5NTRGNzIiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaTJuc2Y8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4tLTxicj4NCiZxdW90O0VzdGEgdmV6IG5v IGZhbGxhcmVtb3MsIERvY3RvciBJbmZpZXJubyZxdW90Ozxicj4NCjxicj4NCkRyIERpZWdvIFIu IExvcGV6PGJyPg0KVGVsZWZvbmljYSBJJiM0MztEPGJyPg0KPGEgaHJlZj0iaHR0cDovL3Blb3Bs ZS50aWQuZXMvZGllZ28ubG9wZXovIj5odHRwOi8vcGVvcGxlLnRpZC5lcy9kaWVnby5sb3Blei88 L2E+PGJyPg0KPGJyPg0KZS1tYWlsOiA8YSBocmVmPSJtYWlsdG86ZGllZ28uci5sb3BlekB0ZWxl Zm9uaWNhLmNvbSI+ZGllZ28uci5sb3BlekB0ZWxlZm9uaWNhLmNvbTwvYT48YnI+DQpUZWw6ICZu YnNwOyAmbmJzcDsmIzQzOzM0IDkxMyAxMjkgMDQxPGJyPg0KTW9iaWxlOiAmIzQzOzM0IDY4MiAw NTEgMDkxPGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0 ZXh0LWFsaWduOmNlbnRlciI+DQo8aHIgc2l6ZT0iMyIgd2lkdGg9IjEwMCUiIGFsaWduPSJjZW50 ZXIiPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Z3Jh eSI+PGJyPg0KRXN0ZSBtZW5zYWplIHkgc3VzIGFkanVudG9zIHNlIGRpcmlnZW4gZXhjbHVzaXZh bWVudGUgYSBzdSBkZXN0aW5hdGFyaW8sIHB1ZWRlIGNvbnRlbmVyIGluZm9ybWFjacOzbiBwcml2 aWxlZ2lhZGEgbyBjb25maWRlbmNpYWwgeSBlcyBwYXJhIHVzbyBleGNsdXNpdm8gZGUgbGEgcGVy c29uYSBvIGVudGlkYWQgZGUgZGVzdGluby4gU2kgbm8gZXMgdXN0ZWQuIGVsIGRlc3RpbmF0YXJp byBpbmRpY2FkbywgcXVlZGEgbm90aWZpY2FkbyBkZSBxdWUgbGENCiBsZWN0dXJhLCB1dGlsaXph Y2nDs24sIGRpdnVsZ2FjacOzbiB5L28gY29waWEgc2luIGF1dG9yaXphY2nDs24gcHVlZGUgZXN0 YXIgcHJvaGliaWRhIGVuIHZpcnR1ZCBkZSBsYSBsZWdpc2xhY2nDs24gdmlnZW50ZS4gU2kgaGEg cmVjaWJpZG8gZXN0ZSBtZW5zYWplIHBvciBlcnJvciwgbGUgcm9nYW1vcyBxdWUgbm9zIGxvIGNv bXVuaXF1ZSBpbm1lZGlhdGFtZW50ZSBwb3IgZXN0YSBtaXNtYSB2w61hIHkgcHJvY2VkYSBhIHN1 IGRlc3RydWNjacOzbi48YnI+DQo8YnI+DQpUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRo aXMgdHJhbnNtaXNzaW9uIGlzIHByaXZpbGVnZWQgYW5kIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlv biBpbnRlbmRlZCBvbmx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSBu YW1lZCBhYm92ZS4gSWYgdGhlIHJlYWRlciBvZiB0aGlzIG1lc3NhZ2UgaXMgbm90IHRoZSBpbnRl bmRlZCByZWNpcGllbnQsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IGRpc3NlbWlu YXRpb24sDQogZGlzdHJpYnV0aW9uIG9yIGNvcHlpbmcgb2YgdGhpcyBjb21tdW5pY2F0aW9uIGlz IHN0cmljdGx5IHByb2hpYml0ZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgdHJhbnNtaXNz aW9uIGluIGVycm9yLCBkbyBub3QgcmVhZCBpdC4gUGxlYXNlIGltbWVkaWF0ZWx5IHJlcGx5IHRv IHRoZSBzZW5kZXIgdGhhdCB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4g ZXJyb3IgYW5kIHRoZW4gZGVsZXRlIGl0Ljxicj4NCjxicj4NCkVzdGEgbWVuc2FnZW0gZSBzZXVz IGFuZXhvcyBzZSBkaXJpZ2VtIGV4Y2x1c2l2YW1lbnRlIGFvIHNldSBkZXN0aW5hdMOhcmlvLCBw b2RlIGNvbnRlciBpbmZvcm1hw6fDo28gcHJpdmlsZWdpYWRhIG91IGNvbmZpZGVuY2lhbCBlIMOp IHBhcmEgdXNvIGV4Y2x1c2l2byBkYSBwZXNzb2Egb3UgZW50aWRhZGUgZGUgZGVzdGluby4gU2Ug bsOjbyDDqSB2b3NzYSBzZW5ob3JpYSBvIGRlc3RpbmF0w6FyaW8gaW5kaWNhZG8sIGZpY2Egbm90 aWZpY2FkbyBkZSBxdWUgYQ0KIGxlaXR1cmEsIHV0aWxpemHDp8OjbywgZGl2dWxnYcOnw6NvIGUv b3UgY8OzcGlhIHNlbSBhdXRvcml6YcOnw6NvIHBvZGUgZXN0YXIgcHJvaWJpZGEgZW0gdmlydHVk ZSBkYSBsZWdpc2xhw6fDo28gdmlnZW50ZS4gU2UgcmVjZWJldSBlc3RhIG1lbnNhZ2VtIHBvciBl cnJvLCByb2dhbW9zLWxoZSBxdWUgbm9zIG8gY29tdW5pcXVlIGltZWRpYXRhbWVudGUgcG9yIGVz dGEgbWVzbWEgdmlhIGUgcHJvY2VkYSBhIHN1YSBkZXN0cnVpw6fDo288L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_CY1PR09MB0922D2B703F55543F1EDC94DA8CC0CY1PR09MB0922namp_-- From nobody Tue May 26 07:01:33 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ED361B2EA0 for ; Tue, 26 May 2015 07:01:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.702 X-Spam-Level: X-Spam-Status: No, score=0.702 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GeDHDQZgtB1v for ; Tue, 26 May 2015 07:01:26 -0700 (PDT) Received: from out4133-130.mail.aliyun.com (out4133-130.mail.aliyun.com [42.120.133.130]) by ietfa.amsl.com (Postfix) with ESMTP id 472C51B2E7C for ; Tue, 26 May 2015 07:01:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1432648879; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=PDlLhBG7TGl+73E1RDO0maPI5v1p+8O3QKH45/R0Gu4=; b=Ggc/ulrkuaudX9kLrVY3ghmVgWFZs0xlsrkKUzMxxcq9LKj4aRTEgl1J2PapPU1p3XqCUe4o8Ppf6C3EHZRbXc6kV/JxycFYmEdPrpYV5AOcVIcS7LSVVWyLwhF+US/RgsmYVUi128XPo5NX7BOixB3YfqO8MrD3EZNy/S7fTjo= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R101e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=r41f05041; MF=dacheng.zdc@alibaba-inc.com; PH=DS; RN=5; RT=5; SR=0; Received: from 10.22.62.16(mailfrom:dacheng.zdc@alibaba-inc.com ip:42.120.73.208) by smtp.aliyun-inc.com(127.0.0.1); Tue, 26 May 2015 22:01:14 +0800 User-Agent: Microsoft-MacOutlook/14.5.0.150423 Date: Tue, 26 May 2015 22:01:09 +0800 From: "Dacheng Zhang" To: "Natale, Bob" , DIEGO LOPEZ GARCIA Message-ID: Thread-Topic: [I2nsf] Definition for "Network Security Functions" References: <241A3C3B-E261-4E27-9BBD-B4925179C1F9@telefonica.com> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3515522474_6640406" Archived-At: Cc: "i2nsf@ietf.org" , Alexey Gorbunov , Linda Dunbar Subject: Re: [I2nsf] Definition for "Network Security Functions" X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 14:01:32 -0000 > ´ËÓʼþʹÓà MIME ¸ñʽ¡£ÓÉÓÚÓʼþÔĶÁ³ÌÐò²»ÄÜʶ±ð ´Ë¸ñʽ£¬Òò´Ë£¬¿ÉÄÜÎÞ·¨Ê¶±ð¸ÃÓʼþµÄ·Ö²¿»ò²¿·ÖÄÚÈÝ¡£ --B_3515522474_6640406 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Make a lot of sense. Thanks Bob and Diego for clarifying it. Cheers Dacheng =E5=8F=91=E4=BB=B6=E4=BA=BA: "Natale, Bob" =E6=97=A5=E6=9C=9F: 2015=E5=B9=B45=E6=9C=8826=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=BA=8C =E4=B8=8B=E5=8D=889:01 =E8=87=B3: DIEGO LOPEZ GARCIA =E6=8A=84=E9=80=81: "i2nsf@ietf.org" , Alexey Gorbunov , dacheng de , Linda Dunbar =E4=B8=BB=E9=A2=98: RE: [I2nsf] Definition for "Network Security Functions" Agreed. =20 Avanti, BobN =20 From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of DIEGO LOPEZ GARCIA Sent: Tuesday, May 26, 2015 4:07 AM To: Natale, Bob Cc: i2nsf@ietf.org; Alexey Gorbunov; Dacheng Zhang; Linda Dunbar Subject: Re: [I2nsf] Definition for "Network Security Functions" =20 Hi Bob,=20 =20 Having spent my professional life trying to apply good-ole Friar William's razor, I agree the shorter version you propose would be correct and complete. But according to my experience I think it would be good to leave the second part ask well in order to avoid misunderstandings like the concern expressed by Dacheng. =20 There is a value in being somehow redundant if it is the price you pay to avoid misconception. =20 Be goode, =20 On 26 May 2015, at 05:42 , Natale, Bob wrote: > Hi Dacheng, >=20 > =20 >=20 > I guess it depends on what sources you rely on for the underlying definit= ions. > I referenced NIST Special Publication 800-53 Revision 4, Security and Pri= vacy > Controls for Federal Information Systems and Organizations. While there a= re > numerous existence proofs in 800-53 to refute your assertion below with > respect to detection, I would just point to the definition of AC-4, > Information Flow Enforcement, in Appendix F, Security Control Catalog, > especially enhancement clauses (3) and (15). As I said, there are many ot= hers. >=20 > =20 >=20 > Of course, it could be that 800-53 is not an acceptable source for > foundational definitions for I2NSF. >=20 > =20 >=20 > Avanti, >=20 > BobN >=20 > =20 >=20 > From: I2nsf [mailto:i2nsf-bounces@ietf.org ] > On Behalf Of Dacheng Zhang > Sent: Monday, May 25, 2015 11:02 PM > To: Natale, Bob; Alexey Gorbunov; Linda Dunbar > Cc: i2nsf@ietf.org > Subject: Re: [I2nsf] Definition for "Network Security Functions" >=20 > =20 >=20 > =20 >=20 > =20 >=20 > =E5=8F=91=E4=BB=B6=E4=BA=BA: "Natale, Bob" > > =E6=97=A5=E6=9C=9F: 2015=E5=B9=B45=E6=9C=8826=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=BA=8C =E4=B8=8A=E5=8D=8810:55 > =E8=87=B3: Alexey Gorbunov >, Linda Dunbar > > =E6=8A=84=E9=80=81: "i2nsf@ietf.org " > > =E4=B8=BB=E9=A2=98: Re: [I2nsf] Definition for "Network Security Functions" >=20 > =20 >=20 > Given agreement around Diego=E2=80=99s definition, I believe it is sufficient t= o say > =E2=80=9CFunctions to ensure the confidentiality, integrity, and available of n= etwork > communications.=E2=80=9D (Putting the CIA in the traditional order.) The secon= d part > (=E2=80=9Cto detect unwanted activity, and to deter it or at least mitigate its > effects on the network=E2=80=9D) adds nothing that is not already included in t= he > first part but implicitly (by omission) excludes some functions (e.g., > preventive functions) that are (normally) included. >=20 > =20 >=20 > Dacheng:// I think CIA cannot really take place of the second part. The C= IA is > about ensuring data=E2=80=98securely' transported over the network. The second = part is > about detecting the improper content in the data or improper signaling wh= ich > may affect the normal operators of network systems. >=20 > =20 >=20 > =20 >=20 > =20 >=20 > =20 >=20 > =20 >=20 > =20 >=20 > =20 >=20 > By extension, I would also say that the definition per above extends to t= he > resources (devices, applications, services) necessary to support network > communications =E2=80=A6 since a violation of security there has a potential > undesired effect in the network traffic. >=20 > =20 >=20 > So, I might suggest an extension of the definition to =E2=80=9CFunctions to ens= ure the > confidentiality, integrity, and availability of network communications an= d the > resources used to support network communications.=E2=80=9D =E2=80=A6? >=20 > =20 >=20 > Avanti, >=20 > BobN >=20 > =20 >=20 > From: I2nsf [mailto:i2nsf-bounces@ietf.org ] > On Behalf Of Alexey Gorbunov > Sent: Monday, May 25, 2015 6:42 PM > To: i2nsf@ietf.org ; Linda Dunbar > Subject: [I2nsf] Definition for "Network Security Functions" >=20 > =20 >=20 > Hi All >=20 > =20 >=20 > I agree with Diego definition: >=20 > "functions to ensure integrity, confidentiality and availability of netwo= rk > communications, to detect unwanted activity, and to deter it or at least > mitigate its effects on the network" >=20 > =20 >=20 > From my point of view that covers all cases of network security function. >=20 > =20 >=20 > Regarding Flow-based network security function: >=20 > =20 >=20 > =E2=80=9C A function that inspects network flows according to a policy intended= for > enforcing security properties. Flow-based security also means that packe= ts > are inspected in the order they are received, and without modification to= the > packet due to the inspection process (MAC rewrites, TTL decrement action;= even > NAT would be outside the inspection process). >=20 > =20 >=20 > I'm not sure if it's valuable to inspect packet without modification. Th= ere > are cases when it's more preferable to inspect and apply policy after NAT= . > This is common practice and it must be a good reason to change it. >=20 > =20 >=20 > Br, Alexey Gorbunov >=20 > Telco Cloud and Security Architect at Nokia >=20 > CCIE R&S 41088 >=20 > =20 >=20 > =20 >=20 > =20 >=20 > =20 >=20 > =20 >=20 > _______________________________________________ I2nsf mailing list > I2nsf@ietf.org > https://www.ietf.org/mailman/listinfo/i2nsf > > _______________________________________________ > I2nsf mailing list > I2nsf@ietf.org > https://www.ietf.org/mailman/listinfo/i2nsf > =20 -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego.r.lopez@telefonica.com Tel: +34 913 129 041 Mobile: +34 682 051 091 ---------------------------------- =20 =20 Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener informaci=C3=B3n 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=C3=B3n, divulgaci=C3=B3n y/o copia sin autorizaci=C3=B3n puede estar prohibida en virtud de= la legislaci=C3=B3n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma v=C3=ADa y proceda a su destrucci=C3=B3n. 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=C3=A1rio, pode conter informa=C3=A7=C3=A3o privilegiada ou confidencial e =C3=A9 para uso exclusi= vo da pessoa ou entidade de destino. Se n=C3=A3o =C3=A9 vossa senhoria o destinat=C3=A1rio indicado, fica notificado de que a leitura, utiliza=C3=A7=C3=A3o, divulga=C3=A7=C3=A3o e/ou c=C3=B3pia sem autoriza=C3=A7=C3=A3o pode estar proibida em virtude da legisla=C3=A7=C3=A3o vig= ente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destrui=C3=A7=C3=A3o --B_3515522474_6640406 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable
Make a lot of sense. Thanks Bo= b and Diego for clarifying it. 

Cheers

Dacheng

=E5=8F= =91=E4=BB=B6=E4=BA=BA: "Natale, Bob" <RNATAL= E@mitre.org>
=E6=97=A5=E6=9C=9F: 2015=E5=B9= =B45=E6=9C=8826=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=BA=8C =E4=B8=8B=E5=8D=889:01
=E8=87=B3: DIEGO LOPEZ GARCIA <dieg= o.r.lopez@telefonica.com>
=E6=8A=84=E9=80=81: <= /span> "i2nsf@ietf.org" <i2nsf@ietf.org>, Alexey Gorbunov <alexey.gorbunov82@gmail.com>, dachen= g de <dacheng.zdc@alibaba-in= c.com>, Linda Dunbar <lin= da.dunbar@huawei.com>
=E4=B8=BB=E9=A2=98: RE: [I2nsf] Definition for "Network Security Functions"

Agreed.

=

 

Avanti,

BobN

 

From: I2nsf [<= a href=3D"mailto:i2nsf-bounces@ietf.org">mailto:i2nsf-bounces@ietf.org] On Behalf Of DIEGO LOPEZ GARCIA
Sent: Tuesday, May 26, 201= 5 4:07 AM
To: Natale, Bob
Cc: i2nsf@ietf.org; Alexey Gorbunov; Dacheng Zhang; Linda Dunbar
Subject: Re: [I2nsf] Definition for "Network Security Functions"

 

Hi Bob,

 

Having spent my professional life tr= ying to apply good-ole Friar William's razor, I agree the shorter version yo= u propose would be correct and complete. But according to my experience I th= ink it would be good to leave the second part ask well in order to avoid misunderstandings like the concern expressed by Dac= heng.

 

There is a value in being somehow redundant if = it is the price you pay to avoid misconception.

 

Be go= ode,

 

On 26 May 2015, at 05:42 , Natale, Bob <RNATALE@mitre.org> wrote:

=



Hi Dacheng,=

 

I guess it depends on what sources you rely on for th= e underlying definitions. I referenced NIST Special Publication 800-53 Revis= ion 4, Security and Privacy Controls for Federal Information Systems and Organizations. While there are numerous existence = proofs in 800-53 to refute your assertion below with respect to detection, I= would just point to the definition of AC-4, Information Flow Enforcement, i= n Appendix F, Security Control Catalog, especially enhancement clauses (3) and (15). As I said, there are= many others.

 =

Of course, it could be that 800-5= 3 is not an acceptable source for foundational definitions for I2NSF.=

 

Avanti,

BobN

 <= /span>

From: I2nsf [mailt= o:i2nsf-bounces@ietf.org]&nbs= p;On Behalf Of Dacheng Zhang
Sent: Monday, May 25, 2015 11:02 PM
To: Natale, Bob; Alexey Gorbunov; Linda Dunbar
Cc:<= span class=3D"apple-converted-space"> i2nsf@ietf.org
Subject:=  Re: [I2nsf] Definition for = "Network Security Functions"

 

=  

=

 <= /o:p>

=E5=8F=91=E4=BB=B6= =E4=BA=BA: "Natale, Bob" <RN= ATALE@mitre.org>
=E6=97=A5=E6=9C=9F<= b>: 2015=E5=B9=B4= 5=E6=9C=8826=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=BA=8C<= span style=3D"font-size: 11pt; font-family: Calibri, sans-serif;"> =E4=B8=8A=E5=8D=8810:55
=E8=87=B3: Alexey Gorbunov <alexey.gorbunov82@gmail.com>, Linda Dunbar <linda.dunb= ar@huawei.com>
=E6=8A=84=E9=80=81= : "i2nsf@ietf.org" <i2nsf@ietf= .org>
=E4=B8=BB=E9=A2=98: Re: [I2nsf] Definition for "Network Security Functions"

<= /div>

 

Given agreement around Diego’s definition, I believe it is suff= icient to say “Functions to ensure the confidentiality, integrity, and= available of network communications.” (Putting  the CIA in the traditional order.) The second part (“to detect unwan= ted activity, and to deter it or at least mitigate its effects on the networ= k”) adds nothing that is not already included in the first part but im= plicitly (by omission) excludes some functions (e.g., preventive functions) that are (normally) included.

 

Dacheng:= // I think CIA cannot really take place of the second part. The CIA is about= ensuring data‘securely' transported over the network. The second part is about detecting the impro= per content in the data or improper signaling which may affect the normal op= erators of network systems. 

&nbs= p;

 

<= /div>

 

 

 

 <= /span>

 

By extension, I would also say that = the definition per above extends to the resources (devices, applications, se= rvices) necessary to support network communications … since a violatio= n of security there has a potential  undesired effect in the network tr= affic.

 

So, I might suggest an extension of the = definition to “Functions to ensure the confidentiality, integrity, and= availability of network communications and the resources used to support network communications.” …?

 

Avanti,

BobN=

 

From: <= span style=3D"font-size: 11pt; font-family: Calibri, sans-serif;">I2nsf [mailt= o:i2nsf-bounces@ietf.org]&nbs= p;On Behalf Of Alexey Gorbunov
Sent: Monday, May 25, 2015 6:42 PM
To: i2nsf@ietf.org; Linda Dunbar
Subject: [I2nsf] Definition for "Network Security = Functions"

 <= /o:p>

Hi All

 

I agree with Diego definition: 

"functions to ensure integrity, confidenti= ality and availability of network communications, to detect unwanted activit= y, and to deter it or at least mitigate its effects on the network"

 

=

From my point of view that covers all c= ases of network security function.

 

R= egarding Flow-based network security function:

 

“ A function that inspects network flows according to a poli= cy intended for enforcing security properties.  Flow-based security als= o means that packets are inspected in the order they are received, and witho= ut modification to the packet due to the inspection process (MAC rewrites, TTL decrement action; even NA= T would be outside the inspection process).

<= div>

 

I'm not sure if it's valuable  to inspect packet without m= odification. There are cases when it's more preferable to inspect and apply = policy after NAT.  This is common practice and it must be a good reason= to change it. 

 

Br, Alexey= Gorbunov

Telco Clo= ud and Security Architect at Nokia

CCIE R&S 41088

 

 

 

 

 =

__________________________________________= _____ I2nsf mailing list I2nsf@ietf.orghttps://www.ietf.org/mailman/listinfo/i2nsf

_______________________________________________=
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listi= nfo/i2nsf

 

--
"Esta vez no fallaremos, Doctor Infierno"

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

e-mail: diego.r.lopez@telefon= ica.com
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------

 

 


Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=C3=B3n privilegiada o confidencial y es para uso exclusiv= o de la persona o entidad de destino. Si no es usted. el destinatario indica= do, queda notificado de que la lectura, utilizaci=C3=B3n, divulgaci=C3=B3n y/o copia sin autorizaci=C3=B3n puede esta= r prohibida en virtud de la legislaci=C3=B3n vigente. Si ha recibido este mensaj= e por error, le rogamos que nos lo comunique inmediatamente por esta misma v= =C3=ADa y proceda a su destrucci=C3=B3n.

The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named a= bove. If the reader of this message is not the intended recipient, you are h= ereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If y= ou have received this transmission in error, do not read it. Please immediat= ely reply to the sender that you have received this communication in error a= nd then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=C3=A1rio,= pode conter informa=C3=A7=C3=A3o privilegiada ou confidencial e =C3=A9 para uso exclusi= vo da pessoa ou entidade de destino. Se n=C3=A3o =C3=A9 vossa senhoria o destinat=C3=A1r= io indicado, fica notificado de que a leitura, utiliza=C3=A7=C3=A3o, divulga=C3=A7=C3=A3o e/ou c=C3=B3pia sem autoriza=C3=A7=C3=A3o pode est= ar proibida em virtude da legisla=C3=A7=C3=A3o vigente. Se recebeu esta mensagem por= erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e pr= oceda a sua destrui=C3=A7=C3=A3o

 --B_3515522474_6640406-- From nobody Tue May 26 09:13:54 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 981E91B2ACD for ; Tue, 26 May 2015 09:08:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pg0ohBFTlXzR for ; Tue, 26 May 2015 09:08:40 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36D7A1B2BCF for ; Tue, 26 May 2015 09:08:34 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BSZ25072; Tue, 26 May 2015 16:08:29 +0000 (GMT) Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 26 May 2015 17:08:28 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml702-chm ([10.193.5.72]) with mapi id 14.03.0158.001; Tue, 26 May 2015 09:08:18 -0700 From: Linda Dunbar To: "'Romascanu, Dan (Dan)'" , "'Joseph Salowey'" , "'DIEGO LOPEZ GARCIA'" , John Strassner , Susan Hares , "Zarny, Myo" , "i2nsf@ietf.org" Thread-Topic: Interim Meeting to reach consensus on I2NSF charter, and discuss if the problem & framework drafts reflect the updated I2NSF charter Thread-Index: AdCSfWPU26bik8y7TtGAxr7qFzwsDQ== Date: Tue, 26 May 2015 16:08:17 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657C4BB08@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.128.195] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657C4BB08dfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-Mailman-Approved-At: Tue, 26 May 2015 09:13:51 -0700 Cc: "Mahmoudi, Charif" , Hesham ElBakoury , Edward Lopez , Dean Bogdanovic , "pjs@etri.re.kr" , 'Rich Groves' , "Henderickx, Wim \(Wim\)" , Zu Qiang Subject: [I2nsf] Interim Meeting to reach consensus on I2NSF charter, and discuss if the problem & framework drafts reflect the updated I2NSF charter X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 16:08:41 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F657C4BB08dfweml701chm_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable When: Tuesday, May 26, 2015 1:30 PM-3:00 PM (UTC-06:00) Central Time (US & = Canada). Where: WebEx Note: The GMT offset above does not reflect daylight saving time adjustment= s. *~*~*~*~*~*~*~*~*~* In order to get ready for a successful I2NSF BOF at IETF93, we plan have a = couple of interim meetings to discuss the following items: * Reach consensus on the I2NSF charter * Go through the problem statement draft, and make sure it is consist= ent with the narrower scoped I2NSF charter. * Go through the framework draft, and make sure it is consistent with= the narrower scoped I2NSF charter. Here is the conference bridge: Join WebEx meeting Meeting number: 647 424 137 Meeting password: 1234 Join by phone 1-877-668-4493 Call-in toll free number (US/Canada) 1-650-479-3208 Call-in toll number (US/Canada) Access code: 647 424 137 Toll-free calling restrictions Can't join the meeting? Contact support. IMPORTANT NOTICE: Please note that this WebEx service allows audio and othe= r information sent during the session to be recorded, which may be discover= able in a legal matter. By joining this session, you automatically consent = to such recordings. If you do not consent to being recorded, discuss your c= oncerns with the host or do not join the session. Linda --_000_4A95BA014132FF49AE685FAB4B9F17F657C4BB08dfweml701chm_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
When: Tuesday, May 26, 2015 1:30 PM-3:00 PM (UTC-06:00) Central Time (= US & Canada).
Where: WebEx
 
Note: The GMT offset above does not reflect daylight saving time adjus= tments.
 
*~*~*~*~*~*~*~*~*~*
 
In order to get ready for a successful I2NSF BOF at IETF93, we plan ha= ve a couple of interim meetings to discuss the following items:
 
  • Reach consensus on the I2NSF charter
  • Go through the problem sta= tement draft, and make sure it is consistent with the narrower scoped I2NSF= charter.
  • Go through the framework draft, and make sure it is cons= istent with the narrower scoped I2NSF charter.
 
 
Here is the conference bridge:
 
Meeting number:  647 424 137     
Meeting password:       1234 = ;  
 <= br>  
Join by = phone 
1-877-668-4493 Call-in toll free number (US/Canada)=  
1-650-479-3208 Call-in toll number (US/Canada) 
Access code: 647 424 137 
Toll-free calling restrictions<= font size=3D"4">  


 
Can't join the meeting? Contact support.  
 
IMPORTANT NOTICE: Please note that this WebEx servi= ce allows audio and other information sent during the session to be recorde= d, which may be discoverable in a legal matter. By joining this session, yo= u automatically consent to such recordings. If you do not consent to being recorded, discuss your concerns with the hos= t or do not join the session.
 
 
Linda
 
 --_000_4A95BA014132FF49AE685FAB4B9F17F657C4BB08dfweml701chm_ Content-Type: text/calendar; charset="utf-8"; method=REQUEST Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSDQpNRVRIT0Q6UkVRVUVTVA0KUFJPRElEOk1pY3Jvc29mdCBFeGNoYW5n ZSBTZXJ2ZXIgMjAxMA0KVkVSU0lPTjoyLjANCkJFR0lOOlZUSU1FWk9ORQ0KVFpJRDpDZW50cmFs IFN0YW5kYXJkIFRpbWUNCkJFR0lOOlNUQU5EQVJEDQpEVFNUQVJUOjE2MDEwMTAxVDAyMDAwMA0K VFpPRkZTRVRGUk9NOi0wNTAwDQpUWk9GRlNFVFRPOi0wNjAwDQpSUlVMRTpGUkVRPVlFQVJMWTtJ TlRFUlZBTD0xO0JZREFZPTFTVTtCWU1PTlRIPTExDQpFTkQ6U1RBTkRBUkQNCkJFR0lOOkRBWUxJ R0hUDQpEVFNUQVJUOjE2MDEwMTAxVDAyMDAwMA0KVFpPRkZTRVRGUk9NOi0wNjAwDQpUWk9GRlNF VFRPOi0wNTAwDQpSUlVMRTpGUkVRPVlFQVJMWTtJTlRFUlZBTD0xO0JZREFZPTJTVTtCWU1PTlRI PTMNCkVORDpEQVlMSUdIVA0KRU5EOlZUSU1FWk9ORQ0KQkVHSU46VkVWRU5UDQpPUkdBTklaRVI7 Q049TGluZGEgRHVuYmFyOk1BSUxUTzpsaW5kYS5kdW5iYXJAaHVhd2VpLmNvbQ0KQVRURU5ERUU7 Uk9MRT1SRVEtUEFSVElDSVBBTlQ7UEFSVFNUQVQ9TkVFRFMtQUNUSU9OO1JTVlA9VFJVRTtDTj0i J1JvbWFzY2FudQ0KICwgRGFuIChEYW4pJyI6TUFJTFRPOmRyb21hc2NhQGF2YXlhLmNvbQ0KQVRU RU5ERUU7Uk9MRT1SRVEtUEFSVElDSVBBTlQ7UEFSVFNUQVQ9TkVFRFMtQUNUSU9OO1JTVlA9VFJV RTtDTj0nSm9zZXBoIFNhDQogbG93ZXknOk1BSUxUTzpqb2VAc2Fsb3dleS5uZXQNCkFUVEVOREVF O1JPTEU9UkVRLVBBUlRJQ0lQQU5UO1BBUlRTVEFUPU5FRURTLUFDVElPTjtSU1ZQPVRSVUU7Q049 J0RJRUdPIExPUA0KIEVaIEdBUkNJQSc6TUFJTFRPOmRpZWdvLnIubG9wZXpAdGVsZWZvbmljYS5j b20NCkFUVEVOREVFO1JPTEU9UkVRLVBBUlRJQ0lQQU5UO1BBUlRTVEFUPU5FRURTLUFDVElPTjtS U1ZQPVRSVUU7Q049Sm9obiBTdHJhcw0KIHNuZXI6TUFJTFRPOkpvaG4uc2MuU3RyYXNzbmVyQGh1 YXdlaS5jb20NCkFUVEVOREVFO1JPTEU9UkVRLVBBUlRJQ0lQQU5UO1BBUlRTVEFUPU5FRURTLUFD VElPTjtSU1ZQPVRSVUU7Q049U3VzYW4gSGFyZQ0KIHM6TUFJTFRPOnNoYXJlc0BuZHpoLmNvbQ0K QVRURU5ERUU7Uk9MRT1SRVEtUEFSVElDSVBBTlQ7UEFSVFNUQVQ9TkVFRFMtQUNUSU9OO1JTVlA9 VFJVRTtDTj0iWmFybnksIE15byINCiA6TUFJTFRPOk15by5aYXJueUBncy5jb20NCkFUVEVOREVF O1JPTEU9UkVRLVBBUlRJQ0lQQU5UO1BBUlRTVEFUPU5FRURTLUFDVElPTjtSU1ZQPVRSVUU7Q049 aTJuc2ZAaWV0Zg0KIC5vcmc6TUFJTFRPOmkybnNmQGlldGYub3JnDQpBVFRFTkRFRTtST0xFPU9Q VC1QQVJUSUNJUEFOVDtQQVJUU1RBVD1ORUVEUy1BQ1RJT047UlNWUD1UUlVFO0NOPSdSaWNoIEdy b3YNCiBlcyc6TUFJTFRPOlJHcm92ZXNAYTEwbmV0d29ya3MuY29tDQpBVFRFTkRFRTtST0xFPU9Q VC1QQVJUSUNJUEFOVDtQQVJUU1RBVD1ORUVEUy1BQ1RJT047UlNWUD1UUlVFO0NOPUhlc2hhbSBF bEINCiBha291cnk6TUFJTFRPOkhlc2hhbS5FbEJha291cnlAaHVhd2VpLmNvbQ0KQVRURU5ERUU7 Uk9MRT1PUFQtUEFSVElDSVBBTlQ7UEFSVFNUQVQ9TkVFRFMtQUNUSU9OO1JTVlA9VFJVRTtDTj1w anNAZXRyaS5yDQogZS5rcjpNQUlMVE86cGpzQGV0cmkucmUua3INCkFUVEVOREVFO1JPTEU9T1BU LVBBUlRJQ0lQQU5UO1BBUlRTVEFUPU5FRURTLUFDVElPTjtSU1ZQPVRSVUU7Q049RWR3YXJkIExv cA0KIGV6Ok1BSUxUTzplbG9wZXpAZm9ydGluZXQuY29tDQpBVFRFTkRFRTtST0xFPU9QVC1QQVJU SUNJUEFOVDtQQVJUU1RBVD1ORUVEUy1BQ1RJT047UlNWUD1UUlVFO0NOPSJNYWhtb3VkaSwgDQog Q2hhcmlmIjpNQUlMVE86Y2hhcmlmLm1haG1vdWRpQG5pc3QuZ292DQpBVFRFTkRFRTtST0xFPU9Q VC1QQVJUSUNJUEFOVDtQQVJUU1RBVD1ORUVEUy1BQ1RJT047UlNWUD1UUlVFO0NOPVp1IFFpYW5n Ok0NCiBBSUxUTzp6dS5xaWFuZ0Blcmljc3Nvbi5jb20NCkFUVEVOREVFO1JPTEU9T1BULVBBUlRJ Q0lQQU5UO1BBUlRTVEFUPU5FRURTLUFDVElPTjtSU1ZQPVRSVUU7Q049IkhlbmRlcmlja3gNCiAs IFdpbSAoV2ltKSI6TUFJTFRPOndpbS5oZW5kZXJpY2t4QGFsY2F0ZWwtbHVjZW50LmNvbQ0KQVRU RU5ERUU7Uk9MRT1PUFQtUEFSVElDSVBBTlQ7UEFSVFNUQVQ9TkVFRFMtQUNUSU9OO1JTVlA9VFJV RTtDTj1EZWFuIEJvZ2RhDQogbm92aWM6TUFJTFRPOmRlYW5iQGp1bmlwZXIubmV0DQpERVNDUklQ VElPTjtMQU5HVUFHRT1lbi1VUzpXaGVuOiBUdWVzZGF5XCwgTWF5IDI2XCwgMjAxNSAxOjMwIFBN LTM6MDAgUE0gKFUNCiBUQy0wNjowMCkgQ2VudHJhbCBUaW1lIChVUyAmIENhbmFkYSkuXG5XaGVy ZTogV2ViRXhcblxuTm90ZTogVGhlIEdNVCBvZmZzZQ0KIHQgYWJvdmUgZG9lcyBub3QgcmVmbGVj dCBkYXlsaWdodCBzYXZpbmcgdGltZSBhZGp1c3RtZW50cy5cblxuKn4qfip+Kn4qfip+DQogKn4q fip+KlxuXG5JbiBvcmRlciB0byBnZXQgcmVhZHkgZm9yIGEgc3VjY2Vzc2Z1bCBJMk5TRiBCT0Yg YXQgSUVURjkzXCwgd2UNCiAgcGxhbiBoYXZlIGEgY291cGxlIG9mIGludGVyaW0gbWVldGluZ3Mg dG8gZGlzY3VzcyB0aGUgZm9sbG93aW5nIGl0ZW1zOlxuXA0KIG7igKIgICAgICAgUmVhY2ggY29u c2Vuc3VzIG9uIHRoZSBJMk5TRiBjaGFydGVyXG7igKIgICAgICAgR28gdGhyb3VnaCB0aGUgDQog cHJvYmxlbSBzdGF0ZW1lbnQgZHJhZnRcLCBhbmQgbWFrZSBzdXJlIGl0IGlzIGNvbnNpc3RlbnQg d2l0aCB0aGUgbmFycm93ZXINCiAgc2NvcGVkIEkyTlNGIGNoYXJ0ZXIuXG7igKIgICAgICAgR28g dGhyb3VnaCB0aGUgZnJhbWV3b3JrIGRyYWZ0XCwgYW5kIG1haw0KIGUgc3VyZSBpdCBpcyBjb25z aXN0ZW50IHdpdGggdGhlIG5hcnJvd2VyIHNjb3BlZCBJMk5TRiBjaGFydGVyLlxuXG5cbkhlcmUg DQogaXMgdGhlIGNvbmZlcmVuY2UgYnJpZGdlOlxuXG5cbkpvaW4gV2ViRXggbWVldGluZzxodHRw czovL2lldGYud2ViZXguY29tL2kNCiBldGYvai5waHA/TVRJRD1tNDFhNGM5Yjk5MmFjNzQxM2M2 MzUzNjA5OTkzMjczN2E+XG5NZWV0aW5nIG51bWJlcjogICAgICAgIA0KICA2NDcgNDI0IDEzN1xu TWVldGluZyBwYXNzd29yZDogICAgICAgMTIzNFxuXG5cbkpvaW4gYnkgcGhvbmVcbjEtODc3LTY2 OC00DQogNDkzIENhbGwtaW4gdG9sbCBmcmVlIG51bWJlciAoVVMvQ2FuYWRhKVxuMS02NTAtNDc5 LTMyMDggQ2FsbC1pbiB0b2xsIG51bWINCiBlciAoVVMvQ2FuYWRhKVxuQWNjZXNzIGNvZGU6IDY0 NyA0MjQgMTM3XG5Ub2xsLWZyZWUgY2FsbGluZyByZXN0cmljdGlvbnM8aA0KIHR0cDovL3d3dy53 ZWJleC5jb20vcGRmL3RvbGxmcmVlX3Jlc3RyaWN0aW9ucy5wZGY+XG5cblxuXG5DYW4ndCBqb2lu IHRoZSBtDQogZWV0aW5nPyBDb250YWN0IHN1cHBvcnQuPGh0dHBzOi8vaWV0Zi53ZWJleC5jb20v aWV0Zi9tYz5cblxuSU1QT1JUQU5UIE5PVEkNCiBDRTogUGxlYXNlIG5vdGUgdGhhdCB0aGlzIFdl YkV4IHNlcnZpY2UgYWxsb3dzIGF1ZGlvIGFuZCBvdGhlciBpbmZvcm1hdGlvbg0KICBzZW50IGR1 cmluZyB0aGUgc2Vzc2lvbiB0byBiZSByZWNvcmRlZFwsIHdoaWNoIG1heSBiZSBkaXNjb3ZlcmFi bGUgaW4gYSBsDQogZWdhbCBtYXR0ZXIuIEJ5IGpvaW5pbmcgdGhpcyBzZXNzaW9uXCwgeW91IGF1 dG9tYXRpY2FsbHkgY29uc2VudCB0byBzdWNoIHINCiBlY29yZGluZ3MuIElmIHlvdSBkbyBub3Qg Y29uc2VudCB0byBiZWluZyByZWNvcmRlZFwsIGRpc2N1c3MgeW91ciBjb25jZXJucw0KICB3aXRo IHRoZSBob3N0IG9yIGRvIG5vdCBqb2luIHRoZSBzZXNzaW9uLlxuXG5cbkxpbmRhXG5cbg0KU1VN TUFSWTtMQU5HVUFHRT1lbi1VUzpJbnRlcmltIE1lZXRpbmcgdG8gcmVhY2ggY29uc2Vuc3VzIG9u ICBJMk5TRiBjaGFydGVyDQogXCwgYW5kIGRpc2N1c3MgaWYgIHRoZSBwcm9ibGVtICYgZnJhbWV3 b3JrIGRyYWZ0cyByZWZsZWN0IHRoZSB1cGRhdGVkIEkyTlMNCiBGIGNoYXJ0ZXINCkRUU1RBUlQ7 VFpJRD1DZW50cmFsIFN0YW5kYXJkIFRpbWU6MjAxNTA1MjZUMTMzMDAwDQpEVEVORDtUWklEPUNl bnRyYWwgU3RhbmRhcmQgVGltZToyMDE1MDUyNlQxNTAwMDANClVJRDowNDAwMDAwMDgyMDBFMDAw NzRDNUI3MTAxQTgyRTAwODAwMDAwMDAwRTA2OUZGMzU0RTkyRDAwMTAwMDAwMDAwMDAwMDAwMA0K IDAxMDAwMDAwMEFDRDc1MDQzODFBNDc4NDJCMDYwMTdGNThDMUJFNDYxDQpDTEFTUzpQVUJMSUMN ClBSSU9SSVRZOjUNCkRUU1RBTVA6MjAxNTA1MjZUMTYwODE2Wg0KVFJBTlNQOk9QQVFVRQ0KU1RB VFVTOkNPTkZJUk1FRA0KU0VRVUVOQ0U6MQ0KTE9DQVRJT047TEFOR1VBR0U9ZW4tVVM6V2ViRXgg DQpYLU1JQ1JPU09GVC1DRE8tQVBQVC1TRVFVRU5DRToxDQpYLU1JQ1JPU09GVC1DRE8tT1dORVJB UFBUSUQ6MjM0MDUxNTUxDQpYLU1JQ1JPU09GVC1DRE8tQlVTWVNUQVRVUzpURU5UQVRJVkUNClgt TUlDUk9TT0ZULUNETy1JTlRFTkRFRFNUQVRVUzpCVVNZDQpYLU1JQ1JPU09GVC1DRE8tQUxMREFZ RVZFTlQ6RkFMU0UNClgtTUlDUk9TT0ZULUNETy1JTVBPUlRBTkNFOjENClgtTUlDUk9TT0ZULUNE Ty1JTlNUVFlQRTowDQpYLU1JQ1JPU09GVC1ESVNBTExPVy1DT1VOVEVSOkZBTFNFDQpCRUdJTjpW QUxBUk0NCkFDVElPTjpESVNQTEFZDQpERVNDUklQVElPTjpSRU1JTkRFUg0KVFJJR0dFUjtSRUxB VEVEPVNUQVJUOi1QVDE1TQ0KRU5EOlZBTEFSTQ0KRU5EOlZFVkVOVA0KRU5EOlZDQUxFTkRBUg0K --_000_4A95BA014132FF49AE685FAB4B9F17F657C4BB08dfweml701chm_-- From nobody Tue May 26 10:32:05 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E753F1B2C6F for ; Tue, 26 May 2015 10:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Bc1bIjuErAg for ; Tue, 26 May 2015 10:32:00 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17FA41B2C68 for ; Tue, 26 May 2015 10:31:58 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BWN64965; Tue, 26 May 2015 17:31:56 +0000 (GMT) Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 26 May 2015 18:31:55 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml702-chm ([10.193.5.72]) with mapi id 14.03.0158.001; Tue, 26 May 2015 10:31:42 -0700 From: Linda Dunbar To: DIEGO LOPEZ GARCIA Thread-Topic: Key problems to reflect the narrower scoped I2NSF charter Thread-Index: AQHQl9nU97yFRfY72keCbwOSULTnig== Date: Tue, 26 May 2015 17:31:41 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657C4BC4B@dfweml701-chm> References: <4A95BA014132FF49AE685FAB4B9F17F657C46D13@dfweml701-chm> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.130.97] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657C4BC4Bdfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "i2nsf@ietf.org" Subject: [I2nsf] Key problems to reflect the narrower scoped I2NSF charter X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 17:32:04 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F657C4BC4Bdfweml701chm_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGllZ28sDQoNClRoYW5rIHlvdSB2ZXJ5IG11Y2ggZm9yIHRoZSBzdWdnZXN0aW9uIChhbmQgdGhl IHRpbWUgdGFrZW4geWVzdGVyZGF5IGZvciB0aGUgY29uZmVyZW5jZSBjYWxsKS4NCg0KSG93IGFi b3V0IHRoZSBmb2xsb3dpbmcgZGVzY3JpcHRpb24gb2YgdGhlIGtleSBwcm9ibGVtcyBmb3IgSTJO U0Y/DQoNCjMuMS4gQ2hhbGxlbmdlcyBGYWNpbmcgU2VjdXJpdHkgU2VydmljZSBQcm92aWRlcnMN Cg0KDQotICAgRGl2ZXJzZSB0eXBlcyBvZiBTZWN1cml0eSBGdW5jdGlvbnMNCiAgICAgICAgIE5v IFN0YW5kYXJkIENoYXJhY3Rlcml6YXRpb24gb2YgTlNGcw0KDQoNCi0gICBEaXZlcnNlIEludGVy ZmFjZXMgdG8gQ29udHJvbCBOU0ZzDQoNCg0KDQotICAgRGl2ZXJzZSBtZWNoYW5pc21zIHRvIG1v bml0b3IgdGhlIGJlaGF2aW9yIG9mIE5TRnMNCg0KDQotICAgTW9yZSBEaXN0cmlidXRlZCBOU0Zz IGFuZCB2TlNGcw0KDQoNCi0gICBEZW1hbmQgdG8gQ29udHJvbCBOU0ZzIER5bmFtaWNhbGx5DQoN Cg0KDQotICAgRGVtYW5kIGZvciBtdWx0aS10ZW5hbmN5IG9mIHRoZSBpbnRlcmZhY2VzIHRvIGNv bnRyb2wgYW5kIG1vbml0b3IgTlNGcy4NCg0KU2VydmljZSBwcm92aWRlcnMgbWF5IHdlbGwgcmVx dWlyZSBoYXZpbmcgc2V2ZXJhbCBvcGVyYXRpb25hbCB1bml0cyB0byBtYWtlIHRoaXMgY29udHJv bCBhbmQgbW9uaXRvcmluZywgZXNwZWNpYWxseSB3aGVuIHRoZXkgYmVjb21lIGRpc3RyaWJ1dGVk IGFuZCB2aXJ0dWFsaXplZA0KDQoNCiAgICAgIDMuMi4gQ2hhbGxlbmdlcyBGYWNpbmcgQ3VzdG9t ZXJzDQoNCi0gICBOZWVkIGNvbnNpc3RlbnQgaW50ZWdyYXRpb24gb2YgTlNGcyBvdmVyIGhldGVy b2dlbmVvdXMgYWRtaW5pc3RyYXRpdmUgZG9tYWlucw0KICAgICAgICAgLSBUb2RheSdzIFBvbGlj eSBFeHByZXNzaW9ucyBhcmUgVmVuZG9ycyBTcGVjaWZpYw0KICAgICAgICAgLSBEaWZmaWN1bHR5 IHRvIE1vbml0b3IgdGhlIEV4ZWN1dGlvbiBvZiBEZXNpcmVkIFBvbGljaWVzDQoNCg0KQ2hlZXJz LA0KTGluZGENCkZyb206IERJRUdPIExPUEVaIEdBUkNJQSBbbWFpbHRvOmRpZWdvLnIubG9wZXpA dGVsZWZvbmljYS5jb21dDQpTZW50OiBNb25kYXksIE1heSAyNSwgMjAxNSAyOjA0IFBNDQpUbzog TGluZGEgRHVuYmFyDQpDYzogaTJuc2ZAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbSTJuc2ZdIHVw ZGF0ZWQgSTJOU0YgcHJvYmxlbSBzdGF0ZW1lbnQgdG8gcmVmbGVjdCB0aGUgbmFycm93ZXIgc2Nv cGVkIGNoYXJ0ZXINCg0KSGksDQoNCkFzIHdlIGRpc2N1c3NlZCByZWNlbnRseSwgSSdkIHNheSB0 aGF0Og0KDQoxLi0gSXQgaXMgaW1wb3J0YW50IHRvIGFkZHJlc3MgbXVsdGktdGVuYW5jeSBvZiB0 aGUgaW50ZXJmYWNlcyB0byBjb250cm9sIGFuZCBtb25pdG9yIE5TRnMuIEZpcnN0LCBiZWNhdXNl IHNlcnZpY2UgcHJvdmlkZXJzIG1heSB3ZWxsIHJlcXVpcmUgdG8gaGF2ZSBzZXZlcmFsIG9wZXJh dGlvbmFsIHVuaXRzIHRvIG1ha2UgdGhpcyBjb250cm9sIGFuZCBtb25pdG9yaW5nLCBlc3BlY2lh bGx5IHdoZW4gdGhleSBiZWNvbWUgZGlzdHJpYnV0ZWQgYW5kIHZpcnR1YWxpemVkLiBTZWNvbmQs IHNlcnZpY2UgcHJvdmlkZXJzIG1heSBmaW5kIGEgdmFsdWUgaW4gb2ZmZXJpbmcgYSAobWVkaWF0 ZWQpIGludGVyZmFjZSB0byBjb250cm9sIGFuZCBtb25pdG9yaW5nIE5TRnMgdG8gdGhlaXIgY3Vz dG9tZXJzLiBUaGlzIGNvdWxkIGNlcnRhaW5seSBiZSBwYXJ0IG9mIDMuMS41Li4uDQoNCjIuLSBJ biB3aGF0IHJlbGF0ZXMgdG8gMy4yLjEsIHJhdGhlciB0aGFuIGRpc3Rpbmd1aXNoaW5nIGJldHdl ZW4gIm9uLXByZW1pc2VzIiBhbmQgInJlbW90ZSIsIEknZCB0YWxrIGFib3V0IGEgY29uc2lzdGVu dCBpbnRlZ3JhdGlvbiBvZiBOU0ZzLCBpbmRlcGVuZGVudGx5IG9mIHRoZWlyIGxvY2F0aW9uIGFu ZCB0aGVpciBpbXBsZW1lbnRhdGlvbiBtZWNoYW5pc21zLg0KDQpCZSBnb29kZSwNCg0KT24gMjIg TWF5IDIwMTUsIGF0IDI0OjQyICwgTGluZGEgRHVuYmFyIDxsaW5kYS5kdW5iYXJAaHVhd2VpLmNv bTxtYWlsdG86bGluZGEuZHVuYmFyQGh1YXdlaS5jb20+PiB3cm90ZToNCg0KDQpXZSB1cGRhdGVk IHRoZSBJMk5TRiBwcm9ibGVtIHN0YXRlbWVudCB0byByZWZsZWN0IHRoZSBuYXJyb3dlciBzY29w ZWQgY2hhcnRlci4NCg0KVGhlIHByaW1hcnkgaXNzdWVzIGFuZCBjaGFsbGVuZ2VzIGZhY2luZyBO U0ZzIGhvc3RlZCBieSBkaWZmZXJlbnQgZG9tYWlucyBhcmU6DQoNCiAgICAgMy4xLiBDaGFsbGVu Z2VzIEZhY2luZyBTZWN1cml0eSBTZXJ2aWNlIFByb3ZpZGVycy4uLi4uLi4uLi4uLi4uNQ0KICAg ICAgICAzLjEuMS4gRGl2ZXJzZSB0eXBlcyBvZiBTZWN1cml0eSBGdW5jdGlvbnMuLi4uLi4uLi4u Li4uLi4uLi41DQogICAgICAgIDMuMS4yLiBObyBTdGFuZGFyZCBDaGFyYWN0ZXJpemF0aW9uIG9m IE5TRnMuLi4uLi4uLi4uLi4uLi4uLjYNCiAgICAgICAgMy4xLjMuIE1vcmUgRGlzdHJpYnV0ZWQg TlNGcyBhbmQgdk5TRnMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uNw0KICAgICAgICAzLjEuNC4gTW9y ZSBEZW1hbmQgdG8gQ29udHJvbCBOU0ZzIER5bmFtaWNhbGx5Li4uLi4uLi4uLi4uLi43DQogICAg ICAgIDMuMS41LiBEaXZlcnNlIEludGVyZmFjZXMgdG8gQ29udHJvbCBhbmQgTW9uaXRvciBOU0Zz Li4uLi4uLjcNCiAgICAgICAgMy4xLjYuIExhY2sgb2YgbWVjaGFuaXNtIHRvIG1vbml0b3IgdGhl IGJlaGF2aW9yIG9mIE5TRnMuLi4uOA0KICAgICAzLjIuIENoYWxsZW5nZXMgRmFjaW5nIEN1c3Rv bWVycy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi44DQogICAgICAgIDMuMi4xLiBOZWVk IHRvIGludGVncmF0ZSBvbi1wcmVtaXNlcyBOU0ZzIHdpdGggUmVtb3RlIE5TRnMuLjgNCiAgICAg ICAgMy4yLjIuIFRvZGF5J3MgUG9saWN5IEV4cHJlc3Npb25zIGFyZSBWZW5kb3JzIFNwZWNpZmlj Li4uLi4uOQ0KICAgICAgICAzLjIuMy4gRGlmZmljdWx0eSB0byBNb25pdG9yIHRoZSBFeGVjdXRp b24gb2YgRGVzaXJlZCBQb2xpY2llcw0KICAgICAgICAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjEwDQogICAgIDMuMy4gRGlmZmljdWx0 eSB0byBWYWxpZGF0ZSBQb2xpY2llcyBhY3Jvc3MgTXVsdGlwbGUgRG9tYWlucy4uMTANCiAgICAg My40LiBMYWNrIG9mIFN0YW5kYXJkIEludGVyZmFjZSB0byBJbmplY3QgRmVlZGJhY2sgdG8gTlNG Li4uLi4xMQ0KDQpZb3VyIGNvbW1lbnRzIGFuZCBzdWdnZXN0aW9ucyBhcmUgaGlnaGx5IGFwcHJl Y2lhdGVkLg0KDQpMaW5kYQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50 ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+IFtt YWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXQ0KU2VudDogVGh1cnNkYXksIE1heSAyMSwg MjAxNSA1OjM3IFBNDQpUbzogTW9oYW1lZCBCb3VjYWRhaXI7IFNoYWliYWwgQ2hha3JhYmFydHk7 IExpbmRhIER1bmJhcjsgQ2hyaXN0aWFuIEphY3F1ZW5ldDsgTXlvIFphcm55OyBDaHJpc3RpYW4g SmFjcXVlbmV0OyBNeW8gWmFybnk7IFNoYWliYWwgQ2hha3JhYmFydHk7IExpbmRhIER1bmJhcjsg TW9oYW1lZCBCb3VjYWRhaXINClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3Ig ZHJhZnQtZHVuYmFyLWkybnNmLXByb2JsZW0tc3RhdGVtZW50LTA0LnR4dA0KDQoNCkEgbmV3IHZl cnNpb24gb2YgSS1ELCBkcmFmdC1kdW5iYXItaTJuc2YtcHJvYmxlbS1zdGF0ZW1lbnQtMDQudHh0 DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IExpbmRhIER1bmJhciBhbmQgcG9z dGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6IGRyYWZ0LWR1bmJhci1pMm5zZi1w cm9ibGVtLXN0YXRlbWVudA0KUmV2aXNpb246IDA0DQpUaXRsZTogSW50ZXJmYWNlIHRvIE5ldHdv cmsgU2VjdXJpdHkgRnVuY3Rpb25zIChJMk5TRikgUHJvYmxlbSBTdGF0ZW1lbnQNCkRvY3VtZW50 IGRhdGU6IDIwMTUtMDUtMjENCkdyb3VwOiBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOiAy MA0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9k cmFmdC1kdW5iYXItaTJuc2YtcHJvYmxlbS1zdGF0ZW1lbnQtMDQudHh0DQpTdGF0dXM6ICAgICAg ICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZHVuYmFyLWkybnNmLXBy b2JsZW0tc3RhdGVtZW50Lw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1kdW5iYXItaTJuc2YtcHJvYmxlbS1zdGF0ZW1lbnQtMDQNCkRpZmY6ICAgICAg ICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtZHVuYmFyLWkybnNm LXByb2JsZW0tc3RhdGVtZW50LTA0DQoNCkFic3RyYWN0Og0KICBUaGlzIGRvY3VtZW50IGRlc2Ny aWJlcyB0aGUgbW90aXZhdGlvbiBhbmQgdGhlIHByb2JsZW0gc3RhdGVtZW50IGZvcg0KICBJbnRl cmZhY2UgdG8gTmV0d29yayBTZWN1cml0eSBGdW5jdGlvbnMgKEkyTlNGKS4NCg0KDQoNCg0KUGxl YXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRp bWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUg YXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnPGh0dHA6Ly90b29scy5pZXRmLm9yZz4uDQoNClRo ZSBJRVRGIFNlY3JldGFyaWF0DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpJMm5zZiBtYWlsaW5nIGxpc3QNCkkybnNmQGlldGYub3JnPG1haWx0bzpJ Mm5zZkBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaTJu c2YNCg0KLS0NCiJFc3RhIHZleiBubyBmYWxsYXJlbW9zLCBEb2N0b3IgSW5maWVybm8iDQoNCkRy IERpZWdvIFIuIExvcGV6DQpUZWxlZm9uaWNhIEkrRA0KaHR0cDovL3Blb3BsZS50aWQuZXMvZGll Z28ubG9wZXovDQoNCmUtbWFpbDogZGllZ28uci5sb3BlekB0ZWxlZm9uaWNhLmNvbTxtYWlsdG86 ZGllZ28uci5sb3BlekB0ZWxlZm9uaWNhLmNvbT4NClRlbDogICAgKzM0IDkxMyAxMjkgMDQxDQpN b2JpbGU6ICszNCA2ODIgMDUxIDA5MQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkVzdGUgbWVuc2FqZSB5 IHN1cyBhZGp1bnRvcyBzZSBkaXJpZ2VuIGV4Y2x1c2l2YW1lbnRlIGEgc3UgZGVzdGluYXRhcmlv LCBwdWVkZSBjb250ZW5lciBpbmZvcm1hY2nDs24gcHJpdmlsZWdpYWRhIG8gY29uZmlkZW5jaWFs IHkgZXMgcGFyYSB1c28gZXhjbHVzaXZvIGRlIGxhIHBlcnNvbmEgbyBlbnRpZGFkIGRlIGRlc3Rp bm8uIFNpIG5vIGVzIHVzdGVkLiBlbCBkZXN0aW5hdGFyaW8gaW5kaWNhZG8sIHF1ZWRhIG5vdGlm aWNhZG8gZGUgcXVlIGxhIGxlY3R1cmEsIHV0aWxpemFjacOzbiwgZGl2dWxnYWNpw7NuIHkvbyBj b3BpYSBzaW4gYXV0b3JpemFjacOzbiBwdWVkZSBlc3RhciBwcm9oaWJpZGEgZW4gdmlydHVkIGRl IGxhIGxlZ2lzbGFjacOzbiB2aWdlbnRlLiBTaSBoYSByZWNpYmlkbyBlc3RlIG1lbnNhamUgcG9y IGVycm9yLCBsZSByb2dhbW9zIHF1ZSBub3MgbG8gY29tdW5pcXVlIGlubWVkaWF0YW1lbnRlIHBv ciBlc3RhIG1pc21hIHbDrWEgeSBwcm9jZWRhIGEgc3UgZGVzdHJ1Y2Npw7NuLg0KDQpUaGUgaW5m b3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgdHJhbnNtaXNzaW9uIGlzIHByaXZpbGVnZWQgYW5k IGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiBpbnRlbmRlZCBvbmx5IGZvciB0aGUgdXNlIG9mIHRo ZSBpbmRpdmlkdWFsIG9yIGVudGl0eSBuYW1lZCBhYm92ZS4gSWYgdGhlIHJlYWRlciBvZiB0aGlz IG1lc3NhZ2UgaXMgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgaGVyZWJ5IG5v dGlmaWVkIHRoYXQgYW55IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiBvciBjb3B5aW5nIG9m IHRoaXMgY29tbXVuaWNhdGlvbiBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgaGF2ZSBy ZWNlaXZlZCB0aGlzIHRyYW5zbWlzc2lvbiBpbiBlcnJvciwgZG8gbm90IHJlYWQgaXQuIFBsZWFz ZSBpbW1lZGlhdGVseSByZXBseSB0byB0aGUgc2VuZGVyIHRoYXQgeW91IGhhdmUgcmVjZWl2ZWQg dGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yIGFuZCB0aGVuIGRlbGV0ZSBpdC4NCg0KRXN0YSBt ZW5zYWdlbSBlIHNldXMgYW5leG9zIHNlIGRpcmlnZW0gZXhjbHVzaXZhbWVudGUgYW8gc2V1IGRl c3RpbmF0w6FyaW8sIHBvZGUgY29udGVyIGluZm9ybWHDp8OjbyBwcml2aWxlZ2lhZGEgb3UgY29u ZmlkZW5jaWFsIGUgw6kgcGFyYSB1c28gZXhjbHVzaXZvIGRhIHBlc3NvYSBvdSBlbnRpZGFkZSBk ZSBkZXN0aW5vLiBTZSBuw6NvIMOpIHZvc3NhIHNlbmhvcmlhIG8gZGVzdGluYXTDoXJpbyBpbmRp Y2FkbywgZmljYSBub3RpZmljYWRvIGRlIHF1ZSBhIGxlaXR1cmEsIHV0aWxpemHDp8OjbywgZGl2 dWxnYcOnw6NvIGUvb3UgY8OzcGlhIHNlbSBhdXRvcml6YcOnw6NvIHBvZGUgZXN0YXIgcHJvaWJp ZGEgZW0gdmlydHVkZSBkYSBsZWdpc2xhw6fDo28gdmlnZW50ZS4gU2UgcmVjZWJldSBlc3RhIG1l bnNhZ2VtIHBvciBlcnJvLCByb2dhbW9zLWxoZSBxdWUgbm9zIG8gY29tdW5pcXVlIGltZWRpYXRh bWVudGUgcG9yIGVzdGEgbWVzbWEgdmlhIGUgcHJvY2VkYSBhIHN1YSBkZXN0cnVpw6fDo28NCg== --_000_4A95BA014132FF49AE685FAB4B9F17F657C4BC4Bdfweml701chm_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OlNpbVN1bjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAx IDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0x OjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21h Ow0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6IlxAU2ltU3VuIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCi8qIFN0 eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9y bWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox Mi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmss IHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVy bGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUs IGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJp ZiI7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlz dFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJ bWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjEwLjBwdDsNCgltYXJnaW4tbGVmdDou NWluOw0KCWxpbmUtaGVpZ2h0OjExNSU7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCnAuTXNvTGlzdFBhcmFncmFwaEN4U3BGaXJzdCwg bGkuTXNvTGlzdFBhcmFncmFwaEN4U3BGaXJzdCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGhDeFNwRmly c3QNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTow aW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJbGluZS1o ZWlnaHQ6MTE1JTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoQ3hTcE1pZGRsZSwgbGkuTXNvTGlzdFBh cmFncmFwaEN4U3BNaWRkbGUsIGRpdi5Nc29MaXN0UGFyYWdyYXBoQ3hTcE1pZGRsZQ0KCXttc28t c3R5bGUtcHJpb3JpdHk6MzQ7DQoJbXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbWFyZ2lu LXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJn aW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglsaW5lLWhlaWdodDoxMTUl Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Ijt9DQpwLk1zb0xpc3RQYXJhZ3JhcGhDeFNwTGFzdCwgbGkuTXNvTGlzdFBhcmFncmFwaEN4U3BM YXN0LCBkaXYuTXNvTGlzdFBhcmFncmFwaEN4U3BMYXN0DQoJe21zby1zdHlsZS1wcmlvcml0eToz NDsNCgltc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJn aW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MTAuMHB0Ow0KCW1hcmdpbi1sZWZ0Oi41aW47 DQoJbGluZS1oZWlnaHQ6MTE1JTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5hcHBsZS10YWItc3Bhbg0KCXttc28tc3R5bGUt bmFtZTphcHBsZS10YWItc3Bhbjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUt bmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1z ZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdE O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0K CW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21z by1saXN0LWlkOjE1NTA4NzQ3MDA7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3Qt dGVtcGxhdGUtaWRzOjc3NzAxMDg0MiAxMzE2NTQ0NjI2IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4 Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0 IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MzsNCgltc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6LTsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MS4waW47 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNv LWZhcmVhc3QtZm9udC1mYW1pbHk6U2ltU3VuO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2lu LWxlZnQ6MS41aW47DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBs aXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZl bDUNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1s ZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0 b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0K QGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCm9sDQoJe21hcmdp bi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RGllZ28sDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5rIHlvdSB2ZXJ5 IG11Y2ggZm9yIHRoZSBzdWdnZXN0aW9uIChhbmQgdGhlIHRpbWUgdGFrZW4geWVzdGVyZGF5IGZv ciB0aGUgY29uZmVyZW5jZSBjYWxsKS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SG93IGFib3V0IHRoZSBmb2xsb3dp bmcgZGVzY3JpcHRpb24gb2YgdGhlIGtleSBwcm9ibGVtcyBmb3IgSTJOU0Y/PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVudDouNWluO3RleHQtYXV0b3NwYWNlOm5vbmUi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij4zLjEuIENoYWxsZW5nZXMgRmFjaW5nIFNlY3VyaXR5IFNlcnZpY2UgUHJvdmlk ZXJzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRl eHQtaW5kZW50Oi41aW47dGV4dC1hdXRvc3BhY2U6bm9uZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OjBpbjttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206MGluO21h cmdpbi1sZWZ0OjEuMGluO21hcmdpbi1ib3R0b206LjAwMDFwdDt0ZXh0LWluZGVudDotLjI1aW47 bGluZS1oZWlnaHQ6bm9ybWFsO21zby1saXN0OmwwIGxldmVsMSBsZm8xO3RleHQtYXV0b3NwYWNl Om5vbmUiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxzcGFuIHN0eWxlPSJtc28t bGlzdDpJZ25vcmUiPi08c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDsiPiZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij5EaXZlcnNlIHR5cGVzIG9mIFNlY3VyaXR5IEZ1bmN0aW9uczxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO3Rl eHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgTm8gU3RhbmRhcmQgQ2hhcmFjdGVyaXphdGlvbiBvZiBOU0Zz PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW47dGV4dC1hdXRvc3BhY2U6bm9uZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoQ3hTcEZpcnN0IiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBpbjttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206 MGluO21hcmdpbi1sZWZ0OjEuMGluO21hcmdpbi1ib3R0b206LjAwMDFwdDt0ZXh0LWluZGVudDot LjI1aW47bGluZS1oZWlnaHQ6bm9ybWFsO21zby1saXN0OmwwIGxldmVsMSBsZm8xO3RleHQtYXV0 b3NwYWNlOm5vbmUiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxzcGFuIHN0eWxl PSJtc28tbGlzdDpJZ25vcmUiPi08c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5k aWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij5EaXZlcnNlIEludGVyZmFjZXMgdG8gQ29udHJvbCBOU0ZzPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGhDeFNwTWlkZGxlIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBpbjttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206 MGluO21hcmdpbi1sZWZ0OjEuMGluO21hcmdpbi1ib3R0b206LjAwMDFwdDtsaW5lLWhlaWdodDpu b3JtYWw7dGV4dC1hdXRvc3BhY2U6bm9uZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGhDeFNwTGFzdCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjBpbjtt YXJnaW4tbGVmdDoxLjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQ7dGV4dC1pbmRlbnQ6LS4yNWlu O2xpbmUtaGVpZ2h0Om5vcm1hbDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMTt0ZXh0LWF1dG9zcGFj ZTpub25lIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48c3BhbiBzdHlsZT0ibXNv LWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+RGl2ZXJzZSBtZWNoYW5pc21zIHRvIG1vbml0b3IgdGhlIGJlaGF2aW9yIG9mIE5T RnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4 dC1hdXRvc3BhY2U6bm9uZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBp bjttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206MGluO21hcmdpbi1sZWZ0OjEuMGluO21h cmdpbi1ib3R0b206LjAwMDFwdDt0ZXh0LWluZGVudDotLjI1aW47bGluZS1oZWlnaHQ6bm9ybWFs O21zby1saXN0OmwwIGxldmVsMSBsZm8xO3RleHQtYXV0b3NwYWNlOm5vbmUiPg0KPCFbaWYgIXN1 cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3Bh biBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZu YnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5Nb3JlIERpc3Ry aWJ1dGVkIE5TRnMgYW5kIHZOU0ZzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9InRleHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaEN4U3BGaXJzdCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90 dG9tOjBpbjttYXJnaW4tbGVmdDoxLjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQ7dGV4dC1pbmRl bnQ6LS4yNWluO2xpbmUtaGVpZ2h0Om5vcm1hbDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMTt0ZXh0 LWF1dG9zcGFjZTpub25lIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48c3BhbiBz dHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwh W2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+RGVtYW5kIHRvIENvbnRyb2wgTlNGcyBEeW5hbWljYWxseTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoQ3hTcE1pZGRsZSIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90 dG9tOjBpbjttYXJnaW4tbGVmdDoxLjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQ7bGluZS1oZWln aHQ6bm9ybWFsO3RleHQtYXV0b3NwYWNlOm5vbmUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoQ3hTcExhc3QiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6MGluO21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTow aW47bWFyZ2luLWxlZnQ6MS4waW47bWFyZ2luLWJvdHRvbTouMDAwMXB0O3RleHQtaW5kZW50Oi0u MjVpbjtsaW5lLWhlaWdodDpub3JtYWw7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzE7dGV4dC1hdXRv c3BhY2U6bm9uZSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PHNwYW4gc3R5bGU9 Im1zby1saXN0Oklnbm9yZSI+LTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRp Zl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPkRlbWFuZCBmb3IgbXVsdGktdGVuYW5jeSBvZiB0aGUgaW50ZXJmYWNlcyB0 byBjb250cm9sIGFuZCBtb25pdG9yIE5TRnMuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hdXRvc3BhY2U6bm9uZSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDoxLjI1aW47dGV4dC1hdXRvc3BhY2U6bm9uZSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlNlcnZpY2Ug cHJvdmlkZXJzIG1heSB3ZWxsIHJlcXVpcmUgaGF2aW5nIHNldmVyYWwgb3BlcmF0aW9uYWwgdW5p dHMgdG8gbWFrZSB0aGlzIGNvbnRyb2wgYW5kIG1vbml0b3JpbmcsIGVzcGVjaWFsbHkgd2hlbiB0 aGV5IGJlY29tZQ0KIGRpc3RyaWJ1dGVkIGFuZCB2aXJ0dWFsaXplZDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWF1dG9zcGFjZTpub25lIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9InRleHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hdXRvc3BhY2U6 bm9uZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAzLjIuIENoYWxs ZW5nZXMgRmFjaW5nIEN1c3RvbWVyczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBpbjttYXJnaW4tcmln aHQ6MGluO21hcmdpbi1ib3R0b206MGluO21hcmdpbi1sZWZ0OjEuMGluO21hcmdpbi1ib3R0b206 LjAwMDFwdDt0ZXh0LWluZGVudDotLjI1aW47bGluZS1oZWlnaHQ6bm9ybWFsO21zby1saXN0Omww IGxldmVsMSBsZm8xO3RleHQtYXV0b3NwYWNlOm5vbmUiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3BhbiBzdHlsZT0iZm9u dDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOw0KPC9zcGFu Pjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5OZWVkIGNvbnNpc3RlbnQgaW50ZWdy YXRpb24gb2YgTlNGcyBvdmVyIGhldGVyb2dlbmVvdXMgYWRtaW5pc3RyYXRpdmUgZG9tYWluczxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWF1 dG9zcGFjZTpub25lIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IC0gVG9kYXkncyBQb2xpY3kgRXhwcmVzc2lvbnMgYXJlIFZlbmRvcnMg U3BlY2lmaWM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0idGV4dC1hdXRvc3BhY2U6bm9uZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtIERpZmZpY3VsdHkgdG8gTW9uaXRvciB0aGUgRXhl Y3V0aW9uIG9mIERlc2lyZWQgUG9saWNpZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5DaGVlcnMsDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ TGluZGE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAw aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IERJRUdPIExPUEVa IEdBUkNJQSBbbWFpbHRvOmRpZWdvLnIubG9wZXpAdGVsZWZvbmljYS5jb21dDQo8YnI+DQo8Yj5T ZW50OjwvYj4gTW9uZGF5LCBNYXkgMjUsIDIwMTUgMjowNCBQTTxicj4NCjxiPlRvOjwvYj4gTGlu ZGEgRHVuYmFyPGJyPg0KPGI+Q2M6PC9iPiBpMm5zZkBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSZTogW0kybnNmXSB1cGRhdGVkIEkyTlNGIHByb2JsZW0gc3RhdGVtZW50IHRvIHJlZmxl Y3QgdGhlIG5hcnJvd2VyIHNjb3BlZCBjaGFydGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SGksIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+QXMgd2UgZGlzY3Vzc2VkIHJlY2VudGx5LCBJJ2Qgc2F5IHRoYXQ6PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjEuLSBJ dCBpcyBpbXBvcnRhbnQgdG8gYWRkcmVzcyBtdWx0aS10ZW5hbmN5IG9mIHRoZSBpbnRlcmZhY2Vz IHRvIGNvbnRyb2wgYW5kIG1vbml0b3IgTlNGcy4gRmlyc3QsIGJlY2F1c2Ugc2VydmljZSBwcm92 aWRlcnMgbWF5IHdlbGwgcmVxdWlyZSB0byBoYXZlIHNldmVyYWwgb3BlcmF0aW9uYWwgdW5pdHMg dG8gbWFrZSB0aGlzIGNvbnRyb2wgYW5kIG1vbml0b3JpbmcsIGVzcGVjaWFsbHkgd2hlbiB0aGV5 IGJlY29tZQ0KIGRpc3RyaWJ1dGVkIGFuZCB2aXJ0dWFsaXplZC4gU2Vjb25kLCBzZXJ2aWNlIHBy b3ZpZGVycyBtYXkgZmluZCBhIHZhbHVlIGluIG9mZmVyaW5nIGEgKG1lZGlhdGVkKSBpbnRlcmZh Y2UgdG8gY29udHJvbCBhbmQgbW9uaXRvcmluZyBOU0ZzIHRvIHRoZWlyIGN1c3RvbWVycy4gVGhp cyBjb3VsZCBjZXJ0YWlubHkgYmUgcGFydCBvZiAzLjEuNS4uLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yLi0gSW4gd2hhdCByZWxhdGVzIHRv IDMuMi4xLCByYXRoZXIgdGhhbiBkaXN0aW5ndWlzaGluZyBiZXR3ZWVuICZxdW90O29uLXByZW1p c2VzJnF1b3Q7IGFuZCAmcXVvdDtyZW1vdGUmcXVvdDssIEknZCB0YWxrIGFib3V0IGEgY29uc2lz dGVudCBpbnRlZ3JhdGlvbiBvZiBOU0ZzLCBpbmRlcGVuZGVudGx5IG9mIHRoZWlyIGxvY2F0aW9u IGFuZCB0aGVpciBpbXBsZW1lbnRhdGlvbiBtZWNoYW5pc21zLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CZSBnb29kZSw8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAyMiBNYXkgMjAxNSwg YXQgMjQ6NDIgLCBMaW5kYSBEdW5iYXIgJmx0OzxhIGhyZWY9Im1haWx0bzpsaW5kYS5kdW5iYXJA aHVhd2VpLmNvbSI+bGluZGEuZHVuYmFyQGh1YXdlaS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSB1cGRhdGVkIHRoZSBJMk5TRiBwcm9i bGVtIHN0YXRlbWVudCB0byByZWZsZWN0IHRoZSBuYXJyb3dlciBzY29wZWQgY2hhcnRlci4NCjxi cj4NCjxicj4NClRoZSBwcmltYXJ5IGlzc3VlcyBhbmQgY2hhbGxlbmdlcyBmYWNpbmcgTlNGcyBo b3N0ZWQgYnkgZGlmZmVyZW50IGRvbWFpbnMgYXJlOjxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOzMuMS4gQ2hhbGxlbmdlcyBGYWNpbmcgU2VjdXJpdHkgU2VydmljZSBQ cm92aWRlcnMuLi4uLi4uLi4uLi4uLjU8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDszLjEuMS4gRGl2ZXJzZSB0eXBlcyBvZiBTZWN1cml0eSBGdW5j dGlvbnMuLi4uLi4uLi4uLi4uLi4uLi41PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7My4xLjIuIE5vIFN0YW5kYXJkIENoYXJhY3Rlcml6YXRpb24g b2YgTlNGcy4uLi4uLi4uLi4uLi4uLi4uNjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOzMuMS4zLiBNb3JlIERpc3RyaWJ1dGVkIE5TRnMgYW5kIHZO U0ZzLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjc8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDszLjEuNC4gTW9yZSBEZW1hbmQgdG8gQ29udHJvbCBOU0Zz IER5bmFtaWNhbGx5Li4uLi4uLi4uLi4uLi43PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7My4xLjUuIERpdmVyc2UgSW50ZXJmYWNlcyB0byBDb250 cm9sIGFuZCBNb25pdG9yIE5TRnMuLi4uLi4uNzxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzMuMS42LiBMYWNrIG9mIG1lY2hhbmlzbSB0byBtb25p dG9yIHRoZSBiZWhhdmlvciBvZiBOU0ZzLi4uLjg8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDszLjIuIENoYWxsZW5nZXMgRmFjaW5nIEN1c3RvbWVycy4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi44PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7My4yLjEuIE5lZWQgdG8gaW50ZWdyYXRlIG9uLXByZW1pc2VzIE5TRnMgd2l0 aCBSZW1vdGUgTlNGcy4uODxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOzMuMi4yLiBUb2RheSdzIFBvbGljeSBFeHByZXNzaW9ucyBhcmUgVmVuZG9y cyBTcGVjaWZpYy4uLi4uLjk8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDszLjIuMy4gRGlmZmljdWx0eSB0byBNb25pdG9yIHRoZSBFeGVjdXRpb24g b2YgRGVzaXJlZCBQb2xpY2llczxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uMTA8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsz LjMuIERpZmZpY3VsdHkgdG8gVmFsaWRhdGUgUG9saWNpZXMgYWNyb3NzIE11bHRpcGxlIERvbWFp bnMuLjEwPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7My40LiBMYWNrIG9mIFN0 YW5kYXJkIEludGVyZmFjZSB0byBJbmplY3QgRmVlZGJhY2sgdG8gTlNGLi4uLi4xMTxicj4NCjxi cj4NCllvdXIgY29tbWVudHMgYW5kIHN1Z2dlc3Rpb25zIGFyZSBoaWdobHkgYXBwcmVjaWF0ZWQu IDxicj4NCjxicj4NCkxpbmRhPGJyPg0KPGJyPg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08 YnI+DQpGcm9tOiA8YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIj5pbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmc8L2E+IFs8YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRz QGlldGYub3JnIj5tYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9hPl0NCjxicj4NClNl bnQ6IFRodXJzZGF5LCBNYXkgMjEsIDIwMTUgNTozNyBQTTxicj4NClRvOiBNb2hhbWVkIEJvdWNh ZGFpcjsgU2hhaWJhbCBDaGFrcmFiYXJ0eTsgTGluZGEgRHVuYmFyOyBDaHJpc3RpYW4gSmFjcXVl bmV0OyBNeW8gWmFybnk7IENocmlzdGlhbiBKYWNxdWVuZXQ7IE15byBaYXJueTsgU2hhaWJhbCBD aGFrcmFiYXJ0eTsgTGluZGEgRHVuYmFyOyBNb2hhbWVkIEJvdWNhZGFpcjxicj4NClN1YmplY3Q6 IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtZHVuYmFyLWkybnNmLXByb2JsZW0t c3RhdGVtZW50LTA0LnR4dDxicj4NCjxicj4NCjxicj4NCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBk cmFmdC1kdW5iYXItaTJuc2YtcHJvYmxlbS1zdGF0ZW1lbnQtMDQudHh0PGJyPg0KaGFzIGJlZW4g c3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBMaW5kYSBEdW5iYXIgYW5kIHBvc3RlZCB0byB0aGUg SUVURiByZXBvc2l0b3J5Ljxicj4NCjxicj4NCk5hbWU6PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1z cGFuIj4gPC9zcGFuPmRyYWZ0LWR1bmJhci1pMm5zZi1wcm9ibGVtLXN0YXRlbWVudDxicj4NClJl dmlzaW9uOjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+IDwvc3Bhbj4wNDxicj4NClRpdGxl OjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+IDwvc3Bhbj5JbnRlcmZhY2UgdG8gTmV0d29y ayBTZWN1cml0eSBGdW5jdGlvbnMgKEkyTlNGKSBQcm9ibGVtIFN0YXRlbWVudDxicj4NCkRvY3Vt ZW50IGRhdGU6PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4gPC9zcGFuPjIwMTUtMDUtMjE8 YnI+DQpHcm91cDo8c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiA8L3NwYW4+SW5kaXZpZHVh bCBTdWJtaXNzaW9uPGJyPg0KUGFnZXM6PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4gPC9z cGFuPjIwPGJyPg0KVVJMOiAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9p bnRlcm5ldC1kcmFmdHMvZHJhZnQtZHVuYmFyLWkybnNmLXByb2JsZW0tc3RhdGVtZW50LTA0LnR4 dCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWR1bmJhci1pMm5z Zi1wcm9ibGVtLXN0YXRlbWVudC0wNC50eHQ8L2E+PGJyPg0KU3RhdHVzOiAmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSJodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1kdW5iYXItaTJuc2YtcHJvYmxlbS1zdGF0ZW1lbnQv Ij5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1kdW5iYXItaTJuc2YtcHJv YmxlbS1zdGF0ZW1lbnQvPC9hPjxicj4NCkh0bWxpemVkOiAmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt ZHVuYmFyLWkybnNmLXByb2JsZW0tc3RhdGVtZW50LTA0Ij5odHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtZHVuYmFyLWkybnNmLXByb2JsZW0tc3RhdGVtZW50LTA0PC9hPjxicj4NCkRp ZmY6ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1k dW5iYXItaTJuc2YtcHJvYmxlbS1zdGF0ZW1lbnQtMDQiPmh0dHBzOi8vd3d3LmlldGYub3JnL3Jm Y2RpZmY/dXJsMj1kcmFmdC1kdW5iYXItaTJuc2YtcHJvYmxlbS1zdGF0ZW1lbnQtMDQ8L2E+PGJy Pg0KPGJyPg0KQWJzdHJhY3Q6PGJyPg0KJm5ic3A7Jm5ic3A7VGhpcyBkb2N1bWVudCBkZXNjcmli ZXMgdGhlIG1vdGl2YXRpb24gYW5kIHRoZSBwcm9ibGVtIHN0YXRlbWVudCBmb3I8YnI+DQombmJz cDsmbmJzcDtJbnRlcmZhY2UgdG8gTmV0d29yayBTZWN1cml0eSBGdW5jdGlvbnMgKEkyTlNGKS48 YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtl IGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRo ZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQNCjxhIGhyZWY9Imh0 dHA6Ly90b29scy5pZXRmLm9yZyI+dG9vbHMuaWV0Zi5vcmc8L2E+Ljxicj4NCjxicj4NClRoZSBJ RVRGIFNlY3JldGFyaWF0PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQpJMm5zZiBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJt YWlsdG86STJuc2ZAaWV0Zi5vcmciPkkybnNmQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaTJuc2YiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaTJuc2Y8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPi0tPGJyPg0K JnF1b3Q7RXN0YSB2ZXogbm8gZmFsbGFyZW1vcywgRG9jdG9yIEluZmllcm5vJnF1b3Q7PGJyPg0K PGJyPg0KRHIgRGllZ28gUi4gTG9wZXo8YnI+DQpUZWxlZm9uaWNhIEkmIzQzO0Q8YnI+DQo8YSBo cmVmPSJodHRwOi8vcGVvcGxlLnRpZC5lcy9kaWVnby5sb3Blei8iPmh0dHA6Ly9wZW9wbGUudGlk LmVzL2RpZWdvLmxvcGV6LzwvYT48YnI+DQo8YnI+DQplLW1haWw6IDxhIGhyZWY9Im1haWx0bzpk aWVnby5yLmxvcGV6QHRlbGVmb25pY2EuY29tIj5kaWVnby5yLmxvcGV6QHRlbGVmb25pY2EuY29t PC9hPjxicj4NClRlbDogJm5ic3A7ICZuYnNwOyYjNDM7MzQgOTEzIDEyOSAwNDE8YnI+DQpNb2Jp bGU6ICYjNDM7MzQgNjgyIDA1MSAwOTE8YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249 ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj4NCjxociBzaXplPSIzIiB3aWR0aD0i MTAwJSIgYWxpZ249ImNlbnRlciI+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpncmF5Ij48YnI+DQpFc3RlIG1lbnNhamUgeSBzdXMg YWRqdW50b3Mgc2UgZGlyaWdlbiBleGNsdXNpdmFtZW50ZSBhIHN1IGRlc3RpbmF0YXJpbywgcHVl ZGUgY29udGVuZXIgaW5mb3JtYWNpw7NuIHByaXZpbGVnaWFkYSBvIGNvbmZpZGVuY2lhbCB5IGVz IHBhcmEgdXNvIGV4Y2x1c2l2byBkZSBsYSBwZXJzb25hIG8gZW50aWRhZCBkZSBkZXN0aW5vLiBT aSBubyBlcyB1c3RlZC4gZWwgZGVzdGluYXRhcmlvIGluZGljYWRvLCBxdWVkYSBub3RpZmljYWRv IGRlIHF1ZSBsYQ0KIGxlY3R1cmEsIHV0aWxpemFjacOzbiwgZGl2dWxnYWNpw7NuIHkvbyBjb3Bp YSBzaW4gYXV0b3JpemFjacOzbiBwdWVkZSBlc3RhciBwcm9oaWJpZGEgZW4gdmlydHVkIGRlIGxh IGxlZ2lzbGFjacOzbiB2aWdlbnRlLiBTaSBoYSByZWNpYmlkbyBlc3RlIG1lbnNhamUgcG9yIGVy cm9yLCBsZSByb2dhbW9zIHF1ZSBub3MgbG8gY29tdW5pcXVlIGlubWVkaWF0YW1lbnRlIHBvciBl c3RhIG1pc21hIHbDrWEgeSBwcm9jZWRhIGEgc3UgZGVzdHJ1Y2Npw7NuLjxicj4NCjxicj4NClRo ZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyB0cmFuc21pc3Npb24gaXMgcHJpdmlsZWdl ZCBhbmQgY29uZmlkZW50aWFsIGluZm9ybWF0aW9uIGludGVuZGVkIG9ubHkgZm9yIHRoZSB1c2Ug b2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IG5hbWVkIGFib3ZlLiBJZiB0aGUgcmVhZGVyIG9m IHRoaXMgbWVzc2FnZSBpcyBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBoZXJl Ynkgbm90aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwNCiBkaXN0cmlidXRpb24gb3IgY29w eWluZyBvZiB0aGlzIGNvbW11bmljYXRpb24gaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gSWYgeW91 IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4gZXJyb3IsIGRvIG5vdCByZWFkIGl0 LiBQbGVhc2UgaW1tZWRpYXRlbHkgcmVwbHkgdG8gdGhlIHNlbmRlciB0aGF0IHlvdSBoYXZlIHJl Y2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciBhbmQgdGhlbiBkZWxldGUgaXQuPGJy Pg0KPGJyPg0KRXN0YSBtZW5zYWdlbSBlIHNldXMgYW5leG9zIHNlIGRpcmlnZW0gZXhjbHVzaXZh bWVudGUgYW8gc2V1IGRlc3RpbmF0w6FyaW8sIHBvZGUgY29udGVyIGluZm9ybWHDp8OjbyBwcml2 aWxlZ2lhZGEgb3UgY29uZmlkZW5jaWFsIGUgw6kgcGFyYSB1c28gZXhjbHVzaXZvIGRhIHBlc3Nv YSBvdSBlbnRpZGFkZSBkZSBkZXN0aW5vLiBTZSBuw6NvIMOpIHZvc3NhIHNlbmhvcmlhIG8gZGVz dGluYXTDoXJpbyBpbmRpY2FkbywgZmljYSBub3RpZmljYWRvIGRlIHF1ZSBhDQogbGVpdHVyYSwg dXRpbGl6YcOnw6NvLCBkaXZ1bGdhw6fDo28gZS9vdSBjw7NwaWEgc2VtIGF1dG9yaXphw6fDo28g cG9kZSBlc3RhciBwcm9pYmlkYSBlbSB2aXJ0dWRlIGRhIGxlZ2lzbGHDp8OjbyB2aWdlbnRlLiBT ZSByZWNlYmV1IGVzdGEgbWVuc2FnZW0gcG9yIGVycm8sIHJvZ2Ftb3MtbGhlIHF1ZSBub3MgbyBj b211bmlxdWUgaW1lZGlhdGFtZW50ZSBwb3IgZXN0YSBtZXNtYSB2aWEgZSBwcm9jZWRhIGEgc3Vh IGRlc3RydWnDp8Ojbzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_4A95BA014132FF49AE685FAB4B9F17F657C4BC4Bdfweml701chm_-- From nobody Tue May 26 11:14:49 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD14F1A0277 for ; Tue, 26 May 2015 11:14:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.21 X-Spam-Level: X-Spam-Status: No, score=-6.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id amEPqaUqaDJE for ; Tue, 26 May 2015 11:14:46 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4972A1B2C7B for ; Tue, 26 May 2015 11:14:45 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BSZ32905; Tue, 26 May 2015 18:14:43 +0000 (GMT) Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 26 May 2015 19:14:42 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml705-chm ([10.193.5.142]) with mapi id 14.03.0158.001; Tue, 26 May 2015 11:14:30 -0700 From: Linda Dunbar To: "i2nsf@ietf.org" Thread-Topic: WebEx bridge information for today's I2NSF Interim meeting at 2:30pm EST Thread-Index: AQHQl8x40KJczfz8+kewYq2juEgGdZ2Oj5aA Date: Tue, 26 May 2015 18:14:29 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657C4BC9E@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.47.130.97] Content-Type: multipart/mixed; boundary="_004_4A95BA014132FF49AE685FAB4B9F17F657C4BC9Edfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [I2nsf] WebEx bridge information for today's I2NSF Interim meeting at 2:30pm EST X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 18:14:47 -0000 --_004_4A95BA014132FF49AE685FAB4B9F17F657C4BC9Edfweml701chm_ Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657C4BC9Edfweml701chm_" --_000_4A95BA014132FF49AE685FAB4B9F17F657C4BC9Edfweml701chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Stephanie McCammon > Subject: (Forward to others) WebEx meeting invitation: I2NSF Date: May 26, 2015 at 8:53:26 PDT To: smccammon@amsl.com Reply-To: smccammon@amsl.com You can forward this invitation to others. Hello, Stephanie McCammon invites you to join this WebEx meeting. I2NSF Tuesday, May 26, 2015 2:30 pm | Eastern Daylight Time (New York, GMT-04:00) | 2 hrs Join WebEx meeting Meeting number: 647 424 137 Meeting password: 1234 Join by phone 1-877-668-4493 Call-in toll free number (US/Canada) 1-650-479-3208 Call-in toll number (US/Canada) Access code: 647 424 137 Toll-free calling restrictions Add this meeting to your calendar. Can't join the meeting? Contact support. IMPORTANT NOTICE: Please note that this WebEx service allows audio and othe= r information sent during the session to be recorded, which may be discover= able in a legal matter. By joining this session, you automatically consent = to such recordings. If you do not consent to being recorded, discuss your c= oncerns with the host or do not join the session. --_000_4A95BA014132FF49AE685FAB4B9F17F657C4BC9Edfweml701chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

From: Stephanie McCammon <messenger@w= ebex.com>

Subject: (Forward to others) WebEx meeting invitati= on: I2NSF

Date: May 26, 2015 at 8:53:26 PDT

To: smccammon@amsl.com<= /o:p>

Reply-To: smccammon@amsl.com

 

You can forward this invitation to others.

 

Hello,

Stephanie McCammon invites you to join this WebEx m= eeting.

 

 

 

I2NSF

Tuesday, May 26, 2015

2:30 pm  |  Eastern Daylight Ti= me (New York, GMT-04:00)  |  2 hrs

 

 

 

Join WebEx meeting

 

Meeting number:

647 424 137

Meeting password:

1234

 

 

 

Join by phone=

1-877-668-4493 Call-in toll free number (US/Canada)

1-650-479-3208 Call-in toll number (US/Canada)

Access code: 647 424 137

Toll-free calling restrictions

 

 

 

Add this meeting to your calendar.

 

 

 

Can't join the meeting? Contact support.=

 

 

 

IMPORTANT NOTICE: Please note that this WebEx servi= ce allows audio and other information sent during the session to be recorde= d, which may be discoverable in a legal matter. By joining this session, you automatically consent to such recordings. If you do not = consent to being recorded, discuss your concerns with the host or do not jo= in the session.

 

--_000_4A95BA014132FF49AE685FAB4B9F17F657C4BC9Edfweml701chm_-- --_004_4A95BA014132FF49AE685FAB4B9F17F657C4BC9Edfweml701chm_ Content-Type: text/calendar; name="WebEx_Meeting.ics" Content-Description: WebEx_Meeting.ics Content-Disposition: attachment; filename="WebEx_Meeting.ics"; size=3806; creation-date="Tue, 26 May 2015 15:56:04 GMT"; modification-date="Tue, 26 May 2015 15:56:04 GMT" Content-ID: Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSClBST0RJRDotLy9NaWNyb3NvZnQgQ29ycG9yYXRpb24vL091dGxvb2sg MTAuMCBNSU1FRElSLy9FTgpWRVJTSU9OOjIuMApNRVRIT0Q6UkVRVUVTVApCRUdJTjpWVElNRVpP TkUKVFpJRDpFYXN0ZXJuIFRpbWUKQkVHSU46U1RBTkRBUkQKRFRTVEFSVDoyMDEzMTEwMVQwMjAw MDAKUlJVTEU6RlJFUT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0xU1U7QllNT05USD0xMQpUWk9G RlNFVEZST006LTA0MDAKVFpPRkZTRVRUTzotMDUwMApUWk5BTUU6U3RhbmRhcmQgVGltZQpFTkQ6 U1RBTkRBUkQKQkVHSU46REFZTElHSFQKRFRTVEFSVDoyMDEzMDMwMVQwMjAwMDAKUlJVTEU6RlJF UT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0yU1U7QllNT05USD0zClRaT0ZGU0VURlJPTTotMDUw MApUWk9GRlNFVFRPOi0wNDAwClRaTkFNRTpEYXlsaWdodCBTYXZpbmdzIFRpbWUKRU5EOkRBWUxJ R0hUCkVORDpWVElNRVpPTkUKQkVHSU46VkVWRU5UCkFUVEVOREVFO0NOPSJTdGVwaGFuaWUgTWND YW1tb24iO1JPTEU9UkVRLVBBUlRJQ0lQQU5UO1JTVlA9VFJVRTpNQUlMVE86c21jY2FtbW9uQGFt c2wuY29tCk9SR0FOSVpFUjtDTj0iU3RlcGhhbmllIE1jQ2FtbW9uIjpNQUlMVE86c21jY2FtbW9u QGFtc2wuY29tCkRUU1RBUlQ7VFpJRD0iRWFzdGVybiBUaW1lIjoyMDE1MDUyNlQxNDMwMDAKRFRF TkQ7VFpJRD0iRWFzdGVybiBUaW1lIjoyMDE1MDUyNlQxNjMwMDAKTE9DQVRJT046aHR0cHM6Ly9p ZXRmLndlYmV4LmNvbS9pZXRmClRSQU5TUDpPUEFRVUUKU0VRVUVOQ0U6MTQzMjY1NTYwNgpVSUQ6 YjAyOTliMzEtNTdiYi00YTVjLWJhOTMtMDU1NDg0ZDdkYWQwCkRUU1RBTVA6MjAxNTA1MjZUMTgz MDAwWgpERVNDUklQVElPTjpcblxuXG5KT0lOIFdFQkVYIE1FRVRJTkdcbmh0dHBzOi8vaWV0Zi53 ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW00MWE0YzliOTkyYWM3NDEzYzYzNTM2MDk5OTMyNzM3 YVxuTWVldGluZyBudW1iZXI6IDY0NyA0MjQgMTM3XG5NZWV0aW5nIHBhc3N3b3JkOiAxMjM0XG5c blxuSk9JTiBCWSBQSE9ORVxuMS04NzctNjY4LTQ0OTMgQ2FsbC1pbiB0b2xsIGZyZWUgbnVtYmVy IChVUy9DYW5hZGEpIFxuMS02NTAtNDc5LTMyMDggQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2Fu YWRhKVxuQWNjZXNzIGNvZGU6IDY0NyA0MjQgMTM3XG5cblRvbGwtZnJlZSBkaWFsaW5nIHJlc3Ry aWN0aW9uczogXG5odHRwOi8vd3d3LndlYmV4LmNvbS9wZGYvdG9sbGZyZWVfcmVzdHJpY3Rpb25z LnBkZlxuXG5cblxuQ2FuJ3Qgam9pbiB0aGUgbWVldGluZz8gQ29udGFjdCBzdXBwb3J0IGhlcmU6 XG5odHRwczovL2lldGYud2ViZXguY29tL2lldGYvbWNcblxuXG5JTVBPUlRBTlQgTk9USUNFOiBQ bGVhc2Ugbm90ZSB0aGF0IHRoaXMgV2ViRXggc2VydmljZSBhbGxvd3MgYXVkaW8gYW5kIG90aGVy IGluZm9ybWF0aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNzaW9uIHRvIGJlIHJlY29yZGVkLCB3aGlj aCBtYXkgYmUgZGlzY292ZXJhYmxlIGluIGEgbGVnYWwgbWF0dGVyLiBCeSBqb2luaW5nIHRoaXMg c2Vzc2lvbiwgeW91IGF1dG9tYXRpY2FsbHkgY29uc2VudCB0byBzdWNoIHJlY29yZGluZ3MuIElm IHlvdSBkbyBub3QgY29uc2VudCB0byBiZWluZyByZWNvcmRlZCwgZGlzY3VzcyB5b3VyIGNvbmNl cm5zIHdpdGggdGhlIGhvc3Qgb3IgZG8gbm90IGpvaW4gdGhlIHNlc3Npb24uXG4KWC1BTFQtREVT QztGTVRUWVBFPXRleHQvaHRtbDoJPEZPTlQgU0laRT0iMSIgRkFDRT0iQVJJQUwiPiZuYnNwOzxC Uj4gPEZPTlQgU0laRT0iNCIgRkFDRT0iQVJJQUwiPgkJPGEJCQkJCWhyZWY9Imh0dHBzOi8vaWV0 Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW00MWE0YzliOTkyYWM3NDEzYzYzNTM2MDk5OTMy NzM3YSI+PEZPTlQgU0laRT0iMyIgQ09MT1I9IiMwMEFGRjkiIEZBQ0U9IkFyaWFsIj5Kb2luIFdl YkV4IG1lZXRpbmc8L0ZPTlQ+PC9hPgkJCTx0YWJsZT4JCQkJPHRyPgkJCQkJPHRkPgkJCQkJCTxG T05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+TWVldGluZyBudW1iZXI6 PC9GT05UPgkJCQkJPC90ZD4JCQkJCTx0ZD4JCQkJCQk8Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2 NjY2NiIgRkFDRT0iYXJpYWwiPjY0NyA0MjQgMTM3PC9GT05UPgkJCQkJPC90ZD4JCQkJPC90cj4J CQk8L3RhYmxlPgkJCTx0YWJsZT48dHI+PHRkPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2 IiBGQUNFPSJhcmlhbCI+TWVldGluZyBwYXNzd29yZDo8L0ZPTlQ+PC90ZD48dGQ+PEZPTlQgU0la RT0iMiIgIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+MTIzNDwvRk9OVD48L3RkPjwvdHI+ PC90YWJsZT4JCTwvRk9OVD48Rk9OVCBTSVpFPSIxIiBGQUNFPSJBUklBTCI+Jm5ic3A7PEJSPiZu YnNwOzxCUj48L0ZPTlQ+PEZPTlQgU0laRT0iNCIgRkFDRT0iQVJJQUwiPjxGT05UIFNJWkU9IjMi IENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+Sm9pbiBieSBwaG9uZTwvRk9OVD4mbmJzcDsg PEJSPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+PHN0cm9uZz4x LTg3Ny02NjgtNDQ5Mzwvc3Ryb25nPiZuYnNwO0NhbGwtaW4gdG9sbCBmcmVlIG51bWJlciAoVVMv Q2FuYWRhKTwvRk9OVD4mbmJzcDsgPEJSPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBG QUNFPSJhcmlhbCI+PHN0cm9uZz4xLTY1MC00NzktMzIwODwvc3Ryb25nPiZuYnNwO0NhbGwtaW4g dG9sbCBudW1iZXIgKFVTL0NhbmFkYSk8L0ZPTlQ+Jm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBD T0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPkFjY2VzcyBjb2RlOiA2NDcgNDI0IDEzNzwvRk9O VD4mbmJzcDsgPEJSPjxhIGhyZWY9Imh0dHA6Ly93d3cud2ViZXguY29tL3BkZi90b2xsZnJlZV9y ZXN0cmljdGlvbnMucGRmIj48Rk9OVCBTSVpFPSIxIiBDT0xPUj0iIzAwQUZGOSIgRkFDRT0iYXJp YWwiPlRvbGwtZnJlZSBjYWxsaW5nIHJlc3RyaWN0aW9uczwvRk9OVD48L2E+ICZuYnNwOyA8QlI+ PC9GT05UPjxCUj48QlI+CSZuYnNwOzxCUj4JPEZPTlQgU0laRT0iMSIgQ09MT1I9IiM2NjY2NjYi IEZBQ0U9ImFyaWFsIj4JCQkJQ2FuJ3Qgam9pbiB0aGUgbWVldGluZz88L0ZPTlQ+CTxhIGhyZWY9 Imh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9tYyI+CTxGT05UIFNJWkU9IjEiIENPTE9SPSIj MDBBRkY5IiBGQUNFPSJBcmlhbCI+Q29udGFjdCBzdXBwb3J0LjwvRk9OVD48L2E+CSZuYnNwOzxC Uj4mbmJzcDs8QlI+PEZPTlQgQ09MT1I9IiNBMEEwQTAiIHNpemU9IjEiIEZBQ0U9ImFyaWFsIj5J TVBPUlRBTlQgTk9USUNFOiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgV2ViRXggc2VydmljZSBhbGxv d3MgYXVkaW8gYW5kIG90aGVyIGluZm9ybWF0aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNzaW9uIHRv IGJlIHJlY29yZGVkLCB3aGljaCBtYXkgYmUgZGlzY292ZXJhYmxlIGluIGEgbGVnYWwgbWF0dGVy LiBCeSBqb2luaW5nIHRoaXMgc2Vzc2lvbiwgeW91IGF1dG9tYXRpY2FsbHkgY29uc2VudCB0byBz dWNoIHJlY29yZGluZ3MuIElmIHlvdSBkbyBub3QgY29uc2VudCB0byBiZWluZyByZWNvcmRlZCwg ZGlzY3VzcyB5b3VyIGNvbmNlcm5zIHdpdGggdGhlIGhvc3Qgb3IgZG8gbm90IGpvaW4gdGhlIHNl c3Npb24uPC9GT05UPjwvRk9OVD4KU1VNTUFSWTpJMk5TRgpQUklPUklUWTo1CkNMQVNTOlBVQkxJ QwpCRUdJTjpWQUxBUk0KVFJJR0dFUjotUFQ1TQpBQ1RJT046RElTUExBWQpERVNDUklQVElPTjpS ZW1pbmRlcgpFTkQ6VkFMQVJNCkVORDpWRVZFTlQKRU5EOlZDQUxFTkRBUgo= --_004_4A95BA014132FF49AE685FAB4B9F17F657C4BC9Edfweml701chm_-- From nobody Tue May 26 12:09:09 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 056AA1ACDDE for ; Tue, 26 May 2015 12:09:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.154 X-Spam-Level: X-Spam-Status: No, score=-94.154 tagged_above=-999 required=5 tests=[BAYES_95=3, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K7IDNE9NluUP for ; Tue, 26 May 2015 12:09:07 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 090C91B2FFB for ; Tue, 26 May 2015 12:08:54 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.178.112; From: "Susan Hares" To: Date: Tue, 26 May 2015 15:08:53 -0400 Message-ID: <000901d097e7$689b1d60$39d15820$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000A_01D097C5.E189F290" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdCX52HRWiZAR4yaQ36HLoWgZzcSgg== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [I2nsf] Could we avoid - I2RS, IDR, NFVrg, SDNrg X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 19:09:09 -0000 This is a multipart message in MIME format. ------=_NextPart_000_000A_01D097C5.E189F290 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Could we avoid - I2RS, IDR, NFVrg, SDNrg as conflicts? Sue ------=_NextPart_000_000A_01D097C5.E189F290 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Could we = avoid - I2RS, IDR, NFVrg, SDNrg as conflicts?

 

Sue =

------=_NextPart_000_000A_01D097C5.E189F290-- From nobody Tue May 26 15:46:18 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC791B32DD for ; Tue, 26 May 2015 15:46:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s9UVfjvUSzYg for ; Tue, 26 May 2015 15:46:12 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 893881B32CF for ; Tue, 26 May 2015 15:46:11 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BSZ45150; Tue, 26 May 2015 22:46:10 +0000 (GMT) Received: from DFWEML703-CHM.china.huawei.com (10.193.5.130) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 26 May 2015 23:46:09 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml703-chm ([10.193.5.130]) with mapi id 14.03.0158.001; Tue, 26 May 2015 15:46:05 -0700 From: Linda Dunbar To: "i2nsf@ietf.org" Thread-Topic: minutes of I2NSF Interim meeting to reach consensus on I2NSF charter and clarify the problem space Thread-Index: AdCYBb9eHjH+FPttRpmr964nD/3bFw== Date: Tue, 26 May 2015 22:46:05 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657C4BE5D@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.130.97] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657C4BE5Ddfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [I2nsf] minutes of I2NSF Interim meeting to reach consensus on I2NSF charter and clarify the problem space X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 22:46:17 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F657C4BE5Ddfweml701chm_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Time: May 26, 2015; 2:30pm - 3:30pm EST Participants: Charif Mahamoudi; Dan Romascanu; Daniel Migault; Ed Lopez; Joe Salowey; Kat= hleen Moriaty; Myo Zarny; Susan Hares; Linda Dunbar; Highlight of the discussion: Problem space discussion: We went through the bullets listed under the I2NSF problem space. Made clar= ification on "Profiles" associated with NSFs, and shuffled some issues amon= g the categories. Here is the refined I2NSF problem space (which will be in= corporated into the next revision of the I2NSF problem statement) Challenges Facing Security Service Providers: - Diverse types of Security Functions No Standard Characterization of NSFs - Diverse Interfaces to Control NSFs - Diverse Interface to monitor the behavior of NSFs - More Distributed NSFs and vNSFs - Demand to Control NSFs Dynamically - Demand for multi-tenancy of the interfaces to control and monitor NSFs. Service providers may well require having several operational units to make= this control and monitoring, especially when they become distributed and v= irtualized - Lack of Standard Interface for Capability Exchange (between controller = and NSFs - Lack of Standard Interface to reference external profiles to NSF (e.g. = Signatures needed by IPS/IDS, BlackList DB by WebFilter) o Different policies might need different Signatures =B7 Grouping Signatures for different policies o Open Source provided signatures/profiles (e.g. by Snort, others), o Focus on the envelop of the format, allow vendors to exchange Challenges Facing Customers: - Need consistent integration of NSFs over heterogeneous administrative d= omains - Today's Policy Expressions are Vendors Specific - Difficulty to Monitor the Execution of Desired Policies o Difficulty to Validate Policies across Multiple Domains I2NSF Charter Discussion: We discussed the distinction between Configuration and Policy Provisioning.= It is emphasized that Configuration is more like the bootstrap for getting= NSFs started (like addresses, ports, etc); the Policy Provisioning is for = dictating the running behavior. We used the definition from draft-lopez-i2n= sf-packet-00: - Configuration - deals with the management and configuration of the NSF = device itself. - Signaling - which represents logging and query functions between the NS= F and external systems. - Provisioning - used to control the security functions of NSFs. It is agreed that "capability or resource negotiation" will be added to the= draft. We agreed to elaborate on the "Policies" used by I2NSF in the charter becau= se "Policy" can mean so many different things. I2NSF is not talking about i= nterpretation of policy: e.g. can't make changes out of maintenance window.= I2NSF only focuses on the polices that NSFs can implement. Add a descripti= on on what kind of policies are in the scope of I2NSF (Charter). Is "allowing 3rd party signature/profile" within the configuration domain? Network Security Function (NSF): functions to ensure integrity, confidentia= lity and availability of network communications, to detect unwanted activit= y, and to block it or at least mitigate its effects on the network. Conflicts to avoid: SACM, SAAS, nfvrg, I2RS, IDR, SDNrg, TRILL, LMAP, XRBLO= CK, SUPA, SFC, NVO3 Proper Agenda for the BOF - Introduction of I2NSF BOF (Chairs, 10 min) - Use cases - Diego (10 min) - Problem Space (10 min) - Gap analysis -(Potential technologies): Bob Moskowitz/DaChen/Hos= nieh Rafiee o Is it within IETF scope & expertise? (why not OpenStack, security allia= nce =A7 What specific value IETF can provide o Why this WG? =A7 Why not done at SACM, I2RS, NETCONF, NETMOD, SFC, ANIMA, PCP...? - Potential solutions: o Packet-Based Paradigm For Interfaces To NSFs - Ed Lopez o Capability layer interface Information Model - Frank Xia o - Charter (30 min) Hard questions (30 min) (Do people feel like they have sufficient informati= on to answer the following questions? or is it premature to even ask the q= uestions?) - Does the community think that the problem statement is clear, we= ll-scoped, solvable, and useful to solve? - Who would be willing to contribute? Writing drafts or source cod= e (e.g. create a branch at IETF Hackathon)? - Can I see a show of hands of folk willing to review documents (o= r comment on the mailing list) - Is there support to form a WG with the proposed charter? o Does the community think that given the charter revisions discussed dur= ing the BOF (subject to review and finalization on the mailing list), a WG = should be formed? - How many people feel that a WG should not be formed? Thanks, Linda Dunbar --_000_4A95BA014132FF49AE685FAB4B9F17F657C4BE5Ddfweml701chm_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable --_000_4A95BA014132FF49AE685FAB4B9F17F657C4BE5Ddfweml701chm_-- From nobody Thu May 28 12:53:08 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA7EA1A8877 for ; Thu, 28 May 2015 12:53:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I0jpkHDOnX-N for ; Thu, 28 May 2015 12:53:01 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0241F1A8871 for ; Thu, 28 May 2015 12:53:00 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BTB62626; Thu, 28 May 2015 19:52:59 +0000 (GMT) Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 28 May 2015 20:52:58 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml705-chm ([10.193.5.142]) with mapi id 14.03.0158.001; Thu, 28 May 2015 12:52:56 -0700 From: Linda Dunbar To: "i2nsf@ietf.org" Thread-Topic: I2NSF Charter as the result of May 26 Interim meeting (removed the term "Policy" because it carries too many meanings). Thread-Index: AdCZf+RdeQLDRxtrQDGM5bHBFmMdQQ== Date: Thu, 28 May 2015 19:52:56 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657C4D13C@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.74] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657C4D13Cdfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [I2nsf] I2NSF Charter as the result of May 26 Interim meeting (removed the term "Policy" because it carries too many meanings). X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 19:53:07 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F657C4D13Cdfweml701chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Network Security Function (NSF) is to ensure integrity, confidentiality and= availability of network communications, to detect unwanted activity, and t= o block it or at least mitigate its effects. NSFs are 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 e= nterprise, service providers, or a combination of both. Likewise, service p= roviders of NSFs may offer their customers network security services that c= onsist of multiple security products and/or functions from different vendor= s. NSFs may be provided by physical and/or virtualized infrastructure. With= out standard interfaces to control and monitor the behavior of NSFs, it has= become virtually impossible for security service providers to automate ser= vice offerings that utilize different security functions from multiple vend= ors. The primary goal of I2NSF is to define an information model, a set of softw= are interfaces and data models for controlling and monitoring aspects of ph= ysical and virtual NSFs. Other aspects of NSFs, such as device or network p= rovisioning and configuration, are out of scope. Controlling and monitoring= of NSFs should include the ability to specify, query, monitor, and control= the NSFs by one or more management entities. Since different security vend= ors support different features and functions on their devices, I2NSF will f= ocus on flow-based NSFs that provide treatment to packets/flows, such as IP= S/IDS, Web filtering, flow filtering, deep packet inspection, or pattern ma= tching and remediation. There are two layers of interfaces envisioned in the I2NSF approach: * The I2NSF Capability Layer specifies how to control and monitor NSF= s at a functional implementation level. That is, I2NSF will standardize a s= et of interfaces by which control and management of NSFs may be invoked, op= erated, and monitored. (I2NSF will not work on any other aspects of NSFs. N= or will I2NSF at this stage specify how to derive control and monitoring ca= pabilities from higher level security policies for the Capability Layer.) * The I2NSF Service Layer defines how clients' security policies may = be expressed and monitored. The Service Layer is out of scope for this phas= e of I2NSF's work. However, I2NSF will provide a forum for Informational dr= afts on data models, APIs, etc. that demonstrate how service layer policies= may be translated to Capability Layer functions. The concrete work at the I2NSF Capability Layer includes development of - An information model that defines concepts required for standard= izing the control and monitoring of NSFs. - A set of YANG data models, derived from the above information mo= del. - The capability registry (IANA) that enables the characteristics = and behavior of NSFs to be specified using a vendor-neutral vocabulary with= out requiring the NSFs themselves to be standardized. The registry enables = various mechanisms, including policy rules, to be used to match monitor and= control functions to the needs of an application and/or environment. - The proper secure communication channels to carry the controllin= g and monitoring information between the NSFs and their management entity (= or entities). Standard interfaces for monitoring and controlling the behavior of NSFs are= essential building blocks for Security Service Providers to automate the u= se of different NSFs from multiple vendors by their Security management ent= ities. This work will leverage the existing protocols and data models defin= ed by I2RS, Netconf, and NETMOD. . If extensions to these protocols are nee= ded, requirements will be developed by this WG, and the extensions will be = developed in cooperation with the WGs responsible for the protocols. The I2NSF WG's deliverables include: - Use cases, problem statement, gap analysis document [The WG will= decide if to proceed as RFC]. - Framework Document, presenting an overview of the use of NSFs an= d the purpose of the models developed by the WG [The WG will decide if to p= roceed as RFC]. - A single, unified, Information Model for controlling and monitor= ing flow-based NSFs. Corresponding YANG Data Models derived from the above Information Model. - IANA registry consideration for flow-based NSFs controlling and = monitoring capabilities.[maybe merged into data models] The WG may additionally choose to develop additional documents to describe = requirements for extensions (if any) to existing protocols used by the WG, = and how the data models are used to monitor and control flow-based NSFs, an= d to describe how to use I2RS, Netconf, and NETMOD to carry the content of = the data models. [The WG may decide that the Use cases, Framework, and gap analysis are simp= ly reference documents during the lifetime of the WG and not to be publishe= d as an RFC.] The WG will work closely with I2RS, Netconf and Netmod WGs. The WG will com= municate with external SDOs like ETSI NFV and will encourage open source co= de development related to the WG scope in organizations like ONF, OpenStack= , ODL, and OPNFV. Suggested Milestones - Use Cases, problem statement, and gap analysis Document: Charter time = + 1 month - Framework: Charter time + 4 months to WG Document - Requirements for extensions to protocols: Charter time + 8 months to W= G document - Info model: Charter time + 8 months to WG Document - IANA registry consideration + 12 months to WG Document - All Early Drafts to IESG: 18 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 - 18 months --_000_4A95BA014132FF49AE685FAB4B9F17F657C4D13Cdfweml701chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Network Security Functio= n (NSF) is to ensure integrity, confidentiality and availability of network= communications, to detect unwanted activity, and to block it or at least m= itigate its effects. NSFs are provided and consumed in increa= singly diverse environments. Users of NSFs could consume network security s= ervices hosted by one or more providers, which may be their own enterprise,= service providers, or a combination of both. Likewise, service providers of NSFs may offer their customers net= work security services that consist of multiple security products and/or fu= nctions from different vendors. NSFs may be provided by physical and/or vir= tualized infrastructure. Without standard interfaces to control and monitor the behavior of NSFs, it has be= come virtually impossible for security service providers to automate servic= e offerings that utilize different security functions from multiple vendors= .

 =

The primary goal of I2NS= F is to define an information model, a set of software interfaces and data = models for controlling and monitoring aspects of physical and virtual NSFs.= Other aspects of NSFs, such as device or network provisioning and configuration, are out of scope. Controlling a= nd monitoring of NSFs should include the ability to specify, query, monitor= , and control the NSFs by one or more management entities. Since different security vendors support different features and func= tions on their devices, I2NSF will focus on flow-based NSFs that provide tr= eatment to packets/flows, such as IPS/IDS, Web filtering, flow filtering, d= eep packet inspection, or pattern matching and remediation.

 =

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

 =

·       The I2NSF Capabi= lity Layer specifies how to control and monitor NSFs at a functional implem= entation level. That is, I2NSF will standardize a set of interfaces by whic= h control and management of NSFs may be invoked, operated, and monitored. (I2NSF will not work on any other asp= ects of NSFs. Nor will I2NSF at this stage specify how to derive control an= d monitoring capabilities from higher level security policies for the Capab= ility Layer.)

 =

·       The I2NSF Servic= e Layer defines how clients’ security policies may be expressed and m= onitored. The Service Layer is out of scope for this phase of I2NSF’s= work. However, I2NSF will provide a forum for Informational drafts on data models, APIs, etc. that demonstrate how servi= ce layer policies may be translated to Capability Layer functions.

 

The concrete work at the I2NSF Capability Layer incl= udes development of

-  &= nbsp;       An information model that defines concepts r= equired for standardizing the control and monitoring of NSFs.

-  &= nbsp;       A set of YANG data models, derived from the = above information model.

-  &= nbsp;       The capability registry (IANA) that enables = the characteristics and behavior of NSFs to be specified using a vendor-neu= tral vocabulary without requiring the NSFs themselves to be standardized. T= he registry enables various mechanisms, including policy rules, to be used to match monitor and control functions = to the needs of an application and/or environment.

-  &= nbsp;       The proper secure communication channels to = carry the controlling and monitoring information between the NSFs and their= management entity (or entities).

 

Standard interfaces for monitoring and controlling t= he behavior of NSFs are essential building blocks for Security Service Prov= iders to automate the use of different NSFs from multiple vendors by their = Security management entities. This work will leverage the existing protocols and data models defined by I2RS,= Netconf, and NETMOD. . If extensions to these protocols are needed, requir= ements will be developed by this WG, and the extensions will be developed i= n cooperation with the WGs responsible for the protocols.

 

 

The I2NSF WG’s deliverables include:

 

-       = ;   Use cases, problem statement, gap analysis document= [The WG will decide if to proceed as RFC].

-       = ;   Framework Document, presenting an overview of the u= se of NSFs and the purpose of the models developed by the WG [The WG will d= ecide if to proceed as RFC].

-       = ;   A single, unified, Information Model for controllin= g and monitoring flow-based NSFs.

Corresponding YA= NG Data Models derived from the above Information Model.

-       = ;   IANA registry consideration for flow-based NSFs con= trolling and monitoring capabilities.[maybe merged into data models]

 

The WG may additionally choose to develop= additional documents to describe requirements for extensions (if any) to e= xisting protocols used by the WG, and how the data models are used to monitor and control flow-based NSFs, and to describe how to us= e I2RS, Netconf, and NETMOD to carry the content of the data models.

 

[The W= G may decide that the Use cases, Framework, and gap analysis are simply ref= erence documents during the lifetime of the WG and not to be published as an RFC.]

The WG will work closely with I2RS, Netconf and Netm= od WGs. The WG will communicate with external SDOs like ETSI NFV and will e= ncourage open source code development related to the WG scope in organizati= ons like ONF, OpenStack, ODL, and OPNFV.

 

Suggested Milestones

  - Use Cases, problem statement, and gap analy= sis Document:  Charter time + 1 month

  - Framework: Charter time + 4 months to W= G Document

  - Requirements for extensions to protocols:&n= bsp; Charter time + 8 months to WG document

  - Info model: Charter time + 8 months to = WG Document

  - IANA registry consideration + 12 months= to WG Document

  - All Early Drafts to IESG: 18 months

 

[decision point – +10 months]  <= /o:p>

  - Data Models: Charter + 9 Months to= WG Document

  - Applicability Statements: 10 months to WG D= ocument

  - Data Models and Applicability Statements to= IESG  - 18 months

 

--_000_4A95BA014132FF49AE685FAB4B9F17F657C4D13Cdfweml701chm_-- From nobody Fri May 29 08:38:12 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1945C1A88CA for ; Fri, 29 May 2015 08:38:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c_s7Z9PC49hc for ; Fri, 29 May 2015 08:38:08 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F31B41AC427 for ; Fri, 29 May 2015 08:38:07 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BWQ91509; Fri, 29 May 2015 15:38:00 +0000 (GMT) Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 29 May 2015 16:37:59 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml705-chm ([10.193.5.142]) with mapi id 14.03.0158.001; Fri, 29 May 2015 08:37:53 -0700 From: Linda Dunbar To: "i2nsf@ietf.org" , "'Michael Georgiades'" , "'Nic Leymann'" , "'DIEGO LOPEZ GARCIA'" , "'Romascanu, Dan (Dan)'" , "'Zarny, Myo'" , xiaojun , "'ANTONIO AGUSTIN PASTOR PERALES'" , "'Joseph Salowey'" Thread-Topic: I2NSF Use cases consolidation Thread-Index: AdCaJWyp91AKkqS8SHiKB3pKw2AhcA== Date: Fri, 29 May 2015 15:37:52 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657C4E14B@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.74] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657C4E14Bdfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [I2nsf] I2NSF Use cases consolidation X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2015 15:38:10 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F657C4E14Bdfweml701chm_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable When: Tuesday, June 02, 2015 9:00 AM-10:00 AM (UTC-06:00) Central Time (US = & Canada). Where: Conference bridge Note: The GMT offset above does not reflect daylight saving time adjustment= s. *~*~*~*~*~*~*~*~*~* We need to consolidate the 3 I2NSF use cases drafts: o ?https://datatracker.ietf.org/doc/draft-qi-i2nsf-access-network-use= case/ o ?https://datatracker.ietf.org/doc/draft-pastor-i2nsf-access-usecase= s/ o https://datatracker.ietf.org/doc/draft-zarny-i2nsf-data-center-use-= cases/ o ?https://datatracker.ietf.org/doc/draft-jeong-i2nsf-sdn-security-se= rvices/ Conference bridge will be sent out soon. Linda --_000_4A95BA014132FF49AE685FAB4B9F17F657C4E14Bdfweml701chm_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
When: Tuesday, June 02, 2015 9:00 AM-10:00 AM (UTC-06:00) Central Time= (US & Canada).
Where: Conference bridge
 
Note: The GMT offset above does not reflect daylight saving time adjus= tments.
 
*~*~*~*~*~*~*~*~*~*
 
We need to consolidate the 3 I2NSF use cases drafts:
 

 

Time: May 26, 2015; 2:30pm – 3:30pm&nbs= p; EST

Participants:

Charif Mahamoudi; Dan Rom= ascanu; Daniel Migault; Ed Lopez; Joe Salowey; Kathleen Moriaty; Myo Zarny;= Susan Hares; Linda Dunbar;

Highlight of the discussion:

Problem space discussion:

We went through the bulle= ts listed under the I2NSF problem space. Made clarification on “Profi= les” associated with NSFs, and shuffled some issues among the categor= ies. Here is the refined I2NSF problem space (which will be incorporated into the next revision of the I2NSF problem statement= )

Cha= llenges Facing Security Service Providers:

-   Diverse types of Security Functions

 =         No Standard Characterization of = NSFs

&= nbsp;

-   Diverse Interfaces to Control NSFs

&= nbsp;

-   Diverse Interface to monitor the behavior of NSFs<= o:p>

&= nbsp;

-   More Distributed NSFs and vNSFs<= /p>

&= nbsp;

-   Demand to Control NSFs Dynamically

&= nbsp;

-   Demand for multi-tenancy of the interfaces to cont= rol and monitor NSFs.

&= nbsp;

Servic= e providers may well require having several operational units to make this = control and monitoring, especially when they become distributed and virtual= ized

&= nbsp;

-<= span style=3D"font:7.0pt "Times New Roman"">   Lack of Standard Interface for Capability Exchange (between controller and NSFs

-<= span style=3D"font:7.0pt "Times New Roman"">   Lack of Standard Interface to reference external p= rofiles to NSF (e.g. Signatures needed by IPS/IDS, BlackList DB by WebFilte= r)

o   Different policies might need different Signatures=

=B7       Grouping Signatures for different policies

o   Open Source provided signatures/profiles (e.g. by = Snort, others),

o   Focus on the envelop of the format, allow vendors = to exchange

&= nbsp;

&= nbsp;

 =      Challenges Facing Customers:

-   Need consistent integration of NSFs over heterogen= eous administrative domains

-   Today’s Policy Expressions are Vendors Speci= fic

-   Difficulty to Monitor the Execution of Desired Pol= icies

o   Difficulty to Validate Policies across Multiple Do= mains

&= nbsp;

I2NSF Charter Discussion:

We discussed the distinction between Configuration and Policy Provisioning.= It is emphasized that Configuration is more like the bootstrap for getting= NSFs started (like addresses, ports, etc); the Policy Provisioning is for = dictating the running behavior. We used the definition from draft-lopez-i2nsf-packet-00:

-   Configuration - deals with the management an= d configuration of the NSF device itself.

-   Signaling - which represents logging and que= ry functions between the NSF and external systems.

-   Provisioning - used to control the security = functions of NSFs.

It is agreed that “capability or resource negotiation” will be = added to the draft.

We agreed to elaborate on the “Policies” used by I2NSF in the c= harter because “Policy” can mean so many different things. I2NS= F is not talking about interpretation of policy: e.g. can’t make chan= ges out of maintenance window. I2NSF only focuses on the polices that NSFs can implement. Add a description on what kind of policies  = are in the scope of I2NSF (Charter). 

Is “allowing 3rd party signature/profile” within the= configuration domain?

Network Security Function (NSF): functions to ensure integrity, confidentia= lity and availability of network communications, to detect unwanted activit= y, and to block it or at least mitigate its effects on the network.

 

Conflicts to avoid:<= span style=3D"color:black"> SACM, SAAS, nfvrg, I2RS, IDR, SDNrg, TRILL, LMA= P, XRBLOCK, SUPA, SFC, NVO3

 

Proper Agenda for the BOF

-       = ;   Introduction of I2NSF BOF (Chairs, 10 min)

-       = ;   Use cases – Diego (10 min)

-       = ;   Problem Space (10 min)

-       = ;   Gap analysis –(Potential technologies): Bob M= oskowitz/DaChen/Hosnieh Rafiee

o   Is it within IETF scope & expertise? (wh= y not OpenStack, security alliance

=A7&= nbsp; What specific value IETF can provide

o   Why this WG?

=A7&= nbsp; Why not done at SACM, I2RS, NETCONF, NETMOD,= SFC, ANIMA, PCP…?

-       = ;   Potential solutions:

o   Packet-Based Paradigm For Interfaces To NSFs= – Ed Lopez

o   Capability layer interface Information Model= – Frank Xia

o    

-       = ;   Charter (30 min)

Hard questions (30 min) (Do people feel like they have sufficient informati= on to answer the following questions?  or is it premature to even ask = the questions?)

 

-       = ;   Does the community think that the problem statement= is clear, well-scoped, solvable, and useful to solve?

-       = ;   Who would be willing to contribute? Writing drafts = or source code (e.g. create a branch at IETF Hackathon)?

-       = ;   Can I see a show of hands of folk willing to review= documents (or comment on the mailing list)

-       = ;   Is there support to form a WG with the proposed cha= rter?

o   Does the community think that given the char= ter revisions discussed during the BOF (subject to review and finalization = on the mailing list), a WG should be formed?

-       = ;   How many people feel that a WG should not be formed= ?

&n= bsp;

&nbs= p;

Thanks, Lin= da Dunbar

 
Conference bridge will be sent out soon.
 
Linda
 
--_000_4A95BA014132FF49AE685FAB4B9F17F657C4E14Bdfweml701chm_ Content-Type: text/calendar; charset="utf-8"; method=REQUEST Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSDQpNRVRIT0Q6UkVRVUVTVA0KUFJPRElEOk1pY3Jvc29mdCBFeGNoYW5n ZSBTZXJ2ZXIgMjAxMA0KVkVSU0lPTjoyLjANCkJFR0lOOlZUSU1FWk9ORQ0KVFpJRDpDZW50cmFs IFN0YW5kYXJkIFRpbWUNCkJFR0lOOlNUQU5EQVJEDQpEVFNUQVJUOjE2MDEwMTAxVDAyMDAwMA0K VFpPRkZTRVRGUk9NOi0wNTAwDQpUWk9GRlNFVFRPOi0wNjAwDQpSUlVMRTpGUkVRPVlFQVJMWTtJ TlRFUlZBTD0xO0JZREFZPTFTVTtCWU1PTlRIPTExDQpFTkQ6U1RBTkRBUkQNCkJFR0lOOkRBWUxJ R0hUDQpEVFNUQVJUOjE2MDEwMTAxVDAyMDAwMA0KVFpPRkZTRVRGUk9NOi0wNjAwDQpUWk9GRlNF VFRPOi0wNTAwDQpSUlVMRTpGUkVRPVlFQVJMWTtJTlRFUlZBTD0xO0JZREFZPTJTVTtCWU1PTlRI PTMNCkVORDpEQVlMSUdIVA0KRU5EOlZUSU1FWk9ORQ0KQkVHSU46VkVWRU5UDQpPUkdBTklaRVI7 Q049TGluZGEgRHVuYmFyOk1BSUxUTzpsaW5kYS5kdW5iYXJAaHVhd2VpLmNvbQ0KQVRURU5ERUU7 Uk9MRT1SRVEtUEFSVElDSVBBTlQ7UEFSVFNUQVQ9TkVFRFMtQUNUSU9OO1JTVlA9VFJVRTtDTj1p Mm5zZkBpZXRmDQogLm9yZzpNQUlMVE86aTJuc2ZAaWV0Zi5vcmcNCkFUVEVOREVFO1JPTEU9UkVR LVBBUlRJQ0lQQU5UO1BBUlRTVEFUPU5FRURTLUFDVElPTjtSU1ZQPVRSVUU7Q049J01pY2hhZWwg Rw0KIGVvcmdpYWRlcyc6TUFJTFRPOm1pY2hhZWxnQHByaW1lLXRlbC5jb20NCkFUVEVOREVFO1JP TEU9UkVRLVBBUlRJQ0lQQU5UO1BBUlRTVEFUPU5FRURTLUFDVElPTjtSU1ZQPVRSVUU7Q049J05p YyBMZXltYQ0KIG5uJzpNQUlMVE86bi5sZXltYW5uQHRlbGVrb20uZGUNCkFUVEVOREVFO1JPTEU9 UkVRLVBBUlRJQ0lQQU5UO1BBUlRTVEFUPU5FRURTLUFDVElPTjtSU1ZQPVRSVUU7Q049J0RJRUdP IExPUA0KIEVaIEdBUkNJQSc6TUFJTFRPOmRpZWdvLnIubG9wZXpAdGVsZWZvbmljYS5jb20NCkFU VEVOREVFO1JPTEU9UkVRLVBBUlRJQ0lQQU5UO1BBUlRTVEFUPU5FRURTLUFDVElPTjtSU1ZQPVRS VUU7Q049IidSb21hc2NhbnUNCiAsIERhbiAoRGFuKSciOk1BSUxUTzpkcm9tYXNjYUBhdmF5YS5j b20NCkFUVEVOREVFO1JPTEU9UkVRLVBBUlRJQ0lQQU5UO1BBUlRTVEFUPU5FRURTLUFDVElPTjtS U1ZQPVRSVUU7Q049IidaYXJueSwgTXkNCiBvJyI6TUFJTFRPOk15by5aYXJueUBncy5jb20NCkFU VEVOREVFO1JPTEU9UkVRLVBBUlRJQ0lQQU5UO1BBUlRTVEFUPU5FRURTLUFDVElPTjtSU1ZQPVRS VUU7Q049eGlhb2p1bjpNQQ0KIElMVE86emh1YW5neGlhb2p1bkBjaGluYW1vYmlsZS5jb20NCkFU VEVOREVFO1JPTEU9UkVRLVBBUlRJQ0lQQU5UO1BBUlRTVEFUPU5FRURTLUFDVElPTjtSU1ZQPVRS VUU7Q049J0FOVE9OSU8gQQ0KIEdVU1RJTiBQQVNUT1IgUEVSQUxFUyc6TUFJTFRPOmFudG9uaW8u cGFzdG9ycGVyYWxlc0B0ZWxlZm9uaWNhLmNvbQ0KQVRURU5ERUU7Uk9MRT1SRVEtUEFSVElDSVBB TlQ7UEFSVFNUQVQ9TkVFRFMtQUNUSU9OO1JTVlA9VFJVRTtDTj0nSm9zZXBoIFNhDQogbG93ZXkn Ok1BSUxUTzpqb2VAc2Fsb3dleS5uZXQNCkRFU0NSSVBUSU9OO0xBTkdVQUdFPWVuLVVTOldoZW46 IFR1ZXNkYXlcLCBKdW5lIDAyXCwgMjAxNSA5OjAwIEFNLTEwOjAwIEFNIA0KIChVVEMtMDY6MDAp IENlbnRyYWwgVGltZSAoVVMgJiBDYW5hZGEpLlxuV2hlcmU6IENvbmZlcmVuY2UgYnJpZGdlXG5c bk5vdGU6DQogIFRoZSBHTVQgb2Zmc2V0IGFib3ZlIGRvZXMgbm90IHJlZmxlY3QgZGF5bGlnaHQg c2F2aW5nIHRpbWUgYWRqdXN0bWVudHMuXG4NCiBcbip+Kn4qfip+Kn4qfip+Kn4qfipcblxuV2Ug bmVlZCB0byBjb25zb2xpZGF0ZSB0aGUgMyBJMk5TRiB1c2UgY2FzZXMgZHJhZg0KIHRzOlxuXG5v ICAgICAgIOKAi2h0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXFpLWkybnNm LWFjY2Vzcy1uDQogZXR3b3JrLXVzZWNhc2UvPGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LXFpLWkybnNmLWFjY2Vzcy1uZXQNCiB3b3JrLXVzZWNhc2UvPlxubyAgICAgICDi gItodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1wYXN0b3ItaQ0KIDJuc2Yt YWNjZXNzLXVzZWNhc2VzLzxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1w YXN0b3ItaTJuc2YtDQogYWNjZXNzLXVzZWNhc2VzLz5cbm8gICAgICAgaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtemFybnktaTINCiBuc2YtZGF0YS1jZW50ZXItdXNlLWNh c2VzL1xubyAgICAgICDigItodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcg0KIGFm dC1qZW9uZy1pMm5zZi1zZG4tc2VjdXJpdHktc2VydmljZXMvPGh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyDQogYWZ0LWplb25nLWkybnNmLXNkbi1zZWN1cml0eS1zZXJ2aWNlcy8+ XG5Db25mZXJlbmNlIGJyaWRnZSB3aWxsIGJlIHNlbnQgb3UNCiB0IHNvb24uXG5cbkxpbmRhXG5c bg0KU1VNTUFSWTtMQU5HVUFHRT1lbi1VUzpJMk5TRiBVc2UgY2FzZXMgY29uc29saWRhdGlvbg0K RFRTVEFSVDtUWklEPUNlbnRyYWwgU3RhbmRhcmQgVGltZToyMDE1MDYwMlQwOTAwMDANCkRURU5E O1RaSUQ9Q2VudHJhbCBTdGFuZGFyZCBUaW1lOjIwMTUwNjAyVDEwMDAwMA0KVUlEOjA0MDAwMDAw ODIwMEUwMDA3NEM1QjcxMDFBODJFMDA4MDAwMDAwMDAzMDg4QzU3RkZBOTlEMDAxMDAwMDAwMDAw MDAwMDAwDQogMDEwMDAwMDAwNjNDMjUzODY5NDgxMTE0REIzQ0M5NDMzMjMwQTBCQUYNCkNMQVNT OlBVQkxJQw0KUFJJT1JJVFk6NQ0KRFRTVEFNUDoyMDE1MDUyOVQxNTM3NTJaDQpUUkFOU1A6T1BB UVVFDQpTVEFUVVM6Q09ORklSTUVEDQpTRVFVRU5DRTowDQpMT0NBVElPTjtMQU5HVUFHRT1lbi1V UzpDb25mZXJlbmNlIGJyaWRnZQ0KWC1NSUNST1NPRlQtQ0RPLUFQUFQtU0VRVUVOQ0U6MA0KWC1N SUNST1NPRlQtQ0RPLU9XTkVSQVBQVElEOi00MDcwMjE2MDENClgtTUlDUk9TT0ZULUNETy1CVVNZ U1RBVFVTOlRFTlRBVElWRQ0KWC1NSUNST1NPRlQtQ0RPLUlOVEVOREVEU1RBVFVTOkJVU1kNClgt TUlDUk9TT0ZULUNETy1BTExEQVlFVkVOVDpGQUxTRQ0KWC1NSUNST1NPRlQtQ0RPLUlNUE9SVEFO Q0U6MQ0KWC1NSUNST1NPRlQtQ0RPLUlOU1RUWVBFOjANClgtTUlDUk9TT0ZULURJU0FMTE9XLUNP VU5URVI6RkFMU0UNCkJFR0lOOlZBTEFSTQ0KQUNUSU9OOkRJU1BMQVkNCkRFU0NSSVBUSU9OOlJF TUlOREVSDQpUUklHR0VSO1JFTEFURUQ9U1RBUlQ6LVBUMTVNDQpFTkQ6VkFMQVJNDQpFTkQ6VkVW RU5UDQpFTkQ6VkNBTEVOREFSDQo= --_000_4A95BA014132FF49AE685FAB4B9F17F657C4E14Bdfweml701chm_-- From nobody Fri May 29 09:39:02 2015 Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A752C1ACCFE for ; Fri, 29 May 2015 09:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZkpVYIjjAIVB for ; Fri, 29 May 2015 09:31:19 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE71E1AC447 for ; Fri, 29 May 2015 09:31:18 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BWQ94968; Fri, 29 May 2015 16:31:12 +0000 (GMT) Received: from DFWEML704-CHM.china.huawei.com (10.193.5.141) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 29 May 2015 17:31:11 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml704-chm ([10.193.5.141]) with mapi id 14.03.0158.001; Fri, 29 May 2015 09:31:02 -0700 From: Linda Dunbar To: "i2nsf@ietf.org" , "'Michael Georgiades'" , "'Nic Leymann'" , "'DIEGO LOPEZ GARCIA'" , "'Romascanu, Dan (Dan)'" , "'Zarny, Myo'" , xiaojun , "'ANTONIO AGUSTIN PASTOR PERALES'" , "'Joseph Salowey'" Thread-Topic: I2NSF Use cases consolidation Thread-Index: AdCaJWyf91AKkqS8SHiKB3pKw2AhcA== Date: Fri, 29 May 2015 16:31:01 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657C4E979@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.74] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657C4E979dfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-Mailman-Approved-At: Fri, 29 May 2015 09:39:01 -0700 Cc: Edward Lopez , Susan Hares , "Tirumaleswar Reddy \(tireddy\)" , Rich Groves Subject: [I2nsf] I2NSF Use cases consolidation X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2015 16:31:21 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F657C4E979dfweml701chm_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable When: Tuesday, June 02, 2015 9:00 AM-10:00 AM (UTC-06:00) Central Time (US = & Canada). Where: WebEx Info provided Note: The GMT offset above does not reflect daylight saving time adjustment= s. *~*~*~*~*~*~*~*~*~* We need to consolidate the 3 I2NSF use cases drafts: o ?https://datatracker.ietf.org/doc/draft-qi-i2nsf-access-network-use= case/ o ?https://datatracker.ietf.org/doc/draft-pastor-i2nsf-access-usecase= s/ o https://datatracker.ietf.org/doc/draft-zarny-i2nsf-data-center-use-= cases/ o ?https://datatracker.ietf.org/doc/draft-jeong-i2nsf-sdn-security-se= rvices/ I2NSF BOF Tuesday, June 2, 2015 10:00 am | Eastern Daylight Time (New York, GMT-04:00) | 1 hr Join WebEx meeting Meeting number: 648 212 196 Meeting password: 1234 Join by phone 1-877-668-4493 Call-in toll free number (US/Canada) 1-650-479-3208 Call-in toll number (US/Canada) Access code: 648 212 196 Toll-free calling restrictions Add this meeting to your calendar. Can't join the meeting? Contact support. IMPORTANT NOTICE: Please note that this WebEx service allows audio and othe= r information sent during the session to be recorded, which may be discover= able in a legal matter. By joining this session, you automatically consent = to such recordings. If you do not consent to being recorded, discuss your c= oncerns with the host or do not join the session. --_000_4A95BA014132FF49AE685FAB4B9F17F657C4E979dfweml701chm_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
When: Tuesday, June 02, 2015 9:00 AM-10:00 AM (UTC-06:00) Central Time= (US & Canada).
Where: WebEx Info provided
 
Note: The GMT offset above does not reflect daylight saving time adjus= tments.
 
*~*~*~*~*~*~*~*~*~*
 
We need to consolidate the 3 I2NSF use cases drafts:
 
 
 
 
I2NSF BOF
Tuesday, June 2, 2015
10:00 am  |  Eastern Daylight Time (New Yor= k, GMT-04:00)  |  1 hr
 
 
 
Join WebEx meeti= ng
 
Meeting number: 648 212 196
Meeting password: 1234
 
 
 
Join by phone
1-877-668-4493 Call-in toll free number (US/Canada)=
1-650-479-3208 Call-in toll number (US/Canada)
Access code: 648 212 196
= Toll-free calling restrictions
 
 
 
Add this meeting<= /span> to your calendar.
 
 
 
Can't join the meeting? Contact support.
 
 
 
IMPORTANT NOTICE: Please note that this WebEx service allows audi= o and other information sent during the session to be recorded, which may b= e discoverable in a legal matter. By joining this session, you automatically consent to such recordings. If you do not c= onsent to being recorded, discuss your concerns with the host or do not joi= n the session.
 
 
 
 
--_000_4A95BA014132FF49AE685FAB4B9F17F657C4E979dfweml701chm_ Content-Type: text/calendar; charset="utf-8"; method=REQUEST Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSDQpNRVRIT0Q6UkVRVUVTVA0KUFJPRElEOk1pY3Jvc29mdCBFeGNoYW5n ZSBTZXJ2ZXIgMjAxMA0KVkVSU0lPTjoyLjANCkJFR0lOOlZUSU1FWk9ORQ0KVFpJRDpDZW50cmFs IFN0YW5kYXJkIFRpbWUNCkJFR0lOOlNUQU5EQVJEDQpEVFNUQVJUOjE2MDEwMTAxVDAyMDAwMA0K VFpPRkZTRVRGUk9NOi0wNTAwDQpUWk9GRlNFVFRPOi0wNjAwDQpSUlVMRTpGUkVRPVlFQVJMWTtJ TlRFUlZBTD0xO0JZREFZPTFTVTtCWU1PTlRIPTExDQpFTkQ6U1RBTkRBUkQNCkJFR0lOOkRBWUxJ R0hUDQpEVFNUQVJUOjE2MDEwMTAxVDAyMDAwMA0KVFpPRkZTRVRGUk9NOi0wNjAwDQpUWk9GRlNF VFRPOi0wNTAwDQpSUlVMRTpGUkVRPVlFQVJMWTtJTlRFUlZBTD0xO0JZREFZPTJTVTtCWU1PTlRI PTMNCkVORDpEQVlMSUdIVA0KRU5EOlZUSU1FWk9ORQ0KQkVHSU46VkVWRU5UDQpPUkdBTklaRVI7 Q049TGluZGEgRHVuYmFyOk1BSUxUTzpsaW5kYS5kdW5iYXJAaHVhd2VpLmNvbQ0KQVRURU5ERUU7 Uk9MRT1SRVEtUEFSVElDSVBBTlQ7UEFSVFNUQVQ9TkVFRFMtQUNUSU9OO1JTVlA9VFJVRTtDTj1p Mm5zZkBpZXRmDQogLm9yZzpNQUlMVE86aTJuc2ZAaWV0Zi5vcmcNCkFUVEVOREVFO1JPTEU9UkVR LVBBUlRJQ0lQQU5UO1BBUlRTVEFUPU5FRURTLUFDVElPTjtSU1ZQPVRSVUU7Q049J01pY2hhZWwg Rw0KIGVvcmdpYWRlcyc6TUFJTFRPOm1pY2hhZWxnQHByaW1lLXRlbC5jb20NCkFUVEVOREVFO1JP TEU9UkVRLVBBUlRJQ0lQQU5UO1BBUlRTVEFUPU5FRURTLUFDVElPTjtSU1ZQPVRSVUU7Q049J05p YyBMZXltYQ0KIG5uJzpNQUlMVE86bi5sZXltYW5uQHRlbGVrb20uZGUNCkFUVEVOREVFO1JPTEU9 UkVRLVBBUlRJQ0lQQU5UO1BBUlRTVEFUPU5FRURTLUFDVElPTjtSU1ZQPVRSVUU7Q049J0RJRUdP IExPUA0KIEVaIEdBUkNJQSc6TUFJTFRPOmRpZWdvLnIubG9wZXpAdGVsZWZvbmljYS5jb20NCkFU VEVOREVFO1JPTEU9UkVRLVBBUlRJQ0lQQU5UO1BBUlRTVEFUPU5FRURTLUFDVElPTjtSU1ZQPVRS VUU7Q049IidSb21hc2NhbnUNCiAsIERhbiAoRGFuKSciOk1BSUxUTzpkcm9tYXNjYUBhdmF5YS5j b20NCkFUVEVOREVFO1JPTEU9UkVRLVBBUlRJQ0lQQU5UO1BBUlRTVEFUPU5FRURTLUFDVElPTjtS U1ZQPVRSVUU7Q049IidaYXJueSwgTXkNCiBvJyI6TUFJTFRPOk15by5aYXJueUBncy5jb20NCkFU VEVOREVFO1JPTEU9UkVRLVBBUlRJQ0lQQU5UO1BBUlRTVEFUPU5FRURTLUFDVElPTjtSU1ZQPVRS VUU7Q049eGlhb2p1bjpNQQ0KIElMVE86emh1YW5neGlhb2p1bkBjaGluYW1vYmlsZS5jb20NCkFU VEVOREVFO1JPTEU9UkVRLVBBUlRJQ0lQQU5UO1BBUlRTVEFUPU5FRURTLUFDVElPTjtSU1ZQPVRS VUU7Q049J0FOVE9OSU8gQQ0KIEdVU1RJTiBQQVNUT1IgUEVSQUxFUyc6TUFJTFRPOmFudG9uaW8u cGFzdG9ycGVyYWxlc0B0ZWxlZm9uaWNhLmNvbQ0KQVRURU5ERUU7Uk9MRT1SRVEtUEFSVElDSVBB TlQ7UEFSVFNUQVQ9TkVFRFMtQUNUSU9OO1JTVlA9VFJVRTtDTj0nSm9zZXBoIFNhDQogbG93ZXkn Ok1BSUxUTzpqb2VAc2Fsb3dleS5uZXQNCkFUVEVOREVFO1JPTEU9T1BULVBBUlRJQ0lQQU5UO1BB UlRTVEFUPU5FRURTLUFDVElPTjtSU1ZQPVRSVUU7Q049VGlydW1hbGVzdw0KIGFyIFJlZGR5ICh0 aXJlZGR5KTpNQUlMVE86dGlyZWRkeUBjaXNjby5jb20NCkFUVEVOREVFO1JPTEU9T1BULVBBUlRJ Q0lQQU5UO1BBUlRTVEFUPU5FRURTLUFDVElPTjtSU1ZQPVRSVUU7Q049UmljaCBHcm92ZQ0KIHM6 TUFJTFRPOlJHcm92ZXNAYTEwbmV0d29ya3MuY29tDQpBVFRFTkRFRTtST0xFPU9QVC1QQVJUSUNJ UEFOVDtQQVJUU1RBVD1ORUVEUy1BQ1RJT047UlNWUD1UUlVFO0NOPVN1c2FuIEhhcmUNCiBzOk1B SUxUTzpzaGFyZXNAbmR6aC5jb20NCkFUVEVOREVFO1JPTEU9T1BULVBBUlRJQ0lQQU5UO1BBUlRT VEFUPU5FRURTLUFDVElPTjtSU1ZQPVRSVUU7Q049RWR3YXJkIExvcA0KIGV6Ok1BSUxUTzplbG9w ZXpAZm9ydGluZXQuY29tDQpERVNDUklQVElPTjtMQU5HVUFHRT1lbi1VUzpXaGVuOiBUdWVzZGF5 XCwgSnVuZSAwMlwsIDIwMTUgOTowMCBBTS0xMDowMCBBTSANCiAoVVRDLTA2OjAwKSBDZW50cmFs IFRpbWUgKFVTICYgQ2FuYWRhKS5cbldoZXJlOiBXZWJFeCBJbmZvIHByb3ZpZGVkXG5cbk5vdA0K IGU6IFRoZSBHTVQgb2Zmc2V0IGFib3ZlIGRvZXMgbm90IHJlZmxlY3QgZGF5bGlnaHQgc2F2aW5n IHRpbWUgYWRqdXN0bWVudHMuDQogXG5cbip+Kn4qfip+Kn4qfip+Kn4qfipcblxuV2UgbmVlZCB0 byBjb25zb2xpZGF0ZSB0aGUgMyBJMk5TRiB1c2UgY2FzZXMgZHINCiBhZnRzOlxuXG5vICAgICAg IOKAi2h0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXFpLWkybnNmLWFjY2Vz cw0KIC1uZXR3b3JrLXVzZWNhc2UvPGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LXFpLWkybnNmLWFjY2Vzcy1uDQogZXR3b3JrLXVzZWNhc2UvPlxubyAgICAgICDigItodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1wYXN0b3INCiAtaTJuc2YtYWNjZXNz LXVzZWNhc2VzLzxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1wYXN0b3It aTJucw0KIGYtYWNjZXNzLXVzZWNhc2VzLz5cbm8gICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtemFybnktDQogaTJuc2YtZGF0YS1jZW50ZXItdXNlLWNhc2VzL1xu byAgICAgICDigItodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy8NCiBkcmFmdC1qZW9u Zy1pMm5zZi1zZG4tc2VjdXJpdHktc2VydmljZXMvPGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jLw0KIGRyYWZ0LWplb25nLWkybnNmLXNkbi1zZWN1cml0eS1zZXJ2aWNlcy8+XG5cblxu XG5cblxuXG5cblxuSTJOU0YgQk9GXG5cblR1DQogZXNkYXlcLCBKdW5lIDJcLCAyMDE1XG5cbjEw OjAwIGFtICB8ICBFYXN0ZXJuIERheWxpZ2h0IFRpbWUgKE5ldyBZb3JrXCwgR00NCiBULTA0OjAw KSAgfCAgMSBoclxuXG5cblxuXG5cbkpvaW4gV2ViRXggbWVldGluZyA8aHR0cHM6Ly9pZXRmLndl YmV4LmNvbS9pZQ0KIHRmL2oucGhwP01USUQ9bTUyZDk5MDVjZTg0OTJjNDYxNTI3ODBhOTJlNDky NGVhPlxuXG5cbk1lZXRpbmcgbnVtYmVyOlxuNjQ4DQogIDIxMiAxOTZcblxuTWVldGluZyBwYXNz d29yZDpcbjEyMzRcblxuXG5cblxuXG5Kb2luIGJ5IHBob25lXG5cbjEtODc3LTY2OC0NCiA0NDkz IENhbGwtaW4gdG9sbCBmcmVlIG51bWJlciAoVVMvQ2FuYWRhKVxuXG4xLTY1MC00NzktMzIwOCBD YWxsLWluIHRvbGwgbg0KIHVtYmVyIChVUy9DYW5hZGEpXG5cbkFjY2VzcyBjb2RlOiA2NDggMjEy IDE5NlxuXG5Ub2xsLWZyZWUgY2FsbGluZyByZXN0cmljDQogdGlvbnM8aHR0cDovL3d3dy53ZWJl eC5jb20vcGRmL3RvbGxmcmVlX3Jlc3RyaWN0aW9ucy5wZGY+XG5cblxuXG5cblxuQWRkIHQNCiBo aXMgbWVldGluZzxodHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJRD1tOWQxYjM3 NTU2NmYxMmJlMTkzZWMyOA0KIDRkMWYyNjkwOTA+IHRvIHlvdXIgY2FsZW5kYXIuXG5cblxuXG5c blxuQ2FuJ3Qgam9pbiB0aGUgbWVldGluZz8gQ29udGFjdCBzDQogdXBwb3J0LjxodHRwczovL2ll dGYud2ViZXguY29tL2lldGYvbWM+XG5cblxuXG5cblxuSU1QT1JUQU5UIE5PVElDRTogUGxlYXMN CiBlIG5vdGUgdGhhdCB0aGlzIFdlYkV4IHNlcnZpY2UgYWxsb3dzIGF1ZGlvIGFuZCBvdGhlciBp bmZvcm1hdGlvbiBzZW50IGR1cg0KIGluZyB0aGUgc2Vzc2lvbiB0byBiZSByZWNvcmRlZFwsIHdo aWNoIG1heSBiZSBkaXNjb3ZlcmFibGUgaW4gYSBsZWdhbCBtYXR0DQogZXIuIEJ5IGpvaW5pbmcg dGhpcyBzZXNzaW9uXCwgeW91IGF1dG9tYXRpY2FsbHkgY29uc2VudCB0byBzdWNoIHJlY29yZGlu Z3MNCiAuIElmIHlvdSBkbyBub3QgY29uc2VudCB0byBiZWluZyByZWNvcmRlZFwsIGRpc2N1c3Mg eW91ciBjb25jZXJucyB3aXRoIHRoZQ0KICBob3N0IG9yIGRvIG5vdCBqb2luIHRoZSBzZXNzaW9u LlxuXG5cblxuXG5cbg0KU1VNTUFSWTtMQU5HVUFHRT1lbi1VUzpJMk5TRiBVc2UgY2FzZXMgY29u c29saWRhdGlvbg0KRFRTVEFSVDtUWklEPUNlbnRyYWwgU3RhbmRhcmQgVGltZToyMDE1MDYwMlQw OTAwMDANCkRURU5EO1RaSUQ9Q2VudHJhbCBTdGFuZGFyZCBUaW1lOjIwMTUwNjAyVDEwMDAwMA0K VUlEOjA0MDAwMDAwODIwMEUwMDA3NEM1QjcxMDFBODJFMDA4MDAwMDAwMDAzMDg4QzU3RkZBOTlE MDAxMDAwMDAwMDAwMDAwMDAwDQogMDEwMDAwMDAwNjNDMjUzODY5NDgxMTE0REIzQ0M5NDMzMjMw QTBCQUYNCkNMQVNTOlBVQkxJQw0KUFJJT1JJVFk6NQ0KRFRTVEFNUDoyMDE1MDUyOVQxNjMxMDFa DQpUUkFOU1A6T1BBUVVFDQpTVEFUVVM6Q09ORklSTUVEDQpTRVFVRU5DRToxDQpMT0NBVElPTjtM QU5HVUFHRT1lbi1VUzpXZWJFeCBJbmZvIHByb3ZpZGVkDQpYLU1JQ1JPU09GVC1DRE8tQVBQVC1T RVFVRU5DRToxDQpYLU1JQ1JPU09GVC1DRE8tT1dORVJBUFBUSUQ6LTQwNzAyMTYwMQ0KWC1NSUNS T1NPRlQtQ0RPLUJVU1lTVEFUVVM6VEVOVEFUSVZFDQpYLU1JQ1JPU09GVC1DRE8tSU5URU5ERURT VEFUVVM6QlVTWQ0KWC1NSUNST1NPRlQtQ0RPLUFMTERBWUVWRU5UOkZBTFNFDQpYLU1JQ1JPU09G VC1DRE8tSU1QT1JUQU5DRToxDQpYLU1JQ1JPU09GVC1DRE8tSU5TVFRZUEU6MA0KWC1NSUNST1NP RlQtRElTQUxMT1ctQ09VTlRFUjpGQUxTRQ0KQkVHSU46VkFMQVJNDQpBQ1RJT046RElTUExBWQ0K REVTQ1JJUFRJT046UkVNSU5ERVINClRSSUdHRVI7UkVMQVRFRD1TVEFSVDotUFQxNU0NCkVORDpW QUxBUk0NCkVORDpWRVZFTlQNCkVORDpWQ0FMRU5EQVINCg== --_000_4A95BA014132FF49AE685FAB4B9F17F657C4E979dfweml701chm_--