From nobody Fri May 1 22:28:41 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA5851A19F0 for ; Fri, 1 May 2015 22:28:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 B0sVu511hW1M for ; Fri, 1 May 2015 22:28:39 -0700 (PDT) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::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 1C2CF1A19EF for ; Fri, 1 May 2015 22:28:38 -0700 (PDT) Received: by iebrs15 with SMTP id rs15so101383662ieb.3 for ; Fri, 01 May 2015 22:28:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arbor.net; s=m0; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Z+IalWgBDRpJZJY0pSxWhAjXNwfyt/YEvNjiIxPndJg=; b=NM7srnkes2E+omAkV2jrQh658xWxPX1t9g6+YYVr7/z1EpXPglj0eWKh0zjVJG18gP nSLN/TUA9v+nb/xdf60032ekT1oeSSer2Hvz0+leyysSbLM8gKxlTKZmOoJRV83BZbE4 uszvTFzijUzQsmj+Tv6ADa/ZOmJeDX2MvRVso= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=Z+IalWgBDRpJZJY0pSxWhAjXNwfyt/YEvNjiIxPndJg=; b=FwUfrOEJsFWq8p84FyVFhlK27X6KRO7yhX1bc1RwO+7Nqcqi9bt0woCHhUd12DKABM 8aD+IJcLB3jZfF8DcnOBxYP7v+09VfKwEwNM8kOnjSz6RNNAEnCkPtR8wUfMfduNewe8 pT0aq529LKLFJ7xe1AyKgGFIGf/DXIqD/tGArMDdfAIn4ORlrohnJwczxJWMtPTD5bkU pFX7MqVdqztfD50u2cQVo350RlLuNmxSVqjyhI0XX7zaq2EQFa2Er+qpyXic43MuKmQ4 lzZYCylJdg9t2J8dw6DP6Rd90FQjoKHcabD+fJiPdKcjvNtHnJXqKfWVR8nN+fNDUZBr 8WLg== X-Gm-Message-State: ALoCoQkJUP2msXPUsmyJ5C2G5+KFELX1qJSgHnIK9emFCG7ajgNssLbeDQtLK0H+Kqj2rxtuHg64 X-Received: by 10.107.150.198 with SMTP id y189mr16190797iod.21.1430544518455; Fri, 01 May 2015 22:28:38 -0700 (PDT) Received: from [10.0.1.6] (c-68-40-187-116.hsd1.mi.comcast.net. [68.40.187.116]) by mx.google.com with ESMTPSA id r4sm527302igw.12.2015.05.01.22.28.37 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 01 May 2015 22:28:37 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Andrew Mortensen In-Reply-To: Date: Sat, 2 May 2015 01:28:36 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6DEAC84F-75B4-41D6-A429-3C2328BEAEBA@arbor.net> References: To: "Teague, Nik" X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "dots@ietf.org" Subject: Re: [Dots] Draft Charter X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2015 05:28:40 -0000 Hi Nik. Thanks for giving us a good foundation to build upon. Comments/nitpicks inline, trying not to overlap too much with Adam. andrew -- > The aim of DDoS Open Threat Signaling (DOTS) is to develop a standards > based approach to the real time signaling of DDoS related telemetry = and > threat handling data between elements concerned with attack = mitigation. I think the =93real time=94 phrase here is intended to emphasize that = the signaling is expected to be done under attack conditions. That seems = to me an important differentiator from mile. We should make it explicit = here. > The elements may be described as: > * On-premise DDoS mitigation platforms > * Service provider DDoS mitigation platforms > * Other network devices/platforms that are able to sense DDoS and = respond Something along the lines of =93Other devices with network perspective = performing traffic analysis=94 or =93=85engaged in traffic analysis=94 = should encompass things like flow monitoring and IDS/IPS. > * Chained instances of the above >=20 > These elements may be communicating inter-domain or intra-domain over > links that may be congested by attack traffic resulting in hostile > conditions for traditional connection oriented approaches and more > generalized signaling and telemetry solutions. Strike =93traditional=94. Regardless of innovation, a = connection-oriented protocol is not appropriate for dots for the reasons = you=92ve just stated. I think this can be tightened to, e.g., =93=85hostil= e conditions for connection-oriented signaling and telemetry protocols.=94= > Robustness under these > conditions is paramount while ensuring appropriate regard for > authentication, authorization, privacy and data integrity. Elements = may > be deployed as part of a wider strategy incorporating multiple points = of > detection and mitigation, both on premise or service provider based. > Should mitigation need to move between elements in the chain then > effective signaling of telemetry and current threat handling is = essential. Is the implication that an on-premise device may signal laterally = intentional? Or is the expectation that each subsequent element in the = chain will be upstream from the previous? > Feedback between participating elements is required for increased > awareness for effective decision making. >=20 > The WG will, where appropriate, reuse existing standard protocols and > mechanisms, for instance IPFIX and its templating mechanism. > The charter of the working group is to produce one or more standards = track > specification to provide for this open signaling in the DDoS problem > space. While the resulting standards should be designed so that = there=B9s a > possibility of applying them to network security applications beyond = DDoS =93=85designed so they may apply to network security applications=85" > mitigation, this working group will focus on just DDoS mitigation. Strike =93just=94. > This streamlined focus of the charter is intended to lead to an = earlier result > due to community interests in having such capability in a short = timeframe. > The specification(s) produced by the WG will include a standard = mechanism > for authentication and authorization, for data integrity, and for > providing for privacy in operation. >=20 > The WG will produce the following deliverables: >=20 > * Use case document to ensure commonality of the work among the > participants in the Working Group. This document may be determined by = the > working group to remain informal and not be published. > * Document or Documents describing the problem space, use cases, = protocol > requirements and other qualifying information as the WG sees fit. > * Document or Documents specifying a protocol and associated data = models > to address the WG stated goal. From nobody Thu May 7 08:53:18 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@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: [Dots] Further Narrowing the I2NSF scope: the new charter for IETF 93 X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." 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 10:09:17 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@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: X-Mailman-Approved-At: Sat, 09 May 2015 10:09:15 -0700 Cc: "'i2rs@ietf.org'" , "'dots@ietf.org'" , "'netmod@ietf.org'" Subject: Re: [Dots] [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93 X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." 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 Sat May 9 10:28:17 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D4C91A1ADF for ; Sat, 9 May 2015 10:28:16 -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, 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 M8EcUYxmFvYI for ; Sat, 9 May 2015 10:28:14 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (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 5A5951A0399 for ; Sat, 9 May 2015 10:28:14 -0700 (PDT) Received: by qku63 with SMTP id 63so66061215qku.3 for ; Sat, 09 May 2015 10:28:13 -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=zmaHIfC8tSBshLtFuSBXSNNPwIIKJdVdCJ/Mib7zEfY=; b=ATKWR7rxR/WBn1AWEuQsp1bLdMFzDbHDKSkg1hrhxpUJ8GEctCkXLoexB11rUZ9L2i GMlgN1/pMosYQiI93WUz9uyFTzLWfZH4gKQJLf0QB/ciuEUttsYHA+u3j5Ce/x51R+K8 LeHn5kxctInI6fPCkkvU0w9NI0VrR5sp/559To46d9swINo0K8F/BvDYbyW95BmZEC/c VRqmslV5v64eCcAP6UMTlvIfOF8nh45HCo5LQ8rvIlJe4rOiWPx48RfIhSq23i9wRMjs +Z3PADDfznyarQsH8teBcTD+XyB8bgPDO9Gs4lLtwW3nZ3ApnnAEXQVAT7tO87Yjbu1v Koaw== X-Received: by 10.140.231.85 with SMTP id b82mr4755828qhc.2.1431192493675; Sat, 09 May 2015 10:28:13 -0700 (PDT) Received: from [192.168.1.3] (209-6-114-252.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.114.252]) by mx.google.com with ESMTPSA id f8sm6196401qka.9.2015.05.09.10.28.11 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 09 May 2015 10:28:12 -0700 (PDT) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (11D257) In-Reply-To: <6DEAC84F-75B4-41D6-A429-3C2328BEAEBA@arbor.net> Date: Sat, 9 May 2015 13:28:12 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6DEAC84F-75B4-41D6-A429-3C2328BEAEBA@arbor.net> To: Andrew Mortensen Archived-At: Cc: "Teague, Nik" , "dots@ietf.org" Subject: Re: [Dots] Draft Charter X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2015 17:28:16 -0000 Are there any other comments on the proposed charter? If you've read it and= do not have changes, expressions of support for the current version would b= e helpful to understand how many folks agree this is important and want to w= ork on this in the IETF. Thank you, Kathleen=20 Sent from my iPhone > On May 2, 2015, at 1:28 AM, Andrew Mortensen wrote:= >=20 > Hi Nik. Thanks for giving us a good foundation to build upon. >=20 > Comments/nitpicks inline, trying not to overlap too much with Adam. >=20 > andrew >=20 > -- >=20 >> The aim of DDoS Open Threat Signaling (DOTS) is to develop a standards >> based approach to the real time signaling of DDoS related telemetry and >> threat handling data between elements concerned with attack mitigation. >=20 > I think the =E2=80=9Creal time=E2=80=9D phrase here is intended to emphasi= ze that the signaling is expected to be done under attack conditions. That s= eems to me an important differentiator from mile. We should make it explicit= here. >=20 >> The elements may be described as: >> * On-premise DDoS mitigation platforms >> * Service provider DDoS mitigation platforms >> * Other network devices/platforms that are able to sense DDoS and respond= >=20 > Something along the lines of =E2=80=9COther devices with network perspecti= ve performing traffic analysis=E2=80=9D or =E2=80=9C=E2=80=A6engaged in tra= ffic analysis=E2=80=9D should encompass things like flow monitoring and IDS/= IPS. >=20 >> * Chained instances of the above >>=20 >> These elements may be communicating inter-domain or intra-domain over >> links that may be congested by attack traffic resulting in hostile >> conditions for traditional connection oriented approaches and more >> generalized signaling and telemetry solutions. >=20 > Strike =E2=80=9Ctraditional=E2=80=9D. Regardless of innovation, a connecti= on-oriented protocol is not appropriate for dots for the reasons you=E2=80=99= ve just stated. I think this can be tightened to, e.g., =E2=80=9C=E2=80=A6ho= stile conditions for connection-oriented signaling and telemetry protocols.=E2= =80=9D >=20 >> Robustness under these >> conditions is paramount while ensuring appropriate regard for >> authentication, authorization, privacy and data integrity. Elements may >> be deployed as part of a wider strategy incorporating multiple points of >> detection and mitigation, both on premise or service provider based. >> Should mitigation need to move between elements in the chain then >> effective signaling of telemetry and current threat handling is essential= . >=20 > Is the implication that an on-premise device may signal laterally intentio= nal? Or is the expectation that each subsequent element in the chain will be= upstream from the previous? >=20 >> Feedback between participating elements is required for increased >> awareness for effective decision making. >>=20 >> The WG will, where appropriate, reuse existing standard protocols and >> mechanisms, for instance IPFIX and its templating mechanism. >> The charter of the working group is to produce one or more standards trac= k >> specification to provide for this open signaling in the DDoS problem >> space. While the resulting standards should be designed so that there=C2= =B9s a >> possibility of applying them to network security applications beyond DDoS= >=20 > =E2=80=9C=E2=80=A6designed so they may apply to network security applicati= ons=E2=80=A6" >=20 >> mitigation, this working group will focus on just DDoS mitigation. >=20 > Strike =E2=80=9Cjust=E2=80=9D. >=20 >> This streamlined focus of the charter is intended to lead to an earlier r= esult >> due to community interests in having such capability in a short timeframe= . >> The specification(s) produced by the WG will include a standard mechanism= >> for authentication and authorization, for data integrity, and for >> providing for privacy in operation. >>=20 >> The WG will produce the following deliverables: >>=20 >> * Use case document to ensure commonality of the work among the >> participants in the Working Group. This document may be determined by th= e >> working group to remain informal and not be published. >> * Document or Documents describing the problem space, use cases, protocol= >> requirements and other qualifying information as the WG sees fit. >> * Document or Documents specifying a protocol and associated data models >> to address the WG stated goal. >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Sat May 9 10:33:27 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D10361A8A97 for ; Sat, 9 May 2015 10:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.328 X-Spam-Level: * X-Spam-Status: No, score=1.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779] 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 PNdyOtXewKYj for ; Sat, 9 May 2015 10:33:24 -0700 (PDT) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.8]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B2B21A89E1 for ; Sat, 9 May 2015 10:33:13 -0700 (PDT) Received: from [216.82.250.179] by server-8.bemta-12.messagelabs.com id AD/F9-07864-8D44E455; Sat, 09 May 2015 17:33:12 +0000 X-Env-Sender: Dave.Larson@corero.com X-Msg-Ref: server-9.tower-210.messagelabs.com!1431192776!19610708!1 X-Originating-IP: [71.184.227.49] X-StarScan-Received: X-StarScan-Version: 6.13.14; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17060 invoked from network); 9 May 2015 17:32:57 -0000 Received: from mercury.corero.com (HELO MERCURY.corero.com) (71.184.227.49) by server-9.tower-210.messagelabs.com with AES128-SHA encrypted SMTP; 9 May 2015 17:32:57 -0000 Received: from MERCURY.corero.com ([fe80::2c05:6b26:abe2:ad24]) by MERCURY.corero.com ([fe80::2c05:6b26:abe2:ad24%19]) with mapi id 14.03.0224.002; Sat, 9 May 2015 13:32:55 -0400 From: Dave Larson To: Kathleen Moriarty , Andrew Mortensen Thread-Topic: [Dots] Draft Charter Thread-Index: AQHQfE+l/Sly82ObQkmwTXHnIFPOXJ1ofBsAgAvJYAD//615AA== Date: Sat, 9 May 2015 17:32:53 +0000 Message-ID: References: <6DEAC84F-75B4-41D6-A429-3C2328BEAEBA@arbor.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [72.182.18.94] Content-Type: text/plain; charset="euc-kr" Content-ID: <405F0B6DD7D391428A377BC7B62232F1@corero.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "Teague, Nik" , "dots@ietf.org" Subject: Re: [Dots] Draft Charter X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2015 17:33:26 -0000 SSBzdXBwb3J0IHRoaXMgY2hhcnRlciAtIGFuZCBJIGFtIHByZXBhcmVkIHRvIHN1cHBvcnQgdGhp cyB3b3JrIHdpdGhpbiB0aGUNCklFVEYuICBUaGlzIGlzIGNyaXRpY2FsbHkgaW1wb3J0YW50IHdv cmsgZm9yIGRlYWxpbmcgd2l0aCBhIGRpZmZpY3VsdA0KcHJvYmxlbSB0b2RheSBhbmQgZW5zdXJp bmcgYW4gb25nb2luZyByb2J1c3QgcmVzcG9uc2UgYXMgdGhlIGlzc3VlIG9mIEREb1MNCmlzIG9u bHkgZ2V0dGluZyB3b3JzZS4NCg0KRGF2ZSANCg0KDQpPbiA1LzkvMTUsIDEyOjI4IFBNLCAiS2F0 aGxlZW4gTW9yaWFydHkiDQo8a2F0aGxlZW4ubW9yaWFydHkuaWV0ZkBnbWFpbC5jb20+IHdyb3Rl Og0KDQo+QXJlIHRoZXJlIGFueSBvdGhlciBjb21tZW50cyBvbiB0aGUgcHJvcG9zZWQgY2hhcnRl cj8gIElmIHlvdSd2ZSByZWFkIGl0DQo+YW5kIGRvIG5vdCBoYXZlIGNoYW5nZXMsIGV4cHJlc3Np b25zIG9mIHN1cHBvcnQgZm9yIHRoZSBjdXJyZW50IHZlcnNpb24NCj53b3VsZCBiZSBoZWxwZnVs IHRvIHVuZGVyc3RhbmQgaG93IG1hbnkgZm9sa3MgYWdyZWUgdGhpcyBpcyBpbXBvcnRhbnQgYW5k DQo+d2FudCB0byB3b3JrIG9uIHRoaXMgaW4gdGhlIElFVEYuDQo+DQo+VGhhbmsgeW91LA0KPkth dGhsZWVuIA0KPg0KPlNlbnQgZnJvbSBteSBpUGhvbmUNCj4NCj4+IE9uIE1heSAyLCAyMDE1LCBh dCAxOjI4IEFNLCBBbmRyZXcgTW9ydGVuc2VuIDxhbW9ydGVuc2VuQGFyYm9yLm5ldD4NCj4+d3Jv dGU6DQo+PiANCj4+IEhpIE5pay4gVGhhbmtzIGZvciBnaXZpbmcgdXMgYSBnb29kIGZvdW5kYXRp b24gdG8gYnVpbGQgdXBvbi4NCj4+IA0KPj4gQ29tbWVudHMvbml0cGlja3MgaW5saW5lLCB0cnlp bmcgbm90IHRvIG92ZXJsYXAgdG9vIG11Y2ggd2l0aCBBZGFtLg0KPj4gDQo+PiBhbmRyZXcNCj4+ IA0KPj4gLS0NCj4+IA0KPj4+IFRoZSBhaW0gb2YgRERvUyBPcGVuIFRocmVhdCBTaWduYWxpbmcg KERPVFMpIGlzIHRvIGRldmVsb3AgYSBzdGFuZGFyZHMNCj4+PiBiYXNlZCBhcHByb2FjaCB0byB0 aGUgcmVhbCB0aW1lIHNpZ25hbGluZyBvZiBERG9TIHJlbGF0ZWQgdGVsZW1ldHJ5IGFuZA0KPj4+ IHRocmVhdCBoYW5kbGluZyBkYXRhIGJldHdlZW4gZWxlbWVudHMgY29uY2VybmVkIHdpdGggYXR0 YWNrIG1pdGlnYXRpb24uDQo+PiANCj4+IEkgdGhpbmsgdGhlIKGwcmVhbCB0aW1lobEgcGhyYXNl IGhlcmUgaXMgaW50ZW5kZWQgdG8gZW1waGFzaXplIHRoYXQgdGhlDQo+PnNpZ25hbGluZyBpcyBl eHBlY3RlZCB0byBiZSBkb25lIHVuZGVyIGF0dGFjayBjb25kaXRpb25zLiBUaGF0IHNlZW1zIHRv DQo+Pm1lIGFuIGltcG9ydGFudCBkaWZmZXJlbnRpYXRvciBmcm9tIG1pbGUuIFdlIHNob3VsZCBt YWtlIGl0IGV4cGxpY2l0DQo+PmhlcmUuDQo+PiANCj4+PiBUaGUgZWxlbWVudHMgbWF5IGJlIGRl c2NyaWJlZCBhczoNCj4+PiAqIE9uLXByZW1pc2UgRERvUyBtaXRpZ2F0aW9uIHBsYXRmb3Jtcw0K Pj4+ICogU2VydmljZSBwcm92aWRlciBERG9TIG1pdGlnYXRpb24gcGxhdGZvcm1zDQo+Pj4gKiBP dGhlciBuZXR3b3JrIGRldmljZXMvcGxhdGZvcm1zIHRoYXQgYXJlIGFibGUgdG8gc2Vuc2UgRERv UyBhbmQNCj4+PnJlc3BvbmQNCj4+IA0KPj4gU29tZXRoaW5nIGFsb25nIHRoZSBsaW5lcyBvZiCh sE90aGVyIGRldmljZXMgd2l0aCBuZXR3b3JrIHBlcnNwZWN0aXZlDQo+PnBlcmZvcm1pbmcgdHJh ZmZpYyBhbmFseXNpc6GxICBvciChsKGmZW5nYWdlZCBpbiB0cmFmZmljIGFuYWx5c2lzobEgc2hv dWxkDQo+PmVuY29tcGFzcyB0aGluZ3MgbGlrZSBmbG93IG1vbml0b3JpbmcgYW5kIElEUy9JUFMu DQo+PiANCj4+PiAqIENoYWluZWQgaW5zdGFuY2VzIG9mIHRoZSBhYm92ZQ0KPj4+IA0KPj4+IFRo ZXNlIGVsZW1lbnRzIG1heSBiZSBjb21tdW5pY2F0aW5nIGludGVyLWRvbWFpbiBvciBpbnRyYS1k b21haW4gb3Zlcg0KPj4+IGxpbmtzIHRoYXQgbWF5IGJlIGNvbmdlc3RlZCBieSBhdHRhY2sgdHJh ZmZpYyByZXN1bHRpbmcgaW4gaG9zdGlsZQ0KPj4+IGNvbmRpdGlvbnMgZm9yIHRyYWRpdGlvbmFs IGNvbm5lY3Rpb24gb3JpZW50ZWQgYXBwcm9hY2hlcyBhbmQgbW9yZQ0KPj4+IGdlbmVyYWxpemVk IHNpZ25hbGluZyBhbmQgdGVsZW1ldHJ5IHNvbHV0aW9ucy4NCj4+IA0KPj4gU3RyaWtlIKGwdHJh ZGl0aW9uYWyhsS4gUmVnYXJkbGVzcyBvZiBpbm5vdmF0aW9uLCBhIGNvbm5lY3Rpb24tb3JpZW50 ZWQNCj4+cHJvdG9jb2wgaXMgbm90IGFwcHJvcHJpYXRlIGZvciBkb3RzIGZvciB0aGUgcmVhc29u cyB5b3Whr3ZlIGp1c3Qgc3RhdGVkLg0KPj5JIHRoaW5rIHRoaXMgY2FuIGJlIHRpZ2h0ZW5lZCB0 bywgZS5nLiwgobChpmhvc3RpbGUgY29uZGl0aW9ucyBmb3INCj4+Y29ubmVjdGlvbi1vcmllbnRl ZCBzaWduYWxpbmcgYW5kIHRlbGVtZXRyeSBwcm90b2NvbHMuobENCj4+IA0KPj4+IFJvYnVzdG5l c3MgdW5kZXIgdGhlc2UNCj4+PiBjb25kaXRpb25zIGlzIHBhcmFtb3VudCB3aGlsZSBlbnN1cmlu ZyBhcHByb3ByaWF0ZSByZWdhcmQgZm9yDQo+Pj4gYXV0aGVudGljYXRpb24sIGF1dGhvcml6YXRp b24sIHByaXZhY3kgYW5kIGRhdGEgaW50ZWdyaXR5LiAgRWxlbWVudHMNCj4+Pm1heQ0KPj4+IGJl IGRlcGxveWVkIGFzIHBhcnQgb2YgYSB3aWRlciBzdHJhdGVneSBpbmNvcnBvcmF0aW5nIG11bHRp cGxlIHBvaW50cw0KPj4+b2YNCj4+PiBkZXRlY3Rpb24gYW5kIG1pdGlnYXRpb24sIGJvdGggb24g cHJlbWlzZSBvciBzZXJ2aWNlIHByb3ZpZGVyIGJhc2VkLg0KPj4+IFNob3VsZCBtaXRpZ2F0aW9u IG5lZWQgdG8gbW92ZSBiZXR3ZWVuIGVsZW1lbnRzIGluIHRoZSBjaGFpbiB0aGVuDQo+Pj4gZWZm ZWN0aXZlIHNpZ25hbGluZyBvZiB0ZWxlbWV0cnkgYW5kIGN1cnJlbnQgdGhyZWF0IGhhbmRsaW5n IGlzDQo+Pj5lc3NlbnRpYWwuDQo+PiANCj4+IElzIHRoZSBpbXBsaWNhdGlvbiB0aGF0IGFuIG9u LXByZW1pc2UgZGV2aWNlIG1heSBzaWduYWwgbGF0ZXJhbGx5DQo+PmludGVudGlvbmFsPyBPciBp cyB0aGUgZXhwZWN0YXRpb24gdGhhdCBlYWNoIHN1YnNlcXVlbnQgZWxlbWVudCBpbiB0aGUNCj4+ Y2hhaW4gd2lsbCBiZSB1cHN0cmVhbSBmcm9tIHRoZSBwcmV2aW91cz8NCj4+IA0KPj4+IEZlZWRi YWNrIGJldHdlZW4gcGFydGljaXBhdGluZyBlbGVtZW50cyBpcyByZXF1aXJlZCBmb3IgaW5jcmVh c2VkDQo+Pj4gYXdhcmVuZXNzIGZvciBlZmZlY3RpdmUgZGVjaXNpb24gbWFraW5nLg0KPj4+IA0K Pj4+IFRoZSBXRyB3aWxsLCB3aGVyZSBhcHByb3ByaWF0ZSwgcmV1c2UgZXhpc3Rpbmcgc3RhbmRh cmQgcHJvdG9jb2xzIGFuZA0KPj4+IG1lY2hhbmlzbXMsIGZvciBpbnN0YW5jZSBJUEZJWCBhbmQg aXRzIHRlbXBsYXRpbmcgbWVjaGFuaXNtLg0KPj4+IFRoZSBjaGFydGVyIG9mIHRoZSB3b3JraW5n IGdyb3VwIGlzIHRvIHByb2R1Y2Ugb25lIG9yIG1vcmUgc3RhbmRhcmRzDQo+Pj50cmFjaw0KPj4+ IHNwZWNpZmljYXRpb24gdG8gcHJvdmlkZSBmb3IgdGhpcyBvcGVuIHNpZ25hbGluZyBpbiB0aGUg RERvUyBwcm9ibGVtDQo+Pj4gc3BhY2UuICBXaGlsZSB0aGUgcmVzdWx0aW5nIHN0YW5kYXJkcyBz aG91bGQgYmUgZGVzaWduZWQgc28gdGhhdA0KPj4+dGhlcmWp9nMgYQ0KPj4+IHBvc3NpYmlsaXR5 IG9mIGFwcGx5aW5nIHRoZW0gdG8gbmV0d29yayBzZWN1cml0eSBhcHBsaWNhdGlvbnMgYmV5b25k DQo+Pj5ERG9TDQo+PiANCj4+IKGwoaZkZXNpZ25lZCBzbyB0aGV5IG1heSBhcHBseSB0byBuZXR3 b3JrIHNlY3VyaXR5IGFwcGxpY2F0aW9uc6GmIg0KPj4gDQo+Pj4gbWl0aWdhdGlvbiwgdGhpcyB3 b3JraW5nIGdyb3VwIHdpbGwgZm9jdXMgb24ganVzdCBERG9TIG1pdGlnYXRpb24uDQo+PiANCj4+ IFN0cmlrZSChsGp1c3ShsS4NCj4+IA0KPj4+IFRoaXMgc3RyZWFtbGluZWQgZm9jdXMgb2YgdGhl IGNoYXJ0ZXIgaXMgaW50ZW5kZWQgdG8gbGVhZCB0byBhbg0KPj4+ZWFybGllciByZXN1bHQNCj4+ PiBkdWUgdG8gY29tbXVuaXR5IGludGVyZXN0cyBpbiBoYXZpbmcgc3VjaCBjYXBhYmlsaXR5IGlu IGEgc2hvcnQNCj4+PnRpbWVmcmFtZS4NCj4+PiBUaGUgc3BlY2lmaWNhdGlvbihzKSBwcm9kdWNl ZCBieSB0aGUgV0cgd2lsbCBpbmNsdWRlIGEgc3RhbmRhcmQNCj4+Pm1lY2hhbmlzbQ0KPj4+IGZv ciBhdXRoZW50aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlvbiwgZm9yIGRhdGEgaW50ZWdyaXR5LCBh bmQgZm9yDQo+Pj4gcHJvdmlkaW5nIGZvciBwcml2YWN5IGluIG9wZXJhdGlvbi4NCj4+PiANCj4+ PiBUaGUgV0cgd2lsbCBwcm9kdWNlIHRoZSBmb2xsb3dpbmcgZGVsaXZlcmFibGVzOg0KPj4+IA0K Pj4+ICogVXNlIGNhc2UgZG9jdW1lbnQgdG8gZW5zdXJlIGNvbW1vbmFsaXR5IG9mIHRoZSB3b3Jr IGFtb25nIHRoZQ0KPj4+IHBhcnRpY2lwYW50cyBpbiB0aGUgV29ya2luZyBHcm91cC4gIFRoaXMg ZG9jdW1lbnQgbWF5IGJlIGRldGVybWluZWQgYnkNCj4+PnRoZQ0KPj4+IHdvcmtpbmcgZ3JvdXAg dG8gcmVtYWluIGluZm9ybWFsIGFuZCBub3QgYmUgcHVibGlzaGVkLg0KPj4+ICogRG9jdW1lbnQg b3IgRG9jdW1lbnRzIGRlc2NyaWJpbmcgdGhlIHByb2JsZW0gc3BhY2UsIHVzZSBjYXNlcywNCj4+ PnByb3RvY29sDQo+Pj4gcmVxdWlyZW1lbnRzIGFuZCBvdGhlciBxdWFsaWZ5aW5nIGluZm9ybWF0 aW9uIGFzIHRoZSBXRyBzZWVzIGZpdC4NCj4+PiAqIERvY3VtZW50IG9yIERvY3VtZW50cyBzcGVj aWZ5aW5nIGEgcHJvdG9jb2wgYW5kIGFzc29jaWF0ZWQgZGF0YQ0KPj4+bW9kZWxzDQo+Pj4gdG8g YWRkcmVzcyB0aGUgV0cgc3RhdGVkIGdvYWwuDQo+PiANCj4+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBEb3RzIG1haWxpbmcgbGlzdA0KPj4gRG90 c0BpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kb3Rz DQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5E b3RzIG1haWxpbmcgbGlzdA0KPkRvdHNAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2RvdHMNCg0K From nobody Sun May 10 18:15:53 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 668841ACC91 for ; Sun, 10 May 2015 18:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, MIME_8BIT_HEADER=0.3, 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 mAESrbosNRyT for ; Sun, 10 May 2015 18:15:50 -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 796701ACC8D for ; Sun, 10 May 2015 18:15:49 -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 BVW52196; Mon, 11 May 2015 01:15:47 +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, 11 May 2015 02:15:46 +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; Mon, 11 May 2015 09:15:42 +0800 From: "Xialiang (Frank)" To: Kathleen Moriarty , Andrew Mortensen Thread-Topic: [Dots] Draft Charter Thread-Index: AQHQfE+l/Sly82ObQkmwTXHnIFPOXJ1nsvEAgAvJXwCAApnrkA== Date: Mon, 11 May 2015 01:15:42 +0000 Message-ID: References: <6DEAC84F-75B4-41D6-A429-3C2328BEAEBA@arbor.net> In-Reply-To: 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: Cc: "Teague, Nik" , "dots@ietf.org" Subject: [Dots] =?utf-8?b?562U5aSNOiAgRHJhZnQgQ2hhcnRlcg==?= X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 01:15:52 -0000 SGkgQWxsLA0KSSBzdXBwb3J0IHRoZSBjaGFydGVyIHdpdGggc29tZSBjb21tZW50cyBwcm9wb3Nl ZCBiZWZvcmUuDQpJIGFsc28gdGhpbmsgdGhpcyB3b3JrIGlzIHZhbHVhYmxlIGZvciBBbnRpLURE b1MgdGVjaG5vbG9naWVzIGV2b2x1dGlvbi4NCg0KQi5SLg0KRnJhbmsNCg0KLS0tLS3pgq7ku7bl jp/ku7YtLS0tLQ0K5Y+R5Lu25Lq6OiBEb3RzIFttYWlsdG86ZG90cy1ib3VuY2VzQGlldGYub3Jn XSDku6PooaggS2F0aGxlZW4gTW9yaWFydHkNCuWPkemAgeaXtumXtDogMjAxNeW5tDXmnIgxMOaX pSAxOjI4DQrmlLbku7bkuro6IEFuZHJldyBNb3J0ZW5zZW4NCuaKhOmAgTogVGVhZ3VlLCBOaWs7 IGRvdHNAaWV0Zi5vcmcNCuS4u+mimDogUmU6IFtEb3RzXSBEcmFmdCBDaGFydGVyDQoNCkFyZSB0 aGVyZSBhbnkgb3RoZXIgY29tbWVudHMgb24gdGhlIHByb3Bvc2VkIGNoYXJ0ZXI/ICBJZiB5b3Un dmUgcmVhZCBpdCBhbmQgZG8gbm90IGhhdmUgY2hhbmdlcywgZXhwcmVzc2lvbnMgb2Ygc3VwcG9y dCBmb3IgdGhlIGN1cnJlbnQgdmVyc2lvbiB3b3VsZCBiZSBoZWxwZnVsIHRvIHVuZGVyc3RhbmQg aG93IG1hbnkgZm9sa3MgYWdyZWUgdGhpcyBpcyBpbXBvcnRhbnQgYW5kIHdhbnQgdG8gd29yayBv biB0aGlzIGluIHRoZSBJRVRGLg0KDQpUaGFuayB5b3UsDQpLYXRobGVlbiANCg0KU2VudCBmcm9t IG15IGlQaG9uZQ0KDQo+IE9uIE1heSAyLCAyMDE1LCBhdCAxOjI4IEFNLCBBbmRyZXcgTW9ydGVu c2VuIDxhbW9ydGVuc2VuQGFyYm9yLm5ldD4gd3JvdGU6DQo+IA0KPiBIaSBOaWsuIFRoYW5rcyBm b3IgZ2l2aW5nIHVzIGEgZ29vZCBmb3VuZGF0aW9uIHRvIGJ1aWxkIHVwb24uDQo+IA0KPiBDb21t ZW50cy9uaXRwaWNrcyBpbmxpbmUsIHRyeWluZyBub3QgdG8gb3ZlcmxhcCB0b28gbXVjaCB3aXRo IEFkYW0uDQo+IA0KPiBhbmRyZXcNCj4gDQo+IC0tDQo+IA0KPj4gVGhlIGFpbSBvZiBERG9TIE9w ZW4gVGhyZWF0IFNpZ25hbGluZyAoRE9UUykgaXMgdG8gZGV2ZWxvcCBhIA0KPj4gc3RhbmRhcmRz IGJhc2VkIGFwcHJvYWNoIHRvIHRoZSByZWFsIHRpbWUgc2lnbmFsaW5nIG9mIEREb1MgcmVsYXRl ZCANCj4+IHRlbGVtZXRyeSBhbmQgdGhyZWF0IGhhbmRsaW5nIGRhdGEgYmV0d2VlbiBlbGVtZW50 cyBjb25jZXJuZWQgd2l0aCBhdHRhY2sgbWl0aWdhdGlvbi4NCj4gDQo+IEkgdGhpbmsgdGhlIOKA nHJlYWwgdGltZeKAnSBwaHJhc2UgaGVyZSBpcyBpbnRlbmRlZCB0byBlbXBoYXNpemUgdGhhdCB0 aGUgc2lnbmFsaW5nIGlzIGV4cGVjdGVkIHRvIGJlIGRvbmUgdW5kZXIgYXR0YWNrIGNvbmRpdGlv bnMuIFRoYXQgc2VlbXMgdG8gbWUgYW4gaW1wb3J0YW50IGRpZmZlcmVudGlhdG9yIGZyb20gbWls ZS4gV2Ugc2hvdWxkIG1ha2UgaXQgZXhwbGljaXQgaGVyZS4NCj4gDQo+PiBUaGUgZWxlbWVudHMg bWF5IGJlIGRlc2NyaWJlZCBhczoNCj4+ICogT24tcHJlbWlzZSBERG9TIG1pdGlnYXRpb24gcGxh dGZvcm1zDQo+PiAqIFNlcnZpY2UgcHJvdmlkZXIgRERvUyBtaXRpZ2F0aW9uIHBsYXRmb3Jtcw0K Pj4gKiBPdGhlciBuZXR3b3JrIGRldmljZXMvcGxhdGZvcm1zIHRoYXQgYXJlIGFibGUgdG8gc2Vu c2UgRERvUyBhbmQgDQo+PiByZXNwb25kDQo+IA0KPiBTb21ldGhpbmcgYWxvbmcgdGhlIGxpbmVz IG9mIOKAnE90aGVyIGRldmljZXMgd2l0aCBuZXR3b3JrIHBlcnNwZWN0aXZlIHBlcmZvcm1pbmcg dHJhZmZpYyBhbmFseXNpc+KAnSAgb3Ig4oCc4oCmZW5nYWdlZCBpbiB0cmFmZmljIGFuYWx5c2lz 4oCdIHNob3VsZCBlbmNvbXBhc3MgdGhpbmdzIGxpa2UgZmxvdyBtb25pdG9yaW5nIGFuZCBJRFMv SVBTLg0KPiANCj4+ICogQ2hhaW5lZCBpbnN0YW5jZXMgb2YgdGhlIGFib3ZlDQo+PiANCj4+IFRo ZXNlIGVsZW1lbnRzIG1heSBiZSBjb21tdW5pY2F0aW5nIGludGVyLWRvbWFpbiBvciBpbnRyYS1k b21haW4gb3ZlciANCj4+IGxpbmtzIHRoYXQgbWF5IGJlIGNvbmdlc3RlZCBieSBhdHRhY2sgdHJh ZmZpYyByZXN1bHRpbmcgaW4gaG9zdGlsZSANCj4+IGNvbmRpdGlvbnMgZm9yIHRyYWRpdGlvbmFs IGNvbm5lY3Rpb24gb3JpZW50ZWQgYXBwcm9hY2hlcyBhbmQgbW9yZSANCj4+IGdlbmVyYWxpemVk IHNpZ25hbGluZyBhbmQgdGVsZW1ldHJ5IHNvbHV0aW9ucy4NCj4gDQo+IFN0cmlrZSDigJx0cmFk aXRpb25hbOKAnS4gUmVnYXJkbGVzcyBvZiBpbm5vdmF0aW9uLCBhIGNvbm5lY3Rpb24tb3JpZW50 ZWQgcHJvdG9jb2wgaXMgbm90IGFwcHJvcHJpYXRlIGZvciBkb3RzIGZvciB0aGUgcmVhc29ucyB5 b3XigJl2ZSBqdXN0IHN0YXRlZC4gSSB0aGluayB0aGlzIGNhbiBiZSB0aWdodGVuZWQgdG8sIGUu Zy4sIOKAnOKApmhvc3RpbGUgY29uZGl0aW9ucyBmb3IgY29ubmVjdGlvbi1vcmllbnRlZCBzaWdu YWxpbmcgYW5kIHRlbGVtZXRyeSBwcm90b2NvbHMu4oCdDQo+IA0KPj4gUm9idXN0bmVzcyB1bmRl ciB0aGVzZQ0KPj4gY29uZGl0aW9ucyBpcyBwYXJhbW91bnQgd2hpbGUgZW5zdXJpbmcgYXBwcm9w cmlhdGUgcmVnYXJkIGZvciANCj4+IGF1dGhlbnRpY2F0aW9uLCBhdXRob3JpemF0aW9uLCBwcml2 YWN5IGFuZCBkYXRhIGludGVncml0eS4gIEVsZW1lbnRzIA0KPj4gbWF5IGJlIGRlcGxveWVkIGFz IHBhcnQgb2YgYSB3aWRlciBzdHJhdGVneSBpbmNvcnBvcmF0aW5nIG11bHRpcGxlIA0KPj4gcG9p bnRzIG9mIGRldGVjdGlvbiBhbmQgbWl0aWdhdGlvbiwgYm90aCBvbiBwcmVtaXNlIG9yIHNlcnZp Y2UgcHJvdmlkZXIgYmFzZWQuDQo+PiBTaG91bGQgbWl0aWdhdGlvbiBuZWVkIHRvIG1vdmUgYmV0 d2VlbiBlbGVtZW50cyBpbiB0aGUgY2hhaW4gdGhlbiANCj4+IGVmZmVjdGl2ZSBzaWduYWxpbmcg b2YgdGVsZW1ldHJ5IGFuZCBjdXJyZW50IHRocmVhdCBoYW5kbGluZyBpcyBlc3NlbnRpYWwuDQo+ IA0KPiBJcyB0aGUgaW1wbGljYXRpb24gdGhhdCBhbiBvbi1wcmVtaXNlIGRldmljZSBtYXkgc2ln bmFsIGxhdGVyYWxseSBpbnRlbnRpb25hbD8gT3IgaXMgdGhlIGV4cGVjdGF0aW9uIHRoYXQgZWFj aCBzdWJzZXF1ZW50IGVsZW1lbnQgaW4gdGhlIGNoYWluIHdpbGwgYmUgdXBzdHJlYW0gZnJvbSB0 aGUgcHJldmlvdXM/DQo+IA0KPj4gRmVlZGJhY2sgYmV0d2VlbiBwYXJ0aWNpcGF0aW5nIGVsZW1l bnRzIGlzIHJlcXVpcmVkIGZvciBpbmNyZWFzZWQgDQo+PiBhd2FyZW5lc3MgZm9yIGVmZmVjdGl2 ZSBkZWNpc2lvbiBtYWtpbmcuDQo+PiANCj4+IFRoZSBXRyB3aWxsLCB3aGVyZSBhcHByb3ByaWF0 ZSwgcmV1c2UgZXhpc3Rpbmcgc3RhbmRhcmQgcHJvdG9jb2xzIGFuZCANCj4+IG1lY2hhbmlzbXMs IGZvciBpbnN0YW5jZSBJUEZJWCBhbmQgaXRzIHRlbXBsYXRpbmcgbWVjaGFuaXNtLg0KPj4gVGhl IGNoYXJ0ZXIgb2YgdGhlIHdvcmtpbmcgZ3JvdXAgaXMgdG8gcHJvZHVjZSBvbmUgb3IgbW9yZSBz dGFuZGFyZHMgDQo+PiB0cmFjayBzcGVjaWZpY2F0aW9uIHRvIHByb3ZpZGUgZm9yIHRoaXMgb3Bl biBzaWduYWxpbmcgaW4gdGhlIEREb1MgDQo+PiBwcm9ibGVtIHNwYWNlLiAgV2hpbGUgdGhlIHJl c3VsdGluZyBzdGFuZGFyZHMgc2hvdWxkIGJlIGRlc2lnbmVkIHNvIA0KPj4gdGhhdCB0aGVyZcK5 cyBhIHBvc3NpYmlsaXR5IG9mIGFwcGx5aW5nIHRoZW0gdG8gbmV0d29yayBzZWN1cml0eSANCj4+ IGFwcGxpY2F0aW9ucyBiZXlvbmQgRERvUw0KPiANCj4g4oCc4oCmZGVzaWduZWQgc28gdGhleSBt YXkgYXBwbHkgdG8gbmV0d29yayBzZWN1cml0eSBhcHBsaWNhdGlvbnPigKYiDQo+IA0KPj4gbWl0 aWdhdGlvbiwgdGhpcyB3b3JraW5nIGdyb3VwIHdpbGwgZm9jdXMgb24ganVzdCBERG9TIG1pdGln YXRpb24uDQo+IA0KPiBTdHJpa2Ug4oCcanVzdOKAnS4NCj4gDQo+PiBUaGlzIHN0cmVhbWxpbmVk IGZvY3VzIG9mIHRoZSBjaGFydGVyIGlzIGludGVuZGVkIHRvIGxlYWQgdG8gYW4gDQo+PiBlYXJs aWVyIHJlc3VsdCBkdWUgdG8gY29tbXVuaXR5IGludGVyZXN0cyBpbiBoYXZpbmcgc3VjaCBjYXBh YmlsaXR5IGluIGEgc2hvcnQgdGltZWZyYW1lLg0KPj4gVGhlIHNwZWNpZmljYXRpb24ocykgcHJv ZHVjZWQgYnkgdGhlIFdHIHdpbGwgaW5jbHVkZSBhIHN0YW5kYXJkIA0KPj4gbWVjaGFuaXNtIGZv ciBhdXRoZW50aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlvbiwgZm9yIGRhdGEgaW50ZWdyaXR5LCAN Cj4+IGFuZCBmb3IgcHJvdmlkaW5nIGZvciBwcml2YWN5IGluIG9wZXJhdGlvbi4NCj4+IA0KPj4g VGhlIFdHIHdpbGwgcHJvZHVjZSB0aGUgZm9sbG93aW5nIGRlbGl2ZXJhYmxlczoNCj4+IA0KPj4g KiBVc2UgY2FzZSBkb2N1bWVudCB0byBlbnN1cmUgY29tbW9uYWxpdHkgb2YgdGhlIHdvcmsgYW1v bmcgdGhlIA0KPj4gcGFydGljaXBhbnRzIGluIHRoZSBXb3JraW5nIEdyb3VwLiAgVGhpcyBkb2N1 bWVudCBtYXkgYmUgZGV0ZXJtaW5lZCANCj4+IGJ5IHRoZSB3b3JraW5nIGdyb3VwIHRvIHJlbWFp biBpbmZvcm1hbCBhbmQgbm90IGJlIHB1Ymxpc2hlZC4NCj4+ICogRG9jdW1lbnQgb3IgRG9jdW1l bnRzIGRlc2NyaWJpbmcgdGhlIHByb2JsZW0gc3BhY2UsIHVzZSBjYXNlcywgDQo+PiBwcm90b2Nv bCByZXF1aXJlbWVudHMgYW5kIG90aGVyIHF1YWxpZnlpbmcgaW5mb3JtYXRpb24gYXMgdGhlIFdH IHNlZXMgZml0Lg0KPj4gKiBEb2N1bWVudCBvciBEb2N1bWVudHMgc3BlY2lmeWluZyBhIHByb3Rv Y29sIGFuZCBhc3NvY2lhdGVkIGRhdGEgDQo+PiBtb2RlbHMgdG8gYWRkcmVzcyB0aGUgV0cgc3Rh dGVkIGdvYWwuDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiBEb3RzIG1haWxpbmcgbGlzdA0KPiBEb3RzQGlldGYub3JnDQo+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG90cw0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRG90cyBtYWlsaW5nIGxpc3QNCkRvdHNAaWV0 Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG90cw0K From nobody Mon May 11 01:50:32 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@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: [Dots] [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93 X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." 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:25:05 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@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: X-Mailman-Approved-At: Mon, 11 May 2015 04:25:04 -0700 Cc: "i2rs@ietf.org" , "netmod@ietf.org" , "i2nsf@ietf.org" , "dots@ietf.org" , Linda Dunbar , "Zarny, Myo" , Kathleen Moriarty Subject: Re: [Dots] [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93 X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." 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 09:45:33 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC161ACDF6 for ; Mon, 11 May 2015 09:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 bYwIY7ZCfzD6 for ; Mon, 11 May 2015 09:45:30 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6E601A8A67 for ; Mon, 11 May 2015 09:45:29 -0700 (PDT) X-AuditID: c6180641-f79086d000001909-ca-555078477c12 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id A6.E0.06409.74870555; Mon, 11 May 2015 11:37:11 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0210.002; Mon, 11 May 2015 12:45:21 -0400 From: Daniel Migault To: Kathleen Moriarty , Andrew Mortensen Thread-Topic: [Dots] Draft Charter Thread-Index: AQHQhJjcRD3cWfX+NUGeihqUtXjKN510NOgAgALVKlA= Date: Mon, 11 May 2015 16:45:20 +0000 Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C160250C@eusaamb107.ericsson.se> References: <6DEAC84F-75B4-41D6-A429-3C2328BEAEBA@arbor.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrILMWRmVeSWpSXmKPExsUyuXRPgq57RUCowbt3khYL3r1jtVj75gir RcPOfIu2T0eZHFg8tlzuZffYOesuu8eSJT+ZPHZtbmALYInisklJzcksSy3St0vgyvj98xxr wQSTigm7f7A2MD4x6mLk5JAQMJF48nMVG4QtJnHh3nogm4tDSOAoo8SZd7NYIJzljBL3lk1h AaliEzCSaDvUzw5iiwgkS7y9sY65i5GDg1nAU+LKXSWQsLCAosTTN0ehSpQklm96wwphW0k8 vN4GZrMIqEpcODcPbDGvgLdE47oJjCC2kMA0RolTa71AbE4BW4mJi5aD1TACHff91BomEJtZ QFzi1pP5TBBHC0gs2XOeGcIWlXj5+B8rhK0kMWnpOVaI0zQl1u/Sh2hVlJjS/ZAdYq2gxMmZ T1gmMIrNQjJ1FkLHLCQds5B0LGBkWcXIUVqcWpabbmS4iREYR8ck2Bx3MC74ZHmIUYCDUYmH d8Ec/1Ah1sSy4srcQ4zSHCxK4rxlVw6GCAmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamAMX1g0 48zWOyc/mGuo8G4Nb9ifsvhodu8Zi7W/NFjf8J6OdUlNPX92V9ist/rvq4Vfratu/mS/mslY eJtjiUhOotHBE3J9+611P6tN+HnigNiNlR8zrXcLOf2Y43VH4cIXgz1qjwW/F22uEco/8XXb KuZUmQPSbzO8b99yNexLmH+nWv51hudlJZbijERDLeai4kQA8xPym4QCAAA= Archived-At: Cc: "Teague, Nik" , "dots@ietf.org" Subject: Re: [Dots] Draft Charter X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 16:45:32 -0000 SSBzdXBwb3J0IHRoZSBjaGFydGVyLg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiBEb3RzIFttYWlsdG86ZG90cy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgS2F0 aGxlZW4gTW9yaWFydHkNClNlbnQ6IFNhdHVyZGF5LCBNYXkgMDksIDIwMTUgMToyOCBQTQ0KVG86 IEFuZHJldyBNb3J0ZW5zZW4NCkNjOiBUZWFndWUsIE5pazsgZG90c0BpZXRmLm9yZw0KU3ViamVj dDogUmU6IFtEb3RzXSBEcmFmdCBDaGFydGVyDQoNCkFyZSB0aGVyZSBhbnkgb3RoZXIgY29tbWVu dHMgb24gdGhlIHByb3Bvc2VkIGNoYXJ0ZXI/ICBJZiB5b3UndmUgcmVhZCBpdCBhbmQgZG8gbm90 IGhhdmUgY2hhbmdlcywgZXhwcmVzc2lvbnMgb2Ygc3VwcG9ydCBmb3IgdGhlIGN1cnJlbnQgdmVy c2lvbiB3b3VsZCBiZSBoZWxwZnVsIHRvIHVuZGVyc3RhbmQgaG93IG1hbnkgZm9sa3MgYWdyZWUg dGhpcyBpcyBpbXBvcnRhbnQgYW5kIHdhbnQgdG8gd29yayBvbiB0aGlzIGluIHRoZSBJRVRGLg0K DQpUaGFuayB5b3UsDQpLYXRobGVlbiANCg0KU2VudCBmcm9tIG15IGlQaG9uZQ0KDQo+IE9uIE1h eSAyLCAyMDE1LCBhdCAxOjI4IEFNLCBBbmRyZXcgTW9ydGVuc2VuIDxhbW9ydGVuc2VuQGFyYm9y Lm5ldD4gd3JvdGU6DQo+IA0KPiBIaSBOaWsuIFRoYW5rcyBmb3IgZ2l2aW5nIHVzIGEgZ29vZCBm b3VuZGF0aW9uIHRvIGJ1aWxkIHVwb24uDQo+IA0KPiBDb21tZW50cy9uaXRwaWNrcyBpbmxpbmUs IHRyeWluZyBub3QgdG8gb3ZlcmxhcCB0b28gbXVjaCB3aXRoIEFkYW0uDQo+IA0KPiBhbmRyZXcN Cj4gDQo+IC0tDQo+IA0KPj4gVGhlIGFpbSBvZiBERG9TIE9wZW4gVGhyZWF0IFNpZ25hbGluZyAo RE9UUykgaXMgdG8gZGV2ZWxvcCBhIA0KPj4gc3RhbmRhcmRzIGJhc2VkIGFwcHJvYWNoIHRvIHRo ZSByZWFsIHRpbWUgc2lnbmFsaW5nIG9mIEREb1MgcmVsYXRlZCANCj4+IHRlbGVtZXRyeSBhbmQg dGhyZWF0IGhhbmRsaW5nIGRhdGEgYmV0d2VlbiBlbGVtZW50cyBjb25jZXJuZWQgd2l0aCBhdHRh Y2sgbWl0aWdhdGlvbi4NCj4gDQo+IEkgdGhpbmsgdGhlIOKAnHJlYWwgdGltZeKAnSBwaHJhc2Ug aGVyZSBpcyBpbnRlbmRlZCB0byBlbXBoYXNpemUgdGhhdCB0aGUgc2lnbmFsaW5nIGlzIGV4cGVj dGVkIHRvIGJlIGRvbmUgdW5kZXIgYXR0YWNrIGNvbmRpdGlvbnMuIFRoYXQgc2VlbXMgdG8gbWUg YW4gaW1wb3J0YW50IGRpZmZlcmVudGlhdG9yIGZyb20gbWlsZS4gV2Ugc2hvdWxkIG1ha2UgaXQg ZXhwbGljaXQgaGVyZS4NCj4gDQo+PiBUaGUgZWxlbWVudHMgbWF5IGJlIGRlc2NyaWJlZCBhczoN Cj4+ICogT24tcHJlbWlzZSBERG9TIG1pdGlnYXRpb24gcGxhdGZvcm1zDQo+PiAqIFNlcnZpY2Ug cHJvdmlkZXIgRERvUyBtaXRpZ2F0aW9uIHBsYXRmb3Jtcw0KPj4gKiBPdGhlciBuZXR3b3JrIGRl dmljZXMvcGxhdGZvcm1zIHRoYXQgYXJlIGFibGUgdG8gc2Vuc2UgRERvUyBhbmQgDQo+PiByZXNw b25kDQo+IA0KPiBTb21ldGhpbmcgYWxvbmcgdGhlIGxpbmVzIG9mIOKAnE90aGVyIGRldmljZXMg d2l0aCBuZXR3b3JrIHBlcnNwZWN0aXZlIHBlcmZvcm1pbmcgdHJhZmZpYyBhbmFseXNpc+KAnSAg b3Ig4oCc4oCmZW5nYWdlZCBpbiB0cmFmZmljIGFuYWx5c2lz4oCdIHNob3VsZCBlbmNvbXBhc3Mg dGhpbmdzIGxpa2UgZmxvdyBtb25pdG9yaW5nIGFuZCBJRFMvSVBTLg0KPiANCj4+ICogQ2hhaW5l ZCBpbnN0YW5jZXMgb2YgdGhlIGFib3ZlDQo+PiANCj4+IFRoZXNlIGVsZW1lbnRzIG1heSBiZSBj b21tdW5pY2F0aW5nIGludGVyLWRvbWFpbiBvciBpbnRyYS1kb21haW4gb3ZlciANCj4+IGxpbmtz IHRoYXQgbWF5IGJlIGNvbmdlc3RlZCBieSBhdHRhY2sgdHJhZmZpYyByZXN1bHRpbmcgaW4gaG9z dGlsZSANCj4+IGNvbmRpdGlvbnMgZm9yIHRyYWRpdGlvbmFsIGNvbm5lY3Rpb24gb3JpZW50ZWQg YXBwcm9hY2hlcyBhbmQgbW9yZSANCj4+IGdlbmVyYWxpemVkIHNpZ25hbGluZyBhbmQgdGVsZW1l dHJ5IHNvbHV0aW9ucy4NCj4gDQo+IFN0cmlrZSDigJx0cmFkaXRpb25hbOKAnS4gUmVnYXJkbGVz cyBvZiBpbm5vdmF0aW9uLCBhIGNvbm5lY3Rpb24tb3JpZW50ZWQgcHJvdG9jb2wgaXMgbm90IGFw cHJvcHJpYXRlIGZvciBkb3RzIGZvciB0aGUgcmVhc29ucyB5b3XigJl2ZSBqdXN0IHN0YXRlZC4g SSB0aGluayB0aGlzIGNhbiBiZSB0aWdodGVuZWQgdG8sIGUuZy4sIOKAnOKApmhvc3RpbGUgY29u ZGl0aW9ucyBmb3IgY29ubmVjdGlvbi1vcmllbnRlZCBzaWduYWxpbmcgYW5kIHRlbGVtZXRyeSBw cm90b2NvbHMu4oCdDQo+IA0KPj4gUm9idXN0bmVzcyB1bmRlciB0aGVzZQ0KPj4gY29uZGl0aW9u cyBpcyBwYXJhbW91bnQgd2hpbGUgZW5zdXJpbmcgYXBwcm9wcmlhdGUgcmVnYXJkIGZvciANCj4+ IGF1dGhlbnRpY2F0aW9uLCBhdXRob3JpemF0aW9uLCBwcml2YWN5IGFuZCBkYXRhIGludGVncml0 eS4gIEVsZW1lbnRzIA0KPj4gbWF5IGJlIGRlcGxveWVkIGFzIHBhcnQgb2YgYSB3aWRlciBzdHJh dGVneSBpbmNvcnBvcmF0aW5nIG11bHRpcGxlIA0KPj4gcG9pbnRzIG9mIGRldGVjdGlvbiBhbmQg bWl0aWdhdGlvbiwgYm90aCBvbiBwcmVtaXNlIG9yIHNlcnZpY2UgcHJvdmlkZXIgYmFzZWQuDQo+ PiBTaG91bGQgbWl0aWdhdGlvbiBuZWVkIHRvIG1vdmUgYmV0d2VlbiBlbGVtZW50cyBpbiB0aGUg Y2hhaW4gdGhlbiANCj4+IGVmZmVjdGl2ZSBzaWduYWxpbmcgb2YgdGVsZW1ldHJ5IGFuZCBjdXJy ZW50IHRocmVhdCBoYW5kbGluZyBpcyBlc3NlbnRpYWwuDQo+IA0KPiBJcyB0aGUgaW1wbGljYXRp b24gdGhhdCBhbiBvbi1wcmVtaXNlIGRldmljZSBtYXkgc2lnbmFsIGxhdGVyYWxseSBpbnRlbnRp b25hbD8gT3IgaXMgdGhlIGV4cGVjdGF0aW9uIHRoYXQgZWFjaCBzdWJzZXF1ZW50IGVsZW1lbnQg aW4gdGhlIGNoYWluIHdpbGwgYmUgdXBzdHJlYW0gZnJvbSB0aGUgcHJldmlvdXM/DQo+IA0KPj4g RmVlZGJhY2sgYmV0d2VlbiBwYXJ0aWNpcGF0aW5nIGVsZW1lbnRzIGlzIHJlcXVpcmVkIGZvciBp bmNyZWFzZWQgDQo+PiBhd2FyZW5lc3MgZm9yIGVmZmVjdGl2ZSBkZWNpc2lvbiBtYWtpbmcuDQo+ PiANCj4+IFRoZSBXRyB3aWxsLCB3aGVyZSBhcHByb3ByaWF0ZSwgcmV1c2UgZXhpc3Rpbmcgc3Rh bmRhcmQgcHJvdG9jb2xzIGFuZCANCj4+IG1lY2hhbmlzbXMsIGZvciBpbnN0YW5jZSBJUEZJWCBh bmQgaXRzIHRlbXBsYXRpbmcgbWVjaGFuaXNtLg0KPj4gVGhlIGNoYXJ0ZXIgb2YgdGhlIHdvcmtp bmcgZ3JvdXAgaXMgdG8gcHJvZHVjZSBvbmUgb3IgbW9yZSBzdGFuZGFyZHMgDQo+PiB0cmFjayBz cGVjaWZpY2F0aW9uIHRvIHByb3ZpZGUgZm9yIHRoaXMgb3BlbiBzaWduYWxpbmcgaW4gdGhlIERE b1MgDQo+PiBwcm9ibGVtIHNwYWNlLiAgV2hpbGUgdGhlIHJlc3VsdGluZyBzdGFuZGFyZHMgc2hv dWxkIGJlIGRlc2lnbmVkIHNvIA0KPj4gdGhhdCB0aGVyZcK5cyBhIHBvc3NpYmlsaXR5IG9mIGFw cGx5aW5nIHRoZW0gdG8gbmV0d29yayBzZWN1cml0eSANCj4+IGFwcGxpY2F0aW9ucyBiZXlvbmQg RERvUw0KPiANCj4g4oCc4oCmZGVzaWduZWQgc28gdGhleSBtYXkgYXBwbHkgdG8gbmV0d29yayBz ZWN1cml0eSBhcHBsaWNhdGlvbnPigKYiDQo+IA0KPj4gbWl0aWdhdGlvbiwgdGhpcyB3b3JraW5n IGdyb3VwIHdpbGwgZm9jdXMgb24ganVzdCBERG9TIG1pdGlnYXRpb24uDQo+IA0KPiBTdHJpa2Ug 4oCcanVzdOKAnS4NCj4gDQo+PiBUaGlzIHN0cmVhbWxpbmVkIGZvY3VzIG9mIHRoZSBjaGFydGVy IGlzIGludGVuZGVkIHRvIGxlYWQgdG8gYW4gDQo+PiBlYXJsaWVyIHJlc3VsdCBkdWUgdG8gY29t bXVuaXR5IGludGVyZXN0cyBpbiBoYXZpbmcgc3VjaCBjYXBhYmlsaXR5IGluIGEgc2hvcnQgdGlt ZWZyYW1lLg0KPj4gVGhlIHNwZWNpZmljYXRpb24ocykgcHJvZHVjZWQgYnkgdGhlIFdHIHdpbGwg aW5jbHVkZSBhIHN0YW5kYXJkIA0KPj4gbWVjaGFuaXNtIGZvciBhdXRoZW50aWNhdGlvbiBhbmQg YXV0aG9yaXphdGlvbiwgZm9yIGRhdGEgaW50ZWdyaXR5LCANCj4+IGFuZCBmb3IgcHJvdmlkaW5n IGZvciBwcml2YWN5IGluIG9wZXJhdGlvbi4NCj4+IA0KPj4gVGhlIFdHIHdpbGwgcHJvZHVjZSB0 aGUgZm9sbG93aW5nIGRlbGl2ZXJhYmxlczoNCj4+IA0KPj4gKiBVc2UgY2FzZSBkb2N1bWVudCB0 byBlbnN1cmUgY29tbW9uYWxpdHkgb2YgdGhlIHdvcmsgYW1vbmcgdGhlIA0KPj4gcGFydGljaXBh bnRzIGluIHRoZSBXb3JraW5nIEdyb3VwLiAgVGhpcyBkb2N1bWVudCBtYXkgYmUgZGV0ZXJtaW5l ZCANCj4+IGJ5IHRoZSB3b3JraW5nIGdyb3VwIHRvIHJlbWFpbiBpbmZvcm1hbCBhbmQgbm90IGJl IHB1Ymxpc2hlZC4NCj4+ICogRG9jdW1lbnQgb3IgRG9jdW1lbnRzIGRlc2NyaWJpbmcgdGhlIHBy b2JsZW0gc3BhY2UsIHVzZSBjYXNlcywgDQo+PiBwcm90b2NvbCByZXF1aXJlbWVudHMgYW5kIG90 aGVyIHF1YWxpZnlpbmcgaW5mb3JtYXRpb24gYXMgdGhlIFdHIHNlZXMgZml0Lg0KPj4gKiBEb2N1 bWVudCBvciBEb2N1bWVudHMgc3BlY2lmeWluZyBhIHByb3RvY29sIGFuZCBhc3NvY2lhdGVkIGRh dGEgDQo+PiBtb2RlbHMgdG8gYWRkcmVzcyB0aGUgV0cgc3RhdGVkIGdvYWwuDQo+IA0KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBEb3RzIG1haWxp bmcgbGlzdA0KPiBEb3RzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vZG90cw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KRG90cyBtYWlsaW5nIGxpc3QNCkRvdHNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vZG90cw0K From nobody Mon May 11 19:03:48 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 597351B2B60 for ; Mon, 11 May 2015 19:03:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_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 em55L00TUs2b for ; Mon, 11 May 2015 19:03:43 -0700 (PDT) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.107]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B62301B2B5C for ; Mon, 11 May 2015 19:03:43 -0700 (PDT) Received: from [216.82.253.243] by server-11.bemta-7.messagelabs.com id AA/40-02799-E7F51555; Tue, 12 May 2015 02:03:42 +0000 X-Env-Sender: Scott.Barvick@corero.com X-Msg-Ref: server-5.tower-171.messagelabs.com!1431396220!11792045!1 X-Originating-IP: [71.184.227.49] X-StarScan-Received: X-StarScan-Version: 6.13.14; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30221 invoked from network); 12 May 2015 02:03:41 -0000 Received: from mercury.corero.com (HELO MERCURY.corero.com) (71.184.227.49) by server-5.tower-171.messagelabs.com with AES128-SHA encrypted SMTP; 12 May 2015 02:03:41 -0000 Received: from MERCURY.corero.com ([fe80::2c05:6b26:abe2:ad24]) by MERCURY.corero.com ([fe80::2c05:6b26:abe2:ad24%19]) with mapi id 14.03.0224.002; Mon, 11 May 2015 22:03:40 -0400 From: Scott Barvick To: Kathleen Moriarty Thread-Topic: [Dots] Draft Charter Thread-Index: AQHQfE+l/Sly82ObQkmwTXHnIFPOXJ1ofBsAgAvJYACAA7StgA== Date: Tue, 12 May 2015 02:03:40 +0000 Message-ID: <8417C2FD-7784-4E75-BB83-D0E58773F39E@corero.com> References: <6DEAC84F-75B4-41D6-A429-3C2328BEAEBA@arbor.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.59.35] Content-Type: text/plain; charset="Windows-1252" Content-ID: <604193A5E6DD834BBA55ED2B26CB8336@corero.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Andrew Mortensen , "dots@ietf.org" , Nik Teague Subject: Re: [Dots] Draft Charter X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 02:03:46 -0000 Kathleen, I=92ll also add my support for the charter and commitment to actively work = on the deliverables that it defines. Regards, Scott On May 9, 2015, at 1:28 PM, Kathleen Moriarty wrote: > Are there any other comments on the proposed charter? If you've read it = and do not have changes, expressions of support for the current version wou= ld be helpful to understand how many folks agree this is important and want= to work on this in the IETF. >=20 > Thank you, > Kathleen=20 >=20 > Sent from my iPhone >=20 >> On May 2, 2015, at 1:28 AM, Andrew Mortensen wrot= e: >>=20 >> Hi Nik. Thanks for giving us a good foundation to build upon. >>=20 >> Comments/nitpicks inline, trying not to overlap too much with Adam. >>=20 >> andrew >>=20 >> -- >>=20 >>> The aim of DDoS Open Threat Signaling (DOTS) is to develop a standards >>> based approach to the real time signaling of DDoS related telemetry and >>> threat handling data between elements concerned with attack mitigation. >>=20 >> I think the =93real time=94 phrase here is intended to emphasize that th= e signaling is expected to be done under attack conditions. That seems to m= e an important differentiator from mile. We should make it explicit here. >>=20 >>> The elements may be described as: >>> * On-premise DDoS mitigation platforms >>> * Service provider DDoS mitigation platforms >>> * Other network devices/platforms that are able to sense DDoS and respo= nd >>=20 >> Something along the lines of =93Other devices with network perspective p= erforming traffic analysis=94 or =93=85engaged in traffic analysis=94 shou= ld encompass things like flow monitoring and IDS/IPS. >>=20 >>> * Chained instances of the above >>>=20 >>> These elements may be communicating inter-domain or intra-domain over >>> links that may be congested by attack traffic resulting in hostile >>> conditions for traditional connection oriented approaches and more >>> generalized signaling and telemetry solutions. >>=20 >> Strike =93traditional=94. Regardless of innovation, a connection-oriente= d protocol is not appropriate for dots for the reasons you=92ve just stated= . I think this can be tightened to, e.g., =93=85hostile conditions for conn= ection-oriented signaling and telemetry protocols.=94 >>=20 >>> Robustness under these >>> conditions is paramount while ensuring appropriate regard for >>> authentication, authorization, privacy and data integrity. Elements ma= y >>> be deployed as part of a wider strategy incorporating multiple points o= f >>> detection and mitigation, both on premise or service provider based. >>> Should mitigation need to move between elements in the chain then >>> effective signaling of telemetry and current threat handling is essenti= al. >>=20 >> Is the implication that an on-premise device may signal laterally intent= ional? Or is the expectation that each subsequent element in the chain will= be upstream from the previous? >>=20 >>> Feedback between participating elements is required for increased >>> awareness for effective decision making. >>>=20 >>> The WG will, where appropriate, reuse existing standard protocols and >>> mechanisms, for instance IPFIX and its templating mechanism. >>> The charter of the working group is to produce one or more standards tr= ack >>> specification to provide for this open signaling in the DDoS problem >>> space. While the resulting standards should be designed so that there= =B9s a >>> possibility of applying them to network security applications beyond DD= oS >>=20 >> =93=85designed so they may apply to network security applications=85" >>=20 >>> mitigation, this working group will focus on just DDoS mitigation. >>=20 >> Strike =93just=94. >>=20 >>> This streamlined focus of the charter is intended to lead to an earlier= result >>> due to community interests in having such capability in a short timefra= me. >>> The specification(s) produced by the WG will include a standard mechani= sm >>> for authentication and authorization, for data integrity, and for >>> providing for privacy in operation. >>>=20 >>> The WG will produce the following deliverables: >>>=20 >>> * Use case document to ensure commonality of the work among the >>> participants in the Working Group. This document may be determined by = the >>> working group to remain informal and not be published. >>> * Document or Documents describing the problem space, use cases, protoc= ol >>> requirements and other qualifying information as the WG sees fit. >>> * Document or Documents specifying a protocol and associated data model= s >>> to address the WG stated goal. >>=20 >> _______________________________________________ >> Dots mailing list >> Dots@ietf.org >> https://www.ietf.org/mailman/listinfo/dots >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Mon May 11 19:06:09 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54A5A1B2B61 for ; Mon, 11 May 2015 19:06:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 y4Q7YGpo8Gii for ; Mon, 11 May 2015 19:06:04 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC4871B2B62 for ; Mon, 11 May 2015 19:06:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7518; q=dns/txt; s=iport; t=1431396365; x=1432605965; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Fodm0ffgv8yG0YLlZmapXKgBiqgOvaQn+dznAqMuqrs=; b=TDodDMwI971zT8mpKIlAJjyQIJpX0WnGQ/heK8vjZ5heWWj0pWZ5/FCT 6NBfOpP6IlgJDcNHB8jAypIgy5fOP2hmNR0lbFpI7O7t3D0AZic/KmQUD ZVbCc0a+ibX2MvwbcsWnJTbPVptgj8IGjhU3q/dPaEN5hSmdofJFP6JHq g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AmBQCvXlFV/51dJa1cgw9UXgaDGMEJgj0KhgUCHIEdTAEBAQEBAYELhCABAQEEAQEBIBE6CwwEAgEGAhEEAQEBAgIGHQMCAgIlCxQBCAgCBAENBQgMB4gRDZd7nQeTcQEBAQEBAQEBAQEBAQEBAQEBAQEBARMEgSGKGIRUFhsHBoJiL4EWAQSSGiaMCIZWjmAjgWaCEW+BRYEBAQEB X-IronPort-AV: E=Sophos;i="5.13,411,1427760000"; d="scan'208";a="418979908" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP; 12 May 2015 02:06:04 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t4C262nt003136 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 May 2015 02:06:02 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.151]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Mon, 11 May 2015 21:06:02 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Daniel Migault , Kathleen Moriarty , Andrew Mortensen Thread-Topic: [Dots] Draft Charter Thread-Index: AQHQhJjdGEzABlGgCUKrKH15838RfJ10RawAgAMYrwCAAEjEMA== Date: Tue, 12 May 2015 02:06:01 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A478424BA@xmb-rcd-x10.cisco.com> References: <6DEAC84F-75B4-41D6-A429-3C2328BEAEBA@arbor.net> <2DD56D786E600F45AC6BDE7DA4E8A8C160250C@eusaamb107.ericsson.se> In-Reply-To: <2DD56D786E600F45AC6BDE7DA4E8A8C160250C@eusaamb107.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.39.205] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "Teague, Nik" , "dots@ietf.org" Subject: Re: [Dots] Draft Charter X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 02:06:08 -0000 KzEuDQoNCi1UaXJ1DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogRG90 cyBbbWFpbHRvOmRvdHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIERhbmllbCBNaWdh dWx0DQo+IFNlbnQ6IE1vbmRheSwgTWF5IDExLCAyMDE1IDEwOjE1IFBNDQo+IFRvOiBLYXRobGVl biBNb3JpYXJ0eTsgQW5kcmV3IE1vcnRlbnNlbg0KPiBDYzogVGVhZ3VlLCBOaWs7IGRvdHNAaWV0 Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtEb3RzXSBEcmFmdCBDaGFydGVyDQo+IA0KPiBJIHN1cHBv cnQgdGhlIGNoYXJ0ZXIuDQo+IA0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g RnJvbTogRG90cyBbbWFpbHRvOmRvdHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEth dGhsZWVuIE1vcmlhcnR5DQo+IFNlbnQ6IFNhdHVyZGF5LCBNYXkgMDksIDIwMTUgMToyOCBQTQ0K PiBUbzogQW5kcmV3IE1vcnRlbnNlbg0KPiBDYzogVGVhZ3VlLCBOaWs7IGRvdHNAaWV0Zi5vcmcN Cj4gU3ViamVjdDogUmU6IFtEb3RzXSBEcmFmdCBDaGFydGVyDQo+IA0KPiBBcmUgdGhlcmUgYW55 IG90aGVyIGNvbW1lbnRzIG9uIHRoZSBwcm9wb3NlZCBjaGFydGVyPyAgSWYgeW91J3ZlIHJlYWQg aXQgYW5kDQo+IGRvIG5vdCBoYXZlIGNoYW5nZXMsIGV4cHJlc3Npb25zIG9mIHN1cHBvcnQgZm9y IHRoZSBjdXJyZW50IHZlcnNpb24gd291bGQgYmUNCj4gaGVscGZ1bCB0byB1bmRlcnN0YW5kIGhv dyBtYW55IGZvbGtzIGFncmVlIHRoaXMgaXMgaW1wb3J0YW50IGFuZCB3YW50IHRvDQo+IHdvcmsg b24gdGhpcyBpbiB0aGUgSUVURi4NCj4gDQo+IFRoYW5rIHlvdSwNCj4gS2F0aGxlZW4NCj4gDQo+ IFNlbnQgZnJvbSBteSBpUGhvbmUNCj4gDQo+ID4gT24gTWF5IDIsIDIwMTUsIGF0IDE6MjggQU0s IEFuZHJldyBNb3J0ZW5zZW4gPGFtb3J0ZW5zZW5AYXJib3IubmV0Pg0KPiB3cm90ZToNCj4gPg0K PiA+IEhpIE5pay4gVGhhbmtzIGZvciBnaXZpbmcgdXMgYSBnb29kIGZvdW5kYXRpb24gdG8gYnVp bGQgdXBvbi4NCj4gPg0KPiA+IENvbW1lbnRzL25pdHBpY2tzIGlubGluZSwgdHJ5aW5nIG5vdCB0 byBvdmVybGFwIHRvbyBtdWNoIHdpdGggQWRhbS4NCj4gPg0KPiA+IGFuZHJldw0KPiA+DQo+ID4g LS0NCj4gPg0KPiA+PiBUaGUgYWltIG9mIEREb1MgT3BlbiBUaHJlYXQgU2lnbmFsaW5nIChET1RT KSBpcyB0byBkZXZlbG9wIGENCj4gPj4gc3RhbmRhcmRzIGJhc2VkIGFwcHJvYWNoIHRvIHRoZSBy ZWFsIHRpbWUgc2lnbmFsaW5nIG9mIEREb1MgcmVsYXRlZA0KPiA+PiB0ZWxlbWV0cnkgYW5kIHRo cmVhdCBoYW5kbGluZyBkYXRhIGJldHdlZW4gZWxlbWVudHMgY29uY2VybmVkIHdpdGgNCj4gYXR0 YWNrIG1pdGlnYXRpb24uDQo+ID4NCj4gPiBJIHRoaW5rIHRoZSDigJxyZWFsIHRpbWXigJ0gcGhy YXNlIGhlcmUgaXMgaW50ZW5kZWQgdG8gZW1waGFzaXplIHRoYXQgdGhlDQo+IHNpZ25hbGluZyBp cyBleHBlY3RlZCB0byBiZSBkb25lIHVuZGVyIGF0dGFjayBjb25kaXRpb25zLiBUaGF0IHNlZW1z IHRvIG1lDQo+IGFuIGltcG9ydGFudCBkaWZmZXJlbnRpYXRvciBmcm9tIG1pbGUuIFdlIHNob3Vs ZCBtYWtlIGl0IGV4cGxpY2l0IGhlcmUuDQo+ID4NCj4gPj4gVGhlIGVsZW1lbnRzIG1heSBiZSBk ZXNjcmliZWQgYXM6DQo+ID4+ICogT24tcHJlbWlzZSBERG9TIG1pdGlnYXRpb24gcGxhdGZvcm1z DQo+ID4+ICogU2VydmljZSBwcm92aWRlciBERG9TIG1pdGlnYXRpb24gcGxhdGZvcm1zDQo+ID4+ ICogT3RoZXIgbmV0d29yayBkZXZpY2VzL3BsYXRmb3JtcyB0aGF0IGFyZSBhYmxlIHRvIHNlbnNl IEREb1MgYW5kDQo+ID4+IHJlc3BvbmQNCj4gPg0KPiA+IFNvbWV0aGluZyBhbG9uZyB0aGUgbGlu ZXMgb2Yg4oCcT3RoZXIgZGV2aWNlcyB3aXRoIG5ldHdvcmsgcGVyc3BlY3RpdmUNCj4gcGVyZm9y bWluZyB0cmFmZmljIGFuYWx5c2lz4oCdICBvciDigJzigKZlbmdhZ2VkIGluIHRyYWZmaWMgYW5h bHlzaXPigJ0gc2hvdWxkDQo+IGVuY29tcGFzcyB0aGluZ3MgbGlrZSBmbG93IG1vbml0b3Jpbmcg YW5kIElEUy9JUFMuDQo+ID4NCj4gPj4gKiBDaGFpbmVkIGluc3RhbmNlcyBvZiB0aGUgYWJvdmUN Cj4gPj4NCj4gPj4gVGhlc2UgZWxlbWVudHMgbWF5IGJlIGNvbW11bmljYXRpbmcgaW50ZXItZG9t YWluIG9yIGludHJhLWRvbWFpbiBvdmVyDQo+ID4+IGxpbmtzIHRoYXQgbWF5IGJlIGNvbmdlc3Rl ZCBieSBhdHRhY2sgdHJhZmZpYyByZXN1bHRpbmcgaW4gaG9zdGlsZQ0KPiA+PiBjb25kaXRpb25z IGZvciB0cmFkaXRpb25hbCBjb25uZWN0aW9uIG9yaWVudGVkIGFwcHJvYWNoZXMgYW5kIG1vcmUN Cj4gPj4gZ2VuZXJhbGl6ZWQgc2lnbmFsaW5nIGFuZCB0ZWxlbWV0cnkgc29sdXRpb25zLg0KPiA+ DQo+ID4gU3RyaWtlIOKAnHRyYWRpdGlvbmFs4oCdLiBSZWdhcmRsZXNzIG9mIGlubm92YXRpb24s IGEgY29ubmVjdGlvbi1vcmllbnRlZA0KPiBwcm90b2NvbCBpcyBub3QgYXBwcm9wcmlhdGUgZm9y IGRvdHMgZm9yIHRoZSByZWFzb25zIHlvdeKAmXZlIGp1c3Qgc3RhdGVkLiBJIHRoaW5rDQo+IHRo aXMgY2FuIGJlIHRpZ2h0ZW5lZCB0bywgZS5nLiwg4oCc4oCmaG9zdGlsZSBjb25kaXRpb25zIGZv ciBjb25uZWN0aW9uLW9yaWVudGVkDQo+IHNpZ25hbGluZyBhbmQgdGVsZW1ldHJ5IHByb3RvY29s cy7igJ0NCj4gPg0KPiA+PiBSb2J1c3RuZXNzIHVuZGVyIHRoZXNlDQo+ID4+IGNvbmRpdGlvbnMg aXMgcGFyYW1vdW50IHdoaWxlIGVuc3VyaW5nIGFwcHJvcHJpYXRlIHJlZ2FyZCBmb3INCj4gPj4g YXV0aGVudGljYXRpb24sIGF1dGhvcml6YXRpb24sIHByaXZhY3kgYW5kIGRhdGEgaW50ZWdyaXR5 LiAgRWxlbWVudHMNCj4gPj4gbWF5IGJlIGRlcGxveWVkIGFzIHBhcnQgb2YgYSB3aWRlciBzdHJh dGVneSBpbmNvcnBvcmF0aW5nIG11bHRpcGxlDQo+ID4+IHBvaW50cyBvZiBkZXRlY3Rpb24gYW5k IG1pdGlnYXRpb24sIGJvdGggb24gcHJlbWlzZSBvciBzZXJ2aWNlIHByb3ZpZGVyDQo+IGJhc2Vk Lg0KPiA+PiBTaG91bGQgbWl0aWdhdGlvbiBuZWVkIHRvIG1vdmUgYmV0d2VlbiBlbGVtZW50cyBp biB0aGUgY2hhaW4gdGhlbg0KPiA+PiBlZmZlY3RpdmUgc2lnbmFsaW5nIG9mIHRlbGVtZXRyeSBh bmQgY3VycmVudCB0aHJlYXQgaGFuZGxpbmcgaXMgZXNzZW50aWFsLg0KPiA+DQo+ID4gSXMgdGhl IGltcGxpY2F0aW9uIHRoYXQgYW4gb24tcHJlbWlzZSBkZXZpY2UgbWF5IHNpZ25hbCBsYXRlcmFs bHkNCj4gaW50ZW50aW9uYWw/IE9yIGlzIHRoZSBleHBlY3RhdGlvbiB0aGF0IGVhY2ggc3Vic2Vx dWVudCBlbGVtZW50IGluIHRoZSBjaGFpbg0KPiB3aWxsIGJlIHVwc3RyZWFtIGZyb20gdGhlIHBy ZXZpb3VzPw0KPiA+DQo+ID4+IEZlZWRiYWNrIGJldHdlZW4gcGFydGljaXBhdGluZyBlbGVtZW50 cyBpcyByZXF1aXJlZCBmb3IgaW5jcmVhc2VkDQo+ID4+IGF3YXJlbmVzcyBmb3IgZWZmZWN0aXZl IGRlY2lzaW9uIG1ha2luZy4NCj4gPj4NCj4gPj4gVGhlIFdHIHdpbGwsIHdoZXJlIGFwcHJvcHJp YXRlLCByZXVzZSBleGlzdGluZyBzdGFuZGFyZCBwcm90b2NvbHMgYW5kDQo+ID4+IG1lY2hhbmlz bXMsIGZvciBpbnN0YW5jZSBJUEZJWCBhbmQgaXRzIHRlbXBsYXRpbmcgbWVjaGFuaXNtLg0KPiA+ PiBUaGUgY2hhcnRlciBvZiB0aGUgd29ya2luZyBncm91cCBpcyB0byBwcm9kdWNlIG9uZSBvciBt b3JlIHN0YW5kYXJkcw0KPiA+PiB0cmFjayBzcGVjaWZpY2F0aW9uIHRvIHByb3ZpZGUgZm9yIHRo aXMgb3BlbiBzaWduYWxpbmcgaW4gdGhlIEREb1MNCj4gPj4gcHJvYmxlbSBzcGFjZS4gIFdoaWxl IHRoZSByZXN1bHRpbmcgc3RhbmRhcmRzIHNob3VsZCBiZSBkZXNpZ25lZCBzbw0KPiA+PiB0aGF0 IHRoZXJlwrlzIGEgcG9zc2liaWxpdHkgb2YgYXBwbHlpbmcgdGhlbSB0byBuZXR3b3JrIHNlY3Vy aXR5DQo+ID4+IGFwcGxpY2F0aW9ucyBiZXlvbmQgRERvUw0KPiA+DQo+ID4g4oCc4oCmZGVzaWdu ZWQgc28gdGhleSBtYXkgYXBwbHkgdG8gbmV0d29yayBzZWN1cml0eSBhcHBsaWNhdGlvbnPigKYi DQo+ID4NCj4gPj4gbWl0aWdhdGlvbiwgdGhpcyB3b3JraW5nIGdyb3VwIHdpbGwgZm9jdXMgb24g anVzdCBERG9TIG1pdGlnYXRpb24uDQo+ID4NCj4gPiBTdHJpa2Ug4oCcanVzdOKAnS4NCj4gPg0K PiA+PiBUaGlzIHN0cmVhbWxpbmVkIGZvY3VzIG9mIHRoZSBjaGFydGVyIGlzIGludGVuZGVkIHRv IGxlYWQgdG8gYW4NCj4gPj4gZWFybGllciByZXN1bHQgZHVlIHRvIGNvbW11bml0eSBpbnRlcmVz dHMgaW4gaGF2aW5nIHN1Y2ggY2FwYWJpbGl0eSBpbiBhDQo+IHNob3J0IHRpbWVmcmFtZS4NCj4g Pj4gVGhlIHNwZWNpZmljYXRpb24ocykgcHJvZHVjZWQgYnkgdGhlIFdHIHdpbGwgaW5jbHVkZSBh IHN0YW5kYXJkDQo+ID4+IG1lY2hhbmlzbSBmb3IgYXV0aGVudGljYXRpb24gYW5kIGF1dGhvcml6 YXRpb24sIGZvciBkYXRhIGludGVncml0eSwNCj4gPj4gYW5kIGZvciBwcm92aWRpbmcgZm9yIHBy aXZhY3kgaW4gb3BlcmF0aW9uLg0KPiA+Pg0KPiA+PiBUaGUgV0cgd2lsbCBwcm9kdWNlIHRoZSBm b2xsb3dpbmcgZGVsaXZlcmFibGVzOg0KPiA+Pg0KPiA+PiAqIFVzZSBjYXNlIGRvY3VtZW50IHRv IGVuc3VyZSBjb21tb25hbGl0eSBvZiB0aGUgd29yayBhbW9uZyB0aGUNCj4gPj4gcGFydGljaXBh bnRzIGluIHRoZSBXb3JraW5nIEdyb3VwLiAgVGhpcyBkb2N1bWVudCBtYXkgYmUgZGV0ZXJtaW5l ZA0KPiA+PiBieSB0aGUgd29ya2luZyBncm91cCB0byByZW1haW4gaW5mb3JtYWwgYW5kIG5vdCBi ZSBwdWJsaXNoZWQuDQo+ID4+ICogRG9jdW1lbnQgb3IgRG9jdW1lbnRzIGRlc2NyaWJpbmcgdGhl IHByb2JsZW0gc3BhY2UsIHVzZSBjYXNlcywNCj4gPj4gcHJvdG9jb2wgcmVxdWlyZW1lbnRzIGFu ZCBvdGhlciBxdWFsaWZ5aW5nIGluZm9ybWF0aW9uIGFzIHRoZSBXRyBzZWVzIGZpdC4NCj4gPj4g KiBEb2N1bWVudCBvciBEb2N1bWVudHMgc3BlY2lmeWluZyBhIHByb3RvY29sIGFuZCBhc3NvY2lh dGVkIGRhdGENCj4gPj4gbW9kZWxzIHRvIGFkZHJlc3MgdGhlIFdHIHN0YXRlZCBnb2FsLg0KPiA+ DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g PiBEb3RzIG1haWxpbmcgbGlzdA0KPiA+IERvdHNAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RvdHMNCj4gDQo+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IERvdHMgbWFpbGluZyBsaXN0DQo+IERvdHNA aWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kb3RzDQo+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IERvdHMg bWFpbGluZyBsaXN0DQo+IERvdHNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9kb3RzDQo= From nobody Tue May 12 00:55:57 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71A471A1BD2 for ; Tue, 12 May 2015 00:55:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 xyBNt-C4AaNo for ; Tue, 12 May 2015 00:55:53 -0700 (PDT) Received: from gateway31.websitewelcome.com (gateway31.websitewelcome.com [192.185.144.80]) (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 180FB1A1B60 for ; Tue, 12 May 2015 00:55:53 -0700 (PDT) Received: by gateway31.websitewelcome.com (Postfix, from userid 500) id 78B8A3CD482B; Tue, 12 May 2015 02:55:52 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway31.websitewelcome.com (Postfix) with ESMTP id 696253CD480B for ; Tue, 12 May 2015 02:55:52 -0500 (CDT) Received: from [204.42.252.17] (port=53101 helo=[5.5.33.172]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Ys52d-0001BZ-GB; Tue, 12 May 2015 02:55:51 -0500 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Turner In-Reply-To: <913383AAA69FF945B8F946018B75898A478424BA@xmb-rcd-x10.cisco.com> Date: Tue, 12 May 2015 09:55:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8E91F3C2-CC7B-4203-A6D9-1BFDF9951F89@ieca.com> References: <6DEAC84F-75B4-41D6-A429-3C2328BEAEBA@arbor.net> <2DD56D786E600F45AC6BDE7DA4E8A8C160250C@eusaamb107.ericsson.se> <913383AAA69FF945B8F946018B75898A478424BA@xmb-rcd-x10.cisco.com> To: Kathleen Moriarty X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 204.42.252.17 X-Exim-ID: 1Ys52d-0001BZ-GB X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([5.5.33.172]) [204.42.252.17]:53101 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: Cc: "dots@ietf.org" Subject: Re: [Dots] Draft Charter X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 07:55:55 -0000 +1 with the tweaks suggested by Adam & Andrew. spt On May 12, 2015, at 04:06, Tirumaleswar Reddy (tireddy) = wrote: > +1. >=20 > -Tiru >=20 >> -----Original Message----- >> From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Daniel Migault >> Sent: Monday, May 11, 2015 10:15 PM >> To: Kathleen Moriarty; Andrew Mortensen >> Cc: Teague, Nik; dots@ietf.org >> Subject: Re: [Dots] Draft Charter >>=20 >> I support the charter. >>=20 >>=20 >> -----Original Message----- >> From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Kathleen = Moriarty >> Sent: Saturday, May 09, 2015 1:28 PM >> To: Andrew Mortensen >> Cc: Teague, Nik; dots@ietf.org >> Subject: Re: [Dots] Draft Charter >>=20 >> Are there any other comments on the proposed charter? If you've read = it and >> do not have changes, expressions of support for the current version = would be >> helpful to understand how many folks agree this is important and want = to >> work on this in the IETF. >>=20 >> Thank you, >> Kathleen >>=20 >> Sent from my iPhone >>=20 >>> On May 2, 2015, at 1:28 AM, Andrew Mortensen >> wrote: >>>=20 >>> Hi Nik. Thanks for giving us a good foundation to build upon. >>>=20 >>> Comments/nitpicks inline, trying not to overlap too much with Adam. >>>=20 >>> andrew >>>=20 >>> -- >>>=20 >>>> The aim of DDoS Open Threat Signaling (DOTS) is to develop a >>>> standards based approach to the real time signaling of DDoS related >>>> telemetry and threat handling data between elements concerned with >> attack mitigation. >>>=20 >>> I think the =93real time=94 phrase here is intended to emphasize = that the >> signaling is expected to be done under attack conditions. That seems = to me >> an important differentiator from mile. We should make it explicit = here. >>>=20 >>>> The elements may be described as: >>>> * On-premise DDoS mitigation platforms >>>> * Service provider DDoS mitigation platforms >>>> * Other network devices/platforms that are able to sense DDoS and >>>> respond >>>=20 >>> Something along the lines of =93Other devices with network = perspective >> performing traffic analysis=94 or =93=85engaged in traffic analysis=94= should >> encompass things like flow monitoring and IDS/IPS. >>>=20 >>>> * Chained instances of the above >>>>=20 >>>> These elements may be communicating inter-domain or intra-domain = over >>>> links that may be congested by attack traffic resulting in hostile >>>> conditions for traditional connection oriented approaches and more >>>> generalized signaling and telemetry solutions. >>>=20 >>> Strike =93traditional=94. Regardless of innovation, a = connection-oriented >> protocol is not appropriate for dots for the reasons you=92ve just = stated. I think >> this can be tightened to, e.g., =93=85hostile conditions for = connection-oriented >> signaling and telemetry protocols.=94 >>>=20 >>>> Robustness under these >>>> conditions is paramount while ensuring appropriate regard for >>>> authentication, authorization, privacy and data integrity. = Elements >>>> may be deployed as part of a wider strategy incorporating multiple >>>> points of detection and mitigation, both on premise or service = provider >> based. >>>> Should mitigation need to move between elements in the chain then >>>> effective signaling of telemetry and current threat handling is = essential. >>>=20 >>> Is the implication that an on-premise device may signal laterally >> intentional? Or is the expectation that each subsequent element in = the chain >> will be upstream from the previous? >>>=20 >>>> Feedback between participating elements is required for increased >>>> awareness for effective decision making. >>>>=20 >>>> The WG will, where appropriate, reuse existing standard protocols = and >>>> mechanisms, for instance IPFIX and its templating mechanism. >>>> The charter of the working group is to produce one or more = standards >>>> track specification to provide for this open signaling in the DDoS >>>> problem space. While the resulting standards should be designed so >>>> that there=B9s a possibility of applying them to network security >>>> applications beyond DDoS >>>=20 >>> =93=85designed so they may apply to network security applications=85" >>>=20 >>>> mitigation, this working group will focus on just DDoS mitigation. >>>=20 >>> Strike =93just=94. >>>=20 >>>> This streamlined focus of the charter is intended to lead to an >>>> earlier result due to community interests in having such capability = in a >> short timeframe. >>>> The specification(s) produced by the WG will include a standard >>>> mechanism for authentication and authorization, for data integrity, >>>> and for providing for privacy in operation. >>>>=20 >>>> The WG will produce the following deliverables: >>>>=20 >>>> * Use case document to ensure commonality of the work among the >>>> participants in the Working Group. This document may be determined >>>> by the working group to remain informal and not be published. >>>> * Document or Documents describing the problem space, use cases, >>>> protocol requirements and other qualifying information as the WG = sees fit. >>>> * Document or Documents specifying a protocol and associated data >>>> models to address the WG stated goal. >>>=20 >>> _______________________________________________ >>> Dots mailing list >>> Dots@ietf.org >>> https://www.ietf.org/mailman/listinfo/dots >>=20 >> _______________________________________________ >> Dots mailing list >> Dots@ietf.org >> https://www.ietf.org/mailman/listinfo/dots >> _______________________________________________ >> Dots mailing list >> Dots@ietf.org >> https://www.ietf.org/mailman/listinfo/dots > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Tue May 12 01:44:13 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8753D1A700A for ; Tue, 12 May 2015 01:44:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_54=0.6, 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 2RbiZkTMyGMD for ; Tue, 12 May 2015 01:44:09 -0700 (PDT) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::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 72DC01A6FBC for ; Tue, 12 May 2015 01:44:09 -0700 (PDT) Received: by ieczm2 with SMTP id zm2so2746077iec.2 for ; Tue, 12 May 2015 01:44:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arbor.net; s=m0; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YnbJFCWjf8xgZS/WBUg3EGhYleWJI3kqzpeL793P5kA=; b=k4LskXDOwr4japXJ4Yf+iUaLp5LT0K5gPhHvGRAe0rwj3P7SXZH5H31iu76WGNuXDt RKCDlA+vwdvbTZ2+/eKBxFpXZTTm+dvRS+wSaFwX9Qz63OyZrzF1xa4hxMoxkEMxorTm iOpc2vAxgUFPkrNbymTRdfEIWLnAM/4810x30= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=YnbJFCWjf8xgZS/WBUg3EGhYleWJI3kqzpeL793P5kA=; b=EKA51R9pfpy3Z2cxp/k5CpTqlzbVKo8GqWh4hnE+U+KuY+pPHZW/bofC7IagRzcspI i+2jCUr9KVyTiwWqrfxsmtxI9C/hi2z7BxwkendvwSe9O92K0gJyPUf0GIc9x5Zjga3m 8zkkbPHJpYICRp3fAy8Na0+rLlZzgpfu1S3DLJNUUb3nTD3X9kHkHl+r57WGCPMMWtGH YbdlvE0AukNzZ5Wr8hvB3f7mX8/XorhlruNNMr8VEPakl2hheQgAYLvGM6SV0Uft2+lM 60PAaM3sZdgYDOu87xCYAs/w3xOmmOaWUAib8vdychHPDXOTi6JhBSMrU3V1tQiG/ai8 VacQ== X-Gm-Message-State: ALoCoQkMHWKfZoCaEJzojZdLQUDzTZJcw/J8VwTIbStikmZj/zoTryQeYRsZ6njJoBNUzttrC/OG X-Received: by 10.50.117.35 with SMTP id kb3mr2252520igb.13.1431420248737; Tue, 12 May 2015 01:44:08 -0700 (PDT) Received: from [10.0.1.6] (c-68-40-187-116.hsd1.mi.comcast.net. [68.40.187.116]) by mx.google.com with ESMTPSA id kl1sm843803igb.15.2015.05.12.01.44.07 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 May 2015 01:44:08 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Andrew Mortensen In-Reply-To: Date: Tue, 12 May 2015 04:44:06 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <05C3CFD6-E60D-4F97-AFFA-814CB1D7473D@arbor.net> References: <6DEAC84F-75B4-41D6-A429-3C2328BEAEBA@arbor.net> To: Kathleen Moriarty X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "Teague, Nik" , "dots@ietf.org" Subject: Re: [Dots] Draft Charter X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 08:44:11 -0000 > On May 9, 2015, at 1:28 PM, Kathleen Moriarty = wrote: >=20 > Are there any other comments on the proposed charter? If you've read = it and do not have changes, expressions of support for the current = version would be helpful to understand how many folks agree this is = important and want to work on this in the IETF. I support and will contribute to dots. It fills a narrow but significant = gap in attack response coordination, at a time when confronting attacks = of increasing frequency and scale demands effective cross-organizational = collaboration.=20 As I=E2=80=99ve indicated with my suggested changes, I believe the = current charter draft requires some minor revisions, but in general = effectively and succinctly communicates the scope and aims of the work = ahead. One issue I do want to see addressed is visible the following extracts: =E2=80=9C...elements may be communicating inter-domain or intra-domain = over links that may be congested by attack traffic resulting in = **hostile conditions for traditional connection oriented approaches** = and more generalized signaling and telemetry solutions. Robustness under these = conditions is paramount while ensuring **appropriate regard for = authentication, authorization, privacy and data integrity.**=E2=80=9D = (Emphasis added) "The WG will, where appropriate, reuse existing standard protocols and = mechanisms, for instance IPFIX and its templating mechanism.=E2=80=9D =E2=80=9CAppropriate regard for authentication, authorization, privacy = and data integrity=E2=80=9D while expecting to use IPFIX in =E2=80=9Chosti= le conditions for traditional connection oriented approaches=E2=80=9D = seems to dictate the use of IPFIX+DTLS, but Brian Trammel warned against = using it during the BoF (=E2=80=9CPlease think very hard about whether = this is going to work under attack=E2=80=9D, = ). Kathleen, you alluded to the same issue on the i2nsf list = (http://www.ietf.org/mail-archive/web/i2nsf/current/msg00327.html): "DOTS will have to stick to very specific requirements to be effective = with a transport during a DDoS attack. IPFIX was consistent across = proposals, but the choice of UDP may change once Brian Trammel's = analysis is shared.=E2=80=9D Is there analysis to be shared? It seems to me the needs laid out in the = charter=E2=80=94signaling over extremely congested pipes while ensuring = message integrity and security=E2=80=94require a common understanding of = IPFIX+DTLS's ability to meet them. andrew >=20 >> On May 2, 2015, at 1:28 AM, Andrew Mortensen = wrote: >>=20 >> Hi Nik. Thanks for giving us a good foundation to build upon. >>=20 >> Comments/nitpicks inline, trying not to overlap too much with Adam. >>=20 >> andrew >>=20 >> -- >>=20 >>> The aim of DDoS Open Threat Signaling (DOTS) is to develop a = standards >>> based approach to the real time signaling of DDoS related telemetry = and >>> threat handling data between elements concerned with attack = mitigation. >>=20 >> I think the =E2=80=9Creal time=E2=80=9D phrase here is intended to = emphasize that the signaling is expected to be done under attack = conditions. That seems to me an important differentiator from mile. We = should make it explicit here. >>=20 >>> The elements may be described as: >>> * On-premise DDoS mitigation platforms >>> * Service provider DDoS mitigation platforms >>> * Other network devices/platforms that are able to sense DDoS and = respond >>=20 >> Something along the lines of =E2=80=9COther devices with network = perspective performing traffic analysis=E2=80=9D or =E2=80=9C=E2=80=A6eng= aged in traffic analysis=E2=80=9D should encompass things like flow = monitoring and IDS/IPS. >>=20 >>> * Chained instances of the above >>>=20 >>> These elements may be communicating inter-domain or intra-domain = over >>> links that may be congested by attack traffic resulting in hostile >>> conditions for traditional connection oriented approaches and more >>> generalized signaling and telemetry solutions. >>=20 >> Strike =E2=80=9Ctraditional=E2=80=9D. Regardless of innovation, a = connection-oriented protocol is not appropriate for dots for the reasons = you=E2=80=99ve just stated. I think this can be tightened to, e.g., = =E2=80=9C=E2=80=A6hostile conditions for connection-oriented signaling = and telemetry protocols.=E2=80=9D >>=20 >>> Robustness under these >>> conditions is paramount while ensuring appropriate regard for >>> authentication, authorization, privacy and data integrity. Elements = may >>> be deployed as part of a wider strategy incorporating multiple = points of >>> detection and mitigation, both on premise or service provider based. >>> Should mitigation need to move between elements in the chain then >>> effective signaling of telemetry and current threat handling is = essential. >>=20 >> Is the implication that an on-premise device may signal laterally = intentional? Or is the expectation that each subsequent element in the = chain will be upstream from the previous? >>=20 >>> Feedback between participating elements is required for increased >>> awareness for effective decision making. >>>=20 >>> The WG will, where appropriate, reuse existing standard protocols = and >>> mechanisms, for instance IPFIX and its templating mechanism. >>> The charter of the working group is to produce one or more standards = track >>> specification to provide for this open signaling in the DDoS problem >>> space. While the resulting standards should be designed so that = there=C2=B9s a >>> possibility of applying them to network security applications beyond = DDoS >>=20 >> =E2=80=9C=E2=80=A6designed so they may apply to network security = applications=E2=80=A6" >>=20 >>> mitigation, this working group will focus on just DDoS mitigation. >>=20 >> Strike =E2=80=9Cjust=E2=80=9D. >>=20 >>> This streamlined focus of the charter is intended to lead to an = earlier result >>> due to community interests in having such capability in a short = timeframe. >>> The specification(s) produced by the WG will include a standard = mechanism >>> for authentication and authorization, for data integrity, and for >>> providing for privacy in operation. >>>=20 >>> The WG will produce the following deliverables: >>>=20 >>> * Use case document to ensure commonality of the work among the >>> participants in the Working Group. This document may be determined = by the >>> working group to remain informal and not be published. >>> * Document or Documents describing the problem space, use cases, = protocol >>> requirements and other qualifying information as the WG sees fit. >>> * Document or Documents specifying a protocol and associated data = models >>> to address the WG stated goal. >>=20 >> _______________________________________________ >> Dots mailing list >> Dots@ietf.org >> https://www.ietf.org/mailman/listinfo/dots From nobody Tue May 12 04:07:31 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@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: [Dots] =?gb2312?b?tPC4tDogW0kybnNmXSBGdXJ0aGVyIE5hcnJvd2luZyB0?= =?gb2312?b?aGUgSTJOU0Ygc2NvcGU6IHRoZSBuZXcgY2hhcnRlciBmb3IgSUVURgk5Mw==?= X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." 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 12:29:17 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B56A1A87BB for ; Tue, 12 May 2015 12:29:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.664 X-Spam-Level: X-Spam-Status: No, score=-96.664 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_HELO_EQ_D_D_D_D=1.597, HELO_DYNAMIC_IPADDR=1.951, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 9jh-4fjffRtV for ; Tue, 12 May 2015 12:29:12 -0700 (PDT) Received: from lvps5-35-241-16.dedicated.hosteurope.de (www.gondrom.org [5.35.241.16]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B5421A1ADF for ; Tue, 12 May 2015 12:29:12 -0700 (PDT) Received: from [172.16.32.178] (unknown [92.45.27.162]) by lvps5-35-241-16.dedicated.hosteurope.de (Postfix) with ESMTPSA id 85A22637A9; Tue, 12 May 2015 21:29:07 +0200 (CEST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=bqsQL9U8dV6yLeNwVB4VCaqvndGLYXV1bpBso9SYl7PRRXJkXdM5J0R/OkZxqwQWDBy8LCEEClZrEHLhZYRKzMetBT086vaDwHiySp5kXOm0SKnGadEtXwb3PbiRszINl+m+G+kh+k59kEFp66oWDfdAPuUKrW8WsYa8dDsDBTU=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type; Message-ID: <55525481.1050200@gondrom.org> Date: Tue, 12 May 2015 21:29:05 +0200 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: kathleen.moriarty.ietf@gmail.com, amortensen@arbor.net References: <6DEAC84F-75B4-41D6-A429-3C2328BEAEBA@arbor.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080405080406040400030406" Archived-At: Cc: nteague@verisign.com, dots@ietf.org Subject: Re: [Dots] Draft Charter X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 19:29:15 -0000 This is a multi-part message in MIME format. --------------080405080406040400030406 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I agree that this is important work for the community and should be done. And overall, I do support the proposed charter with adjustments as suggested by several people here on the mailing-list. Best regards, Tobias On 09/05/15 19:28, Kathleen Moriarty wrote: > Are there any other comments on the proposed charter? If you've read it and do not have changes, expressions of support for the current version would be helpful to understand how many folks agree this is important and want to work on this in the IETF. > > Thank you, > Kathleen > > Sent from my iPhone > >> On May 2, 2015, at 1:28 AM, Andrew Mortensen wrote: >> >> Hi Nik. Thanks for giving us a good foundation to build upon. >> >> Comments/nitpicks inline, trying not to overlap too much with Adam. >> >> andrew >> >> -- >> >>> The aim of DDoS Open Threat Signaling (DOTS) is to develop a standards >>> based approach to the real time signaling of DDoS related telemetry and >>> threat handling data between elements concerned with attack mitigation. >> I think the “real time†phrase here is intended to emphasize that the signaling is expected to be done under attack conditions. That seems to me an important differentiator from mile. We should make it explicit here. >> >>> The elements may be described as: >>> * On-premise DDoS mitigation platforms >>> * Service provider DDoS mitigation platforms >>> * Other network devices/platforms that are able to sense DDoS and respond >> Something along the lines of “Other devices with network perspective performing traffic analysis†or “…engaged in traffic analysis†should encompass things like flow monitoring and IDS/IPS. >> >>> * Chained instances of the above >>> >>> These elements may be communicating inter-domain or intra-domain over >>> links that may be congested by attack traffic resulting in hostile >>> conditions for traditional connection oriented approaches and more >>> generalized signaling and telemetry solutions. >> Strike “traditionalâ€. Regardless of innovation, a connection-oriented protocol is not appropriate for dots for the reasons you’ve just stated. I think this can be tightened to, e.g., “…hostile conditions for connection-oriented signaling and telemetry protocols.†>> >>> Robustness under these >>> conditions is paramount while ensuring appropriate regard for >>> authentication, authorization, privacy and data integrity. Elements may >>> be deployed as part of a wider strategy incorporating multiple points of >>> detection and mitigation, both on premise or service provider based. >>> Should mitigation need to move between elements in the chain then >>> effective signaling of telemetry and current threat handling is essential. >> Is the implication that an on-premise device may signal laterally intentional? Or is the expectation that each subsequent element in the chain will be upstream from the previous? >> >>> Feedback between participating elements is required for increased >>> awareness for effective decision making. >>> >>> The WG will, where appropriate, reuse existing standard protocols and >>> mechanisms, for instance IPFIX and its templating mechanism. >>> The charter of the working group is to produce one or more standards track >>> specification to provide for this open signaling in the DDoS problem >>> space. While the resulting standards should be designed so that there¹s a >>> possibility of applying them to network security applications beyond DDoS >> “…designed so they may apply to network security applications…" >> >>> mitigation, this working group will focus on just DDoS mitigation. >> Strike “justâ€. >> >>> This streamlined focus of the charter is intended to lead to an earlier result >>> due to community interests in having such capability in a short timeframe. >>> The specification(s) produced by the WG will include a standard mechanism >>> for authentication and authorization, for data integrity, and for >>> providing for privacy in operation. >>> >>> The WG will produce the following deliverables: >>> >>> * Use case document to ensure commonality of the work among the >>> participants in the Working Group. This document may be determined by the >>> working group to remain informal and not be published. >>> * Document or Documents describing the problem space, use cases, protocol >>> requirements and other qualifying information as the WG sees fit. >>> * Document or Documents specifying a protocol and associated data models >>> to address the WG stated goal. >> _______________________________________________ >> Dots mailing list >> Dots@ietf.org >> https://www.ietf.org/mailman/listinfo/dots > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots --------------080405080406040400030406 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit I agree that this is important work for the community and should be done.
And overall, I do support the proposed charter with adjustments as suggested by several people here on the mailing-list.
Best regards, Tobias


On 09/05/15 19:28, Kathleen Moriarty wrote:
Are there any other comments on the proposed charter?  If you've read it and do not have changes, expressions of support for the current version would be helpful to understand how many folks agree this is important and want to work on this in the IETF.

Thank you,
Kathleen 

Sent from my iPhone


On May 2, 2015, at 1:28 AM, Andrew Mortensen <amortensen@arbor.net> wrote:

Hi Nik. Thanks for giving us a good foundation to build upon.

Comments/nitpicks inline, trying not to overlap too much with Adam.

andrew

--


The aim of DDoS Open Threat Signaling (DOTS) is to develop a standards
based approach to the real time signaling of DDoS related telemetry and
threat handling data between elements concerned with attack mitigation.

I think the “real time†phrase here is intended to emphasize that the signaling is expected to be done under attack conditions. That seems to me an important differentiator from mile. We should make it explicit here.


The elements may be described as:
* On-premise DDoS mitigation platforms
* Service provider DDoS mitigation platforms
* Other network devices/platforms that are able to sense DDoS and respond

Something along the lines of “Other devices with network perspective performing traffic analysis† or “…engaged in traffic analysis†should encompass things like flow monitoring and IDS/IPS.


* Chained instances of the above

These elements may be communicating inter-domain or intra-domain over
links that may be congested by attack traffic resulting in hostile
conditions for traditional connection oriented approaches and more
generalized signaling and telemetry solutions.

Strike “traditionalâ€. Regardless of innovation, a connection-oriented protocol is not appropriate for dots for the reasons you’ve just stated. I think this can be tightened to, e.g., “…hostile conditions for connection-oriented signaling and telemetry protocols.â€


Robustness under these
conditions is paramount while ensuring appropriate regard for
authentication, authorization, privacy and data integrity.  Elements may
be deployed as part of a wider strategy incorporating multiple points of
detection and mitigation, both on premise or service provider based.
Should mitigation need to move between elements in the chain then
effective signaling of telemetry and current threat handling is essential.

Is the implication that an on-premise device may signal laterally intentional? Or is the expectation that each subsequent element in the chain will be upstream from the previous?


Feedback between participating elements is required for increased
awareness for effective decision making.

The WG will, where appropriate, reuse existing standard protocols and
mechanisms, for instance IPFIX and its templating mechanism.
The charter of the working group is to produce one or more standards track
specification to provide for this open signaling in the DDoS problem
space.  While the resulting standards should be designed so that there¹s a
possibility of applying them to network security applications beyond DDoS

“…designed so they may apply to network security applications…"


mitigation, this working group will focus on just DDoS mitigation.

Strike “justâ€.


This streamlined focus of the charter is intended to lead to an earlier result
due to community interests in having such capability in a short timeframe.
The specification(s) produced by the WG will include a standard mechanism
for authentication and authorization, for data integrity, and for
providing for privacy in operation.

The WG will produce the following deliverables:

* Use case document to ensure commonality of the work among the
participants in the Working Group.  This document may be determined by the
working group to remain informal and not be published.
* Document or Documents describing the problem space, use cases, protocol
requirements and other qualifying information as the WG sees fit.
* Document or Documents specifying a protocol and associated data models
to address the WG stated goal.

_______________________________________________
Dots mailing list
Dots@ietf.org
https://www.ietf.org/mailman/listinfo/dots

_______________________________________________
Dots mailing list
Dots@ietf.org
https://www.ietf.org/mailman/listinfo/dots

--------------080405080406040400030406-- From nobody Tue May 12 14:38:56 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B90841AD1F5 for ; Tue, 12 May 2015 14:38:54 -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 W1-r75Hmu3Pm for ; Tue, 12 May 2015 14:38:51 -0700 (PDT) Received: from mail11.a10networks.com (mx3.a10networks.com [12.207.16.164]) by ietfa.amsl.com (Postfix) with ESMTP id 52B811AD151 for ; Tue, 12 May 2015 14:38:45 -0700 (PDT) X-AuditID: c0a80b0a-b7f8d8e00000775d-84-555272e4af6b Received: from webmail.a10networks.com ( [192.168.1.101]) by mail11.a10networks.com (Symantec Messaging Gateway) with SMTP id 0C.09.30557.4E272555; Tue, 12 May 2015 14:38:44 -0700 (PDT) Received: from SJ-MB01.corp.a10networks.com ([fe80::ac4c:cbf3:938f:9a1d]) by SJ-CASHT01.corp.a10networks.com ([fe80::fc7d:19ae:354e:4f0a%11]) with mapi id 14.03.0210.002; Tue, 12 May 2015 14:38:44 -0700 From: Rich Groves To: Tobias Gondrom , Kathleen Moriarty Thread-Topic: [Dots] Draft Charter Thread-Index: AQHQfE+l/Sly82ObQkmwTXHnIFPOXJ1ormYAgAvJXwCABNjFgIAAJYAA Date: Tue, 12 May 2015 21:38:44 +0000 Message-ID: <0586B864-F60B-4633-8A93-B724C5F9BDC3@a10networks.com> References: <6DEAC84F-75B4-41D6-A429-3C2328BEAEBA@arbor.net> <55525481.1050200@gondrom.org> In-Reply-To: <55525481.1050200@gondrom.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.122] Content-Type: multipart/alternative; boundary="_000_0586B864F60B46338A93B724C5F9BDC3a10networkscom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDIsWRmVeSWpSXmKPExsVyYAVjqu6ToqBQg3l9NhYL3r1jtVj75gir RcPOfIu2T0eZLG4tmM/owOqx5XIvu8fOWXfZPR7cmc/ksWTJTyaPXZsb2AJYo7hsUlJzMstS i/TtErgyXh/ayVRwpI2x4mDrAqYGxs9NjF2MnBwSAiYSH1fMZ4ewxSQu3FvPBmILCexmlLjf LdrFyAVkn2OUeH1vCVgRm4C2xKGnG5hBbBGBdIlJa3aCxZkFqiS2HX7JCmILCyhKLJg0gQmi Rkli+aY3rBC2m0Tbn7NgvSwCqhIrFz4Fs3kFnCQOL57GArFsO6PE8aYLYEM5gZZt29sOdikj 0HXfT61hglgmLnHryXwmiKsFJJbsOc8MYYtKvHz8jxXCVpRo2POeEaI+TWL+4b1MEMsEJU7O fMIygVF0FpJRs5CUzUJSNouRAyiuKbF+lz5EiaLElO6H7BC2hkTrnLlQtrPE7OmrmJHVLGDk WMUolpuYmWNoqJdoaJCXWlKeX5RdrJecn7uJERzH3Fw7GG+/sz3EKMDBqMTDO+FZYKgQa2JZ cWXuIUYJDmYlEd5VRkGhQrwpiZVVqUX58UWlOanFhxilOViUxHkVX8iGCgmkJ5akZqemFqQW wWSZODilGhhzu154PEi6q8lu/908YP4/0Unnt2tvq5avsP/G1yShcPnvoy96DXEJHF66XFLC 3GZssxZ2nA1dfJPbVCTw3aZHSzxEaoRum+kLzDvrk9a6N+CYX9Lqqztjd7VbHBP5/1r5+hbF 92+L8kzfzeJmO9XAptjC/jdjysa+Cd0nznyfp9XfeCqMLViJpTgj0VCLuag4EQDQBi253wIA AA== Archived-At: Cc: "amortensen@arbor.net" , "dots@ietf.org" , "Teague, Nik" Subject: Re: [Dots] Draft Charter X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 21:38:54 -0000 --_000_0586B864F60B46338A93B724C5F9BDC3a10networkscom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzEgIEkgc3VwcG9ydCB0aGUgY2hhcnRlci4gQWdyZWVkIHRoYXQgaXQgaXMgaW1wb3J0YW50IGFu ZCB3ZSBjb21taXQgdG8gd29yayBhY3RpdmVseSBvbiBpdC4NCk9uIE1heSAxMiwgMjAxNSwgYXQg MTI6MjkgUE0sIFRvYmlhcyBHb25kcm9tIDx0b2JpYXMuZ29uZHJvbUBnb25kcm9tLm9yZzxtYWls dG86dG9iaWFzLmdvbmRyb21AZ29uZHJvbS5vcmc+PiB3cm90ZToNCg0KSSBhZ3JlZSB0aGF0IHRo aXMgaXMgaW1wb3J0YW50IHdvcmsgZm9yIHRoZSBjb21tdW5pdHkgYW5kIHNob3VsZCBiZSBkb25l Lg0KQW5kIG92ZXJhbGwsIEkgZG8gc3VwcG9ydCB0aGUgcHJvcG9zZWQgY2hhcnRlciB3aXRoIGFk anVzdG1lbnRzIGFzIHN1Z2dlc3RlZCBieSBzZXZlcmFsIHBlb3BsZSBoZXJlIG9uIHRoZSBtYWls aW5nLWxpc3QuDQpCZXN0IHJlZ2FyZHMsIFRvYmlhcw0KDQoNCk9uIDA5LzA1LzE1IDE5OjI4LCBL YXRobGVlbiBNb3JpYXJ0eSB3cm90ZToNCg0KQXJlIHRoZXJlIGFueSBvdGhlciBjb21tZW50cyBv biB0aGUgcHJvcG9zZWQgY2hhcnRlcj8gIElmIHlvdSd2ZSByZWFkIGl0IGFuZCBkbyBub3QgaGF2 ZSBjaGFuZ2VzLCBleHByZXNzaW9ucyBvZiBzdXBwb3J0IGZvciB0aGUgY3VycmVudCB2ZXJzaW9u IHdvdWxkIGJlIGhlbHBmdWwgdG8gdW5kZXJzdGFuZCBob3cgbWFueSBmb2xrcyBhZ3JlZSB0aGlz IGlzIGltcG9ydGFudCBhbmQgd2FudCB0byB3b3JrIG9uIHRoaXMgaW4gdGhlIElFVEYuDQoNClRo YW5rIHlvdSwNCkthdGhsZWVuDQoNClNlbnQgZnJvbSBteSBpUGhvbmUNCg0KDQoNCk9uIE1heSAy LCAyMDE1LCBhdCAxOjI4IEFNLCBBbmRyZXcgTW9ydGVuc2VuIDxhbW9ydGVuc2VuQGFyYm9yLm5l dD48bWFpbHRvOmFtb3J0ZW5zZW5AYXJib3IubmV0PiB3cm90ZToNCg0KSGkgTmlrLiBUaGFua3Mg Zm9yIGdpdmluZyB1cyBhIGdvb2QgZm91bmRhdGlvbiB0byBidWlsZCB1cG9uLg0KDQpDb21tZW50 cy9uaXRwaWNrcyBpbmxpbmUsIHRyeWluZyBub3QgdG8gb3ZlcmxhcCB0b28gbXVjaCB3aXRoIEFk YW0uDQoNCmFuZHJldw0KDQotLQ0KDQoNCg0KVGhlIGFpbSBvZiBERG9TIE9wZW4gVGhyZWF0IFNp Z25hbGluZyAoRE9UUykgaXMgdG8gZGV2ZWxvcCBhIHN0YW5kYXJkcw0KYmFzZWQgYXBwcm9hY2gg dG8gdGhlIHJlYWwgdGltZSBzaWduYWxpbmcgb2YgRERvUyByZWxhdGVkIHRlbGVtZXRyeSBhbmQN CnRocmVhdCBoYW5kbGluZyBkYXRhIGJldHdlZW4gZWxlbWVudHMgY29uY2VybmVkIHdpdGggYXR0 YWNrIG1pdGlnYXRpb24uDQoNCg0KSSB0aGluayB0aGUg4oCccmVhbCB0aW1l4oCdIHBocmFzZSBo ZXJlIGlzIGludGVuZGVkIHRvIGVtcGhhc2l6ZSB0aGF0IHRoZSBzaWduYWxpbmcgaXMgZXhwZWN0 ZWQgdG8gYmUgZG9uZSB1bmRlciBhdHRhY2sgY29uZGl0aW9ucy4gVGhhdCBzZWVtcyB0byBtZSBh biBpbXBvcnRhbnQgZGlmZmVyZW50aWF0b3IgZnJvbSBtaWxlLiBXZSBzaG91bGQgbWFrZSBpdCBl eHBsaWNpdCBoZXJlLg0KDQoNCg0KVGhlIGVsZW1lbnRzIG1heSBiZSBkZXNjcmliZWQgYXM6DQoq IE9uLXByZW1pc2UgRERvUyBtaXRpZ2F0aW9uIHBsYXRmb3Jtcw0KKiBTZXJ2aWNlIHByb3ZpZGVy IEREb1MgbWl0aWdhdGlvbiBwbGF0Zm9ybXMNCiogT3RoZXIgbmV0d29yayBkZXZpY2VzL3BsYXRm b3JtcyB0aGF0IGFyZSBhYmxlIHRvIHNlbnNlIEREb1MgYW5kIHJlc3BvbmQNCg0KDQpTb21ldGhp bmcgYWxvbmcgdGhlIGxpbmVzIG9mIOKAnE90aGVyIGRldmljZXMgd2l0aCBuZXR3b3JrIHBlcnNw ZWN0aXZlIHBlcmZvcm1pbmcgdHJhZmZpYyBhbmFseXNpc+KAnSAgb3Ig4oCc4oCmZW5nYWdlZCBp biB0cmFmZmljIGFuYWx5c2lz4oCdIHNob3VsZCBlbmNvbXBhc3MgdGhpbmdzIGxpa2UgZmxvdyBt b25pdG9yaW5nIGFuZCBJRFMvSVBTLg0KDQoNCg0KKiBDaGFpbmVkIGluc3RhbmNlcyBvZiB0aGUg YWJvdmUNCg0KVGhlc2UgZWxlbWVudHMgbWF5IGJlIGNvbW11bmljYXRpbmcgaW50ZXItZG9tYWlu IG9yIGludHJhLWRvbWFpbiBvdmVyDQpsaW5rcyB0aGF0IG1heSBiZSBjb25nZXN0ZWQgYnkgYXR0 YWNrIHRyYWZmaWMgcmVzdWx0aW5nIGluIGhvc3RpbGUNCmNvbmRpdGlvbnMgZm9yIHRyYWRpdGlv bmFsIGNvbm5lY3Rpb24gb3JpZW50ZWQgYXBwcm9hY2hlcyBhbmQgbW9yZQ0KZ2VuZXJhbGl6ZWQg c2lnbmFsaW5nIGFuZCB0ZWxlbWV0cnkgc29sdXRpb25zLg0KDQoNClN0cmlrZSDigJx0cmFkaXRp b25hbOKAnS4gUmVnYXJkbGVzcyBvZiBpbm5vdmF0aW9uLCBhIGNvbm5lY3Rpb24tb3JpZW50ZWQg cHJvdG9jb2wgaXMgbm90IGFwcHJvcHJpYXRlIGZvciBkb3RzIGZvciB0aGUgcmVhc29ucyB5b3Xi gJl2ZSBqdXN0IHN0YXRlZC4gSSB0aGluayB0aGlzIGNhbiBiZSB0aWdodGVuZWQgdG8sIGUuZy4s IOKAnOKApmhvc3RpbGUgY29uZGl0aW9ucyBmb3IgY29ubmVjdGlvbi1vcmllbnRlZCBzaWduYWxp bmcgYW5kIHRlbGVtZXRyeSBwcm90b2NvbHMu4oCdDQoNCg0KDQpSb2J1c3RuZXNzIHVuZGVyIHRo ZXNlDQpjb25kaXRpb25zIGlzIHBhcmFtb3VudCB3aGlsZSBlbnN1cmluZyBhcHByb3ByaWF0ZSBy ZWdhcmQgZm9yDQphdXRoZW50aWNhdGlvbiwgYXV0aG9yaXphdGlvbiwgcHJpdmFjeSBhbmQgZGF0 YSBpbnRlZ3JpdHkuICBFbGVtZW50cyBtYXkNCmJlIGRlcGxveWVkIGFzIHBhcnQgb2YgYSB3aWRl ciBzdHJhdGVneSBpbmNvcnBvcmF0aW5nIG11bHRpcGxlIHBvaW50cyBvZg0KZGV0ZWN0aW9uIGFu ZCBtaXRpZ2F0aW9uLCBib3RoIG9uIHByZW1pc2Ugb3Igc2VydmljZSBwcm92aWRlciBiYXNlZC4N ClNob3VsZCBtaXRpZ2F0aW9uIG5lZWQgdG8gbW92ZSBiZXR3ZWVuIGVsZW1lbnRzIGluIHRoZSBj aGFpbiB0aGVuDQplZmZlY3RpdmUgc2lnbmFsaW5nIG9mIHRlbGVtZXRyeSBhbmQgY3VycmVudCB0 aHJlYXQgaGFuZGxpbmcgaXMgZXNzZW50aWFsLg0KDQoNCklzIHRoZSBpbXBsaWNhdGlvbiB0aGF0 IGFuIG9uLXByZW1pc2UgZGV2aWNlIG1heSBzaWduYWwgbGF0ZXJhbGx5IGludGVudGlvbmFsPyBP ciBpcyB0aGUgZXhwZWN0YXRpb24gdGhhdCBlYWNoIHN1YnNlcXVlbnQgZWxlbWVudCBpbiB0aGUg Y2hhaW4gd2lsbCBiZSB1cHN0cmVhbSBmcm9tIHRoZSBwcmV2aW91cz8NCg0KDQoNCkZlZWRiYWNr IGJldHdlZW4gcGFydGljaXBhdGluZyBlbGVtZW50cyBpcyByZXF1aXJlZCBmb3IgaW5jcmVhc2Vk DQphd2FyZW5lc3MgZm9yIGVmZmVjdGl2ZSBkZWNpc2lvbiBtYWtpbmcuDQoNClRoZSBXRyB3aWxs LCB3aGVyZSBhcHByb3ByaWF0ZSwgcmV1c2UgZXhpc3Rpbmcgc3RhbmRhcmQgcHJvdG9jb2xzIGFu ZA0KbWVjaGFuaXNtcywgZm9yIGluc3RhbmNlIElQRklYIGFuZCBpdHMgdGVtcGxhdGluZyBtZWNo YW5pc20uDQpUaGUgY2hhcnRlciBvZiB0aGUgd29ya2luZyBncm91cCBpcyB0byBwcm9kdWNlIG9u ZSBvciBtb3JlIHN0YW5kYXJkcyB0cmFjaw0Kc3BlY2lmaWNhdGlvbiB0byBwcm92aWRlIGZvciB0 aGlzIG9wZW4gc2lnbmFsaW5nIGluIHRoZSBERG9TIHByb2JsZW0NCnNwYWNlLiAgV2hpbGUgdGhl IHJlc3VsdGluZyBzdGFuZGFyZHMgc2hvdWxkIGJlIGRlc2lnbmVkIHNvIHRoYXQgdGhlcmXCuXMg YQ0KcG9zc2liaWxpdHkgb2YgYXBwbHlpbmcgdGhlbSB0byBuZXR3b3JrIHNlY3VyaXR5IGFwcGxp Y2F0aW9ucyBiZXlvbmQgRERvUw0KDQoNCuKAnOKApmRlc2lnbmVkIHNvIHRoZXkgbWF5IGFwcGx5 IHRvIG5ldHdvcmsgc2VjdXJpdHkgYXBwbGljYXRpb25z4oCmIg0KDQoNCg0KbWl0aWdhdGlvbiwg dGhpcyB3b3JraW5nIGdyb3VwIHdpbGwgZm9jdXMgb24ganVzdCBERG9TIG1pdGlnYXRpb24uDQoN Cg0KU3RyaWtlIOKAnGp1c3TigJ0uDQoNCg0KDQpUaGlzIHN0cmVhbWxpbmVkIGZvY3VzIG9mIHRo ZSBjaGFydGVyIGlzIGludGVuZGVkIHRvIGxlYWQgdG8gYW4gZWFybGllciByZXN1bHQNCmR1ZSB0 byBjb21tdW5pdHkgaW50ZXJlc3RzIGluIGhhdmluZyBzdWNoIGNhcGFiaWxpdHkgaW4gYSBzaG9y dCB0aW1lZnJhbWUuDQpUaGUgc3BlY2lmaWNhdGlvbihzKSBwcm9kdWNlZCBieSB0aGUgV0cgd2ls bCBpbmNsdWRlIGEgc3RhbmRhcmQgbWVjaGFuaXNtDQpmb3IgYXV0aGVudGljYXRpb24gYW5kIGF1 dGhvcml6YXRpb24sIGZvciBkYXRhIGludGVncml0eSwgYW5kIGZvcg0KcHJvdmlkaW5nIGZvciBw cml2YWN5IGluIG9wZXJhdGlvbi4NCg0KVGhlIFdHIHdpbGwgcHJvZHVjZSB0aGUgZm9sbG93aW5n IGRlbGl2ZXJhYmxlczoNCg0KKiBVc2UgY2FzZSBkb2N1bWVudCB0byBlbnN1cmUgY29tbW9uYWxp dHkgb2YgdGhlIHdvcmsgYW1vbmcgdGhlDQpwYXJ0aWNpcGFudHMgaW4gdGhlIFdvcmtpbmcgR3Jv dXAuICBUaGlzIGRvY3VtZW50IG1heSBiZSBkZXRlcm1pbmVkIGJ5IHRoZQ0Kd29ya2luZyBncm91 cCB0byByZW1haW4gaW5mb3JtYWwgYW5kIG5vdCBiZSBwdWJsaXNoZWQuDQoqIERvY3VtZW50IG9y IERvY3VtZW50cyBkZXNjcmliaW5nIHRoZSBwcm9ibGVtIHNwYWNlLCB1c2UgY2FzZXMsIHByb3Rv Y29sDQpyZXF1aXJlbWVudHMgYW5kIG90aGVyIHF1YWxpZnlpbmcgaW5mb3JtYXRpb24gYXMgdGhl IFdHIHNlZXMgZml0Lg0KKiBEb2N1bWVudCBvciBEb2N1bWVudHMgc3BlY2lmeWluZyBhIHByb3Rv Y29sIGFuZCBhc3NvY2lhdGVkIGRhdGEgbW9kZWxzDQp0byBhZGRyZXNzIHRoZSBXRyBzdGF0ZWQg Z29hbC4NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KRG90cyBtYWlsaW5nIGxpc3QNCkRvdHNAaWV0Zi5vcmc8bWFpbHRvOkRvdHNAaWV0Zi5vcmc+ DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RvdHMNCg0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRG90cyBtYWlsaW5nIGxp c3QNCkRvdHNAaWV0Zi5vcmc8bWFpbHRvOkRvdHNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RvdHMNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KRG90cyBtYWlsaW5nIGxpc3QNCkRvdHNAaWV0Zi5vcmc8 bWFpbHRvOkRvdHNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2RvdHMNCg0K --_000_0586B864F60B46338A93B724C5F9BDC3a10networkscom_ Content-Type: text/html; charset="utf-8" Content-ID: <2731D2658AE90940893A629E67872939@corp.a10networks.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KJiM0MzsxICZuYnNwO0kgc3VwcG9y dCB0aGUgY2hhcnRlci4gQWdyZWVkIHRoYXQgaXQgaXMgaW1wb3J0YW50IGFuZCB3ZSBjb21taXQg dG8gd29yayBhY3RpdmVseSBvbiBpdC48YnIgY2xhc3M9IiI+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIE1heSAxMiwgMjAxNSwgYXQg MTI6MjkgUE0sIFRvYmlhcyBHb25kcm9tICZsdDs8YSBocmVmPSJtYWlsdG86dG9iaWFzLmdvbmRy b21AZ29uZHJvbS5vcmciIGNsYXNzPSIiPnRvYmlhcy5nb25kcm9tQGdvbmRyb20ub3JnPC9hPiZn dDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0K PGRpdiBjbGFzcz0iIj4NCjxkaXYgYmdjb2xvcj0iI0ZGRkZGRiIgdGV4dD0iIzAwMDAwMCIgY2xh c3M9IiI+PGZvbnQgZmFjZT0iQXJpYWwiIGNsYXNzPSIiPkkgYWdyZWUgdGhhdCB0aGlzIGlzIGlt cG9ydGFudCB3b3JrIGZvciB0aGUgY29tbXVuaXR5IGFuZCBzaG91bGQgYmUgZG9uZS4NCjxiciBj bGFzcz0iIj4NCkFuZCBvdmVyYWxsLCBJIGRvIHN1cHBvcnQgdGhlIHByb3Bvc2VkIGNoYXJ0ZXIg d2l0aCBhZGp1c3RtZW50cyBhcyBzdWdnZXN0ZWQgYnkgc2V2ZXJhbA0KPC9mb250PnBlb3BsZSBo ZXJlIG9uIHRoZSBtYWlsaW5nLWxpc3QuIDxiciBjbGFzcz0iIj4NCkJlc3QgcmVnYXJkcywgVG9i aWFzPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFz cz0ibW96LWNpdGUtcHJlZml4Ij5PbiAwOS8wNS8xNSAxOToyOCwgS2F0aGxlZW4gTW9yaWFydHkg d3JvdGU6PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBjaXRlPSJtaWQ6RkFGRjIw QTAtNzMwMS00N0E3LUJGRkUtMjUzNDUyOEUzREZBQGdtYWlsLmNvbSIgdHlwZT0iY2l0ZSIgY2xh c3M9IiI+DQo8cHJlIHdyYXA9IiIgY2xhc3M9IiI+QXJlIHRoZXJlIGFueSBvdGhlciBjb21tZW50 cyBvbiB0aGUgcHJvcG9zZWQgY2hhcnRlcj8gIElmIHlvdSd2ZSByZWFkIGl0IGFuZCBkbyBub3Qg aGF2ZSBjaGFuZ2VzLCBleHByZXNzaW9ucyBvZiBzdXBwb3J0IGZvciB0aGUgY3VycmVudCB2ZXJz aW9uIHdvdWxkIGJlIGhlbHBmdWwgdG8gdW5kZXJzdGFuZCBob3cgbWFueSBmb2xrcyBhZ3JlZSB0 aGlzIGlzIGltcG9ydGFudCBhbmQgd2FudCB0byB3b3JrIG9uIHRoaXMgaW4gdGhlIElFVEYuDQoN ClRoYW5rIHlvdSwNCkthdGhsZWVuIA0KDQpTZW50IGZyb20gbXkgaVBob25lDQoNCjwvcHJlPg0K PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8cHJlIHdyYXA9IiIgY2xhc3M9IiI+ T24gTWF5IDIsIDIwMTUsIGF0IDE6MjggQU0sIEFuZHJldyBNb3J0ZW5zZW4gPGEgY2xhc3M9Im1v ei10eHQtbGluay1yZmMyMzk2RSIgaHJlZj0ibWFpbHRvOmFtb3J0ZW5zZW5AYXJib3IubmV0Ij4m bHQ7YW1vcnRlbnNlbkBhcmJvci5uZXQmZ3Q7PC9hPiB3cm90ZToNCg0KSGkgTmlrLiBUaGFua3Mg Zm9yIGdpdmluZyB1cyBhIGdvb2QgZm91bmRhdGlvbiB0byBidWlsZCB1cG9uLg0KDQpDb21tZW50 cy9uaXRwaWNrcyBpbmxpbmUsIHRyeWluZyBub3QgdG8gb3ZlcmxhcCB0b28gbXVjaCB3aXRoIEFk YW0uDQoNCmFuZHJldw0KDQotLQ0KDQo8L3ByZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNs YXNzPSIiPg0KPHByZSB3cmFwPSIiIGNsYXNzPSIiPlRoZSBhaW0gb2YgRERvUyBPcGVuIFRocmVh dCBTaWduYWxpbmcgKERPVFMpIGlzIHRvIGRldmVsb3AgYSBzdGFuZGFyZHMNCmJhc2VkIGFwcHJv YWNoIHRvIHRoZSByZWFsIHRpbWUgc2lnbmFsaW5nIG9mIEREb1MgcmVsYXRlZCB0ZWxlbWV0cnkg YW5kDQp0aHJlYXQgaGFuZGxpbmcgZGF0YSBiZXR3ZWVuIGVsZW1lbnRzIGNvbmNlcm5lZCB3aXRo IGF0dGFjayBtaXRpZ2F0aW9uLg0KPC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlIHdyYXA9IiIg Y2xhc3M9IiI+SSB0aGluayB0aGUg4oCccmVhbCB0aW1l4oCdIHBocmFzZSBoZXJlIGlzIGludGVu ZGVkIHRvIGVtcGhhc2l6ZSB0aGF0IHRoZSBzaWduYWxpbmcgaXMgZXhwZWN0ZWQgdG8gYmUgZG9u ZSB1bmRlciBhdHRhY2sgY29uZGl0aW9ucy4gVGhhdCBzZWVtcyB0byBtZSBhbiBpbXBvcnRhbnQg ZGlmZmVyZW50aWF0b3IgZnJvbSBtaWxlLiBXZSBzaG91bGQgbWFrZSBpdCBleHBsaWNpdCBoZXJl Lg0KDQo8L3ByZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPHByZSB3cmFw PSIiIGNsYXNzPSIiPlRoZSBlbGVtZW50cyBtYXkgYmUgZGVzY3JpYmVkIGFzOg0KKiBPbi1wcmVt aXNlIEREb1MgbWl0aWdhdGlvbiBwbGF0Zm9ybXMNCiogU2VydmljZSBwcm92aWRlciBERG9TIG1p dGlnYXRpb24gcGxhdGZvcm1zDQoqIE90aGVyIG5ldHdvcmsgZGV2aWNlcy9wbGF0Zm9ybXMgdGhh dCBhcmUgYWJsZSB0byBzZW5zZSBERG9TIGFuZCByZXNwb25kDQo8L3ByZT4NCjwvYmxvY2txdW90 ZT4NCjxwcmUgd3JhcD0iIiBjbGFzcz0iIj5Tb21ldGhpbmcgYWxvbmcgdGhlIGxpbmVzIG9mIOKA nE90aGVyIGRldmljZXMgd2l0aCBuZXR3b3JrIHBlcnNwZWN0aXZlIHBlcmZvcm1pbmcgdHJhZmZp YyBhbmFseXNpc+KAnSAgb3Ig4oCc4oCmZW5nYWdlZCBpbiB0cmFmZmljIGFuYWx5c2lz4oCdIHNo b3VsZCBlbmNvbXBhc3MgdGhpbmdzIGxpa2UgZmxvdyBtb25pdG9yaW5nIGFuZCBJRFMvSVBTLg0K DQo8L3ByZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPHByZSB3cmFwPSIi IGNsYXNzPSIiPiogQ2hhaW5lZCBpbnN0YW5jZXMgb2YgdGhlIGFib3ZlDQoNClRoZXNlIGVsZW1l bnRzIG1heSBiZSBjb21tdW5pY2F0aW5nIGludGVyLWRvbWFpbiBvciBpbnRyYS1kb21haW4gb3Zl cg0KbGlua3MgdGhhdCBtYXkgYmUgY29uZ2VzdGVkIGJ5IGF0dGFjayB0cmFmZmljIHJlc3VsdGlu ZyBpbiBob3N0aWxlDQpjb25kaXRpb25zIGZvciB0cmFkaXRpb25hbCBjb25uZWN0aW9uIG9yaWVu dGVkIGFwcHJvYWNoZXMgYW5kIG1vcmUNCmdlbmVyYWxpemVkIHNpZ25hbGluZyBhbmQgdGVsZW1l dHJ5IHNvbHV0aW9ucy4NCjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHByZSB3cmFwPSIiIGNsYXNz PSIiPlN0cmlrZSDigJx0cmFkaXRpb25hbOKAnS4gUmVnYXJkbGVzcyBvZiBpbm5vdmF0aW9uLCBh IGNvbm5lY3Rpb24tb3JpZW50ZWQgcHJvdG9jb2wgaXMgbm90IGFwcHJvcHJpYXRlIGZvciBkb3Rz IGZvciB0aGUgcmVhc29ucyB5b3XigJl2ZSBqdXN0IHN0YXRlZC4gSSB0aGluayB0aGlzIGNhbiBi ZSB0aWdodGVuZWQgdG8sIGUuZy4sIOKAnOKApmhvc3RpbGUgY29uZGl0aW9ucyBmb3IgY29ubmVj dGlvbi1vcmllbnRlZCBzaWduYWxpbmcgYW5kIHRlbGVtZXRyeSBwcm90b2NvbHMu4oCdDQoNCjwv cHJlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8cHJlIHdyYXA9IiIgY2xh c3M9IiI+Um9idXN0bmVzcyB1bmRlciB0aGVzZQ0KY29uZGl0aW9ucyBpcyBwYXJhbW91bnQgd2hp bGUgZW5zdXJpbmcgYXBwcm9wcmlhdGUgcmVnYXJkIGZvcg0KYXV0aGVudGljYXRpb24sIGF1dGhv cml6YXRpb24sIHByaXZhY3kgYW5kIGRhdGEgaW50ZWdyaXR5LiAgRWxlbWVudHMgbWF5DQpiZSBk ZXBsb3llZCBhcyBwYXJ0IG9mIGEgd2lkZXIgc3RyYXRlZ3kgaW5jb3Jwb3JhdGluZyBtdWx0aXBs ZSBwb2ludHMgb2YNCmRldGVjdGlvbiBhbmQgbWl0aWdhdGlvbiwgYm90aCBvbiBwcmVtaXNlIG9y IHNlcnZpY2UgcHJvdmlkZXIgYmFzZWQuDQpTaG91bGQgbWl0aWdhdGlvbiBuZWVkIHRvIG1vdmUg YmV0d2VlbiBlbGVtZW50cyBpbiB0aGUgY2hhaW4gdGhlbg0KZWZmZWN0aXZlIHNpZ25hbGluZyBv ZiB0ZWxlbWV0cnkgYW5kIGN1cnJlbnQgdGhyZWF0IGhhbmRsaW5nIGlzIGVzc2VudGlhbC4NCjwv cHJlPg0KPC9ibG9ja3F1b3RlPg0KPHByZSB3cmFwPSIiIGNsYXNzPSIiPklzIHRoZSBpbXBsaWNh dGlvbiB0aGF0IGFuIG9uLXByZW1pc2UgZGV2aWNlIG1heSBzaWduYWwgbGF0ZXJhbGx5IGludGVu dGlvbmFsPyBPciBpcyB0aGUgZXhwZWN0YXRpb24gdGhhdCBlYWNoIHN1YnNlcXVlbnQgZWxlbWVu dCBpbiB0aGUgY2hhaW4gd2lsbCBiZSB1cHN0cmVhbSBmcm9tIHRoZSBwcmV2aW91cz8NCg0KPC9w cmU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxwcmUgd3JhcD0iIiBjbGFz cz0iIj5GZWVkYmFjayBiZXR3ZWVuIHBhcnRpY2lwYXRpbmcgZWxlbWVudHMgaXMgcmVxdWlyZWQg Zm9yIGluY3JlYXNlZA0KYXdhcmVuZXNzIGZvciBlZmZlY3RpdmUgZGVjaXNpb24gbWFraW5nLg0K DQpUaGUgV0cgd2lsbCwgd2hlcmUgYXBwcm9wcmlhdGUsIHJldXNlIGV4aXN0aW5nIHN0YW5kYXJk IHByb3RvY29scyBhbmQNCm1lY2hhbmlzbXMsIGZvciBpbnN0YW5jZSBJUEZJWCBhbmQgaXRzIHRl bXBsYXRpbmcgbWVjaGFuaXNtLg0KVGhlIGNoYXJ0ZXIgb2YgdGhlIHdvcmtpbmcgZ3JvdXAgaXMg dG8gcHJvZHVjZSBvbmUgb3IgbW9yZSBzdGFuZGFyZHMgdHJhY2sNCnNwZWNpZmljYXRpb24gdG8g cHJvdmlkZSBmb3IgdGhpcyBvcGVuIHNpZ25hbGluZyBpbiB0aGUgRERvUyBwcm9ibGVtDQpzcGFj ZS4gIFdoaWxlIHRoZSByZXN1bHRpbmcgc3RhbmRhcmRzIHNob3VsZCBiZSBkZXNpZ25lZCBzbyB0 aGF0IHRoZXJlwrlzIGENCnBvc3NpYmlsaXR5IG9mIGFwcGx5aW5nIHRoZW0gdG8gbmV0d29yayBz ZWN1cml0eSBhcHBsaWNhdGlvbnMgYmV5b25kIEREb1MNCjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0K PHByZSB3cmFwPSIiIGNsYXNzPSIiPuKAnOKApmRlc2lnbmVkIHNvIHRoZXkgbWF5IGFwcGx5IHRv IG5ldHdvcmsgc2VjdXJpdHkgYXBwbGljYXRpb25z4oCmJnF1b3Q7DQoNCjwvcHJlPg0KPGJsb2Nr cXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8cHJlIHdyYXA9IiIgY2xhc3M9IiI+bWl0aWdh dGlvbiwgdGhpcyB3b3JraW5nIGdyb3VwIHdpbGwgZm9jdXMgb24ganVzdCBERG9TIG1pdGlnYXRp b24uDQo8L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwcmUgd3JhcD0iIiBjbGFzcz0iIj5TdHJpa2Ug 4oCcanVzdOKAnS4NCg0KPC9wcmU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4N CjxwcmUgd3JhcD0iIiBjbGFzcz0iIj5UaGlzIHN0cmVhbWxpbmVkIGZvY3VzIG9mIHRoZSBjaGFy dGVyIGlzIGludGVuZGVkIHRvIGxlYWQgdG8gYW4gZWFybGllciByZXN1bHQNCmR1ZSB0byBjb21t dW5pdHkgaW50ZXJlc3RzIGluIGhhdmluZyBzdWNoIGNhcGFiaWxpdHkgaW4gYSBzaG9ydCB0aW1l ZnJhbWUuDQpUaGUgc3BlY2lmaWNhdGlvbihzKSBwcm9kdWNlZCBieSB0aGUgV0cgd2lsbCBpbmNs dWRlIGEgc3RhbmRhcmQgbWVjaGFuaXNtDQpmb3IgYXV0aGVudGljYXRpb24gYW5kIGF1dGhvcml6 YXRpb24sIGZvciBkYXRhIGludGVncml0eSwgYW5kIGZvcg0KcHJvdmlkaW5nIGZvciBwcml2YWN5 IGluIG9wZXJhdGlvbi4NCg0KVGhlIFdHIHdpbGwgcHJvZHVjZSB0aGUgZm9sbG93aW5nIGRlbGl2 ZXJhYmxlczoNCg0KKiBVc2UgY2FzZSBkb2N1bWVudCB0byBlbnN1cmUgY29tbW9uYWxpdHkgb2Yg dGhlIHdvcmsgYW1vbmcgdGhlDQpwYXJ0aWNpcGFudHMgaW4gdGhlIFdvcmtpbmcgR3JvdXAuICBU aGlzIGRvY3VtZW50IG1heSBiZSBkZXRlcm1pbmVkIGJ5IHRoZQ0Kd29ya2luZyBncm91cCB0byBy ZW1haW4gaW5mb3JtYWwgYW5kIG5vdCBiZSBwdWJsaXNoZWQuDQoqIERvY3VtZW50IG9yIERvY3Vt ZW50cyBkZXNjcmliaW5nIHRoZSBwcm9ibGVtIHNwYWNlLCB1c2UgY2FzZXMsIHByb3RvY29sDQpy ZXF1aXJlbWVudHMgYW5kIG90aGVyIHF1YWxpZnlpbmcgaW5mb3JtYXRpb24gYXMgdGhlIFdHIHNl ZXMgZml0Lg0KKiBEb2N1bWVudCBvciBEb2N1bWVudHMgc3BlY2lmeWluZyBhIHByb3RvY29sIGFu ZCBhc3NvY2lhdGVkIGRhdGEgbW9kZWxzDQp0byBhZGRyZXNzIHRoZSBXRyBzdGF0ZWQgZ29hbC4N CjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHByZSB3cmFwPSIiIGNsYXNzPSIiPl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpEb3RzIG1haWxpbmcgbGlzdA0K PGEgY2xhc3M9Im1vei10eHQtbGluay1hYmJyZXZpYXRlZCIgaHJlZj0ibWFpbHRvOkRvdHNAaWV0 Zi5vcmciPkRvdHNAaWV0Zi5vcmc8L2E+DQo8YSBjbGFzcz0ibW96LXR4dC1saW5rLWZyZWV0ZXh0 IiBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RvdHMiPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG90czwvYT4NCjwvcHJlPg0KPC9ibG9j a3F1b3RlPg0KPHByZSB3cmFwPSIiIGNsYXNzPSIiPl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpEb3RzIG1haWxpbmcgbGlzdA0KPGEgY2xhc3M9Im1vei10 eHQtbGluay1hYmJyZXZpYXRlZCIgaHJlZj0ibWFpbHRvOkRvdHNAaWV0Zi5vcmciPkRvdHNAaWV0 Zi5vcmc8L2E+DQo8YSBjbGFzcz0ibW96LXR4dC1saW5rLWZyZWV0ZXh0IiBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RvdHMiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vZG90czwvYT4NCjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNs YXNzPSIiPg0KPC9kaXY+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxiciBjbGFzcz0iIj4NCkRvdHMgbWFpbGluZyBsaXN0PGJyIGNsYXNzPSIiPg0KPGEg aHJlZj0ibWFpbHRvOkRvdHNAaWV0Zi5vcmciIGNsYXNzPSIiPkRvdHNAaWV0Zi5vcmc8L2E+PGJy IGNsYXNzPSIiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kb3RzPGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_0586B864F60B46338A93B724C5F9BDC3a10networkscom_-- From nobody Tue May 12 15:15:04 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D98361A9070 for ; Tue, 12 May 2015 15:15:02 -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 m_gkG7ywsSQl for ; Tue, 12 May 2015 15:14:59 -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 C89601A906E for ; Tue, 12 May 2015 15:14:58 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BVY84609; Tue, 12 May 2015 22:14:57 +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; Tue, 12 May 2015 23:14:56 +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; Tue, 12 May 2015 15:14:45 -0700 From: Linda Dunbar To: Scott Barvick , "Adam W. Montville" , "Teague, Nik" Thread-Topic: [Dots] Draft Charter Thread-Index: AQHQfE+l/Sly82ObQkmwTXHnIFPOXJ1ZfxCAgAAiHMCAAZWkgIAdz1+w Date: Tue, 12 May 2015 22:14:45 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657C13F96@dfweml701-chm> References: <1C8B68F6-75A6-4869-B03A-7DCFD0092437@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F657C090E5@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.129.193] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "dots@ietf.org" Subject: Re: [Dots] Draft Charter X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 22:15:03 -0000 I support the charter, with some suggestion on the wording: Since it is not within DOTS scope to figure out "congestion status" of the = links/paths nor ensure zero packet loss, the charter should simply say: "These elements may be communicating over congested links/paths, with poss= ibility of packets loss. Therefore, mechanisms have be considered to compe= nsate packets loss to ensure appropriate regard for authentication, authori= zation, privacy and data integrity."=20 Instead of the following wording: >> These elements may be communicating inter-domain or intra-domain over=20 >> links/path that may be congested by attack traffic resulting in hostile= =20 >> conditions for traditional connection oriented approaches and more=20 >> generalized signaling and telemetry solutions. Robustness under=20 >> these conditions is paramount while ensuring appropriate regard for=20 >> authentication, authorization, privacy and data integrity. Linda Dunbar -----Original Message----- From: Scott Barvick [mailto:Scott.Barvick@corero.com]=20 Sent: Thursday, April 23, 2015 10:49 AM To: Linda Dunbar; Adam W. Montville; Teague, Nik Cc: dots@ietf.org Subject: Re: [Dots] Draft Charter Linda, If I understand your questions, IMO the answer to both of them is no, but = we do need to clarify. 1) "ensure . congestion status" - Under a big DDoS attack, the inbound link to the DDoS device may be so saturated that 'traditional methods. solu= tions" will not work because they most likely utilize 2 way (connection-oriented) traffic. If the inbound link is saturated, we might only be able to "reliably" get the situation signaled through a conne= ctionless protocol that counts on repetition and statistical likelihood for= success. So, I don't think we can ensure congestion status (other than de= signing for congestion:). 2) "ensure secure channels" . The channel is not dedicated so the protocol needs to do the right thing, as the charter says about ". Appropri= ate regard for . data integrity". If my channel, you mean the logical chan= nel between the devices, then, yes, I think we have to address that. 3) At least in the first round, I don't see us having the DDoS elements trying to figure out optimal paths between the devices. The DDoS devices signal, the upstream receivers take action, and the routing/rerouting happe= ns around the DDoS devices. Regards, Scott On 4/22/15, 6:47 PM, "Linda Dunbar" wrote: >I have a few questions on the DOTS scope: > >on the this paragraph: > >> These elements may be communicating inter-domain or intra-domain over=20 >> links that may be congested by attack traffic resulting in hostile=20 >> conditions for traditional connection oriented approaches and more=20 >> generalized signaling and telemetry solutions. Robustness under=20 >> these conditions is paramount while ensuring appropriate regard for=20 >> authentication, authorization, privacy and data integrity. > >Is it the goal of the DOTS group to ensure the secure channels and=20 >congestion status for paths between the On-premise DDoS mitigation=20 >platforms and the Service provider DDoS mitigation platforms? > >Is it in the scope for DDOS elements to communicate with Network=20 >Management system to figure out an optimal path between the DDOS=20 >elements? > >Linda > >-----Original Message----- >From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Adam W.=20 >Montville >Sent: Wednesday, April 22, 2015 8:35 AM >To: Teague, Nik >Cc: dots@ietf.org >Subject: Re: [Dots] Draft Charter > >Well-written, Nik. I spotted a couple of minor nits (there may be=20 >others), and have a couple of observations/comments - all inline. > >> On Apr 21, 2015, at 11:24 AM, Teague, Nik wrote: >>=20 >> Hi, >>=20 >> Please see a 1st pass draft charter below - comments and feedback=20 >> always welcome. >>=20 >> -Nik >>=20 >>=20 >> The aim of DDoS Open Threat Signaling (DOTS) is to develop a=20 >>standards based approach to the real time signaling of DDoS related=20 >>telemetry and threat handling data between elements concerned with=20 >>attack mitigation. >>=20 >> The elements may be described as: >> * On-premise DDoS mitigation platforms >> * Service provider DDoS mitigation platforms >> * Other network devices/platforms that are able to sense DDoS and=20 >> respond >> * Chained instances of the above >>=20 > >The first two points seem pretty tight, but the third bullet seems less=20 >so. As a reader, it feels that you may have wanted to write something=20 >like "Other DDoS mitigation platforms", but didn't for what is likely=20 >an important reason. Maybe another way to look at it is that the first=20 >two bullets seem to be distinguished based on mitigation platform=20 >location, but the third is a catch-all not necessarily related to location= . > >This isn't a suggestion to change, but an observation you might choose=20 >to consider to clarify your meaning. > >> These elements may be communicating inter-domain or intra-domain over =20 >>links that may be congested by attack traffic resulting in hostile =20 >>conditions for traditional connection oriented approaches and more =20 >>generalized signaling and telemetry solutions. Robustness under these =20 >>conditions is paramount while ensuring appropriate regard for =20 >>authentication, authorization, privacy and data integrity. Elements =20 >>may be deployed as part of a wider strategy incorporating multiple =20 >>points of detection and mitigation, both on premise or service=20 >>provider based. >> Should mitigation need to move between elements in the chain then =20 >>effective signaling of telemetry and current threat handling is=20 >>essential. > >Consider a comma between "chain" and "then" resulting in: "Should=20 >mitigation need to move between elements in the chain, then." > >> Feedback between participating elements is required for increased=20 >> awareness for effective decision making. > >Could this be ".required for increased awareness supporting effective=20 >decision making"? > >>=20 >> The WG will, where appropriate, reuse existing standard protocols and=20 >> mechanisms, for instance IPFIX and its templating mechanism. > >Would it be helpful to also say that you intend (if you do) to=20 >coordinate efforts with other working groups that may be working on=20 >similar problems? Consider i2nsf, supa, sacm, and mile. Some of these=20 >have standards you might leverage, but others are still working on solutio= ns. >In sacm, for example, we are working to define models and protocols=20 >based on endpoint posture assessment, which includes some expression of=20 >policy, endpoint attributes, and so on. Pieces of these things may be=20 >useful to dots. > > >>=20 >> The charter of the working group is to produce one or more standards=20 >> track specification to provide for this open signaling in the DDoS=20 >> problem space. > >Make "specification" plural, so that the sentence reads: ".to produce=20 >one or more standards track specifications.". > >> While the resulting standards should be designed so that there=B9s a=20 >> possibility of applying them to network security applications beyond=20 >> DDoS mitigation, this working group will focus on just DDoS mitigation. > >The ' in "there's" came up funny (probably a copy/paste issue). > >> This >> streamlined focus of the charter is intended to lead to an earlier =20 >>result due to community interests in having such capability in a short=20 >>timeframe. >> The specification(s) produced by the WG will include a standard =20 >>mechanism for authentication and authorization, for data integrity, =20 >>and for providing for privacy in operation. >>=20 >> The WG will produce the following deliverables: >>=20 >> * Use case document to ensure commonality of the work among the =20 >>participants in the Working Group. This document may be determined by =20 >>the working group to remain informal and not be published. >> * Document or Documents describing the problem space, use cases, =20 >>protocol requirements and other qualifying information as the WG sees=20 >>fit. >> * Document or Documents specifying a protocol and associated data =20 >>models to address the WG stated goal. > >Something we recently did in sacm is to create a milestone for=20 >revisiting milestones. The idea is that we know we're going to have=20 >some data models and protocols, but we're not sure how many or how they=20 >might be divided among multiple drafts. Something like that could be=20 >useful here as well, because it is clear that you will have models and=20 >protocols, but it's not clear how that work will ultimately materialize. > >It might be too early, but do you have any idea as to dates for these=20 >milestones? > >>=20 >> _______________________________________________ >> Dots mailing list >> Dots@ietf.org >> https://www.ietf.org/mailman/listinfo/dots > >_______________________________________________ >Dots mailing list >Dots@ietf.org >https://www.ietf.org/mailman/listinfo/dots > >_______________________________________________ >Dots mailing list >Dots@ietf.org >https://www.ietf.org/mailman/listinfo/dots From nobody Tue May 12 17:35:04 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99A531A8881 for ; Tue, 12 May 2015 17:35:02 -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, 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 VhHwt29tg5l1 for ; Tue, 12 May 2015 17:34:59 -0700 (PDT) Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::235]) (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 9D69E1A887C for ; Tue, 12 May 2015 17:34:59 -0700 (PDT) Received: by qgdy78 with SMTP id y78so13747433qgd.0 for ; Tue, 12 May 2015 17:34:59 -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=UnVwZbJte2jZtHcV9NZndfIwPJY0EGmhhZqluM/h8Qw=; b=FPViSy/dASMKFOfXfsxC/ku+gA386aQ+NkrSjzOakPA0N+66kEqWQXEWZ2Rohi0IhT WDarSfMEVc/q0DRmnycwvFR1tB8KUDkHP4JzZ0ATAUWgRim9ehyG/zL3uEHXKgkvbDcZ a4g6snOKrxQR3aQ6xPgzVQ9CW0leQN6OdzIjTnjO5b3DeTl22EhCYqWbXwz2BbmWqahh z5J72gybFD30Yhb7z6l9LuUDoYpyCOARH/EQgdzDMrN88wGPQzdyS4RQ9Ahx5tSqW29Y 9XbT9dIkaHo3SBkjt9PbqIXUbsz3tqrMuwCvO5xLWArpFslzodTNMr6EJGMBvKHxBZzw fEDQ== X-Received: by 10.55.21.8 with SMTP id f8mr38975608qkh.2.1431477298994; Tue, 12 May 2015 17:34:58 -0700 (PDT) Received: from [192.168.1.3] (209-6-114-252.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.114.252]) by mx.google.com with ESMTPSA id g108sm14593660qgg.26.2015.05.12.17.34.57 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 May 2015 17:34:57 -0700 (PDT) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (11D257) In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657C13F96@dfweml701-chm> Date: Tue, 12 May 2015 20:34:56 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1C8B68F6-75A6-4869-B03A-7DCFD0092437@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F657C090E5@dfweml701-chm> <4A95BA014132FF49AE685FAB4B9F17F657C13F96@dfweml701-chm> To: Linda Dunbar Archived-At: Cc: "Teague, Nik" , Scott Barvick , "Adam W. Montville" , "dots@ietf.org" Subject: Re: [Dots] Draft Charter X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 00:35:02 -0000 Interesting. I read the current text with the intent of your proposed text,= but if others read it differently, adjustments may be helpful. I do like t= he wording of the original, so maybe it could be tweaked a bit to make sure L= inda's point is clear? Thanks, Kathleen (No hat)=20 Sent from my iPhone > On May 12, 2015, at 6:14 PM, Linda Dunbar wrote:= >=20 > I support the charter, with some suggestion on the wording: >=20 > Since it is not within DOTS scope to figure out "congestion status" of the= links/paths nor ensure zero packet loss, the charter should simply say: >=20 > "These elements may be communicating over congested links/paths, with poss= ibility of packets loss. Therefore, mechanisms have be considered to compen= sate packets loss to ensure appropriate regard for authentication, authoriza= tion, privacy and data integrity."=20 >=20 > Instead of the following wording: >>> These elements may be communicating inter-domain or intra-domain over=20= >>> links/path that may be congested by attack traffic resulting in hostile=20= >>> conditions for traditional connection oriented approaches and more=20 >>> generalized signaling and telemetry solutions. Robustness under=20 >>> these conditions is paramount while ensuring appropriate regard for=20 >>> authentication, authorization, privacy and data integrity. >=20 > Linda Dunbar >=20 > -----Original Message----- > From: Scott Barvick [mailto:Scott.Barvick@corero.com]=20 > Sent: Thursday, April 23, 2015 10:49 AM > To: Linda Dunbar; Adam W. Montville; Teague, Nik > Cc: dots@ietf.org > Subject: Re: [Dots] Draft Charter >=20 > Linda, >=20 > If I understand your questions, IMO the answer to both of them is no, but= we do need to clarify. >=20 > 1) "ensure . congestion status" - Under a big DDoS attack, the inbound > link to the DDoS device may be so saturated that 'traditional methods. sol= utions" will not work because they most likely utilize 2 way > (connection-oriented) traffic. If the inbound link is saturated, we > might only be able to "reliably" get the situation signaled through a conn= ectionless protocol that counts on repetition and statistical likelihood for= success. So, I don't think we can ensure congestion status (other than des= igning for congestion:). >=20 > 2) "ensure secure channels" . The channel is not dedicated so the > protocol needs to do the right thing, as the charter says about ". Appropr= iate regard for . data integrity". If my channel, you mean the logical chan= nel between the devices, then, yes, I think we have to address that. >=20 > 3) At least in the first round, I don't see us having the DDoS elements > trying to figure out optimal paths between the devices. The DDoS devices= > signal, the upstream receivers take action, and the routing/rerouting happ= ens around the DDoS devices. >=20 > Regards, > Scott >=20 >=20 >> On 4/22/15, 6:47 PM, "Linda Dunbar" wrote: >>=20 >> I have a few questions on the DOTS scope: >>=20 >> on the this paragraph: >>=20 >>> These elements may be communicating inter-domain or intra-domain over=20= >>> links that may be congested by attack traffic resulting in hostile=20 >>> conditions for traditional connection oriented approaches and more=20 >>> generalized signaling and telemetry solutions. Robustness under=20 >>> these conditions is paramount while ensuring appropriate regard for=20 >>> authentication, authorization, privacy and data integrity. >>=20 >> Is it the goal of the DOTS group to ensure the secure channels and=20 >> congestion status for paths between the On-premise DDoS mitigation=20 >> platforms and the Service provider DDoS mitigation platforms? >>=20 >> Is it in the scope for DDOS elements to communicate with Network=20 >> Management system to figure out an optimal path between the DDOS=20 >> elements? >>=20 >> Linda >>=20 >> -----Original Message----- >> From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Adam W.=20 >> Montville >> Sent: Wednesday, April 22, 2015 8:35 AM >> To: Teague, Nik >> Cc: dots@ietf.org >> Subject: Re: [Dots] Draft Charter >>=20 >> Well-written, Nik. I spotted a couple of minor nits (there may be=20 >> others), and have a couple of observations/comments - all inline. >>=20 >>> On Apr 21, 2015, at 11:24 AM, Teague, Nik wrote: >>>=20 >>> Hi, >>>=20 >>> Please see a 1st pass draft charter below - comments and feedback=20 >>> always welcome. >>>=20 >>> -Nik >>>=20 >>>=20 >>> The aim of DDoS Open Threat Signaling (DOTS) is to develop a=20 >>> standards based approach to the real time signaling of DDoS related=20 >>> telemetry and threat handling data between elements concerned with=20 >>> attack mitigation. >>>=20 >>> The elements may be described as: >>> * On-premise DDoS mitigation platforms >>> * Service provider DDoS mitigation platforms >>> * Other network devices/platforms that are able to sense DDoS and=20 >>> respond >>> * Chained instances of the above >>=20 >> The first two points seem pretty tight, but the third bullet seems less=20= >> so. As a reader, it feels that you may have wanted to write something=20= >> like "Other DDoS mitigation platforms", but didn't for what is likely=20 >> an important reason. Maybe another way to look at it is that the first=20= >> two bullets seem to be distinguished based on mitigation platform=20 >> location, but the third is a catch-all not necessarily related to locatio= n. >>=20 >> This isn't a suggestion to change, but an observation you might choose=20= >> to consider to clarify your meaning. >>=20 >>> These elements may be communicating inter-domain or intra-domain over =20= >>> links that may be congested by attack traffic resulting in hostile =20 >>> conditions for traditional connection oriented approaches and more =20 >>> generalized signaling and telemetry solutions. Robustness under these =20= >>> conditions is paramount while ensuring appropriate regard for =20 >>> authentication, authorization, privacy and data integrity. Elements =20= >>> may be deployed as part of a wider strategy incorporating multiple =20 >>> points of detection and mitigation, both on premise or service=20 >>> provider based. >>> Should mitigation need to move between elements in the chain then =20 >>> effective signaling of telemetry and current threat handling is=20 >>> essential. >>=20 >> Consider a comma between "chain" and "then" resulting in: "Should=20 >> mitigation need to move between elements in the chain, then." >>=20 >>> Feedback between participating elements is required for increased=20 >>> awareness for effective decision making. >>=20 >> Could this be ".required for increased awareness supporting effective=20 >> decision making"? >>=20 >>>=20 >>> The WG will, where appropriate, reuse existing standard protocols and=20= >>> mechanisms, for instance IPFIX and its templating mechanism. >>=20 >> Would it be helpful to also say that you intend (if you do) to=20 >> coordinate efforts with other working groups that may be working on=20 >> similar problems? Consider i2nsf, supa, sacm, and mile. Some of these=20= >> have standards you might leverage, but others are still working on soluti= ons. >> In sacm, for example, we are working to define models and protocols=20 >> based on endpoint posture assessment, which includes some expression of=20= >> policy, endpoint attributes, and so on. Pieces of these things may be=20 >> useful to dots. >>=20 >>=20 >>>=20 >>> The charter of the working group is to produce one or more standards=20 >>> track specification to provide for this open signaling in the DDoS=20 >>> problem space. >>=20 >> Make "specification" plural, so that the sentence reads: ".to produce=20 >> one or more standards track specifications.". >>=20 >>> While the resulting standards should be designed so that there=C2=B9s a=20= >>> possibility of applying them to network security applications beyond=20 >>> DDoS mitigation, this working group will focus on just DDoS mitigation. >>=20 >> The ' in "there's" came up funny (probably a copy/paste issue). >>=20 >>> This >>> streamlined focus of the charter is intended to lead to an earlier =20 >>> result due to community interests in having such capability in a short=20= >>> timeframe. >>> The specification(s) produced by the WG will include a standard =20 >>> mechanism for authentication and authorization, for data integrity, =20 >>> and for providing for privacy in operation. >>>=20 >>> The WG will produce the following deliverables: >>>=20 >>> * Use case document to ensure commonality of the work among the =20 >>> participants in the Working Group. This document may be determined by =20= >>> the working group to remain informal and not be published. >>> * Document or Documents describing the problem space, use cases, =20 >>> protocol requirements and other qualifying information as the WG sees=20= >>> fit. >>> * Document or Documents specifying a protocol and associated data =20 >>> models to address the WG stated goal. >>=20 >> Something we recently did in sacm is to create a milestone for=20 >> revisiting milestones. The idea is that we know we're going to have=20 >> some data models and protocols, but we're not sure how many or how they=20= >> might be divided among multiple drafts. Something like that could be=20 >> useful here as well, because it is clear that you will have models and=20= >> protocols, but it's not clear how that work will ultimately materialize. >>=20 >> It might be too early, but do you have any idea as to dates for these=20 >> milestones? >>=20 >>>=20 >>> _______________________________________________ >>> Dots mailing list >>> Dots@ietf.org >>> https://www.ietf.org/mailman/listinfo/dots >>=20 >> _______________________________________________ >> Dots mailing list >> Dots@ietf.org >> https://www.ietf.org/mailman/listinfo/dots >>=20 >> _______________________________________________ >> Dots mailing list >> Dots@ietf.org >> https://www.ietf.org/mailman/listinfo/dots >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Tue May 12 18:11:40 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB71D1A890B for ; Tue, 12 May 2015 18:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_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 zYWJXkVJc_jF for ; Tue, 12 May 2015 18:11:36 -0700 (PDT) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.194]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 148161A88FE for ; Tue, 12 May 2015 18:11:35 -0700 (PDT) Received: from [216.82.242.179] by server-2.bemta-8.messagelabs.com id 6F/FA-16129-7C4A2555; Wed, 13 May 2015 01:11:35 +0000 X-Env-Sender: Scott.Barvick@corero.com X-Msg-Ref: server-14.tower-86.messagelabs.com!1431479494!580789!1 X-Originating-IP: [71.184.227.49] X-StarScan-Received: X-StarScan-Version: 6.13.14; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18376 invoked from network); 13 May 2015 01:11:34 -0000 Received: from mercury.corero.com (HELO MERCURY.corero.com) (71.184.227.49) by server-14.tower-86.messagelabs.com with AES128-SHA encrypted SMTP; 13 May 2015 01:11:34 -0000 Received: from MERCURY.corero.com ([fe80::2c05:6b26:abe2:ad24]) by MERCURY.corero.com ([fe80::2c05:6b26:abe2:ad24%19]) with mapi id 14.03.0224.002; Tue, 12 May 2015 21:11:28 -0400 From: Scott Barvick To: Kathleen Moriarty Thread-Topic: [Dots] Draft Charter Thread-Index: AQHQfE+l/Sly82ObQkmwTXHnIFPOXJ1ZTMWAgACaP4CAANpyAIAeixOAgAAnKgCAAAo2AA== Date: Wed, 13 May 2015 01:11:28 +0000 Message-ID: <35115B22-1A8D-4697-B151-6043A949E28C@corero.com> References: <1C8B68F6-75A6-4869-B03A-7DCFD0092437@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F657C090E5@dfweml701-chm> <4A95BA014132FF49AE685FAB4B9F17F657C13F96@dfweml701-chm> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.34.110.88] Content-Type: text/plain; charset="Windows-1252" Content-ID: <2D2C950AE4FC244DA70EFCF0069D448B@corero.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Nik Teague , "dots@ietf.org" , "Adam W. Montville" , Linda Dunbar Subject: Re: [Dots] Draft Charter X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 01:11:39 -0000 I don=92t think that the original implies that the elements need to determi= ne congestion status nor ensure zero packet loss, just be robust and secure= in the face of them. I also agree that the new suggestion is functionall= y equivalent so I think we should stick with the current proposal because i= t makes the important point that this work is not covered by existing or ot= her proposed efforts. Scott On May 12, 2015, at 8:34 PM, Kathleen Moriarty wrote: > Interesting. I read the current text with the intent of your proposed te= xt, but if others read it differently, adjustments may be helpful. I do li= ke the wording of the original, so maybe it could be tweaked a bit to make = sure Linda's point is clear? >=20 > Thanks, > Kathleen > (No hat)=20 >=20 > Sent from my iPhone >=20 >> On May 12, 2015, at 6:14 PM, Linda Dunbar wrot= e: >>=20 >> I support the charter, with some suggestion on the wording: >>=20 >> Since it is not within DOTS scope to figure out "congestion status" of t= he links/paths nor ensure zero packet loss, the charter should simply say: >>=20 >> "These elements may be communicating over congested links/paths, with po= ssibility of packets loss. Therefore, mechanisms have be considered to com= pensate packets loss to ensure appropriate regard for authentication, autho= rization, privacy and data integrity."=20 >>=20 >> Instead of the following wording: >>>> These elements may be communicating inter-domain or intra-domain over= =20 >>>> links/path that may be congested by attack traffic resulting in hostil= e=20 >>>> conditions for traditional connection oriented approaches and more=20 >>>> generalized signaling and telemetry solutions. Robustness under=20 >>>> these conditions is paramount while ensuring appropriate regard for=20 >>>> authentication, authorization, privacy and data integrity. >>=20 >> Linda Dunbar >>=20 >> -----Original Message----- >> From: Scott Barvick [mailto:Scott.Barvick@corero.com]=20 >> Sent: Thursday, April 23, 2015 10:49 AM >> To: Linda Dunbar; Adam W. Montville; Teague, Nik >> Cc: dots@ietf.org >> Subject: Re: [Dots] Draft Charter >>=20 >> Linda, >>=20 >> If I understand your questions, IMO the answer to both of them is no, b= ut we do need to clarify. >>=20 >> 1) "ensure . congestion status" - Under a big DDoS attack, the inboun= d >> link to the DDoS device may be so saturated that 'traditional methods. s= olutions" will not work because they most likely utilize 2 way >> (connection-oriented) traffic. If the inbound link is saturated, we >> might only be able to "reliably" get the situation signaled through a co= nnectionless protocol that counts on repetition and statistical likelihood = for success. So, I don't think we can ensure congestion status (other than= designing for congestion:). >>=20 >> 2) "ensure secure channels" . The channel is not dedicated so the >> protocol needs to do the right thing, as the charter says about ". Appro= priate regard for . data integrity". If my channel, you mean the logical c= hannel between the devices, then, yes, I think we have to address that. >>=20 >> 3) At least in the first round, I don't see us having the DDoS elements >> trying to figure out optimal paths between the devices. The DDoS devic= es >> signal, the upstream receivers take action, and the routing/rerouting ha= ppens around the DDoS devices. >>=20 >> Regards, >> Scott >>=20 >>=20 >>> On 4/22/15, 6:47 PM, "Linda Dunbar" wrote: >>>=20 >>> I have a few questions on the DOTS scope: >>>=20 >>> on the this paragraph: >>>=20 >>>> These elements may be communicating inter-domain or intra-domain over= =20 >>>> links that may be congested by attack traffic resulting in hostile=20 >>>> conditions for traditional connection oriented approaches and more=20 >>>> generalized signaling and telemetry solutions. Robustness under=20 >>>> these conditions is paramount while ensuring appropriate regard for=20 >>>> authentication, authorization, privacy and data integrity. >>>=20 >>> Is it the goal of the DOTS group to ensure the secure channels and=20 >>> congestion status for paths between the On-premise DDoS mitigation=20 >>> platforms and the Service provider DDoS mitigation platforms? >>>=20 >>> Is it in the scope for DDOS elements to communicate with Network=20 >>> Management system to figure out an optimal path between the DDOS=20 >>> elements? >>>=20 >>> Linda >>>=20 >>> -----Original Message----- >>> From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Adam W.=20 >>> Montville >>> Sent: Wednesday, April 22, 2015 8:35 AM >>> To: Teague, Nik >>> Cc: dots@ietf.org >>> Subject: Re: [Dots] Draft Charter >>>=20 >>> Well-written, Nik. I spotted a couple of minor nits (there may be=20 >>> others), and have a couple of observations/comments - all inline. >>>=20 >>>> On Apr 21, 2015, at 11:24 AM, Teague, Nik wrote= : >>>>=20 >>>> Hi, >>>>=20 >>>> Please see a 1st pass draft charter below - comments and feedback=20 >>>> always welcome. >>>>=20 >>>> -Nik >>>>=20 >>>>=20 >>>> The aim of DDoS Open Threat Signaling (DOTS) is to develop a=20 >>>> standards based approach to the real time signaling of DDoS related=20 >>>> telemetry and threat handling data between elements concerned with=20 >>>> attack mitigation. >>>>=20 >>>> The elements may be described as: >>>> * On-premise DDoS mitigation platforms >>>> * Service provider DDoS mitigation platforms >>>> * Other network devices/platforms that are able to sense DDoS and=20 >>>> respond >>>> * Chained instances of the above >>>=20 >>> The first two points seem pretty tight, but the third bullet seems less= =20 >>> so. As a reader, it feels that you may have wanted to write something= =20 >>> like "Other DDoS mitigation platforms", but didn't for what is likely=20 >>> an important reason. Maybe another way to look at it is that the first= =20 >>> two bullets seem to be distinguished based on mitigation platform=20 >>> location, but the third is a catch-all not necessarily related to locat= ion. >>>=20 >>> This isn't a suggestion to change, but an observation you might choose= =20 >>> to consider to clarify your meaning. >>>=20 >>>> These elements may be communicating inter-domain or intra-domain over = =20 >>>> links that may be congested by attack traffic resulting in hostile =20 >>>> conditions for traditional connection oriented approaches and more =20 >>>> generalized signaling and telemetry solutions. Robustness under these= =20 >>>> conditions is paramount while ensuring appropriate regard for =20 >>>> authentication, authorization, privacy and data integrity. Elements = =20 >>>> may be deployed as part of a wider strategy incorporating multiple =20 >>>> points of detection and mitigation, both on premise or service=20 >>>> provider based. >>>> Should mitigation need to move between elements in the chain then =20 >>>> effective signaling of telemetry and current threat handling is=20 >>>> essential. >>>=20 >>> Consider a comma between "chain" and "then" resulting in: "Should=20 >>> mitigation need to move between elements in the chain, then." >>>=20 >>>> Feedback between participating elements is required for increased=20 >>>> awareness for effective decision making. >>>=20 >>> Could this be ".required for increased awareness supporting effective=20 >>> decision making"? >>>=20 >>>>=20 >>>> The WG will, where appropriate, reuse existing standard protocols and= =20 >>>> mechanisms, for instance IPFIX and its templating mechanism. >>>=20 >>> Would it be helpful to also say that you intend (if you do) to=20 >>> coordinate efforts with other working groups that may be working on=20 >>> similar problems? Consider i2nsf, supa, sacm, and mile. Some of these= =20 >>> have standards you might leverage, but others are still working on solu= tions. >>> In sacm, for example, we are working to define models and protocols=20 >>> based on endpoint posture assessment, which includes some expression of= =20 >>> policy, endpoint attributes, and so on. Pieces of these things may be=20 >>> useful to dots. >>>=20 >>>=20 >>>>=20 >>>> The charter of the working group is to produce one or more standards=20 >>>> track specification to provide for this open signaling in the DDoS=20 >>>> problem space. >>>=20 >>> Make "specification" plural, so that the sentence reads: ".to produce=20 >>> one or more standards track specifications.". >>>=20 >>>> While the resulting standards should be designed so that there=B9s a=20 >>>> possibility of applying them to network security applications beyond=20 >>>> DDoS mitigation, this working group will focus on just DDoS mitigation= . >>>=20 >>> The ' in "there's" came up funny (probably a copy/paste issue). >>>=20 >>>> This >>>> streamlined focus of the charter is intended to lead to an earlier =20 >>>> result due to community interests in having such capability in a short= =20 >>>> timeframe. >>>> The specification(s) produced by the WG will include a standard =20 >>>> mechanism for authentication and authorization, for data integrity, =20 >>>> and for providing for privacy in operation. >>>>=20 >>>> The WG will produce the following deliverables: >>>>=20 >>>> * Use case document to ensure commonality of the work among the =20 >>>> participants in the Working Group. This document may be determined by= =20 >>>> the working group to remain informal and not be published. >>>> * Document or Documents describing the problem space, use cases, =20 >>>> protocol requirements and other qualifying information as the WG sees= =20 >>>> fit. >>>> * Document or Documents specifying a protocol and associated data =20 >>>> models to address the WG stated goal. >>>=20 >>> Something we recently did in sacm is to create a milestone for=20 >>> revisiting milestones. The idea is that we know we're going to have=20 >>> some data models and protocols, but we're not sure how many or how they= =20 >>> might be divided among multiple drafts. Something like that could be=20 >>> useful here as well, because it is clear that you will have models and= =20 >>> protocols, but it's not clear how that work will ultimately materialize= . >>>=20 >>> It might be too early, but do you have any idea as to dates for these=20 >>> milestones? >>>=20 >>>>=20 >>>> _______________________________________________ >>>> Dots mailing list >>>> Dots@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dots >>>=20 >>> _______________________________________________ >>> Dots mailing list >>> Dots@ietf.org >>> https://www.ietf.org/mailman/listinfo/dots >>>=20 >>> _______________________________________________ >>> Dots mailing list >>> Dots@ietf.org >>> https://www.ietf.org/mailman/listinfo/dots >>=20 >> _______________________________________________ >> Dots mailing list >> Dots@ietf.org >> https://www.ietf.org/mailman/listinfo/dots From nobody Tue May 12 20:51:58 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 625781A92E3 for ; Tue, 12 May 2015 20:51:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.911 X-Spam-Level: X-Spam-Status: No, score=-103.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, 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 xgArgBI6xKbD for ; Tue, 12 May 2015 20:51:54 -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 430ED1A92E0 for ; Tue, 12 May 2015 20:51:53 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BVZ01996; Wed, 13 May 2015 03:51:51 +0000 (GMT) Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 13 May 2015 04:51:50 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.244]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Wed, 13 May 2015 11:51:43 +0800 From: Zongning To: Kathleen Moriarty , Andrew Mortensen Thread-Topic: [Dots] Draft Charter Thread-Index: AQHQhJjdjz0djB2h1U2ku3JfOS1eip1za74AgAXqscA= Date: Wed, 13 May 2015 03:51:42 +0000 Message-ID: References: <6DEAC84F-75B4-41D6-A429-3C2328BEAEBA@arbor.net> In-Reply-To: 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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "Teague, Nik" , "dots@ietf.org" Subject: [Dots] =?utf-8?b?562U5aSNOiAgRHJhZnQgQ2hhcnRlcg==?= X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 03:51:56 -0000 SGksDQoNCkkgc3VwcG9ydCB0aGUgY3VycmVudCBET1RTIGNoYXJ0ZXIuIEp1c3Qgc29tZSBnZW5l cmFsIHN1Z2dlc3Rpb25zOg0KMS4gd2h5IGRvZXNuJ3QgRE9UUyBjb25zaWRlciB0aGUgY2VudHJh bGl6ZWQgYXJjaGl0ZWN0dXJlIHdoaWNoIGluY2x1ZGVzIGEgY2VudHJhbGl6ZWQgYW5hbHlzaXMg YW5kIGNvbnRyb2wgcGxhdGZvcm0/IENvbXBhcmluZyB0aGUgZGlzdHJpYnV0ZWQgd2F5LCBhIGNl bnRyYWxpemVkIHBsYXRmb3JtIGhhcyBhZHZhbnRhZ2Ugb2YgZm9ybWluZyBhIGhvbGlzdGljIHZp ZXcgb2YgbmV0d29yayB0aHJlYXQgZm9yIGRldGVjdGlvbiwgYW5kIGdlbmVyYXRpbmcgdGhlIG92 ZXJhbGwgb3B0aW1pemVkIHNlY3VyaXR5IHBvbGljaWVzIGZvciBtaXRpZ2F0aW9uLiBBIHR5cGlj YWwgZXhhbXBsZSBpcyBkZWZlbmRpbmcgYWdhaW5zdCB0aGUgQVBUIGF0dGFja3MgaW4gbmV0d29y azsgMi4gT25seSByZXVzZSBJUEZJWCBpcyBub3QgZW5vdWdoLCBET1RTIHdvcmtzIG5lZWQgdG8g ZXh0ZW5kIGl0IHdpdGggbmV3IElQRklYIGVsZW1lbnRzIGZvciBzcGVjaWFsIHNlY3VyaXR5IHJl cXVpcmVtZW50czsgMy4gTWF5YmUgYSBmcmFtZXdvcmsgZG9jdW1lbnQgaXMgbmVlZGVkIHRvIGRl c2NyaWJlIHRoZSB3aG9sZSBzb2x1dGlvbiwgaW5jbHVkZTogaXRzIGNvbXBvbmVudHMsIHRoZSBs b2dpYyByZWxhdGlvbnMgYW5kIGNvbW11bmljYXRpb24gcHJvdG9jb2xzIGJldHdlZW4gdGhlbS4u Lg0KDQpUaGFua3MuDQoNCi1OaW5nDQoNCi0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCuWPkeS7tuS6 ujogRG90cyBbbWFpbHRvOmRvdHMtYm91bmNlc0BpZXRmLm9yZ10g5Luj6KGoIEthdGhsZWVuIE1v cmlhcnR5DQrlj5HpgIHml7bpl7Q6IDIwMTXlubQ15pyIMTDml6UgMToyOA0K5pS25Lu25Lq6OiBB bmRyZXcgTW9ydGVuc2VuDQrmioTpgIE6IFRlYWd1ZSwgTmlrOyBkb3RzQGlldGYub3JnDQrkuLvp opg6IFJlOiBbRG90c10gRHJhZnQgQ2hhcnRlcg0KDQpBcmUgdGhlcmUgYW55IG90aGVyIGNvbW1l bnRzIG9uIHRoZSBwcm9wb3NlZCBjaGFydGVyPyAgSWYgeW91J3ZlIHJlYWQgaXQgYW5kIGRvIG5v dCBoYXZlIGNoYW5nZXMsIGV4cHJlc3Npb25zIG9mIHN1cHBvcnQgZm9yIHRoZSBjdXJyZW50IHZl cnNpb24gd291bGQgYmUgaGVscGZ1bCB0byB1bmRlcnN0YW5kIGhvdyBtYW55IGZvbGtzIGFncmVl IHRoaXMgaXMgaW1wb3J0YW50IGFuZCB3YW50IHRvIHdvcmsgb24gdGhpcyBpbiB0aGUgSUVURi4N Cg0KVGhhbmsgeW91LA0KS2F0aGxlZW4gDQoNClNlbnQgZnJvbSBteSBpUGhvbmUNCg0KPiBPbiBN YXkgMiwgMjAxNSwgYXQgMToyOCBBTSwgQW5kcmV3IE1vcnRlbnNlbiA8YW1vcnRlbnNlbkBhcmJv ci5uZXQ+IHdyb3RlOg0KPiANCj4gSGkgTmlrLiBUaGFua3MgZm9yIGdpdmluZyB1cyBhIGdvb2Qg Zm91bmRhdGlvbiB0byBidWlsZCB1cG9uLg0KPiANCj4gQ29tbWVudHMvbml0cGlja3MgaW5saW5l LCB0cnlpbmcgbm90IHRvIG92ZXJsYXAgdG9vIG11Y2ggd2l0aCBBZGFtLg0KPiANCj4gYW5kcmV3 DQo+IA0KPiAtLQ0KPiANCj4+IFRoZSBhaW0gb2YgRERvUyBPcGVuIFRocmVhdCBTaWduYWxpbmcg KERPVFMpIGlzIHRvIGRldmVsb3AgYSANCj4+IHN0YW5kYXJkcyBiYXNlZCBhcHByb2FjaCB0byB0 aGUgcmVhbCB0aW1lIHNpZ25hbGluZyBvZiBERG9TIHJlbGF0ZWQgDQo+PiB0ZWxlbWV0cnkgYW5k IHRocmVhdCBoYW5kbGluZyBkYXRhIGJldHdlZW4gZWxlbWVudHMgY29uY2VybmVkIHdpdGggYXR0 YWNrIG1pdGlnYXRpb24uDQo+IA0KPiBJIHRoaW5rIHRoZSDigJxyZWFsIHRpbWXigJ0gcGhyYXNl IGhlcmUgaXMgaW50ZW5kZWQgdG8gZW1waGFzaXplIHRoYXQgdGhlIHNpZ25hbGluZyBpcyBleHBl Y3RlZCB0byBiZSBkb25lIHVuZGVyIGF0dGFjayBjb25kaXRpb25zLiBUaGF0IHNlZW1zIHRvIG1l IGFuIGltcG9ydGFudCBkaWZmZXJlbnRpYXRvciBmcm9tIG1pbGUuIFdlIHNob3VsZCBtYWtlIGl0 IGV4cGxpY2l0IGhlcmUuDQo+IA0KPj4gVGhlIGVsZW1lbnRzIG1heSBiZSBkZXNjcmliZWQgYXM6 DQo+PiAqIE9uLXByZW1pc2UgRERvUyBtaXRpZ2F0aW9uIHBsYXRmb3Jtcw0KPj4gKiBTZXJ2aWNl IHByb3ZpZGVyIEREb1MgbWl0aWdhdGlvbiBwbGF0Zm9ybXMNCj4+ICogT3RoZXIgbmV0d29yayBk ZXZpY2VzL3BsYXRmb3JtcyB0aGF0IGFyZSBhYmxlIHRvIHNlbnNlIEREb1MgYW5kIA0KPj4gcmVz cG9uZA0KPiANCj4gU29tZXRoaW5nIGFsb25nIHRoZSBsaW5lcyBvZiDigJxPdGhlciBkZXZpY2Vz IHdpdGggbmV0d29yayBwZXJzcGVjdGl2ZSBwZXJmb3JtaW5nIHRyYWZmaWMgYW5hbHlzaXPigJ0g IG9yIOKAnOKApmVuZ2FnZWQgaW4gdHJhZmZpYyBhbmFseXNpc+KAnSBzaG91bGQgZW5jb21wYXNz IHRoaW5ncyBsaWtlIGZsb3cgbW9uaXRvcmluZyBhbmQgSURTL0lQUy4NCj4gDQo+PiAqIENoYWlu ZWQgaW5zdGFuY2VzIG9mIHRoZSBhYm92ZQ0KPj4gDQo+PiBUaGVzZSBlbGVtZW50cyBtYXkgYmUg Y29tbXVuaWNhdGluZyBpbnRlci1kb21haW4gb3IgaW50cmEtZG9tYWluIG92ZXIgDQo+PiBsaW5r cyB0aGF0IG1heSBiZSBjb25nZXN0ZWQgYnkgYXR0YWNrIHRyYWZmaWMgcmVzdWx0aW5nIGluIGhv c3RpbGUgDQo+PiBjb25kaXRpb25zIGZvciB0cmFkaXRpb25hbCBjb25uZWN0aW9uIG9yaWVudGVk IGFwcHJvYWNoZXMgYW5kIG1vcmUgDQo+PiBnZW5lcmFsaXplZCBzaWduYWxpbmcgYW5kIHRlbGVt ZXRyeSBzb2x1dGlvbnMuDQo+IA0KPiBTdHJpa2Ug4oCcdHJhZGl0aW9uYWzigJ0uIFJlZ2FyZGxl c3Mgb2YgaW5ub3ZhdGlvbiwgYSBjb25uZWN0aW9uLW9yaWVudGVkIHByb3RvY29sIGlzIG5vdCBh cHByb3ByaWF0ZSBmb3IgZG90cyBmb3IgdGhlIHJlYXNvbnMgeW914oCZdmUganVzdCBzdGF0ZWQu IEkgdGhpbmsgdGhpcyBjYW4gYmUgdGlnaHRlbmVkIHRvLCBlLmcuLCDigJzigKZob3N0aWxlIGNv bmRpdGlvbnMgZm9yIGNvbm5lY3Rpb24tb3JpZW50ZWQgc2lnbmFsaW5nIGFuZCB0ZWxlbWV0cnkg cHJvdG9jb2xzLuKAnQ0KPiANCj4+IFJvYnVzdG5lc3MgdW5kZXIgdGhlc2UNCj4+IGNvbmRpdGlv bnMgaXMgcGFyYW1vdW50IHdoaWxlIGVuc3VyaW5nIGFwcHJvcHJpYXRlIHJlZ2FyZCBmb3IgDQo+ PiBhdXRoZW50aWNhdGlvbiwgYXV0aG9yaXphdGlvbiwgcHJpdmFjeSBhbmQgZGF0YSBpbnRlZ3Jp dHkuICBFbGVtZW50cyANCj4+IG1heSBiZSBkZXBsb3llZCBhcyBwYXJ0IG9mIGEgd2lkZXIgc3Ry YXRlZ3kgaW5jb3Jwb3JhdGluZyBtdWx0aXBsZSANCj4+IHBvaW50cyBvZiBkZXRlY3Rpb24gYW5k IG1pdGlnYXRpb24sIGJvdGggb24gcHJlbWlzZSBvciBzZXJ2aWNlIHByb3ZpZGVyIGJhc2VkLg0K Pj4gU2hvdWxkIG1pdGlnYXRpb24gbmVlZCB0byBtb3ZlIGJldHdlZW4gZWxlbWVudHMgaW4gdGhl IGNoYWluIHRoZW4gDQo+PiBlZmZlY3RpdmUgc2lnbmFsaW5nIG9mIHRlbGVtZXRyeSBhbmQgY3Vy cmVudCB0aHJlYXQgaGFuZGxpbmcgaXMgZXNzZW50aWFsLg0KPiANCj4gSXMgdGhlIGltcGxpY2F0 aW9uIHRoYXQgYW4gb24tcHJlbWlzZSBkZXZpY2UgbWF5IHNpZ25hbCBsYXRlcmFsbHkgaW50ZW50 aW9uYWw/IE9yIGlzIHRoZSBleHBlY3RhdGlvbiB0aGF0IGVhY2ggc3Vic2VxdWVudCBlbGVtZW50 IGluIHRoZSBjaGFpbiB3aWxsIGJlIHVwc3RyZWFtIGZyb20gdGhlIHByZXZpb3VzPw0KPiANCj4+ IEZlZWRiYWNrIGJldHdlZW4gcGFydGljaXBhdGluZyBlbGVtZW50cyBpcyByZXF1aXJlZCBmb3Ig aW5jcmVhc2VkIA0KPj4gYXdhcmVuZXNzIGZvciBlZmZlY3RpdmUgZGVjaXNpb24gbWFraW5nLg0K Pj4gDQo+PiBUaGUgV0cgd2lsbCwgd2hlcmUgYXBwcm9wcmlhdGUsIHJldXNlIGV4aXN0aW5nIHN0 YW5kYXJkIHByb3RvY29scyBhbmQgDQo+PiBtZWNoYW5pc21zLCBmb3IgaW5zdGFuY2UgSVBGSVgg YW5kIGl0cyB0ZW1wbGF0aW5nIG1lY2hhbmlzbS4NCj4+IFRoZSBjaGFydGVyIG9mIHRoZSB3b3Jr aW5nIGdyb3VwIGlzIHRvIHByb2R1Y2Ugb25lIG9yIG1vcmUgc3RhbmRhcmRzIA0KPj4gdHJhY2sg c3BlY2lmaWNhdGlvbiB0byBwcm92aWRlIGZvciB0aGlzIG9wZW4gc2lnbmFsaW5nIGluIHRoZSBE RG9TIA0KPj4gcHJvYmxlbSBzcGFjZS4gIFdoaWxlIHRoZSByZXN1bHRpbmcgc3RhbmRhcmRzIHNo b3VsZCBiZSBkZXNpZ25lZCBzbyANCj4+IHRoYXQgdGhlcmXCuXMgYSBwb3NzaWJpbGl0eSBvZiBh cHBseWluZyB0aGVtIHRvIG5ldHdvcmsgc2VjdXJpdHkgDQo+PiBhcHBsaWNhdGlvbnMgYmV5b25k IEREb1MNCj4gDQo+IOKAnOKApmRlc2lnbmVkIHNvIHRoZXkgbWF5IGFwcGx5IHRvIG5ldHdvcmsg c2VjdXJpdHkgYXBwbGljYXRpb25z4oCmIg0KPiANCj4+IG1pdGlnYXRpb24sIHRoaXMgd29ya2lu ZyBncm91cCB3aWxsIGZvY3VzIG9uIGp1c3QgRERvUyBtaXRpZ2F0aW9uLg0KPiANCj4gU3RyaWtl IOKAnGp1c3TigJ0uDQo+IA0KPj4gVGhpcyBzdHJlYW1saW5lZCBmb2N1cyBvZiB0aGUgY2hhcnRl ciBpcyBpbnRlbmRlZCB0byBsZWFkIHRvIGFuIA0KPj4gZWFybGllciByZXN1bHQgZHVlIHRvIGNv bW11bml0eSBpbnRlcmVzdHMgaW4gaGF2aW5nIHN1Y2ggY2FwYWJpbGl0eSBpbiBhIHNob3J0IHRp bWVmcmFtZS4NCj4+IFRoZSBzcGVjaWZpY2F0aW9uKHMpIHByb2R1Y2VkIGJ5IHRoZSBXRyB3aWxs IGluY2x1ZGUgYSBzdGFuZGFyZCANCj4+IG1lY2hhbmlzbSBmb3IgYXV0aGVudGljYXRpb24gYW5k IGF1dGhvcml6YXRpb24sIGZvciBkYXRhIGludGVncml0eSwgDQo+PiBhbmQgZm9yIHByb3ZpZGlu ZyBmb3IgcHJpdmFjeSBpbiBvcGVyYXRpb24uDQo+PiANCj4+IFRoZSBXRyB3aWxsIHByb2R1Y2Ug dGhlIGZvbGxvd2luZyBkZWxpdmVyYWJsZXM6DQo+PiANCj4+ICogVXNlIGNhc2UgZG9jdW1lbnQg dG8gZW5zdXJlIGNvbW1vbmFsaXR5IG9mIHRoZSB3b3JrIGFtb25nIHRoZSANCj4+IHBhcnRpY2lw YW50cyBpbiB0aGUgV29ya2luZyBHcm91cC4gIFRoaXMgZG9jdW1lbnQgbWF5IGJlIGRldGVybWlu ZWQgDQo+PiBieSB0aGUgd29ya2luZyBncm91cCB0byByZW1haW4gaW5mb3JtYWwgYW5kIG5vdCBi ZSBwdWJsaXNoZWQuDQo+PiAqIERvY3VtZW50IG9yIERvY3VtZW50cyBkZXNjcmliaW5nIHRoZSBw cm9ibGVtIHNwYWNlLCB1c2UgY2FzZXMsIA0KPj4gcHJvdG9jb2wgcmVxdWlyZW1lbnRzIGFuZCBv dGhlciBxdWFsaWZ5aW5nIGluZm9ybWF0aW9uIGFzIHRoZSBXRyBzZWVzIGZpdC4NCj4+ICogRG9j dW1lbnQgb3IgRG9jdW1lbnRzIHNwZWNpZnlpbmcgYSBwcm90b2NvbCBhbmQgYXNzb2NpYXRlZCBk YXRhIA0KPj4gbW9kZWxzIHRvIGFkZHJlc3MgdGhlIFdHIHN0YXRlZCBnb2FsLg0KPiANCj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gRG90cyBtYWls aW5nIGxpc3QNCj4gRG90c0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2RvdHMNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCkRvdHMgbWFpbGluZyBsaXN0DQpEb3RzQGlldGYub3JnDQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RvdHMNCg== From nobody Tue May 12 20:55:38 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@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: [Dots] [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93 X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." 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 08:13:52 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED0D11B2D38 for ; Wed, 13 May 2015 08:13:50 -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 G8ksIT6QQp5E for ; Wed, 13 May 2015 08:13:43 -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 4E4991B2D29 for ; Wed, 13 May 2015 08:13:42 -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 BSM42539; Wed, 13 May 2015 15:13:41 +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, 13 May 2015 16:13:40 +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, 13 May 2015 08:13:35 -0700 From: Linda Dunbar To: Scott Barvick , Kathleen Moriarty Thread-Topic: [Dots] Draft Charter Thread-Index: AQHQfE+l/Sly82ObQkmwTXHnIFPOXJ1ZfxCAgAAiHMCAAZWkgIAdz1+wgACfzwCAAAo1AIAAc5Gw Date: Wed, 13 May 2015 15:13:35 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657C14362@dfweml701-chm> References: <1C8B68F6-75A6-4869-B03A-7DCFD0092437@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F657C090E5@dfweml701-chm> <4A95BA014132FF49AE685FAB4B9F17F657C13F96@dfweml701-chm> <35115B22-1A8D-4697-B151-6043A949E28C@corero.com> In-Reply-To: <35115B22-1A8D-4697-B151-6043A949E28C@corero.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: Nik Teague , "Adam W. Montville" , "dots@ietf.org" Subject: Re: [Dots] Draft Charter X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 15:13:51 -0000 If everyone agrees, it is fine with me.=20 I just wanted to emphasize that packet loss happens even without security a= ttacks, with connection oriented or connectionless oriented path.=20 I.e. Events/data exchanges among DDoS devices have to consider mechanism to= mitigate packet loss.=20 Linda -----Original Message----- From: Scott Barvick [mailto:Scott.Barvick@corero.com]=20 Sent: Tuesday, May 12, 2015 8:11 PM To: Kathleen Moriarty Cc: Linda Dunbar; Adam W. Montville; Nik Teague; dots@ietf.org Subject: Re: [Dots] Draft Charter I don't think that the original implies that the elements need to determine= congestion status nor ensure zero packet loss, just be robust and secure i= n the face of them. I also agree that the new suggestion is functionally = equivalent so I think we should stick with the current proposal because it = makes the important point that this work is not covered by existing or othe= r proposed efforts. Scott On May 12, 2015, at 8:34 PM, Kathleen Moriarty wrote: > Interesting. I read the current text with the intent of your proposed te= xt, but if others read it differently, adjustments may be helpful. I do li= ke the wording of the original, so maybe it could be tweaked a bit to make = sure Linda's point is clear? >=20 > Thanks, > Kathleen > (No hat) >=20 > Sent from my iPhone >=20 >> On May 12, 2015, at 6:14 PM, Linda Dunbar wrot= e: >>=20 >> I support the charter, with some suggestion on the wording: >>=20 >> Since it is not within DOTS scope to figure out "congestion status" of t= he links/paths nor ensure zero packet loss, the charter should simply say: >>=20 >> "These elements may be communicating over congested links/paths, with po= ssibility of packets loss. Therefore, mechanisms have be considered to com= pensate packets loss to ensure appropriate regard for authentication, autho= rization, privacy and data integrity."=20 >>=20 >> Instead of the following wording: >>>> These elements may be communicating inter-domain or intra-domain=20 >>>> over links/path that may be congested by attack traffic resulting=20 >>>> in hostile conditions for traditional connection oriented=20 >>>> approaches and more generalized signaling and telemetry solutions. =20 >>>> Robustness under these conditions is paramount while ensuring=20 >>>> appropriate regard for authentication, authorization, privacy and data= integrity. >>=20 >> Linda Dunbar >>=20 >> -----Original Message----- >> From: Scott Barvick [mailto:Scott.Barvick@corero.com] >> Sent: Thursday, April 23, 2015 10:49 AM >> To: Linda Dunbar; Adam W. Montville; Teague, Nik >> Cc: dots@ietf.org >> Subject: Re: [Dots] Draft Charter >>=20 >> Linda, >>=20 >> If I understand your questions, IMO the answer to both of them is no, b= ut we do need to clarify. >>=20 >> 1) "ensure . congestion status" - Under a big DDoS attack, the inboun= d >> link to the DDoS device may be so saturated that 'traditional methods. s= olutions" will not work because they most likely utilize 2 way >> (connection-oriented) traffic. If the inbound link is saturated, we >> might only be able to "reliably" get the situation signaled through a co= nnectionless protocol that counts on repetition and statistical likelihood = for success. So, I don't think we can ensure congestion status (other than= designing for congestion:). >>=20 >> 2) "ensure secure channels" . The channel is not dedicated so the >> protocol needs to do the right thing, as the charter says about ". Appro= priate regard for . data integrity". If my channel, you mean the logical c= hannel between the devices, then, yes, I think we have to address that. >>=20 >> 3) At least in the first round, I don't see us having the DDoS elements >> trying to figure out optimal paths between the devices. The DDoS devic= es >> signal, the upstream receivers take action, and the routing/rerouting ha= ppens around the DDoS devices. >>=20 >> Regards, >> Scott >>=20 >>=20 >>> On 4/22/15, 6:47 PM, "Linda Dunbar" wrote: >>>=20 >>> I have a few questions on the DOTS scope: >>>=20 >>> on the this paragraph: >>>=20 >>>> These elements may be communicating inter-domain or intra-domain=20 >>>> over links that may be congested by attack traffic resulting in=20 >>>> hostile conditions for traditional connection oriented approaches=20 >>>> and more generalized signaling and telemetry solutions. Robustness=20 >>>> under these conditions is paramount while ensuring appropriate=20 >>>> regard for authentication, authorization, privacy and data integrity. >>>=20 >>> Is it the goal of the DOTS group to ensure the secure channels and=20 >>> congestion status for paths between the On-premise DDoS mitigation=20 >>> platforms and the Service provider DDoS mitigation platforms? >>>=20 >>> Is it in the scope for DDOS elements to communicate with Network=20 >>> Management system to figure out an optimal path between the DDOS=20 >>> elements? >>>=20 >>> Linda >>>=20 >>> -----Original Message----- >>> From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Adam W.=20 >>> Montville >>> Sent: Wednesday, April 22, 2015 8:35 AM >>> To: Teague, Nik >>> Cc: dots@ietf.org >>> Subject: Re: [Dots] Draft Charter >>>=20 >>> Well-written, Nik. I spotted a couple of minor nits (there may be=20 >>> others), and have a couple of observations/comments - all inline. >>>=20 >>>> On Apr 21, 2015, at 11:24 AM, Teague, Nik wrote= : >>>>=20 >>>> Hi, >>>>=20 >>>> Please see a 1st pass draft charter below - comments and feedback=20 >>>> always welcome. >>>>=20 >>>> -Nik >>>>=20 >>>>=20 >>>> The aim of DDoS Open Threat Signaling (DOTS) is to develop a=20 >>>> standards based approach to the real time signaling of DDoS=20 >>>> related telemetry and threat handling data between elements=20 >>>> concerned with attack mitigation. >>>>=20 >>>> The elements may be described as: >>>> * On-premise DDoS mitigation platforms >>>> * Service provider DDoS mitigation platforms >>>> * Other network devices/platforms that are able to sense DDoS and=20 >>>> respond >>>> * Chained instances of the above >>>=20 >>> The first two points seem pretty tight, but the third bullet seems=20 >>> less so. As a reader, it feels that you may have wanted to write=20 >>> something like "Other DDoS mitigation platforms", but didn't for=20 >>> what is likely an important reason. Maybe another way to look at it=20 >>> is that the first two bullets seem to be distinguished based on=20 >>> mitigation platform location, but the third is a catch-all not necessar= ily related to location. >>>=20 >>> This isn't a suggestion to change, but an observation you might=20 >>> choose to consider to clarify your meaning. >>>=20 >>>> These elements may be communicating inter-domain or intra-domain=20 >>>> over links that may be congested by attack traffic resulting in=20 >>>> hostile conditions for traditional connection oriented approaches=20 >>>> and more generalized signaling and telemetry solutions. Robustness=20 >>>> under these conditions is paramount while ensuring appropriate=20 >>>> regard for authentication, authorization, privacy and data=20 >>>> integrity. Elements may be deployed as part of a wider strategy=20 >>>> incorporating multiple points of detection and mitigation, both on=20 >>>> premise or service provider based. >>>> Should mitigation need to move between elements in the chain then=20 >>>> effective signaling of telemetry and current threat handling is=20 >>>> essential. >>>=20 >>> Consider a comma between "chain" and "then" resulting in: "Should=20 >>> mitigation need to move between elements in the chain, then." >>>=20 >>>> Feedback between participating elements is required for increased=20 >>>> awareness for effective decision making. >>>=20 >>> Could this be ".required for increased awareness supporting=20 >>> effective decision making"? >>>=20 >>>>=20 >>>> The WG will, where appropriate, reuse existing standard protocols=20 >>>> and mechanisms, for instance IPFIX and its templating mechanism. >>>=20 >>> Would it be helpful to also say that you intend (if you do) to=20 >>> coordinate efforts with other working groups that may be working on=20 >>> similar problems? Consider i2nsf, supa, sacm, and mile. Some of=20 >>> these have standards you might leverage, but others are still working o= n solutions. >>> In sacm, for example, we are working to define models and protocols=20 >>> based on endpoint posture assessment, which includes some expression=20 >>> of policy, endpoint attributes, and so on. Pieces of these things=20 >>> may be useful to dots. >>>=20 >>>=20 >>>>=20 >>>> The charter of the working group is to produce one or more=20 >>>> standards track specification to provide for this open signaling in=20 >>>> the DDoS problem space. >>>=20 >>> Make "specification" plural, so that the sentence reads: ".to=20 >>> produce one or more standards track specifications.". >>>=20 >>>> While the resulting standards should be designed so that there=B9s a=20 >>>> possibility of applying them to network security applications=20 >>>> beyond DDoS mitigation, this working group will focus on just DDoS mit= igation. >>>=20 >>> The ' in "there's" came up funny (probably a copy/paste issue). >>>=20 >>>> This >>>> streamlined focus of the charter is intended to lead to an earlier=20 >>>> result due to community interests in having such capability in a=20 >>>> short timeframe. >>>> The specification(s) produced by the WG will include a standard=20 >>>> mechanism for authentication and authorization, for data integrity,=20 >>>> and for providing for privacy in operation. >>>>=20 >>>> The WG will produce the following deliverables: >>>>=20 >>>> * Use case document to ensure commonality of the work among the=20 >>>> participants in the Working Group. This document may be determined=20 >>>> by the working group to remain informal and not be published. >>>> * Document or Documents describing the problem space, use cases,=20 >>>> protocol requirements and other qualifying information as the WG=20 >>>> sees fit. >>>> * Document or Documents specifying a protocol and associated data=20 >>>> models to address the WG stated goal. >>>=20 >>> Something we recently did in sacm is to create a milestone for=20 >>> revisiting milestones. The idea is that we know we're going to have=20 >>> some data models and protocols, but we're not sure how many or how=20 >>> they might be divided among multiple drafts. Something like that=20 >>> could be useful here as well, because it is clear that you will have=20 >>> models and protocols, but it's not clear how that work will ultimately = materialize. >>>=20 >>> It might be too early, but do you have any idea as to dates for=20 >>> these milestones? >>>=20 >>>>=20 >>>> _______________________________________________ >>>> Dots mailing list >>>> Dots@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dots >>>=20 >>> _______________________________________________ >>> Dots mailing list >>> Dots@ietf.org >>> https://www.ietf.org/mailman/listinfo/dots >>>=20 >>> _______________________________________________ >>> Dots mailing list >>> Dots@ietf.org >>> https://www.ietf.org/mailman/listinfo/dots >>=20 >> _______________________________________________ >> Dots mailing list >> Dots@ietf.org >> https://www.ietf.org/mailman/listinfo/dots From nobody Wed May 13 09:26:46 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@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: [Dots] 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 X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." 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:31 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@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: [Dots] [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93 X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 16:31:25 -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:26:41 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@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: X-Mailman-Approved-At: Wed, 13 May 2015 10:26:40 -0700 Cc: "i2rs@ietf.org" , "dots@ietf.org" , "netmod@ietf.org" Subject: Re: [Dots] [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93 X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." 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 15:06:56 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@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 15:06:55 -0700 Cc: "i2rs@ietf.org" , "netmod@ietf.org" , "i2nsf@ietf.org" , "dots@ietf.org" , Linda Dunbar , Kathleen Moriarty Subject: Re: [Dots] [netmod] [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93 X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." 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 Fri May 15 05:58:55 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99F311A8029 for ; Fri, 15 May 2015 05:58:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.21 X-Spam-Level: X-Spam-Status: No, score=-99.21 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, 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 iZF36cl5MDlv for ; Fri, 15 May 2015 05:58:52 -0700 (PDT) Received: from mail.tcb.net (mail.tcb.net [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id 8E03B1A1BED for ; Fri, 15 May 2015 05:58:06 -0700 (PDT) Received: from dspam (unknown [127.0.0.1]) by mail.tcb.net (Postfix) with SMTP id 1B837300348 for ; Fri, 15 May 2015 12:58:06 +0000 (UTC) Received: from mail2.tcb.net (localhost [127.0.0.1]) by mail.tcb.net (Postfix) with ESMTP id ECC5F300347 for ; Fri, 15 May 2015 06:58:05 -0600 (MDT) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_40ced50884aa9eb85d849d27956673a2" Date: Fri, 15 May 2015 06:58:05 -0600 From: Danny McPherson To: In-Reply-To: References: <1C8B68F6-75A6-4869-B03A-7DCFD0092437@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F657C090E5@dfweml701-chm> <4A95BA014132FF49AE685FAB4B9F17F657C13F96@dfweml701-chm> Message-ID: X-Sender: danny@tcb.net User-Agent: Roundcube Webmail/0.8.2 X-DSPAM-Result: Innocent X-DSPAM-Processed: Fri May 15 06:58:06 2015 X-DSPAM-Confidence: 1.0000 X-DSPAM-Improbability: 1 in 98689409 chance of being spam X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 5555ed5e8678713368349 X-DSPAM-Factors: 27, it+differently, 0.40000, it+differently, 0.40000, current+#+and, 0.40000, current+#+and, 0.40000, addressing+#+point, 0.40000, addressing+#+point, 0.40000, be+#+a, 0.40000, be+#+a, 0.40000, precisely+#+#+#+I, 0.40000, precisely+#+#+#+I, 0.40000, the+#+#+as, 0.40000, the+#+#+as, 0.40000, Subject*Re+#+#+Charter, 0.40000, charter+as, 0.40000, charter+as, 0.40000, Moriarty+#+#+I, 0.40000, Moriarty+#+#+I, 0.40000, but+if, 0.40000, but+if, 0.40000, Moriarty+#+#+#+read, 0.40000, Moriarty+#+#+#+read, 0.40000, be+helpful, 0.40000, be+helpful, 0.40000, do+#+the, 0.40000, do+#+the, 0.40000, robustness+#+#+#+precisely, 0.40000, robustness+#+#+#+precisely, 0.40000 Archived-At: Subject: Re: [Dots] Draft Charter X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2015 12:58:53 -0000 --=_40ced50884aa9eb85d849d27956673a2 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=UTF-8 On 2015-05-12 18:34, Kathleen Moriarty wrote: > Interesting. I read the current text with the intent of your proposed text, but if others read it differently, adjustments may be helpful. I do like the wording of the original, so maybe it could be tweaked a bit to make sure Linda's point is clear? I believe the current text and discussion around robustness and congestion is precisely addressing Linda's point. I support the current charter as well. -danny --=_40ced50884aa9eb85d849d27956673a2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

On 2015-05-12 18:34, Kathleen Moriarty wrote:

> Interesting.  I read the current text with the intent of your pro=
posed text, but if others read it differently, adjustments may be helpful=
=2E  I do like the wording of the original, so maybe it could be tweaked a =
bit to make sure Linda's point is clear?


I believe the cur=
rent text and discussion around robustness and congestion is precisely addr=
essing Linda's point.  

I support the current charter as well.
-danny
 
--=_40ced50884aa9eb85d849d27956673a2-- From nobody Sat May 16 19:26:11 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A4391A88C9 for ; Sat, 16 May 2015 19:26:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 fgS-chrS_vAn for ; Sat, 16 May 2015 19:26:07 -0700 (PDT) Received: from plainfield.sei.cmu.edu (plainfield.sei.cmu.edu [192.58.107.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE6491A884E for ; Sat, 16 May 2015 19:26:06 -0700 (PDT) Received: from timber.sei.cmu.edu (timber.sei.cmu.edu [10.64.21.23]) by plainfield.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id t4H2Q5bb013078 for ; Sat, 16 May 2015 22:26:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1431829565; bh=Wn8joJhZnLKyj6FxrKs0xMMAD468gwxRQyr8dBlgXk0=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version:Sender:Reply-To:Cc: In-Reply-To:References; b=mYnGwwlPRFKlqjNlBw8hOgSdp3KiB1XnrVzCWlzBCO1XrPBLBf9m7LDs4KuXV1hG3 ox6FbzP8HugIMhzGOduy2IVksGDHjK/QNRAcXorfr0GYeiYFLJVOP8ACKQcvefUB1s raoJkjnT5DAfGIXI+XK4RMVoELfcu+35Dhp/nFa0= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by timber.sei.cmu.edu (8.14.4/8.14.4/1456) with ESMTP id t4H2Q2j1016536 for ; Sat, 16 May 2015 22:26:02 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0210.002; Sat, 16 May 2015 22:26:01 -0400 From: "Roman D. Danyliw" To: "dots@ietf.org" Thread-Topic: Consolidation of all draft charter feedback Thread-Index: AdCQRqxKc0cQVxSCQYyh/0Eeuj4KmQ== Date: Sun, 17 May 2015 02:26:01 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFCD9441477@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Dots] Consolidation of all draft charter feedback X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2015 02:26:09 -0000 Hello! There has been robust discussion on the draft charter text (http://www.ietf= .org/mail-archive/web/dots/current/msg00077.html). To make it easier to re= view the draft charter with the benefit of previous feedback, below you can= find a summary of all comments to date aggregated inline with correspondin= g links. =20 Per Kathleen Moriarty's request (http://www.ietf.org/mail-archive/web/dots/= current/msg00074.html), please provide further commentary or statements of = support. Roman ----[ Aggregated comments on the draft charter ]---- > The aim of DDoS Open Threat Signaling (DOTS) is to develop a standards > based approach to the real time signaling of DDoS related telemetry and [Andrew Mortensen] suggested that "real time" signaling is expected under a= ttack conditions, and that this detail should be noted explicitly in http:/= /www.ietf.org/mail-archive/web/dots/current/msg00086.html > threat handling data between elements concerned with attack mitigation. >=20 > The elements may be described as: > * On-premise DDoS mitigation platforms > * Service provider DDoS mitigation platforms > * Other network devices/platforms that are able to sense DDoS and respond [Adam Montville] suggested to tighten up the language of this third bullet = in http://www.ietf.org/mail-archive/web/dots/current/msg00080.html -- [Nik Teague] proposed to the following text in response to Adam: "While the resulting standards should be designed so that there=B9s a possibility of applying them to network security applications beyond DDoS mitigation, this working group will focus on just DDoS mitigation.=B2 in http://www.ietf.org/mail-archive/web/dots/current/msg00083.html -- [Xialiang (Frank)] Recommended leaving the third bullet vague pending a rev= iew of the use cases in http://www.ietf.org/mail-archive/web/dots/current/msg00085.html -- [Andrew Mortensen] suggested "Other devices with network perspective perfor= ming traffic analysis" or ".engaged in traffic analysis" > * Chained instances of the above >=20 > These elements may be communicating inter-domain or intra-domain over > links that may be congested by attack traffic resulting in hostile condit= ions for > traditional connection oriented approaches and more generalized signaling [Andrew Mortensen] suggested removing "traditional" in http://www.ietf.org/= mail-archive/web/dots/current/msg00086.html > and telemetry solutions. Robustness under these conditions is paramount > while ensuring appropriate regard for authentication, authorization, priv= acy > and data integrity. Elements may be deployed as part of a wider strategy > incorporating multiple points of detection and mitigation, both on premis= e or > service provider based. > Should mitigation need to move between elements in the chain then [Adam Montville] suggested a comma between "chain" and "then" resulting in:= "Should mitigation need to move between elements in the chain, then." in h= ttp://www.ietf.org/mail-archive/web/dots/current/msg00080.html -- [Linda Dunbar] sought clarity on whether the following items were in scope: * determining the optimal path between DDOS elements determined in concert = with the Network Management system * ensuring the secure channels and congestion status for paths between the = mitigating devices In http://www.ietf.org/mail-archive/web/dots/current/msg00081.html -- [Scott Barvick] replied to [Linda Dunbar] on this scope in http://www.ietf.= org/mail-archive/web/dots/current/msg00082.html -- [Andrew Mo ] sought clarity on whether "... an on-premise device may signal= laterally intentional? Or is the expectation that each subsequent element = in the chain will be upstream from the previous?" in http://www.ietf.org/ma= il-archive/web/dots/current/msg00086.html -- [Linda Dunbar] suggested updated text that reads as "These elements may be = communicating over congested links/paths, with possibility of packets loss.= Therefore, mechanisms have be considered to compensate packets loss to en= sure appropriate regard for authentication, authorization, privacy and data= integrity." In http://www.ietf.org/mail-archive/web/dots/current/msg00102.= html -- [Scott Barvick] in http://www.ietf.org/mail-archive/web/dots/current/msg001= 04.html and [Kathleen Moriarty] in http://www.ietf.org/mail-archive/web/dot= s/current/msg00103.html believe the existing language covers [Linda Dunbar]= 's proposal. > effective signaling of telemetry and current threat handling is essential= . > Feedback between participating elements is required for increased > awareness for effective decision making. [Adam Montville] suggested ".required for increased awareness supporting e= ffective decision making" in http://www.ietf.org/mail-archive/web/dots/curr= ent/msg00080.html -- [Xialiang (Frank)] suggested "Feedback and initial capability negotiation m= echanisms between participating elements is required for increased awarenes= s for effective decision making." in http://www.ietf.org/mail-archive/web/d= ots/current/msg00085.html > The WG will, where appropriate, reuse existing standard protocols and > mechanisms, for instance IPFIX and its templating mechanism. [Adam Montville] suggested mentioning other working groups in=20 http://www.ietf.org/mail-archive/web/dots/current/msg00080.html -- [Andrew ] highlighted the inherent conflict between reusing IPFIX (stated h= ere) and the limitation of "traditional connection oriented protocols" (sta= ted above in the chart) in http://www.ietf.org/mail-archive/web/dots/curren= t/msg00098.html > The charter of the working group is to produce one or more standards trac= k > specification to provide for this open signaling in the DDoS problem spac= e. [Adam Montville] suggested making "specification" plural, so that the sente= nce reads: ".to produce one or more standards track specifications." in htt= p://www.ietf.org/mail-archive/web/dots/current/msg00080.html > While the resulting standards should be designed so that there=B9s a poss= ibility > of applying them to network security applications beyond DDoS mitigation, [Andrew Mortensen] suggested using ".designed so they may apply to network = security applications." in http://www.ietf.org/mail-archive/web/dots/curren= t/msg00086.html > this working group will focus on just DDoS mitigation. This streamlined = focus [Andrew Mortensen] suggested removing "just" in http://www.ietf.org/mail-ar= chive/web/dots/current/msg00086.html > of the charter is intended to lead to an earlier result due to community > interests in having such capability in a short timeframe. > The specification(s) produced by the WG will include a standard mechanis= m > for authentication and authorization, for data integrity, and for providi= ng for > privacy in operation. >=20 > The WG will produce the following deliverables: >=20 > * Use case document to ensure commonality of the work among the > participants in the Working Group. This document may be determined by > the working group to remain informal and not be published. > * Document or Documents describing the problem space, use cases, protocol > requirements and other qualifying information as the WG sees fit. > * Document or Documents specifying a protocol and associated data models > to address the WG stated goal. [Adam Montville] suggested adding a milestone to review milestones and spec= ific dates for these in=20 http://www.ietf.org/mail-archive/web/dots/current/msg00080.html > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Tue May 19 07:21:07 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E629A1B2FD4 for ; Tue, 19 May 2015 07:21:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.302 X-Spam-Level: X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, 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 rrFERpAsvXxn for ; Tue, 19 May 2015 07:21:00 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BB4E1B304F for ; Tue, 19 May 2015 07:13:49 -0700 (PDT) X-AuditID: c6180641-f79086d000001909-aa-555ae058587d Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 69.D2.06409.850EA555; Tue, 19 May 2015 09:03:53 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0210.002; Tue, 19 May 2015 10:13:47 -0400 From: Daniel Migault To: "Roman D. Danyliw" , "dots@ietf.org" Thread-Topic: Consolidation of all draft charter feedback Thread-Index: AdCQRqxKc0cQVxSCQYyh/0Eeuj4KmQB9vAJQ Date: Tue, 19 May 2015 14:13:46 +0000 Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C161F7E8@eusaamb107.ericsson.se> References: <359EC4B99E040048A7131E0F4E113AFCD9441477@marathon> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFCD9441477@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrELMWRmVeSWpSXmKPExsUyuXRPuG7kg6hQg4tPBCzWvjnCavG5jc2B yWPGBh+PJUt+MgUwRXHZpKTmZJalFunbJXBlfD/ZwlZwza3izqO5zA2MB6y7GDk5JARMJLr3 T2WEsMUkLtxbz9bFyMUhJHCUUaJny0koZzmjRNvReSwgVWwCRhJth/rZQWwRATeJxoMXmEFs YQELiZbrE1kg4pYSa97dY4KwjSTmP7sFtoFFQFXi+O3NYPW8At4Sy3adYe1i5ABaYC/R8V4D JMwp4CCxeFcvWAkj0EHfT60BG8MsIC5x68l8JohDBSSW7DnPDGGLSrx8/I8VwlaU2Nc/nR2i Xk/ixtQpbBC2tsSyha+h1gpKnJz5hGUCo+gsJGNnIWmZhaRlFpKWBYwsqxg5SotTy3LTjQw3 MQIj4ZgEm+MOxgWfLA8xCnAwKvHwLtCIChViTSwrrsw9xCjNwaIkzntRNSRUSCA9sSQ1OzW1 ILUovqg0J7X4ECMTB6dUA2Pq+ycfdrPbRh6QshbrTVXzOvVfsi9W+uL9Y9wPfZcuu3EwbPll 9rUtSYea9//amL9XJHNy88aGx5OLTHwTKrXTokQ0fbQtNuTETeh7Eab5Vtsv4euuzdO41Bwt 8zbNYZp0M8/D6/Xe/LVcZV89k0SWnjH7XfpL/WMvW+it9zlRS4MMHO5ViiuxFGckGmoxFxUn AgB38bhkZQIAAA== Archived-At: Subject: Re: [Dots] Consolidation of all draft charter feedback X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 14:21:05 -0000 Hi,=20 I suggest to remove the first milestone item: OLD > * Use case document to ensure commonality of the work among the=20 > participants in the Working Group. This document may be determined by=20 > the working group to remain informal and not be published. > * Document or Documents describing the problem space, use cases,=20 > protocol requirements and other qualifying information as the WG sees fit= . > * Document or Documents specifying a protocol and associated data=20 > models to address the WG stated goal. NEW > * Document or Documents describing the problem space, use cases,=20 > protocol requirements and other qualifying information as the WG sees fit= . > * Document or Documents specifying a protocol and associated data=20 > models to address the WG stated goal. BR,=20 Daniel -----Original Message----- From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Roman D. Danyliw Sent: Saturday, May 16, 2015 10:26 PM To: dots@ietf.org Subject: [Dots] Consolidation of all draft charter feedback Hello! There has been robust discussion on the draft charter text (http://www.ietf= .org/mail-archive/web/dots/current/msg00077.html). To make it easier to re= view the draft charter with the benefit of previous feedback, below you can= find a summary of all comments to date aggregated inline with correspondin= g links. =20 Per Kathleen Moriarty's request (http://www.ietf.org/mail-archive/web/dots/= current/msg00074.html), please provide further commentary or statements of = support. Roman ----[ Aggregated comments on the draft charter ]---- > The aim of DDoS Open Threat Signaling (DOTS) is to develop a standards=20 > based approach to the real time signaling of DDoS related telemetry=20 > and [Andrew Mortensen] suggested that "real time" signaling is expected under a= ttack conditions, and that this detail should be noted explicitly in http:/= /www.ietf.org/mail-archive/web/dots/current/msg00086.html > threat handling data between elements concerned with attack mitigation. >=20 > The elements may be described as: > * On-premise DDoS mitigation platforms > * Service provider DDoS mitigation platforms > * Other network devices/platforms that are able to sense DDoS and=20 > respond [Adam Montville] suggested to tighten up the language of this third bullet = in http://www.ietf.org/mail-archive/web/dots/current/msg00080.html -- [Nik Teague] proposed to the following text in response to Adam: "While the resulting standards should be designed so that there=B9s a possi= bility of applying them to network security applications beyond DDoS mitiga= tion, this working group will focus on just DDoS mitigation.=B2 in http://www.ietf.org/mail-archive/web/dots/current/msg00083.html -- [Xialiang (Frank)] Recommended leaving the third bullet vague pending a rev= iew of the use cases in http://www.ietf.org/mail-archive/web/dots/current/m= sg00085.html -- [Andrew Mortensen] suggested "Other devices with network perspective perfor= ming traffic analysis" or ".engaged in traffic analysis" > * Chained instances of the above >=20 > These elements may be communicating inter-domain or intra-domain over=20 > links that may be congested by attack traffic resulting in hostile=20 > conditions for traditional connection oriented approaches and more=20 > generalized signaling [Andrew Mortensen] suggested removing "traditional" in http://www.ietf.org/= mail-archive/web/dots/current/msg00086.html > and telemetry solutions. Robustness under these conditions is=20 > paramount while ensuring appropriate regard for authentication,=20 > authorization, privacy and data integrity. Elements may be deployed=20 > as part of a wider strategy incorporating multiple points of detection=20 > and mitigation, both on premise or service provider based. > Should mitigation need to move between elements in the chain then [Adam Montville] suggested a comma between "chain" and "then" resulting in:= "Should mitigation need to move between elements in the chain, then." in h= ttp://www.ietf.org/mail-archive/web/dots/current/msg00080.html -- [Linda Dunbar] sought clarity on whether the following items were in scope: * determining the optimal path between DDOS elements determined in concert = with the Network Management system * ensuring the secure channels and congestion status for paths between the = mitigating devices In http://www.ietf.org/mail-archive/web/dots/current/msg00081.html -- [Scott Barvick] replied to [Linda Dunbar] on this scope in http://www.ietf.= org/mail-archive/web/dots/current/msg00082.html -- [Andrew Mo ] sought clarity on whether "... an on-premise device may signal= laterally intentional? Or is the expectation that each subsequent element = in the chain will be upstream from the previous?" in http://www.ietf.org/ma= il-archive/web/dots/current/msg00086.html -- [Linda Dunbar] suggested updated text that reads as "These elements may be = communicating over congested links/paths, with possibility of packets loss.= Therefore, mechanisms have be considered to compensate packets loss to en= sure appropriate regard for authentication, authorization, privacy and data= integrity." In http://www.ietf.org/mail-archive/web/dots/current/msg00102.= html -- [Scott Barvick] in http://www.ietf.org/mail-archive/web/dots/current/msg001= 04.html and [Kathleen Moriarty] in http://www.ietf.org/mail-archive/web/dot= s/current/msg00103.html believe the existing language covers [Linda Dunbar]= 's proposal. > effective signaling of telemetry and current threat handling is essential= . > Feedback between participating elements is required for increased=20 > awareness for effective decision making. [Adam Montville] suggested ".required for increased awareness supporting e= ffective decision making" in http://www.ietf.org/mail-archive/web/dots/curr= ent/msg00080.html -- [Xialiang (Frank)] suggested "Feedback and initial capability negotiation m= echanisms between participating elements is required for increased awarenes= s for effective decision making." in http://www.ietf.org/mail-archive/web/d= ots/current/msg00085.html > The WG will, where appropriate, reuse existing standard protocols and=20 > mechanisms, for instance IPFIX and its templating mechanism. [Adam Montville] suggested mentioning other working groups in http://www.ie= tf.org/mail-archive/web/dots/current/msg00080.html -- [Andrew ] highlighted the inherent conflict between reusing IPFIX (stated h= ere) and the limitation of "traditional connection oriented protocols" (sta= ted above in the chart) in http://www.ietf.org/mail-archive/web/dots/curren= t/msg00098.html > The charter of the working group is to produce one or more standards=20 > track specification to provide for this open signaling in the DDoS proble= m space. [Adam Montville] suggested making "specification" plural, so that the sente= nce reads: ".to produce one or more standards track specifications." in htt= p://www.ietf.org/mail-archive/web/dots/current/msg00080.html > While the resulting standards should be designed so that there=B9s a=20 > possibility of applying them to network security applications beyond=20 > DDoS mitigation, [Andrew Mortensen] suggested using ".designed so they may apply to network = security applications." in http://www.ietf.org/mail-archive/web/dots/curren= t/msg00086.html > this working group will focus on just DDoS mitigation. This=20 > streamlined focus [Andrew Mortensen] suggested removing "just" in http://www.ietf.org/mail-ar= chive/web/dots/current/msg00086.html > of the charter is intended to lead to an earlier result due to=20 > community interests in having such capability in a short timeframe. > The specification(s) produced by the WG will include a standard=20 > mechanism for authentication and authorization, for data integrity,=20 > and for providing for privacy in operation. >=20 > The WG will produce the following deliverables: >=20 > * Use case document to ensure commonality of the work among the=20 > participants in the Working Group. This document may be determined by=20 > the working group to remain informal and not be published. > * Document or Documents describing the problem space, use cases,=20 > protocol requirements and other qualifying information as the WG sees fit= . > * Document or Documents specifying a protocol and associated data=20 > models to address the WG stated goal. [Adam Montville] suggested adding a milestone to review milestones and spec= ific dates for these in http://www.ietf.org/mail-archive/web/dots/current/m= sg00080.html > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots From nobody Tue May 19 13:31:12 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 568761A88F2 for ; Tue, 19 May 2015 13:31:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_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 AWT6iJaaaEYr for ; Tue, 19 May 2015 13:31:07 -0700 (PDT) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.199]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C20B1A8AD1 for ; Tue, 19 May 2015 13:31:05 -0700 (PDT) Received: from [216.82.242.179] by server-7.bemta-8.messagelabs.com id 08/F5-03199-88D9B555; Tue, 19 May 2015 20:31:04 +0000 X-Env-Sender: Scott.Barvick@corero.com X-Msg-Ref: server-3.tower-86.messagelabs.com!1432067314!50514622!1 X-Originating-IP: [71.184.227.49] X-StarScan-Received: X-StarScan-Version: 6.13.15; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31254 invoked from network); 19 May 2015 20:28:35 -0000 Received: from mercury.corero.com (HELO MERCURY.corero.com) (71.184.227.49) by server-3.tower-86.messagelabs.com with AES128-SHA encrypted SMTP; 19 May 2015 20:28:35 -0000 Received: from MERCURY.corero.com ([fe80::2c05:6b26:abe2:ad24]) by MERCURY.corero.com ([fe80::2c05:6b26:abe2:ad24%19]) with mapi id 14.03.0224.002; Tue, 19 May 2015 16:28:34 -0400 From: Scott Barvick To: Daniel Migault , "Roman D. Danyliw" , "dots@ietf.org" Thread-Topic: [Dots] Consolidation of all draft charter feedback Thread-Index: AQHQknJgAVj6xCg6rU6E3vQWsI1yrQ== Date: Tue, 19 May 2015 20:28:33 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.0.150423 x-originating-ip: [192.168.60.123] Content-Type: text/plain; charset="euc-kr" Content-ID: <0D8494A34BC04C4CAE5014A866C5DC09@corero.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Consolidation of all draft charter feedback X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 20:31:10 -0000 QmVjYXVzZSBpdCBzZWVtcyBwZXJoYXBzIHRvbyBpbmZvcm1hbCBhbmQgdGhlcmVmb3JlIG5vdCBt dWNoIHZhbHVlIG92ZXINCnRoZSBvZmZpY2lhbCBkb2N1bWVudCB3aXRoIHVzZSBjYXNlcyBhbmQg ZW5vdWdoIHdpZ2dsZSByb29tIHdpdGggoa5hcyB0aGUNCldHIHNlZXMgZml0oa8gdG8gbGV0IHVz IGRvIHdoYXQgd2UgdGhpbmsgd2UgbmVlZCB0byBkbz8gICAgSWYgc28sIEkgY291bGQNCmFncmVl IHdpdGggdGhhdC4gIA0KDQpTY290dCANCg0KT24gNS8xOS8xNSwgMTA6MTMgQU0sICJEYW5pZWwg TWlnYXVsdCIgPGRhbmllbC5taWdhdWx0QGVyaWNzc29uLmNvbT4gd3JvdGU6DQoNCj5IaSwgDQo+ DQo+SSBzdWdnZXN0IHRvIHJlbW92ZSB0aGUgZmlyc3QgbWlsZXN0b25lIGl0ZW06DQo+DQo+T0xE DQo+PiAqIFVzZSBjYXNlIGRvY3VtZW50IHRvIGVuc3VyZSBjb21tb25hbGl0eSBvZiB0aGUgd29y ayBhbW9uZyB0aGUNCj4+IHBhcnRpY2lwYW50cyBpbiB0aGUgV29ya2luZyBHcm91cC4gIFRoaXMg ZG9jdW1lbnQgbWF5IGJlIGRldGVybWluZWQgYnkNCj4+IHRoZSB3b3JraW5nIGdyb3VwIHRvIHJl bWFpbiBpbmZvcm1hbCBhbmQgbm90IGJlIHB1Ymxpc2hlZC4NCj4+ICogRG9jdW1lbnQgb3IgRG9j dW1lbnRzIGRlc2NyaWJpbmcgdGhlIHByb2JsZW0gc3BhY2UsIHVzZSBjYXNlcywNCj4+IHByb3Rv Y29sIHJlcXVpcmVtZW50cyBhbmQgb3RoZXIgcXVhbGlmeWluZyBpbmZvcm1hdGlvbiBhcyB0aGUg V0cgc2Vlcw0KPj5maXQuDQo+PiAqIERvY3VtZW50IG9yIERvY3VtZW50cyBzcGVjaWZ5aW5nIGEg cHJvdG9jb2wgYW5kIGFzc29jaWF0ZWQgZGF0YQ0KPj4gbW9kZWxzIHRvIGFkZHJlc3MgdGhlIFdH IHN0YXRlZCBnb2FsLg0KPg0KPk5FVw0KPj4gKiBEb2N1bWVudCBvciBEb2N1bWVudHMgZGVzY3Jp YmluZyB0aGUgcHJvYmxlbSBzcGFjZSwgdXNlIGNhc2VzLA0KPj4gcHJvdG9jb2wgcmVxdWlyZW1l bnRzIGFuZCBvdGhlciBxdWFsaWZ5aW5nIGluZm9ybWF0aW9uIGFzIHRoZSBXRyBzZWVzDQo+PmZp dC4NCj4+ICogRG9jdW1lbnQgb3IgRG9jdW1lbnRzIHNwZWNpZnlpbmcgYSBwcm90b2NvbCBhbmQg YXNzb2NpYXRlZCBkYXRhDQo+PiBtb2RlbHMgdG8gYWRkcmVzcyB0aGUgV0cgc3RhdGVkIGdvYWwu DQo+DQo+QlIsIA0KPkRhbmllbA0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTog RG90cyBbbWFpbHRvOmRvdHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJvbWFuIEQu IERhbnlsaXcNCj5TZW50OiBTYXR1cmRheSwgTWF5IDE2LCAyMDE1IDEwOjI2IFBNDQo+VG86IGRv dHNAaWV0Zi5vcmcNCj5TdWJqZWN0OiBbRG90c10gQ29uc29saWRhdGlvbiBvZiBhbGwgZHJhZnQg Y2hhcnRlciBmZWVkYmFjaw0KPg0KPkhlbGxvIQ0KPg0KPlRoZXJlIGhhcyBiZWVuIHJvYnVzdCBk aXNjdXNzaW9uIG9uIHRoZSBkcmFmdCBjaGFydGVyIHRleHQNCj4oaHR0cDovL3d3dy5pZXRmLm9y Zy9tYWlsLWFyY2hpdmUvd2ViL2RvdHMvY3VycmVudC9tc2cwMDA3Ny5odG1sKS4gIFRvDQo+bWFr ZSBpdCBlYXNpZXIgdG8gcmV2aWV3IHRoZSBkcmFmdCBjaGFydGVyIHdpdGggdGhlIGJlbmVmaXQg b2YgcHJldmlvdXMNCj5mZWVkYmFjaywgYmVsb3cgeW91IGNhbiBmaW5kIGEgc3VtbWFyeSBvZiBh bGwgY29tbWVudHMgdG8gZGF0ZSBhZ2dyZWdhdGVkDQo+aW5saW5lIHdpdGggY29ycmVzcG9uZGlu ZyBsaW5rcy4NCj4NCj5QZXIgS2F0aGxlZW4gTW9yaWFydHkncyByZXF1ZXN0DQo+KGh0dHA6Ly93 d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9kb3RzL2N1cnJlbnQvbXNnMDAwNzQuaHRtbCks IHBsZWFzZQ0KPnByb3ZpZGUgZnVydGhlciBjb21tZW50YXJ5IG9yIHN0YXRlbWVudHMgb2Ygc3Vw cG9ydC4NCj4NCj5Sb21hbg0KPg0KPi0tLS1bIEFnZ3JlZ2F0ZWQgY29tbWVudHMgb24gdGhlIGRy YWZ0IGNoYXJ0ZXIgXS0tLS0NCj4NCj4+IFRoZSBhaW0gb2YgRERvUyBPcGVuIFRocmVhdCBTaWdu YWxpbmcgKERPVFMpIGlzIHRvIGRldmVsb3AgYSBzdGFuZGFyZHMNCj4+IGJhc2VkIGFwcHJvYWNo IHRvIHRoZSByZWFsIHRpbWUgc2lnbmFsaW5nIG9mIEREb1MgcmVsYXRlZCB0ZWxlbWV0cnkNCj4+ IGFuZA0KPg0KPltBbmRyZXcgTW9ydGVuc2VuXSBzdWdnZXN0ZWQgdGhhdCAicmVhbCB0aW1lIiBz aWduYWxpbmcgaXMgZXhwZWN0ZWQgdW5kZXINCj5hdHRhY2sgY29uZGl0aW9ucywgYW5kIHRoYXQg dGhpcyBkZXRhaWwgc2hvdWxkIGJlIG5vdGVkIGV4cGxpY2l0bHkgaW4NCj5odHRwOi8vd3d3Lmll dGYub3JnL21haWwtYXJjaGl2ZS93ZWIvZG90cy9jdXJyZW50L21zZzAwMDg2Lmh0bWwNCj4NCj4+ IHRocmVhdCBoYW5kbGluZyBkYXRhIGJldHdlZW4gZWxlbWVudHMgY29uY2VybmVkIHdpdGggYXR0 YWNrIG1pdGlnYXRpb24uDQo+PiANCj4+IFRoZSBlbGVtZW50cyBtYXkgYmUgZGVzY3JpYmVkIGFz Og0KPj4gKiBPbi1wcmVtaXNlIEREb1MgbWl0aWdhdGlvbiBwbGF0Zm9ybXMNCj4+ICogU2Vydmlj ZSBwcm92aWRlciBERG9TIG1pdGlnYXRpb24gcGxhdGZvcm1zDQo+PiAqIE90aGVyIG5ldHdvcmsg ZGV2aWNlcy9wbGF0Zm9ybXMgdGhhdCBhcmUgYWJsZSB0byBzZW5zZSBERG9TIGFuZA0KPj4gcmVz cG9uZA0KPg0KPltBZGFtIE1vbnR2aWxsZV0gc3VnZ2VzdGVkIHRvIHRpZ2h0ZW4gdXAgdGhlIGxh bmd1YWdlIG9mIHRoaXMgdGhpcmQNCj5idWxsZXQgaW4gaHR0cDovL3d3dy5pZXRmLm9yZy9tYWls LWFyY2hpdmUvd2ViL2RvdHMvY3VycmVudC9tc2cwMDA4MC5odG1sDQo+DQo+LS0NCj5bTmlrIFRl YWd1ZV0gcHJvcG9zZWQgdG8gdGhlIGZvbGxvd2luZyB0ZXh0IGluIHJlc3BvbnNlIHRvIEFkYW06 DQo+DQo+IldoaWxlIHRoZSByZXN1bHRpbmcgc3RhbmRhcmRzIHNob3VsZCBiZSBkZXNpZ25lZCBz byB0aGF0IHRoZXJlqfZzIGENCj5wb3NzaWJpbGl0eSBvZiBhcHBseWluZyB0aGVtIHRvIG5ldHdv cmsgc2VjdXJpdHkgYXBwbGljYXRpb25zIGJleW9uZCBERG9TDQo+bWl0aWdhdGlvbiwgdGhpcyB3 b3JraW5nIGdyb3VwIHdpbGwgZm9jdXMgb24ganVzdCBERG9TIG1pdGlnYXRpb24uqfcNCj4NCj5p biBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvZG90cy9jdXJyZW50L21zZzAw MDgzLmh0bWwNCj4NCj4tLQ0KPltYaWFsaWFuZyAoRnJhbmspXSBSZWNvbW1lbmRlZCBsZWF2aW5n IHRoZSB0aGlyZCBidWxsZXQgdmFndWUgcGVuZGluZyBhDQo+cmV2aWV3IG9mIHRoZSB1c2UgY2Fz ZXMgaW4NCj5odHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvZG90cy9jdXJyZW50 L21zZzAwMDg1Lmh0bWwNCj4NCj4tLQ0KPltBbmRyZXcgTW9ydGVuc2VuXSBzdWdnZXN0ZWQgIk90 aGVyIGRldmljZXMgd2l0aCBuZXR3b3JrIHBlcnNwZWN0aXZlDQo+cGVyZm9ybWluZyB0cmFmZmlj IGFuYWx5c2lzIiAgb3IgIi5lbmdhZ2VkIGluIHRyYWZmaWMgYW5hbHlzaXMiDQo+DQo+PiAqIENo YWluZWQgaW5zdGFuY2VzIG9mIHRoZSBhYm92ZQ0KPj4gDQo+PiBUaGVzZSBlbGVtZW50cyBtYXkg YmUgY29tbXVuaWNhdGluZyBpbnRlci1kb21haW4gb3IgaW50cmEtZG9tYWluIG92ZXINCj4+IGxp bmtzIHRoYXQgbWF5IGJlIGNvbmdlc3RlZCBieSBhdHRhY2sgdHJhZmZpYyByZXN1bHRpbmcgaW4g aG9zdGlsZQ0KPj4gY29uZGl0aW9ucyBmb3IgdHJhZGl0aW9uYWwgY29ubmVjdGlvbiBvcmllbnRl ZCBhcHByb2FjaGVzIGFuZCBtb3JlDQo+PiBnZW5lcmFsaXplZCBzaWduYWxpbmcNCj4NCj5bQW5k cmV3IE1vcnRlbnNlbl0gc3VnZ2VzdGVkIHJlbW92aW5nICJ0cmFkaXRpb25hbCIgaW4NCj5odHRw Oi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvZG90cy9jdXJyZW50L21zZzAwMDg2Lmh0 bWwNCj4NCj4+IGFuZCB0ZWxlbWV0cnkgc29sdXRpb25zLiAgUm9idXN0bmVzcyB1bmRlciB0aGVz ZSBjb25kaXRpb25zIGlzDQo+PiBwYXJhbW91bnQgd2hpbGUgZW5zdXJpbmcgYXBwcm9wcmlhdGUg cmVnYXJkIGZvciBhdXRoZW50aWNhdGlvbiwNCj4+IGF1dGhvcml6YXRpb24sIHByaXZhY3kgYW5k IGRhdGEgaW50ZWdyaXR5LiAgRWxlbWVudHMgbWF5IGJlIGRlcGxveWVkDQo+PiBhcyBwYXJ0IG9m IGEgd2lkZXIgc3RyYXRlZ3kgaW5jb3Jwb3JhdGluZyBtdWx0aXBsZSBwb2ludHMgb2YgZGV0ZWN0 aW9uDQo+PiBhbmQgbWl0aWdhdGlvbiwgYm90aCBvbiBwcmVtaXNlIG9yIHNlcnZpY2UgcHJvdmlk ZXIgYmFzZWQuDQo+PiBTaG91bGQgbWl0aWdhdGlvbiBuZWVkIHRvIG1vdmUgYmV0d2VlbiBlbGVt ZW50cyBpbiB0aGUgY2hhaW4gdGhlbg0KPg0KPltBZGFtIE1vbnR2aWxsZV0gc3VnZ2VzdGVkIGEg Y29tbWEgYmV0d2VlbiAiY2hhaW4iIGFuZCAidGhlbiIgcmVzdWx0aW5nDQo+aW46ICJTaG91bGQg bWl0aWdhdGlvbiBuZWVkIHRvIG1vdmUgYmV0d2VlbiBlbGVtZW50cyBpbiB0aGUgY2hhaW4sIHRo ZW4uIg0KPmluIGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9kb3RzL2N1cnJl bnQvbXNnMDAwODAuaHRtbA0KPg0KPi0tDQo+W0xpbmRhIER1bmJhcl0gc291Z2h0IGNsYXJpdHkg b24gd2hldGhlciB0aGUgZm9sbG93aW5nIGl0ZW1zIHdlcmUgaW4NCj5zY29wZToNCj4qIGRldGVy bWluaW5nIHRoZSBvcHRpbWFsIHBhdGggYmV0d2VlbiBERE9TIGVsZW1lbnRzIGRldGVybWluZWQg aW4NCj5jb25jZXJ0IHdpdGggdGhlIE5ldHdvcmsgTWFuYWdlbWVudCBzeXN0ZW0NCj4qIGVuc3Vy aW5nIHRoZSBzZWN1cmUgY2hhbm5lbHMgYW5kIGNvbmdlc3Rpb24gc3RhdHVzIGZvciBwYXRocyBi ZXR3ZWVuDQo+dGhlIG1pdGlnYXRpbmcgZGV2aWNlcw0KPg0KPkluIGh0dHA6Ly93d3cuaWV0Zi5v cmcvbWFpbC1hcmNoaXZlL3dlYi9kb3RzL2N1cnJlbnQvbXNnMDAwODEuaHRtbA0KPg0KPi0tDQo+ W1Njb3R0IEJhcnZpY2tdIHJlcGxpZWQgdG8gW0xpbmRhIER1bmJhcl0gb24gdGhpcyBzY29wZSBp bg0KPmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9kb3RzL2N1cnJlbnQvbXNn MDAwODIuaHRtbA0KPg0KPi0tDQo+W0FuZHJldyBNbyBdIHNvdWdodCBjbGFyaXR5IG9uIHdoZXRo ZXIgIi4uLiBhbiBvbi1wcmVtaXNlIGRldmljZSBtYXkNCj5zaWduYWwgbGF0ZXJhbGx5IGludGVu dGlvbmFsPyBPciBpcyB0aGUgZXhwZWN0YXRpb24gdGhhdCBlYWNoIHN1YnNlcXVlbnQNCj5lbGVt ZW50IGluIHRoZSBjaGFpbiB3aWxsIGJlIHVwc3RyZWFtIGZyb20gdGhlIHByZXZpb3VzPyIgaW4N Cj5odHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvZG90cy9jdXJyZW50L21zZzAw MDg2Lmh0bWwNCj4NCj4tLQ0KPltMaW5kYSBEdW5iYXJdIHN1Z2dlc3RlZCB1cGRhdGVkIHRleHQg dGhhdCByZWFkcyBhcyAiVGhlc2UgZWxlbWVudHMgbWF5DQo+YmUgY29tbXVuaWNhdGluZyBvdmVy IGNvbmdlc3RlZCBsaW5rcy9wYXRocywgd2l0aCBwb3NzaWJpbGl0eSBvZiBwYWNrZXRzDQo+bG9z cy4gIFRoZXJlZm9yZSwgbWVjaGFuaXNtcyBoYXZlIGJlIGNvbnNpZGVyZWQgdG8gY29tcGVuc2F0 ZSBwYWNrZXRzDQo+bG9zcyB0byBlbnN1cmUgYXBwcm9wcmlhdGUgcmVnYXJkIGZvciBhdXRoZW50 aWNhdGlvbiwgYXV0aG9yaXphdGlvbiwNCj5wcml2YWN5IGFuZCBkYXRhIGludGVncml0eS4iIElu DQo+aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2RvdHMvY3VycmVudC9tc2cw MDEwMi5odG1sDQo+DQo+LS0NCj5bU2NvdHQgQmFydmlja10gaW4NCj5odHRwOi8vd3d3LmlldGYu b3JnL21haWwtYXJjaGl2ZS93ZWIvZG90cy9jdXJyZW50L21zZzAwMTA0Lmh0bWwgYW5kDQo+W0th dGhsZWVuIE1vcmlhcnR5XSBpbg0KPmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dl Yi9kb3RzL2N1cnJlbnQvbXNnMDAxMDMuaHRtbCBiZWxpZXZlDQo+dGhlIGV4aXN0aW5nIGxhbmd1 YWdlIGNvdmVycyBbTGluZGEgRHVuYmFyXSdzIHByb3Bvc2FsLg0KPg0KPj4gZWZmZWN0aXZlIHNp Z25hbGluZyBvZiB0ZWxlbWV0cnkgYW5kIGN1cnJlbnQgdGhyZWF0IGhhbmRsaW5nIGlzDQo+PmVz c2VudGlhbC4NCj4+ICBGZWVkYmFjayBiZXR3ZWVuIHBhcnRpY2lwYXRpbmcgZWxlbWVudHMgaXMg cmVxdWlyZWQgZm9yIGluY3JlYXNlZA0KPj4gYXdhcmVuZXNzIGZvciBlZmZlY3RpdmUgZGVjaXNp b24gbWFraW5nLg0KPg0KPltBZGFtIE1vbnR2aWxsZV0gc3VnZ2VzdGVkICAiLnJlcXVpcmVkIGZv ciBpbmNyZWFzZWQgYXdhcmVuZXNzIHN1cHBvcnRpbmcNCj5lZmZlY3RpdmUgZGVjaXNpb24gbWFr aW5nIiBpbg0KPmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9kb3RzL2N1cnJl bnQvbXNnMDAwODAuaHRtbA0KPg0KPi0tDQo+W1hpYWxpYW5nIChGcmFuayldIHN1Z2dlc3RlZCAi RmVlZGJhY2sgYW5kIGluaXRpYWwgY2FwYWJpbGl0eSBuZWdvdGlhdGlvbg0KPm1lY2hhbmlzbXMg YmV0d2VlbiBwYXJ0aWNpcGF0aW5nIGVsZW1lbnRzIGlzIHJlcXVpcmVkIGZvciBpbmNyZWFzZWQN Cj5hd2FyZW5lc3MgZm9yIGVmZmVjdGl2ZSBkZWNpc2lvbiBtYWtpbmcuIiBpbg0KPmh0dHA6Ly93 d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9kb3RzL2N1cnJlbnQvbXNnMDAwODUuaHRtbA0K Pg0KPj4gVGhlIFdHIHdpbGwsIHdoZXJlIGFwcHJvcHJpYXRlLCByZXVzZSBleGlzdGluZyBzdGFu ZGFyZCBwcm90b2NvbHMgYW5kDQo+PiBtZWNoYW5pc21zLCBmb3IgaW5zdGFuY2UgSVBGSVggYW5k IGl0cyB0ZW1wbGF0aW5nIG1lY2hhbmlzbS4NCj4NCj5bQWRhbSBNb250dmlsbGVdIHN1Z2dlc3Rl ZCBtZW50aW9uaW5nIG90aGVyIHdvcmtpbmcgZ3JvdXBzIGluDQo+aHR0cDovL3d3dy5pZXRmLm9y Zy9tYWlsLWFyY2hpdmUvd2ViL2RvdHMvY3VycmVudC9tc2cwMDA4MC5odG1sDQo+DQo+LS0NCj5b QW5kcmV3IF0gaGlnaGxpZ2h0ZWQgdGhlIGluaGVyZW50IGNvbmZsaWN0IGJldHdlZW4gcmV1c2lu ZyBJUEZJWCAoc3RhdGVkDQo+aGVyZSkgYW5kIHRoZSBsaW1pdGF0aW9uIG9mICJ0cmFkaXRpb25h bCBjb25uZWN0aW9uIG9yaWVudGVkIHByb3RvY29scyINCj4oc3RhdGVkIGFib3ZlIGluIHRoZSBj aGFydCkgaW4NCj5odHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvZG90cy9jdXJy ZW50L21zZzAwMDk4Lmh0bWwNCj4NCj4+IFRoZSBjaGFydGVyIG9mIHRoZSB3b3JraW5nIGdyb3Vw IGlzIHRvIHByb2R1Y2Ugb25lIG9yIG1vcmUgc3RhbmRhcmRzDQo+PiB0cmFjayBzcGVjaWZpY2F0 aW9uIHRvIHByb3ZpZGUgZm9yIHRoaXMgb3BlbiBzaWduYWxpbmcgaW4gdGhlIEREb1MNCj4+cHJv YmxlbSBzcGFjZS4NCj4NCj5bQWRhbSBNb250dmlsbGVdIHN1Z2dlc3RlZCBtYWtpbmcgInNwZWNp ZmljYXRpb24iIHBsdXJhbCwgc28gdGhhdCB0aGUNCj5zZW50ZW5jZSByZWFkczogIi50byBwcm9k dWNlIG9uZSBvciBtb3JlIHN0YW5kYXJkcyB0cmFjayBzcGVjaWZpY2F0aW9ucy4iDQo+aW4gaHR0 cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2RvdHMvY3VycmVudC9tc2cwMDA4MC5o dG1sDQo+DQo+PiBXaGlsZSB0aGUgcmVzdWx0aW5nIHN0YW5kYXJkcyBzaG91bGQgYmUgZGVzaWdu ZWQgc28gdGhhdCB0aGVyZan2cyBhDQo+PiBwb3NzaWJpbGl0eSBvZiBhcHBseWluZyB0aGVtIHRv IG5ldHdvcmsgc2VjdXJpdHkgYXBwbGljYXRpb25zIGJleW9uZA0KPj4gRERvUyBtaXRpZ2F0aW9u LA0KPg0KPltBbmRyZXcgTW9ydGVuc2VuXSBzdWdnZXN0ZWQgdXNpbmcgIi5kZXNpZ25lZCBzbyB0 aGV5IG1heSBhcHBseSB0bw0KPm5ldHdvcmsgc2VjdXJpdHkgYXBwbGljYXRpb25zLiIgaW4NCj5o dHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvZG90cy9jdXJyZW50L21zZzAwMDg2 Lmh0bWwNCj4NCj4+IHRoaXMgd29ya2luZyBncm91cCB3aWxsIGZvY3VzIG9uIGp1c3QgRERvUyBt aXRpZ2F0aW9uLiAgVGhpcw0KPj4gc3RyZWFtbGluZWQgZm9jdXMNCj4NCj5bQW5kcmV3IE1vcnRl bnNlbl0gc3VnZ2VzdGVkIHJlbW92aW5nICJqdXN0IiBpbg0KPmh0dHA6Ly93d3cuaWV0Zi5vcmcv bWFpbC1hcmNoaXZlL3dlYi9kb3RzL2N1cnJlbnQvbXNnMDAwODYuaHRtbA0KPg0KPj4gb2YgdGhl IGNoYXJ0ZXIgaXMgaW50ZW5kZWQgdG8gbGVhZCB0byBhbiBlYXJsaWVyIHJlc3VsdCBkdWUgdG8N Cj4+IGNvbW11bml0eSBpbnRlcmVzdHMgaW4gaGF2aW5nIHN1Y2ggY2FwYWJpbGl0eSBpbiBhIHNo b3J0IHRpbWVmcmFtZS4NCj4+ICBUaGUgc3BlY2lmaWNhdGlvbihzKSBwcm9kdWNlZCBieSB0aGUg V0cgd2lsbCBpbmNsdWRlIGEgc3RhbmRhcmQNCj4+IG1lY2hhbmlzbSBmb3IgYXV0aGVudGljYXRp b24gYW5kIGF1dGhvcml6YXRpb24sIGZvciBkYXRhIGludGVncml0eSwNCj4+IGFuZCBmb3IgcHJv dmlkaW5nIGZvciBwcml2YWN5IGluIG9wZXJhdGlvbi4NCj4+IA0KPj4gVGhlIFdHIHdpbGwgcHJv ZHVjZSB0aGUgZm9sbG93aW5nIGRlbGl2ZXJhYmxlczoNCj4+IA0KPj4gKiBVc2UgY2FzZSBkb2N1 bWVudCB0byBlbnN1cmUgY29tbW9uYWxpdHkgb2YgdGhlIHdvcmsgYW1vbmcgdGhlDQo+PiBwYXJ0 aWNpcGFudHMgaW4gdGhlIFdvcmtpbmcgR3JvdXAuICBUaGlzIGRvY3VtZW50IG1heSBiZSBkZXRl cm1pbmVkIGJ5DQo+PiB0aGUgd29ya2luZyBncm91cCB0byByZW1haW4gaW5mb3JtYWwgYW5kIG5v dCBiZSBwdWJsaXNoZWQuDQo+PiAqIERvY3VtZW50IG9yIERvY3VtZW50cyBkZXNjcmliaW5nIHRo ZSBwcm9ibGVtIHNwYWNlLCB1c2UgY2FzZXMsDQo+PiBwcm90b2NvbCByZXF1aXJlbWVudHMgYW5k IG90aGVyIHF1YWxpZnlpbmcgaW5mb3JtYXRpb24gYXMgdGhlIFdHIHNlZXMNCj4+Zml0Lg0KPj4g KiBEb2N1bWVudCBvciBEb2N1bWVudHMgc3BlY2lmeWluZyBhIHByb3RvY29sIGFuZCBhc3NvY2lh dGVkIGRhdGENCj4+IG1vZGVscyB0byBhZGRyZXNzIHRoZSBXRyBzdGF0ZWQgZ29hbC4NCj4NCj5b QWRhbSBNb250dmlsbGVdIHN1Z2dlc3RlZCBhZGRpbmcgYSBtaWxlc3RvbmUgdG8gcmV2aWV3IG1p bGVzdG9uZXMgYW5kDQo+c3BlY2lmaWMgZGF0ZXMgZm9yIHRoZXNlIGluDQo+aHR0cDovL3d3dy5p ZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2RvdHMvY3VycmVudC9tc2cwMDA4MC5odG1sDQo+DQo+ DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4g RG90cyBtYWlsaW5nIGxpc3QNCj4+IERvdHNAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vZG90cw0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+RG90cyBtYWlsaW5nIGxpc3QNCj5Eb3RzQGlldGYub3Jn DQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kb3RzDQo+DQo+X19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5Eb3RzIG1haWxpbmcg bGlzdA0KPkRvdHNAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2RvdHMNCg0K From nobody Tue May 19 14:37:38 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2166C1B3389 for ; Tue, 19 May 2015 14:37:38 -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, RCVD_IN_DNSWL_LOW=-0.7] 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 FUGDfRAFl8qP for ; Tue, 19 May 2015 14:37:35 -0700 (PDT) Received: from mail-ie0-f181.google.com (mail-ie0-f181.google.com [209.85.223.181]) (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 CC08D1B3357 for ; Tue, 19 May 2015 14:37:32 -0700 (PDT) Received: by ieczm2 with SMTP id zm2so24807023iec.1 for ; Tue, 19 May 2015 14:37:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=AUpcOUpNB3yj/jGvR12pfwsJ83WduPSjBGVDessL+Ew=; b=Ykyy46DvxK7pmSGt17HeOGYVYSycWStX6P11KO1IJX8GT0bLbP8XwJGFW2jMoxdoQo kMs3rQjCaBaLN+XT+JrG5Jzxvi36nXtc/kik1aAQ02d18nc27ZQczbB1HuOarpzWBRHd Vk2FloHc8hwPwtETEuZ7EyDOpS+TPXoTX9naQTZrR4/gcwIVgrTBx/iMHlh1X/Inc3g5 qx7q8OyP4tBgRdwcW9i5zXyLG1w3SkSOBXS88IRO/gthO7MHaK4VCGAFZBe+eUxHUXFO rLnYE32tJyvglMTTUC9ZoGT7txwFpurXEJ12uW3wf/o2eEMeBGjFqW9mGBiE2EGzNg4P c+UQ== X-Gm-Message-State: ALoCoQniHL0Qf5kGV+bK9WfDJqKKCFzxzNAS8yX0VZv0pvT+g32qc4QNOP+lEi7XE/m8zIPBTjDQ X-Received: by 10.107.169.93 with SMTP id s90mr3012500ioe.83.1432071452251; Tue, 19 May 2015 14:37:32 -0700 (PDT) Received: from ?IPv6:2001:428:1:1:ec4:7aff:fe32:71f6? ([2001:428:1:1:ec4:7aff:fe32:71f6]) by mx.google.com with ESMTPSA id c10sm7439898ioe.25.2015.05.19.14.37.30 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 May 2015 14:37:31 -0700 (PDT) Message-ID: <555BAD14.5010607@flowtools.net> Date: Tue, 19 May 2015 15:37:24 -0600 From: John Schiel User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: dots@ietf.org References: <359EC4B99E040048A7131E0F4E113AFCD9441477@marathon> <2DD56D786E600F45AC6BDE7DA4E8A8C161F7E8@eusaamb107.ericsson.se> In-Reply-To: <2DD56D786E600F45AC6BDE7DA4E8A8C161F7E8@eusaamb107.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Dots] Consolidation of all draft charter feedback X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 21:37:38 -0000 On 05/19/2015 08:13 AM, Daniel Migault wrote: > Hi, > > I suggest to remove the first milestone item: I kind of like the idea of a use case document as long as the examples are small and concise. It would provide a good reference tool for discussion and for developing the standard. Thanks, --John > > OLD >> * Use case document to ensure commonality of the work among the >> participants in the Working Group. This document may be determined by >> the working group to remain informal and not be published. >> * Document or Documents describing the problem space, use cases, >> protocol requirements and other qualifying information as the WG sees fit. >> * Document or Documents specifying a protocol and associated data >> models to address the WG stated goal. > NEW >> * Document or Documents describing the problem space, use cases, >> protocol requirements and other qualifying information as the WG sees fit. >> * Document or Documents specifying a protocol and associated data >> models to address the WG stated goal. > BR, > Daniel > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Roman D. Danyliw > Sent: Saturday, May 16, 2015 10:26 PM > To: dots@ietf.org > Subject: [Dots] Consolidation of all draft charter feedback > > Hello! > > There has been robust discussion on the draft charter text (http://www.ietf.org/mail-archive/web/dots/current/msg00077.html). To make it easier to review the draft charter with the benefit of previous feedback, below you can find a summary of all comments to date aggregated inline with corresponding links. > > Per Kathleen Moriarty's request (http://www.ietf.org/mail-archive/web/dots/current/msg00074.html), please provide further commentary or statements of support. > > Roman > > ----[ Aggregated comments on the draft charter ]---- > >> The aim of DDoS Open Threat Signaling (DOTS) is to develop a standards >> based approach to the real time signaling of DDoS related telemetry >> and > [Andrew Mortensen] suggested that "real time" signaling is expected under attack conditions, and that this detail should be noted explicitly in http://www.ietf.org/mail-archive/web/dots/current/msg00086.html > >> threat handling data between elements concerned with attack mitigation. >> >> The elements may be described as: >> * On-premise DDoS mitigation platforms >> * Service provider DDoS mitigation platforms >> * Other network devices/platforms that are able to sense DDoS and >> respond > [Adam Montville] suggested to tighten up the language of this third bullet in http://www.ietf.org/mail-archive/web/dots/current/msg00080.html > > -- > [Nik Teague] proposed to the following text in response to Adam: > > "While the resulting standards should be designed so that there¹s a possibility of applying them to network security applications beyond DDoS mitigation, this working group will focus on just DDoS mitigation.² > > in http://www.ietf.org/mail-archive/web/dots/current/msg00083.html > > -- > [Xialiang (Frank)] Recommended leaving the third bullet vague pending a review of the use cases in http://www.ietf.org/mail-archive/web/dots/current/msg00085.html > > -- > [Andrew Mortensen] suggested "Other devices with network perspective performing traffic analysis" or ".engaged in traffic analysis" > >> * Chained instances of the above >> >> These elements may be communicating inter-domain or intra-domain over >> links that may be congested by attack traffic resulting in hostile >> conditions for traditional connection oriented approaches and more >> generalized signaling > [Andrew Mortensen] suggested removing "traditional" in http://www.ietf.org/mail-archive/web/dots/current/msg00086.html > >> and telemetry solutions. Robustness under these conditions is >> paramount while ensuring appropriate regard for authentication, >> authorization, privacy and data integrity. Elements may be deployed >> as part of a wider strategy incorporating multiple points of detection >> and mitigation, both on premise or service provider based. >> Should mitigation need to move between elements in the chain then > [Adam Montville] suggested a comma between "chain" and "then" resulting in: "Should mitigation need to move between elements in the chain, then." in http://www.ietf.org/mail-archive/web/dots/current/msg00080.html > > -- > [Linda Dunbar] sought clarity on whether the following items were in scope: > * determining the optimal path between DDOS elements determined in concert with the Network Management system > * ensuring the secure channels and congestion status for paths between the mitigating devices > > In http://www.ietf.org/mail-archive/web/dots/current/msg00081.html > > -- > [Scott Barvick] replied to [Linda Dunbar] on this scope in http://www.ietf.org/mail-archive/web/dots/current/msg00082.html > > -- > [Andrew Mo ] sought clarity on whether "... an on-premise device may signal laterally intentional? Or is the expectation that each subsequent element in the chain will be upstream from the previous?" in http://www.ietf.org/mail-archive/web/dots/current/msg00086.html > > -- > [Linda Dunbar] suggested updated text that reads as "These elements may be communicating over congested links/paths, with possibility of packets loss. Therefore, mechanisms have be considered to compensate packets loss to ensure appropriate regard for authentication, authorization, privacy and data integrity." In http://www.ietf.org/mail-archive/web/dots/current/msg00102.html > > -- > [Scott Barvick] in http://www.ietf.org/mail-archive/web/dots/current/msg00104.html and [Kathleen Moriarty] in http://www.ietf.org/mail-archive/web/dots/current/msg00103.html believe the existing language covers [Linda Dunbar]'s proposal. > >> effective signaling of telemetry and current threat handling is essential. >> Feedback between participating elements is required for increased >> awareness for effective decision making. > [Adam Montville] suggested ".required for increased awareness supporting effective decision making" in http://www.ietf.org/mail-archive/web/dots/current/msg00080.html > > -- > [Xialiang (Frank)] suggested "Feedback and initial capability negotiation mechanisms between participating elements is required for increased awareness for effective decision making." in http://www.ietf.org/mail-archive/web/dots/current/msg00085.html > >> The WG will, where appropriate, reuse existing standard protocols and >> mechanisms, for instance IPFIX and its templating mechanism. > [Adam Montville] suggested mentioning other working groups in http://www.ietf.org/mail-archive/web/dots/current/msg00080.html > > -- > [Andrew ] highlighted the inherent conflict between reusing IPFIX (stated here) and the limitation of "traditional connection oriented protocols" (stated above in the chart) in http://www.ietf.org/mail-archive/web/dots/current/msg00098.html > >> The charter of the working group is to produce one or more standards >> track specification to provide for this open signaling in the DDoS problem space. > [Adam Montville] suggested making "specification" plural, so that the sentence reads: ".to produce one or more standards track specifications." in http://www.ietf.org/mail-archive/web/dots/current/msg00080.html > >> While the resulting standards should be designed so that there¹s a >> possibility of applying them to network security applications beyond >> DDoS mitigation, > [Andrew Mortensen] suggested using ".designed so they may apply to network security applications." in http://www.ietf.org/mail-archive/web/dots/current/msg00086.html > >> this working group will focus on just DDoS mitigation. This >> streamlined focus > [Andrew Mortensen] suggested removing "just" in http://www.ietf.org/mail-archive/web/dots/current/msg00086.html > >> of the charter is intended to lead to an earlier result due to >> community interests in having such capability in a short timeframe. >> The specification(s) produced by the WG will include a standard >> mechanism for authentication and authorization, for data integrity, >> and for providing for privacy in operation. >> >> The WG will produce the following deliverables: >> >> * Use case document to ensure commonality of the work among the >> participants in the Working Group. This document may be determined by >> the working group to remain informal and not be published. >> * Document or Documents describing the problem space, use cases, >> protocol requirements and other qualifying information as the WG sees fit. >> * Document or Documents specifying a protocol and associated data >> models to address the WG stated goal. > [Adam Montville] suggested adding a milestone to review milestones and specific dates for these in http://www.ietf.org/mail-archive/web/dots/current/msg00080.html > > >> _______________________________________________ >> Dots mailing list >> Dots@ietf.org >> https://www.ietf.org/mailman/listinfo/dots > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Tue May 19 14:48:25 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8FDB1ACCE1 for ; Tue, 19 May 2015 14:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 TtVmkc_3Eyu4 for ; Tue, 19 May 2015 14:48:22 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B97BD1ACCE0 for ; Tue, 19 May 2015 14:48:21 -0700 (PDT) X-AuditID: c618062d-f79a96d000007fb1-88-555b570379a7 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 66.FB.32689.3075B555; Tue, 19 May 2015 17:30:12 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0210.002; Tue, 19 May 2015 17:48:19 -0400 From: Daniel Migault To: John Schiel , "dots@ietf.org" Thread-Topic: [Dots] Consolidation of all draft charter feedback Thread-Index: AdCQRqxKc0cQVxSCQYyh/0Eeuj4KmQB9vAJQABf6RwAACC6Q4A== Date: Tue, 19 May 2015 21:48:19 +0000 Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C1620E13@eusaamb107.ericsson.se> References: <359EC4B99E040048A7131E0F4E113AFCD9441477@marathon> <2DD56D786E600F45AC6BDE7DA4E8A8C161F7E8@eusaamb107.ericsson.se> <555BAD14.5010607@flowtools.net> In-Reply-To: <555BAD14.5010607@flowtools.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUyuXRPgi5LeHSoweMpPBZr3xxhtZi97B+b A5PHgt3drB5LlvxkCmCK4rJJSc3JLEst0rdL4MroufKfpWB5YEXrhQ2sDYwLXboYOTkkBEwk pv04xwJhi0lcuLeerYuRi0NI4CijxP9rK6Gc5YwS3999YwapYhMwkmg71M/excjBISLgITF7 uQ9IWFjAXuLejkZ2EFtEwEHi5LbtTBC2k8SFiVfBFrAIqEp8nfSLFcTmFfCWWNaylQVi/hJG ieOt39hAEpwCuhK3Hi0BG8QIdNH3U2vABjELiEvcejKfCeJSAYkle84zQ9iiEi8f/2OFsJUk Ji09xwpRrydxY+oUNghbW2LZwtfMEIsFJU7OfMIygVF0FpKxs5C0zELSMgtJywJGllWMHKXF qWW56UYGmxiB8XBMgk13B+Oel5aHGAU4GJV4eB8kRIUKsSaWFVfmHmKU5mBREuf9ZhgSKiSQ nliSmp2aWpBaFF9UmpNafIiRiYNTqoGRjyfr1+KrivJx4iLvqndl3nr44HLpzFDepId7j9l9 iFSssShhDJQudb2z6PqNo1NWl+VNd5ij9EL+fs3bay+mLzZ4mFHvdS3KeN6Wt3HpFgZxVvN9 7y7r3Btz8ICE51U3H7bHjKLhSxuO1y8NF4n9dut5THZlgUfK6tOZ+afnOG+YxC78x5BTiaU4 I9FQi7moOBEAN2t+emgCAAA= Archived-At: Subject: Re: [Dots] Consolidation of all draft charter feedback X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 21:48:24 -0000 Hi,=20 I also like the idea of a use case document and I think it is a helpful doc= ument to have. The reason I mentioned the first item could be removed is th= at use cases are already mentioned in the second item, and as such it looks= redundant with the second item. BR,=20 Daniel=20 -----Original Message----- From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of John Schiel Sent: Tuesday, May 19, 2015 5:37 PM To: dots@ietf.org Subject: Re: [Dots] Consolidation of all draft charter feedback On 05/19/2015 08:13 AM, Daniel Migault wrote: > Hi, > > I suggest to remove the first milestone item: I kind of like the idea of a use case document as long as the examples are = small and concise. It would provide a good reference tool for discussion an= d for developing the standard. Thanks, --John > > OLD >> * Use case document to ensure commonality of the work among the=20 >> participants in the Working Group. This document may be determined=20 >> by the working group to remain informal and not be published. >> * Document or Documents describing the problem space, use cases,=20 >> protocol requirements and other qualifying information as the WG sees fi= t. >> * Document or Documents specifying a protocol and associated data=20 >> models to address the WG stated goal. > NEW >> * Document or Documents describing the problem space, use cases,=20 >> protocol requirements and other qualifying information as the WG sees fi= t. >> * Document or Documents specifying a protocol and associated data=20 >> models to address the WG stated goal. > BR, > Daniel > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Roman D.=20 > Danyliw > Sent: Saturday, May 16, 2015 10:26 PM > To: dots@ietf.org > Subject: [Dots] Consolidation of all draft charter feedback > > Hello! > > There has been robust discussion on the draft charter text (http://www.ie= tf.org/mail-archive/web/dots/current/msg00077.html). To make it easier to = review the draft charter with the benefit of previous feedback, below you c= an find a summary of all comments to date aggregated inline with correspond= ing links. > > Per Kathleen Moriarty's request (http://www.ietf.org/mail-archive/web/dot= s/current/msg00074.html), please provide further commentary or statements o= f support. > > Roman > > ----[ Aggregated comments on the draft charter ]---- > >> The aim of DDoS Open Threat Signaling (DOTS) is to develop a=20 >> standards based approach to the real time signaling of DDoS related=20 >> telemetry and > [Andrew Mortensen] suggested that "real time" signaling is expected=20 > under attack conditions, and that this detail should be noted=20 > explicitly in=20 > http://www.ietf.org/mail-archive/web/dots/current/msg00086.html > >> threat handling data between elements concerned with attack mitigation. >> >> The elements may be described as: >> * On-premise DDoS mitigation platforms >> * Service provider DDoS mitigation platforms >> * Other network devices/platforms that are able to sense DDoS and=20 >> respond > [Adam Montville] suggested to tighten up the language of this third=20 > bullet in=20 > http://www.ietf.org/mail-archive/web/dots/current/msg00080.html > > -- > [Nik Teague] proposed to the following text in response to Adam: > > "While the resulting standards should be designed so that there=B9s a=20 > possibility of applying them to network security applications beyond=20 > DDoS mitigation, this working group will focus on just DDoS=20 > mitigation.=B2 > > in http://www.ietf.org/mail-archive/web/dots/current/msg00083.html > > -- > [Xialiang (Frank)] Recommended leaving the third bullet vague pending=20 > a review of the use cases in=20 > http://www.ietf.org/mail-archive/web/dots/current/msg00085.html > > -- > [Andrew Mortensen] suggested "Other devices with network perspective perf= orming traffic analysis" or ".engaged in traffic analysis" > >> * Chained instances of the above >> >> These elements may be communicating inter-domain or intra-domain over=20 >> links that may be congested by attack traffic resulting in hostile=20 >> conditions for traditional connection oriented approaches and more=20 >> generalized signaling > [Andrew Mortensen] suggested removing "traditional" in=20 > http://www.ietf.org/mail-archive/web/dots/current/msg00086.html > >> and telemetry solutions. Robustness under these conditions is=20 >> paramount while ensuring appropriate regard for authentication,=20 >> authorization, privacy and data integrity. Elements may be deployed=20 >> as part of a wider strategy incorporating multiple points of=20 >> detection and mitigation, both on premise or service provider based. >> Should mitigation need to move between elements in the chain then > [Adam Montville] suggested a comma between "chain" and "then"=20 > resulting in: "Should mitigation need to move between elements in the=20 > chain, then." in=20 > http://www.ietf.org/mail-archive/web/dots/current/msg00080.html > > -- > [Linda Dunbar] sought clarity on whether the following items were in scop= e: > * determining the optimal path between DDOS elements determined in=20 > concert with the Network Management system > * ensuring the secure channels and congestion status for paths between=20 > the mitigating devices > > In http://www.ietf.org/mail-archive/web/dots/current/msg00081.html > > -- > [Scott Barvick] replied to [Linda Dunbar] on this scope in=20 > http://www.ietf.org/mail-archive/web/dots/current/msg00082.html > > -- > [Andrew Mo ] sought clarity on whether "... an on-premise device may=20 > signal laterally intentional? Or is the expectation that each=20 > subsequent element in the chain will be upstream from the previous?"=20 > in http://www.ietf.org/mail-archive/web/dots/current/msg00086.html > > -- > [Linda Dunbar] suggested updated text that reads as "These elements=20 > may be communicating over congested links/paths, with possibility of=20 > packets loss. Therefore, mechanisms have be considered to compensate=20 > packets loss to ensure appropriate regard for authentication,=20 > authorization, privacy and data integrity." In=20 > http://www.ietf.org/mail-archive/web/dots/current/msg00102.html > > -- > [Scott Barvick] in http://www.ietf.org/mail-archive/web/dots/current/msg0= 0104.html and [Kathleen Moriarty] in http://www.ietf.org/mail-archive/web/d= ots/current/msg00103.html believe the existing language covers [Linda Dunba= r]'s proposal. > >> effective signaling of telemetry and current threat handling is essentia= l. >> Feedback between participating elements is required for increased=20 >> awareness for effective decision making. > [Adam Montville] suggested ".required for increased awareness=20 > supporting effective decision making" in=20 > http://www.ietf.org/mail-archive/web/dots/current/msg00080.html > > -- > [Xialiang (Frank)] suggested "Feedback and initial capability=20 > negotiation mechanisms between participating elements is required for=20 > increased awareness for effective decision making." in=20 > http://www.ietf.org/mail-archive/web/dots/current/msg00085.html > >> The WG will, where appropriate, reuse existing standard protocols and=20 >> mechanisms, for instance IPFIX and its templating mechanism. > [Adam Montville] suggested mentioning other working groups in=20 > http://www.ietf.org/mail-archive/web/dots/current/msg00080.html > > -- > [Andrew ] highlighted the inherent conflict between reusing IPFIX=20 > (stated here) and the limitation of "traditional connection oriented=20 > protocols" (stated above in the chart) in=20 > http://www.ietf.org/mail-archive/web/dots/current/msg00098.html > >> The charter of the working group is to produce one or more standards=20 >> track specification to provide for this open signaling in the DDoS probl= em space. > [Adam Montville] suggested making "specification" plural, so that the=20 > sentence reads: ".to produce one or more standards track=20 > specifications." in=20 > http://www.ietf.org/mail-archive/web/dots/current/msg00080.html > >> While the resulting standards should be designed so that there=B9s a=20 >> possibility of applying them to network security applications beyond=20 >> DDoS mitigation, > [Andrew Mortensen] suggested using ".designed so they may apply to=20 > network security applications." in=20 > http://www.ietf.org/mail-archive/web/dots/current/msg00086.html > >> this working group will focus on just DDoS mitigation. This=20 >> streamlined focus > [Andrew Mortensen] suggested removing "just" in=20 > http://www.ietf.org/mail-archive/web/dots/current/msg00086.html > >> of the charter is intended to lead to an earlier result due to=20 >> community interests in having such capability in a short timeframe. >> The specification(s) produced by the WG will include a standard=20 >> mechanism for authentication and authorization, for data integrity,=20 >> and for providing for privacy in operation. >> >> The WG will produce the following deliverables: >> >> * Use case document to ensure commonality of the work among the=20 >> participants in the Working Group. This document may be determined=20 >> by the working group to remain informal and not be published. >> * Document or Documents describing the problem space, use cases,=20 >> protocol requirements and other qualifying information as the WG sees fi= t. >> * Document or Documents specifying a protocol and associated data=20 >> models to address the WG stated goal. > [Adam Montville] suggested adding a milestone to review milestones and=20 > specific dates for these in=20 > http://www.ietf.org/mail-archive/web/dots/current/msg00080.html > > >> _______________________________________________ >> Dots mailing list >> Dots@ietf.org >> https://www.ietf.org/mailman/listinfo/dots > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots From nobody Tue May 19 15:58:02 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56ABA1B34C8 for ; Tue, 19 May 2015 15:58:01 -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, RCVD_IN_DNSWL_LOW=-0.7] 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 OSa4RzlJrnvJ for ; Tue, 19 May 2015 15:57:58 -0700 (PDT) Received: from mail-ig0-f172.google.com (mail-ig0-f172.google.com [209.85.213.172]) (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 782611B34C6 for ; Tue, 19 May 2015 15:57:58 -0700 (PDT) Received: by igcau1 with SMTP id au1so26429124igc.1 for ; Tue, 19 May 2015 15:57:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=0FBJLoZyFm4A7QqXHpT6hoN+fQWltHSOKl97vMYaAxk=; b=IRmJ5uOug1psdKthWECH/Urfn4/twjP7X1cBU4nmNGbknilrK1vlXdmhHBDL/NVAD0 l3XYHgAr2VvaN6u+lyUYW2tdWbLp8KrWtFbXBMWNKgHwwPxRWyPA/22ZmWuzhNMBMfRF WdjG/5JaN5wqg/fuEUJs57SsPnEJr453Zll0Icea54Kq1zRwpZmR85XtGWaEEw3Y853F oloE6KBZjTvNw+eWkM9CUzAJBKzVu4qfW7QUlyEOAVird/63EwOuhvmhrocb5I+UMKIn lDUz2h0iLZxPdgcQLcmKFurDC84ATmguhlVTwFe9hKMTnEPwhZrvMDT+O6FwxcrIUpgk Krtw== X-Gm-Message-State: ALoCoQm42ew6cBZgh6apYlBhilEJzv3sh9lLphV/NV2HIgMnTpc2t874DxnBkirRqazETOPPSVfe X-Received: by 10.50.39.105 with SMTP id o9mr24678927igk.39.1432076277880; Tue, 19 May 2015 15:57:57 -0700 (PDT) Received: from ?IPv6:2001:428:1:1:ec4:7aff:fe32:71f6? ([2001:428:1:1:ec4:7aff:fe32:71f6]) by mx.google.com with ESMTPSA id n14sm11026677ion.5.2015.05.19.15.57.56 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 May 2015 15:57:56 -0700 (PDT) Message-ID: <555BBFF3.1090104@flowtools.net> Date: Tue, 19 May 2015 16:57:55 -0600 From: John Schiel User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Daniel Migault , "dots@ietf.org" References: <359EC4B99E040048A7131E0F4E113AFCD9441477@marathon> <2DD56D786E600F45AC6BDE7DA4E8A8C161F7E8@eusaamb107.ericsson.se> <555BAD14.5010607@flowtools.net> <2DD56D786E600F45AC6BDE7DA4E8A8C1620E13@eusaamb107.ericsson.se> In-Reply-To: <2DD56D786E600F45AC6BDE7DA4E8A8C1620E13@eusaamb107.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Dots] Consolidation of all draft charter feedback X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 22:58:01 -0000 On 05/19/2015 03:48 PM, Daniel Migault wrote: > Hi, > > I also like the idea of a use case document and I think it is a helpful document to have. The reason I mentioned the first item could be removed is that use cases are already mentioned in the second item, and as such it looks redundant with the second item. Daniel, Ahh, ok, point taken, I didn't see that. Was trying to work my way through the summarization and missed that. Thanks for pointing that out. --John > > BR, > Daniel > > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of John Schiel > Sent: Tuesday, May 19, 2015 5:37 PM > To: dots@ietf.org > Subject: Re: [Dots] Consolidation of all draft charter feedback > > > > On 05/19/2015 08:13 AM, Daniel Migault wrote: >> Hi, >> >> I suggest to remove the first milestone item: > I kind of like the idea of a use case document as long as the examples are small and concise. It would provide a good reference tool for discussion and for developing the standard. > > Thanks, > > --John > >> OLD >>> * Use case document to ensure commonality of the work among the >>> participants in the Working Group. This document may be determined >>> by the working group to remain informal and not be published. >>> * Document or Documents describing the problem space, use cases, >>> protocol requirements and other qualifying information as the WG sees fit. >>> * Document or Documents specifying a protocol and associated data >>> models to address the WG stated goal. >> NEW >>> * Document or Documents describing the problem space, use cases, >>> protocol requirements and other qualifying information as the WG sees fit. >>> * Document or Documents specifying a protocol and associated data >>> models to address the WG stated goal. >> BR, >> Daniel >> -----Original Message----- >> From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Roman D. >> Danyliw >> Sent: Saturday, May 16, 2015 10:26 PM >> To: dots@ietf.org >> Subject: [Dots] Consolidation of all draft charter feedback >> >> Hello! >> >> There has been robust discussion on the draft charter text (http://www.ietf.org/mail-archive/web/dots/current/msg00077.html). To make it easier to review the draft charter with the benefit of previous feedback, below you can find a summary of all comments to date aggregated inline with corresponding links. >> >> Per Kathleen Moriarty's request (http://www.ietf.org/mail-archive/web/dots/current/msg00074.html), please provide further commentary or statements of support. >> >> Roman >> >> ----[ Aggregated comments on the draft charter ]---- >> >>> The aim of DDoS Open Threat Signaling (DOTS) is to develop a >>> standards based approach to the real time signaling of DDoS related >>> telemetry and >> [Andrew Mortensen] suggested that "real time" signaling is expected >> under attack conditions, and that this detail should be noted >> explicitly in >> http://www.ietf.org/mail-archive/web/dots/current/msg00086.html >> >>> threat handling data between elements concerned with attack mitigation. >>> >>> The elements may be described as: >>> * On-premise DDoS mitigation platforms >>> * Service provider DDoS mitigation platforms >>> * Other network devices/platforms that are able to sense DDoS and >>> respond >> [Adam Montville] suggested to tighten up the language of this third >> bullet in >> http://www.ietf.org/mail-archive/web/dots/current/msg00080.html >> >> -- >> [Nik Teague] proposed to the following text in response to Adam: >> >> "While the resulting standards should be designed so that there¹s a >> possibility of applying them to network security applications beyond >> DDoS mitigation, this working group will focus on just DDoS >> mitigation.² >> >> in http://www.ietf.org/mail-archive/web/dots/current/msg00083.html >> >> -- >> [Xialiang (Frank)] Recommended leaving the third bullet vague pending >> a review of the use cases in >> http://www.ietf.org/mail-archive/web/dots/current/msg00085.html >> >> -- >> [Andrew Mortensen] suggested "Other devices with network perspective performing traffic analysis" or ".engaged in traffic analysis" >> >>> * Chained instances of the above >>> >>> These elements may be communicating inter-domain or intra-domain over >>> links that may be congested by attack traffic resulting in hostile >>> conditions for traditional connection oriented approaches and more >>> generalized signaling >> [Andrew Mortensen] suggested removing "traditional" in >> http://www.ietf.org/mail-archive/web/dots/current/msg00086.html >> >>> and telemetry solutions. Robustness under these conditions is >>> paramount while ensuring appropriate regard for authentication, >>> authorization, privacy and data integrity. Elements may be deployed >>> as part of a wider strategy incorporating multiple points of >>> detection and mitigation, both on premise or service provider based. >>> Should mitigation need to move between elements in the chain then >> [Adam Montville] suggested a comma between "chain" and "then" >> resulting in: "Should mitigation need to move between elements in the >> chain, then." in >> http://www.ietf.org/mail-archive/web/dots/current/msg00080.html >> >> -- >> [Linda Dunbar] sought clarity on whether the following items were in scope: >> * determining the optimal path between DDOS elements determined in >> concert with the Network Management system >> * ensuring the secure channels and congestion status for paths between >> the mitigating devices >> >> In http://www.ietf.org/mail-archive/web/dots/current/msg00081.html >> >> -- >> [Scott Barvick] replied to [Linda Dunbar] on this scope in >> http://www.ietf.org/mail-archive/web/dots/current/msg00082.html >> >> -- >> [Andrew Mo ] sought clarity on whether "... an on-premise device may >> signal laterally intentional? Or is the expectation that each >> subsequent element in the chain will be upstream from the previous?" >> in http://www.ietf.org/mail-archive/web/dots/current/msg00086.html >> >> -- >> [Linda Dunbar] suggested updated text that reads as "These elements >> may be communicating over congested links/paths, with possibility of >> packets loss. Therefore, mechanisms have be considered to compensate >> packets loss to ensure appropriate regard for authentication, >> authorization, privacy and data integrity." In >> http://www.ietf.org/mail-archive/web/dots/current/msg00102.html >> >> -- >> [Scott Barvick] in http://www.ietf.org/mail-archive/web/dots/current/msg00104.html and [Kathleen Moriarty] in http://www.ietf.org/mail-archive/web/dots/current/msg00103.html believe the existing language covers [Linda Dunbar]'s proposal. >> >>> effective signaling of telemetry and current threat handling is essential. >>> Feedback between participating elements is required for increased >>> awareness for effective decision making. >> [Adam Montville] suggested ".required for increased awareness >> supporting effective decision making" in >> http://www.ietf.org/mail-archive/web/dots/current/msg00080.html >> >> -- >> [Xialiang (Frank)] suggested "Feedback and initial capability >> negotiation mechanisms between participating elements is required for >> increased awareness for effective decision making." in >> http://www.ietf.org/mail-archive/web/dots/current/msg00085.html >> >>> The WG will, where appropriate, reuse existing standard protocols and >>> mechanisms, for instance IPFIX and its templating mechanism. >> [Adam Montville] suggested mentioning other working groups in >> http://www.ietf.org/mail-archive/web/dots/current/msg00080.html >> >> -- >> [Andrew ] highlighted the inherent conflict between reusing IPFIX >> (stated here) and the limitation of "traditional connection oriented >> protocols" (stated above in the chart) in >> http://www.ietf.org/mail-archive/web/dots/current/msg00098.html >> >>> The charter of the working group is to produce one or more standards >>> track specification to provide for this open signaling in the DDoS problem space. >> [Adam Montville] suggested making "specification" plural, so that the >> sentence reads: ".to produce one or more standards track >> specifications." in >> http://www.ietf.org/mail-archive/web/dots/current/msg00080.html >> >>> While the resulting standards should be designed so that there¹s a >>> possibility of applying them to network security applications beyond >>> DDoS mitigation, >> [Andrew Mortensen] suggested using ".designed so they may apply to >> network security applications." in >> http://www.ietf.org/mail-archive/web/dots/current/msg00086.html >> >>> this working group will focus on just DDoS mitigation. This >>> streamlined focus >> [Andrew Mortensen] suggested removing "just" in >> http://www.ietf.org/mail-archive/web/dots/current/msg00086.html >> >>> of the charter is intended to lead to an earlier result due to >>> community interests in having such capability in a short timeframe. >>> The specification(s) produced by the WG will include a standard >>> mechanism for authentication and authorization, for data integrity, >>> and for providing for privacy in operation. >>> >>> The WG will produce the following deliverables: >>> >>> * Use case document to ensure commonality of the work among the >>> participants in the Working Group. This document may be determined >>> by the working group to remain informal and not be published. >>> * Document or Documents describing the problem space, use cases, >>> protocol requirements and other qualifying information as the WG sees fit. >>> * Document or Documents specifying a protocol and associated data >>> models to address the WG stated goal. >> [Adam Montville] suggested adding a milestone to review milestones and >> specific dates for these in >> http://www.ietf.org/mail-archive/web/dots/current/msg00080.html >> >> >>> _______________________________________________ >>> Dots mailing list >>> Dots@ietf.org >>> https://www.ietf.org/mailman/listinfo/dots >> _______________________________________________ >> Dots mailing list >> Dots@ietf.org >> https://www.ietf.org/mailman/listinfo/dots >> >> _______________________________________________ >> Dots mailing list >> Dots@ietf.org >> https://www.ietf.org/mailman/listinfo/dots > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Wed May 20 10:02:45 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CCF11A897D for ; Wed, 20 May 2015 10:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 XVcpeDd9jlkU for ; Wed, 20 May 2015 10:02:37 -0700 (PDT) Received: from mail-qg0-f98.google.com (mail-qg0-f98.google.com [209.85.192.98]) (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 1A5711A898E for ; Wed, 20 May 2015 10:02:36 -0700 (PDT) Received: by qgdz60 with SMTP id z60so2418172qgd.0 for ; Wed, 20 May 2015 10:02:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:accept-language:content-language:user-agent:content-type :content-id:content-transfer-encoding:mime-version; bh=GoUw7MT0f0UBTwk07BcHVsPEGROHjLryBjXW09AmK1g=; b=BGHg2GQJ1rWP9IVY42pOlYXl9Wtgkuadms9QFq+JOtnelKwRnHQN37RhcPPnVtItsw SVo7sjZlSQTbIS8f4oEPQzgPPRpYSLz4eubKLX6t9GEYkzGNsOIJ0qAGE5UlFgGV8eOY 3TPZLOtuAqgTwTCICPNIIksofX20vX0ao4OsX6MJVkuzldc+kW7XshPiPN+3DtshBW3E G0KejDJ069FKQp01ZtOtlGOUgEFAMeUoTJxEMJnQa1+rMtetJgMyE+8gVI33IIrEycSY gBPaysCholvTW0X7TGM9FG0374o/PLipY454iE8v8+FkKDpzlU9qFvtWxTB7l06ESBqY ftvQ== X-Gm-Message-State: ALoCoQmAnmGP/USuZxEs8HcAte7otsOcZiSUJLmEtxbnpFMfeEekpG9WLz5M5B5uH11qQ6K9Yj0+0E8nK2z5UebOJ/52HNaPUg== X-Received: by 10.140.36.137 with SMTP id p9mr44289086qgp.16.1432141355279; Wed, 20 May 2015 10:02:35 -0700 (PDT) Received: from brn1lxmailout02.verisign.com (brn1lxmailout02.verisign.com. [72.13.63.42]) by mx.google.com with ESMTPS id hx6sm4453356qcb.1.2015.05.20.10.02.34 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 20 May 2015 10:02:35 -0700 (PDT) X-Relaying-Domain: verisign.com Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02 [10.173.152.206]) by brn1lxmailout02.verisign.com (8.13.8/8.13.8) with ESMTP id t4KH2YwA000864 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 20 May 2015 13:02:34 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Wed, 20 May 2015 13:02:33 -0400 From: "Teague, Nik" To: "dots@ietf.org" Thread-Topic: draft DOTS WG Charter [updated] Thread-Index: AQHQkx7Dqn+0n8uoLUGYnTBjEzWvDQ== Date: Wed, 20 May 2015 17:02:33 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.0.150423 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Dots] draft DOTS WG Charter [updated] X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 17:02:42 -0000 Hi, Please see below an updated draft charter based on the received comments/feedback. The milestone dates are there for discussion and are possibly much more aggressive than strictly necessary but feel free as always to comment. I=B9ve added in Andrew=B9s suggestion for the 3rd element definition which = I think may cover Frank and Ning=B9s concerns. I have deliberately omitted capabilities from the charter as I believe that=B9s something to be discussed in line with requirements/use cases. Thoughts/feedback of course valued and welcome. -Nik =8B[Charter for Working Group]=8B The aim of DDoS Open Threat Signaling (DOTS) is to develop a standards based approach for the real time signaling of DDoS related telemetry and threat handling data between elements concerned with attack mitigation. The elements may be described as: * On-premise DDoS mitigation platforms * Service provider DDoS mitigation platforms * Other devices/platforms with network perspective engaged in traffic analysis The elements may be chained for communication to construct a larger collaborative system. These elements may be communicating inter-domain or intra-domain over links that may be congested by attack traffic resulting in hostile conditions for connection oriented approaches and more generalized signaling and telemetry solutions. Robustness under these conditions is paramount while ensuring appropriate regard for authentication, authorization, privacy and data integrity. Elements may be deployed as part of a wider strategy incorporating multiple points of detection and mitigation, both on premise or service provider based. Should mitigation need to move between elements in the chain, then effective signaling of telemetry and current threat handling is essential. Feedback between participating elements is required for increased awareness supporting effective decision making. The WG will, where appropriate, reuse or extend existing standard protocols and mechanisms, for instance IPFIX and its templating mechanism. The WG may coordinate with other working groups and initiatives that compliment the DOTS effort E.G. SACM, MILE, SUPA, I2NSF. The charter of the working group is to produce one or more standards track specifications to provide for this open signaling in the DDoS problem space. While the resulting standards should be designed so they apply to network security applications beyond DDoS mitigation, this working group will focus on DDoS mitigation. This streamlined focus of the charter is intended to lead to an earlier result due to community interests in having such capability in a short timeframe. The specification(s) produced by the WG will include a standard mechanism for authentication and authorization, for data integrity, and for providing for privacy in operation. The WG will produce the following deliverables and milestones: * Document or Documents describing the problem space, use cases, protocol requirements and other qualifying information as the WG sees fit. * Document or Documents specifying a protocol and associated data models to address the WG stated goal. * Nov-2015: Requirements/use case document as information RFC * Apr-2016: Transport document as proposed standard RFC * May-2016: Data model document as proposed standard RFC * Periodically re-examine/scrutinise milestones (3x month intervals) From nobody Thu May 21 10:58:02 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBF491A007F for ; Thu, 21 May 2015 10:57:59 -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, RCVD_IN_DNSWL_LOW=-0.7] 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 i5Cvm-aAlDAQ for ; Thu, 21 May 2015 10:57:57 -0700 (PDT) Received: from mail-ig0-f182.google.com (mail-ig0-f182.google.com [209.85.213.182]) (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 0FFDB1A006B for ; Thu, 21 May 2015 10:57:57 -0700 (PDT) Received: by igbyr2 with SMTP id yr2so16485197igb.0 for ; Thu, 21 May 2015 10:57:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=4OeaqrfCov9DtDtWNjIMsU7cYb0SUkasB9ldziOND+I=; b=cAinbAPt3NE2tFj8+H1UGuXFg35zb+hxOEB6JQp9aQjGCOpNqqT6AWdwyYtJRG65HF u6UiEbL53RKdMiiRgi6cnaB8sFpPbl0NmU+yQ4nWdDgdU1nGcl0ivpx0BzSCdpowc70D 081/UG7/ClQlfHWXI9g8o+a5qNPMw9Y0e5Unn+eJ4kbHimxmVx7qiKkK0wCN4K6tqu5P oLnud5goYg4QH4i7ITSZC36iE22ED3G8484TFW41UqV3exZaWibi5XUVC16UkqMypqH1 flVmN6mh9d9xkNQl2gkhcvWVcCDFBlbH0OWvv01jrqV12HywzS+fqZXQLz4KqHh3AJmp fR4g== X-Gm-Message-State: ALoCoQnyuvgQdQibICpM+670XxLB9WKtrMPLAtPooHuQuIWRbZsybNF1GTzTu31yFEBRXsnM1NFr X-Received: by 10.50.110.104 with SMTP id hz8mr5571421igb.38.1432231076444; Thu, 21 May 2015 10:57:56 -0700 (PDT) Received: from ?IPv6:2001:428:1:1:ec4:7aff:fe32:71f6? ([2001:428:1:1:ec4:7aff:fe32:71f6]) by mx.google.com with ESMTPSA id z195sm15393232iod.33.2015.05.21.10.57.54 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 May 2015 10:57:55 -0700 (PDT) Message-ID: <555E1CA1.4040903@flowtools.net> Date: Thu, 21 May 2015 11:57:53 -0600 From: John Schiel User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: dots@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Dots] draft DOTS WG Charter [updated] X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 17:57:59 -0000 Looks great, a few nits inline. On 05/20/2015 11:02 AM, Teague, Nik wrote: > Hi, > > Please see below an updated draft charter based on the received > comments/feedback. The milestone dates are there for discussion and are > possibly much more aggressive than strictly necessary but feel free as > always to comment. > > I¹ve added in Andrew¹s suggestion for the 3rd element definition which I > think may cover Frank and Ning¹s concerns. I have deliberately omitted > capabilities from the charter as I believe that¹s something to be > discussed in line with requirements/use cases. > > Thoughts/feedback of course valued and welcome. > > -Nik > > ‹[Charter for Working Group]‹ > > The aim of DDoS Open Threat Signaling (DOTS) is to develop a standards > based approach for the real time signaling of DDoS related telemetry and > threat handling data between elements concerned with attack mitigation. > > The elements may be described as: > * On-premise DDoS mitigation platforms > * Service provider DDoS mitigation platforms > * Other devices/platforms with network perspective engaged in traffic > analysis > > The elements may be chained for communication to construct a larger > collaborative system. > > These elements may be communicating inter-domain or intra-domain over > links that may be congested by attack traffic resulting in hostile > conditions for connection oriented approaches and more generalized > signaling and telemetry solutions. Robustness under these conditions is > paramount while ensuring appropriate regard for authentication, > authorization, privacy and data integrity. Elements may be deployed as > part of a wider strategy incorporating multiple points of detection and > mitigation, both on premise or service provider based. Should mitigation > need to move between elements in the chain, then effective signaling of > telemetry and current threat handling is essential. Feedback between > participating elements is required for increased awareness supporting > effective decision making. > > The WG will, where appropriate, reuse or extend existing standard > protocols and mechanisms, for instance IPFIX and its templating mechanism. > The WG may coordinate with other working groups and initiatives that > compliment the DOTS effort E.G. SACM, MILE, SUPA, I2NSF. > > The charter of the working group is to produce one or more standards track > specifications to provide for this open signaling in the DDoS problem > space. While the resulting standards should be designed so they apply to > network security applications beyond DDoS mitigation, this working group > will focus on DDoS mitigation. This streamlined focus of the charter is > intended to lead to an earlier result due to community interests in having > such capability in a short timeframe. Re "This streamlined..." sentence. I had to read this 3 or 4 times but I think what you are trying to convey is the thought of a streamlined focus in order to get to a standard sooner due to the desire of the community wanting this standard. Is this what you meant? > The specification(s) produced by > the WG will include a standard mechanism for authentication and > authorization, for data integrity, and for providing for privacy in > operation. Don't need all of the 'for' (s) listed above, for applies to all items in the list. Change to: "The specification(s) produced by the WG will include a standard mechanism for authentication and authorization, data integrity, and providing for privacy in operation." --John Schiel > > The WG will produce the following deliverables and milestones: > > * Document or Documents describing the problem space, use cases, protocol > requirements and other qualifying information as the WG sees fit. > * Document or Documents specifying a protocol and associated data models > to address the WG stated goal. > > * Nov-2015: Requirements/use case document as information RFC > * Apr-2016: Transport document as proposed standard RFC > * May-2016: Data model document as proposed standard RFC > > * Periodically re-examine/scrutinise milestones (3x month intervals) > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Fri May 22 07:32:24 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0D411A014D for ; Fri, 22 May 2015 07:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-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 NVxhsB4bIVmk for ; Fri, 22 May 2015 07:32:16 -0700 (PDT) Received: from gateway34.websitewelcome.com (gateway34.websitewelcome.com [192.185.148.222]) (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 F21CC1B29A2 for ; Fri, 22 May 2015 07:32:15 -0700 (PDT) Received: by gateway34.websitewelcome.com (Postfix, from userid 500) id 736DF13296E4B; Fri, 22 May 2015 09:32:15 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway34.websitewelcome.com (Postfix) with ESMTP id 646C413296E12 for ; Fri, 22 May 2015 09:32:15 -0500 (CDT) Received: from [173.73.121.66] (port=58343 helo=[192.168.1.6]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Yvnzi-0002qq-Ow for dots@ietf.org; Fri, 22 May 2015 09:32:14 -0500 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Turner In-Reply-To: <555E1CA1.4040903@flowtools.net> Date: Fri, 22 May 2015 10:32:13 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <555E1CA1.4040903@flowtools.net> To: dots@ietf.org X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 173.73.121.66 X-Exim-ID: 1Yvnzi-0002qq-Ow X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.6]) [173.73.121.66]:58343 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: Subject: Re: [Dots] draft DOTS WG Charter [updated] X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 14:32:23 -0000 On May 21, 2015, at 13:57, John Schiel wrote: > Looks great, a few nits inline. >=20 > On 05/20/2015 11:02 AM, Teague, Nik wrote: >> Hi, >>=20 >> Please see below an updated draft charter based on the received >> comments/feedback. The milestone dates are there for discussion and = are >> possibly much more aggressive than strictly necessary but feel free = as >> always to comment. >>=20 >> I=B9ve added in Andrew=B9s suggestion for the 3rd element definition = which I >> think may cover Frank and Ning=B9s concerns. I have deliberately = omitted >> capabilities from the charter as I believe that=B9s something to be >> discussed in line with requirements/use cases. >>=20 >> Thoughts/feedback of course valued and welcome. >>=20 >> -Nik >>=20 >> =8B[Charter for Working Group]=8B >>=20 >> The aim of DDoS Open Threat Signaling (DOTS) is to develop a = standards >> based approach for the real time signaling of DDoS related telemetry = and >> threat handling data between elements concerned with attack = mitigation. >>=20 >> The elements may be described as: >> * On-premise DDoS mitigation platforms >> * Service provider DDoS mitigation platforms >> * Other devices/platforms with network perspective engaged in traffic >> analysis >>=20 >> The elements may be chained for communication to construct a larger >> collaborative system. >>=20 >> These elements may be communicating inter-domain or intra-domain over >> links that may be congested by attack traffic resulting in hostile >> conditions for connection oriented approaches and more generalized >> signaling and telemetry solutions. Robustness under these conditions = is >> paramount while ensuring appropriate regard for authentication, >> authorization, privacy and data integrity. Elements may be deployed = as >> part of a wider strategy incorporating multiple points of detection = and >> mitigation, both on premise or service provider based. Should = mitigation >> need to move between elements in the chain, then effective signaling = of >> telemetry and current threat handling is essential. Feedback between >> participating elements is required for increased awareness supporting >> effective decision making. >>=20 >> The WG will, where appropriate, reuse or extend existing standard >> protocols and mechanisms, for instance IPFIX and its templating = mechanism. >> The WG may coordinate with other working groups and initiatives that >> compliment the DOTS effort E.G. SACM, MILE, SUPA, I2NSF. >>=20 >> The charter of the working group is to produce one or more standards = track >> specifications to provide for this open signaling in the DDoS problem >> space. While the resulting standards should be designed so they = apply to >> network security applications beyond DDoS mitigation, this working = group >> will focus on DDoS mitigation. This streamlined focus of the charter = is >> intended to lead to an earlier result due to community interests in = having >> such capability in a short timeframe. >=20 > Re "This streamlined..." sentence. I had to read this 3 or 4 times but = I think what you are trying to convey is the thought of a streamlined = focus in order to get to a standard sooner due to the desire of the = community wanting this standard. Is this what you meant? I hope it=92s saying the WG is going to concentrate on DDoS to get = something done sooner rather than later or in IETF parlance we=92re = doing it to avoid boiling the ocean. How about: Focusing the WG=92s efforts on DDoS is intended to meet the community=92s desire for solution in the shorter term. Alternatively I could see dropping the last sentence and adding the = phrase =93to avoid boiling the ocean=94 to the penultimate sentence ;) >> The specification(s) produced by >> the WG will include a standard mechanism for authentication and >> authorization, for data integrity, and for providing for privacy in >> operation. >=20 > Don't need all of the 'for' (s) listed above, for applies to all items = in the list. >=20 > Change to: >=20 > "The specification(s) produced by the WG will include a standard = mechanism > for authentication and authorization, data integrity, and providing > for privacy in operation." >=20 > --John Schiel >=20 >>=20 >> The WG will produce the following deliverables and milestones: >>=20 >> * Document or Documents describing the problem space, use cases, = protocol >> requirements and other qualifying information as the WG sees fit. >> * Document or Documents specifying a protocol and associated data = models >> to address the WG stated goal. >>=20 >> * Nov-2015: Requirements/use case document as information RFC >> * Apr-2016: Transport document as proposed standard RFC >> * May-2016: Data model document as proposed standard RFC >>=20 >> * Periodically re-examine/scrutinise milestones (3x month intervals) I=92d tweak the milestones to be when the drafts are expected to be = adopted by the and when they are expected to get to the IESG. After it = gets to the IESG, the timeline is pretty much out of the WG=92s hands: Date - WG document for Requirements/Use Cases (informational) Date - WG document for Transport (proposed standard) Date - WG document for Data Model (proposed standard) Date - Requirements/Use Cases draft to IESG Date - Transport draft to IESG Date - Data Model draft to IESG lgtm otherwise spt >> _______________________________________________ >> Dots mailing list >> Dots@ietf.org >> https://www.ietf.org/mailman/listinfo/dots >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From andy.huangzhigang@huawei.com Fri May 29 02:33:31 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1AF31B2AB3 for ; Fri, 29 May 2015 02:33:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.76 X-Spam-Level: X-Spam-Status: No, score=-1.76 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 M1p6vsjxSLkK for ; Fri, 29 May 2015 02:33: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 26CBE1B2AB0 for ; Fri, 29 May 2015 02:33:29 -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 BTC14588; Fri, 29 May 2015 09:33:27 +0000 (GMT) Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 29 May 2015 10:33:21 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.89]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Fri, 29 May 2015 17:33:15 +0800 From: "Huangzhigang (Andy)" To: "dots@ietf.org" Thread-Topic: is there a need to get SoC involved in the scenario? Thread-Index: AdCZ8nsdOwVGx8mAQ3Kc4xjjs9Oo1Q== Date: Fri, 29 May 2015 09:33:14 +0000 Message-ID: <642E47958E505F41805A4E023120F0B46E12E04E@nkgeml501-mbs.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-cr-hashedpuzzle: AsMw Av6v BXNB BfXH CtbO CxAk C5Kv Dfsq EEMM EgDK FquF GFOc HsIW ICYx IL39 IaIT; 1; ZABvAHQAcwBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {E12F34ED-0527-4C5D-8EBE-D6CC4EB5BAA3}; YQBuAGQAeQAuAGgAdQBhAG4AZwB6AGgAaQBnAGEAbgBnAEAAaAB1AGEAdwBlAGkALgBjAG8AbQA=; Fri, 29 May 2015 09:33:12 GMT; aQBzACAAdABoAGUAcgBlACAAYQAgAG4AZQBlAGQAIAB0AG8AIABnAGUAdAAgAFMAbwBDACAAaQBuAHYAbwBsAHYAZQBkACAAaQBuACAAdABoAGUAIABzAGMAZQBuAGEAcgBpAG8APwA= x-cr-puzzleid: {E12F34ED-0527-4C5D-8EBE-D6CC4EB5BAA3} x-originating-ip: [10.138.43.21] Content-Type: multipart/related; boundary="_004_642E47958E505F41805A4E023120F0B46E12E04Enkgeml501mbschi_"; type="multipart/alternative" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Dots] is there a need to get SoC involved in the scenario? X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2015 09:35:22 -0000 --_004_642E47958E505F41805A4E023120F0B46E12E04Enkgeml501mbschi_ Content-Type: multipart/alternative; boundary="_000_642E47958E505F41805A4E023120F0B46E12E04Enkgeml501mbschi_" --_000_642E47958E505F41805A4E023120F0B46E12E04Enkgeml501mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkNCg0KSSBoYXZlIGEgcXVlc3Rpb24gaGVyZSwgaXMgRE9UUyBsaW1pdGVkIHRvIGludGVyZmFj ZSBiZXR3ZWVuIG9uLXByZW1pc2UgYW5kIGNsb3VkIEREb1MgZGV0ZWN0aW9uL21pdGlnYXRpb24g ZXF1aXBtZW50PyBJcyB0aGVyZSBhIG5lZWQgdG8gZ2V0IHNvbWUga2luZCBvZiBtYW5hZ2VtZW50 IHN5c3RlbSBsaWtlIFNvQyBpbnZvbHZlZCBpbiwgaXQgY291bGQgaGVscCBvbi1wcmVtaXNlIGFu ZCBjbG91ZCBERG9TIGVxdWlwbWVudCB0byBkaXNjb3ZlciBlYWNoIG90aGVyLCBhbmQgaXQgY291 bGQgcHJvdmlkZSBzb21lIHBvbGljeSB0byBzZWxlY3QgdGhlIGJlc3Qgb25lICBpbiBjYXNlIHRo ZXJlIGFyZSBtdWx0aXBsZSBDbG91ZCBERG9TIG1pdGlnYXRpb24gY2VudGVyIGxvY2F0ZWQgaW4g dGhlIGRpZmZlcmVudCBhcmVhLg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkFu ZHkgSHVhbmcgKFpoaWdhbmcgSHVhbmcsILvG1r641ikNCk5ldHdvcmsgUmVzZWFyY2ggRGVwYXJ0 bWVudCwgSHVhd2VpIFRlY2hub2xvZ2llcyBDby4sIEx0ZC4NCkFkZHJlc3M6IEh1YXdlaSBUZWNo bm9sb2dpZXMsIE5vIDEwMSwgc29mdHdhcmUgQXZlbnVlLCBZdWh1YSBEaXN0cmljdCwgTmFuamlu Zw0KVGVsZXBob25lOiA4Ni0wMjUtNTY2MjQ0ODENCk1vYmlsZTogODYtMTM4MTM5MDcyNDUNCg0K W0NvbXBhbnlfbG9nb10NCg0KDQo= --_000_642E47958E505F41805A4E023120F0B46E12E04Enkgeml501mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi

 

I have a question here, is DOTS limited to interface= between on-premise and cloud DDoS detection/mitigation equipment? Is there= a need to get some kind of management system like SoC involved in, it coul= d help on-premise and cloud DDoS equipment to discover each other, and it could provide some policy to select the bes= t one  in case there are multiple Cloud DDoS mitigation center located= in the different area.

 

 

-----------------------------= --------------------------------------------------------<= /p>

Andy Huang (Zhigang Huang, =BB=C6=D6=BE=B8=D6)

Network Research Department, = Huawei Technologies Co., Ltd.

Address: Huawei Technologies,= No 101, software Avenue, Yuhua District, Nanjing

Telephone: 86-025-56624481

Mobile: 86-13813907245


3D"Company_logo"

 

--_000_642E47958E505F41805A4E023120F0B46E12E04Enkgeml501mbschi_-- --_004_642E47958E505F41805A4E023120F0B46E12E04Enkgeml501mbschi_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=6737; creation-date="Fri, 29 May 2015 09:33:14 GMT"; modification-date="Fri, 29 May 2015 09:33:14 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/7QxmUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA AAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAIASAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAA AAA/gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAA AAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgAB AGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0A AAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD///////// ////////////////////A+gAADhCSU0EAAAAAAAAAgAAOEJJTQQCAAAAAAACAAA4QklNBDAAAAAA AAEBADhCSU0ELQAAAAAABgABAAAABjhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4A AAAAAAQAAAAAOEJJTQQaAAAAAAM9AAAABgAAAAAAAAAAAAAAIAAAAGYAAAAEAGwAbwBnAG8AAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAGYAAAAgAAAAAAAAAAAAAAAAAAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAA AFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAg AAAAAFJnaHRsb25nAAAAZgAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAAS AAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxF U2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAA AEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAA TGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAIAAAAABSZ2h0bG9uZwAAAGYAAAADdXJsVEVYVAAA AAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAA AQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpB bGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAA AA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNl QkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9u ZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4QklN BCgAAAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAg4QklNBAwA AAAABnAAAAABAAAAZgAAACAAAAE0AAAmgAAABlQAGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAM QWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUT ExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMB IgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEB AAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSR obFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSF tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIR AyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVV NnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEA AhEDEQA/APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC6 6f56f3t30Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUs VaDHl/dl/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5Vtns U/qp1vqPUvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9 w9+kqfV+qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVh fWLCzerW9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX 146P1azqFWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKeh SWDk/XHpVHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8t bvSU9Ikucy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uo JBeNpMtfRc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxb qtG20uI0PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv /QXjOu9COI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5F ztrrn/usXoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4 HX+6yY/jQHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v 6hNyW9Q6jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m +u1tQc9n0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6 tfRj2YnTgMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJ JT5b0bpfUrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6r WuLnfpNjXu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z OEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBB AGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwAyAAAAAQA4QklNBAYAAAAAAAcABQAA AAEBAP/hB4ZFeGlmAABJSSoACAAAAAcAEgEDAAEAAAABAAAAGgEFAAEAAABiAAAAGwEFAAEAAABq AAAAKAEDAAEAAAACAAAAMQECABwAAAByAAAAMgECABQAAACOAAAAaYcEAAEAAACiAAAAzAAAAID8 CgAQJwAAgPwKABAnAABBZG9iZSBQaG90b3Nob3AgQ1MyIFdpbmRvd3MAMjAwNzowMjoyNiAxNjox ODo1MwADAAGgAwABAAAA/////wKgBAABAAAAZgAAAAOgBAABAAAAIAAAAAAAAAAGAAMBAwABAAAA BgAAABoBBQABAAAAGgEAABsBBQABAAAAIgEAACgBAwABAAAAAgAAAAECBAABAAAAKgEAAAICBAAB AAAAVAYAAAAAAABIAAAAAQAAAEgAAAABAAAA/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVf Q00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMBIgACEQED EQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0 pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/ APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC66f56f3t3 0Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUsVaDHl/dl /X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5VtnsU/qp1vqP UvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9w9+kqfV+ qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVhfWLCzerW 9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX146P1azq FWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKehSWDk/XHp VHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8tbvSU9Iku cy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uoJBeNpMtf Rc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxbqtG20uI0 PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv/QXjOu9C OI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5Fztrrn/us XoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4HX+6yY/j QHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v6hNyW9Q6 jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m+u1tQc9n 0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6tfRj2YnT gMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJJT5b0bpf UrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6rWuLnfpNj Xu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z/9sAQwAI BgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04 MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAIABmAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAA AAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGh CCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp anN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV 1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkK C//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy 0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKD hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm 5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A99LKCASAT0FcOvxDin8XjRre2Bt1l8mS4Zud3Tge ma5X4j67qukeObG5hdkhto1e3H8L5+9n1z0rnriVIvF9pqdmP9E1CdLiPn7pLDcp9wcj8q8+vimn yx0sz6zLsihOj7WtrzxbXk/87a/f2PazrqpqL27oBEsnlhwec+4rYyCSM8jtXj0OupJ4hvZbhytr aSvNOfYHhfqTgVJ4G8R6nrfxAuLklzbTRMZlz8qKPu/THSnSxT5rS1u9Dlr5HNU5VVooxu/8vX/g dz1+iszX9at/Dug3mr3Su9vax+Y4jGWI9qz9U8ZafpXgtfFE0U7WTQpKEVRvw2McZ967z506Oiuf 03xbY6n4juNDhjmFzBaR3bMw+Xa4BA+vIp2leKrHV9d1nSIElSfSXVJ2cAKdwyMH8KAN6iuM0P4l 6J4hn1eDTkuJJdNRpCpUAzICQWTnkZFK/wASdEj8Ar4wInNiSF8sKPMD7tu3GcZBoA7KiuSu/iDo 9p4NsvE22eW0vWRII41BkZ2OAuM9Rg/lVbUviXptnq82lWem6pql7bgfaUsbfzBCT2Y5xn2oA7ai uB134q6V4b0nTb7VdM1K3N/v2W7xASJtOPmGeOtFAHnupab4l8P3s+kX+nT6ro/mFoCVLgAngo45 RvUfpWr4a8NnUmFrB5qwxyrcol0hSS3YEZB7MrDjI74r0TxX4MtPFSRNLd3VpcRcLNbyEHHcEdDV zQPDGn+G7XyrNZHdv9ZPM5d3+p/oK4/q153ex9Is9ccNyrSfktL93/wN+uh5n4m8NNp8ssEvm+Rc TtcyC2QvJOSTtUDsqjue5NZumaX4h1meLStP06fTNLLgzHaV3Ad3c8sfbp7V7Frnh6w8QWohvEcM v3JYmKun0P8AjVHwx4PtfDJleO7urueQYMk75wvoB0FTLC+/psa0s/UcLaWtRbXWl++/57dNCp8S reR/hjrlvBG8shtNqqilmbkdhXmniXwPqEPweS7XW/EFzKbWE/2dI+6MHjK7MZwP6V73RXcfLHj8 V+3g34ivrOq2F9/ZmoaPbwx3MFu0oWRAMqwUZB4rDe/1hIPGWsaXpl/HJ4lu4rPTPMhZXIwQ0hGM qAO59a98ooA8Fl0Dxb4DvvDmuXNnp8tlpiiwnTTUdpJIHPJcEc4Jzx3pkOgagvj2HwV9gmfw+dY/ thZmQ+X5XllvLPGOuePWvfaKAPBfD2iapL48svB91ZTLpGhalPqKTsp2SKeY1B6cE5/Oqg0u58Le LfEMes33imwjvLs3FvcaOheKdSSfmwCcjOK+haKAPm34sWlxqvhPwrJpi6zqcY8/M13CxnPzD74x ke3tRX0lRQB//9k= --_004_642E47958E505F41805A4E023120F0B46E12E04Enkgeml501mbschi_-- From nobody Fri May 29 02:40:41 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09BDA1B2AB7 for ; Fri, 29 May 2015 02:40:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.76 X-Spam-Level: X-Spam-Status: No, score=-1.76 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 c4a5kxSIeBOP for ; Fri, 29 May 2015 02:40:38 -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 C4B141B2AB5 for ; Fri, 29 May 2015 02:40:37 -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 BWQ58022; Fri, 29 May 2015 09:40:35 +0000 (GMT) Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 29 May 2015 10:38:52 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.89]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Fri, 29 May 2015 17:38:49 +0800 From: "Huangzhigang (Andy)" To: "dots@ietf.org" Thread-Topic: is there a need to get SoC involved in the scenario? Thread-Index: AdCZ80KVrFGd643yT0SHWzbmsKm/Mw== Date: Fri, 29 May 2015 09:38:48 +0000 Message-ID: <642E47958E505F41805A4E023120F0B46E12E095@nkgeml501-mbs.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-cr-hashedpuzzle: AK3W A63x BxcD B2lA CdVL DitQ FrU7 FuDh GYa5 GjTV G21f HjHo Iszk Jiiw KawM Kn6h; 1; ZABvAHQAcwBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {6B0941D8-B19D-4EF4-93E9-C6031B96CC6A}; YQBuAGQAeQAuAGgAdQBhAG4AZwB6AGgAaQBnAGEAbgBnAEAAaAB1AGEAdwBlAGkALgBjAG8AbQA=; Fri, 29 May 2015 09:38:46 GMT; aQBzACAAdABoAGUAcgBlACAAYQAgAG4AZQBlAGQAIAB0AG8AIABnAGUAdAAgAFMAbwBDACAAaQBuAHYAbwBsAHYAZQBkACAAaQBuACAAdABoAGUAIABzAGMAZQBuAGEAcgBpAG8APwA= x-cr-puzzleid: {6B0941D8-B19D-4EF4-93E9-C6031B96CC6A} x-originating-ip: [10.138.43.21] Content-Type: multipart/related; boundary="_004_642E47958E505F41805A4E023120F0B46E12E095nkgeml501mbschi_"; type="multipart/alternative" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Dots] is there a need to get SoC involved in the scenario? X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2015 09:40:40 -0000 --_004_642E47958E505F41805A4E023120F0B46E12E095nkgeml501mbschi_ Content-Type: multipart/alternative; boundary="_000_642E47958E505F41805A4E023120F0B46E12E095nkgeml501mbschi_" --_000_642E47958E505F41805A4E023120F0B46E12E095nkgeml501mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkNCg0KSSBoYXZlIGEgcXVlc3Rpb24gaGVyZSwgaXMgRE9UUyBsaW1pdGVkIHRvIGludGVyZmFj ZSBiZXR3ZWVuIG9uLXByZW1pc2UgYW5kIGNsb3VkIEREb1MgZGV0ZWN0aW9uL21pdGlnYXRpb24g ZXF1aXBtZW50PyBJcyB0aGVyZSBhIG5lZWQgdG8gZ2V0IHNvbWUga2luZCBvZiBtYW5hZ2VtZW50 IHN5c3RlbSBsaWtlIFNvQyBpbnZvbHZlZCBpbiwgaXQgY291bGQgaGVscCBvbi1wcmVtaXNlIGFu ZCBjbG91ZCBERG9TIGVxdWlwbWVudCB0byBkaXNjb3ZlciBlYWNoIG90aGVyLCBhbmQgaXQgY291 bGQgcHJvdmlkZSBzb21lIHBvbGljeSB0byBzZWxlY3QgdGhlIGJlc3Qgb25lICBpbiBjYXNlIHRo ZXJlIGFyZSBtdWx0aXBsZSBDbG91ZCBERG9TIG1pdGlnYXRpb24gY2VudGVyIGxvY2F0ZWQgaW4g dGhlIGRpZmZlcmVudCBhcmVhLg0KDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQpBbmR5IEh1YW5nIChaaGlnYW5nIEh1YW5nLCC7xta+uNYpDQpOZXR3b3JrIFJlc2VhcmNoIERl cGFydG1lbnQsIEh1YXdlaSBUZWNobm9sb2dpZXMgQ28uLCBMdGQuDQpBZGRyZXNzOiBIdWF3ZWkg VGVjaG5vbG9naWVzLCBObyAxMDEsIHNvZnR3YXJlIEF2ZW51ZSwgWXVodWEgRGlzdHJpY3QsIE5h bmppbmcNClRlbGVwaG9uZTogODYtMDI1LTU2NjI0NDgxDQpNb2JpbGU6IDg2LTEzODEzOTA3MjQ1 DQoNCltDb21wYW55X2xvZ29dDQoNCg0K --_000_642E47958E505F41805A4E023120F0B46E12E095nkgeml501mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi

 

I have a question here, is DOTS limited to interface= between on-premise and cloud DDoS detection/mitigation equipment? Is there= a need to get some kind of management system like SoC involved in, it coul= d help on-premise and cloud DDoS equipment to discover each other, and it could provide some policy to select the bes= t one  in case there are multiple Cloud DDoS mitigation center located= in the different area.

 

 

 

 

-----------------------------= --------------------------------------------------------<= /p>

Andy Huang (Zhigang Huang, =BB=C6=D6=BE=B8=D6)

Network Research Department, = Huawei Technologies Co., Ltd.

Address: Huawei Technologies,= No 101, software Avenue, Yuhua District, Nanjing

Telephone: 86-025-56624481

Mobile: 86-13813907245


3D"Company_logo"

 

--_000_642E47958E505F41805A4E023120F0B46E12E095nkgeml501mbschi_-- --_004_642E47958E505F41805A4E023120F0B46E12E095nkgeml501mbschi_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=6737; creation-date="Fri, 29 May 2015 09:38:48 GMT"; modification-date="Fri, 29 May 2015 09:38:48 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/7QxmUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA AAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAIASAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAA AAA/gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAA AAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgAB AGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0A AAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD///////// ////////////////////A+gAADhCSU0EAAAAAAAAAgAAOEJJTQQCAAAAAAACAAA4QklNBDAAAAAA AAEBADhCSU0ELQAAAAAABgABAAAABjhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4A AAAAAAQAAAAAOEJJTQQaAAAAAAM9AAAABgAAAAAAAAAAAAAAIAAAAGYAAAAEAGwAbwBnAG8AAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAGYAAAAgAAAAAAAAAAAAAAAAAAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAA AFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAg AAAAAFJnaHRsb25nAAAAZgAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAAS AAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxF U2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAA AEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAA TGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAIAAAAABSZ2h0bG9uZwAAAGYAAAADdXJsVEVYVAAA AAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAA AQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpB bGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAA AA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNl QkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9u ZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4QklN BCgAAAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAg4QklNBAwA AAAABnAAAAABAAAAZgAAACAAAAE0AAAmgAAABlQAGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAM QWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUT ExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMB IgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEB AAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSR obFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSF tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIR AyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVV NnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEA AhEDEQA/APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC6 6f56f3t30Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUs VaDHl/dl/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5Vtns U/qp1vqPUvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9 w9+kqfV+qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVh fWLCzerW9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX 146P1azqFWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKeh SWDk/XHpVHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8t bvSU9Ikucy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uo JBeNpMtfRc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxb qtG20uI0PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv /QXjOu9COI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5F ztrrn/usXoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4 HX+6yY/jQHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v 6hNyW9Q6jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m +u1tQc9n0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6 tfRj2YnTgMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJ JT5b0bpfUrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6r WuLnfpNjXu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z OEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBB AGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwAyAAAAAQA4QklNBAYAAAAAAAcABQAA AAEBAP/hB4ZFeGlmAABJSSoACAAAAAcAEgEDAAEAAAABAAAAGgEFAAEAAABiAAAAGwEFAAEAAABq AAAAKAEDAAEAAAACAAAAMQECABwAAAByAAAAMgECABQAAACOAAAAaYcEAAEAAACiAAAAzAAAAID8 CgAQJwAAgPwKABAnAABBZG9iZSBQaG90b3Nob3AgQ1MyIFdpbmRvd3MAMjAwNzowMjoyNiAxNjox ODo1MwADAAGgAwABAAAA/////wKgBAABAAAAZgAAAAOgBAABAAAAIAAAAAAAAAAGAAMBAwABAAAA BgAAABoBBQABAAAAGgEAABsBBQABAAAAIgEAACgBAwABAAAAAgAAAAECBAABAAAAKgEAAAICBAAB AAAAVAYAAAAAAABIAAAAAQAAAEgAAAABAAAA/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVf Q00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMBIgACEQED EQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0 pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/ APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC66f56f3t3 0Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUsVaDHl/dl /X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5VtnsU/qp1vqP UvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9w9+kqfV+ qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVhfWLCzerW 9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX146P1azq FWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKehSWDk/XHp VHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8tbvSU9Iku cy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uoJBeNpMtf Rc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxbqtG20uI0 PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv/QXjOu9C OI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5Fztrrn/us XoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4HX+6yY/j QHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v6hNyW9Q6 jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m+u1tQc9n 0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6tfRj2YnT gMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJJT5b0bpf UrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6rWuLnfpNj Xu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z/9sAQwAI BgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04 MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAIABmAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAA AAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGh CCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp anN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV 1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkK C//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy 0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKD hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm 5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A99LKCASAT0FcOvxDin8XjRre2Bt1l8mS4Zud3Tge ma5X4j67qukeObG5hdkhto1e3H8L5+9n1z0rnriVIvF9pqdmP9E1CdLiPn7pLDcp9wcj8q8+vimn yx0sz6zLsihOj7WtrzxbXk/87a/f2PazrqpqL27oBEsnlhwec+4rYyCSM8jtXj0OupJ4hvZbhytr aSvNOfYHhfqTgVJ4G8R6nrfxAuLklzbTRMZlz8qKPu/THSnSxT5rS1u9Dlr5HNU5VVooxu/8vX/g dz1+iszX9at/Dug3mr3Su9vax+Y4jGWI9qz9U8ZafpXgtfFE0U7WTQpKEVRvw2McZ967z506Oiuf 03xbY6n4juNDhjmFzBaR3bMw+Xa4BA+vIp2leKrHV9d1nSIElSfSXVJ2cAKdwyMH8KAN6iuM0P4l 6J4hn1eDTkuJJdNRpCpUAzICQWTnkZFK/wASdEj8Ar4wInNiSF8sKPMD7tu3GcZBoA7KiuSu/iDo 9p4NsvE22eW0vWRII41BkZ2OAuM9Rg/lVbUviXptnq82lWem6pql7bgfaUsbfzBCT2Y5xn2oA7ai uB134q6V4b0nTb7VdM1K3N/v2W7xASJtOPmGeOtFAHnupab4l8P3s+kX+nT6ro/mFoCVLgAngo45 RvUfpWr4a8NnUmFrB5qwxyrcol0hSS3YEZB7MrDjI74r0TxX4MtPFSRNLd3VpcRcLNbyEHHcEdDV zQPDGn+G7XyrNZHdv9ZPM5d3+p/oK4/q153ex9Is9ccNyrSfktL93/wN+uh5n4m8NNp8ssEvm+Rc TtcyC2QvJOSTtUDsqjue5NZumaX4h1meLStP06fTNLLgzHaV3Ad3c8sfbp7V7Frnh6w8QWohvEcM v3JYmKun0P8AjVHwx4PtfDJleO7urueQYMk75wvoB0FTLC+/psa0s/UcLaWtRbXWl++/57dNCp8S reR/hjrlvBG8shtNqqilmbkdhXmniXwPqEPweS7XW/EFzKbWE/2dI+6MHjK7MZwP6V73RXcfLHj8 V+3g34ivrOq2F9/ZmoaPbwx3MFu0oWRAMqwUZB4rDe/1hIPGWsaXpl/HJ4lu4rPTPMhZXIwQ0hGM qAO59a98ooA8Fl0Dxb4DvvDmuXNnp8tlpiiwnTTUdpJIHPJcEc4Jzx3pkOgagvj2HwV9gmfw+dY/ thZmQ+X5XllvLPGOuePWvfaKAPBfD2iapL48svB91ZTLpGhalPqKTsp2SKeY1B6cE5/Oqg0u58Le LfEMes33imwjvLs3FvcaOheKdSSfmwCcjOK+haKAPm34sWlxqvhPwrJpi6zqcY8/M13CxnPzD74x ke3tRX0lRQB//9k= --_004_642E47958E505F41805A4E023120F0B46E12E095nkgeml501mbschi_-- From nobody Fri May 29 08:02:45 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E17481A924A for ; Fri, 29 May 2015 08:02:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.15 X-Spam-Level: X-Spam-Status: No, score=-0.15 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, SPF_HELO_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 RUYN-aORgtRB for ; Fri, 29 May 2015 08:02:40 -0700 (PDT) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.99]) (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 888481A9231 for ; Fri, 29 May 2015 08:02:39 -0700 (PDT) Received: from [216.82.253.243] by server-3.bemta-7.messagelabs.com id AF/76-47069-E8F78655; Fri, 29 May 2015 15:02:38 +0000 X-Env-Sender: Scott.Barvick@corero.com X-Msg-Ref: server-7.tower-171.messagelabs.com!1432911750!17372017!1 X-Originating-IP: [71.184.227.49] X-StarScan-Received: X-StarScan-Version: 6.13.15; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2317 invoked from network); 29 May 2015 15:02:35 -0000 Received: from mercury.corero.com (HELO MERCURY.corero.com) (71.184.227.49) by server-7.tower-171.messagelabs.com with AES128-SHA encrypted SMTP; 29 May 2015 15:02:35 -0000 Received: from MERCURY.corero.com ([fe80::2c05:6b26:abe2:ad24]) by MERCURY.corero.com ([fe80::2c05:6b26:abe2:ad24%19]) with mapi id 14.03.0224.002; Fri, 29 May 2015 10:50:00 -0400 From: Scott Barvick To: "Huangzhigang (Andy)" , "dots@ietf.org" Thread-Topic: [Dots] is there a need to get SoC involved in the scenario? Thread-Index: AQHQmh68fkEtWfgiU0uEfofxif1UtQ== Date: Fri, 29 May 2015 14:49:59 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.0.150423 x-originating-ip: [192.168.60.124] Content-Type: multipart/mixed; boundary="_004_D18DE23B1729Dscottbarvickcorerocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] is there a need to get SoC involved in the scenario? X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2015 15:02:44 -0000 --_004_D18DE23B1729Dscottbarvickcorerocom_ Content-Type: multipart/alternative; boundary="_000_D18DE23B1729Dscottbarvickcorerocom_" --_000_D18DE23B1729Dscottbarvickcorerocom_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 QW5keSwNCg0KRE9UUyBpcyBvbmUgb3IgbW9yZSBpbnRlcmZhY2VzIHRoYXQgY2FuIGJlIGltcGxl bWVudGVkIGluIGFueSB0eXBlIG9mIGVxdWlwbWVudCB0aGF0IHdhbnRzIHRvIGJlIGVpdGhlciBz aWRlIG9mIHRoZSBpbnRlcmZhY2UuICAgSXQgd291bGQgbWFrZSBzZW5zZSB0byBtZSB0aGF0IHRo ZSB1cHN0cmVhbSBzaWRlIGNvdWxkIGJlIGEgbWFuYWdlbWVudCBzeXN0ZW0gaW4gYSBTb0MuICAg ICBIb3cgdGhlIGVuZHBvaW50cyBkaXNjb3ZlciBvciBzZWxlY3QgZWFjaCBvdGhlciBhZnRlciBk aXNjb3Zlcnkgc2VlbXMgbGlrZSBzb21ldGhpbmcgdG8gYmUgZGlzY3Vzc2VkLCBldmVuIGlmIHdl IGVuZCB1cCBzdGFydGluZyB3aXRoIGEgc3RhdGljIG1lY2hhbmlzbSBpbml0aWFsbHkuDQoNClNj b3R0DQoNCkZyb206ICJIdWFuZ3poaWdhbmcgKEFuZHkpIiA8YW5keS5odWFuZ3poaWdhbmdAaHVh d2VpLmNvbTxtYWlsdG86YW5keS5odWFuZ3poaWdhbmdAaHVhd2VpLmNvbT4+DQpEYXRlOiBGcmlk YXksIE1heSAyOSwgMjAxNSBhdCA1OjM4IEFNDQpUbzogImRvdHNAaWV0Zi5vcmc8bWFpbHRvOmRv dHNAaWV0Zi5vcmc+IiA8ZG90c0BpZXRmLm9yZzxtYWlsdG86ZG90c0BpZXRmLm9yZz4+DQpTdWJq ZWN0OiBbRG90c10gaXMgdGhlcmUgYSBuZWVkIHRvIGdldCBTb0MgaW52b2x2ZWQgaW4gdGhlIHNj ZW5hcmlvPw0KDQpIaQ0KDQpJIGhhdmUgYSBxdWVzdGlvbiBoZXJlLCBpcyBET1RTIGxpbWl0ZWQg dG8gaW50ZXJmYWNlIGJldHdlZW4gb24tcHJlbWlzZSBhbmQgY2xvdWQgRERvUyBkZXRlY3Rpb24v bWl0aWdhdGlvbiBlcXVpcG1lbnQ/IElzIHRoZXJlIGEgbmVlZCB0byBnZXQgc29tZSBraW5kIG9m IG1hbmFnZW1lbnQgc3lzdGVtIGxpa2UgU29DIGludm9sdmVkIGluLCBpdCBjb3VsZCBoZWxwIG9u LXByZW1pc2UgYW5kIGNsb3VkIEREb1MgZXF1aXBtZW50IHRvIGRpc2NvdmVyIGVhY2ggb3RoZXIs IGFuZCBpdCBjb3VsZCBwcm92aWRlIHNvbWUgcG9saWN5IHRvIHNlbGVjdCB0aGUgYmVzdCBvbmUg IGluIGNhc2UgdGhlcmUgYXJlIG11bHRpcGxlIENsb3VkIEREb1MgbWl0aWdhdGlvbiBjZW50ZXIg bG9jYXRlZCBpbiB0aGUgZGlmZmVyZW50IGFyZWEuDQoNCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCkFuZHkgSHVhbmcgKFpoaWdhbmcgSHVhbmcsILvG1r641ikNCk5ldHdvcmsg UmVzZWFyY2ggRGVwYXJ0bWVudCwgSHVhd2VpIFRlY2hub2xvZ2llcyBDby4sIEx0ZC4NCkFkZHJl c3M6IEh1YXdlaSBUZWNobm9sb2dpZXMsIE5vIDEwMSwgc29mdHdhcmUgQXZlbnVlLCBZdWh1YSBE aXN0cmljdCwgTmFuamluZw0KVGVsZXBob25lOiA4Ni0wMjUtNTY2MjQ0ODENCk1vYmlsZTogODYt MTM4MTM5MDcyNDUNCg0KW0NvbXBhbnlfbG9nb10NCg0KDQo= --_000_D18DE23B1729Dscottbarvickcorerocom_ Content-Type: text/html; charset="gb2312" Content-ID: Content-Transfer-Encoding: quoted-printable
Andy,

DOTS is one or more interfaces that can be implemented in any type of = equipment that wants to be either side of the interface.   It would ma= ke sense to me that the upstream side could be a management system in a SoC= .     How the endpoints discover or select each other after discovery seems like something to be discussed, even if w= e end up starting with a static mechanism initially.

Scott

From: "Huangzhigang (Andy)&quo= t; <andy.huangzhigang@hu= awei.com>
Date: Friday, May 29, 2015 at 5:38 = AM
To: "dots@ietf.org" <dots@i= etf.org>
Subject: [Dots] is there a need to = get SoC involved in the scenario?

Hi

 

I have a question here, is DOTS limited to interface= between on-premise and cloud DDoS detection/mitigation equipment? Is there= a need to get some kind of management system like SoC involved in, it coul= d help on-premise and cloud DDoS equipment to discover each other, and it could provide some policy to select the bes= t one  in case there are multiple Cloud DDoS mitigation center located= in the different area.

 

 

 

 

------------------------------------------------= -------------------------------------

Andy Huang (Zhigang Huang, =BB=C6=D6=BE=B8=D6)

Network Research Department, Huawei Technologies= Co., Ltd.

Address: Huawei Technologies, No 101, software A= venue, Yuhua District, Nanjing

Telephone: 86-025-56624481

Mobile: 86-13813907245


3D"Company_logo"=

 

 --_000_D18DE23B1729Dscottbarvickcorerocom_-- --_004_D18DE23B1729Dscottbarvickcorerocom_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: attachment; filename="image001.jpg"; size=6737; creation-date="Fri, 29 May 2015 14:49:59 GMT"; modification-date="Fri, 29 May 2015 14:49:59 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/7QxmUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA AAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAIASAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAA AAA/gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAA AAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgAB AGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0A AAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD///////// ////////////////////A+gAADhCSU0EAAAAAAAAAgAAOEJJTQQCAAAAAAACAAA4QklNBDAAAAAA AAEBADhCSU0ELQAAAAAABgABAAAABjhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4A AAAAAAQAAAAAOEJJTQQaAAAAAAM9AAAABgAAAAAAAAAAAAAAIAAAAGYAAAAEAGwAbwBnAG8AAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAGYAAAAgAAAAAAAAAAAAAAAAAAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAA AFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAg AAAAAFJnaHRsb25nAAAAZgAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAAS AAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxF U2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAA AEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAA TGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAIAAAAABSZ2h0bG9uZwAAAGYAAAADdXJsVEVYVAAA AAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAA AQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpB bGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAA AA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNl QkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9u ZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4QklN BCgAAAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAg4QklNBAwA AAAABnAAAAABAAAAZgAAACAAAAE0AAAmgAAABlQAGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAM QWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUT ExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMB IgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEB AAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSR obFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSF tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIR AyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVV NnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEA AhEDEQA/APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC6 6f56f3t30Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUs VaDHl/dl/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5Vtns U/qp1vqPUvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9 w9+kqfV+qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVh fWLCzerW9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX 146P1azqFWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKeh SWDk/XHpVHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8t bvSU9Ikucy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uo JBeNpMtfRc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxb qtG20uI0PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv /QXjOu9COI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5F ztrrn/usXoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4 HX+6yY/jQHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v 6hNyW9Q6jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m +u1tQc9n0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6 tfRj2YnTgMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJ JT5b0bpfUrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6r WuLnfpNjXu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z OEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBB AGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwAyAAAAAQA4QklNBAYAAAAAAAcABQAA AAEBAP/hB4ZFeGlmAABJSSoACAAAAAcAEgEDAAEAAAABAAAAGgEFAAEAAABiAAAAGwEFAAEAAABq AAAAKAEDAAEAAAACAAAAMQECABwAAAByAAAAMgECABQAAACOAAAAaYcEAAEAAACiAAAAzAAAAID8 CgAQJwAAgPwKABAnAABBZG9iZSBQaG90b3Nob3AgQ1MyIFdpbmRvd3MAMjAwNzowMjoyNiAxNjox ODo1MwADAAGgAwABAAAA/////wKgBAABAAAAZgAAAAOgBAABAAAAIAAAAAAAAAAGAAMBAwABAAAA BgAAABoBBQABAAAAGgEAABsBBQABAAAAIgEAACgBAwABAAAAAgAAAAECBAABAAAAKgEAAAICBAAB AAAAVAYAAAAAAABIAAAAAQAAAEgAAAABAAAA/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVf Q00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMBIgACEQED EQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0 pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/ APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC66f56f3t3 0Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUsVaDHl/dl /X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5VtnsU/qp1vqP UvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9w9+kqfV+ qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVhfWLCzerW 9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX146P1azq FWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKehSWDk/XHp VHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8tbvSU9Iku cy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uoJBeNpMtf Rc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxbqtG20uI0 PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv/QXjOu9C OI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5Fztrrn/us XoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4HX+6yY/j QHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v6hNyW9Q6 jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m+u1tQc9n 0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6tfRj2YnT gMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJJT5b0bpf UrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6rWuLnfpNj Xu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z/9sAQwAI BgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04 MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAIABmAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAA AAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGh CCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp anN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV 1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkK C//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy 0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKD hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm 5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A99LKCASAT0FcOvxDin8XjRre2Bt1l8mS4Zud3Tge ma5X4j67qukeObG5hdkhto1e3H8L5+9n1z0rnriVIvF9pqdmP9E1CdLiPn7pLDcp9wcj8q8+vimn yx0sz6zLsihOj7WtrzxbXk/87a/f2PazrqpqL27oBEsnlhwec+4rYyCSM8jtXj0OupJ4hvZbhytr aSvNOfYHhfqTgVJ4G8R6nrfxAuLklzbTRMZlz8qKPu/THSnSxT5rS1u9Dlr5HNU5VVooxu/8vX/g dz1+iszX9at/Dug3mr3Su9vax+Y4jGWI9qz9U8ZafpXgtfFE0U7WTQpKEVRvw2McZ967z506Oiuf 03xbY6n4juNDhjmFzBaR3bMw+Xa4BA+vIp2leKrHV9d1nSIElSfSXVJ2cAKdwyMH8KAN6iuM0P4l 6J4hn1eDTkuJJdNRpCpUAzICQWTnkZFK/wASdEj8Ar4wInNiSF8sKPMD7tu3GcZBoA7KiuSu/iDo 9p4NsvE22eW0vWRII41BkZ2OAuM9Rg/lVbUviXptnq82lWem6pql7bgfaUsbfzBCT2Y5xn2oA7ai uB134q6V4b0nTb7VdM1K3N/v2W7xASJtOPmGeOtFAHnupab4l8P3s+kX+nT6ro/mFoCVLgAngo45 RvUfpWr4a8NnUmFrB5qwxyrcol0hSS3YEZB7MrDjI74r0TxX4MtPFSRNLd3VpcRcLNbyEHHcEdDV zQPDGn+G7XyrNZHdv9ZPM5d3+p/oK4/q153ex9Is9ccNyrSfktL93/wN+uh5n4m8NNp8ssEvm+Rc TtcyC2QvJOSTtUDsqjue5NZumaX4h1meLStP06fTNLLgzHaV3Ad3c8sfbp7V7Frnh6w8QWohvEcM v3JYmKun0P8AjVHwx4PtfDJleO7urueQYMk75wvoB0FTLC+/psa0s/UcLaWtRbXWl++/57dNCp8S reR/hjrlvBG8shtNqqilmbkdhXmniXwPqEPweS7XW/EFzKbWE/2dI+6MHjK7MZwP6V73RXcfLHj8 V+3g34ivrOq2F9/ZmoaPbwx3MFu0oWRAMqwUZB4rDe/1hIPGWsaXpl/HJ4lu4rPTPMhZXIwQ0hGM qAO59a98ooA8Fl0Dxb4DvvDmuXNnp8tlpiiwnTTUdpJIHPJcEc4Jzx3pkOgagvj2HwV9gmfw+dY/ thZmQ+X5XllvLPGOuePWvfaKAPBfD2iapL48svB91ZTLpGhalPqKTsp2SKeY1B6cE5/Oqg0u58Le LfEMes33imwjvLs3FvcaOheKdSSfmwCcjOK+haKAPm34sWlxqvhPwrJpi6zqcY8/M13CxnPzD74x ke3tRX0lRQB//9k= --_004_D18DE23B1729Dscottbarvickcorerocom_-- From nobody Fri May 29 17:33:17 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C01C1ACAD8 for ; Fri, 29 May 2015 17:33:16 -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 ESY5dpMbEhH4 for ; Fri, 29 May 2015 17:33: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 78EED1AC44E for ; Fri, 29 May 2015 17:33:12 -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 BWR16008; Sat, 30 May 2015 00:33:10 +0000 (GMT) Received: from SZXEMA414-HUB.china.huawei.com (10.82.72.73) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 30 May 2015 01:33:09 +0100 Received: from SZXEMA502-MBS.china.huawei.com ([169.254.4.143]) by SZXEMA414-HUB.china.huawei.com ([10.82.72.73]) with mapi id 14.03.0158.001; Sat, 30 May 2015 08:32:59 +0800 From: "Xialiang (Frank)" To: Scott Barvick Thread-Topic: [Dots] is there a need to get SoC involved in the scenario? Thread-Index: AQHQmh68fkEtWfgiU0uEfofxif1UtZ2TqjaA Date: Sat, 30 May 2015 00:32:57 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.135.43.91] Content-Type: multipart/related; boundary="_004_C02846B1344F344EB4FAA6FA7AF481F12ADDD851SZXEMA502MBSchi_"; type="multipart/alternative" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "dots@ietf.org" , "Huangzhigang \(Andy\)" Subject: [Dots] =?gb2312?b?tPC4tDogIGlzIHRoZXJlIGEgbmVlZCB0byBnZXQgU29D?= =?gb2312?b?IGludm9sdmVkIGluIHRoZSBzY2VuYXJpbz8=?= X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 May 2015 00:33:16 -0000 --_004_C02846B1344F344EB4FAA6FA7AF481F12ADDD851SZXEMA502MBSchi_ Content-Type: multipart/alternative; boundary="_000_C02846B1344F344EB4FAA6FA7AF481F12ADDD851SZXEMA502MBSchi_" --_000_C02846B1344F344EB4FAA6FA7AF481F12ADDD851SZXEMA502MBSchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SWYgdGhpcyBwb2ludCBtYWtlcyBzZW5zZSwgbXkgdW5kZXJzdGFuZGluZyBpcyBET1RTIGludGVy ZmFjZSBzaG91bGQgYmUgbW9yZSBnZW5lcmFsIGFuZCBzdXBwb3J0IG1vcmUgc2lnbmFsaW5nLg0K DQq3orz+yMs6IERvdHMgW21haWx0bzpkb3RzLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gU2NvdHQg QmFydmljaw0Kt6LLzcqxvOQ6IDIwMTXE6jXUwjI5yNUgMjI6NTANCsrVvP7IyzogSHVhbmd6aGln YW5nIChBbmR5KTsgZG90c0BpZXRmLm9yZw0K1vfM4jogUmU6IFtEb3RzXSBpcyB0aGVyZSBhIG5l ZWQgdG8gZ2V0IFNvQyBpbnZvbHZlZCBpbiB0aGUgc2NlbmFyaW8/DQoNCkFuZHksDQoNCkRPVFMg aXMgb25lIG9yIG1vcmUgaW50ZXJmYWNlcyB0aGF0IGNhbiBiZSBpbXBsZW1lbnRlZCBpbiBhbnkg dHlwZSBvZiBlcXVpcG1lbnQgdGhhdCB3YW50cyB0byBiZSBlaXRoZXIgc2lkZSBvZiB0aGUgaW50 ZXJmYWNlLiAgIEl0IHdvdWxkIG1ha2Ugc2Vuc2UgdG8gbWUgdGhhdCB0aGUgdXBzdHJlYW0gc2lk ZSBjb3VsZCBiZSBhIG1hbmFnZW1lbnQgc3lzdGVtIGluIGEgU29DLiAgICAgSG93IHRoZSBlbmRw b2ludHMgZGlzY292ZXIgb3Igc2VsZWN0IGVhY2ggb3RoZXIgYWZ0ZXIgZGlzY292ZXJ5IHNlZW1z IGxpa2Ugc29tZXRoaW5nIHRvIGJlIGRpc2N1c3NlZCwgZXZlbiBpZiB3ZSBlbmQgdXAgc3RhcnRp bmcgd2l0aCBhIHN0YXRpYyBtZWNoYW5pc20gaW5pdGlhbGx5Lg0KDQpTY290dA0KDQpGcm9tOiAi SHVhbmd6aGlnYW5nIChBbmR5KSIgPGFuZHkuaHVhbmd6aGlnYW5nQGh1YXdlaS5jb208bWFpbHRv OmFuZHkuaHVhbmd6aGlnYW5nQGh1YXdlaS5jb20+Pg0KRGF0ZTogRnJpZGF5LCBNYXkgMjksIDIw MTUgYXQgNTozOCBBTQ0KVG86ICJkb3RzQGlldGYub3JnPG1haWx0bzpkb3RzQGlldGYub3JnPiIg PGRvdHNAaWV0Zi5vcmc8bWFpbHRvOmRvdHNAaWV0Zi5vcmc+Pg0KU3ViamVjdDogW0RvdHNdIGlz IHRoZXJlIGEgbmVlZCB0byBnZXQgU29DIGludm9sdmVkIGluIHRoZSBzY2VuYXJpbz8NCg0KSGkN Cg0KSSBoYXZlIGEgcXVlc3Rpb24gaGVyZSwgaXMgRE9UUyBsaW1pdGVkIHRvIGludGVyZmFjZSBi ZXR3ZWVuIG9uLXByZW1pc2UgYW5kIGNsb3VkIEREb1MgZGV0ZWN0aW9uL21pdGlnYXRpb24gZXF1 aXBtZW50PyBJcyB0aGVyZSBhIG5lZWQgdG8gZ2V0IHNvbWUga2luZCBvZiBtYW5hZ2VtZW50IHN5 c3RlbSBsaWtlIFNvQyBpbnZvbHZlZCBpbiwgaXQgY291bGQgaGVscCBvbi1wcmVtaXNlIGFuZCBj bG91ZCBERG9TIGVxdWlwbWVudCB0byBkaXNjb3ZlciBlYWNoIG90aGVyLCBhbmQgaXQgY291bGQg cHJvdmlkZSBzb21lIHBvbGljeSB0byBzZWxlY3QgdGhlIGJlc3Qgb25lICBpbiBjYXNlIHRoZXJl IGFyZSBtdWx0aXBsZSBDbG91ZCBERG9TIG1pdGlnYXRpb24gY2VudGVyIGxvY2F0ZWQgaW4gdGhl IGRpZmZlcmVudCBhcmVhLg0KDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpB bmR5IEh1YW5nIChaaGlnYW5nIEh1YW5nLCC7xta+uNYpDQpOZXR3b3JrIFJlc2VhcmNoIERlcGFy dG1lbnQsIEh1YXdlaSBUZWNobm9sb2dpZXMgQ28uLCBMdGQuDQpBZGRyZXNzOiBIdWF3ZWkgVGVj aG5vbG9naWVzLCBObyAxMDEsIHNvZnR3YXJlIEF2ZW51ZSwgWXVodWEgRGlzdHJpY3QsIE5hbmpp bmcNClRlbGVwaG9uZTogODYtMDI1LTU2NjI0NDgxDQpNb2JpbGU6IDg2LTEzODEzOTA3MjQ1DQoN CltDb21wYW55X2xvZ29dDQoNCg0KDQo= --_000_C02846B1344F344EB4FAA6FA7AF481F12ADDD851SZXEMA502MBSchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

If this point makes sense, my understanding is DOTS interface sho= uld be more general and support more signaling.

 

=B7=A2=BC=FE=C8=CB: Dots [m= ailto:dots-bounces@ietf.org] =B4=FA= =B1=ED Scott Barvick
=B7=A2= =CB=CD=CA=B1=BC=E4: 2015=C4=EA5=D4=C229=C8=D5 22:50
=CA=D5=BC=FE=C8=CB: Huangzhigang (Andy); dots@ietf.org
=D6=F7=CC=E2: Re: [Dots] is there a need to get SoC involved in the scenario?

 

Andy,

 

DOTS is one or more interfaces that can be implemented in any type = of equipment that wants to be either side of the interface.   It would= make sense to me that the upstream side could be a management system in a SoC.     How the endpoints discover = or select each other after discovery seems like something to be discussed, = even if we end up starting with a static mechanism initially.

 

Scott

 

From: = "Huangzhigang (A= ndy)" <andy.huangzh= igang@huawei.com>
Date: Friday, May 29, 2015 at 5:38 AM
To: "dots@ietf.org" &= lt;dots@ietf.org>
Subject: [Dots] is there a need to get SoC involved in the scenario?=

 

Hi

 

I have a = question here, is DOTS limited to interface between on-premise and cloud DD= oS detection/mitigation equipment? Is there a need to get some kind of mana= gement system like SoC involved in, it could help on-premise and cloud DDoS equipment to discover each other, and= it could provide some policy to select the best one  in case there ar= e multiple Cloud DDoS mitigation center located in the different area.=

 

 

 

 

--------------= -----------------------------------------------------------------------

Andy Huang (Zh= igang Huang, =BB=C6=D6=BE=B8=D6)

Network Resear= ch Department, Huawei Technologies Co., Ltd.

Address: Huawe= i Technologies, No 101, software Avenue, Yuhua District, Nanjing

Telephone: 86-= 025-56624481

Mobile: 86-138= 13907245


3D"Company_logo"


 

--_000_C02846B1344F344EB4FAA6FA7AF481F12ADDD851SZXEMA502MBSchi_-- --_004_C02846B1344F344EB4FAA6FA7AF481F12ADDD851SZXEMA502MBSchi_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=6737; creation-date="Sat, 30 May 2015 00:32:57 GMT"; modification-date="Sat, 30 May 2015 00:32:57 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/7QxmUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA AAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAIASAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAA AAA/gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAA AAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgAB AGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0A AAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD///////// ////////////////////A+gAADhCSU0EAAAAAAAAAgAAOEJJTQQCAAAAAAACAAA4QklNBDAAAAAA AAEBADhCSU0ELQAAAAAABgABAAAABjhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4A AAAAAAQAAAAAOEJJTQQaAAAAAAM9AAAABgAAAAAAAAAAAAAAIAAAAGYAAAAEAGwAbwBnAG8AAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAGYAAAAgAAAAAAAAAAAAAAAAAAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAA AFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAg AAAAAFJnaHRsb25nAAAAZgAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAAS AAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxF U2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAA AEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAA TGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAIAAAAABSZ2h0bG9uZwAAAGYAAAADdXJsVEVYVAAA AAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAA AQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpB bGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAA AA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNl QkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9u ZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4QklN BCgAAAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAg4QklNBAwA AAAABnAAAAABAAAAZgAAACAAAAE0AAAmgAAABlQAGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAM QWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUT ExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMB IgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEB AAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSR obFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSF tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIR AyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVV NnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEA AhEDEQA/APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC6 6f56f3t30Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUs VaDHl/dl/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5Vtns U/qp1vqPUvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9 w9+kqfV+qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVh fWLCzerW9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX 146P1azqFWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKeh SWDk/XHpVHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8t bvSU9Ikucy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uo JBeNpMtfRc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxb qtG20uI0PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv /QXjOu9COI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5F ztrrn/usXoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4 HX+6yY/jQHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v 6hNyW9Q6jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m +u1tQc9n0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6 tfRj2YnTgMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJ JT5b0bpfUrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6r WuLnfpNjXu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z OEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBB AGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwAyAAAAAQA4QklNBAYAAAAAAAcABQAA AAEBAP/hB4ZFeGlmAABJSSoACAAAAAcAEgEDAAEAAAABAAAAGgEFAAEAAABiAAAAGwEFAAEAAABq AAAAKAEDAAEAAAACAAAAMQECABwAAAByAAAAMgECABQAAACOAAAAaYcEAAEAAACiAAAAzAAAAID8 CgAQJwAAgPwKABAnAABBZG9iZSBQaG90b3Nob3AgQ1MyIFdpbmRvd3MAMjAwNzowMjoyNiAxNjox ODo1MwADAAGgAwABAAAA/////wKgBAABAAAAZgAAAAOgBAABAAAAIAAAAAAAAAAGAAMBAwABAAAA BgAAABoBBQABAAAAGgEAABsBBQABAAAAIgEAACgBAwABAAAAAgAAAAECBAABAAAAKgEAAAICBAAB AAAAVAYAAAAAAABIAAAAAQAAAEgAAAABAAAA/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVf Q00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMBIgACEQED EQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0 pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/ APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC66f56f3t3 0Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUsVaDHl/dl /X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5VtnsU/qp1vqP UvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9w9+kqfV+ qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVhfWLCzerW 9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX146P1azq FWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKehSWDk/XHp VHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8tbvSU9Iku cy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uoJBeNpMtf Rc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxbqtG20uI0 PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv/QXjOu9C OI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5Fztrrn/us XoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4HX+6yY/j QHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v6hNyW9Q6 jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m+u1tQc9n 0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6tfRj2YnT gMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJJT5b0bpf UrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6rWuLnfpNj Xu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z/9sAQwAI BgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04 MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAIABmAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAA AAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGh CCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp anN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV 1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkK C//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy 0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKD hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm 5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A99LKCASAT0FcOvxDin8XjRre2Bt1l8mS4Zud3Tge ma5X4j67qukeObG5hdkhto1e3H8L5+9n1z0rnriVIvF9pqdmP9E1CdLiPn7pLDcp9wcj8q8+vimn yx0sz6zLsihOj7WtrzxbXk/87a/f2PazrqpqL27oBEsnlhwec+4rYyCSM8jtXj0OupJ4hvZbhytr aSvNOfYHhfqTgVJ4G8R6nrfxAuLklzbTRMZlz8qKPu/THSnSxT5rS1u9Dlr5HNU5VVooxu/8vX/g dz1+iszX9at/Dug3mr3Su9vax+Y4jGWI9qz9U8ZafpXgtfFE0U7WTQpKEVRvw2McZ967z506Oiuf 03xbY6n4juNDhjmFzBaR3bMw+Xa4BA+vIp2leKrHV9d1nSIElSfSXVJ2cAKdwyMH8KAN6iuM0P4l 6J4hn1eDTkuJJdNRpCpUAzICQWTnkZFK/wASdEj8Ar4wInNiSF8sKPMD7tu3GcZBoA7KiuSu/iDo 9p4NsvE22eW0vWRII41BkZ2OAuM9Rg/lVbUviXptnq82lWem6pql7bgfaUsbfzBCT2Y5xn2oA7ai uB134q6V4b0nTb7VdM1K3N/v2W7xASJtOPmGeOtFAHnupab4l8P3s+kX+nT6ro/mFoCVLgAngo45 RvUfpWr4a8NnUmFrB5qwxyrcol0hSS3YEZB7MrDjI74r0TxX4MtPFSRNLd3VpcRcLNbyEHHcEdDV zQPDGn+G7XyrNZHdv9ZPM5d3+p/oK4/q153ex9Is9ccNyrSfktL93/wN+uh5n4m8NNp8ssEvm+Rc TtcyC2QvJOSTtUDsqjue5NZumaX4h1meLStP06fTNLLgzHaV3Ad3c8sfbp7V7Frnh6w8QWohvEcM v3JYmKun0P8AjVHwx4PtfDJleO7urueQYMk75wvoB0FTLC+/psa0s/UcLaWtRbXWl++/57dNCp8S reR/hjrlvBG8shtNqqilmbkdhXmniXwPqEPweS7XW/EFzKbWE/2dI+6MHjK7MZwP6V73RXcfLHj8 V+3g34ivrOq2F9/ZmoaPbwx3MFu0oWRAMqwUZB4rDe/1hIPGWsaXpl/HJ4lu4rPTPMhZXIwQ0hGM qAO59a98ooA8Fl0Dxb4DvvDmuXNnp8tlpiiwnTTUdpJIHPJcEc4Jzx3pkOgagvj2HwV9gmfw+dY/ thZmQ+X5XllvLPGOuePWvfaKAPBfD2iapL48svB91ZTLpGhalPqKTsp2SKeY1B6cE5/Oqg0u58Le LfEMes33imwjvLs3FvcaOheKdSSfmwCcjOK+haKAPm34sWlxqvhPwrJpi6zqcY8/M13CxnPzD74x ke3tRX0lRQB//9k= --_004_C02846B1344F344EB4FAA6FA7AF481F12ADDD851SZXEMA502MBSchi_-- From nobody Fri May 29 21:59:46 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5F8C1A923C for ; Fri, 29 May 2015 21:59:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 b1miYdFl8vpu for ; Fri, 29 May 2015 21:59:44 -0700 (PDT) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (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 5D6E21A8A9B for ; Fri, 29 May 2015 21:59:44 -0700 (PDT) Received: by pabru16 with SMTP id ru16so73971230pab.1 for ; Fri, 29 May 2015 21:59:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arbor.net; s=m0; h=from:to:subject:date:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; bh=BB39nIcmI2WNWJLkoYqw7Sgi+5hjepoG2cL+BklrLjI=; b=EaxyXOytquVhSAEjsLUV4LLMdFrWND6qMVndpbEK1q+mREsBi8LQEArbs9EthUlnyf 15S/khd3lHHL9iNpeqDxYApV5Jm48tgzGeQlL/VSvo2YFyyZcy5B7q23GyYfxYiRrYbV NsFg1IfhLE4wzZj0/rqrin8bbYKIiaxh9jKD4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-type:content-transfer-encoding; bh=BB39nIcmI2WNWJLkoYqw7Sgi+5hjepoG2cL+BklrLjI=; b=Dr21n1EFLw99vIUf0WHhQnWNB6Ur/YtPZ2R6k2qNpp49Avs5ralepDq+Al6w5shb0M OdonzUpbS+xcAHmCCH0C4nQGiRTrGXLtQnyjlW8CLKJvvKFxolR6PJHe9jTlekznLU0H 6tdHKAyg9OBTpbyq/a/FVM6zl5XmFaU39ikal/k1W5dqktE1Ompd/iz0VEgZ6+lPppLm iqKoSoJKUJTlL8tMk2YEXQ2bMGIKHFO0OnlAHQJutEnWxf58WQKJsMFngTyQtn8DuAvy Yw4fOHUszyQEwt+8qb9LmeuYcE71930p9u+TuO0jqCFxHd3/8FnV8Zn7Ts8GTtOX2Xe5 5pGg== X-Gm-Message-State: ALoCoQkCXWblwYSDNp/GjJmHsBxuH3q0PepIC/+qOpCGMlWX7IyuWV7m076MTmWg1BnAnMn5908E X-Received: by 10.70.36.102 with SMTP id p6mr20816809pdj.18.1432961984001; Fri, 29 May 2015 21:59:44 -0700 (PDT) Received: from [172.19.254.136] (202-176-81-112.static.asianet.co.th. [202.176.81.112]) by mx.google.com with ESMTPSA id ms7sm7255804pdb.11.2015.05.29.21.59.41 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 29 May 2015 21:59:42 -0700 (PDT) From: "Roland Dobbins" To: "dots@ietf.org" Date: Sat, 30 May 2015 11:59:37 +0700 Message-ID: <4970C3A8-ED23-469B-818F-35414F76AD35@arbor.net> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: MailMate (1.9.1r5084) Archived-At: Subject: Re: [Dots] is there a need to get SoC involved in the scenario? X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 May 2015 04:59:46 -0000 On 29 May 2015, at 21:49, Scott Barvick wrote: > How the endpoints discover or select each other after discovery seems = > like something to be discussed, even if we end up starting with a = > static mechanism initially. DDoS mitigation isn't something that lends itself to dynamic = relationships between mitigation elements and controlling elements, for = many reasons. Static configuration is highly desirable; any discussion = of dynamic discovery mechanisms (as opposed to = capability-exchange/abstraction mechanisms, which are a different topic = and are desirable; something along the lines of = , = though I'm not endorsing/promoting that particular draft, at least at = this time) aren't really relevant for the foreseeable future, IMHO. ----------------------------------- Roland Dobbins From nobody Sun May 31 09:16:39 2015 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C76F51A1B8B for ; Sun, 31 May 2015 09:16:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_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 zYHvxKb2sTXc for ; Sun, 31 May 2015 09:16:36 -0700 (PDT) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.197]) (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 BC1BE1A1B8E for ; Sun, 31 May 2015 09:16:35 -0700 (PDT) Received: from [216.82.241.211] by server-5.bemta-8.messagelabs.com id B1/BE-01833-2E33B655; Sun, 31 May 2015 16:16:34 +0000 X-Env-Sender: Dave.Larson@corero.com X-Msg-Ref: server-7.tower-85.messagelabs.com!1433088993!49322096!1 X-Originating-IP: [71.184.227.49] X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8331 invoked from network); 31 May 2015 16:16:34 -0000 Received: from mercury.corero.com (HELO MERCURY.corero.com) (71.184.227.49) by server-7.tower-85.messagelabs.com with AES128-SHA encrypted SMTP; 31 May 2015 16:16:34 -0000 Received: from MERCURY.corero.com ([fe80::2c05:6b26:abe2:ad24]) by MERCURY.corero.com ([fe80::2c05:6b26:abe2:ad24%19]) with mapi id 14.03.0224.002; Sun, 31 May 2015 12:16:33 -0400 From: Dave Larson To: Roland Dobbins , "dots@ietf.org" Thread-Topic: [Dots] is there a need to get SoC involved in the scenario? Thread-Index: AQHQmh68fkEtWfgiU0uEfofxif1UtZ2UOauAgAIMZIA= Date: Sun, 31 May 2015 16:16:32 +0000 Message-ID: References: <4970C3A8-ED23-469B-818F-35414F76AD35@arbor.net> In-Reply-To: <4970C3A8-ED23-469B-818F-35414F76AD35@arbor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.53.168.56] Content-Type: text/plain; charset="us-ascii" Content-ID: <2D2DD8213154AC439E6192B83720E9E7@corero.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] is there a need to get SoC involved in the scenario? X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 May 2015 16:16:38 -0000 I agree with Roland on this point. Seeking to establish dynamic relationships (discovery) seems orthogonal to the initial goal of building a general DDoS mitigation signaling capability. Dave On 5/30/15, 12:59 AM, "Roland Dobbins" wrote: > >On 29 May 2015, at 21:49, Scott Barvick wrote: > >> How the endpoints discover or select each other after discovery seems >> like something to be discussed, even if we end up starting with a >> static mechanism initially. > >DDoS mitigation isn't something that lends itself to dynamic >relationships between mitigation elements and controlling elements, for >many reasons. Static configuration is highly desirable; any discussion >of dynamic discovery mechanisms (as opposed to >capability-exchange/abstraction mechanisms, which are a different topic >and are desirable; something along the lines of >?include_text=3D1>,=20 >though I'm not endorsing/promoting that particular draft, at least at >this time) aren't really relevant for the foreseeable future, IMHO. > >----------------------------------- >Roland Dobbins > >_______________________________________________ >Dots mailing list >Dots@ietf.org >https://www.ietf.org/mailman/listinfo/dots