From nobody Tue Sep 2 00:02:22 2014 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D79541A802A for ; Tue, 2 Sep 2014 00:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FF_IHOPE_YOU_SINK=2.166, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, 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 jaeMQ9wriUCD for ; Tue, 2 Sep 2014 00:02:16 -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 B44701A86E8 for ; Mon, 1 Sep 2014 23:58:17 -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 BIY99251; Tue, 02 Sep 2014 06:58:06 +0000 (GMT) Received: from SZXEMA405-HUB.china.huawei.com (10.82.72.37) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 2 Sep 2014 07:58:05 +0100 Received: from SZXEMA509-MBS.china.huawei.com ([169.254.2.196]) by SZXEMA405-HUB.china.huawei.com ([10.82.72.37]) with mapi id 14.03.0158.001; Tue, 2 Sep 2014 14:58:01 +0800 From: "Liushucheng (Will)" To: "junbi@tsinghua.edu.cn" Thread-Topic: [Supa] Discussion on SUPA draft chatter Thread-Index: Ac/Egg4rnM3Ac+nuTf6RywsQVZWuJwAaL1f3AGOEcSA= Date: Tue, 2 Sep 2014 06:58:01 +0000 Message-ID: References: <008201cfc482$191b5d10$4b521730$@tsinghua.edu.cn> <626d708fa5b94a238efcd5c50e29dbda@EXMBX31.ad.utwente.nl> In-Reply-To: <626d708fa5b94a238efcd5c50e29dbda@EXMBX31.ad.utwente.nl> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.78.79] Content-Type: multipart/alternative; boundary="_000_C9B5F12337F6F841B35C404CF0554ACB5FF69BAASZXEMA509MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/supa/gNTLiTpvKE7gwbupQDuWpPBEVwc Cc: "karagian@cs.utwente.nl" , "supa@ietf.org" Subject: Re: [Supa] Discussion on SUPA draft chatter X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 07:02:21 -0000 --_000_C9B5F12337F6F841B35C404CF0554ACB5FF69BAASZXEMA509MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jun, I am trying to answer your second question. Regarding to protocol specifica= tions, IMHO, vendor-neutral data models to describe network/device configu= ration may belong to this area, e.g., the YANG model for configuration of S= AVI? Regards, Will From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of karagian@cs.utwente.= nl Sent: Sunday, August 31, 2014 3:18 PM To: junbi@tsinghua.edu.cn; supa@ietf.org Subject: Re: [Supa] Discussion on SUPA draft chatter Hi Jun, Thank you very much for your email! Please note that we are working on providing preliminary versions of drafts= that are providing the information associated with these milestones. Please also note that in order to show why the SUPA activity is useful for = the IETF community we are also working on a state of the art/gap analysis. Best regards, Georgios ________________________________ Van: Supa > namens Jun = Bi > Verzonden: zaterdag 30 augustus 2014 20:42 Aan: supa@ietf.org Onderwerp: [Supa] Discussion on SUPA draft chatter Hi all, I would like to trigger the discussion on SUPA charter. The latest version of SUPA draft charter I received is below. I would ask questions about items in milestones, may I ask, I-D 'Guidelines on mapping network service graphs into specific network management and controlling policies' as an Informational RFC. What specific technologies the "mapping" here means ? Do we have an example= ? I-D 'SUPA NETCONF/YANG (or RESTCONF/YANG) model and Protocol Specification' Standards Track RFC. What would be included into this protocol specification ? Thanks, Jun SUPA (Shared Unified Policy Automation) charter Target Area: Description of Working Group: Today network operators are challenged to create an abstract view of their = network infrastructure and help service developers on using and programming= this abstraction rather than manipulating individual devices. An abstract = view of a network infrastructure and service function interdependencies can= be realized using a network service graph. A network service graph is a gr= aph specified by a Network Service Provider that defines how one or more ne= twork services are applied to traffic flowing through a set of nodes of the= graph, which includes attributes such as: o) network topology, based on I2RS, SFC based network topologies and repres= ented by a graph of links and nodes o) service functions (e.g., policing function, NAT, Firewall, DNS, DHCP) an= d their interdependencies o) mapping between service function (and their service function interdepend= encies) and network topology (similar to ALTO mapping) o) application based policies (actions and access policies) generated by ne= twork service systems to map the network service graph instance into specif= ic network management policies, i.e., into device level configuration model= s. Such application based demands are: *) Configuration types: o) request to dynamically configure a node o) request to place a service function on a network function *) Data plane types: o) request to steer a traffic flow o) request prioritize a traffic flow o) request to encapsulate/de-capsulate a traffic flow o) request block or admit a traffic flow *) Control plane / Routing plane types: o) request to change the routing state on a network function Network services are enhanced Operational Support System (OSS) services tha= t help a communication service provider to monitor, control, analyze and ma= nage a communication network. In this context, network services can be used= to provide the required configuration and application programming interfac= es to network service developers. Subsequently, a network service can use t= he service based demands and possibly update its associated network service= graph. The main goal of SUPA is to provide application based policies and means to= model and program the abstract view of network infrastructure and service = function interdependencies in order to support and feed network management = and controlling policies (e.g., dynamic network configuration, I2RS routing= strategies). This can be realized by: (1) modeling the network service graph, which among others include applicat= ion based policies, using YANG, (2) applying NETCONF (or RESTCONF) to enable dissemination of up to date (f= resh) network service graphs in a secure and efficient manner between netwo= rk service systems and network management and controlling systems, (3) providing guidelines on mapping attributes of network service graphs pr= ovided by network service systems into specific network management and cont= rolling policies. Work items related to SUPA include: o) specify the network service graph based on YANG models o) specify and standardize how NETCONF/YANG (or RESTCONF/YANG) can be used = to securely and efficiently distribute up to date (fresh) network service g= raphs between network service systems and network management and controllin= g systems o) provide guidelines for mechanisms that can dynamically map attributes, i= ncluding application based policies, of network service graphs into specifi= c network management and controlling policies, such as dynamic network conf= iguration, I2RS routing strategies o) document how to use NETCONF (or RESTCONF) authentication and authorizati= on mechanisms to achieve protection and isolation The following items are out of the SUPA scope: o) specification of the network management and controlling policies and the= ir associated device configuration models Milestones: I-D 'Problem Statement and Use Cases' as an Informational RFC. I-D 'Guidelines on mapping network service graphs into specific network management and controlling policies' as an Informational RFC. I-D 'Guidelines on using NETCONF (or RESTCONF) authentication and authorization mechanisms to achieve security protection and isolation' as an Informational RFC. I-D 'SUPA NETCONF/YANG (or RESTCONF/YANG) model and Protocol Specification' Standards Track RFC. --_000_C9B5F12337F6F841B35C404CF0554ACB5FF69BAASZXEMA509MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jun,=

 <= /p>

I am trying to answer you= r second question. Regarding to protocol specifications, IMHO,  vendor= -neutral data models to describe network/device configuration may belong to this area, e.g., the YANG model for configuration of SAVI? <= o:p>

 <= /p>

Regards,

Will

 <= /p>

From: Supa [ma= ilto:supa-bounces@ietf.org] On Behalf Of karagian@cs.utwente.nl
Sent: Sunday, August 31, 2014 3:18 PM
To: junbi@tsinghua.edu.cn; supa@ietf.org
Subject: Re: [Supa] Discussion on SUPA draft chatter

 

Hi Jun,

 

Thank you very much for your email!

Please note that we are working on pr= oviding preliminary versions of drafts that are providing the information a= ssociated with these milestones.

 

Please also note that in order to sho= w why the SUPA activity is useful for the IETF community we are also workin= g on a state of the art/gap analysis.

 

Best regards,

Georgios

Van: Supa <supa-bounces@ietf.org> namens Jun Bi <junbi@tsinghua.= edu.cn>
Verzonden: zaterdag 30 augustus 2014 20:42
Aan: supa@ietf.org
Onderwerp: [Supa] Discussion on SUPA draft chatter

 

    I-D 'Guidelines= on mapping network service graphs into specific network 

    management= and controlling policies' as an Informational RFC.

&= nbsp;

&= nbsp;

<= br> &n= bsp;   I-D 'SUPA NETCONF/YANG (or RESTCONF/YANG) model and Protoc= ol

    Specificat= ion' Standards Track RFC.

&= nbsp;

SUPA (Shared Unified Policy Automa= tion) charter

Target Area:

Description of Working Group:

Today network operators are challenged to create an abstract view of their = network infrastructure and help service developers on using and programming= this abstraction rather than manipulating individual devices. An abstract = view of a network infrastructure and service function interdependencies can be realized using a network ser= vice graph. A network service graph is a graph specified by a Network Servi= ce Provider that defines how one or more network services are applied to tr= affic flowing through a set of nodes of the graph, which includes attributes such as:

 

o) network topology, based on I2RS= , SFC based network topologies and represented by a graph of links and node= s

 

o) service functions (e.g., polici= ng function, NAT, Firewall, DNS, DHCP) and their interdependencies

 

o) mapping between service functio= n (and their service function interdependencies) and network topology (simi= lar to ALTO mapping)=

 

o) application based policies (act= ions and access policies) generated by network service systems to map the n= etwork service graph instance into specific network management policies, i.e., into device level configuration models. Such ap= plication based demands are:

   *) Configuration type= s:

     &nbs= p; o) request to dynamically configure a node

     &nbs= p; o) request to place a service function on a network

     &nbs= p;    function

   *) Data plane ty= pes:

      &nb= sp;o) request to steer a traffic flow<= o:p>

     &nbs= p; o) request prioritize a traffic flow

     &nbs= p; o) request to encapsulate/de-capsulate a traffic flow

     &nbs= p; o) request block or admit a traffic flow

   *) Control plane / Ro= uting plane types:

     &nbs= p; o) request to change the routing state on a network

     &nbs= p;    function

Network services are enhanced Oper= ational Support System (OSS) services that help a communication service pro= vider to monitor, control, analyze and manage a communication network. In this context, network services can be used to pr= ovide the required configuration and application programming interfaces to = network service developers. Subsequently, a network service can use the ser= vice based demands and possibly update its associated network service graph.

 

The main goal of SUPA is to provid= e application based policies and means to model and program the abstract vi= ew of network infrastructure and service function interdependencies in order to support and feed network management and cont= rolling policies (e.g., dynamic network configuration, I2RS routing strateg= ies).

This can be realized by:

 

(1) modeling the network service g= raph, which among others include application based policies, using YANG,

 

(2) applying NETCONF (or RESTCONF)= to enable dissemination of up to date (fresh) network service graphs in a = secure and efficient manner between network service systems and network management and controlling systems,

 

(3) providing guidelines on mappin= g attributes of network service graphs provided by network service systems = into specific network management and controlling policies.

 


Work items related to SUPA include:

o) specify the network service gra= ph based on YANG models

 

o) specify and standardize how NET= CONF/YANG (or RESTCONF/YANG) can be used to securely and efficiently distri= bute up to date (fresh) network service graphs between network service systems and network management and controlling systems

 

o) provide guidelines for mechanis= ms that can dynamically map attributes, including application based policie= s, of network service graphs into specific network management and controlling policies, such as dynamic network configuration= , I2RS routing strategies

 

o) document how to use NETCONF (or= RESTCONF) authentication and authorization mechanisms to achieve protectio= n and isolation

 

The following items are out of the= SUPA scope:

 

o) specification of the network ma= nagement and controlling policies and their associated device configuration= models

 

Milestones:

    I-D 'Problem Statement and Use Cases' as an Informationa= l RFC.


    I-D 'Guidelines on mapping network service graphs into s= pecific network 

    management= and controlling policies' as an Informational RFC.

 

    I-D 'Guidelines o= n using NETCONF (or RESTCONF) authentication and

    authorizatio= n mechanisms to achieve security protection and isolation'

    as an Inform= ational RFC.

 

    I-D 'SUPA NETCO= NF/YANG (or RESTCONF/YANG) model and Protocol

    Specificat= ion' Standards Track RFC.

--_000_C9B5F12337F6F841B35C404CF0554ACB5FF69BAASZXEMA509MBSchi_-- From nobody Tue Sep 2 01:34:35 2014 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECD6E1A013B for ; Tue, 2 Sep 2014 01:34:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.393 X-Spam-Level: X-Spam-Status: No, score=0.393 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RP_MATCHES_RCVD=-0.668] 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 rUO1qgzh1JWq for ; Tue, 2 Sep 2014 01:34:32 -0700 (PDT) Received: from cernet.edu.cn (mail.cernet.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with ESMTP id 789FA1A010A for ; Tue, 2 Sep 2014 01:34:31 -0700 (PDT) Received: from AndrewYaoPC (unknown [166.111.132.217]) by centos (Coremail) with SMTP id AQAAf3AL3wIUgQVUvM8jAA--.1028S2; Tue, 02 Sep 2014 16:34:28 +0800 (CST) From: "Guang Yao" To: Date: Tue, 2 Sep 2014 16:34:29 +0800 Message-ID: <002c01cfc688$b6d618d0$24824a70$@cernet.edu.cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002D_01CFC6CB.C4FA1C20" X-Mailer: Microsoft Outlook 15.0 Thread-Index: Ac/Gh8AZTLQx+gy7TtGf8Y+pK8azPQ== Content-Language: zh-cn X-CM-TRANSID: AQAAf3AL3wIUgQVUvM8jAA--.1028S2 X-Coremail-Antispam: 1UD129KBjvdXoW7JrykArWxurW5Gry8ZryxZrb_yoWfXrg_A3 4093y7t3WfJF1rG3ZIkrWfXrWFyrWUKrWIy340kwnxt34YvFWrGFyrCr95W3W8X3y0qrnx Xry5ArySkrnxJjkaLaAFLSUrUUUUUb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJTRUUUb-xYjsxI4VWDJwAYFVCjjxCrM7AC8VAFwI0_Jr0_Gr1l1xkIjI8I 6I8E6xAIw20EY4v20xvaj40_Wr0E3s1l1IIY67AEw4v_Jr0_Jr4l8cAvFVAK0II2c7xJM2 8EF7xvwVC0I7IYx2IY67AKxVW8JVW5JwA2z4x0Y4vE2Ix0cI8IcVCY1x0267AKxVW8Jr0_ Cr1UM28EF7xvwVC2z280aVAFwI0_Gr1j6F4UJwA2z4x0Y4vEx4A2jsIEc7CjxVAFwI0_Cr 1j6rxdM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVAYj202j2C_Wr0_Ar1l5I8CrVAq jxCE14ACF2xKxwAqx4xG64kEw2xG04xIwI0_Gr0_Xr1l5I8CrVCF0I0E4I0vr24lYx0Ex4 A2jsIE14v26r1j6r4UMcvjeVCFs4IE7xkEbVWUJVW8JwACjcxG0xvY0x0EwIxGrwACjcxG 0xvY0x0EwIxGrVCF72vEw4AK0wCjr7xvwVCIw2I0I7xG6c02F41lc2xSY4AK67AK6r43Mx AIw28IcxkI7VAKI48JMI8I3I0E5I8CrVAFwI0_JrI_JrWlx2IqxVCjr7xvwVAFwI0_JrI_ JrWlx4CE17CEb7AF67AKxVWUJVWUXwCIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r 1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267AKxVWUJVW8JwCI42IY6xAIw20EY4v20xvaj40_ Wr1j6rW3Jr1lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcVC2z280aVCY1x0267AKxVWUJV W8JbIYCTnIWIevJa73UjIFyTuYvjxUs380DUUUU X-CM-SenderInfo: 51drw3xdqjquphuqv3oohg3hdfq/ Archived-At: http://mailarchive.ietf.org/arch/msg/supa/whmUflxHi6YRhJvVOSY1o-vIbfU Subject: [Supa] Any example of "network service graph"? X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 08:34:34 -0000 This is a multipart message in MIME format. ------=_NextPart_000_002D_01CFC6CB.C4FA1C20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear folks, I'm reading the documents, and I find "network service graph" is a critical concept to understand how SUPA/APONF works. The definition is as follows: "Network service graph: provides an abstraction view of a network infrastructure, which also includes network service attributes." I can understand it provides a view of the network, and contains something about the services/applications. However, what exactly is the view it provides? And what are the "network service attributes"? I fail to understand these concepts clearly. Maybe it is due to I missed the discussions at the beginning stage. So would you please give an example of the "Network service graph"? For example, the "Network service graph" should be associated with the "flow steering policy", or "the IPv6 transition policy"? Many thanks! Best regards, Guang ------=_NextPart_000_002D_01CFC6CB.C4FA1C20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear folks,

 

I’m = reading the documents, and I find “network service graph” is = a critical concept to understand how SUPA/APONF works.

 

The = definition is as follows:

“Network service graph: = provides an abstraction view of a network

infrastructure, which = also includes network service attributes.”

 

I can = understand it provides a view of the network, and contains something = about the services/applications. However, what exactly is the view it = provides? And what are the “network service = attributes”? I fail to understand these concepts clearly. = Maybe it is due to I missed the discussions at the beginning = stage.

 

So would you please give an example of the = “Network = service graph”? For example, the “Network service = graph” should be associated with the “flow steering = policy”, or “the IPv6 transition policy”? Many = thanks!

 

Best = regards,

Guang

------=_NextPart_000_002D_01CFC6CB.C4FA1C20-- From nobody Tue Sep 2 12:45:43 2014 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C56AA1A8864 for ; Tue, 2 Sep 2014 12:45:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.308 X-Spam-Level: X-Spam-Status: No, score=-2.308 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RP_MATCHES_RCVD=-0.668, 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 q2x8PkVmMU3O for ; Tue, 2 Sep 2014 12:45:38 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 522201A068E for ; Tue, 2 Sep 2014 12:45:38 -0700 (PDT) Received: from h200.viagenie.ca (h200.viagenie.ca [206.123.31.200]) by jazz.viagenie.ca (Postfix) with ESMTPSA id DEFFC403EE for ; Tue, 2 Sep 2014 15:45:36 -0400 (EDT) From: JF Tremblay Content-Type: multipart/alternative; boundary="Apple-Mail=_20E3CAA0-1DE8-462E-93D4-5FFAF69264D7" Message-Id: <8ECF7AE3-6C16-4E8B-B842-22ABB36B2990@viagenie.ca> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Date: Tue, 2 Sep 2014 15:45:36 -0400 References: <002c01cfc688$b6d618d0$24824a70$@cernet.edu.cn> To: supa@ietf.org In-Reply-To: <002c01cfc688$b6d618d0$24824a70$@cernet.edu.cn> X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/supa/jkwNWsnbmhtrBQ7rSLgmPlBiDn4 Subject: Re: [Supa] Any example of "network service graph"? X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 19:45:41 -0000 --Apple-Mail=_20E3CAA0-1DE8-462E-93D4-5FFAF69264D7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 This is a very good question actually.=20 I believe the wording =93Network Service Graph=94 was somehow derived = from ETSI =93Network Forwarding Graph=94. The =93Service=94 part might = be a derivative from some past discussions on service graphs. I find = this wording a bit confusing and I=92d like to suggest a few other = replacement ideas: 1. Network Topology 2. Topology graph 3. Network graph My own personal favorite is 2, as it clearly shows this is a topology = graph and it avoids the work =93network=94, which is often linked to = layer-3 concepts. A supa topology graph could describe any sort of = topology, at any level and with any type of abstraction. It could be, = for example, a service nodes graph, a physical topology graph, a L3VPN = representation, etc.=20 Here=92s a tentative definition (replace =93topology graph=94 by your = favorite wording below) Topology graph:=20 Describes a group of network elements or network functions connected to = each other using links. Links might be unidirectional or bidirectional = and describe different levels of network relations, such as physical = links, data links, network (IP) links, sessions or service relationship, = for example. This graph might represent a physical configuration, a = virtualized one or any level of abstraction required by the presenter or = the topology, usually a network controller offering an abstract view for = a higher level application or another type of controller. =20 Again, the idea here is to define this topology graph as a generic = concept that could describe pretty much any abstracted representation = might want to use. Comments?=20 JF Tremblay, Viagenie jean-francois.tremblay@viagenie.ca On Sep 2, 2014, at 4:34 AM, Guang Yao wrote: > Dear folks, > =20 > I=92m reading the documents, and I find =93network service graph=94 is = a critical concept to understand how SUPA/APONF works. > =20 > The definition is as follows: > =93Network service graph: provides an abstraction view of a network > infrastructure, which also includes network service attributes.=94 > =20 > I can understand it provides a view of the network, and contains = something about the services/applications. However, what exactly is the = view it provides? And what are the =93network service attributes=94? I = fail to understand these concepts clearly. Maybe it is due to I missed = the discussions at the beginning stage. > =20 > So would you please give an example of the =93Network service graph=94? = For example, the =93Network service graph=94 should be associated with = the =93flow steering policy=94, or =93the IPv6 transition policy=94? = Many thanks! > =20 > Best regards, > Guang > _______________________________________________ > Supa mailing list > Supa@ietf.org > https://www.ietf.org/mailman/listinfo/supa --Apple-Mail=_20E3CAA0-1DE8-462E-93D4-5FFAF69264D7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
This is a very good question = actually. 

I believe the wording =93Network = Service Graph=94 was somehow derived from ETSI =93Network Forwarding = Graph=94. The =93Service=94 part might be a derivative from some past = discussions on service graphs. I find this wording a bit confusing and = I=92d like to suggest a few other replacement ideas:
1. = Network Topology
2. Topology graph
3. Network = graph

My own personal favorite is 2, as it = clearly shows this is a topology graph and it avoids the work =93network=94= , which is often linked to layer-3 concepts. A supa topology graph could = describe any sort of topology, at any level and with any type of = abstraction. It could be, for example, a service nodes graph, a physical = topology graph, a L3VPN representation, = etc. 

Here=92s a tentative definition = (replace =93topology graph=94 by your favorite wording = below)

Topology = graph: 
Describes a group of network elements or network = functions connected to each other using links. Links might be = unidirectional or bidirectional and describe different levels of network = relations, such as physical links, data links, network (IP) links, = sessions or service relationship, for example. This graph might = represent a physical configuration, a virtualized one or any level of = abstraction required by the presenter or the topology, usually a network = controller offering an abstract view for a higher level application or = another type of controller. =   

Again, the idea here is to = define this topology graph as a generic concept that could describe = pretty much any abstracted representation might want to use. = Comments? 

JF Tremblay, Viagenie
jean-francois.tremblay@= viagenie.ca


On Sep 2, 2014, at 4:34 AM, Guang Yao = <yaoguang@cernet.edu.cn> wrote:

Dear = folks,
 
I=92m = reading the documents, and I find =93network service graph=94 is a = critical concept to understand how SUPA/APONF = works.
 
The = definition is as follows:
=93Network service graph: = provides an abstraction view of a network
infrastructure, which also includes network service = attributes.=94
 
I can = understand it provides a view of the network, and contains something = about the services/applications. However, what exactly is the view it = provides? And what are the =93network service attributes=94? I fail to = understand these concepts clearly. Maybe it is due to I missed the = discussions at the beginning stage.
 
So would = you please give an example of the =93Network service graph=94? For example, the = =93Network = service graph=94 should be associated with the =93flow steering policy=94, = or =93the IPv6 transition policy=94? Many = thanks!
 
Best regards,
Guang
_____________________________= __________________
Supa mailing list
Supa@ietf.org
https://www.ietf.org/mailman/listinfo/supa

= --Apple-Mail=_20E3CAA0-1DE8-462E-93D4-5FFAF69264D7-- From nobody Tue Sep 2 13:40:19 2014 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C20E11A06A0 for ; Tue, 2 Sep 2014 13:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668, 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 PfMuq4VghieT for ; Tue, 2 Sep 2014 13:40:16 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 441B31A0494 for ; Tue, 2 Sep 2014 13:40:16 -0700 (PDT) Received: from h200.viagenie.ca (h200.viagenie.ca [206.123.31.200]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 0993E403EE for ; Tue, 2 Sep 2014 16:40:14 -0400 (EDT) From: JF Tremblay Content-Type: multipart/alternative; boundary="Apple-Mail=_00E02F46-0ECB-4FF8-A1D4-FBC8418A2E27" Message-Id: <1C3210EC-63EC-4128-A2BB-7EBFB343CA92@viagenie.ca> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Date: Tue, 2 Sep 2014 16:40:14 -0400 References: <008201cfc482$191b5d10$4b521730$@tsinghua.edu.cn> To: supa@ietf.org In-Reply-To: <008201cfc482$191b5d10$4b521730$@tsinghua.edu.cn> X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/supa/V1sBZdBpIW-RgGsd0OJRfao7Eo8 Subject: Re: [Supa] Discussion on SUPA draft charter X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 20:40:18 -0000 --Apple-Mail=_00E02F46-0ECB-4FF8-A1D4-FBC8418A2E27 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Good question, indeed.=20 In my humble opinion, we could divide supa=92s work in clearer blocks or = objectives, for example:=20 a) provide a way to express an abstracted view of a network through a = flexible model and transport protocol b) provide guidance in the way the mapping of the abstracted should be = mapped to actual network configuration for physical and virtualized = devices=20 The =93mapping=94 part of the work is clearly part of b), but netconf = and yang models are clearly part of a). These are two distincts part of = the proposed work.=20 It would be hard to work on b) without doing a) first, so the charter = should reflect this. You can=92t defined how things are =93mapped=94 = before first defining how they are defined and abstracted.=20 For a), I=92d suggest we aim at providing flexibility so that the = protocol and the models are able to describe pretty much any type of = abstraction, for any network level, type of devices and services = (virtualized or physical), complexity and associated parameters. That = way, a provider that=92s used to work =93close to the metal=94 can start = with very little abstraction and then increase abstraction as required.=20= As for an =93example of mapping=94, the datacenter example is not bad. = The client configures a view containing only abstracted =93datacenters=94 = with a limited number of links. This is the view that an application = admin, a system admin or a tenant operator could view. Let=92s say that = datacenter client would like to reserve bandwidth between A and B = (either programatically or manually). The controller could offer an = abstracted view for this purpose. Then once the request is received, = this is mapped to a layer-3 model and applied (or submitted for = approval). There are two views here, the abstracted one exposed = north-side only and a layer-3 view that might be exposed both southbound = (for configuration) and northbound (for approval, debugging, showing = results in display, etc). Supa does not touch the southern side, but = would provide mechanisms for northbound transport and exposure to = abstractions (which is mostly section a) above).=20 I=92m not sure how much of b) could actually be specified. This is very = device-specific and also specific to the southbound protocol used.=20 JF Tremblay, Viagenie jean-francois.tremblay@viagenie.ca On Aug 30, 2014, at 2:42 PM, Jun Bi wrote: > Hi all, > =20 > I would like to trigger the discussion on SUPA charter. > =20 > The latest version of SUPA draft charter I received is below. > =20 > I would ask questions about items in milestones, may I ask, > =20 > I-D 'Guidelines on mapping network service graphs into specific = network=20 > management and controlling policies' as an Informational RFC. > =20 > What specific technologies the =93mapping=94 here means ? Do we have = an example ? > =20 >=20 > I-D 'SUPA NETCONF/YANG (or RESTCONF/YANG) model and Protocol > Specification' Standards Track RFC. > =20 > What would be included into this protocol specification ? > =20 > Thanks, > Jun > =20 > =20 > SUPA (Shared Unified Policy Automation) charter >=20 > Target Area:=20 >=20 > Description of Working Group: >=20 > Today network operators are challenged to create an abstract view of = their network infrastructure and help service developers on using and = programming this abstraction rather than manipulating individual = devices. An abstract view of a network infrastructure and service = function interdependencies can be realized using a network service = graph. A network service graph is a graph specified by a Network Service = Provider that defines how one or more network services are applied to = traffic flowing through a set of nodes of the graph, which includes = attributes such as: > =20 > o) network topology, based on I2RS, SFC based network topologies and = represented by a graph of links and nodes > =20 > o) service functions (e.g., policing function, NAT, Firewall, DNS, = DHCP) and their interdependencies > =20 > o) mapping between service function (and their service function = interdependencies) and network topology (similar to ALTO mapping) > =20 > o) application based policies (actions and access policies) generated = by network service systems to map the network service graph instance = into specific network management policies, i.e., into device level = configuration models. Such application based demands are: > *) Configuration types: > o) request to dynamically configure a node > o) request to place a service function on a network > function > *) Data plane types: > o) request to steer a traffic flow > o) request prioritize a traffic flow > o) request to encapsulate/de-capsulate a traffic flow > o) request block or admit a traffic flow > *) Control plane / Routing plane types: > o) request to change the routing state on a network > function > Network services are enhanced Operational Support System (OSS) = services that help a communication service provider to monitor, control, = analyze and manage a communication network. In this context, network = services can be used to provide the required configuration and = application programming interfaces to network service developers. = Subsequently, a network service can use the service based demands and = possibly update its associated network service graph. > =20 > The main goal of SUPA is to provide application based policies and = means to model and program the abstract view of network infrastructure = and service function interdependencies in order to support and feed = network management and controlling policies (e.g., dynamic network = configuration, I2RS routing strategies). > This can be realized by: > =20 > (1) modeling the network service graph, which among others include = application based policies, using YANG, > =20 > (2) applying NETCONF (or RESTCONF) to enable dissemination of up to = date (fresh) network service graphs in a secure and efficient manner = between network service systems and network management and controlling = systems, > =20 > (3) providing guidelines on mapping attributes of network service = graphs provided by network service systems into specific network = management and controlling policies. > =20 >=20 > Work items related to SUPA include: >=20 > o) specify the network service graph based on YANG models > =20 > o) specify and standardize how NETCONF/YANG (or RESTCONF/YANG) can be = used to securely and efficiently distribute up to date (fresh) network = service graphs between network service systems and network management = and controlling systems > =20 > o) provide guidelines for mechanisms that can dynamically map = attributes, including application based policies, of network service = graphs into specific network management and controlling policies, such = as dynamic network configuration, I2RS routing strategies > =20 > o) document how to use NETCONF (or RESTCONF) authentication and = authorization mechanisms to achieve protection and isolation > =20 > The following items are out of the SUPA scope: > =20 > o) specification of the network management and controlling policies = and their associated device configuration models > =20 > Milestones: >=20 > I-D 'Problem Statement and Use Cases' as an Informational RFC. >=20 > I-D 'Guidelines on mapping network service graphs into specific = network=20 > management and controlling policies' as an Informational RFC. > =20 > I-D 'Guidelines on using NETCONF (or RESTCONF) authentication and > authorization mechanisms to achieve security protection and = isolation' > as an Informational RFC. > =20 > I-D 'SUPA NETCONF/YANG (or RESTCONF/YANG) model and Protocol > Specification' Standards Track RFC. > =20 > _______________________________________________ > Supa mailing list > Supa@ietf.org > https://www.ietf.org/mailman/listinfo/supa --Apple-Mail=_00E02F46-0ECB-4FF8-A1D4-FBC8418A2E27 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Good question, = indeed. 

In my humble opinion, we could = divide supa=92s work in clearer blocks or objectives, for = example: 
a) provide a way to express an abstracted view = of a network through a flexible model and transport = protocol
b) provide guidance in the way the mapping of the = abstracted should be mapped to actual network configuration for physical = and virtualized devices 

The =93mapping=94 = part of the work is clearly part of b), but netconf and yang models are = clearly part of a). These are two distincts part of the proposed = work. 

It would be hard to work on b) = without doing a) first, so the charter should reflect this. You can=92t = defined how things are =93mapped=94 before first defining how they are = defined and abstracted. 

For a), I=92d = suggest we aim at providing flexibility so that the protocol and the = models are able to describe pretty much any type of abstraction, for any = network level, type of devices and services (virtualized or physical), = complexity and associated parameters. That way, a provider that=92s used = to work =93close to the metal=94 can start with very little abstraction = and then increase abstraction as = required. 

As for an =93example of = mapping=94, the datacenter example is not bad. The client configures a = view containing only abstracted =93datacenters=94 with a limited number = of links. This is the view that an application admin, a system admin or = a tenant operator could view. Let=92s say that datacenter client would = like to reserve bandwidth between A and B (either programatically or = manually). The controller could offer an abstracted view for this = purpose. Then once the request is received, this is mapped to a layer-3 = model and applied (or submitted for approval). There are two views here, = the abstracted one exposed north-side only and a layer-3 view that might = be exposed both southbound (for configuration) and northbound (for = approval, debugging, showing results in display, etc).  Supa does = not touch the southern side, but would provide mechanisms for northbound = transport and exposure to abstractions (which is mostly section a) = above). 

I=92m not sure how much of b) = could actually be specified. This is very device-specific and also = specific to the southbound protocol used. 


On Aug 30, 2014, at 2:42 PM, Jun Bi <junbi@tsinghua.edu.cn> = wrote:

Hi = all,
 
I would = like to trigger the discussion on SUPA = charter.
 
The latest = version of SUPA draft charter I received is = below.
 
I would ask = questions about items in milestones, may I = ask,
 
    I-D 'Guidelines on mapping network service = graphs into specific network 
    management and controlling policies' as = an Informational RFC.
 
What specific = technologies the =93mapping=94 here means ? Do we have an example = ?
 

    I-D 'SUPA NETCONF/YANG (or = RESTCONF/YANG) model and Protocol
    Specification' Standards Track = RFC.
 
What would be included into this = protocol specification  ?
 
Thanks,
Jun
 
 
SUPA (Shared Unified Policy Automation) charter

Target = Area: 

Description of = Working Group:

Today network operators are challenged to create = an abstract view of their network infrastructure and help service = developers on using and programming this abstraction rather than = manipulating individual devices. An abstract view of a network = infrastructure and service function interdependencies can be realized = using a network service graph. A network service graph is a graph = specified by a Network Service Provider that defines how one or more = network services are applied to traffic flowing through a set of nodes = of the graph, which includes attributes such as:
 
o) network = topology, based on I2RS, SFC based network topologies and represented by = a graph of links and nodes
 
o) service = functions (e.g., policing function, NAT, Firewall, DNS, DHCP) and their = interdependencies
 
o) mapping between = service function (and their service function interdependencies) and = network topology (similar to ALTO mapping)
 
o) application = based policies (actions and access policies) generated by network = service systems to map the network service graph instance into specific = network management policies, i.e., into device level configuration = models. Such application based demands are:
   *) Configuration types:
       o) request to dynamically = configure a node
       o) request to place a = service function on a network
          functio= n
   *) Data plane = types:
    =    o) request to steer a traffic = flow
       o) request prioritize a = traffic flow
       o) request to = encapsulate/de-capsulate a traffic flow
       o) request block or admit a = traffic flow
   *) = Control plane / Routing plane types:
       o) request to change the = routing state on a network
          functio= n
Network services = are enhanced Operational Support System (OSS) services that help a = communication service provider to monitor, control, analyze and manage a = communication network. In this context, network services can be used to = provide the required configuration and application programming = interfaces to network service developers. Subsequently, a network = service can use the service based demands and possibly update its = associated network service graph.
 
The main goal of = SUPA is to provide application based policies and means to model and = program the abstract view of network infrastructure and service function = interdependencies in order to support and feed network management and = controlling policies (e.g., dynamic network configuration, I2RS routing = strategies).
This can be = realized by:
 
(1) modeling the = network service graph, which among others include application based = policies, using YANG,
 
(2) applying = NETCONF (or RESTCONF) to enable dissemination of up to date (fresh) = network service graphs in a secure and efficient manner between network = service systems and network management and controlling = systems,
 
(3) providing = guidelines on mapping attributes of network service graphs provided by = network service systems into specific network management and controlling = policies.
 

Work items = related to SUPA include:

o) specify the network service graph based on YANG = models
 
o) specify and = standardize how NETCONF/YANG (or RESTCONF/YANG) can be used to securely = and efficiently distribute up to date (fresh) network service graphs = between network service systems and network management and controlling = systems
 
o) provide = guidelines for mechanisms that can dynamically map attributes, including = application based policies, of network service graphs into specific = network management and controlling policies, such as dynamic network = configuration, I2RS routing strategies
 
o) document how to = use NETCONF (or RESTCONF) authentication and authorization mechanisms to = achieve protection and isolation
 
The following items = are out of the SUPA scope:
 
o) specification of = the network management and controlling policies and their associated = device configuration models
 
Milestones:

    I-D 'Problem Statement and = Use Cases' as an Informational RFC.

    I-D 'Guidelines on mapping network service = graphs into specific network 
    management and controlling policies' as = an Informational RFC.
 
    = I-D 'Guidelines on using NETCONF (or RESTCONF) authentication = and
    authorization mechanisms to achieve = security protection and isolation'
    as an Informational = RFC.
 
    = I-D 'SUPA NETCONF/YANG (or RESTCONF/YANG) model and = Protocol
    Specification' Standards Track = RFC.
 
__________________________________________= _____
Supa mailing list
Supa@ietf.org
https://www.ietf.org/mailman/listinfo/supa

= --Apple-Mail=_00E02F46-0ECB-4FF8-A1D4-FBC8418A2E27-- From nobody Tue Sep 2 19:15:24 2014 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68A081A895F for ; Tue, 2 Sep 2014 19:15:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668] 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 qE6mZmfn1Q1u for ; Tue, 2 Sep 2014 19:15:12 -0700 (PDT) Received: from cernet.edu.cn (cernet.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with ESMTP id B66A11A895B for ; Tue, 2 Sep 2014 19:15:11 -0700 (PDT) Received: from AndrewYaoPC (unknown [166.111.132.217]) by centos (Coremail) with SMTP id AQAAf3C7_gereQZUsEYkAA--.1002S2; Wed, 03 Sep 2014 10:15:08 +0800 (CST) From: "Guang Yao" To: "'JF Tremblay'" , References: <002c01cfc688$b6d618d0$24824a70$@cernet.edu.cn> <8ECF7AE3-6C16-4E8B-B842-22ABB36B2990@viagenie.ca> In-Reply-To: <8ECF7AE3-6C16-4E8B-B842-22ABB36B2990@viagenie.ca> Date: Wed, 3 Sep 2014 10:15:08 +0800 Message-ID: <000201cfc71c$e261ddb0$a7259910$@cernet.edu.cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01CFC75F.F0871980" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQHpbgsQaqV9nPW7KrnGcVzw8yWyYwIy17hBm6m5DSA= Content-Language: zh-cn X-CM-TRANSID: AQAAf3C7_gereQZUsEYkAA--.1002S2 X-Coremail-Antispam: 1UD129KBjvJXoWxAw48XF4UJFWrJr18Xw1fZwb_yoW7Jw4fp3 W5KF4kCwnrWw1Uuw4Ivw1rWrWF9F4kGw45GwnxX3yjv398WF1I9F1aqF1Yvr4UGrWrJr10 v3yYgry5ua1qvrUanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUU9Sb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2z4x0Y4vE2Ix0cI8IcVAFwI0_Gr0_Xr1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr0_ Cr1l84ACjcxK6I8E87Iv67AKxVW8Jr0_Cr1UM28EF7xvwVC2z280aVCY1x0267AKxVW8Jr 0_Cr1UM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVAYj202j2C_Xr0_Wr1l5I8CrVAq jxCE14ACF2xKxwAqx4xG64kEw2xG04xIwI0_Jr0_Gr1l5I8CrVCF0I0E4I0vr24lYx0Ex4 A2jsIE14v26r1j6r4UMcvjeVCFs4IE7xkEbVWUJVW8JwACjcxG0xvY0x0EwIxGrwACjcxG 0xvY0x0EwIxGrVCF72vEw4AK0wCjr7xvwVCIw2I0I7xG6c02F41lc2xSY4AK67AK6r4UMx AIw28IcxkI7VAKI48JMI8I3I0E5I8CrVAFwI0_JrI_JrWlx2IqxVCjr7xvwVAFwI0_JrI_ JrWlx4CE17CEb7AF67AKxVWUXVWUAwCIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r 1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267AKxVWUJVW8JwCI42IY6xAIw20EY4v20xvaj40_ WFyUJVCq3wCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r1j6r 4UYxBIdaVFxhVjvjDU0xZFpf9x07beNVkUUUUU= X-CM-SenderInfo: 51drw3xdqjquphuqv3oohg3hdfq/ Archived-At: http://mailarchive.ietf.org/arch/msg/supa/76W0qMvyvVLGZpXn1ulXapbpk18 Subject: Re: [Supa] Any example of "network service graph"? X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 02:15:21 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0003_01CFC75F.F0871980 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This is a very clear explanation, thank you! If "network graph" is used, I can understand it is a topology graph which contains network elements (e.g., servers, switches). If using "service graph", I guess it should be a graph of network functions (from ETSI). Thus, maybe it is nature to use "network service graph" to denote "an abstraction view of a network infrastructure including network service attributes". However, it is somewhat hard for me to understand this definition before reading your explanation. I think at least it should be described as a graph of nodes and links (as your description), rather than an "abstraction view" which is abstract indeed. And I find in the new charter the "network service graph" has been re-defined. "A network service graph is a graph specified by a Network Service Provider that defines how one or more network services are applied to traffic flowing through a set of nodes of the graph, which includes attributes such as: o) network topology o) service functions their interdependencies o) mapping between service function and network topology o) application based policies" It has been very clear. I can understand there is a network topology, a number of services graphs composed by service functions, and a mapping between each function and its location on the topology. However, I'm not sure about the exact meaning of "application based policies", which are "generated by network service systems to map the network service graph instance into specific network management policies". I feel in the definition there is nothing about the applications. Would there be some further explanation on this definition? Thank you very much! Besides, I found the service graphs must be composed to resolve conflicts between applications before being applied to the network. However it seems this task is not in the milestones. Is this task covered by other groups or did I miss something? Best regards, Guang From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of JF Tremblay Sent: Wednesday, September 03, 2014 3:46 AM To: supa@ietf.org Subject: Re: [Supa] Any example of "network service graph"? This is a very good question actually. I believe the wording "Network Service Graph" was somehow derived from ETSI "Network Forwarding Graph". The "Service" part might be a derivative from some past discussions on service graphs. I find this wording a bit confusing and I'd like to suggest a few other replacement ideas: 1. Network Topology 2. Topology graph 3. Network graph My own personal favorite is 2, as it clearly shows this is a topology graph and it avoids the work "network", which is often linked to layer-3 concepts. A supa topology graph could describe any sort of topology, at any level and with any type of abstraction. It could be, for example, a service nodes graph, a physical topology graph, a L3VPN representation, etc. Here's a tentative definition (replace "topology graph" by your favorite wording below) Topology graph: Describes a group of network elements or network functions connected to each other using links. Links might be unidirectional or bidirectional and describe different levels of network relations, such as physical links, data links, network (IP) links, sessions or service relationship, for example. This graph might represent a physical configuration, a virtualized one or any level of abstraction required by the presenter or the topology, usually a network controller offering an abstract view for a higher level application or another type of controller. Again, the idea here is to define this topology graph as a generic concept that could describe pretty much any abstracted representation might want to use. Comments? JF Tremblay, Viagenie jean-francois.tremblay@viagenie.ca On Sep 2, 2014, at 4:34 AM, Guang Yao > wrote: Dear folks, I'm reading the documents, and I find "network service graph" is a critical concept to understand how SUPA/APONF works. The definition is as follows: "Network service graph: provides an abstraction view of a network infrastructure, which also includes network service attributes." I can understand it provides a view of the network, and contains something about the services/applications. However, what exactly is the view it provides? And what are the "network service attributes"? I fail to understand these concepts clearly. Maybe it is due to I missed the discussions at the beginning stage. So would you please give an example of the "Network service graph"? For example, the "Network service graph" should be associated with the "flow steering policy", or "the IPv6 transition policy"? Many thanks! Best regards, Guang _______________________________________________ Supa mailing list Supa@ietf.org https://www.ietf.org/mailman/listinfo/supa ------=_NextPart_000_0003_01CFC75F.F0871980 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This is a very clear explanation, thank you!

 

If “network graph” is used, I can understand it is a = topology graph which contains network elements (e.g., servers, = switches). If using “service graph”, I guess it should be a = graph of network functions (from ETSI). Thus, maybe it is nature to use = “network service graph” to denote “an abstraction view = of a network infrastructure including network service attributes”. = However, it is somewhat hard for me to understand this definition before = reading your explanation. I think at least it should be described as a = graph of nodes and links (as your description), rather than an = “abstraction view” which is abstract = indeed.

 

And I find in the new charter the “network service graph” = has been re-defined.

 

 

“A network service graph is a graph specified = by a Network Service Provider that defines how one or more network = services are applied to traffic flowing through a set of nodes of the = graph, which includes attributes such as:

 

o) network topology

 

o) service functions their = interdependencies

 

o) mapping between service function and network = topology

 

o) application based = policies”

 

It has been very clear. I can understand there is a network topology, = a number of services graphs composed by service functions, and a mapping = between each function and its location on the topology. =

 

However, I’m not sure about the exact meaning of = “application based policies”, which are “generated by = network service systems to map the network service graph instance into = specific network management policies”. I feel in the definition = there is nothing about the  applications… Would there be some = further explanation on this definition? Thank you very = much!

 

Besides, I found the service graphs must be composed to resolve = conflicts between applications before being applied to the network. = However it seems this task is not in the milestones. Is this task = covered by other groups or did I miss something?

 

Best regards,

Guang

 

 

From: Supa = [mailto:supa-bounces@ietf.org] On Behalf Of JF = Tremblay
Sent: Wednesday, September 03, 2014 3:46 = AM
To: supa@ietf.org
Subject: Re: [Supa] Any example = of "network service = graph"?

 

This is = a very good question actually. 

 

I = believe the wording “Network Service Graph” was somehow = derived from ETSI “Network Forwarding Graph”. The = “Service” part might be a derivative from some past = discussions on service graphs. I find this wording a bit confusing and = I’d like to suggest a few other replacement = ideas:

1. Network = Topology

2. Topology = graph

3. Network = graph

 

My own personal favorite is 2, as it clearly shows = this is a topology graph and it avoids the work “network”, = which is often linked to layer-3 concepts. A supa topology graph could = describe any sort of topology, at any level and with any type of = abstraction. It could be, for example, a service nodes graph, a physical = topology graph, a L3VPN representation, = etc. 

 

Here’s a tentative definition (replace = “topology graph” by your favorite wording = below)

 

Topology graph: 

Describes a group of network elements or network = functions connected to each other using links. Links might be = unidirectional or bidirectional and describe different levels of network = relations, such as physical links, data links, network (IP) links, = sessions or service relationship, for example. This graph might = represent a physical configuration, a virtualized one or any level of = abstraction required by the presenter or the topology, usually a network = controller offering an abstract view for a higher level application or = another type of controller. =   

 

Again, the idea here is to define this topology graph = as a generic concept that could describe pretty much any abstracted = representation might want to use. = Comments? 

 

JF = Tremblay, Viagenie

jean-francois.tremblay= @viagenie.ca

 

On Sep 2, 2014, at 4:34 AM, Guang Yao <yaoguang@cernet.edu.cn> = wrote:



Dear = folks,

 =

I’m = reading the documents, and I find “network service graph” is = a critical concept to understand how SUPA/APONF = works.

 =

The = definition is as follows:

“Network service = graph: provides an abstraction view of a network=

infrastructure, which = also includes network service attributes.”

 =

I can = understand it provides a view of the network, and contains something = about the services/applications. However, what exactly is the view it = provides? And what are the “network service = attributes”? I = fail to understand these concepts clearly. Maybe it is due to I missed = the discussions at the beginning = stage.

 =

So would = you please give an example of the “Network service = graph”? = For example, the “Network service = graph” = should be associated with the “flow steering = policy”, or “the IPv6 transition policy”? Many = thanks!=

 =

Best regards,=

Guang=

__________= _____________________________________
Supa mailing list
Supa@ietf.org
https://www.ietf.org/mailman/listinfo/supa

 

------=_NextPart_000_0003_01CFC75F.F0871980-- From nobody Tue Sep 2 21:50:52 2014 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 997C91A8A06 for ; Tue, 2 Sep 2014 21:50:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.403 X-Spam-Level: X-Spam-Status: No, score=-0.403 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FF_IHOPE_YOU_SINK=2.166, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a5APTXlIR6s3 for ; Tue, 2 Sep 2014 21:50:46 -0700 (PDT) Received: from tsinghua.edu.cn (smtp01.tsinghua.edu.cn [166.111.204.30]) by ietfa.amsl.com (Postfix) with ESMTP id B56B61A8A05 for ; Tue, 2 Sep 2014 21:50:45 -0700 (PDT) Received: from junbithinkpadx1 (unknown [59.66.24.216]) by app5 (Coremail) with SMTP id DsxvpgBXOS4WngZUyMzBAA--.13670S2; Wed, 03 Sep 2014 12:50:31 +0800 (CST) From: "Jun Bi" To: "'Liushucheng \(Will\)'" References: <008201cfc482$191b5d10$4b521730$@tsinghua.edu.cn> <626d708fa5b94a238efcd5c50e29dbda@EXMBX31.ad.utwente.nl> In-Reply-To: Date: Wed, 3 Sep 2014 12:50:31 +0800 Message-ID: <00e301cfc732$97427180$c5c75480$@tsinghua.edu.cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00E4_01CFC775.A56897B0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQDBvJU4Kf/7Gwa0S1uNAg8I3JBSRAIAEo9SAlRG7tqd6EiyYA== Content-Language: zh-cn X-CM-TRANSID: DsxvpgBXOS4WngZUyMzBAA--.13670S2 X-Coremail-Antispam: 1UD129KBjvJXoW3AF18Gr4kGryrKF4UZF4rAFb_yoWxAF1DpF W5WF40yayxW3Wjgrs2v3WruF4Fgrs3C3y3CwnrX34UZwnIyF1FgF1agw1Yq3y8Cr1rJr18 Z390qF15uw1avrJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUU92b7Iv0xC_Cr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2z4x0Y4vE2Ix0cI8IcVAFwI0_Ar0_tr1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j 6F4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oV Cq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40Eb7x2x7xS6ryj6rWUMc02F40E57IF 67AEF4xIwI1l5I8CrVAKz4kIr2xC04v26r1j6r4UMc02F40E42I26xC2a48xMcIj6xIIjx v20xvE14v26r1Y6r17McIj6I8E87Iv67AKxVW8JVWxJwAm72CE4IkC6x0Yz7v_Jr0_Gr1l F7xvr2IYc2Ij64vIr41l7480Y4vEI4kI2Ix0rVAqx4xJMxkIecxEwVAFwVW8XwCF04k20x vY0x0EwIxGrwC20s026c02F40E14v26r106r1rMI8I3I0E7480Y4vE14v26r106r1rMI8E 67AF67kF1VAFwI0_Jrv_JF1lIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCw CI42IY6xIIjxv20xvEc7CjxVAFwI0_Gr0_Cr1lIxAIcVCF04k26cxKx2IYs7xG6rWUJVWr Zr1UMIIF0xvEx4A2jsIE14v26r4j6F4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Gr0_Gr1UYx BIdaVFxhVjvjDU0xZFpf9x0UUjRo7UUUUU= X-CM-SenderInfo: xmxquxo6wvx0pjkxthxhgxhubq/ Archived-At: http://mailarchive.ietf.org/arch/msg/supa/XXdpsqLfNS5uetQRgpKRHLufKWk Cc: karagian@cs.utwente.nl, supa@ietf.org Subject: Re: [Supa] Discussion on SUPA draft chatter X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 04:50:50 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00E4_01CFC775.A56897B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Will, Good example. So to compose this RFC, shall we collect enough typical use cases to prove the protocol covers typical configuration requirements? Or we just take I-D 'Problem Statement and Use Cases' as an Informational RFC. as input. Best Regards, Jun From: Liushucheng (Will) [mailto:liushucheng@huawei.com] Sent: Tuesday, September 2, 2014 2:58 PM To: junbi@tsinghua.edu.cn Cc: supa@ietf.org; karagian@cs.utwente.nl Subject: RE: [Supa] Discussion on SUPA draft chatter Hi Jun, I am trying to answer your second question. Regarding to protocol specifications, IMHO, vendor-neutral data models to describe network/device configuration may belong to this area, e.g., the YANG model for configuration of SAVI? Regards, Will From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of karagian@cs.utwente.nl Sent: Sunday, August 31, 2014 3:18 PM To: junbi@tsinghua.edu.cn ; supa@ietf.org Subject: Re: [Supa] Discussion on SUPA draft chatter Hi Jun, Thank you very much for your email! Please note that we are working on providing preliminary versions of drafts that are providing the information associated with these milestones. Please also note that in order to show why the SUPA activity is useful for the IETF community we are also working on a state of the art/gap analysis. Best regards, Georgios _____ Van: Supa > namens Jun Bi > Verzonden: zaterdag 30 augustus 2014 20:42 Aan: supa@ietf.org Onderwerp: [Supa] Discussion on SUPA draft chatter Hi all, I would like to trigger the discussion on SUPA charter. The latest version of SUPA draft charter I received is below. I would ask questions about items in milestones, may I ask, I-D 'Guidelines on mapping network service graphs into specific network management and controlling policies' as an Informational RFC. What specific technologies the "mapping" here means ? Do we have an example ? I-D 'SUPA NETCONF/YANG (or RESTCONF/YANG) model and Protocol Specification' Standards Track RFC. What would be included into this protocol specification ? Thanks, Jun SUPA (Shared Unified Policy Automation) charter Target Area: Description of Working Group: Today network operators are challenged to create an abstract view of their network infrastructure and help service developers on using and programming this abstraction rather than manipulating individual devices. An abstract view of a network infrastructure and service function interdependencies can be realized using a network service graph. A network service graph is a graph specified by a Network Service Provider that defines how one or more network services are applied to traffic flowing through a set of nodes of the graph, which includes attributes such as: o) network topology, based on I2RS, SFC based network topologies and represented by a graph of links and nodes o) service functions (e.g., policing function, NAT, Firewall, DNS, DHCP) and their interdependencies o) mapping between service function (and their service function interdependencies) and network topology (similar to ALTO mapping) o) application based policies (actions and access policies) generated by network service systems to map the network service graph instance into specific network management policies, i.e., into device level configuration models. Such application based demands are: *) Configuration types: o) request to dynamically configure a node o) request to place a service function on a network function *) Data plane types: o) request to steer a traffic flow o) request prioritize a traffic flow o) request to encapsulate/de-capsulate a traffic flow o) request block or admit a traffic flow *) Control plane / Routing plane types: o) request to change the routing state on a network function Network services are enhanced Operational Support System (OSS) services that help a communication service provider to monitor, control, analyze and manage a communication network. In this context, network services can be used to provide the required configuration and application programming interfaces to network service developers. Subsequently, a network service can use the service based demands and possibly update its associated network service graph. The main goal of SUPA is to provide application based policies and means to model and program the abstract view of network infrastructure and service function interdependencies in order to support and feed network management and controlling policies (e.g., dynamic network configuration, I2RS routing strategies). This can be realized by: (1) modeling the network service graph, which among others include application based policies, using YANG, (2) applying NETCONF (or RESTCONF) to enable dissemination of up to date (fresh) network service graphs in a secure and efficient manner between network service systems and network management and controlling systems, (3) providing guidelines on mapping attributes of network service graphs provided by network service systems into specific network management and controlling policies. Work items related to SUPA include: o) specify the network service graph based on YANG models o) specify and standardize how NETCONF/YANG (or RESTCONF/YANG) can be used to securely and efficiently distribute up to date (fresh) network service graphs between network service systems and network management and controlling systems o) provide guidelines for mechanisms that can dynamically map attributes, including application based policies, of network service graphs into specific network management and controlling policies, such as dynamic network configuration, I2RS routing strategies o) document how to use NETCONF (or RESTCONF) authentication and authorization mechanisms to achieve protection and isolation The following items are out of the SUPA scope: o) specification of the network management and controlling policies and their associated device configuration models Milestones: I-D 'Problem Statement and Use Cases' as an Informational RFC. I-D 'Guidelines on mapping network service graphs into specific network management and controlling policies' as an Informational RFC. I-D 'Guidelines on using NETCONF (or RESTCONF) authentication and authorization mechanisms to achieve security protection and isolation' as an Informational RFC. I-D 'SUPA NETCONF/YANG (or RESTCONF/YANG) model and Protocol Specification' Standards Track RFC. ------=_NextPart_000_00E4_01CFC775.A56897B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Will,

 

Good example.

 

So to compose this RFC, shall we collect enough typical use cases to = prove the protocol covers typical configuration requirements? Or we just = take I-D 'Problem Statement and Use Cases' as an = Informational RFC. as input.

 

Best Regards,

Jun

 

 

From: = Liushucheng (Will) [mailto:liushucheng@huawei.com]
Sent: = Tuesday, September 2, 2014 2:58 PM
To: = junbi@tsinghua.edu.cn
Cc: supa@ietf.org; = karagian@cs.utwente.nl
Subject: RE: [Supa] Discussion on SUPA = draft chatter

 

Hi Jun,

 

I am trying to answer your second question. Regarding to protocol = specifications, IMHO,  vendor-neutral data models to describe = network/device configuration may belong to this area, e.g., the YANG = model for configuration of SAVI?

 

Regards,

Will

 

From:= Supa [mailto:supa-bounces@ietf.org] = On Behalf Of karagian@cs.utwente.nl
S= ent: Sunday, August 31, 2014 3:18 PM
To: junbi@tsinghua.edu.cn; supa@ietf.org
Subject: Re: = [Supa] Discussion on SUPA draft = chatter

 

Hi = Jun,

 

Thank you very = much for your email!

Please note = that we are working on providing preliminary versions of drafts that are = providing the information associated with these = milestones.

 

Please also = note that in order to show why the SUPA activity is useful for the IETF = community we are also working on a state of the art/gap = analysis.

 

Best = regards,

Georgios

Van: Supa <supa-bounces@ietf.org> = namens Jun Bi <junbi@tsinghua.edu.cn>
Verzonden: zaterdag 30 augustus 2014 20:42
Aan: supa@ietf.org
Onderwerp: = [Supa] Discussion on SUPA draft chatter =

 

Hi all,

 

I would like to trigger the discussion on SUPA charter.

 

The latest version of SUPA draft charter I received is = below.

 

I would ask questions about items in milestones, may I = ask,

 

    I-D = 'Guidelines on mapping network service graphs into specific = network 

    management and controlling = policies' as an Informational RFC.

=  

What specific technologies the “mapping” here means ? Do = we have an example ?

=  

=
    I-D 'SUPA NETCONF/YANG (or = RESTCONF/YANG) model and Protocol

    Specification' Standards = Track RFC.

=  

What would be included into this protocol specification  ? =

 

Thanks,

Jun

 

 

SUPA (Shared Unified = Policy Automation) charter

Target Area:

Description of = Working Group:

Today network operators are challenged to create = an abstract view of their network infrastructure and help service = developers on using and programming this abstraction rather than = manipulating individual devices. An abstract view of a network = infrastructure and service function interdependencies can be realized = using a network service graph. A network service graph is a graph = specified by a Network Service Provider that defines how one or more = network services are applied to traffic flowing through a set of nodes = of the graph, which includes attributes such as:

 

o) network topology, = based on I2RS, SFC based network topologies and represented by a graph = of links and nodes

 

o) service functions = (e.g., policing function, NAT, Firewall, DNS, DHCP) and their = interdependencies

 

o) mapping between = service function (and their service function interdependencies) and = network topology (similar to ALTO mapping)

 

o) application based = policies (actions and access policies) generated by network service = systems to map the network service graph instance into specific network = management policies, i.e., into device level configuration models. Such = application based demands are:

   *) = Configuration types:

       o) request to = dynamically configure a node

       o) request to = place a service function on a network

         = ; function

   *) = Data plane types:

    =    o) request to steer a traffic flow

       o) request = prioritize a traffic flow

       o) request to = encapsulate/de-capsulate a traffic flow

       o) request = block or admit a traffic flow

   *) = Control plane / Routing plane types:

       o) request to = change the routing state on a network

         = ; function

Network services are = enhanced Operational Support System (OSS) services that help a = communication service provider to monitor, control, analyze and manage a = communication network. In this context, network services can be used to = provide the required configuration and application programming = interfaces to network service developers. Subsequently, a network = service can use the service based demands and possibly update its = associated network service graph.

 

The main goal of SUPA = is to provide application based policies and means to model and program = the abstract view of network infrastructure and service function = interdependencies in order to support and feed network management and = controlling policies (e.g., dynamic network configuration, I2RS routing = strategies).

This can be realized = by:

 

(1) modeling the = network service graph, which among others include application based = policies, using YANG,

 

(2) applying NETCONF = (or RESTCONF) to enable dissemination of up to date (fresh) network = service graphs in a secure and efficient manner between network service = systems and network management and controlling systems,

 

(3) providing = guidelines on mapping attributes of network service graphs provided by = network service systems into specific network management and controlling = policies.

 


Work = items related to SUPA include:

o) specify the network = service graph based on YANG models

 

o) specify and = standardize how NETCONF/YANG (or RESTCONF/YANG) can be used to securely = and efficiently distribute up to date (fresh) network service graphs = between network service systems and network management and controlling = systems

 

o) provide guidelines = for mechanisms that can dynamically map attributes, including = application based policies, of network service graphs into specific = network management and controlling policies, such as dynamic network = configuration, I2RS routing strategies

 

o) document how to use = NETCONF (or RESTCONF) authentication and authorization mechanisms to = achieve protection and isolation

 

The following items = are out of the SUPA scope:

 

o) specification of = the network management and controlling policies and their associated = device configuration models

 

Milestones:

    I-D 'Problem = Statement and Use Cases' as an Informational RFC.


    = I-D 'Guidelines on mapping network service graphs into specific = network 

    management and controlling = policies' as an Informational RFC.

 

    I-D = 'Guidelines on using NETCONF (or RESTCONF) authentication and =

    authorization mechanisms to = achieve security protection and isolation'

    as an Informational = RFC.

 

    I-D = 'SUPA NETCONF/YANG (or RESTCONF/YANG) model and Protocol

    Specification' Standards = Track RFC.

 

------=_NextPart_000_00E4_01CFC775.A56897B0-- From nobody Wed Sep 3 00:23:28 2014 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1742C1A001E for ; Wed, 3 Sep 2014 00:23:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FF_IHOPE_YOU_SINK=2.166, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, 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 lDbjuQo0Qlc8 for ; Wed, 3 Sep 2014 00:23: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 0504F1A0008 for ; Wed, 3 Sep 2014 00:23:15 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJA08768; Wed, 03 Sep 2014 07:23:02 +0000 (GMT) Received: from SZXEMA402-HUB.china.huawei.com (10.82.72.34) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 3 Sep 2014 08:23:01 +0100 Received: from SZXEMA509-MBS.china.huawei.com ([169.254.2.196]) by SZXEMA402-HUB.china.huawei.com ([10.82.72.34]) with mapi id 14.03.0158.001; Wed, 3 Sep 2014 15:22:58 +0800 From: "Liushucheng (Will)" To: Jun Bi Thread-Topic: [Supa] Discussion on SUPA draft chatter Thread-Index: Ac/Egg4rnM3Ac+nuTf6RywsQVZWuJwAaL1f3AGOEcSAAHaragAAV9++g Date: Wed, 3 Sep 2014 07:22:58 +0000 Message-ID: References: <008201cfc482$191b5d10$4b521730$@tsinghua.edu.cn> <626d708fa5b94a238efcd5c50e29dbda@EXMBX31.ad.utwente.nl> <00e301cfc732$97427180$c5c75480$@tsinghua.edu.cn> In-Reply-To: <00e301cfc732$97427180$c5c75480$@tsinghua.edu.cn> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.78.79] Content-Type: multipart/alternative; boundary="_000_C9B5F12337F6F841B35C404CF0554ACB5FF6A69BSZXEMA509MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/supa/Rn7DbSkGSNO9H0N4WMrsXwixkfI Cc: "karagian@cs.utwente.nl" , "supa@ietf.org" Subject: Re: [Supa] Discussion on SUPA draft chatter X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 07:23:21 -0000 --_000_C9B5F12337F6F841B35C404CF0554ACB5FF6A69BSZXEMA509MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jun, IMHO, I think both PS and core use cases are all needed for this work. Mayb= e we should change this sentence to: Submit to IESG Information document de= fining the SUPA problem statement and core use cases. Regards, Will (Shucheng LIU) From: Jun Bi [mailto:junbi@tsinghua.edu.cn] Sent: Wednesday, September 03, 2014 12:51 PM To: Liushucheng (Will) Cc: supa@ietf.org; karagian@cs.utwente.nl Subject: RE: [Supa] Discussion on SUPA draft chatter Hi Will, Good example. So to compose this RFC, shall we collect enough typical use cases to prove = the protocol covers typical configuration requirements? Or we just take I-D= 'Problem Statement and Use Cases' as an Informational RFC. as input. Best Regards, Jun From: Liushucheng (Will) [mailto:liushucheng@huawei.com] Sent: Tuesday, September 2, 2014 2:58 PM To: junbi@tsinghua.edu.cn Cc: supa@ietf.org; karagian@cs.utwente.nl Subject: RE: [Supa] Discussion on SUPA draft chatter Hi Jun, I am trying to answer your second question. Regarding to protocol specifica= tions, IMHO, vendor-neutral data models to describe network/device configu= ration may belong to this area, e.g., the YANG model for configuration of S= AVI? Regards, Will From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of karagian@cs.utwente.= nl Sent: Sunday, August 31, 2014 3:18 PM To: junbi@tsinghua.edu.cn; supa@ietf.org Subject: Re: [Supa] Discussion on SUPA draft chatter Hi Jun, Thank you very much for your email! Please note that we are working on providing preliminary versions of drafts= that are providing the information associated with these milestones. Please also note that in order to show why the SUPA activity is useful for = the IETF community we are also working on a state of the art/gap analysis. Best regards, Georgios ________________________________ Van: Supa > namens Jun = Bi > Verzonden: zaterdag 30 augustus 2014 20:42 Aan: supa@ietf.org Onderwerp: [Supa] Discussion on SUPA draft chatter Hi all, I would like to trigger the discussion on SUPA charter. The latest version of SUPA draft charter I received is below. I would ask questions about items in milestones, may I ask, I-D 'Guidelines on mapping network service graphs into specific network management and controlling policies' as an Informational RFC. What specific technologies the "mapping" here means ? Do we have an example= ? I-D 'SUPA NETCONF/YANG (or RESTCONF/YANG) model and Protocol Specification' Standards Track RFC. What would be included into this protocol specification ? Thanks, Jun SUPA (Shared Unified Policy Automation) charter Target Area: Description of Working Group: Today network operators are challenged to create an abstract view of their = network infrastructure and help service developers on using and programming= this abstraction rather than manipulating individual devices. An abstract = view of a network infrastructure and service function interdependencies can= be realized using a network service graph. A network service graph is a gr= aph specified by a Network Service Provider that defines how one or more ne= twork services are applied to traffic flowing through a set of nodes of the= graph, which includes attributes such as: o) network topology, based on I2RS, SFC based network topologies and repres= ented by a graph of links and nodes o) service functions (e.g., policing function, NAT, Firewall, DNS, DHCP) an= d their interdependencies o) mapping between service function (and their service function interdepend= encies) and network topology (similar to ALTO mapping) o) application based policies (actions and access policies) generated by ne= twork service systems to map the network service graph instance into specif= ic network management policies, i.e., into device level configuration model= s. Such application based demands are: *) Configuration types: o) request to dynamically configure a node o) request to place a service function on a network function *) Data plane types: o) request to steer a traffic flow o) request prioritize a traffic flow o) request to encapsulate/de-capsulate a traffic flow o) request block or admit a traffic flow *) Control plane / Routing plane types: o) request to change the routing state on a network function Network services are enhanced Operational Support System (OSS) services tha= t help a communication service provider to monitor, control, analyze and ma= nage a communication network. In this context, network services can be used= to provide the required configuration and application programming interfac= es to network service developers. Subsequently, a network service can use t= he service based demands and possibly update its associated network service= graph. The main goal of SUPA is to provide application based policies and means to= model and program the abstract view of network infrastructure and service = function interdependencies in order to support and feed network management = and controlling policies (e.g., dynamic network configuration, I2RS routing= strategies). This can be realized by: (1) modeling the network service graph, which among others include applicat= ion based policies, using YANG, (2) applying NETCONF (or RESTCONF) to enable dissemination of up to date (f= resh) network service graphs in a secure and efficient manner between netwo= rk service systems and network management and controlling systems, (3) providing guidelines on mapping attributes of network service graphs pr= ovided by network service systems into specific network management and cont= rolling policies. Work items related to SUPA include: o) specify the network service graph based on YANG models o) specify and standardize how NETCONF/YANG (or RESTCONF/YANG) can be used = to securely and efficiently distribute up to date (fresh) network service g= raphs between network service systems and network management and controllin= g systems o) provide guidelines for mechanisms that can dynamically map attributes, i= ncluding application based policies, of network service graphs into specifi= c network management and controlling policies, such as dynamic network conf= iguration, I2RS routing strategies o) document how to use NETCONF (or RESTCONF) authentication and authorizati= on mechanisms to achieve protection and isolation The following items are out of the SUPA scope: o) specification of the network management and controlling policies and the= ir associated device configuration models Milestones: I-D 'Problem Statement and Use Cases' as an Informational RFC. I-D 'Guidelines on mapping network service graphs into specific network management and controlling policies' as an Informational RFC. I-D 'Guidelines on using NETCONF (or RESTCONF) authentication and authorization mechanisms to achieve security protection and isolation' as an Informational RFC. I-D 'SUPA NETCONF/YANG (or RESTCONF/YANG) model and Protocol Specification' Standards Track RFC. --_000_C9B5F12337F6F841B35C404CF0554ACB5FF6A69BSZXEMA509MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jun,=

 <= /p>

IMHO, I think both PS and= core use cases are all needed for this work. Maybe we should change this s= entence to: Submit to IESG Information document defining the SUPA problem statement and core use cases.

 <= /p>

Regards,

Will (Shucheng LIU)

 <= /p>

From: Jun Bi [= mailto:junbi@tsinghua.edu.cn]
Sent: Wednesday, September 03, 2014 12:51 PM
To: Liushucheng (Will)
Cc: supa@ietf.org; karagian@cs.utwente.nl
Subject: RE: [Supa] Discussion on SUPA draft chatter

 

Hi Will,

 <= /p>

Good example.<= /span>

 <= /p>

So to compose this RFC, s= hall we collect enough typical use cases to prove the protocol covers typic= al configuration requirements? Or we just take I-= D 'Problem Statement and Use Cases' as an Informational RFC. as input.=

 

Best Regards,

Jun

 <= /p>

 <= /p>

From: Liushu= cheng (Will) [mailto:liushucheng@= huawei.com]
Sent: Tuesday, September 2, 2014 2:58 PM
To: junbi@tsinghua.edu.cn
Cc: supa@ietf.org; karagian@cs.utwente.nl
Subject: RE: [Supa] Discussion on SUPA draft chatter

 

Hi Jun,=

 <= /p>

I am trying to answer you= r second question. Regarding to protocol specifications, IMHO,  vendor= -neutral data models to describe network/device configuration may belong to this area, e.g., the YANG model for configuration of SAVI? <= o:p>

 <= /p>

Regards,

Will

 <= /p>

From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of karagian@cs.u= twente.nl
Sent: Sunday, August 31, 2014 3:18 PM
To: junbi@tsinghua.edu.cn; supa@ietf.org
Subject: Re: [Supa] Discussion on SUPA draft chatter

 

Hi Jun,

 

Thank you very much for your email!

Please note that we are working on pr= oviding preliminary versions of drafts that are providing the information a= ssociated with these milestones.

 

Please also note that in order to sho= w why the SUPA activity is useful for the IETF community we are also workin= g on a state of the art/gap analysis.

 

Best regards,

Georgios

Van: Supa <supa-bounces@ietf.org> namens Jun Bi <junbi@tsinghua.= edu.cn>
Verzonden: zaterdag 30 augustus 2014 20:42
Aan: supa@ietf.org
Onderwerp: [Supa] Discussion on SUPA draft chatter

 

    I-D 'Guidelines= on mapping network service graphs into specific network 

    management= and controlling policies' as an Informational RFC.

&= nbsp;

&= nbsp;

<= br> &n= bsp;   I-D 'SUPA NETCONF/YANG (or RESTCONF/YANG) model and Protoc= ol

    Specificat= ion' Standards Track RFC.

&= nbsp;

SUPA (Shared Unified Policy Automa= tion) charter

Target Area:

Description of Working Group:

Today network operators are challenged to create an abstract view of their = network infrastructure and help service developers on using and programming= this abstraction rather than manipulating individual devices. An abstract = view of a network infrastructure and service function interdependencies can be realized using a network ser= vice graph. A network service graph is a graph specified by a Network Servi= ce Provider that defines how one or more network services are applied to tr= affic flowing through a set of nodes of the graph, which includes attributes such as:

 

o) network topology, based on I2RS= , SFC based network topologies and represented by a graph of links and node= s

 

o) service functions (e.g., polici= ng function, NAT, Firewall, DNS, DHCP) and their interdependencies

 

o) mapping between service functio= n (and their service function interdependencies) and network topology (simi= lar to ALTO mapping)=

 

o) application based policies (act= ions and access policies) generated by network service systems to map the n= etwork service graph instance into specific network management policies, i.e., into device level configuration models. Such ap= plication based demands are:

   *) Configuration type= s:

     &nbs= p; o) request to dynamically configure a node

     &nbs= p; o) request to place a service function on a network

     &nbs= p;    function

   *) Data plane ty= pes:

      &nb= sp;o) request to steer a traffic flow<= o:p>

     &nbs= p; o) request prioritize a traffic flow

     &nbs= p; o) request to encapsulate/de-capsulate a traffic flow

     &nbs= p; o) request block or admit a traffic flow

   *) Control plane / Ro= uting plane types:

     &nbs= p; o) request to change the routing state on a network

     &nbs= p;    function

Network services are enhanced Oper= ational Support System (OSS) services that help a communication service pro= vider to monitor, control, analyze and manage a communication network. In this context, network services can be used to pr= ovide the required configuration and application programming interfaces to = network service developers. Subsequently, a network service can use the ser= vice based demands and possibly update its associated network service graph.

 

The main goal of SUPA is to provid= e application based policies and means to model and program the abstract vi= ew of network infrastructure and service function interdependencies in order to support and feed network management and cont= rolling policies (e.g., dynamic network configuration, I2RS routing strateg= ies).

This can be realized by:

 

(1) modeling the network service g= raph, which among others include application based policies, using YANG,

 

(2) applying NETCONF (or RESTCONF)= to enable dissemination of up to date (fresh) network service graphs in a = secure and efficient manner between network service systems and network management and controlling systems,

 

(3) providing guidelines on mappin= g attributes of network service graphs provided by network service systems = into specific network management and controlling policies.

 


Work items related to SUPA include:

o) specify the network service gra= ph based on YANG models

 

o) specify and standardize how NET= CONF/YANG (or RESTCONF/YANG) can be used to securely and efficiently distri= bute up to date (fresh) network service graphs between network service systems and network management and controlling systems

 

o) provide guidelines for mechanis= ms that can dynamically map attributes, including application based policie= s, of network service graphs into specific network management and controlling policies, such as dynamic network configuration= , I2RS routing strategies

 

o) document how to use NETCONF (or= RESTCONF) authentication and authorization mechanisms to achieve protectio= n and isolation

 

The following items are out of the= SUPA scope:

 

o) specification of the network ma= nagement and controlling policies and their associated device configuration= models

 

Milestones:

    I-D 'Problem Statement and Use Cases' as an Informationa= l RFC.


    I-D 'Guidelines on mapping network service graphs into s= pecific network 

    management= and controlling policies' as an Informational RFC.

 

    I-D 'Guidelines o= n using NETCONF (or RESTCONF) authentication and

    authorizatio= n mechanisms to achieve security protection and isolation'

    as an Inform= ational RFC.

 

    I-D 'SUPA NETCO= NF/YANG (or RESTCONF/YANG) model and Protocol

    Specificat= ion' Standards Track RFC.

--_000_C9B5F12337F6F841B35C404CF0554ACB5FF6A69BSZXEMA509MBSchi_-- From nobody Wed Sep 3 03:06:07 2014 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9E3A1A0450 for ; Wed, 3 Sep 2014 03:06:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.403 X-Spam-Level: X-Spam-Status: No, score=-0.403 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FF_IHOPE_YOU_SINK=2.166, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MQV6ors9uTXw for ; Wed, 3 Sep 2014 03:05:57 -0700 (PDT) Received: from tsinghua.edu.cn (smtp04.tsinghua.edu.cn [166.111.204.33]) by ietfa.amsl.com (Postfix) with ESMTP id 7E91A1A0195 for ; Wed, 3 Sep 2014 03:05:55 -0700 (PDT) Received: from junbithinkpadx1 (unknown [59.66.24.216]) by app6 (Coremail) with SMTP id D8xvpgA3GDHw5wZUcxFKAA--.7075S2; Wed, 03 Sep 2014 18:05:36 +0800 (CST) From: "Jun Bi" To: "'Liushucheng \(Will\)'" References: <008201cfc482$191b5d10$4b521730$@tsinghua.edu.cn> <626d708fa5b94a238efcd5c50e29dbda@EXMBX31.ad.utwente.nl> <00e301cfc732$97427180$c5c75480$@tsinghua.edu.cn> In-Reply-To: Date: Wed, 3 Sep 2014 18:05:36 +0800 Message-ID: <019201cfc75e$9bb69080$d323b180$@tsinghua.edu.cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0193_01CFC7A1.A9DF75D0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQDBvJU4Kf/7Gwa0S1uNAg8I3JBSRAIAEo9SAlRG7toBf2kh2QFDsh6IndKIWnA= Content-Language: zh-cn X-CM-TRANSID: D8xvpgA3GDHw5wZUcxFKAA--.7075S2 X-Coremail-Antispam: 1UD129KBjvJXoW3Ww1DZw43uFy5uw17Ww43trb_yoW3JF4xpF W5WF4jyay7W3WjgrZ2v3WrWr1Fgrs3C3y3Cw1DX34UZwnIkF10gF1agw4Yq3y8Cr1rJr18 Z390qF15uw1avrJanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUU9Yb7Iv0xC_Cr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j 6F4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oV Cq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40Eb7x2x7xS6ryj6rWUMc02F40E57IF 67AEF4xIwI1l5I8CrVAKz4kIr2xC04v26r1j6r4UMc02F40E42I26xC2a48xMcIj6xIIjx v20xvE14v26r1Y6r17McIj6I8E87Iv67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr1l F7xvr2IYc2Ij64vIr41l7480Y4vEI4kI2Ix0rVAqx4xJMxkIecxEwVAFwVW8twCF04k20x vY0x0EwIxGrwC20s026c02F40E14v26r106r1rMI8I3I0E7480Y4vE14v26r106r1rMI8E 67AF67kF1VAFwI0_Jrv_JF1lIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCw CI42IY6xIIjxv20xvEc7CjxVAFwI0_Gr0_Cr1lIxAIcVCF04k26cxKx2IYs7xG6r4j6FyU MIIF0xvEx4A2jsIE14v26r4j6F4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Gr1j6F4UJbIYCT nIWIevJa73UjIFyTuYvj7UU6uPUUUUU X-CM-SenderInfo: xmxquxo6wvx0pjkxthxhgxhubq/ Archived-At: http://mailarchive.ietf.org/arch/msg/supa/OiwRUy58L4mBId9n7S2PhzAseUs Cc: karagian@cs.utwente.nl, supa@ietf.org Subject: Re: [Supa] Discussion on SUPA draft chatter X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 10:06:04 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0193_01CFC7A1.A9DF75D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I see, Thanks. Jun From: supa-bounces@ietf.org [mailto:supa-bounces@ietf.org] On Behalf Of Liushucheng (Will) Sent: Wednesday, September 3, 2014 3:23 PM To: Jun Bi Cc: karagian@cs.utwente.nl; supa@ietf.org Subject: Re: [Supa] Discussion on SUPA draft chatter Hi Jun, IMHO, I think both PS and core use cases are all needed for this work. Maybe we should change this sentence to: Submit to IESG Information document defining the SUPA problem statement and core use cases. Regards, Will (Shucheng LIU) From: Jun Bi [mailto:junbi@tsinghua.edu.cn] Sent: Wednesday, September 03, 2014 12:51 PM To: Liushucheng (Will) Cc: supa@ietf.org ; karagian@cs.utwente.nl Subject: RE: [Supa] Discussion on SUPA draft chatter Hi Will, Good example. So to compose this RFC, shall we collect enough typical use cases to prove the protocol covers typical configuration requirements? Or we just take I-D 'Problem Statement and Use Cases' as an Informational RFC. as input. Best Regards, Jun From: Liushucheng (Will) [mailto:liushucheng@huawei.com] Sent: Tuesday, September 2, 2014 2:58 PM To: junbi@tsinghua.edu.cn Cc: supa@ietf.org ; karagian@cs.utwente.nl Subject: RE: [Supa] Discussion on SUPA draft chatter Hi Jun, I am trying to answer your second question. Regarding to protocol specifications, IMHO, vendor-neutral data models to describe network/device configuration may belong to this area, e.g., the YANG model for configuration of SAVI? Regards, Will From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of karagian@cs.utwente.nl Sent: Sunday, August 31, 2014 3:18 PM To: junbi@tsinghua.edu.cn ; supa@ietf.org Subject: Re: [Supa] Discussion on SUPA draft chatter Hi Jun, Thank you very much for your email! Please note that we are working on providing preliminary versions of drafts that are providing the information associated with these milestones. Please also note that in order to show why the SUPA activity is useful for the IETF community we are also working on a state of the art/gap analysis. Best regards, Georgios _____ Van: Supa > namens Jun Bi > Verzonden: zaterdag 30 augustus 2014 20:42 Aan: supa@ietf.org Onderwerp: [Supa] Discussion on SUPA draft chatter Hi all, I would like to trigger the discussion on SUPA charter. The latest version of SUPA draft charter I received is below. I would ask questions about items in milestones, may I ask, I-D 'Guidelines on mapping network service graphs into specific network management and controlling policies' as an Informational RFC. What specific technologies the "mapping" here means ? Do we have an example ? I-D 'SUPA NETCONF/YANG (or RESTCONF/YANG) model and Protocol Specification' Standards Track RFC. What would be included into this protocol specification ? Thanks, Jun SUPA (Shared Unified Policy Automation) charter Target Area: Description of Working Group: Today network operators are challenged to create an abstract view of their network infrastructure and help service developers on using and programming this abstraction rather than manipulating individual devices. An abstract view of a network infrastructure and service function interdependencies can be realized using a network service graph. A network service graph is a graph specified by a Network Service Provider that defines how one or more network services are applied to traffic flowing through a set of nodes of the graph, which includes attributes such as: o) network topology, based on I2RS, SFC based network topologies and represented by a graph of links and nodes o) service functions (e.g., policing function, NAT, Firewall, DNS, DHCP) and their interdependencies o) mapping between service function (and their service function interdependencies) and network topology (similar to ALTO mapping) o) application based policies (actions and access policies) generated by network service systems to map the network service graph instance into specific network management policies, i.e., into device level configuration models. Such application based demands are: *) Configuration types: o) request to dynamically configure a node o) request to place a service function on a network function *) Data plane types: o) request to steer a traffic flow o) request prioritize a traffic flow o) request to encapsulate/de-capsulate a traffic flow o) request block or admit a traffic flow *) Control plane / Routing plane types: o) request to change the routing state on a network function Network services are enhanced Operational Support System (OSS) services that help a communication service provider to monitor, control, analyze and manage a communication network. In this context, network services can be used to provide the required configuration and application programming interfaces to network service developers. Subsequently, a network service can use the service based demands and possibly update its associated network service graph. The main goal of SUPA is to provide application based policies and means to model and program the abstract view of network infrastructure and service function interdependencies in order to support and feed network management and controlling policies (e.g., dynamic network configuration, I2RS routing strategies). This can be realized by: (1) modeling the network service graph, which among others include application based policies, using YANG, (2) applying NETCONF (or RESTCONF) to enable dissemination of up to date (fresh) network service graphs in a secure and efficient manner between network service systems and network management and controlling systems, (3) providing guidelines on mapping attributes of network service graphs provided by network service systems into specific network management and controlling policies. Work items related to SUPA include: o) specify the network service graph based on YANG models o) specify and standardize how NETCONF/YANG (or RESTCONF/YANG) can be used to securely and efficiently distribute up to date (fresh) network service graphs between network service systems and network management and controlling systems o) provide guidelines for mechanisms that can dynamically map attributes, including application based policies, of network service graphs into specific network management and controlling policies, such as dynamic network configuration, I2RS routing strategies o) document how to use NETCONF (or RESTCONF) authentication and authorization mechanisms to achieve protection and isolation The following items are out of the SUPA scope: o) specification of the network management and controlling policies and their associated device configuration models Milestones: I-D 'Problem Statement and Use Cases' as an Informational RFC. I-D 'Guidelines on mapping network service graphs into specific network management and controlling policies' as an Informational RFC. I-D 'Guidelines on using NETCONF (or RESTCONF) authentication and authorization mechanisms to achieve security protection and isolation' as an Informational RFC. I-D 'SUPA NETCONF/YANG (or RESTCONF/YANG) model and Protocol Specification' Standards Track RFC. ------=_NextPart_000_0193_01CFC7A1.A9DF75D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I see, Thanks.

 

Jun

 

From: = supa-bounces@ietf.org [mailto:supa-bounces@ietf.org] On Behalf Of = Liushucheng (Will)
Sent: Wednesday, September 3, 2014 3:23 = PM
To: Jun Bi
Cc: karagian@cs.utwente.nl; = supa@ietf.org
Subject: Re: [Supa] Discussion on SUPA draft = chatter

 

Hi Jun,

 

IMHO, I think both PS and core use cases are all needed for this = work. Maybe we should change this sentence to: Submit to IESG = Information document defining the SUPA problem statement and core use = cases.

 

Regards,

Will (Shucheng LIU)

 

From:= Jun Bi [mailto:junbi@tsinghua.edu.cn] =
Sent: Wednesday, September 03, 2014 12:51 PM
To: = Liushucheng (Will)
Cc: supa@ietf.org; karagian@cs.utwente.nl
S= ubject: RE: [Supa] Discussion on SUPA draft = chatter

 

Hi Will,

 

Good example.

 

So to compose this RFC, shall we collect enough typical use cases to = prove the protocol covers typical configuration requirements? Or we just = take I-D 'Problem Statement and Use Cases' as an = Informational RFC. as input.

 

Best Regards,

Jun

 

 

From: = Liushucheng (Will) [mailto:liushucheng@huawei.com]=
Sent: Tuesday, September 2, 2014 2:58 PM
To: junbi@tsinghua.edu.cn
Cc:= supa@ietf.org; karagian@cs.utwente.nl
S= ubject: RE: [Supa] Discussion on SUPA draft = chatter

 

Hi Jun,

 

I am trying to answer your second question. Regarding to protocol = specifications, IMHO,  vendor-neutral data models to describe = network/device configuration may belong to this area, e.g., the YANG = model for configuration of SAVI?

 

Regards,

Will

 

From:= Supa [mailto:supa-bounces@ietf.org] = On Behalf Of karagian@cs.utwente.nl
S= ent: Sunday, August 31, 2014 3:18 PM
To: junbi@tsinghua.edu.cn; supa@ietf.org
Subject: Re: = [Supa] Discussion on SUPA draft = chatter

 

Hi = Jun,

 

Thank you very = much for your email!

Please note = that we are working on providing preliminary versions of drafts that are = providing the information associated with these = milestones.

 

Please also = note that in order to show why the SUPA activity is useful for the IETF = community we are also working on a state of the art/gap = analysis.

 

Best = regards,

Georgios

Van: Supa <supa-bounces@ietf.org> = namens Jun Bi <junbi@tsinghua.edu.cn>
Verzonden: zaterdag 30 augustus 2014 20:42
Aan: supa@ietf.org
Onderwerp: = [Supa] Discussion on SUPA draft chatter =

 

Hi all,

 

I would like to trigger the discussion on SUPA charter.

 

The latest version of SUPA draft charter I received is = below.

 

I would ask questions about items in milestones, may I = ask,

 

    I-D = 'Guidelines on mapping network service graphs into specific = network 

    management and controlling = policies' as an Informational RFC.

=  

What specific technologies the “mapping” here means ? Do = we have an example ?

=  

=
    I-D 'SUPA NETCONF/YANG (or = RESTCONF/YANG) model and Protocol

    Specification' Standards = Track RFC.

=  

What would be included into this protocol specification  ? =

 

Thanks,

Jun

 

 

SUPA (Shared Unified = Policy Automation) charter

Target Area:

Description of = Working Group:

Today network operators are challenged to create = an abstract view of their network infrastructure and help service = developers on using and programming this abstraction rather than = manipulating individual devices. An abstract view of a network = infrastructure and service function interdependencies can be realized = using a network service graph. A network service graph is a graph = specified by a Network Service Provider that defines how one or more = network services are applied to traffic flowing through a set of nodes = of the graph, which includes attributes such as:

 

o) network topology, = based on I2RS, SFC based network topologies and represented by a graph = of links and nodes

 

o) service functions = (e.g., policing function, NAT, Firewall, DNS, DHCP) and their = interdependencies

 

o) mapping between = service function (and their service function interdependencies) and = network topology (similar to ALTO mapping)

 

o) application based = policies (actions and access policies) generated by network service = systems to map the network service graph instance into specific network = management policies, i.e., into device level configuration models. Such = application based demands are:

   *) = Configuration types:

       o) request to = dynamically configure a node

       o) request to = place a service function on a network

         = ; function

   *) = Data plane types:

    =    o) request to steer a traffic flow

       o) request = prioritize a traffic flow

       o) request to = encapsulate/de-capsulate a traffic flow

       o) request = block or admit a traffic flow

   *) = Control plane / Routing plane types:

       o) request to = change the routing state on a network

         = ; function

Network services are = enhanced Operational Support System (OSS) services that help a = communication service provider to monitor, control, analyze and manage a = communication network. In this context, network services can be used to = provide the required configuration and application programming = interfaces to network service developers. Subsequently, a network = service can use the service based demands and possibly update its = associated network service graph.

 

The main goal of SUPA = is to provide application based policies and means to model and program = the abstract view of network infrastructure and service function = interdependencies in order to support and feed network management and = controlling policies (e.g., dynamic network configuration, I2RS routing = strategies).

This can be realized = by:

 

(1) modeling the = network service graph, which among others include application based = policies, using YANG,

 

(2) applying NETCONF = (or RESTCONF) to enable dissemination of up to date (fresh) network = service graphs in a secure and efficient manner between network service = systems and network management and controlling systems,

 

(3) providing = guidelines on mapping attributes of network service graphs provided by = network service systems into specific network management and controlling = policies.

 


Work = items related to SUPA include:

o) specify the network = service graph based on YANG models

 

o) specify and = standardize how NETCONF/YANG (or RESTCONF/YANG) can be used to securely = and efficiently distribute up to date (fresh) network service graphs = between network service systems and network management and controlling = systems

 

o) provide guidelines = for mechanisms that can dynamically map attributes, including = application based policies, of network service graphs into specific = network management and controlling policies, such as dynamic network = configuration, I2RS routing strategies

 

o) document how to use = NETCONF (or RESTCONF) authentication and authorization mechanisms to = achieve protection and isolation

 

The following items = are out of the SUPA scope:

 

o) specification of = the network management and controlling policies and their associated = device configuration models

 

Milestones:

    I-D 'Problem = Statement and Use Cases' as an Informational RFC.


    = I-D 'Guidelines on mapping network service graphs into specific = network 

    management and controlling = policies' as an Informational RFC.

 

    I-D = 'Guidelines on using NETCONF (or RESTCONF) authentication and =

    authorization mechanisms to = achieve security protection and isolation'

    as an Informational = RFC.

 

    I-D = 'SUPA NETCONF/YANG (or RESTCONF/YANG) model and Protocol

    Specification' Standards = Track RFC.

 

------=_NextPart_000_0193_01CFC7A1.A9DF75D0-- From nobody Wed Sep 3 13:30:15 2014 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7809D1A6F4B for ; Wed, 3 Sep 2014 13:30:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668, 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 PN8yLmR1blHN for ; Wed, 3 Sep 2014 13:30:11 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0756E1A0AEE for ; Wed, 3 Sep 2014 13:30:10 -0700 (PDT) Received: from h200.viagenie.ca (h200.viagenie.ca [206.123.31.200]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 84FAB403D3 for ; Wed, 3 Sep 2014 16:30:09 -0400 (EDT) From: JF Tremblay Content-Type: multipart/alternative; boundary="Apple-Mail=_1C5FFB4D-7324-4C16-9372-C24C384D5D9A" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Date: Wed, 3 Sep 2014 16:30:09 -0400 References: <002c01cfc688$b6d618d0$24824a70$@cernet.edu.cn> <8ECF7AE3-6C16-4E8B-B842-22ABB36B2990@viagenie.ca> <000201cfc71c$e261ddb0$a7259910$@cernet.edu.cn> To: supa@ietf.org In-Reply-To: <000201cfc71c$e261ddb0$a7259910$@cernet.edu.cn> X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/supa/9CyKIDW9MvcpUkHWs4jjIJ6cdyM Subject: Re: [Supa] Any example of "network service graph"? X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 20:30:13 -0000 --Apple-Mail=_1C5FFB4D-7324-4C16-9372-C24C384D5D9A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Sep 2, 2014, at 10:15 PM, Guang Yao wrote: > If =93network graph=94 is used, I can understand it is a topology = graph which contains network elements (e.g., servers, switches). If = using =93service graph=94, I guess it should be a graph of network = functions (from ETSI). Thus, maybe it is nature to use =93network = service graph=94 to denote =93an abstraction view of a network = infrastructure including network service attributes=94. However, it is = somewhat hard for me to understand this definition before reading your = explanation. I think at least it should be described as a graph of nodes = and links (as your description), rather than an =93abstraction view=94 = which is abstract indeed. > And I find in the new charter the =93network service graph=94 has been = re-defined. > However, I=92m not sure about the exact meaning of =93application = based policies=94, which are =93generated by network service systems to = map the network service graph instance into specific network management = policies=94. I feel in the definition there is nothing about the = applications=85 Would there be some further explanation on this = definition? Thank you very much! Well, my point was against including =93services=94 in the definition. = If what supa defines is a =93network service graph=94, than this is = barely an interface to sfc, which is already described in = draft-penno-sfc-yang = (http://tools.ietf.org/html/draft-penno-sfc-yang-05). > Besides, I found the service graphs must be composed to resolve = conflicts between applications before being applied to the network. = However it seems this task is not in the milestones. Is this task = covered by other groups or did I miss something?=20 This is the =93policy=94 part. How to resolve conflicts and permissions = before applying any change. SUPA should provide guidelines on how to = resolve these in a deterministic way.=20 Again, my personal view is that supa has three main blocks of work:=20 - Defining an abstract model (a generic topology graph, basically a = better version of draft-clemm-i2rs-yang-network-topo) - Define how the model will be defined and transported, if possible with = an existing protocol (could be YANG for example) - Define the guidelines to apply policies, in other words how an = abstract model should be applied to devices (virtual or not)=20 My 2 cents.=20 JF=20 --Apple-Mail=_1C5FFB4D-7324-4C16-9372-C24C384D5D9A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

On Sep 2, 2014, = at 10:15 PM, Guang Yao <yaoguang@cernet.edu.cn> = wrote:

If =93network graph=94 is used, I can understand it is = a topology graph which contains network elements (e.g., servers, = switches). If using =93service graph=94, I guess it should be a graph of = network functions (from ETSI). Thus, maybe it is nature to use =93network = service graph=94 to denote =93an abstraction view of a network = infrastructure including network service attributes=94. However, it is = somewhat hard for me to understand this definition before reading your = explanation. I think at least it should be described as a graph of nodes = and links (as your description), rather than an =93abstraction view=94 = which is abstract indeed.
And I find in the new charter the =93network service = graph=94 has been = re-defined.
<snip>
However, I=92m not sure about the exact meaning of = =93application based policies=94, which are =93generated by network = service systems to map the network service graph instance into specific = network management policies=94. I feel in the definition there is = nothing about the  applications=85 Would there be some further = explanation on this definition? Thank you very = much!

Well, my = point was against including =93services=94 in the definition. If what = supa defines is a =93network service graph=94, than this is barely an = interface to sfc, which is already described in draft-penno-sfc-yang (http://tools.i= etf.org/html/draft-penno-sfc-yang-05).

 Besides, I = found the service graphs must be composed to resolve conflicts between = applications before being applied to the network. However it seems this = task is not in the milestones. Is this task covered by other groups or = did I miss something? 

This = is the =93policy=94 part. How to resolve conflicts and permissions = before applying any change. SUPA should provide guidelines on how to = resolve these in a deterministic = way. 

Again, my personal view is that supa = has three main blocks of work: 
- Defining an abstract = model (a generic topology graph, basically a better version of = draft-clemm-i2rs-yang-network-topo)
- Define how the model = will be defined and transported, if possible with an existing protocol = (could be YANG for example)
- Define the guidelines to apply = policies, in other words how an abstract model should be applied to = devices (virtual or not) 

My 2 = cents. 

JF 

= = --Apple-Mail=_1C5FFB4D-7324-4C16-9372-C24C384D5D9A-- From nobody Wed Sep 3 14:46:07 2014 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59B131A878F for ; Wed, 3 Sep 2014 14:46:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668] 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 6WfrLuC3Bce7 for ; Wed, 3 Sep 2014 14:46:01 -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 BF0CD1A70FE for ; Wed, 3 Sep 2014 14:44:41 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 8420615B9; Wed, 3 Sep 2014 23:44:40 +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 5f_1NEhK9xTj; Wed, 3 Sep 2014 23:44:26 +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, 3 Sep 2014 23:44:39 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id DBD3320035; Wed, 3 Sep 2014 23:44:39 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id hgPCgpdJ2lSX; Wed, 3 Sep 2014 23:44:39 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BF01120033; Wed, 3 Sep 2014 23:44:38 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D9FCC2E59548; Wed, 3 Sep 2014 23:44:37 +0200 (CEST) Date: Wed, 3 Sep 2014 23:44:37 +0200 From: Juergen Schoenwaelder To: JF Tremblay Message-ID: <20140903214437.GA81569@elstar.local> Mail-Followup-To: JF Tremblay , supa@ietf.org References: <002c01cfc688$b6d618d0$24824a70$@cernet.edu.cn> <8ECF7AE3-6C16-4E8B-B842-22ABB36B2990@viagenie.ca> <000201cfc71c$e261ddb0$a7259910$@cernet.edu.cn> 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: http://mailarchive.ietf.org/arch/msg/supa/jV7pEQFxmFyn5cIF7Suieujmq9g Cc: supa@ietf.org Subject: Re: [Supa] Any example of "network service graph"? X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 21:46:04 -0000 On Wed, Sep 03, 2014 at 04:30:09PM -0400, JF Tremblay wrote: > > - Define how the model will be defined and transported, if possible with an existing protocol (could be YANG for example) > YANG is a data modeling language, not a protocol. NETCONF and RESTCONF are protocols to access and manipulate data defined in YANG data models. I assume people understand that but then I also see these terms messed up more than occasionally... /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Sep 3 19:39:37 2014 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CFC31A8843 for ; Wed, 3 Sep 2014 19:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.868 X-Spam-Level: X-Spam-Status: No, score=-4.868 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, 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 6-j7LNypwJTy for ; Wed, 3 Sep 2014 19:39:32 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 657971A6F46 for ; Wed, 3 Sep 2014 19:39:31 -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 BJA94111; Thu, 04 Sep 2014 02:39:29 +0000 (GMT) Received: from SZXEMA402-HUB.china.huawei.com (10.82.72.34) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 4 Sep 2014 03:39:28 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.57]) by SZXEMA402-HUB.china.huawei.com ([10.82.72.34]) with mapi id 14.03.0158.001; Thu, 4 Sep 2014 10:39:25 +0800 From: Felix To: JF Tremblay , "supa@ietf.org" Thread-Topic: [Supa] Any example of "network service graph"? Thread-Index: Ac/Gh8AZTLQx+gy7TtGf8Y+pK8azPQAG6jcAAA2aswAAJj42gAAdhY1A Date: Thu, 4 Sep 2014 02:39:23 +0000 Message-ID: <4B29BA0800EE424E850D442A1A3D18034073BC1C@SZXEMA510-MBX.china.huawei.com> References: <002c01cfc688$b6d618d0$24824a70$@cernet.edu.cn> <8ECF7AE3-6C16-4E8B-B842-22ABB36B2990@viagenie.ca> <000201cfc71c$e261ddb0$a7259910$@cernet.edu.cn> 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.66.114.148] Content-Type: multipart/alternative; boundary="_000_4B29BA0800EE424E850D442A1A3D18034073BC1CSZXEMA510MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/supa/MCoJ-HwpswPF_eE1NRc-ZfK7hng Subject: Re: [Supa] Any example of "network service graph"? X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 02:39:35 -0000 --_000_4B29BA0800EE424E850D442A1A3D18034073BC1CSZXEMA510MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi JF, >From my point, the information of configuration can't be found from the fir= st view of "network graph". The main Goal of SUPA is to provide vendor-neutral network level configurat= ion model to management applications. So that the management applications c= an dynamically reconfigure the network to do what they want. So I tend to c= hoose something like "Network level configuration graph" or "vendor-neutral= network level configuration graph" Best regards! Felix From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of JF Tremblay Sent: Thursday, September 04, 2014 4:30 AM To: supa@ietf.org Subject: Re: [Supa] Any example of "network service graph"? On Sep 2, 2014, at 10:15 PM, Guang Yao > wrote: If "network graph" is used, I can understand it is a topology graph which c= ontains network elements (e.g., servers, switches). If using "service graph= ", I guess it should be a graph of network functions (from ETSI). Thus, may= be it is nature to use "network service graph" to denote "an abstraction vi= ew of a network infrastructure including network service attributes". Howev= er, it is somewhat hard for me to understand this definition before reading= your explanation. I think at least it should be described as a graph of no= des and links (as your description), rather than an "abstraction view" whic= h is abstract indeed. And I find in the new charter the "network service graph" has been re-defin= ed. However, I'm not sure about the exact meaning of "application based policie= s", which are "generated by network service systems to map the network serv= ice graph instance into specific network management policies". I feel in th= e definition there is nothing about the applications... Would there be som= e further explanation on this definition? Thank you very much! Well, my point was against including "services" in the definition. If what = supa defines is a "network service graph", than this is barely an interface= to sfc, which is already described in draft-penno-sfc-yang (http://tools.i= etf.org/html/draft-penno-sfc-yang-05). Besides, I found the service graphs must be composed to resolve conflicts = between applications before being applied to the network. However it seems = this task is not in the milestones. Is this task covered by other groups or= did I miss something? This is the "policy" part. How to resolve conflicts and permissions before = applying any change. SUPA should provide guidelines on how to resolve these= in a deterministic way. Again, my personal view is that supa has three main blocks of work: - Defining an abstract model (a generic topology graph, basically a better = version of draft-clemm-i2rs-yang-network-topo) - Define how the model will be defined and transported, if possible with an= existing protocol (could be YANG for example) - Define the guidelines to apply policies, in other words how an abstract m= odel should be applied to devices (virtual or not) My 2 cents. JF --_000_4B29BA0800EE424E850D442A1A3D18034073BC1CSZXEMA510MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi JF,

 = ;

From my po= int, the information of configuration can’t be found from the first v= iew of “network graph”.

 = ;

The main G= oal of SUPA is to provide vendor-neutral network level configuration model = to management applications. So that the management applications can dynamically reconfigure the network to do what they want. So I tend to= choose something like “Network level configuration graph” or &= #8220;vendor-neutral network level configuration graph”

 = ;

Best regar= ds!

Felix=

 = ;

 = ;

From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of JF Tremblay
Sent: Thursday, September 04, 2014 4:30 AM
To: supa@ietf.org
Subject: Re: [Supa] Any example of "network service graph"= ?

 

&nbs= p;

On Sep 2, 2014, at 10:15 PM, Gu= ang Yao <yaoguang@cernet.edu.c= n> wrote:



If “= network graph” is used, I can understand it is a topology graph which= contains network elements (e.g., servers, switches). If using “servi= ce graph”, I guess it should be a graph of network functions (from ETSI= ). Thus, maybe it is nature to use “network service graph” to d= enote “an abstraction view of a network infrastructure including netw= ork service attributes”. However, it is somewhat hard for me to understand this definition before reading your explanation. I think = at least it should be described as a graph of nodes and links (as your desc= ription), rather than an “abstraction view” which is abstract i= ndeed.

And I find= in the new charter the “network service graph” has been re-def= ined.

<snip>

However, I= ’m not sure about the exact meaning of “application based polic= ies”, which are “generated by network service systems to map th= e network service graph instance into specific network management policies”. I= feel in the definition there is nothing about the  applications…= ; Would there be some further explanation on this definition? Thank you ver= y much!

 

Well, my point was against incl= uding “services” in the definition. If what supa defines is a &= #8220;network service graph”, than this is barely an interface to sfc= , which is already described in draft-penno-sfc-yang (http://tools.ietf.org/html/draft-= penno-sfc-yang-05).

 

 Besi= des, I found the service graphs must be composed to resolve conflicts betwe= en applications before being applied to the network. However it seems this task is not in the milestones. Is this task covered by other gr= oups or did I miss something? <= /span>

 

This is the “policy”= ; part. How to resolve conflicts and permissions before applying any change= . SUPA should provide guidelines on how to resolve these in a deterministic= way. 

 

Again, my personal view is that= supa has three main blocks of work: 

- Defining an abstract model (a= generic topology graph, basically a better version of draft-clemm-i2rs-yan= g-network-topo)

- Define how the model will be = defined and transported, if possible with an existing protocol (could be YA= NG for example)

- Define the guidelines to appl= y policies, in other words how an abstract model should be applied to devic= es (virtual or not) 

 

My 2 cents. 

 

JF 

 

--_000_4B29BA0800EE424E850D442A1A3D18034073BC1CSZXEMA510MBXchi_-- From nobody Wed Sep 3 20:00:47 2014 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F4E51A0473 for ; Wed, 3 Sep 2014 20:00:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668] 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 bL4FMpxAcuZw for ; Wed, 3 Sep 2014 20:00:20 -0700 (PDT) Received: from cernet.edu.cn (mail.cernet.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with ESMTP id 481131A0675 for ; Wed, 3 Sep 2014 20:00:18 -0700 (PDT) Received: from AndrewYaoPC (unknown [166.111.132.217]) by centos (Coremail) with SMTP id AQAAf3DLHQW31QdUpPokAA--.728S2; Thu, 04 Sep 2014 11:00:07 +0800 (CST) From: "Guang Yao" To: "'Felix'" , "'JF Tremblay'" , References: <002c01cfc688$b6d618d0$24824a70$@cernet.edu.cn> <8ECF7AE3-6C16-4E8B-B842-22ABB36B2990@viagenie.ca> <000201cfc71c$e261ddb0$a7259910$@cernet.edu.cn> <4B29BA0800EE424E850D442A1A3D18034073BC1C@SZXEMA510-MBX.china.huawei.com> In-Reply-To: <4B29BA0800EE424E850D442A1A3D18034073BC1C@SZXEMA510-MBX.china.huawei.com> Date: Thu, 4 Sep 2014 11:00:08 +0800 Message-ID: <000501cfc7ec$562a5d60$027f1820$@cernet.edu.cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01CFC82F.644F4B10" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQHpbgsQaqV9nPW7KrnGcVzw8yWyYwIy17hBAagAoSABe4qTegKIHmjsm34HcWA= Content-Language: zh-cn X-CM-TRANSID: AQAAf3DLHQW31QdUpPokAA--.728S2 X-Coremail-Antispam: 1UD129KBjvJXoWxZw18Cr4DuF4kCF45ur17Jrb_yoWrJr4kpF yagFnYgrs7WF17Cw4kZw1rWr45uFWkGF43C3sxJ34j9ws0gr1I9r1agw1Yvr4UWrWrJr10 v3yS9Fy5uw45ArJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUU9ab7Iv0xC_tr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2z4x0Y4vE2Ix0cI8IcVAFwI0_JFI_Gr1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr0_ Cr1l84ACjcxK6I8E87Iv67AKxVWxJVW8Jr1l84ACjcxK6I8E87Iv6xkF7I0E14v26r4UJV WxJr1le2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG67k08I80eVW5JVWrJwAqx4xG6c80 4VAFz4xC04v7Mc02F40Ew4AK048IF2xKxVWUJVW8JwAqx4xG6xAIxVCFxsxG0wAv7VC2z2 80aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcxkI7VAKI48JM4x0Y48I cxkI7VAKI48G6xCjnVAKz4kxMx8GjcxK6IxK0xIIj40E5I8CrwCY02Avz4vE14v_Gr4l42 xK82IYc2Ij64vIr41lx2IqxVAqx4xG67AKxVWUGVWUWwC20s026x8GjcxK67AKxVWUGVWU WwC2zVAF1VAY17CE14v26r1Y6r17MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr 0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0xvE42xK8VAvwI8IcIk0rVWr Zr1j6s0DMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Jr0_Gr UvcSsGvfC2KfnxnUUI43ZEXa7IU8Z0eJUUUUU== X-CM-SenderInfo: 51drw3xdqjquphuqv3oohg3hdfq/ Archived-At: http://mailarchive.ietf.org/arch/msg/supa/eSiklrUrwGpCL_GgN4IjcI5NoYw Subject: Re: [Supa] Any example of "network service graph"? X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 03:00:33 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0006_01CFC82F.644F4B10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Felix, When I read "So that the management applications can dynamically reconfigure the network to do what they want.", two concerns come to my mind: 1. What if the configurations of two applications conflict each other? 2. What if the configuration is malicious or wrongly generated, and can result in loop/packet drop/unreach ? Maybe these topics should be mentioned in the charter? Best regards, Guang From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Felix Sent: Thursday, September 04, 2014 10:39 AM To: JF Tremblay; supa@ietf.org Subject: Re: [Supa] Any example of "network service graph"? Hi JF, >From my point, the information of configuration can't be found from the first view of "network graph". The main Goal of SUPA is to provide vendor-neutral network level configuration model to management applications. So that the management applications can dynamically reconfigure the network to do what they want. So I tend to choose something like "Network level configuration graph" or "vendor-neutral network level configuration graph" Best regards! Felix From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of JF Tremblay Sent: Thursday, September 04, 2014 4:30 AM To: supa@ietf.org Subject: Re: [Supa] Any example of "network service graph"? On Sep 2, 2014, at 10:15 PM, Guang Yao > wrote: If "network graph" is used, I can understand it is a topology graph which contains network elements (e.g., servers, switches). If using "service graph", I guess it should be a graph of network functions (from ETSI). Thus, maybe it is nature to use "network service graph" to denote "an abstraction view of a network infrastructure including network service attributes". However, it is somewhat hard for me to understand this definition before reading your explanation. I think at least it should be described as a graph of nodes and links (as your description), rather than an "abstraction view" which is abstract indeed. And I find in the new charter the "network service graph" has been re-defined. However, I'm not sure about the exact meaning of "application based policies", which are "generated by network service systems to map the network service graph instance into specific network management policies". I feel in the definition there is nothing about the applications. Would there be some further explanation on this definition? Thank you very much! Well, my point was against including "services" in the definition. If what supa defines is a "network service graph", than this is barely an interface to sfc, which is already described in draft-penno-sfc-yang (http://tools.ietf.org/html/draft-penno-sfc-yang-05). Besides, I found the service graphs must be composed to resolve conflicts between applications before being applied to the network. However it seems this task is not in the milestones. Is this task covered by other groups or did I miss something? This is the "policy" part. How to resolve conflicts and permissions before applying any change. SUPA should provide guidelines on how to resolve these in a deterministic way. Again, my personal view is that supa has three main blocks of work: - Defining an abstract model (a generic topology graph, basically a better version of draft-clemm-i2rs-yang-network-topo) - Define how the model will be defined and transported, if possible with an existing protocol (could be YANG for example) - Define the guidelines to apply policies, in other words how an abstract model should be applied to devices (virtual or not) My 2 cents. JF ------=_NextPart_000_0006_01CFC82F.644F4B10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Felix,

 

When I read “So that the management applications can dynamically reconfigure the = network to do what they want.”, two concerns come to my mind:

 

1.       = What if the configurations of two applications conflict each = other?

2.       = What if the configuration is malicious or wrongly generated, and can = result in loop/packet drop/unreach ?

 

Maybe these topics should be mentioned in the = charter?

 

Best regards,

Guang

 

From: Supa = [mailto:supa-bounces@ietf.org] On Behalf Of Felix
Sent: = Thursday, September 04, 2014 10:39 AM
To: JF Tremblay; = supa@ietf.org
Subject: Re: [Supa] Any example of "network = service graph"?

 

Hi JF,

 

From my point, the information of configuration can’t be found = from the first view of “network = graph”.

 

The main Goal of SUPA is to provide vendor-neutral network level = configuration model to management applications. So that the management = applications can dynamically reconfigure the network to do what they = want. So I tend to choose something like “Network level = configuration graph” or “vendor-neutral network level = configuration graph”

 

Best regards!

Felix

 

 

From:= = Supa [mailto:supa-bounces@ietf.org] = On Behalf Of JF Tremblay
Sent: Thursday, September 04, = 2014 4:30 AM
To: supa@ietf.org
Subject: Re: = [Supa] Any example of "network service = graph"?

 

 

=

On Sep 2, 2014, at 10:15 PM, Guang Yao <yaoguang@cernet.edu.cn> = wrote:

 

If “network graph” is used, I can understand it is a = topology graph which contains network elements (e.g., servers, = switches). If using “service graph”, I guess it should be a = graph of network functions (from ETSI). Thus, maybe it is nature to use = “network service graph” to denote “an abstraction view = of a network infrastructure including network service attributes”. = However, it is somewhat hard for me to understand this definition before = reading your explanation. I think at least it should be described as a = graph of nodes and links (as your description), rather than an = “abstraction view” which is abstract = indeed.

And I find in the new charter the “network service graph” = has been re-defined.

<snip>

However, I’m not sure about the exact meaning of = “application based policies”, which are “generated by = network service systems to map the network service graph instance into = specific network management policies”. I feel in the definition = there is nothing about the  applications… Would there be some = further explanation on this definition? Thank you very = much!

 

Well, my point was against including = “services” in the definition. If what supa defines is a = “network service graph”, than this is barely an interface to = sfc, which is already described in draft-penno-sfc-yang (http://tools.= ietf.org/html/draft-penno-sfc-yang-05).

 

 Besides, I found the service graphs must be composed to resolve = conflicts between applications before being applied to the network. = However it seems this task is not in the milestones. Is this task = covered by other groups or did I miss = something? 

 

This is the “policy” part. How to resolve = conflicts and permissions before applying any change. SUPA should = provide guidelines on how to resolve these in a deterministic = way. 

 

Again, my personal view is that supa has three main = blocks of work: 

- = Defining an abstract model (a generic topology graph, basically a better = version of = draft-clemm-i2rs-yang-network-topo)

- Define how the model will be defined and = transported, if possible with an existing protocol (could be YANG for = example)

- Define the = guidelines to apply policies, in other words how an abstract model = should be applied to devices (virtual or = not) 

 

My 2 cents. 

 

JF 

 

------=_NextPart_000_0006_01CFC82F.644F4B10-- From nobody Wed Sep 3 20:16:25 2014 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A30F1A0675 for ; Wed, 3 Sep 2014 20:16:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.868 X-Spam-Level: X-Spam-Status: No, score=-4.868 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, 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 K_tWB63L5a35 for ; Wed, 3 Sep 2014 20:16:20 -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 EE3DD1A04FA for ; Wed, 3 Sep 2014 20:16:19 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJA96623; Thu, 04 Sep 2014 03:16:18 +0000 (GMT) Received: from SZXEMA406-HUB.china.huawei.com (10.82.72.38) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 4 Sep 2014 04:16:17 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.57]) by SZXEMA406-HUB.china.huawei.com ([10.82.72.38]) with mapi id 14.03.0158.001; Thu, 4 Sep 2014 11:16:11 +0800 From: Felix To: Guang Yao , "'JF Tremblay'" , "supa@ietf.org" Thread-Topic: [Supa] Any example of "network service graph"? Thread-Index: Ac/Gh8AZTLQx+gy7TtGf8Y+pK8azPQAG6jcAAA2aswAAJj42gAAdhY1A//+AyQD//3cBEA== Date: Thu, 4 Sep 2014 03:16:11 +0000 Message-ID: <4B29BA0800EE424E850D442A1A3D18034073BC57@SZXEMA510-MBX.china.huawei.com> References: <002c01cfc688$b6d618d0$24824a70$@cernet.edu.cn> <8ECF7AE3-6C16-4E8B-B842-22ABB36B2990@viagenie.ca> <000201cfc71c$e261ddb0$a7259910$@cernet.edu.cn> <4B29BA0800EE424E850D442A1A3D18034073BC1C@SZXEMA510-MBX.china.huawei.com> <000501cfc7ec$562a5d60$027f1820$@cernet.edu.cn> In-Reply-To: <000501cfc7ec$562a5d60$027f1820$@cernet.edu.cn> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.114.148] Content-Type: multipart/alternative; boundary="_000_4B29BA0800EE424E850D442A1A3D18034073BC57SZXEMA510MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/supa/PuPVXeEhguKu7qF6ic2CFZ22wt0 Subject: Re: [Supa] Any example of "network service graph"? X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 03:16:23 -0000 --_000_4B29BA0800EE424E850D442A1A3D18034073BC57SZXEMA510MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Guang, I think that there need a mechanism in the controller or controller like fu= nction in network. The network level configuration should first reach the c= ontroller like function, and the controller should deal with the conflict b= etween applications. The anti-attack for malicious or wrongly configuration= should also be deal with in the controller like function. Best regards! Felix From: Guang Yao [mailto:yaoguang@cernet.edu.cn] Sent: Thursday, September 04, 2014 11:00 AM To: Felix; 'JF Tremblay'; supa@ietf.org Subject: RE: [Supa] Any example of "network service graph"? Hi Felix, When I read "So that the management applications can dynamically reconfigur= e the network to do what they want.", two concerns come to my mind: 1. What if the configurations of two applications conflict each other= ? 2. What if the configuration is malicious or wrongly generated, and c= an result in loop/packet drop/unreach ? Maybe these topics should be mentioned in the charter? Best regards, Guang From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Felix Sent: Thursday, September 04, 2014 10:39 AM To: JF Tremblay; supa@ietf.org Subject: Re: [Supa] Any example of "network service graph"? Hi JF, >From my point, the information of configuration can't be found from the fir= st view of "network graph". The main Goal of SUPA is to provide vendor-neutral network level configurat= ion model to management applications. So that the management applications c= an dynamically reconfigure the network to do what they want. So I tend to c= hoose something like "Network level configuration graph" or "vendor-neutral= network level configuration graph" Best regards! Felix From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of JF Tremblay Sent: Thursday, September 04, 2014 4:30 AM To: supa@ietf.org Subject: Re: [Supa] Any example of "network service graph"? On Sep 2, 2014, at 10:15 PM, Guang Yao > wrote: If "network graph" is used, I can understand it is a topology graph which c= ontains network elements (e.g., servers, switches). If using "service graph= ", I guess it should be a graph of network functions (from ETSI). Thus, may= be it is nature to use "network service graph" to denote "an abstraction vi= ew of a network infrastructure including network service attributes". Howev= er, it is somewhat hard for me to understand this definition before reading= your explanation. I think at least it should be described as a graph of no= des and links (as your description), rather than an "abstraction view" whic= h is abstract indeed. And I find in the new charter the "network service graph" has been re-defin= ed. However, I'm not sure about the exact meaning of "application based policie= s", which are "generated by network service systems to map the network serv= ice graph instance into specific network management policies". I feel in th= e definition there is nothing about the applications... Would there be som= e further explanation on this definition? Thank you very much! Well, my point was against including "services" in the definition. If what = supa defines is a "network service graph", than this is barely an interface= to sfc, which is already described in draft-penno-sfc-yang (http://tools.i= etf.org/html/draft-penno-sfc-yang-05). Besides, I found the service graphs must be composed to resolve conflicts = between applications before being applied to the network. However it seems = this task is not in the milestones. Is this task covered by other groups or= did I miss something? This is the "policy" part. How to resolve conflicts and permissions before = applying any change. SUPA should provide guidelines on how to resolve these= in a deterministic way. Again, my personal view is that supa has three main blocks of work: - Defining an abstract model (a generic topology graph, basically a better = version of draft-clemm-i2rs-yang-network-topo) - Define how the model will be defined and transported, if possible with an= existing protocol (could be YANG for example) - Define the guidelines to apply policies, in other words how an abstract m= odel should be applied to devices (virtual or not) My 2 cents. JF --_000_4B29BA0800EE424E850D442A1A3D18034073BC57SZXEMA510MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Guang,<= o:p>

 = ;

I think th= at there need a mechanism in the controller or controller like function in = network. The network level configuration should first reach the controller like function, and the controller should deal with the conflict between applications.= The anti-attack for malicious or wrongly configuration should also be deal with in the controller like function.

 = ;

Best regar= ds!

Felix=

 = ;

 = ;

From: Guang Yao [mailto:yaoguang@cernet.edu.cn]
Sent: Thursday, September 04, 2014 11:00 AM
To: Felix; 'JF Tremblay'; supa@ietf.org
Subject: RE: [Supa] Any example of "network service graph"= ?

 

Hi Felix,<= o:p>

 = ;

When I rea= d “So that the manag= ement applications can dynamically reconfigure the network to do what they want.”, two concerns come to my mind:<= o:p>

 = ;

1.       What if the configurations= of two applications conflict each other?

2.       What if the configuration = is malicious or wrongly generated, and can result in loop/packet drop/unrea= ch ?

 = ;

Maybe thes= e topics should be mentioned in the charter?

 = ;

Best regar= ds,

Guang=

 = ;

From: Supa [mail= to:supa-bounces@ietf.org] On Behalf Of Felix
Sent: Thursday, September 04, 2014 10:39 AM
To: JF Tremblay; supa@ietf.org<= br> Subject: Re: [Supa] Any example of "network service graph"= ?

 

Hi JF,

 = ;

From my po= int, the information of configuration can’t be found from the first v= iew of “network graph”.

 = ;

The main G= oal of SUPA is to provide vendor-neutral network level configuration model = to management applications. So that the management applications can dynamically reconfigure the network to do what they want. So I tend to= choose something like “Network level configuration graph” or &= #8220;vendor-neutral network level configuration graph”

 = ;

Best regar= ds!

Felix=

 = ;

 = ;

From: Supa [mailto= :supa-bounces@ietf.org] On Behalf Of JF Tremblay
Sent: Thursday, September 04, 2014 4:30 AM
To: supa@ietf.org
Subject: Re: [Supa] Any example of "network service graph"= ?

 

&nbs= p;

On Sep 2, 2014, at 10:15 PM, Gu= ang Yao <yaoguang@cernet.edu.c= n> wrote:

=  

If “= network graph” is used, I can understand it is a topology graph which= contains network elements (e.g., servers, switches). If using “servi= ce graph”, I guess it should be a graph of network functions (from ETSI= ). Thus, maybe it is nature to use “network service graph” to d= enote “an abstraction view of a network infrastructure including netw= ork service attributes”. However, it is somewhat hard for me to understand this definition before reading your explanation. I think = at least it should be described as a graph of nodes and links (as your desc= ription), rather than an “abstraction view” which is abstract i= ndeed.

And I find= in the new charter the “network service graph” has been re-def= ined.

= <snip>

However, I= ’m not sure about the exact meaning of “application based polic= ies”, which are “generated by network service systems to map th= e network service graph instance into specific network management policies”. I= feel in the definition there is nothing about the  applications…= ; Would there be some further explanation on this definition? Thank you ver= y much!

 

Well, my point was against incl= uding “services” in the definition. If what supa defines is a &= #8220;network service graph”, than this is barely an interface to sfc= , which is already described in draft-penno-sfc-yang (http://tools.ietf.org/html/draft-= penno-sfc-yang-05).

 

 Besi= des, I found the service graphs must be composed to resolve conflicts betwe= en applications before being applied to the network. However it seems this task is not in the milestones. Is this task covered by other gr= oups or did I miss something? <= /span>

 

This is the “policy”= ; part. How to resolve conflicts and permissions before applying any change= . SUPA should provide guidelines on how to resolve these in a deterministic= way. 

 

Again, my personal view is that= supa has three main blocks of work: 

- Defining an abstract model (a= generic topology graph, basically a better version of draft-clemm-i2rs-yan= g-network-topo)

- Define how the model will be = defined and transported, if possible with an existing protocol (could be YA= NG for example)

- Define the guidelines to appl= y policies, in other words how an abstract model should be applied to devic= es (virtual or not) 

 

My 2 cents. 

 

JF 

 

--_000_4B29BA0800EE424E850D442A1A3D18034073BC57SZXEMA510MBXchi_-- From nobody Wed Sep 3 20:18:06 2014 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D3441A0AA3 for ; Wed, 3 Sep 2014 20:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 RTKOPkkeTVZH for ; Wed, 3 Sep 2014 20:18:00 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with ESMTP id 1004F1A0675 for ; Wed, 3 Sep 2014 20:17:59 -0700 (PDT) Received: from AndrewYaoPC (unknown [166.111.132.217]) by centos (Coremail) with SMTP id AQAAf3AL3wLm2QdUx_wkAA--.1037S2; Thu, 04 Sep 2014 11:17:58 +0800 (CST) From: "Guang Yao" To: "'JF Tremblay'" , References: <002c01cfc688$b6d618d0$24824a70$@cernet.edu.cn> <8ECF7AE3-6C16-4E8B-B842-22ABB36B2990@viagenie.ca> <000201cfc71c$e261ddb0$a7259910$@cernet.edu.cn> In-Reply-To: Date: Thu, 4 Sep 2014 11:17:59 +0800 Message-ID: <000a01cfc7ee$d4700a10$7d501e30$@cernet.edu.cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000B_01CFC831.E294D0B0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQHpbgsQaqV9nPW7KrnGcVzw8yWyYwIy17hBAagAoSABe4qTepuSSYRQ Content-Language: zh-cn X-CM-TRANSID: AQAAf3AL3wLm2QdUx_wkAA--.1037S2 X-Coremail-Antispam: 1UD129KBjvJXoWxWw47uFW5try7tr4xCr1xKrg_yoWrGF45pw 1agF1vgrn7Ww17Cw4Ivw4rWFWF9FWkCws8Cw1rG34jvws0gFyI9F47tr4Yvr4UWrWrGr10 vr4Yvry5uan8Z3DanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUU9Sb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2z4x0Y4vE2Ix0cI8IcVAFwI0_JFI_Gr1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr0_ Cr1l84ACjcxK6I8E87Iv67AKxVWxJVW8Jr1l84ACjcxK6I8E87Iv6xkF7I0E14v26r4UJV WxJr1le2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG67k08I80eVW5JVWrJwAqx4xG6c80 4VAFz4xC04v7Mc02F40Ew4AK048IF2xKxVWUJVW8JwAqx4xG6xAIxVCFxsxG0wAv7VC2z2 80aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcxkI7VAKI48JM4x0Y48I cxkI7VAKI48G6xCjnVAKz4kxMx8GjcxK6IxK0xIIj40E5I8CrwCY02Avz4vE14v_Gr4l42 xK82IYc2Ij64vIr41lx2IqxVAqx4xG67AKxVWUGVWUWwC20s026x8GjcxK67AKxVWUGVWU WwC2zVAF1VAY17CE14v26r1Y6r17MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr 0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0xvE42xK8VAvwI8IcIk0rVWr Jr0_WFyUJwCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r1j6r 4UYxBIdaVFxhVjvjDU0xZFpf9x07brrWrUUUUU= X-CM-SenderInfo: 51drw3xdqjquphuqv3oohg3hdfq/ Archived-At: http://mailarchive.ietf.org/arch/msg/supa/EKftXL0O_PPGdnylpry7CXD_E5c Subject: Re: [Supa] Any example of "network service graph"? X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 03:18:04 -0000 This is a multipart message in MIME format. ------=_NextPart_000_000B_01CFC831.E294D0B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi JF, Thank you very much for your kind reply. As I can understand, the procedure may be like this: 1. At first "an abstracted view" of the network is formed. It has nothing about the applications and is only determined by the network topology. This can be the "topology graph" you mentioned. 2. The "abstracted view" is delivered to the applications. Then each application determine how each service should be deployed in the "abstracted view". For example, they define functions/polices on each node of the topology. 3. The network management system collects the requirements from the applications. Then it merges the requirements from the applications, resolves the conflicts, and checks errors. After that, it integrate the services to the topology graph. Then the topology graph will contains the service information. Then it would be OK to name the graph " network service graph". It is not a SFC since it also contains network topology. 4. The polices in the integrated graph are finally applied to the network devices, through NETCONF or something else. I inferred the whole procedure because I don't find the specifications in the existing documents. Please kindly correct me if there are misunderstandings. Best regards, Guang From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of JF Tremblay Sent: Thursday, September 04, 2014 4:30 AM To: supa@ietf.org Subject: Re: [Supa] Any example of "network service graph"? On Sep 2, 2014, at 10:15 PM, Guang Yao > wrote: If "network graph" is used, I can understand it is a topology graph which contains network elements (e.g., servers, switches). If using "service graph", I guess it should be a graph of network functions (from ETSI). Thus, maybe it is nature to use "network service graph" to denote "an abstraction view of a network infrastructure including network service attributes". However, it is somewhat hard for me to understand this definition before reading your explanation. I think at least it should be described as a graph of nodes and links (as your description), rather than an "abstraction view" which is abstract indeed. And I find in the new charter the "network service graph" has been re-defined. However, I'm not sure about the exact meaning of "application based policies", which are "generated by network service systems to map the network service graph instance into specific network management policies". I feel in the definition there is nothing about the applications. Would there be some further explanation on this definition? Thank you very much! Well, my point was against including "services" in the definition. If what supa defines is a "network service graph", than this is barely an interface to sfc, which is already described in draft-penno-sfc-yang (http://tools.ietf.org/html/draft-penno-sfc-yang-05). Besides, I found the service graphs must be composed to resolve conflicts between applications before being applied to the network. However it seems this task is not in the milestones. Is this task covered by other groups or did I miss something? This is the "policy" part. How to resolve conflicts and permissions before applying any change. SUPA should provide guidelines on how to resolve these in a deterministic way. Again, my personal view is that supa has three main blocks of work: - Defining an abstract model (a generic topology graph, basically a better version of draft-clemm-i2rs-yang-network-topo) - Define how the model will be defined and transported, if possible with an existing protocol (could be YANG for example) - Define the guidelines to apply policies, in other words how an abstract model should be applied to devices (virtual or not) My 2 cents. JF ------=_NextPart_000_000B_01CFC831.E294D0B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi JF,

 

Thank you very much for your kind reply.

 

As I can understand, the procedure may be like = this:

 

1.       = At first “an abstracted view” of the network is formed. = It has nothing about the applications and is only determined by the = network topology. This can be the “topology graph” you = mentioned.

2.       = The “abstracted view” is delivered to the applications. = Then each application determine how each service should be deployed in = the “abstracted view”. For example, they define = functions/polices on each node of the topology.

3.       = The network management system collects the requirements from the = applications. Then it merges the requirements from the applications, = resolves the conflicts, and checks errors. After that, it integrate the = services to the topology graph. Then the topology graph will contains = the service information. Then it would be OK to name the graph “ = network service graph”. It is not a SFC since it also contains = network topology.

4.       = The polices in the integrated graph are finally applied to the = network devices, through NETCONF or something = else.

 

I inferred the whole procedure because I don’t find the = specifications in the existing documents. Please kindly correct me if = there are misunderstandings.

 

Best regards,

Guang

 

From: Supa = [mailto:supa-bounces@ietf.org] On Behalf Of JF = Tremblay
Sent: Thursday, September 04, 2014 4:30 = AM
To: supa@ietf.org
Subject: Re: [Supa] Any example = of "network service = graph"?

 

 

=

On Sep 2, 2014, at 10:15 PM, Guang Yao <yaoguang@cernet.edu.cn> = wrote:



If “network graph” is used, I can understand it is a = topology graph which contains network elements (e.g., servers, = switches). If using “service graph”, I guess it should be a = graph of network functions (from ETSI). Thus, maybe it is nature to use = “network service graph” to denote “an abstraction view = of a network infrastructure including network service attributes”. = However, it is somewhat hard for me to understand this definition before = reading your explanation. I think at least it should be described as a = graph of nodes and links (as your description), rather than an = “abstraction view” which is abstract = indeed.

And I find in the new charter the “network service graph” = has been re-defined.

<snip>

However, I’m not sure about the exact meaning of = “application based policies”, which are “generated by = network service systems to map the network service graph instance into = specific network management policies”. I feel in the definition = there is nothing about the  applications… Would there be some = further explanation on this definition? Thank you very = much!

 

Well, my point was against including = “services” in the definition. If what supa defines is a = “network service graph”, than this is barely an interface to = sfc, which is already described in draft-penno-sfc-yang (http://tools.= ietf.org/html/draft-penno-sfc-yang-05).

 

 Besides, I found the service graphs must be composed to resolve = conflicts between applications before being applied to the network. = However it seems this task is not in the milestones. Is this task = covered by other groups or did I miss = something? 

 

This is the “policy” part. How to resolve = conflicts and permissions before applying any change. SUPA should = provide guidelines on how to resolve these in a deterministic = way. 

 

Again, my personal view is that supa has three main = blocks of work: 

- = Defining an abstract model (a generic topology graph, basically a better = version of = draft-clemm-i2rs-yang-network-topo)

- Define how the model will be defined and = transported, if possible with an existing protocol (could be YANG for = example)

- Define the = guidelines to apply policies, in other words how an abstract model = should be applied to devices (virtual or = not) 

 

My 2 cents. 

 

JF 

 

------=_NextPart_000_000B_01CFC831.E294D0B0-- From nobody Wed Sep 3 20:22:08 2014 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60F841A879C for ; Wed, 3 Sep 2014 20:22:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668] 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 m8mZahPCS0GA for ; Wed, 3 Sep 2014 20:22:04 -0700 (PDT) Received: from cernet.edu.cn (mail.cernet.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with ESMTP id AE4F21A6F4A for ; Wed, 3 Sep 2014 20:22:03 -0700 (PDT) Received: from AndrewYaoPC (unknown [166.111.132.217]) by centos (Coremail) with SMTP id AQAAf3DLHQXU2gdUKv0kAA--.729S2; Thu, 04 Sep 2014 11:21:57 +0800 (CST) From: "Guang Yao" To: "'Felix'" , "'JF Tremblay'" , References: <002c01cfc688$b6d618d0$24824a70$@cernet.edu.cn> <8ECF7AE3-6C16-4E8B-B842-22ABB36B2990@viagenie.ca> <000201cfc71c$e261ddb0$a7259910$@cernet.edu.cn> <4B29BA0800EE424E850D442A1A3D18034073BC1C@SZXEMA510-MBX.china.huawei.com> <000501cfc7ec$562a5d60$027f1820$@cernet.edu.cn> <4B29BA0800EE424E850D442A1A3D18034073BC57@SZXEMA510-MBX.china.huawei.com> In-Reply-To: <4B29BA0800EE424E850D442A1A3D18034073BC57@SZXEMA510-MBX.china.huawei.com> Date: Thu, 4 Sep 2014 11:21:58 +0800 Message-ID: <002001cfc7ef$62966b90$27c342b0$@cernet.edu.cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0021_01CFC832.70BB8050" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQHpbgsQaqV9nPW7KrnGcVzw8yWyYwIy17hBAagAoSABe4qTegKIHmjsAjKETrcCE15XFptb33qQ Content-Language: zh-cn X-CM-TRANSID: AQAAf3DLHQXU2gdUKv0kAA--.729S2 X-Coremail-Antispam: 1UD129KBjvJXoWxWw48Kr15Zr4xGFyxWw13XFb_yoWrur1rpF yagFn8Gws7WF1xCr4vqw1rGr45uaykGrsxC3ZxJ34j9ws8WryI9r1aq34YvrWUWrWrAr10 v3ya9Fy5u3Z8ZrJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUU9Sb7Iv0xC_Zr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2z4x0Y4vE2Ix0cI8IcVAFwI0_Jr0_JF4l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr0_ Cr1l84ACjcxK6I8E87Iv67AKxVWxJVW8Jr1l84ACjcxK6I8E87Iv6xkF7I0E14v26r4UJV WxJr1le2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG67k08I80eVW5JVWrJwAqx4xG6c80 4VAFz4xC04v7Mc02F40Ew4AK048IF2xKxVWUJVW8JwAqx4xG6xAIxVCFxsxG0wAv7VC0I7 IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4U M4x0Y48IcxkI7VAKI48JM4x0Y48IcxkI7VAKI48G6xCjnVAKz4kxMxkIecxEwVAFwVW8Gw CF04k20xvY0x0EwIxGrwC20s026c02F40E14v26r106r1rMI8I3I0E7480Y4vE14v26r10 6r1rMI8E67AF67kF1VAFwI0_Jrv_JF1lIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxV WUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIxAIcVCF04k26cxKx2IYs7xG 6Fyj6rWUJwCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r1j6r 4UYxBIdaVFxhVjvjDU0xZFpf9x07jsCztUUUUU= X-CM-SenderInfo: 51drw3xdqjquphuqv3oohg3hdfq/ Archived-At: http://mailarchive.ietf.org/arch/msg/supa/4V_zSGEHy98HeMoBh8K2cm7fiUk Subject: Re: [Supa] Any example of "network service graph"? X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 03:22:07 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0021_01CFC832.70BB8050 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit +1 Guang From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Felix Sent: Thursday, September 04, 2014 11:16 AM To: Guang Yao; 'JF Tremblay'; supa@ietf.org Subject: Re: [Supa] Any example of "network service graph"? Hi Guang, I think that there need a mechanism in the controller or controller like function in network. The network level configuration should first reach the controller like function, and the controller should deal with the conflict between applications. The anti-attack for malicious or wrongly configuration should also be deal with in the controller like function. Best regards! Felix From: Guang Yao [mailto:yaoguang@cernet.edu.cn] Sent: Thursday, September 04, 2014 11:00 AM To: Felix; 'JF Tremblay'; supa@ietf.org Subject: RE: [Supa] Any example of "network service graph"? Hi Felix, When I read "So that the management applications can dynamically reconfigure the network to do what they want.", two concerns come to my mind: 1. What if the configurations of two applications conflict each other? 2. What if the configuration is malicious or wrongly generated, and can result in loop/packet drop/unreach ? Maybe these topics should be mentioned in the charter? Best regards, Guang From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Felix Sent: Thursday, September 04, 2014 10:39 AM To: JF Tremblay; supa@ietf.org Subject: Re: [Supa] Any example of "network service graph"? Hi JF, >From my point, the information of configuration can't be found from the first view of "network graph". The main Goal of SUPA is to provide vendor-neutral network level configuration model to management applications. So that the management applications can dynamically reconfigure the network to do what they want. So I tend to choose something like "Network level configuration graph" or "vendor-neutral network level configuration graph" Best regards! Felix From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of JF Tremblay Sent: Thursday, September 04, 2014 4:30 AM To: supa@ietf.org Subject: Re: [Supa] Any example of "network service graph"? On Sep 2, 2014, at 10:15 PM, Guang Yao > wrote: If "network graph" is used, I can understand it is a topology graph which contains network elements (e.g., servers, switches). If using "service graph", I guess it should be a graph of network functions (from ETSI). Thus, maybe it is nature to use "network service graph" to denote "an abstraction view of a network infrastructure including network service attributes". However, it is somewhat hard for me to understand this definition before reading your explanation. I think at least it should be described as a graph of nodes and links (as your description), rather than an "abstraction view" which is abstract indeed. And I find in the new charter the "network service graph" has been re-defined. However, I'm not sure about the exact meaning of "application based policies", which are "generated by network service systems to map the network service graph instance into specific network management policies". I feel in the definition there is nothing about the applications. Would there be some further explanation on this definition? Thank you very much! Well, my point was against including "services" in the definition. If what supa defines is a "network service graph", than this is barely an interface to sfc, which is already described in draft-penno-sfc-yang (http://tools.ietf.org/html/draft-penno-sfc-yang-05). Besides, I found the service graphs must be composed to resolve conflicts between applications before being applied to the network. However it seems this task is not in the milestones. Is this task covered by other groups or did I miss something? This is the "policy" part. How to resolve conflicts and permissions before applying any change. SUPA should provide guidelines on how to resolve these in a deterministic way. Again, my personal view is that supa has three main blocks of work: - Defining an abstract model (a generic topology graph, basically a better version of draft-clemm-i2rs-yang-network-topo) - Define how the model will be defined and transported, if possible with an existing protocol (could be YANG for example) - Define the guidelines to apply policies, in other words how an abstract model should be applied to devices (virtual or not) My 2 cents. JF ------=_NextPart_000_0021_01CFC832.70BB8050 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1

 

Guang

 

From: Supa = [mailto:supa-bounces@ietf.org] On Behalf Of Felix
Sent: = Thursday, September 04, 2014 11:16 AM
To: Guang Yao; 'JF = Tremblay'; supa@ietf.org
Subject: Re: [Supa] Any example of = "network service graph"?

 

Hi Guang,

 

I think that there need a mechanism in the controller or controller = like function in network. The network level configuration should first = reach the controller like function, and the controller should deal with = the conflict between applications. The anti-attack for malicious or = wrongly configuration should also be deal with in the controller like = function.

 

Best regards!

Felix

 

 

From:= = Guang Yao [mailto:yaoguang@cernet.edu.cn]=
Sent: Thursday, September 04, 2014 11:00 AM
To: = Felix; 'JF Tremblay'; supa@ietf.org
Subject: RE: = [Supa] Any example of "network service = graph"?

 

Hi Felix,

 

When I read “So that the management applications can dynamically reconfigure the = network to do what they want.”, two concerns come to my mind:

 

1.     &nb= sp; What if the configurations of two applications conflict each = other?

2.     &nb= sp; What if the configuration is malicious or wrongly generated, and can = result in loop/packet drop/unreach ?

 

Maybe these topics should be mentioned in the = charter?

 

Best regards,

Guang

 

From: Supa [mailto:supa-bounces@ietf.org] = On Behalf Of Felix
Sent: Thursday, September 04, 2014 = 10:39 AM
To: JF Tremblay; supa@ietf.org
Subject: Re: = [Supa] Any example of "network service = graph"?

 

Hi JF,

 

From my point, the information of configuration can’t be found = from the first view of “network = graph”.

 

The main Goal of SUPA is to provide vendor-neutral network level = configuration model to management applications. So that the management = applications can dynamically reconfigure the network to do what they = want. So I tend to choose something like “Network level = configuration graph” or “vendor-neutral network level = configuration graph”

 

Best regards!

Felix

 

 

From:= = Supa [mailto:supa-bounces@ietf.org] = On Behalf Of JF Tremblay
Sent: Thursday, September 04, = 2014 4:30 AM
To: supa@ietf.org
Subject: Re: = [Supa] Any example of "network service = graph"?

 

 

=

On Sep 2, 2014, at 10:15 PM, Guang Yao <yaoguang@cernet.edu.cn> = wrote:

 

If “network graph” is used, I can understand it is a = topology graph which contains network elements (e.g., servers, = switches). If using “service graph”, I guess it should be a = graph of network functions (from ETSI). Thus, maybe it is nature to use = “network service graph” to denote “an abstraction view = of a network infrastructure including network service attributes”. = However, it is somewhat hard for me to understand this definition before = reading your explanation. I think at least it should be described as a = graph of nodes and links (as your description), rather than an = “abstraction view” which is abstract = indeed.

And I find in the new charter the “network service graph” = has been re-defined.

<snip>

However, I’m not sure about the exact meaning of = “application based policies”, which are “generated by = network service systems to map the network service graph instance into = specific network management policies”. I feel in the definition = there is nothing about the  applications… Would there be some = further explanation on this definition? Thank you very = much!

 

Well, my point was against including = “services” in the definition. If what supa defines is a = “network service graph”, than this is barely an interface to = sfc, which is already described in draft-penno-sfc-yang (http://tools.= ietf.org/html/draft-penno-sfc-yang-05).

 

 Besides, I found the service graphs must be composed to resolve = conflicts between applications before being applied to the network. = However it seems this task is not in the milestones. Is this task = covered by other groups or did I miss = something? 

 

This is the “policy” part. How to resolve = conflicts and permissions before applying any change. SUPA should = provide guidelines on how to resolve these in a deterministic = way. 

 

Again, my personal view is that supa has three main = blocks of work: 

- = Defining an abstract model (a generic topology graph, basically a better = version of = draft-clemm-i2rs-yang-network-topo)

- Define how the model will be defined and = transported, if possible with an existing protocol (could be YANG for = example)

- Define the = guidelines to apply policies, in other words how an abstract model = should be applied to devices (virtual or = not) 

 

My 2 cents. 

 

JF 

 

------=_NextPart_000_0021_01CFC832.70BB8050-- From nobody Fri Sep 5 07:18:43 2014 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F7C21A0703 for ; Fri, 5 Sep 2014 07:18:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, 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 Kr4JLteVtxlY for ; Fri, 5 Sep 2014 07:18:40 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 884A91A0701 for ; Fri, 5 Sep 2014 07:18:40 -0700 (PDT) Received: from h200.viagenie.ca (h200.viagenie.ca [206.123.31.200]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 6AAD2403C2 for ; Fri, 5 Sep 2014 10:18:39 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: JF Tremblay In-Reply-To: <20140903214437.GA81569@elstar.local> Date: Fri, 5 Sep 2014 10:18:39 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <002c01cfc688$b6d618d0$24824a70$@cernet.edu.cn> <8ECF7AE3-6C16-4E8B-B842-22ABB36B2990@viagenie.ca> <000201cfc71c$e261ddb0$a7259910$@cernet.edu.cn> <20140903214437.GA81569@elstar.local> To: supa@ietf.org X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/supa/MayFhRIm3oicDIXHil1CEQQ65Qk Subject: Re: [Supa] Any example of "network service graph"? X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 14:18:42 -0000 On Sep 3, 2014, at 5:44 PM, Juergen Schoenwaelder = wrote: > On Wed, Sep 03, 2014 at 04:30:09PM -0400, JF Tremblay wrote: >>=20 >> - Define how the model will be defined and transported, if possible = with an existing protocol (could be YANG for example) >>=20 >=20 > YANG is a data modeling language, not a protocol. NETCONF and RESTCONF > are protocols to access and manipulate data defined in YANG data > models. I assume people understand that but then I also see these > terms messed up more than occasionally=85 Ok, I agree this sentence was poorly worded. YANG applied to the model = definition, not the protocol, of course. The point was that *both* a = modelling language AND a transport have to be chosen or defined, but = that depending of the choice of the modelling language, the transport = might already be defined. If YANG is chosen as a modelling langage, then NETCONF or RESTCONF are a = given as the protocols.=20 JF=20= From nobody Fri Sep 5 08:01:42 2014 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E40A71A0711 for ; Fri, 5 Sep 2014 08:01:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668, 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 drWP5rvQc6L7 for ; Fri, 5 Sep 2014 08:01:34 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 376221A070F for ; Fri, 5 Sep 2014 08:01:34 -0700 (PDT) Received: from h200.viagenie.ca (h200.viagenie.ca [206.123.31.200]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 1F2CF403C2 for ; Fri, 5 Sep 2014 11:01:33 -0400 (EDT) From: JF Tremblay Content-Type: multipart/alternative; boundary="Apple-Mail=_076943FC-6D89-4886-980B-946402125DF2" Message-Id: <9EAC5D55-8460-40FF-82CD-ECB90BF6E3D4@viagenie.ca> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Date: Fri, 5 Sep 2014 11:01:34 -0400 References: <002c01cfc688$b6d618d0$24824a70$@cernet.edu.cn> <8ECF7AE3-6C16-4E8B-B842-22ABB36B2990@viagenie.ca> <000201cfc71c$e261ddb0$a7259910$@cernet.edu.cn> <4B29BA0800EE424E850D442A1A3D18034073BC1C@SZXEMA510-MBX.china.huawei.com> To: "supa@ietf.org" In-Reply-To: <4B29BA0800EE424E850D442A1A3D18034073BC1C@SZXEMA510-MBX.china.huawei.com> X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/supa/kQmmMCKgk_pbTiitWkOxypdDWPw Subject: Re: [Supa] Any example of "network service graph"? X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 15:01:38 -0000 --Apple-Mail=_076943FC-6D89-4886-980B-946402125DF2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Sep 3, 2014, at 10:39 PM, Felix wrote: > Hi JF, > =46rom my point, the information of configuration can=92t be found = from the first view of =93network graph=94. > The main Goal of SUPA is to provide vendor-neutral network level = configuration model to management applications. [...] Ok, I see this is where we disagree. =93network level=94 in the sentence = above really limits the graphs to layer-3 modelling, in my opinion. = Adding the word =93configuration=94 makes it even closer to the actual = configuration of the device and further from an actual useful = abstraction.=20 Do yo suggest that supa should be limited to network device = configuration? The value of centrally controlled networks is in the = quality of abstractions it can provide to higher levels (apps). Exposing = actual network layer-3 topology and configuration isn=92t a new thing. = This is what several other organizations are defining and it=92s being = done even within the ietf already. draft-clemm-i2rs-yang-network-topo, = for example, already defines a basic topology using YANG (which is = closely related to routing however). =20 Let=92s take for example a datacenter abstraction, one of supa=92s use = case. The goal here is to offer apps an abstracted view of datacenters = and allow them to modify parameters relating to the whole datacenter, = not single devices. Yes, the result will be actual configuration on = devices, but it should=92t be exposed to the app (unless it wants it). As an app d=E9velopper using supa, I=92d like to be able to send a = request to the controller like this: =93reserve me bandwidth x between = datacenters A and B from this time to that time.=94 This does=92t sound = like network level configuration=85 but maybe we=92re just disagreeing = on vocabulary here.=20 Of course it doesn=92t preclude that supa offers a network-device view = of the network. It just that it=92s not its main goal, in my opinion.=20 JF --Apple-Mail=_076943FC-6D89-4886-980B-946402125DF2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

On Sep 3, 2014, at = 10:39 PM, Felix <felix.lu@huawei.com> = wrote:

Hi JF,
=46rom my = point, the information of configuration can=92t be found from the first = view of =93network graph=94.
The main Goal of SUPA is to = provide vendor-neutral network level configuration model to management = applications. = [...]

Ok, I see this = is where we disagree. =93network level=94 in the sentence above really = limits the graphs to layer-3 modelling, in my opinion. Adding the word = =93configuration=94 makes it even closer to the actual configuration of = the device and further from an actual useful = abstraction. 

Do yo suggest that supa = should be limited to network device configuration? The value of = centrally controlled networks is in the quality of abstractions it can = provide to higher levels (apps). Exposing actual network layer-3 = topology and configuration isn=92t a new thing. This is what several = other organizations are defining and it=92s being done even within the = ietf already. draft-clemm-i2rs-yang-network-topo, for example, already = defines a basic topology using YANG (which is closely related to routing = however).   

Let=92s take for example = a datacenter abstraction, one of supa=92s use case. The goal here is to = offer apps an abstracted view of datacenters and allow them to modify = parameters relating to the whole datacenter, not single devices. Yes, = the result will be actual configuration on devices, but it should=92t be = exposed to the app (unless it wants it).

As an = app d=E9velopper using supa, I=92d like to be able to send a request to = the controller like this: =93reserve me bandwidth x between datacenters = A and B from this time to that time.=94 This does=92t sound like network = level configuration=85 but maybe we=92re just disagreeing on vocabulary = here. 

Of course it doesn=92t preclude = that supa offers a network-device view of the network. It just that it=92s= not its main goal, in my = opinion. 

JF



= --Apple-Mail=_076943FC-6D89-4886-980B-946402125DF2-- From nobody Fri Sep 5 08:19:33 2014 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93F3A1A0715 for ; Fri, 5 Sep 2014 08:19:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668, 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 L85a5v_OOYEH for ; Fri, 5 Sep 2014 08:19:29 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id B8BE01A0711 for ; Fri, 5 Sep 2014 08:19:29 -0700 (PDT) Received: from h200.viagenie.ca (h200.viagenie.ca [206.123.31.200]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 89F81403C2 for ; Fri, 5 Sep 2014 11:19:28 -0400 (EDT) From: JF Tremblay Content-Type: multipart/alternative; boundary="Apple-Mail=_6EEB6579-CB52-4DBB-9471-35FB6B1C2B3E" Message-Id: <0F8B45CF-41BB-4B4F-9C52-F40516232FB9@viagenie.ca> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Date: Fri, 5 Sep 2014 11:19:28 -0400 References: <002c01cfc688$b6d618d0$24824a70$@cernet.edu.cn> <8ECF7AE3-6C16-4E8B-B842-22ABB36B2990@viagenie.ca> <000201cfc71c$e261ddb0$a7259910$@cernet.edu.cn> <000a01cfc7ee$d4700a10$7d501e30$@cernet.edu.cn> To: supa@ietf.org In-Reply-To: <000a01cfc7ee$d4700a10$7d501e30$@cernet.edu.cn> X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/supa/yPKfu-2LzQvFCbIb3iEA3zDFEkg Subject: Re: [Supa] Any example of "network service graph"? X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 15:19:31 -0000 --Apple-Mail=_6EEB6579-CB52-4DBB-9471-35FB6B1C2B3E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Guang,=20 Thank you for providing a good concrete example.=20 On Sep 3, 2014, at 11:17 PM, Guang Yao wrote: >=20 > 1. At first =93an abstracted view=94 of the network is formed. = It has nothing about the applications and is only determined by the = network topology. This can be the =93topology graph=94 you mentioned. Sure, this is one use case for supa, but a very simple one that isn=92t = providing a lot of value compared what=92s already been done at the IETF = and in other forums.=20 > 2. The =93abstracted view=94 is delivered to the applications. = Then each application determine how each service should be deployed in = the =93abstracted view=94. For example, they define functions/polices on = each node of the topology. > 3. The network management system collects the requirements from = the applications. Then it merges the requirements from the applications, = resolves the conflicts, and checks errors. After that, it integrate the = services to the topology graph. Then the topology graph will contains = the service information. Then it would be OK to name the graph =93 = network service graph=94. It is not a SFC since it also contains network = topology. > 4. The polices in the integrated graph are finally applied to = the network devices, through NETCONF or something else. > =20 > I inferred the whole procedure because I don=92t find the = specifications in the existing documents. Please kindly correct me if = there are misunderstandings. Let=92s take another concrete example, but with an abstract view this = time.=20 1. Say my controller offers several views, for example L3 network = topology, L3VPN topologies, L2VPNs topologies and datacenter view.=20 An app may know in advance the available view or not (interesting = idea, do we need a discovery mechanism for the views? It might be = useful).=20 2. An app sends a request for a list of datacenters. 3. The controller sends a list of active datacenters=20 4. The app then uses the datacenter view to send a request specifying: = =93reserve 3 Gbps of bandwidth at high QOS between datacenters A and B = between 1:00 AM and 3:00 AM=94 Here, the view the app uses only contains datacenters, not devices, = links or other low-level information.=20 5. The controller translates (maps, compile, etc, they are synonyms) the = request into physical device configuration 6. The controller verifies if the current policy set allows the app to = make these changes.=20 7. The controller replies with a success/error type of message.=20 8. The app MAY request a complete view of the network and see what has = changed, but it=92s likely not to.=20 Does this example makes sense? It uses an abstracted datacenter view for = the network. This is why I believe it isn=92t right to say that supa = defines a =93network service graph=94 or "network level configuration=94. = It would limit the scope of the wg to something that=92s already been = done.=20 My 2 cents. Comments welcome.=20 JF --Apple-Mail=_6EEB6579-CB52-4DBB-9471-35FB6B1C2B3E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Guang, 
Thank you for providing = a good concrete example. 

On Sep 3, 2014, at = 11:17 PM, Guang Yao <yaoguang@cernet.edu.cn> = wrote:

1.       At first =93an abstracted view=94 of the network is = formed. It has nothing about the applications and is only determined by = the network topology. This can be the =93topology graph=94 you = mentioned.

Sure, = this is one use case for supa, but a very simple one that isn=92t = providing a lot of value compared what=92s already been done at the IETF = and in other forums. 


2.       The =93abstracted view=94 is delivered to the = applications. Then each application determine how each service should be = deployed in the =93abstracted view=94. For example, they define = functions/polices on each node of the = topology.
3.       The network management system collects the = requirements from the applications. Then it merges the requirements from = the applications, resolves the conflicts, and checks errors. After that, = it integrate the services to the topology graph. Then the topology graph = will contains the service information. Then it would be OK to name the = graph =93 network service graph=94. It is not a SFC since it also = contains network topology.
4.       The polices in the integrated graph are finally = applied to the network devices, through NETCONF or something = else.
 
I inferred the whole procedure because I don=92t find = the specifications in the existing documents. Please kindly correct me = if there are = misunderstandings.

Let= =92s take another concrete example, but with an abstract view this = time. 

1. Say my controller offers several = views, for example L3 network topology, L3VPN topologies, L2VPNs = topologies and datacenter view. 
   An app may = know in advance the available view or not (interesting idea, do we need = a discovery mechanism for the views? It might be = useful). 
2. An app sends a request for a list of = datacenters.
3. The controller sends a list of active = datacenters 
4. The app then uses the datacenter view to = send a request specifying: =93reserve 3 Gbps of bandwidth at high QOS = between datacenters A and B between 1:00 AM and 3:00 = AM=94
    Here, the view the app uses only contains = datacenters, not devices, links or other low-level = information. 
5. The controller translates (maps, = compile, etc, they are synonyms) the request into physical device = configuration
6. The controller verifies if the current policy = set allows the app to make these changes. 
7. The = controller replies with a success/error type of = message. 
8. The app MAY request a complete view of the = network and see what has changed, but it=92s likely not = to. 

Does this example makes sense? It = uses an abstracted datacenter view for the network. This is why I = believe it isn=92t right to say that supa defines a =93network service = graph=94 or "network level configuration=94. It would limit the scope of = the wg to something that=92s already been = done. 

My 2 cents. Comments = welcome. 

JF




= --Apple-Mail=_6EEB6579-CB52-4DBB-9471-35FB6B1C2B3E-- From nobody Tue Sep 9 00:12:37 2014 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 693371A0B14 for ; Tue, 9 Sep 2014 00:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.551 X-Spam-Level: X-Spam-Status: No, score=-3.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.652] 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 RxDqUcBfc-wX for ; Tue, 9 Sep 2014 00:12:32 -0700 (PDT) Received: from cernet.edu.cn (cernet.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with ESMTP id BF68E1A0B0E for ; Tue, 9 Sep 2014 00:12:31 -0700 (PDT) Received: from AndrewYaoPC (unknown [166.111.132.217]) by centos (Coremail) with SMTP id AQAAf3ArqAVcqA5U40MoAA--.1030S2; Tue, 09 Sep 2014 15:12:28 +0800 (CST) From: "Guang Yao" To: "'JF Tremblay'" , References: <002c01cfc688$b6d618d0$24824a70$@cernet.edu.cn> <8ECF7AE3-6C16-4E8B-B842-22ABB36B2990@viagenie.ca> <000201cfc71c$e261ddb0$a7259910$@cernet.edu.cn> <000a01cfc7ee$d4700a10$7d501e30$@cernet.edu.cn> <0F8B45CF-41BB-4B4F-9C52-F40516232FB9@viagenie.ca> In-Reply-To: <0F8B45CF-41BB-4B4F-9C52-F40516232FB9@viagenie.ca> Date: Tue, 9 Sep 2014 15:12:26 +0800 Message-ID: <001b01cfcbfd$692fabd0$3b8f0370$@cernet.edu.cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001C_01CFCC40.7754C090" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQHpbgsQaqV9nPW7KrnGcVzw8yWyYwIy17hBAagAoSABe4qTegHUhFqFAoAWjZObd8OFUA== Content-Language: zh-cn X-CM-TRANSID: AQAAf3ArqAVcqA5U40MoAA--.1030S2 X-Coremail-Antispam: 1UD129KBjvJXoWxXryfJrWkZr4fZw4UGFyrXrb_yoW5KrW5pF WYgFnFyrykWr18CrWI9w1xWryruas3Cw4UJFn3J34jvwnxGryI9F47tF1YvFy8urWfWr1Y vw4jyF98Z3WDZFJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUU9ab7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2z4x0Y4vE2Ix0cI8IcVAFwI0_Jr0_JF4l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Jr0_ Gr1l84ACjcxK6I8E87Iv67AKxVW8Jr0_Cr1UM28EF7xvwVC2z280aVCY1x0267AKxVWxJr 0_GcWle2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG67k08I80eVW5JVWrJwAqx4xG6c80 4VAFz4xC04v7Mc02F40Ew4AK048IF2xKxVWUJVW8JwAqx4xG6xAIxVCFxsxG0wAv7VC2z2 80aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcxkI7VAKI48JM4x0Y48I cxkI7VAKI48G6xCjnVAKz4kxMx8GjcxK6IxK0xIIj40E5I8CrwCY02Avz4vE14v_GF4l42 xK82IYc2Ij64vIr41lx2IqxVAqx4xG67AKxVWUGVWUWwC20s026x8GjcxK67AKxVWUGVWU WwC2zVAF1VAY17CE14v26r1Y6r17MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr 0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0xvE42xK8VAvwI8IcIk0rVWr Zr1j6s0DMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Jr0_Gr UvcSsGvfC2KfnxnUUI43ZEXa7IU5ylk3UUUUU== X-CM-SenderInfo: 51drw3xdqjquphuqv3oohg3hdfq/ Archived-At: http://mailarchive.ietf.org/arch/msg/supa/JQA_IoLmbl1naTN4cEwG-adCBVA Subject: Re: [Supa] Any example of "network service graph"? X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 07:12:35 -0000 This is a multipart message in MIME format. ------=_NextPart_000_001C_01CFCC40.7754C090 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi JF, This is a clear & interesting & useful example! If these features were supported, SUPA will be wonderful. One small question: You use "reserve 3 Gbps of bandwidth at high QOS between datacenters A and B between 1:00 AM and 3:00 AM" as the policy from the app. It seems SUPA should provide an exhausted list of high-level policy patterns? At least, it is hard for the controller to understand natural language. Or has this been done by some other group? Best regards, Guang From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of JF Tremblay Sent: Friday, September 05, 2014 11:19 PM To: supa@ietf.org Subject: Re: [Supa] Any example of "network service graph"? Guang, Thank you for providing a good concrete example. On Sep 3, 2014, at 11:17 PM, Guang Yao > wrote: 1. At first "an abstracted view" of the network is formed. It has nothing about the applications and is only determined by the network topology. This can be the "topology graph" you mentioned. Sure, this is one use case for supa, but a very simple one that isn't providing a lot of value compared what's already been done at the IETF and in other forums. 2. The "abstracted view" is delivered to the applications. Then each application determine how each service should be deployed in the "abstracted view". For example, they define functions/polices on each node of the topology. 3. The network management system collects the requirements from the applications. Then it merges the requirements from the applications, resolves the conflicts, and checks errors. After that, it integrate the services to the topology graph. Then the topology graph will contains the service information. Then it would be OK to name the graph " network service graph". It is not a SFC since it also contains network topology. 4. The polices in the integrated graph are finally applied to the network devices, through NETCONF or something else. I inferred the whole procedure because I don't find the specifications in the existing documents. Please kindly correct me if there are misunderstandings. Let's take another concrete example, but with an abstract view this time. 1. Say my controller offers several views, for example L3 network topology, L3VPN topologies, L2VPNs topologies and datacenter view. An app may know in advance the available view or not (interesting idea, do we need a discovery mechanism for the views? It might be useful). 2. An app sends a request for a list of datacenters. 3. The controller sends a list of active datacenters 4. The app then uses the datacenter view to send a request specifying: "reserve 3 Gbps of bandwidth at high QOS between datacenters A and B between 1:00 AM and 3:00 AM" Here, the view the app uses only contains datacenters, not devices, links or other low-level information. 5. The controller translates (maps, compile, etc, they are synonyms) the request into physical device configuration 6. The controller verifies if the current policy set allows the app to make these changes. 7. The controller replies with a success/error type of message. 8. The app MAY request a complete view of the network and see what has changed, but it's likely not to. Does this example makes sense? It uses an abstracted datacenter view for the network. This is why I believe it isn't right to say that supa defines a "network service graph" or "network level configuration". It would limit the scope of the wg to something that's already been done. My 2 cents. Comments welcome. JF ------=_NextPart_000_001C_01CFCC40.7754C090 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi JF,

 

This is a clear & interesting & useful = example!

 

If these features were supported, SUPA will be = wonderful.

 

One small question:

 

You use “reserve 3 Gbps of bandwidth at high QOS between = datacenters A and B between 1:00 AM and 3:00 AM” as the policy = from the app. It seems SUPA should provide an exhausted list of = high-level policy patterns? At least, it is hard for the controller to = understand natural language. Or has this been done by some other = group?

 

Best regards,

 

Guang

 

From: Supa = [mailto:supa-bounces@ietf.org] On Behalf Of JF = Tremblay
Sent: Friday, September 05, 2014 11:19 = PM
To: supa@ietf.org
Subject: Re: [Supa] Any example = of "network service = graph"?

 

Guang, 

Thank you for providing a good concrete = example. 

 

On = Sep 3, 2014, at 11:17 PM, Guang Yao <yaoguang@cernet.edu.cn> = wrote:

 = ;

1.     &nb= sp; At first “an abstracted view” of the network is formed. = It has nothing about the applications and is only determined by the = network topology. This can be the “topology graph” you = mentioned.

 

Sure, this is one use case for supa, but a very simple = one that isn’t providing a lot of value compared what’s = already been done at the IETF and in other = forums. 

 



2.     &nb= sp; The “abstracted view” is delivered to the applications. = Then each application determine how each service should be deployed in = the “abstracted view”. For example, they define = functions/polices on each node of the = topology.

3.     &nb= sp; The network management system collects the requirements from the = applications. Then it merges the requirements from the applications, = resolves the conflicts, and checks errors. After that, it integrate the = services to the topology graph. Then the topology graph will contains = the service information. Then it would be OK to name the graph “ = network service graph”. It is not a SFC since it also contains = network topology.

4.     &nb= sp; The polices in the integrated graph are finally applied to the = network devices, through NETCONF or something = else.

 

I inferred the whole procedure because I don’t find the = specifications in the existing documents. Please kindly correct me if = there are = misunderstandings.

 

Let’s take another concrete example, but with an = abstract view this time. 

 

1. Say my controller offers several views, for example = L3 network topology, L3VPN topologies, L2VPNs topologies and datacenter = view. 

  =  An app may know in advance the available view or not (interesting = idea, do we need a discovery mechanism for the views? It might be = useful). 

2. An app = sends a request for a list of datacenters.

3. The controller sends a list of active = datacenters 

4. The = app then uses the datacenter view to send a request specifying: = “reserve 3 Gbps of bandwidth at high QOS between datacenters A and = B between 1:00 AM and 3:00 AM”

    Here, the view the app uses only = contains datacenters, not devices, links or other low-level = information. 

5. The = controller translates (maps, compile, etc, they are synonyms) the = request into physical device configuration

6. The controller verifies if the current policy set = allows the app to make these changes. 

7. The controller replies with a success/error type of = message. 

8. The app = MAY request a complete view of the network and see what has changed, but = it’s likely not to. 

 

Does this example makes sense? It uses an abstracted = datacenter view for the network. This is why I believe it isn’t = right to say that supa defines a “network service graph” or = "network level configuration”. It would limit the scope of = the wg to something that’s already been = done. 

 

My 2 cents. Comments = welcome. 

 

JF

 

 

 

 

------=_NextPart_000_001C_01CFCC40.7754C090-- From nobody Wed Sep 10 00:36:07 2014 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31EDB1A0669 for ; Wed, 10 Sep 2014 00:35:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.852 X-Spam-Level: X-Spam-Status: No, score=-5.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, 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 o2MVERxPGmcy for ; Wed, 10 Sep 2014 00:35:53 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3169A1A0657 for ; Wed, 10 Sep 2014 00:35:53 -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 BJG36976; Wed, 10 Sep 2014 07:35:51 +0000 (GMT) Received: from SZXEMA401-HUB.china.huawei.com (10.82.72.33) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 10 Sep 2014 08:35:48 +0100 Received: from SZXEMA509-MBS.china.huawei.com ([169.254.2.196]) by SZXEMA401-HUB.china.huawei.com ([10.82.72.33]) with mapi id 14.03.0158.001; Wed, 10 Sep 2014 15:35:44 +0800 From: "Liushucheng (Will)" To: JF Tremblay , "supa@ietf.org" Thread-Topic: [Supa] Any example of "network service graph"? Thread-Index: Ac/Gh8AZTLQx+gy7TtGf8Y+pK8azPQAG6jcAAA2aswAAJj42gAAdhY1AADuV5QAA/HKCcA== Date: Wed, 10 Sep 2014 07:35:43 +0000 Message-ID: References: <002c01cfc688$b6d618d0$24824a70$@cernet.edu.cn> <8ECF7AE3-6C16-4E8B-B842-22ABB36B2990@viagenie.ca> <000201cfc71c$e261ddb0$a7259910$@cernet.edu.cn> <4B29BA0800EE424E850D442A1A3D18034073BC1C@SZXEMA510-MBX.china.huawei.com> <9EAC5D55-8460-40FF-82CD-ECB90BF6E3D4@viagenie.ca> In-Reply-To: <9EAC5D55-8460-40FF-82CD-ECB90BF6E3D4@viagenie.ca> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.78.79] Content-Type: multipart/alternative; boundary="_000_C9B5F12337F6F841B35C404CF0554ACB5FF6C778SZXEMA509MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/supa/1PSksmlqak_cP7ogpiZbaZlQJUE Subject: Re: [Supa] Any example of "network service graph"? X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2014 07:35:58 -0000 --_000_C9B5F12337F6F841B35C404CF0554ACB5FF6C778SZXEMA509MBSchi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable So, have we reached an agreement which term should be used? Regards, Will (Shucheng LIU) From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of JF Tremblay Sent: Friday, September 05, 2014 11:02 PM To: supa@ietf.org Subject: Re: [Supa] Any example of "network service graph"? On Sep 3, 2014, at 10:39 PM, Felix > wrote: Hi JF, >From my point, the information of configuration can't be found from the fir= st view of "network graph". The main Goal of SUPA is to provide vendor-neutral network level configurat= ion model to management applications. [...] Ok, I see this is where we disagree. "network level" in the sentence above = really limits the graphs to layer-3 modelling, in my opinion. Adding the wo= rd "configuration" makes it even closer to the actual configuration of the = device and further from an actual useful abstraction. Do yo suggest that supa should be limited to network device configuration? = The value of centrally controlled networks is in the quality of abstraction= s it can provide to higher levels (apps). Exposing actual network layer-3 t= opology and configuration isn't a new thing. This is what several other org= anizations are defining and it's being done even within the ietf already. d= raft-clemm-i2rs-yang-network-topo, for example, already defines a basic top= ology using YANG (which is closely related to routing however). Let's take for example a datacenter abstraction, one of supa's use case. Th= e goal here is to offer apps an abstracted view of datacenters and allow th= em to modify parameters relating to the whole datacenter, not single device= s. Yes, the result will be actual configuration on devices, but it should't= be exposed to the app (unless it wants it). As an app d=E9velopper using supa, I'd like to be able to send a request to= the controller like this: "reserve me bandwidth x between datacenters A an= d B from this time to that time." This does't sound like network level conf= iguration... but maybe we're just disagreeing on vocabulary here. Of course it doesn't preclude that supa offers a network-device view of the= network. It just that it's not its main goal, in my opinion. JF --_000_C9B5F12337F6F841B35C404CF0554ACB5FF6C778SZXEMA509MBSchi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

So, have we reached an ag= reement which term should be used?

 <= /p>

Regards,

Will (Shucheng LIU)

 <= /p>

From: Supa [ma= ilto:supa-bounces@ietf.org] On Behalf Of JF Tremblay
Sent: Friday, September 05, 2014 11:02 PM
To: supa@ietf.org
Subject: Re: [Supa] Any example of "network service graph"= ?

 

 

On Sep 3, 2014, at 10:39 PM, Felix <felix.lu@huawei.com> wrote:



Hi JF,<= /p>

From my point, the inform= ation of configuration can’t be found from the first view of “n= etwork graph”.

The main Goal of SUPA is = to provide vendor-neutral network level configuration model to management a= pplications. [...]

 

Ok, I see this is where we disagree. “network = level” in the sentence above really limits the graphs to layer-3 mode= lling, in my opinion. Adding the word “configuration” makes it = even closer to the actual configuration of the device and further from an actual useful abstraction. 

 

Do yo suggest that supa should be limited to network= device configuration? The value of centrally controlled networks is in the= quality of abstractions it can provide to higher levels (apps). Exposing a= ctual network layer-3 topology and configuration isn’t a new thing. This is what several other organiza= tions are defining and it’s being done even within the ietf already. = draft-clemm-i2rs-yang-network-topo, for example, already defines a basic to= pology using YANG (which is closely related to routing however).   

 

Let’s take for example a datacenter abstractio= n, one of supa’s use case. The goal here is to offer apps an abstract= ed view of datacenters and allow them to modify parameters relating to the = whole datacenter, not single devices. Yes, the result will be actual configuration on devices, but it should’t be e= xposed to the app (unless it wants it).

 

As an app d=E9velopper using supa, I’d like to= be able to send a request to the controller like this: “reserve me b= andwidth x between datacenters A and B from this time to that time.” = This does’t sound like network level configuration… but maybe we’re just disagreeing on vocabulary here. 

 

Of course it doesn’t preclude that supa offers= a network-device view of the network. It just that it’s not its main= goal, in my opinion. 

 

JF

 

 

 

--_000_C9B5F12337F6F841B35C404CF0554ACB5FF6C778SZXEMA509MBSchi_-- From nobody Wed Sep 10 01:48:42 2014 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2C791A06A6 for ; Wed, 10 Sep 2014 01:48:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_55=0.6] 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 bNP32nMrbJ1Z for ; Wed, 10 Sep 2014 01:48:38 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with ESMTP id 42E9E1A069C for ; Wed, 10 Sep 2014 01:48:37 -0700 (PDT) Received: from AndrewYaoPC (unknown [166.111.132.217]) by centos (Coremail) with SMTP id AQAAf3AL3wJdEBBUzAApAA--.1091S2; Wed, 10 Sep 2014 16:48:29 +0800 (CST) From: "Guang Yao" To: "'Liushucheng \(Will\)'" , "'JF Tremblay'" , References: <002c01cfc688$b6d618d0$24824a70$@cernet.edu.cn> <8ECF7AE3-6C16-4E8B-B842-22ABB36B2990@viagenie.ca> <000201cfc71c$e261ddb0$a7259910$@cernet.edu.cn> <4B29BA0800EE424E850D442A1A3D18034073BC1C@SZXEMA510-MBX.china.huawei.com> <9EAC5D55-8460-40FF-82CD-ECB90BF6E3D4@viagenie.ca> In-Reply-To: Date: Wed, 10 Sep 2014 16:48:26 +0800 Message-ID: <004f01cfccd3$fcf0d0c0$f6d27240$@cernet.edu.cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0050_01CFCD17.0B154940" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQHpbgsQaqV9nPW7KrnGcVzw8yWyYwIy17hBAagAoSABe4qTegKIHmjsAgiJSSUBdG9G1Jtr7OVQ Content-Language: zh-cn X-CM-TRANSID: AQAAf3AL3wJdEBBUzAApAA--.1091S2 X-Coremail-Antispam: 1UD129KBjvJXoWxZr43CFyfZFWxXr4fZrWUurg_yoW5ZF15pF WagFn8XF1Du3W8Gayvga1rCrWF93s7Crs8Can8J34jvrs8CFy29rn0q34YvFW8Cr1rJr1Y v3ya9FyrG3WDuFDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUU9Sb7Iv0xC_Cr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2z4x0Y4vE2Ix0cI8IcVAFwI0_JFI_Gr1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr0_ Cr1l84ACjcxK6I8E87Iv67AKxVW8Jr0_Cr1UM28EF7xvwVC2z280aVCY1x0267AKxVWxJr 0_GcWle2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG67k08I80eVW5JVWrJwAqx4xG6c80 4VAFz4xC04v7Mc02F40Ew4AK048IF2xKxVWUJVW8JwAqx4xG6xAIxVCFxsxG0wAv7VC2z2 80aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcxkI7VAKI48JM4x0Y48I cxkI7VAKI48G6xCjnVAKz4kxMx8GjcxK6IxK0xIIj40E5I8CrwCY02Avz4vE14v_GFyl42 xK82IYc2Ij64vIr41lx2IqxVAqx4xG67AKxVWUGVWUWwC20s026x8GjcxK67AKxVWUGVWU WwC2zVAF1VAY17CE14v26r1Y6r17MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr 0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0xvE42xK8VAvwI8IcIk0rVWr Jr0_WFyUJwCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r1j6r 4UYxBIdaVFxhVjvjDU0xZFpf9x07jYWlkUUUUU= X-CM-SenderInfo: 51drw3xdqjquphuqv3oohg3hdfq/ Archived-At: http://mailarchive.ietf.org/arch/msg/supa/bWHhlRcHXb5Oow45jeLSJuOQgBA Subject: Re: [Supa] Any example of "network service graph"? X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2014 08:48:41 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0050_01CFCD17.0B154940 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable IMHO: =20 1. The apps only require a =93network graph=94, which is an = abstraction view of the network topology. 2. The controller should merge the services and place the = functions on the real topology(service placement will be a problem). Then an = intermediate graph with topology and service is formed. This one can be named = =93network service graph=94. 3. Finally, the service-level graph is translated into a configuration-level(or policy-level) graph(maybe no graph is required = here), and the configurations are applied on the devices. =20 So, I think the graphs are actually different views on the same thing. = Maybe we should define it to be a model, and =93network graph=94, =93network = service graph=94, =93network level configuration graph=94 are just different = views of this model.=20 =20 From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Liushucheng = (Will) Sent: Wednesday, September 10, 2014 3:36 PM To: JF Tremblay; supa@ietf.org Subject: Re: [Supa] Any example of "network service graph"? =20 So, have we reached an agreement which term should be used? =20 Regards, Will (Shucheng LIU) =20 From: Supa [ = mailto:supa-bounces@ietf.org] On Behalf Of JF Tremblay Sent: Friday, September 05, 2014 11:02 PM To: supa@ietf.org Subject: Re: [Supa] Any example of "network service graph"? =20 =20 On Sep 3, 2014, at 10:39 PM, Felix > wrote: =20 Hi JF, >From my point, the information of configuration can=92t be found from = the first view of =93network graph=94. The main Goal of SUPA is to provide vendor-neutral network level configuration model to management applications. [...] =20 Ok, I see this is where we disagree. =93network level=94 in the sentence = above really limits the graphs to layer-3 modelling, in my opinion. Adding the word =93configuration=94 makes it even closer to the actual = configuration of the device and further from an actual useful abstraction.=20 =20 Do yo suggest that supa should be limited to network device = configuration? The value of centrally controlled networks is in the quality of = abstractions it can provide to higher levels (apps). Exposing actual network layer-3 topology and configuration isn=92t a new thing. This is what several = other organizations are defining and it=92s being done even within the ietf = already. draft-clemm-i2rs-yang-network-topo, for example, already defines a basic topology using YANG (which is closely related to routing however). =20 =20 Let=92s take for example a datacenter abstraction, one of supa=92s use = case. The goal here is to offer apps an abstracted view of datacenters and allow = them to modify parameters relating to the whole datacenter, not single = devices. Yes, the result will be actual configuration on devices, but it = should=92t be exposed to the app (unless it wants it). =20 As an app d=E9velopper using supa, I=92d like to be able to send a = request to the controller like this: =93reserve me bandwidth x between datacenters = A and B from this time to that time.=94 This does=92t sound like network level configuration=85 but maybe we=92re just disagreeing on vocabulary here.=20 =20 Of course it doesn=92t preclude that supa offers a network-device view = of the network. It just that it=92s not its main goal, in my opinion.=20 =20 JF =20 =20 =20 ------=_NextPart_000_0050_01CFCD17.0B154940 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

IMHO:

 

1.       = The apps only require a “network graph”, which is an = abstraction view of the network topology.

2.       = The controller should merge the services and place the functions on = the real topology(service placement will be a problem). Then an = intermediate graph with topology and service is formed. This one can be = named “network service graph”.

3.       = Finally, the service-level graph is translated into a = configuration-level(or policy-level) graph(maybe no graph is required = here), and the configurations are applied on the = devices.

 

So, I think the graphs are actually different views on the same = thing. Maybe we should define it to be a model, and “network = graph”, “network service graph”, “network level configuration graph” are just different views of this model. =

 

From: Supa = [mailto:supa-bounces@ietf.org] On Behalf Of Liushucheng = (Will)
Sent: Wednesday, September 10, 2014 3:36 = PM
To: JF Tremblay; supa@ietf.org
Subject: Re: = [Supa] Any example of "network service = graph"?

 

So, have we reached an agreement which term should be = used?

 

Regards,

Will (Shucheng LIU)

 

From:= = Supa [mailto:supa-= bounces@ietf.org] On = Behalf Of JF Tremblay
Sent: Friday, September 05, 2014 = 11:02 PM
To: supa@ietf.or= g
Subje= ct: Re: [Supa] Any example of "network service = graph"?

 

 

On Sep 3, 2014, at 10:39 PM, Felix <felix.lu@huawei.com> = wrote:

 

Hi JF,

From my point, the information of configuration can’t be found = from the first view of “network = graph”.

The main Goal of SUPA is to provide vendor-neutral network level = configuration model to management applications. = [...]

 

Ok, I see this is where we disagree. “network = level” in the sentence above really limits the graphs to layer-3 = modelling, in my opinion. Adding the word “configuration” = makes it even closer to the actual configuration of the device and = further from an actual useful = abstraction. 

 

Do yo suggest that supa should be limited to network = device configuration? The value of centrally controlled networks is in = the quality of abstractions it can provide to higher levels (apps). = Exposing actual network layer-3 topology and configuration isn’t a = new thing. This is what several other organizations are defining and = it’s being done even within the ietf already. = draft-clemm-i2rs-yang-network-topo, for example, already defines a basic = topology using YANG (which is closely related to routing however). =   

 

Let’s take for example a datacenter abstraction, = one of supa’s use case. The goal here is to offer apps an = abstracted view of datacenters and allow them to modify parameters = relating to the whole datacenter, not single devices. Yes, the result = will be actual configuration on devices, but it should’t be = exposed to the app (unless it wants it).

 

As an app d=E9velopper using supa, I’d like to = be able to send a request to the controller like this: “reserve me = bandwidth x between datacenters A and B from this time to that = time.” This does’t sound like network level = configuration… but maybe we’re just disagreeing on = vocabulary here. 

 

Of course it doesn’t preclude that supa offers a = network-device view of the network. It just that it’s not its main = goal, in my opinion. 

 

JF

 

 

 

------=_NextPart_000_0050_01CFCD17.0B154940-- From nobody Wed Sep 10 06:03:45 2014 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 327691A7022 for ; Wed, 10 Sep 2014 06:03:42 -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, HTML_MESSAGE=0.001, J_CHICKENPOX_55=0.6, 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 5VKP97sq8Z1Z for ; Wed, 10 Sep 2014 06:03:26 -0700 (PDT) Received: from out47-ams.mf.surf.net (out47-ams.mf.surf.net [145.0.1.47]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF5D31A7023 for ; Wed, 10 Sep 2014 06:03:17 -0700 (PDT) Received: from EXEDGE02.ad.utwente.nl (exedge02.ad.utwente.nl [130.89.5.49]) by outgoing2-ams.mf.surf.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id s8AD34MN016354; Wed, 10 Sep 2014 15:03:05 +0200 Received: from EXMBX33.ad.utwente.nl (130.89.4.148) by EXEDGE02.ad.utwente.nl (130.89.5.49) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 10 Sep 2014 15:03:09 +0200 Received: from EXMBX31.ad.utwente.nl (130.89.4.146) by EXMBX33.ad.utwente.nl (130.89.4.148) with Microsoft SMTP Server (TLS) id 15.0.913.22; Wed, 10 Sep 2014 15:02:59 +0200 Received: from EXMBX31.ad.utwente.nl ([130.89.4.146]) by EXMBX31.ad.utwente.nl ([130.89.4.146]) with mapi id 15.00.0913.011; Wed, 10 Sep 2014 15:02:59 +0200 From: To: , , , Thread-Topic: [Supa] Any example of "network service graph"? Thread-Index: Ac/Gh8AZTLQx+gy7TtGf8Y+pK8azPQATfN4AAA2aswAAJj42gAAM5TSAAEw2PQAA6+LPgAACiiMAAAyQcGE= Date: Wed, 10 Sep 2014 13:02:59 +0000 Message-ID: References: <002c01cfc688$b6d618d0$24824a70$@cernet.edu.cn> <8ECF7AE3-6C16-4E8B-B842-22ABB36B2990@viagenie.ca> <000201cfc71c$e261ddb0$a7259910$@cernet.edu.cn> <4B29BA0800EE424E850D442A1A3D18034073BC1C@SZXEMA510-MBX.china.huawei.com> <9EAC5D55-8460-40FF-82CD-ECB90BF6E3D4@viagenie.ca> , <004f01cfccd3$fcf0d0c0$f6d27240$@cernet.edu.cn> In-Reply-To: <004f01cfccd3$fcf0d0c0$f6d27240$@cernet.edu.cn> Accept-Language: nl-NL, nl-BE, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [213.61.52.82] Content-Type: multipart/alternative; boundary="_000_de9cef98eaae48809d5c51224dc14b76EXMBX31adutwentenl_" MIME-Version: 1.0 X-Bayes-Prob: 0.0001 (Score 0, tokens from: utwente-out:default, base:default, @@RPTN) X-CanIt-Geo: ip=130.89.5.49; country=NL; region=Provincie Overijssel; city=Enschede; latitude=52.2195; longitude=6.8912; http://maps.google.com/maps?q=52.2195,6.8912&z=6 X-CanItPRO-Stream: utwente-out:default (inherits from utwente:default, base:default) X-Canit-Stats-ID: 0vMNp34dh - aba7c92d16f9 - 20140910 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: http://mailarchive.ietf.org/arch/msg/supa/4bXnDr6U3euY_Hsww59CnR6mrL4 Subject: Re: [Supa] Any example of "network service graph"? X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2014 13:03:42 -0000 --_000_de9cef98eaae48809d5c51224dc14b76EXMBX31adutwentenl_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Guang Yao, Please note that I agree with most of what you mentioned, except the fact t= hat IMHO the three different graphs are not vieweing the same model, but th= ey are viewing different abstraction models of the the same network. The network service graph contains the most details of all three. Moreover,= please note that the network service graph includes the information/model= provided by the =93network level configuration graph=94. Furthermore, what you defined as =93network level configuration graph=94 i= s IMHO, similar t the network topology grph that the SFC WG and the i2RS WG= s might work on in the (near) future. IMHO SUPA can focus on the network service graph. Please also note that the= work on the modeling activities associated with the =93network level confi= guration graph=94 can be excluded from SUPA if the SFC WG and or I2RS WGs w= ill decide to work (in the near future) on modeling the =93network level co= nfiguration graph=94. Best regards, Georgios ________________________________ Van: Supa namens Guang Yao Verzonden: woensdag 10 september 2014 10:48 Aan: 'Liushucheng (Will)'; 'JF Tremblay'; supa@ietf.org Onderwerp: Re: [Supa] Any example of "network service graph"? IMHO: 1. The apps only require a =93network graph=94, which is an abstracti= on view of the network topology. 2. The controller should merge the services and place the functions o= n the real topology(service placement will be a problem). Then an intermedi= ate graph with topology and service is formed. This one can be named =93net= work service graph=94. 3. Finally, the service-level graph is translated into a configuratio= n-level(or policy-level) graph(maybe no graph is required here), and the co= nfigurations are applied on the devices. So, I think the graphs are actually different views on the same thing. Mayb= e we should define it to be a model, and =93network graph=94, =93network se= rvice graph=94, =93network level configuration graph=94 are just different = views of this model. From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Liushucheng (Will) Sent: Wednesday, September 10, 2014 3:36 PM To: JF Tremblay; supa@ietf.org Subject: Re: [Supa] Any example of "network service graph"? So, have we reached an agreement which term should be used? Regards, Will (Shucheng LIU) From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of JF Tremblay Sent: Friday, September 05, 2014 11:02 PM To: supa@ietf.org Subject: Re: [Supa] Any example of "network service graph"? On Sep 3, 2014, at 10:39 PM, Felix > wrote: Hi JF, >From my point, the information of configuration can=92t be found from the f= irst view of =93network graph=94. The main Goal of SUPA is to provide vendor-neutral network level configurat= ion model to management applications. [...] Ok, I see this is where we disagree. =93network level=94 in the sentence ab= ove really limits the graphs to layer-3 modelling, in my opinion. Adding th= e word =93configuration=94 makes it even closer to the actual configuration= of the device and further from an actual useful abstraction. Do yo suggest that supa should be limited to network device configuration? = The value of centrally controlled networks is in the quality of abstraction= s it can provide to higher levels (apps). Exposing actual network layer-3 t= opology and configuration isn=92t a new thing. This is what several other o= rganizations are defining and it=92s being done even within the ietf alread= y. draft-clemm-i2rs-yang-network-topo, for example, already defines a basic= topology using YANG (which is closely related to routing however). Let=92s take for example a datacenter abstraction, one of supa=92s use case= . The goal here is to offer apps an abstracted view of datacenters and allo= w them to modify parameters relating to the whole datacenter, not single de= vices. Yes, the result will be actual configuration on devices, but it shou= ld=92t be exposed to the app (unless it wants it). As an app d=E9velopper using supa, I=92d like to be able to send a request = to the controller like this: =93reserve me bandwidth x between datacenters = A and B from this time to that time.=94 This does=92t sound like network le= vel configuration=85 but maybe we=92re just disagreeing on vocabulary here. Of course it doesn=92t preclude that supa offers a network-device view of t= he network. It just that it=92s not its main goal, in my opinion. JF --_000_de9cef98eaae48809d5c51224dc14b76EXMBX31adutwentenl_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hi Guang Yao,

 

Please note that I agree with most of what you mentioned, except the fac= t that IMHO the three different graphs are not vieweing the same model, but= they are viewing different abstraction models of the the same network.

 

The network service graph contains = the most details of all three. Moreover, please note that the network servi= ce  graph includes the information/model provided by the =93network level configuration graph=94.

 

Furthermore, what you defined as =93network level configuration graph=94  is IMHO, similar t the network topology grph t= hat the SFC WG and the i2RS WGs might work on in the (near) future.

 

 

IMHO SUPA can focus on the network = service graph. Please also note that the work on the modeling activities as= sociated with the =93network level configuration graph=94 can be excluded from SUPA if the SFC WG and= or I2RS WGs will decide to work (in the near future) on modeling the =93network level configuration graph=94.

 

Best regards,

Georgios

 

 

 

 

Van: Supa <supa-bounce= s@ietf.org> namens Guang Yao <yaoguang@cernet.edu.cn>
Verzonden: woensdag 10 september 2014 10:48
Aan: 'Liushucheng (Will)'; 'JF Tremblay'; supa@ietf.org
Onderwerp: Re: [Supa] Any example of "network service graph&quo= t;?
 

IMHO:=

 

1. &nb= sp;     The apps only = require a =93network graph=94, which is an abstraction view of the network = topology.

2. &nb= sp;     The controller= should merge the services and place the functions on the real topology(ser= vice placement will be a problem). Then an intermediate graph with topology and service is formed. This one can be named =93networ= k service graph=94.

3. &nb= sp;     Finally, the s= ervice-level graph is translated into a configuration-level(or policy-level= ) graph(maybe no graph is required here), and the configurations are applied on the devices.

 

So, I think = the graphs are actually different views on the same thing. Maybe we should = define it to be a model, and =93network graph=94, =93network service graph=94, =93network leve= l configuration graph=94 are= just different views of this model.

 

From: Su= pa [mailto:supa-bounces@ietf.org] On Behalf Of Liushucheng (Will)
Sent: Wednesday, September 10, 2014 3:36 PM
To: JF Tremblay; supa@ietf.org
Subject: Re: [Supa] Any example of "network service graph"= ?

 

So, have we = reached an agreement which term should be used?

 

Regards,

Will (Shuche= ng LIU)

 

From: Supa= [mailto:supa= -bounces@ietf.org] On Behalf Of JF Tremblay
Sent: Friday, September 05, 2014 11:02 PM
To: supa@ietf.= org
Subject: Re: [Supa] Any example of "network service graph"= ?

 

 

On Sep 3, 2014, at 10:39 PM, Felix <felix.lu@huawei.com> wrote:

 

Hi JF,

From my po= int, the information of configuration can=92t be found from the first view = of =93network graph=94.

The main G= oal of SUPA is to provide vendor-neutral network level configuration model = to management applications. [...]

 

Ok, I see this is where we disagree. =93network leve= l=94 in the sentence above really limits the graphs to layer-3 modelling, i= n my opinion. Adding the word =93configuration=94 makes it even closer to t= he actual configuration of the device and further from an actual useful abstraction. 

 

Do yo suggest that supa should be limited to network= device configuration? The value of centrally controlled networks is in the= quality of abstractions it can provide to higher levels (apps). Exposing a= ctual network layer-3 topology and configuration isn=92t a new thing. This is what several other organization= s are defining and it=92s being done even within the ietf already. draft-cl= emm-i2rs-yang-network-topo, for example, already defines a basic topology u= sing YANG (which is closely related to routing however).   

 

Let=92s take for example a datacenter abstraction, o= ne of supa=92s use case. The goal here is to offer apps an abstracted view = of datacenters and allow them to modify parameters relating to the whole da= tacenter, not single devices. Yes, the result will be actual configuration on devices, but it should=92t be expos= ed to the app (unless it wants it).

 

As an app d=E9velopper using supa, I=92d like to be = able to send a request to the controller like this: =93reserve me bandwidth= x between datacenters A and B from this time to that time.=94 This does=92= t sound like network level configuration=85 but maybe we=92re just disagreeing on vocabulary here. 

 

Of course it doesn=92t preclude that supa offers a n= etwork-device view of the network. It just that it=92s not its main goal, i= n my opinion. 

 

JF

 

 

 

--_000_de9cef98eaae48809d5c51224dc14b76EXMBX31adutwentenl_-- From nobody Thu Sep 11 12:19:16 2014 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BDDF1A002C for ; Thu, 11 Sep 2014 12:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.952 X-Spam-Level: X-Spam-Status: No, score=-2.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_55=0.6, RP_MATCHES_RCVD=-1.652, 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 ZdQog8CWLYKA for ; Thu, 11 Sep 2014 12:19:12 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 301141A0007 for ; Thu, 11 Sep 2014 12:19:12 -0700 (PDT) Received: from h200.viagenie.ca (h200.viagenie.ca [206.123.31.200]) by jazz.viagenie.ca (Postfix) with ESMTPSA id E22DC4021C for ; Thu, 11 Sep 2014 15:19:10 -0400 (EDT) From: JF Tremblay Content-Type: multipart/alternative; boundary="Apple-Mail=_DFF6F9E9-1F6B-4277-B4E5-B2F1DAF62630" Message-Id: <8BE8D7E2-ADAC-4431-B189-24BF55EDF7D3@viagenie.ca> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Date: Thu, 11 Sep 2014 15:19:10 -0400 References: <002c01cfc688$b6d618d0$24824a70$@cernet.edu.cn> <8ECF7AE3-6C16-4E8B-B842-22ABB36B2990@viagenie.ca> <000201cfc71c$e261ddb0$a7259910$@cernet.edu.cn> <4B29BA0800EE424E850D442A1A3D18034073BC1C@SZXEMA510-MBX.china.huawei.com> <9EAC5D55-8460-40FF-82CD-ECB90BF6E3D4@viagenie.ca> <004f01cfccd3$fcf0d0c0$f6d27240$@cernet.edu.cn> To: supa@ietf.org In-Reply-To: <004f01cfccd3$fcf0d0c0$f6d27240$@cernet.edu.cn> X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/supa/HvGZgSeJVXwoZBW3oJc3nd2hOnM Subject: Re: [Supa] Any example of "network service graph"? X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 19:19:14 -0000 --Apple-Mail=_DFF6F9E9-1F6B-4277-B4E5-B2F1DAF62630 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Comments inline.=20 I quoted you out-of-order Guang, but I believe this makes a better = discussion.=20 On Sep 10, 2014, at 4:48 AM, Guang Yao wrote: > So, I think the graphs are actually different views on the same thing. Exactly! We=92re discussing different levels (granularity) of = abstractions for the same physical network. These abstractions can be of = any level (0 to 7), this is why we were discussing = multi-level/multi-layer topologies/graph.=20 > Maybe we should define it to be a model, and =93network graph=94, = =93network service graph=94, =93network level configuration graph=94 are = just different views of this model. I=92m almost in agreement here. These are graphs or topologies, these = words can be inter-changed IMHO. The =93network=94 (L3), =93service=94 = (L4-7-ish) and =93configuration=94 (NMS level) are qualifiers for the = graphs. If we use these words in the charter, then we automatically = limit supa=92s work to some specific layers, which is something that = we=92d like to avoid. At least this was my understanding of the work.=20 > IMHO: > =20 > 1. The apps only require a =93network graph=94, which is an = abstraction view of the network topology. I disagree. For the reason above. =93Network=94 is often constrained to = L2-L3 in people mind. For example, if I build a service graph for sfc, = will it still be considered a network graph? It seems odd. But maybe = it=92s just me.=20 > 2. The controller should merge the services and place the = functions on the real topology(service placement will be a problem). Agree.=20 > Then an intermediate graph with topology and service is formed. Agree. I=92m not sure =93intermediate=94 is the right word here. I would = suggest =93finer granularity=94 (alto wording) or =93lower-level=94 or = =93more detailed=94 or =93less abstract=94 as synonyms.=20 > This one can be named =93network service graph=94. =93Network graph=94 maybe, but without the =93service=94, for the = reasons mentioned above. But this is not what the application usually = sees. The network view not exposed to the apps unless the apps really = needs to dig into it. The apps want to see higher level abstraction. = They barely see the network. Actually, quoting what Martin Casado from = VmWare recently said: =93Most apps don=92t care at all about the network = and should not even be aware of it=94. Of course, a network management = app will probably want the gory details and access a really fine grain = network graph, there I agree.=20 > 3. Finally, the service-level graph is translated into a = configuration-level(or policy-level) graph(maybe no graph is required = here), and the configurations are applied on the devices. Almost! Actually, it=92s any network graph at any granularity/level that = will be translated to configuration-level graph for application to a = physical controller.=20 JF --Apple-Mail=_DFF6F9E9-1F6B-4277-B4E5-B2F1DAF62630 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Comments inline. 
I quoted you = out-of-order Guang, but I believe this makes a better = discussion. 

On Sep 10, 2014, at 4:48 AM, Guang Yao <yaoguang@cernet.edu.cn> = wrote:

So, I think the graphs are actually different views = on the same thing. =

Exactly! We=92re= discussing different levels (granularity) of abstractions for the same = physical network. These abstractions can be of any level (0 to 7), this = is why we were discussing multi-level/multi-layer = topologies/graph. 

Maybe we should define it to be a model, and =93network= graph=94, =93network service graph=94, =93network level configuration graph=94 are just different views of this = model.

I=92m almost = in agreement here. These are graphs or topologies, these words can be = inter-changed IMHO. The =93network=94 (L3), =93service=94 (L4-7-ish) and = =93configuration=94 (NMS level) are qualifiers for the graphs. If we use = these words in the charter, then we automatically limit supa=92s work to = some specific layers, which is something that we=92d like to avoid. At = least this was my understanding of the = work. 


IMHO:
 
1.       The apps only require a =93network graph=94, which is = an abstraction view of the network = topology.

I = disagree. For the reason above. =93Network=94 is often constrained to = L2-L3 in people mind. For example, if I build a service graph for sfc, = will it still be considered a network graph? It seems odd. But maybe = it=92s just me. 

2.       The controller should merge the services and place = the functions on the real topology(service placement will be a problem). =

Agree. 
Then an intermediate = graph with topology and service is formed. =

Agree. I=92m = not sure =93intermediate=94 is the right word here. I would suggest = =93finer granularity=94 (alto wording) or =93lower-level=94 or =93more = detailed=94 or =93less abstract=94 as = synonyms. 


This one can be named = =93network service = graph=94.

=93Netw= ork graph=94 maybe, but without the =93service=94, for the reasons = mentioned above. But this is not what the application usually sees. The = network view not exposed to the apps unless the apps really needs to dig = into it. The apps want to see higher level abstraction. They barely see = the network. Actually, quoting what Martin Casado from VmWare recently = said: =93Most apps don=92t care at all about the network and should not = even be aware of it=94. Of course, a network management app will = probably want the gory details and access a really fine grain network = graph, there I agree. 


3.       Finally, the service-level graph is translated into a = configuration-level(or policy-level) graph(maybe no graph is required = here), and the configurations are applied on the = devices.

Almost! = Actually, it=92s any network graph at any granularity/level that will be = translated to configuration-level graph for application to a physical = controller. 

JF

= --Apple-Mail=_DFF6F9E9-1F6B-4277-B4E5-B2F1DAF62630-- From nobody Thu Sep 11 12:34:20 2014 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CFDB1A0054 for ; Thu, 11 Sep 2014 12:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.652, 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 k_TTWsam2_-4 for ; Thu, 11 Sep 2014 12:34:15 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8ABD31A0045 for ; Thu, 11 Sep 2014 12:34:15 -0700 (PDT) Received: from h200.viagenie.ca (h200.viagenie.ca [206.123.31.200]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 6AF734021C for ; Thu, 11 Sep 2014 15:34:14 -0400 (EDT) From: JF Tremblay Content-Type: multipart/alternative; boundary="Apple-Mail=_B5D8D8E6-76F3-46BB-AAE1-4734D655B528" Message-Id: <649DF198-7E76-47BD-A50C-0AAB7100D04C@viagenie.ca> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Date: Thu, 11 Sep 2014 15:34:14 -0400 References: <002c01cfc688$b6d618d0$24824a70$@cernet.edu.cn> <8ECF7AE3-6C16-4E8B-B842-22ABB36B2990@viagenie.ca> <000201cfc71c$e261ddb0$a7259910$@cernet.edu.cn> <4B29BA0800EE424E850D442A1A3D18034073BC1C@SZXEMA510-MBX.china.huawei.com> <9EAC5D55-8460-40FF-82CD-ECB90BF6E3D4@viagenie.ca> , <004f01cfccd3$fcf0d0c0$f6d27240$@cernet.edu.cn> To: supa@ietf.org In-Reply-To: X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/supa/HUvBaQCwHMtLUQ_gIzO9BP-kAVE Subject: Re: [Supa] Any example of "network service graph"? X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 19:34:17 -0000 --Apple-Mail=_B5D8D8E6-76F3-46BB-AAE1-4734D655B528 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Sep 10, 2014, at 9:02 AM, karagian@cs.utwente.nl wrote: > Hi Guang Yao, > Please note that I agree with most of what you mentioned, except the = fact that IMHO the three different graphs are not vieweing the same = model, but they are viewing different abstraction models of the the same = network. Exact! These are different levels/granularity of the same network.=20 > The network service graph contains the most details of all three. Hum=85 I just lost you there. This should be exactly the opposite. The = service view is of higher level, therefore larger granularity. It = shouldn=92t be detailed at all. Look at the service chain definition in = draft-penno-sfc-yang, it=92s very simple and high-level, which is = exactly what it should be! The app specifies a service chain at the higher level. Just which = services should be chained in which order. Then the controller take this = abstract view and translates it into a less abstract topology view with = specific service elements, interfaces and encapsulation to make it a = service function path. Then it can be translated to configuration-level = information and pushed to physical controllers, depending of the level = of abstractions they understand.=20 > Moreover, please note that the network service graph includes the = information/model provided by the =93network level configuration graph=94.= Exactly the opposite. See comment above. The service layer is higher = abstraction then the network or configuration level.=20 > Furthermore, what you defined as =93network level configuration graph=94= is IMHO, similar t the network topology grph that the SFC WG and the = i2RS WGs might work on in the (near) future. Might be. But this is goal of supa. To provide a generic way to define = these graphs/topologies in a standard way. Whatever sfc and i2rs define = will suite their needs, but it=92s always going to be a subset. I agree = that many people at the IETF (and especially the IESG) do not like = overlapping. But in this case, if we want supa to tackle abstraction, it = will overlap with other work in progress.=20 > IMHO SUPA can focus on the network service graph. Too narrow and entirely covered by SFC already.=20 > Best regards, > Georgios Georgios, I hope you=92ll see this as a positive and constructive = discussion. I believe it=92s great and a sane thing to have a thorough = discussion on the charter, even if it comes late. The follow-up = discussions later will only be strengthened by discussing it in-depth = now.=20 JF --Apple-Mail=_B5D8D8E6-76F3-46BB-AAE1-4734D655B528 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Sep 10, 2014, at 9:02 AM, karagian@cs.utwente.nl = wrote:

Hi Guang Yao,
Please note that I agree with most of what you mentioned, except = the fact that IMHO the three different graphs are not vieweing the same = model, but they are viewing different abstraction models of the the same = network.

Exact! These = are different levels/granularity of the same = network. 

The = network service graph contains the most details of all three. =

Hum=85 I just = lost you there. This should be exactly the opposite. The service view is = of higher level, therefore larger granularity. It shouldn=92t be = detailed at all. Look at the service chain definition = in draft-penno-sfc-yang, it=92s very simple and high-level, which = is exactly what it should be!

The app specifies = a service chain at the higher level. Just which services should be = chained in which order. Then the controller take this abstract view and = translates it into a less abstract topology view with specific service = elements, interfaces and encapsulation to make it a service function = path. Then it can be translated to configuration-level information and = pushed to physical controllers, depending of the level of abstractions = they understand. 


Moreover, please note that the network = service  graph includes the information/model provided by the = =93network level configuration graph=94.

Exactly the opposite. See comment above. The service layer is higher = abstraction then the network or configuration = level. 


Furthermore, what you defined as =93network level configuration graph=94  is IMHO, similar t the network topology = grph that the SFC WG and the i2RS WGs might work on in the (near) = future.

Might = be. But this is goal of supa. To provide a generic way to define these = graphs/topologies in a standard way. Whatever sfc and i2rs define will = suite their needs, but it=92s always going to be a subset. I agree that = many people at the IETF (and especially the IESG) do not like = overlapping. But in this case, if we want supa to tackle abstraction, it = will overlap with other work in = progress. 

 IMHO SUPA can focus on the = network service = graph.


Too narrow = and entirely covered by SFC already. 

 Best = regards,

Georgios

G= eorgios, I hope you=92ll see this as a positive and constructive = discussion. I believe it=92s great and a sane thing to have a thorough = discussion on the charter, even if it comes late. The follow-up = discussions later will only be strengthened by discussing it in-depth = now. 

JF

= --Apple-Mail=_B5D8D8E6-76F3-46BB-AAE1-4734D655B528-- From nobody Thu Sep 11 22:31:54 2014 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 708CC1A05D3 for ; Thu, 11 Sep 2014 22:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 jxZOsRezaE7v for ; Thu, 11 Sep 2014 22:31:40 -0700 (PDT) Received: from out41-ams.mf.surf.net (out41-ams.mf.surf.net [145.0.1.41]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B3631A0538 for ; Thu, 11 Sep 2014 22:31:38 -0700 (PDT) Received: from EXEDGE01.ad.utwente.nl (exedge01.ad.utwente.nl [130.89.5.48]) by outgoing2-ams.mf.surf.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id s8C5VZQH019302; Fri, 12 Sep 2014 07:31:35 +0200 Received: from EXMBX33.ad.utwente.nl (130.89.4.148) by EXEDGE01.ad.utwente.nl (130.89.5.48) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 12 Sep 2014 07:31:35 +0200 Received: from EXMBX31.ad.utwente.nl (130.89.4.146) by EXMBX33.ad.utwente.nl (130.89.4.148) with Microsoft SMTP Server (TLS) id 15.0.913.22; Fri, 12 Sep 2014 07:31:16 +0200 Received: from EXMBX31.ad.utwente.nl ([130.89.4.146]) by EXMBX31.ad.utwente.nl ([130.89.4.146]) with mapi id 15.00.0913.011; Fri, 12 Sep 2014 07:31:16 +0200 From: To: , Thread-Topic: [Supa] Any example of "network service graph"? Thread-Index: Ac/Gh8AZTLQx+gy7TtGf8Y+pK8azPQATfN4AAA2aswAAJj42gAAM5TSAAEw2PQAA6+LPgAACiiMAAAyQcGEAPEgRAAAYrc4Z Date: Fri, 12 Sep 2014 05:31:15 +0000 Message-ID: References: <002c01cfc688$b6d618d0$24824a70$@cernet.edu.cn> <8ECF7AE3-6C16-4E8B-B842-22ABB36B2990@viagenie.ca> <000201cfc71c$e261ddb0$a7259910$@cernet.edu.cn> <4B29BA0800EE424E850D442A1A3D18034073BC1C@SZXEMA510-MBX.china.huawei.com> <9EAC5D55-8460-40FF-82CD-ECB90BF6E3D4@viagenie.ca> , <004f01cfccd3$fcf0d0c0$f6d27240$@cernet.edu.cn> , <649DF198-7E76-47BD-A50C-0AAB7100D04C@viagenie.ca> In-Reply-To: <649DF198-7E76-47BD-A50C-0AAB7100D04C@viagenie.ca> Accept-Language: nl-NL, nl-BE, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [46.189.28.237] Content-Type: multipart/alternative; boundary="_000_d299f0998be0426eacef3deafbbd76ceEXMBX31adutwentenl_" MIME-Version: 1.0 X-Bayes-Prob: 0.0001 (Score 0, tokens from: utwente-out:default, base:default, @@RPTN) X-CanIt-Geo: ip=130.89.5.48; country=NL; region=Provincie Overijssel; city=Enschede; latitude=52.2195; longitude=6.8912; http://maps.google.com/maps?q=52.2195,6.8912&z=6 X-CanItPRO-Stream: utwente-out:default (inherits from utwente:default, base:default) X-Canit-Stats-ID: 0vMO5vzd5 - 50f9d2af60f1 - 20140912 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: http://mailarchive.ietf.org/arch/msg/supa/clq3QXJ7XR3xOzBDJIM-9oNAgtw Subject: Re: [Supa] Any example of "network service graph"? X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 05:31:52 -0000 --_000_d299f0998be0426eacef3deafbbd76ceEXMBX31adutwentenl_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi JF, See in line! ________________________________ Van: Supa namens JF Tremblay Verzonden: donderdag 11 september 2014 21:34 Aan: supa@ietf.org Onderwerp: Re: [Supa] Any example of "network service graph"? On Sep 10, 2014, at 9:02 AM, karagian@cs.utwente.nl wrote: Hi Guang Yao, Please note that I agree with most of what you mentioned, except the fact t= hat IMHO the three different graphs are not vieweing the same model, but th= ey are viewing different abstraction models of the the same network. Exact! These are different levels/granularity of the same network. The network service graph contains the most details of all three. Hum... I just lost you there. This should be exactly the opposite. The serv= ice view is of higher level, therefore larger granularity. It shouldn't be = detailed at all. Look at the service chain definition in draft-penno-sfc-ya= ng, it's very simple and high-level, which is exactly what it should be! The app specifies a service chain at the higher level. Just which services = should be chained in which order. Then the controller take this abstract vi= ew and translates it into a less abstract topology view with specific servi= ce elements, interfaces and encapsulation to make it a service function pat= h. Then it can be translated to configuration-level information and pushed = to physical controllers, depending of the level of abstractions they unders= tand. Georgios: The netwrok service graph, as it was defined in APONF contained b= oth service and neywork models/views and provide also the way of how these = views are interconnected with each other. In your definition I miss how the inetconnction between these two models (s= ervice and network) will be realized. Moreover, please note that the network service graph includes the informat= ion/model provided by the "network level configuration graph". Exactly the opposite. See comment above. The service layer is higher abstra= ction then the network or configuration level. Georgios: Well the network service graph includes all the service and netwr= ok topology descriptions and in addition to that it provides the glue betwe= en them. So it is describing how service functions are mapped/located into = network entities. Furthermore, what you defined as "network level configuration graph" is IM= HO, similar t the network topology grph that the SFC WG and the i2RS WGs mi= ght work on in the (near) future. Might be. But this is goal of supa. To provide a generic way to define thes= e graphs/topologies in a standard way. Whatever sfc and i2rs define will su= ite their needs, but it's always going to be a subset. I agree that many pe= ople at the IETF (and especially the IESG) do not like overlapping. But in = this case, if we want supa to tackle abstraction, it will overlap with othe= r work in progress. IMHO SUPA can focus on the network service graph. Too narrow and entirely covered by SFC already. Georgios: As I mentioned above, only the network topology model might be co= vered by SFC or i2RS and maybe also ALTO. The rest can be covered by SUPA. Best regards, Georgios Best regards, Georgios Georgios, I hope you'll see this as a positive and constructive discussion.= I believe it's great and a sane thing to have a thorough discussion on the= charter, even if it comes late. The follow-up discussions later will only = be strengthened by discussing it in-depth now. JF --_000_d299f0998be0426eacef3deafbbd76ceEXMBX31adutwentenl_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi JF,

 

See in line!

Van: Supa <supa-bounce= s@ietf.org> namens JF Tremblay <jean-francois.tremblay@viagenie.ca>= ;
Verzonden: donderdag 11 september 2014 21:34
Aan: supa@ietf.org
Onderwerp: Re: [Supa] Any example of "network service graph&quo= t;?
 

On Sep 10, 2014, at 9:02 AM, karagian@cs.utwente.nl wrote:

Hi Guang Yao,
Please note that I agre= e with most of what you mentioned, except the fact that IMHO the three diff= erent graphs are not vieweing the same model, but they are viewing differen= t abstraction models of the the same network.

Exact! These are different levels/granularity of the same network.&nbs= p;

The network servi= ce graph contains the most details of all three.

Hum… I just lost you there. This should be exactly the opposite.= The service view is of higher level, therefore larger granularity. It shou= ldn’t be detailed at all. Look at the service chain definition in&nbs= p;draft-penno-sfc-yang, it’s very simple and high-level, which is exactly what it should be!

The app specifies a service chain at the higher level. Just which serv= ices should be chained in which order. Then the controller take this abstra= ct view and translates it into a less abstract topology view with specific = service elements, interfaces and encapsulation to make it a service function path. Then it can be translate= d to configuration-level information and pushed to physical controllers, de= pending of the level of abstractions they understand. 

Georgios: The netwrok service graph, as it was defined in APONF contained b= oth service and neywork models/views and provide also the way of how t= hese views are interconnected with each other.
In your definition I miss how the inetconnction between these two mode= ls (service and network) will be realized.

Moreover, please = note that the network service  graph includes the information/model pr= ovided by the “network level configuration graph”.

Exactly the opposite. See comment above. The service layer is higher a= bstraction then the network or configuration level. 
 
Georgios: Well the network service graph includes all the service= and netwrok topology descriptions and in addition to that it provides= the glue between them. So it is describing how service functions are mappe= d/located into network entities.
 
 
 
 


Furthermore, what= you defined as “network level configuration graph”  is IMHO, similar t the network topology grph that the SFC WG and the = i2RS WGs might work on in the (near) future.

Might be. But this is goal of supa. To provide a generic way to define= these graphs/topologies in a standard way. Whatever sfc and i2rs define wi= ll suite their needs, but it’s always going to be a subset. I agree t= hat many people at the IETF (and especially the IESG) do not like overlapping. But in this case, if we want supa to ta= ckle abstraction, it will overlap with other work in progress. 

 IMHO SUPA can focus on the network service graph.


Too narrow and entirely covered by SFC already. 
 
Georgios: As I mentioned above, only the network topology model might = be covered by SFC  or i2RS and maybe also ALTO. The rest can be covere= d by SUPA.
 
Best regards,
Georgios

 Best regards,

Georgios

Georgios, I hope you’ll see this as a positive and constructive = discussion. I believe it’s great and a sane thing to have a thorough = discussion on the charter, even if it comes late. The follow-up discussions= later will only be strengthened by discussing it in-depth now. 

JF

--_000_d299f0998be0426eacef3deafbbd76ceEXMBX31adutwentenl_-- From nobody Fri Sep 12 09:42:00 2014 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F9B71A6FA1 for ; Fri, 12 Sep 2014 09:41:58 -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, FREEMAIL_FROM=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 tdXFUQpPT3G0 for ; Fri, 12 Sep 2014 09:41:56 -0700 (PDT) Received: from mail-oa0-x22e.google.com (mail-oa0-x22e.google.com [IPv6:2607:f8b0:4003:c02::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8821C1A0672 for ; Fri, 12 Sep 2014 09:41:56 -0700 (PDT) Received: by mail-oa0-f46.google.com with SMTP id eb12so779011oac.33 for ; Fri, 12 Sep 2014 09:41:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding; bh=cYHzl2GBfTnaMknG1YrhbkUioQUbZ3J8ik4pFcH3KrY=; b=lqc3ooUneeceJfkiAm6aIcYACQiGNb2pVWkeFKVfcCiBl8YSDMqUbYzvjIehNBOmcn nRkADyOusrt4Z5Gg/pooSSXDihYk/IXjwJO2qzjQwzUsbZovSPci2ctNIvrAQfkVVViH L2E+gMBUsxIYrRC4bOXu275T5tLkpLoggEL7gJCEqaHxGxVtOZPzXdPXj1q3AB3cycgf RadA+ws/vkQ5JBOGwchiukSYNG5vps7SclTOit+u35yOBh+jHDqAA4eYFQLOjOY7JqTU z0PUrjMlakiIN55rMXOvYmEo2Q+iOTuuM2YByUu512x1Hhl3GxUDcfTRDneg6vXyEnYz 1xfg== X-Received: by 10.60.179.163 with SMTP id dh3mr9813135oec.42.1410540115966; Fri, 12 Sep 2014 09:41:55 -0700 (PDT) Received: from ?IPv6:2605:6000:9005:3f00:7465:17a5:3f72:de09? ([2605:6000:9005:3f00:7465:17a5:3f72:de09]) by mx.google.com with ESMTPSA id w6sm2857194obz.20.2014.09.12.09.41.53 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Sep 2014 09:41:54 -0700 (PDT) Message-ID: <54132250.5070701@gmail.com> Date: Fri, 12 Sep 2014 11:41:52 -0500 From: Spencer Dawkins User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: supa@ietf.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/supa/D6JZtvQeXWkeJETnHRGADyoxBcg Cc: Benoit Claise Subject: [Supa] Area hand-off, and some friendly advice ... X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 16:41:58 -0000 Dear SUPA friends, Several IESG members had a chat earlier this week, and decided that SUPA really belongs in OPS. I've requested that the area affiliation in http://www.ietf.org/list/nonwg.html be updated to reflect that. Benoit will be your AD for additional charter discussion. If I might offer some friendly advice, several ADs are fairly confused about the relationship between openv6, APONF, and SUPA. If you could put together a short paragraph that's something like "we started openv6 to do X, then we realized we needed to do Y so we proposed APONF, and after discussions in Toronto, we chose a different direction with SUPA because of Z", that would be very helpful. I also have a request from Benoit (and Adrian, and Joel) to make the description at https://www.ietf.org/mailman/listinfo/supa more understandable for people who haven't been following the work - if you intend to charter a working group, you'll want people to understand what you're proposing. You should probably keep in mind that people who talk over a long period of time are likely to develop a shared understanding that people who weren't involved don't understand clearly. If there's a smart newcomer who could look over problem statements, proposed charters and see what's not clear to newcomers, that would likely be helpful as well. Thanks, and best wishes. I'll see you in the hallways of Honolulu, where all ADs lurk sooner or later ... Spencer From nobody Mon Sep 15 13:57:47 2014 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1F391A8752 for ; Mon, 15 Sep 2014 13:57:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.253 X-Spam-Level: X-Spam-Status: No, score=-5.253 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, 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 m6PySVqvbOgb for ; Mon, 15 Sep 2014 13:57: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 C31011A8751 for ; Mon, 15 Sep 2014 13:57:42 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BMQ28619; Mon, 15 Sep 2014 20:57:41 +0000 (GMT) Received: from SZXEML419-HUB.china.huawei.com (10.82.67.158) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 15 Sep 2014 21:57:39 +0100 Received: from szxeml557-mbs.china.huawei.com ([169.254.6.57]) by szxeml419-hub.china.huawei.com ([10.82.67.158]) with mapi id 14.03.0158.001; Tue, 16 Sep 2014 04:57:33 +0800 From: Tina TSOU To: Spencer Dawkins , "supa@ietf.org" Thread-Topic: [Supa] Area hand-off, and some friendly advice ... Thread-Index: AQHPzqh9GTuRDclUaESQdripqpP+jZwCp2Dw Date: Mon, 15 Sep 2014 20:57:32 +0000 Message-ID: References: <54132250.5070701@gmail.com> In-Reply-To: <54132250.5070701@gmail.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.244.69] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/supa/mMPhug7vxa8s-uOmrgHvwXif2T4 Cc: Benoit Claise Subject: Re: [Supa] Area hand-off, and some friendly advice ... X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 20:57:46 -0000 Dear Spencer, Benoit et al, Thank you for your friendly advice.=20 Below are SUPA draft charter, and OPENv6, APONF and SUPA group historic per= spective, based on the list discussion. Look forward to more opinions and d= iscussions on the list. * SUPA draft charter: -------------- SUPA (Shared Unified Policy Automation) Target Area: OPS Description of Working Group: Network operators are faced with networks of increasing size and complexity= while trying to improve their quality and availability, as more and more s= ervices depend on them. Programmatic ways to configure networks, often cal= led software-defined, are considered by many network operators in order to = shift the balance in their favor. =20 Automation of configuration may provide significant improvements in configu= ration agility, error detection and uptime for operators. However the real = value behind central configuration schemes lies within the possible simplif= ication through abstraction provided by such systems to applications runnin= g above them (on the so-called northbound side). Well-designed abstractions= are able to provide a wide range of granularity for various applications n= eeds, from the lower-level physical network to high-level application servi= ces. =20 Although several organizations outside of the IETF have defined various sch= emes for the configuration of network devices and specific network controll= ers, none of them offer a vendor-neutral standardized way for applications = to transmit their needs to controllers. The SUPA (Shared Unified Policy Aut= omation) working group will work on the definition of such as standardized = interface for applications to communicate with network controllers of all t= ypes. =20 The interface definitions will be based on the concept of network graph, an= entity describing an arbitrary topology of nodes and links at any level of= abstraction and granularity. Such a graph may describe, for example, a phy= sical topology, a L2 network, a service topology or the relationships betwe= en datacenters. Although some IETF working groups have started work relatin= g to the description of various topologies such as I2RS (L3 and routing top= ologies), ALTO (cost maps), SFC (service chain), none of these groups aim a= t offering a truly generic multi-layer and abstract topology for standard n= orthbound configuration. =20 Work items for SUPA include: =20 1) Choice of a modeling language used by the group to describe the network = graph. Existing modeling languages such as YANG will be considered for this= purpose unless no suitable one is found. =20 2) Choice of a transport protocol for the modeling language mentioned above= . The group will re-use a protocol already defined as a transport for the m= odeling language, such as NETCONF or RESTCONF in the case of YANG. =20 3) The definition of a standardized model for a network topology graph. Thi= s model may be used to describe topologies at any functional layer, from ph= ysical networks to network services and higher abstractions. The nodes of t= his graph may describe physical nodes as well as virtualized ones. =20 4) The definition and standardization of a number of basic abstracted model= s using network graphs. These might include, but are not limited to, L3VPNs= , L2VPNs, datacenters, traffic engineering, implementation of IPv6 transiti= on mechanism and their enforcement to users. =20 =20 5) Guidelines for the mapping of abstract model information to physical or = virtualized network components. =20 Proposed milestones for the working group: =20 - Produce a problem statement document for SUPA. - Produce a gap analysis for SUPA in order to verify overlap with the wor= k of other IETF groups. - Produce a requirement document describing the desired properties of an = abstract multi-layer network graph definition. - Produce a gap analysis of existing modeling language, their characteris= tics, possible transport protocols and how they compare to the SUPA require= ments. - Produce a document specifying the model for a generic multi-layer netwo= rk graph. - Produce several documents describing different levels of abstract views= using the network graph model defined above, including physical view, logi= cal view, layer-3 view, configuration view, performance probing view, servi= ce view and other such as L3VPN, L2VPN, datacenters and traffic engineering= . =20 ------------ * OPENv6, APONF and SUPA group historic perspective ------------------------------------------------------------------------- Most IETF working groups are formed in the interest of solving some actual = real-world problem from network operators, developers or manufacturers and = the initial work from the OPENv6 group was no exception. Some operators saw= a common interest in defining a common approach for the deployment of IPv6= transition tools. Although the preferred way of deploying IPv6 remains by = dual-stacking, several operators have deployed additional transition tools = such as 6RD (RFC5969), DS-Lite (RFC6333), NAT64 (RFC6146) and others with t= he intent of speeding up or to provide more flexibility in their IPv6 servi= ces. Each of these protocols presents its own set of deployment challenges = and failure modes for users, either because of unsupported applications, pa= rtial implementations in some off-the-shelf devices such as home routers or= some limitations of the protocols themselves to name a few cases.=20 The fact these protocols are often deployed with techniques targeting the e= xtension of IPv4 service, such as Carrier Grade NAT, making their deploymen= t even more complex, especially when targeting minimal end-user impact. Alt= hough some approaches in solving this were proposed, for example in RFC6264= , the market hasn't seen the advent of configurable CGN devices or adaptive= home gateways. The only solution for operators is to have an agile way to = provision rapidly and easily any type of IPv6 or IPv4 service depending of = the specific needs of each end-user and their device. These changes must be= performed with respect to the operator existing policies regarding the net= work, billing, security and other constraints.=20 While exploring these issues, it became clear the best way to address them = would be to use a central controller that would be able to coordinate the d= eployment of different protocols amongst several devices in a consistent fa= shion. Such a controller would receive high-level policy information from a= management application, transform it in network-level configuration and ap= ply it to physical or virtual devices. At that point, several other use cas= es outside of the deployment of IPv6 started to emerge, for example for the= control of data center traffic steering, for the creation of tunnels and t= he provisioning of L3VPN. The group decided to rename its activities under = the acronym APONF, for Application Policy on Network Functions, which seeme= d a more fitting name. The definition of policies by a management applicati= on toward a network controller would be at the center of the work for the g= roup. Several group documents were created around this concept.=20 When presented at a bar bof during IETF-90 in Toronto, most of the feedback= was positive, but the scope of the work was often judged too large in scop= e. It wasn't clear either how much overlap there was with other IETF groups= . A better analysis of this aspect in the following weeks revealed some lev= el of overlap with other groups, but also where deficiencies exist. The two= aspects where IETF work seems to be lacking are in the definition of high-= level policy language for applications and also in a standard model to desc= ribe network topologies at different levels of granularity, or abstraction.= Some existing working groups have published work on the latter. For exampl= e, the ALTO working group defined a way to describe network functions at di= fferent level of granularity using cost maps, but this approach does not se= em practical for the description of complex network topologies to and from = a central controller. A topology draft exists in the I2RS group, but it is = very centered around routing protocols and L2-L3 links.=20 The group has recently renamed its activities under the SUPA (Shared Unifie= d Policy Automation) acronym with the intention of defining a standard way = to push policies to a central controller. It appears, however, that in orde= r to define such policies, the definition of a standard multi-layer model f= or the description of networks of all types would be desirable. Therefore t= he initial work for the SUPA group would be to select an existing modeling = language and define a clear multi-layer model able to describe network or s= ervice information at any level of granularity or complexity. -------------- Thank you, Tina -----Original Message----- From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Spencer Dawkins Sent: Friday, September 12, 2014 9:42 AM To: supa@ietf.org Cc: Benoit Claise Subject: [Supa] Area hand-off, and some friendly advice ... Dear SUPA friends, Several IESG members had a chat earlier this week, and decided that SUPA re= ally belongs in OPS. I've requested that the area affiliation in http://www= .ietf.org/list/nonwg.html be updated to reflect that. Benoit will be your AD for additional charter discussion. If I might offer some friendly advice, several ADs are fairly confused abou= t the relationship between openv6, APONF, and SUPA. If you could put togeth= er a short paragraph that's something like "we started openv6 to do X, then= we realized we needed to do Y so we proposed APONF, and after discussions = in Toronto, we chose a different direction with SUPA because of Z", that wo= uld be very helpful. I also have a request from Benoit (and Adrian, and Joel) to make the descri= ption at https://www.ietf.org/mailman/listinfo/supa more understandable for= people who haven't been following the work - if you intend to charter a wo= rking group, you'll want people to understand what you're proposing. You should probably keep in mind that people who talk over a long period of= time are likely to develop a shared understanding that people who weren't = involved don't understand clearly. If there's a smart newcomer who could lo= ok over problem statements, proposed charters and see what's not clear to n= ewcomers, that would likely be helpful as well. Thanks, and best wishes. I'll see you in the hallways of Honolulu, where al= l ADs lurk sooner or later ... Spencer _______________________________________________ Supa mailing list Supa@ietf.org https://www.ietf.org/mailman/listinfo/supa From nobody Wed Sep 17 20:19:58 2014 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D97B51A00F0 for ; Wed, 17 Sep 2014 20:19:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.128 X-Spam-Level: X-Spam-Status: No, score=0.128 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.652] 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 5eULoXz9eiCg for ; Wed, 17 Sep 2014 20:19:53 -0700 (PDT) Received: from sendg.mailex.chinaunicom.cn (sendg.mailex.chinaunicom.cn [210.53.66.230]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D90CB1A00ED for ; Wed, 17 Sep 2014 20:19:51 -0700 (PDT) Received: from SBG8380-4.chinaunicom.cn (10.0.15.35) by M10-HQ-MLOUT01.cnc.intra (10.0.15.20) with Microsoft SMTP Server id 8.2.254.0; Thu, 18 Sep 2014 11:19:42 +0800 X-AuditID: 0a000f23-b7f5d6d000000f9d-e2-541a4f541f95 Received: from M10-CEN-MLHUB02.cnc.intra ( [10.0.192.42]) by SBG8380-4.chinaunicom.cn (Symantec Messaging Gateway) with SMTP id DF.FC.03997.45F4A145; Thu, 18 Sep 2014 11:19:49 +0800 (HKT) Received: from m10-hq-mlch01.hq.cnc.intra (10.0.15.26) by M10-CEN-MLHUB02.cnc.intra (10.0.192.42) with Microsoft SMTP Server (TLS) id 8.2.213.0; Thu, 18 Sep 2014 11:19:48 +0800 Received: from YingCheng-PC (114.255.193.232) by m10-hq-mlch01.hq.cnc.intra (10.0.15.26) with Microsoft SMTP Server id 8.2.213.0; Thu, 18 Sep 2014 11:19:48 +0800 Date: Thu, 18 Sep 2014 11:19:46 +0800 From: =?utf-8?B?WWluZyBDaGVuZw==?= To: =?utf-8?B?c3VwYQ==?= Message-ID: <201409181119448043251@chinaunicom.cn> X-mailer: Foxmail 6, 15, 201, 26 [cn] MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=====003_Dragon385747871675_=====" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNKsWRmVeSWpSXmKPExsXCxXBASzfUXyrE4MZ3Dov5H1pZLVqOTmG2 aNhsbjF7yypmBxaPliNvWT2WLPnJ5PF34nVGj3UfzANYoupsEvPy8ksSS1IVUlKLk22VgjPT 8xJLSotSFfxLS5LyS/NSlBQyU2yVjJUUCnISk1NzU/NKbJUSCwpSgTJ2XAoYwAaoLDNPITUv OT8lMy/dVik0xE3XQsnu6bKmZ/PmPGta8XLKzBfr1z/rW/psyraEKywZz3f8Zy04FFbx9PAt pgbGCSFdjJwcEgImEkd3TGCDsMUkLtxbD2RzcQgJ7GWUuPv7JyuEs4VRYsLjW0wQzlJGiVPL /rKAtLAIqEos29cB1s4mYC/RtH0XK4gtIqAl0fR3NTtIA7PAFGaJd0f+gxUJC5RKLL64iBnE 5hUwkuh71wu1W1XialsfE8TQCIlLzxayQNQISpyc+QTMZhYIlmhp+gI0lAPoCnWJ5bfsJjAK zEJSNQtJ1SygKmYBTYn1u/QhwooSU7ofskPYGhKtc+ayI4svYGRbxSgR7ORuYWxhoGuil5yR mZdYmpeZnJ+rl5y3iREc9fzKOxgfnLA8xCjAwajEw6twRjJEiDWxrLgy9xCjBAezkgjvfg+p ECHelMTKqtSi/Pii0pzU4kOMyUAvTWSWEk3OByakvJJ4Q2MLC3NjY1MTYyNjM9KElcR5OT6L hwgJpANTUnZqakFqEcwWJg5OqQbG1WyRns4inJIhWlpJ3/vmfl4QNZHrQLlzk4Xq+lseRc+S ylca1CY0d3XZ/4iTzo+umf9rvZrqFIMZLexvncRFXDmWOlu/8/zUmbdQejXjtz+qy/6Z2lbP K++ezc6e/LuHc6foXk9J55yLnxyXnLTZvuOueJyUTLpRs8zHbTv+9GevXJxm90aJpTgj0VCL uag4EQCKHHvDPgMAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/supa/5BdMKKYPPJrI0gNPPq9yJQx6HM8 Cc: =?utf-8?B?SkZUcmVtYmxheQ==?= , =?utf-8?B?Q2F0aHkgWmhvdQ==?= , =?utf-8?B?R2Vvcmdpb3MgS2FyYWdpYW5uaXM=?= Subject: Re: [Supa] =?utf-8?q?New_Version_Notification_for_draft-cheng-supa-dd?= =?utf-8?q?c-use-cases-00=2Etxt?= X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 03:19:57 -0000 --=====003_Dragon385747871675_===== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 IA0KRGVhciBleHBlcnRzLA0KDQpBIG5ldyB2ZXJzaW9uIG9mIEREQyB1c2UgY2FzZSBpcyBz dWJtaXR0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4gUGxlYXNlIGtpbmRseSByZXZpZXcg aXQgdmlhIHRoZSBmb2xsb3dpbmcgbGluay4NCg0KaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRl cm5ldC1kcmFmdHMvZHJhZnQtY2hlbmctc3VwYS1kZGMtdXNlLWNhc2VzLTAwLnR4dA0KQW55 IGNvbW1lbnRzL3F1ZXN0aW9ucyBhcmUgd2VsY29tZWQuDQoNClRoYW5rcyBhbmQgYmVzdCBy ZWdhcmRzLA0KWWluZw0KDQoNCg0KDQoyMDE0LTA5LTE4IA0KDQoNCg0KWWluZyBDSEVORyAg 56iL6I65DQpDaGluYSBVbmljb20gTmV0d29yayBUZWNobm9sb2d5IFJlc2VhcmNoIEluc3Rp dHV0ZSDkuK3lm73ogZTpgJrnvZHnu5zmioDmnK/noJTnqbbpmaINClRlbDogKzg2LTEwLTY4 Nzk5OTk5LTc3MDINCk1vYmlsZTogKzg2LTE4NjAxMTAyOTcxDQoNCg0KDQoNCg0K5Y+R5Lu2 5Lq677yaIGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyANCuWPkemAgeaXtumXtO+8miAyMDE0 LTA5LTE3ICAxNzoxMjoxMSANCuaUtuS7tuS6uu+8miBDYXRoeSBaaG91OyBHZW9yZ2lvcyBL YXJhZ2lhbm5pczsgWWluZyBDaGVuZyjogZTpgJrpm4blm6LogZTpgJrnvZHnu5zmioDmnK/n oJTnqbbpmaIpOyBZaW5nIENoZW5nKOiBlOmAmumbhuWbouiBlOmAmue9kee7nOaKgOacr+eg lOeptumZoik7IEpGIFRyZW1ibGF5OyBDYXRoeSBaaG91OyBKRlRyZW1ibGF5OyBHZW9yZ2lv cyBLYXJhZ2lhbm5pcyANCuaKhOmAge+8miANCuS4u+mimO+8miBOZXcgVmVyc2lvbiBOb3Rp ZmljYXRpb24gZm9yIGRyYWZ0LWNoZW5nLXN1cGEtZGRjLXVzZS1jYXNlcy0wMC50eHQgDQog DQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtY2hlbmctc3VwYS1kZGMtdXNlLWNhc2Vz LTAwLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBDYXRoeSBaaG91 IGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRvcnkuDQpOYW1lOiBkcmFmdC1jaGVu Zy1zdXBhLWRkYy11c2UtY2FzZXMNClJldmlzaW9uOiAwMA0KVGl0bGU6IFVzZSBDYXNlcyBm b3IgRGlzdHJpYnV0ZWQgRGF0YSBDZW50ZXIgQXBwbGljYXRpbm9zIGluIFNVUEENCkRvY3Vt ZW50IGRhdGU6IDIwMTQtMDktMTcNCkdyb3VwOiBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBh Z2VzOiAxMA0KVVJMOiAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQt ZHJhZnRzL2RyYWZ0LWNoZW5nLXN1cGEtZGRjLXVzZS1jYXNlcy0wMC50eHQNClN0YXR1czog ICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1jaGVuZy1z dXBhLWRkYy11c2UtY2FzZXMvDQpIdG1saXplZDogICAgICAgaHR0cDovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtY2hlbmctc3VwYS1kZGMtdXNlLWNhc2VzLTAwDQpBYnN0cmFjdDoN CiAgIFRoaXMgZG9jdW1lbnQgcHJvdmlkZXMgc2V2ZXJhbCBkaXN0cmlidXRlZCBkYXRhIGNl bnRlciAoZGRjKSB1c2UNCiAgIGNhc2VzIGFuZCBleHBsYWlucyBob3cgYW4gb3BlcmF0b3Ig Y291bGQgdXNlIFNVUEEgKFNoYXJlZCBVbmlmaWVkDQogICBQb2xpY3kgQXV0b21hdGlvbikg dG8gcHJvdmlkZSB0aGVzZSBhcHBsaWNhdGlvbnMuDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0 ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVy c2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KVGhlIElF VEYgU2VjcmV0YXJpYXQNCg0K5aaC5p6c5oKo6ZSZ6K+v5o6l5pS25LqG6K+l6YKu5Lu277yM 6K+36YCa6L+H55S15a2Q6YKu5Lu256uL5Y2z6YCa55+l5oiR5Lus44CC6K+35Zue5aSN6YKu 5Lu25YiwaHFzLXNwbWNAY2hpbmF1bmljb20uY27vvIzljbPlj6/ku6XpgIDorqLmraTpgq7k u7bjgILmiJHku6zlsIbnq4vljbPlsIbmgqjnmoTkv6Hmga/ku47miJHku6znmoTlj5HpgIHn m67lvZXkuK3liKDpmaTjgIINCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4g ZXJyb3IgcGxlYXNlIG5vdGlmeSB1cyBpbW1lZGlhdGVseSBieSBlLW1haWwuIFBsZWFzZSBy ZXBseSB0byBocXMtc3BtY0BjaGluYXVuaWNvbS5jbiBpZiB5b3Ugd2FudCB0byB1bnN1YnNj cmliZSBmcm9tIHRoaXMgbWFpbC4gV2Ugd2lsbCBpbW1lZGlhdGVseSByZW1vdmUgeW91ciBp bmZvcm1hdGlvbiBmcm9tIG91ciBzZW5kaW5nIGNhdGFsb2d1ZS4NCg== --=====003_Dragon385747871675_===== Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0 aW9uYWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBj aGFyc2V0PXV0Zi04IiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxNRVRBIG5hbWU9R0VO RVJBVE9SIGNvbnRlbnQ9Ik1TSFRNTCA4LjAwLjc2MDEuMTc1MTQiPg0KPFNUWUxFPkBmb250 LWZhY2Ugew0KCWZvbnQtZmFtaWx5OiDlrovkvZM7DQp9DQpAZm9udC1mYWNlIHsNCglmb250 LWZhbWlseTogVmVyZGFuYTsNCn0NCkBmb250LWZhY2Ugew0KCWZvbnQtZmFtaWx5OiBA5a6L 5L2TOw0KfQ0KQHBhZ2UgU2VjdGlvbjEge3NpemU6IDU5NS4zcHQgODQxLjlwdDsgbWFyZ2lu OiA3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7IGxheW91dC1ncmlkOiAxNS42cHQ7IH0N ClAuTXNvTm9ybWFsIHsNCglURVhULUpVU1RJRlk6IGludGVyLWlkZW9ncmFwaDsgVEVYVC1B TElHTjoganVzdGlmeTsgTUFSR0lOOiAwY20gMGNtIDBwdDsgRk9OVC1GQU1JTFk6ICJUaW1l cyBOZXcgUm9tYW4iOyBGT05ULVNJWkU6IDEwLjVwdA0KfQ0KTEkuTXNvTm9ybWFsIHsNCglU RVhULUpVU1RJRlk6IGludGVyLWlkZW9ncmFwaDsgVEVYVC1BTElHTjoganVzdGlmeTsgTUFS R0lOOiAwY20gMGNtIDBwdDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9tYW4iOyBGT05U LVNJWkU6IDEwLjVwdA0KfQ0KRElWLk1zb05vcm1hbCB7DQoJVEVYVC1KVVNUSUZZOiBpbnRl ci1pZGVvZ3JhcGg7IFRFWFQtQUxJR046IGp1c3RpZnk7IE1BUkdJTjogMGNtIDBjbSAwcHQ7 IEZPTlQtRkFNSUxZOiAiVGltZXMgTmV3IFJvbWFuIjsgRk9OVC1TSVpFOiAxMC41cHQNCn0N CkE6bGluayB7DQoJQ09MT1I6IGJsdWU7IFRFWFQtREVDT1JBVElPTjogdW5kZXJsaW5lDQp9 DQpTUEFOLk1zb0h5cGVybGluayB7DQoJQ09MT1I6IGJsdWU7IFRFWFQtREVDT1JBVElPTjog dW5kZXJsaW5lDQp9DQpBOnZpc2l0ZWQgew0KCUNPTE9SOiBwdXJwbGU7IFRFWFQtREVDT1JB VElPTjogdW5kZXJsaW5lDQp9DQpTUEFOLk1zb0h5cGVybGlua0ZvbGxvd2VkIHsNCglDT0xP UjogcHVycGxlOyBURVhULURFQ09SQVRJT046IHVuZGVybGluZQ0KfQ0KU1BBTi5FbWFpbFN0 eWxlMTcgew0KCUZPTlQtU1RZTEU6IG5vcm1hbDsgRk9OVC1GQU1JTFk6IFZlcmRhbmE7IENP TE9SOiB3aW5kb3d0ZXh0OyBGT05ULVdFSUdIVDogbm9ybWFsOyBURVhULURFQ09SQVRJT046 IG5vbmU7IG1zby1zdHlsZS10eXBlOiBwZXJzb25hbC1jb21wb3NlDQp9DQpESVYuU2VjdGlv bjEgew0KCXBhZ2U6IFNlY3Rpb24xDQp9DQpVTktOT1dOIHsNCglGT05ULVNJWkU6IDEwcHQN Cn0NCkJMT0NLUVVPVEUgew0KCU1BUkdJTi1UT1A6IDBweDsgTUFSR0lOLUJPVFRPTTogMHB4 OyBNQVJHSU4tTEVGVDogMmVtDQp9DQpPTCB7DQoJTUFSR0lOLVRPUDogMHB4OyBNQVJHSU4t Qk9UVE9NOiAwcHgNCn0NClVMIHsNCglNQVJHSU4tVE9QOiAwcHg7IE1BUkdJTi1CT1RUT006 IDBweA0KfQ0KPC9TVFlMRT4NCjwvSEVBRD4NCjxCT0RZIHN0eWxlPSJNQVJHSU46IDEwcHg7 IEZPTlQtRkFNSUxZOiB2ZXJkYW5hOyBGT05ULVNJWkU6IDEwcHQiPg0KPERJVj48Rk9OVCBj b2xvcj0jMDAwMDgwIHNpemU9MiBmYWNlPVZlcmRhbmE+PEZPTlQgY29sb3I9IzAwMDAwMD4m bmJzcDs8L0ZPTlQ+DQo8RElWPkRlYXIgZXhwZXJ0cyw8L0RJVj4NCjxESVY+Jm5ic3A7PC9E SVY+DQo8RElWPkEgbmV3IHZlcnNpb24gb2YgRERDIHVzZSBjYXNlIGlzJm5ic3A7c3VibWl0 dGVkIHRvIHRoZSANCklFVEYmbmJzcDtyZXBvc2l0b3J5LiBQbGVhc2Uga2luZGx5IHJldmll dyBpdCB2aWEgdGhlIGZvbGxvd2luZyBsaW5rLjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4N CjxESVYgDQphbGlnbj1jZW50ZXI+aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm dHMvZHJhZnQtY2hlbmctc3VwYS1kZGMtdXNlLWNhc2VzLTAwLnR4dDwvRElWPg0KPERJVj5B bnkgY29tbWVudHMvcXVlc3Rpb25zIGFyZSB3ZWxjb21lZC48L0RJVj4NCjxESVY+Jm5ic3A7 PC9ESVY+DQo8RElWPlRoYW5rcyBhbmQgYmVzdCByZWdhcmRzLDwvRElWPg0KPERJVj5ZaW5n PC9ESVY+PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMDgwPjwvRk9OVD4m bmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgY29sb3I9IzAwMDA4MD48L0ZPTlQ+Jm5ic3A7PC9E SVY+DQo8RElWPjxGT05UIGNvbG9yPSMwMDAwODAgc2l6ZT0yIGZhY2U9VmVyZGFuYT48L0ZP TlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGNvbG9yPSMwMDAwODAgc2l6ZT0yIGZhY2U9 VmVyZGFuYT48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGNvbG9yPSNjMGMwYzAg c2l6ZT0yIGZhY2U9VmVyZGFuYT4yMDE0LTA5LTE4IDwvRk9OVD48L0RJVj48Rk9OVCANCmNv bG9yPSMwMDAwODAgc2l6ZT0yIGZhY2U9VmVyZGFuYT4NCjxIUiBzdHlsZT0iV0lEVEg6IDEw MHB4IiBhbGlnbj1sZWZ0IGNvbG9yPSNiNWM0ZGYgU0laRT0xPg0KPC9GT05UPg0KPERJVj48 Rk9OVCBjb2xvcj0jYzBjMGMwIHNpemU9MiBmYWNlPVZlcmRhbmE+PFNQQU4+DQo8RElWPllp bmcgQ0hFTkcmbmJzcDsg56iL6I65PEJSPkNoaW5hIFVuaWNvbSBOZXR3b3JrIFRlY2hub2xv Z3kgUmVzZWFyY2ggSW5zdGl0dXRlIA0K5Lit5Zu96IGU6YCa572R57uc5oqA5pyv56CU56m2 6ZmiPEJSPlRlbDogKzg2LTEwLTY4Nzk5OTk5LTc3MDI8QlI+TW9iaWxlOiANCis4Ni0xODYw MTEwMjk3MTxCUj48QlI+PC9ESVY+PC9TUEFOPjwvRk9OVD48L0RJVj4NCjxIUiBjb2xvcj0j YjVjNGRmIFNJWkU9MT4NCg0KPERJVj48Rk9OVCBzaXplPTIgZmFjZT1WZXJkYW5hPjxTVFJP Tkc+5Y+R5Lu25Lq677yaPC9TVFJPTkc+IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyANCjwv Rk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yIGZhY2U9VmVyZGFuYT48U1RST05HPuWP kemAgeaXtumXtO+8mjwvU1RST05HPiAyMDE0LTA5LTE3Jm5ic3A7IDE3OjEyOjExIA0KPC9G T05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTIgZmFjZT1WZXJkYW5hPjxTVFJPTkc+5pS2 5Lu25Lq677yaPC9TVFJPTkc+IENhdGh5IFpob3U7IEdlb3JnaW9zIA0KS2FyYWdpYW5uaXM7 IFlpbmcgQ2hlbmco6IGU6YCa6ZuG5Zui6IGU6YCa572R57uc5oqA5pyv56CU56m26ZmiKTsg WWluZyBDaGVuZyjogZTpgJrpm4blm6LogZTpgJrnvZHnu5zmioDmnK/noJTnqbbpmaIpOyBK RiBUcmVtYmxheTsgDQpDYXRoeSBaaG91OyBKRlRyZW1ibGF5OyBHZW9yZ2lvcyBLYXJhZ2lh bm5pcyA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9MiBmYWNlPVZlcmRhbmE+PFNU Uk9ORz7mioTpgIHvvJo8L1NUUk9ORz4gPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXpl PTIgZmFjZT1WZXJkYW5hPjxTVFJPTkc+5Li76aKY77yaPC9TVFJPTkc+IE5ldyBWZXJzaW9u IE5vdGlmaWNhdGlvbiBmb3IgDQpkcmFmdC1jaGVuZy1zdXBhLWRkYy11c2UtY2FzZXMtMDAu dHh0IDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yIGZhY2U9VmVyZGFuYT48L0ZP TlQ+IDwvRElWPg0KPERJVj48Rk9OVCBzaXplPTIgZmFjZT1WZXJkYW5hPg0KPERJVj48L0RJ Vj4NCjxESVY+QSZuYnNwO25ldyZuYnNwO3ZlcnNpb24mbmJzcDtvZiZuYnNwO0ktRCwmbmJz cDtkcmFmdC1jaGVuZy1zdXBhLWRkYy11c2UtY2FzZXMtMDAudHh0PC9ESVY+DQo8RElWPmhh cyZuYnNwO2JlZW4mbmJzcDtzdWNjZXNzZnVsbHkmbmJzcDtzdWJtaXR0ZWQmbmJzcDtieSZu YnNwO0NhdGh5Jm5ic3A7WmhvdSZuYnNwO2FuZCZuYnNwO3Bvc3RlZCZuYnNwO3RvJm5ic3A7 dGhlPC9ESVY+DQo8RElWPklFVEYmbmJzcDtyZXBvc2l0b3J5LjwvRElWPg0KPERJVj48L0RJ Vj4NCjxESVY+TmFtZTogZHJhZnQtY2hlbmctc3VwYS1kZGMtdXNlLWNhc2VzPC9ESVY+DQo8 RElWPlJldmlzaW9uOiAwMDwvRElWPg0KPERJVj5UaXRsZTogDQpVc2UmbmJzcDtDYXNlcyZu YnNwO2ZvciZuYnNwO0Rpc3RyaWJ1dGVkJm5ic3A7RGF0YSZuYnNwO0NlbnRlciZuYnNwO0Fw cGxpY2F0aW5vcyZuYnNwO2luJm5ic3A7U1VQQTwvRElWPg0KPERJVj5Eb2N1bWVudCZuYnNw O2RhdGU6IDIwMTQtMDktMTc8L0RJVj4NCjxESVY+R3JvdXA6IEluZGl2aWR1YWwmbmJzcDtT dWJtaXNzaW9uPC9ESVY+DQo8RElWPlBhZ2VzOiAxMDwvRElWPg0KPERJVj5VUkw6Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQt Y2hlbmctc3VwYS1kZGMtdXNlLWNhc2VzLTAwLnR4dDwvRElWPg0KPERJVj5TdGF0dXM6Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7aHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtY2hlbmctc3VwYS1kZGMtdXNl LWNhc2VzLzwvRElWPg0KPERJVj5IdG1saXplZDombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDtodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1jaGVu Zy1zdXBhLWRkYy11c2UtY2FzZXMtMDA8L0RJVj4NCjxESVY+PC9ESVY+DQo8RElWPjwvRElW Pg0KPERJVj5BYnN0cmFjdDo8L0RJVj4NCjxESVY+Jm5ic3A7Jm5ic3A7Jm5ic3A7VGhpcyZu YnNwO2RvY3VtZW50Jm5ic3A7cHJvdmlkZXMmbmJzcDtzZXZlcmFsJm5ic3A7ZGlzdHJpYnV0 ZWQmbmJzcDtkYXRhJm5ic3A7Y2VudGVyJm5ic3A7KGRkYykmbmJzcDt1c2U8L0RJVj4NCjxE SVY+Jm5ic3A7Jm5ic3A7Jm5ic3A7Y2FzZXMmbmJzcDthbmQmbmJzcDtleHBsYWlucyZuYnNw O2hvdyZuYnNwO2FuJm5ic3A7b3BlcmF0b3ImbmJzcDtjb3VsZCZuYnNwO3VzZSZuYnNwO1NV UEEmbmJzcDsoU2hhcmVkJm5ic3A7VW5pZmllZDwvRElWPg0KPERJVj4mbmJzcDsmbmJzcDsm bmJzcDtQb2xpY3kmbmJzcDtBdXRvbWF0aW9uKSZuYnNwO3RvJm5ic3A7cHJvdmlkZSZuYnNw O3RoZXNlJm5ic3A7YXBwbGljYXRpb25zLjwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7PC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+UGxlYXNlJm5ic3A7 bm90ZSZuYnNwO3RoYXQmbmJzcDtpdCZuYnNwO21heSZuYnNwO3Rha2UmbmJzcDthJm5ic3A7 Y291cGxlJm5ic3A7b2YmbmJzcDttaW51dGVzJm5ic3A7ZnJvbSZuYnNwO3RoZSZuYnNwO3Rp bWUmbmJzcDtvZiZuYnNwO3N1Ym1pc3Npb248L0RJVj4NCjxESVY+dW50aWwmbmJzcDt0aGUm bmJzcDtodG1saXplZCZuYnNwO3ZlcnNpb24mbmJzcDthbmQmbmJzcDtkaWZmJm5ic3A7YXJl Jm5ic3A7YXZhaWxhYmxlJm5ic3A7YXQmbmJzcDt0b29scy5pZXRmLm9yZy48L0RJVj4NCjxE SVY+PC9ESVY+DQo8RElWPlRoZSZuYnNwO0lFVEYmbmJzcDtTZWNyZXRhcmlhdDwvRElWPg0K PERJVj48L0RJVj48L0ZPTlQ+PC9ESVY+PHA+5aaC5p6c5oKo6ZSZ6K+v5o6l5pS25LqG6K+l 6YKu5Lu277yM6K+36YCa6L+H55S15a2Q6YKu5Lu256uL5Y2z6YCa55+l5oiR5Lus44CC6K+3 5Zue5aSN6YKu5Lu25YiwaHFzLXNwbWNAY2hpbmF1bmljb20uY27vvIzljbPlj6/ku6XpgIDo rqLmraTpgq7ku7bjgILmiJHku6zlsIbnq4vljbPlsIbmgqjnmoTkv6Hmga/ku47miJHku6zn moTlj5HpgIHnm67lvZXkuK3liKDpmaTjgIINCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMg ZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB1cyBpbW1lZGlhdGVseSBieSBlLW1haWwu IFBsZWFzZSByZXBseSB0byBocXMtc3BtY0BjaGluYXVuaWNvbS5jbiBpZiB5b3Ugd2FudCB0 byB1bnN1YnNjcmliZSBmcm9tIHRoaXMgbWFpbC4gV2Ugd2lsbCBpbW1lZGlhdGVseSByZW1v dmUgeW91ciBpbmZvcm1hdGlvbiBmcm9tIG91ciBzZW5kaW5nIGNhdGFsb2d1ZS48L3A+DQo8 L0JPRFk+PC9IVE1MPg0K --=====003_Dragon385747871675_=====-- From georgios.karagiannis@huawei.com Wed Sep 17 20:38:56 2014 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67F001A0690 for ; Wed, 17 Sep 2014 20:38:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.252 X-Spam-Level: X-Spam-Status: No, score=-5.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, 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 YfpVNntsC_2r for ; Wed, 17 Sep 2014 20:38:47 -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 B08301A00F0 for ; Wed, 17 Sep 2014 20:38:46 -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 BJO56694; Thu, 18 Sep 2014 03:38:44 +0000 (GMT) Received: from LHREML516-MBX.china.huawei.com ([169.254.1.85]) by lhreml402-hub.china.huawei.com ([10.201.5.241]) with mapi id 14.03.0158.001; Thu, 18 Sep 2014 04:38:37 +0100 From: Georgios Karagiannis To: Tina TSOU Thread-Topic: [Supa] Area hand-off, and some friendly advice ... Thread-Index: AQHPzqh9Us1IwolkWUGUssV+Mn5WLpwFfqEggAAWG8mAAKjywA== Date: Thu, 18 Sep 2014 03:38:37 +0000 Message-ID: References: , <338BDC47F10D414AB0BC843C4D5DCFE085CE25@SJCEML701-CHM.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.83.145] Content-Type: multipart/alternative; boundary="_000_C5034E44CD620A44971BAAEB372655DC63488ALHREML516MBXchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/supa/Z36fOCbivPvtqX0rB_xxvDMdAIc Cc: "supa@ietf.org" Subject: Re: [Supa] Area hand-off, and some friendly advice ... X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 04:04:52 -0000 --_000_C5034E44CD620A44971BAAEB372655DC63488ALHREML516MBXchina_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Tina, Dear all, Thank you very much for sending the updated charter. In principle I agree w= ith these updated, but I have some comments: Comment_1: What you mean by the term "applications"? Are you referring to "= end user applications"? According to discussions that we have had in APONF, I believe that we had d= ecided to work on an interface between network services, which are enhanced= OSS type of services and the controller and NOT between end user applicati= ons and the controller. Comment_2: The charter does not include any information about the "policy a= utomation" that needs to be supported by this activity, see title of this a= ctivity. IMO, the charter can include text, similar to the below: "A network graph includes application based policies, which are actions and= access policies generated by network service systems to map the network g= raph instance into specific network management policies, i.e., into physica= l or virtualized network components. Such application based demands are: *) Configuration types: o) request to dynamically configure e.g., (virtualized) L2= VPN, a (virtualized L3VPN), a service topology, the relationships between datacentre= s o) request to place the configuration, e.g., a service topo= logy on physical locations, e.g., on VMs (virtual Machines) *) Data plane types: o) request to steer a traffic flow o) request prioritize a traffic flow o) request to encapsulate/de-capsulate a traffic flow o) request block or admit a traffic flow *) Control plane / Routing plane types: o) request to change the routing state on a service or net= work function As starting point SUPA will only focus on application based demands used fo= r configuration purposes. " Comment_3: the charter does not include any information about authenticatio= n and authorization support. We could add the following bullet into the work items: o) The definition on how to use NETCONF (or RESTCONF) authentication and au= thorization mechanisms to achieve protection and isolation Comment_4: the charter does not explain what is out of scope. You may add: "The following items are out of the SUPA scope: o) specification of the network management and controlling policies and the= ir associated device configuration models" Comment_5: there is not a one to one mapping between the work items and the= milestones. Moreover, there are too many milestones that are focusing on p= roducing Informational RFCs. You may remove some of the bullets and add new ones. The Milestones section= can then become: Milestones: - Produce 'Problem Statement and Use Cases' as an Informational RFC. - Produce a document specifying the model for a generic multi-layer netw= ork graph, as an Informational RFC. - Produce several documents describing different levels of abstract views= using the network graph model defined above, including physical view, logi= cal view, layer-3 view, configuration view, performance probing view, servi= ce view and other such as L3VPN, L2VPN, datacenters and traffic engineering= , as Protocol Specifications' Standards Track RFCs. - Produce a document on SUPA NETCONF/YANG (or RESTCONF/YANG) Protocol Spe= cification' Standards Track RFC. - Produce a document that provides the guidelines on using NETCONF (or R= ESTCONF) authentication and authorization mechanisms to achieve security pr= otection and isolation' as an Informational RFC. Best regards, Georgios : From: Tina TSOU > Date: September 15, 2014 at 1:57:32 PM PDT To: Spencer Dawkins >, "supa@ietf.org" > Cc: Benoit Claise > Subject: Re: [Supa] Area hand-off, and some friendly advice ... Dear Spencer, Benoit et al, Thank you for your friendly advice. Below are SUPA draft charter, and OPENv6, APONF and SUPA group historic per= spective, based on the list discussion. Look forward to more opinions and d= iscussions on the list. * SUPA draft charter: -------------- SUPA (Shared Unified Policy Automation) Target Area: OPS Description of Working Group: Network operators are faced with networks of increasing size and complexity= while trying to improve their quality and availability, as more and more s= ervices depend on them. Programmatic ways to configure networks, often cal= led software-defined, are considered by many network operators in order to = shift the balance in their favor. Automation of configuration may provide significant improvements in configu= ration agility, error detection and uptime for operators. However the real = value behind central configuration schemes lies within the possible simplif= ication through abstraction provided by such systems to applications runnin= g above them (on the so-called northbound side). Well-designed abstractions= are able to provide a wide range of granularity for various applications n= eeds, from the lower-level physical network to high-level application servi= ces. Although several organizations outside of the IETF have defined various sch= emes for the configuration of network devices and specific network controll= ers, none of them offer a vendor-neutral standardized way for applications = to transmit their needs to controllers. The SUPA (Shared Unified Policy Aut= omation) working group will work on the definition of such as standardized = interface for applications to communicate with network controllers of all t= ypes. The interface definitions will be based on the concept of network graph, an= entity describing an arbitrary topology of nodes and links at any level of= abstraction and granularity. Such a graph may describe, for example, a phy= sical topology, a L2 network, a service topology or the relationships betwe= en datacenters. Although some IETF working groups have started work relatin= g to the description of various topologies such as I2RS (L3 and routing top= ologies), ALTO (cost maps), SFC (service chain), none of these groups aim a= t offering a truly generic multi-layer and abstract topology for standard n= orthbound configuration. Work items for SUPA include: 1) Choice of a modeling language used by the group to describe the network = graph. Existing modeling languages such as YANG will be considered for this= purpose unless no suitable one is found. 2) Choice of a transport protocol for the modeling language mentioned above= . The group will re-use a protocol already defined as a transport for the m= odeling language, such as NETCONF or RESTCONF in the case of YANG. 3) The definition of a standardized model for a network topology graph. Thi= s model may be used to describe topologies at any functional layer, from ph= ysical networks to network services and higher abstractions. The nodes of t= his graph may describe physical nodes as well as virtualized ones. 4) The definition and standardization of a number of basic abstracted model= s using network graphs. These might include, but are not limited to, L3VPNs= , L2VPNs, datacenters, traffic engineering, implementation of IPv6 transiti= on mechanism and their enforcement to users. 5) Guidelines for the mapping of abstract model information to physical or = virtualized network components. Proposed milestones for the working group: - Produce a problem statement document for SUPA. - Produce a gap analysis for SUPA in order to verify overlap with the wor= k of other IETF groups. - Produce a requirement document describing the desired properties of an = abstract multi-layer network graph definition. - Produce a gap analysis of existing modeling language, their characteris= tics, possible transport protocols and how they compare to the SUPA require= ments. - Produce a document specifying the model for a generic multi-layer netwo= rk graph. - Produce several documents describing different levels of abstract views= using the network graph model defined above, including physical view, logi= cal view, layer-3 view, configuration view, performance probing view, servi= ce view and other such as L3VPN, L2VPN, datacenters and traffic engineering= . ------------ * OPENv6, APONF and SUPA group historic perspective ------------------------------------------------------------------------- Most IETF working groups are formed in the interest of solving some actual = real-world problem from network operators, developers or manufacturers and = the initial work from the OPENv6 group was no exception. Some operators saw= a common interest in defining a common approach for the deployment of IPv6= transition tools. Although the preferred way of deploying IPv6 remains by = dual-stacking, several operators have deployed additional transition tools = such as 6RD (RFC5969), DS-Lite (RFC6333), NAT64 (RFC6146) and others with t= he intent of speeding up or to provide more flexibility in their IPv6 servi= ces. Each of these protocols presents its own set of deployment challenges = and failure modes for users, either because of unsupported applications, pa= rtial implementations in some off-the-shelf devices such as home routers or= some limitations of the protocols themselves to name a few cases. The fact these protocols are often deployed with techniques targeting the e= xtension of IPv4 service, such as Carrier Grade NAT, making their deploymen= t even more complex, especially when targeting minimal end-user impact. Alt= hough some approaches in solving this were proposed, for example in RFC6264= , the market hasn't seen the advent of configurable CGN devices or adaptive= home gateways. The only solution for operators is to have an agile way to = provision rapidly and easily any type of IPv6 or IPv4 service depending of = the specific needs of each end-user and their device. These changes must be= performed with respect to the operator existing policies regarding the net= work, billing, security and other constraints. While exploring these issues, it became clear the best way to address them = would be to use a central controller that would be able to coordinate the d= eployment of different protocols amongst several devices in a consistent fa= shion. Such a controller would receive high-level policy information from a= management application, transform it in network-level configuration and ap= ply it to physical or virtual devices. At that point, several other use cas= es outside of the deployment of IPv6 started to emerge, for example for the= control of data center traffic steering, for the creation of tunnels and t= he provisioning of L3VPN. The group decided to rename its activities under = the acronym APONF, for Application Policy on Network Functions, which seeme= d a more fitting name. The definition of policies by a management applicati= on toward a network controller would be at the center of the work for the g= roup. Several group documents were created around this concept. When presented at a bar bof during IETF-90 in Toronto, most of the feedback= was positive, but the scope of the work was often judged too large in scop= e. It wasn't clear either how much overlap there was with other IETF groups= . A better analysis of this aspect in the following weeks revealed some lev= el of overlap with other groups, but also where deficiencies exist. The two= aspects where IETF work seems to be lacking are in the definition of high-= level policy language for applications and also in a standard model to desc= ribe network topologies at different levels of granularity, or abstraction.= Some existing working groups have published work on the latter. For exampl= e, the ALTO working group defined a way to describe network functions at di= fferent level of granularity using cost maps, but this approach does not se= em practical for the description of complex network topologies to and from = a central controller. A topology draft exists in the I2RS group, but it is = very centered ! around ro uting protocols and L2-L3 links. The group has recently renamed its activities under the SUPA (Shared Unifie= d Policy Automation) acronym with the intention of defining a standard way = to push policies to a central controller. It appears, however, that in orde= r to define such policies, the definition of a standard multi-layer model f= or the description of networks of all types would be desirable. Therefore t= he initial work for the SUPA group would be to select an existing modeling = language and define a clear multi-layer model able to describe network or s= ervice information at any level of granularity or complexity. -------------- Thank you, Tina -----Original Message----- From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Spencer Dawkins Sent: Friday, September 12, 2014 9:42 AM To: supa@ietf.org Cc: Benoit Claise Subject: [Supa] Area hand-off, and some friendly advice ... Dear SUPA friends, Several IESG members had a chat earlier this week, and decided that SUPA re= ally belongs in OPS. I've requested that the area affiliation in http://www= .ietf.org/list/nonwg.html be updated to reflect that. Benoit will be your AD for additional charter discussion. If I might offer some friendly advice, several ADs are fairly confused abou= t the relationship between openv6, APONF, and SUPA. If you could put togeth= er a short paragraph that's something like "we started openv6 to do X, then= we realized we needed to do Y so we proposed APONF, and after discussions = in Toronto, we chose a different direction with SUPA because of Z", that wo= uld be very helpful. I also have a request from Benoit (and Adrian, and Joel) to make the descri= ption at https://www.ietf.org/mailman/listinfo/supa more understandable for= people who haven't been following the work - if you intend to charter a wo= rking group, you'll want people to understand what you're proposing. You should probably keep in mind that people who talk over a long period of= time are likely to develop a shared understanding that people who weren't = involved don't understand clearly. If there's a smart newcomer who could lo= ok over problem statements, proposed charters and see what's not clear to n= ewcomers, that would likely be helpful as well. Thanks, and best wishes. I'll see you in the hallways of Honolulu, where al= l ADs lurk sooner or later ... Spencer _______________________________________________ Supa mailing list Supa@ietf.org https://www.ietf.org/mailman/listinfo/supa _______________________________________________ Supa mailing list Supa@ietf.org https://www.ietf.org/mailman/listinfo/supa --_000_C5034E44CD620A44971BAAEB372655DC63488ALHREML516MBXchina_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 <= /p>

Dear Tina, Dear all,

Thank you very much for sending the updated charter. In principle = I agree with these updated, but I have some comments:

Comment_1: What you mean by the term “applications”? A= re you referring to “end user applications”?

According to discussions that we have had in APONF, I believe that= we had decided to work on an interface between network services, which are= enhanced OSS type of services and the controller and NOT between end user applications and the controller.<= /o:p>

 

Comment_2: The charter does not include any information about the = “policy automation” that needs to be supported by this activity= , see title of this activity.

IMO, the charter can i= nclude text, similar to the below:

 

“A network graph= includes application based policies, which are actions and access policies= generated by network service systems to map the network  graph instan= ce into specific network management policies, i.e., into physical or virtualized network components.  <= /p>

 Such application= based demands are:

   &nbs= p;        *) Configuration types:

   &nbs= p;             = o) request to dynamically configure e.g., (virtualized) L2VPN, a (virtualiz= ed L3VPN),  

   &nbs= p;            &= nbsp; a service topology, the  relationships between datacentres<= o:p>

   &nbs= p;            o) req= uest to place the configuration, e.g., a service topology on physical locat= ions, e.g.,

   &nbs= p;            &= nbsp;   on VMs (virtual Machines)

 

   &nbs= p;       *) Data plane types:

   &nbs= p;            o) req= uest to steer a traffic flow

   &nbs= p;             = o) request prioritize a traffic flow

   &nbs= p;             = o) request to encapsulate/de-capsulate a traffic flow

   &nbs= p;             = o) request block or admit a traffic flow

 

   &nbs= p;         *) Control plane / Routi= ng plane types:

   &nbs= p;             = o) request to change the routing state on a service or network function

 

As starting point SUPA= will only focus on application based demands used for configuration purpos= es. “

 

 

Comment_3: the charter= does not include any information about authentication and authorization su= pport.

We could add the follo= wing bullet into the work items:

o) The definition on h= ow to use NETCONF (or RESTCONF) authentication and authorization mechanisms= to achieve protection and isolation

 

Comment_4: the charter= does not explain what is out of scope. You may add:

“The following i= tems are out of the SUPA scope:

 

o) specification of th= e network management and controlling policies and their associated device c= onfiguration models”

 

Comment_5: there is no= t a one to one mapping between the work items and the milestones. Moreover,= there are too many milestones that are focusing on producing Informational= RFCs.

You may remove some of= the bullets and add new ones. The Milestones section can then become:=

Milestones:=

-   Produce = 'Problem Statement and Use Cases' as an Informational RFC.

 

-   Produce = a document specifying the  model for a generic multi-layer network gra= ph, as an Informational RFC.

 

-   Produce = several documents describing different levels of abstract views using the n= etwork graph model defined above, including physical view, logical view, la= yer-3 view, configuration view, performance probing view, service view and other such as L3VPN, L2VPN, datacenters and traffic= engineering, as Protocol Specifications' Standards Track RFCs.<= /span>

 

-   Produce = a document on SUPA NETCONF/YANG (or RESTCONF/YANG) Protocol Specification' = Standards Track RFC.

 

-    Pr= oduce a document that provides the guidelines on using NETCONF (or RESTCONF= ) authentication and authorization mechanisms to achieve security protectio= n and isolation' as an Informational RFC.

 

Best regards,

Georgios

 

 

:

From: Tina TSO= U <Tina.Tsou.Zouting@hua= wei.com>
Date: September 15, 2014 at 1:57:32 PM PDT
To: Spencer Dawkins <spencerdawkins.ietf@gmail.com>, "supa@ietf.org" <supa@i= etf.org>
Cc: Benoit Claise <bclaise@c= isco.com>
Subject: Re: [Supa] Area hand-off, and some friendly advice ...

Dear Spencer, Benoit et al,

Thank you for your friendly advice.

Below are SUPA draft charter, and OPENv6, APONF and SUPA group historic per= spective, based on the list discussion. Look forward to more opinions and d= iscussions on the list.


* SUPA draft charter:
--------------

SUPA (Shared Unified Policy Automation)

Target Area: OPS

Description of Working Group:

Network operators are faced with networks of increasing size and complexity= while trying to improve their quality and availability, as more and more s= ervices depend on them. Programmatic ways to configure networks, often &nbs= p;called software-defined, are considered by many network operators in order to shift the balance in their favor.
Automation of configuration may provide significant improvements in configu= ration agility, error detection and uptime for operators. However the real = value behind central configuration schemes lies within the possible simplif= ication through abstraction provided by such systems to applications running above them (on the so-called north= bound side). Well-designed abstractions are able to provide a wide range of= granularity for various applications needs, from the lower-level physical = network to high-level application services.

Although several organizations outside of the IETF have defined various sch= emes for the configuration of network devices and specific network controll= ers, none of them offer a vendor-neutral standardized way for applications = to transmit their needs to controllers. The SUPA (Shared Unified Policy Automation) working group will work on the= definition of such as standardized interface for applications to communica= te with network controllers of all types.

The interface definitions will be based on the concept of network graph, an= entity describing an arbitrary topology of nodes and links at any level of= abstraction and granularity. Such a graph may describe, for example, a phy= sical topology, a L2 network, a service topology or the relationships between datacenters. Although some I= ETF working groups have started work relating to the description of various= topologies such as I2RS (L3 and routing topologies), ALTO (cost maps), SFC= (service chain), none of these groups aim at offering a truly generic multi-layer and abstract topology f= or standard northbound configuration.

Work items for SUPA include:

1) Choice of a modeling language used by the group to describe the network = graph. Existing modeling languages such as YANG will be considered for this= purpose unless no suitable one is found.

2) Choice of a transport protocol for the modeling language mentioned above= . The group will re-use a protocol already defined as a transport for the m= odeling language, such as NETCONF or RESTCONF in the case of YANG.

3) The definition of a standardized model for a network topology graph. Thi= s model may be used to describe topologies at any functional layer, from ph= ysical networks to network services and higher abstractions. The nodes of t= his graph may describe physical nodes as well as virtualized ones.

4) The definition and standardization of a number of basic abstracted model= s using network graphs. These might include, but are not limited to, L3VPNs= , L2VPNs, datacenters, traffic engineering, implementation of IPv6 transiti= on mechanism and their enforcement to users.  

5) Guidelines for the mapping of abstract model information to physical or = virtualized network components.  

Proposed milestones for the working group:

-   Produce a problem statement document for SUPA.

-   Produce a gap analysis for SUPA in order to verify overlap wi= th the work of other IETF groups.

-   Produce a requirement document describing the desired propert= ies of an abstract multi-layer network graph definition.

-   Produce a gap analysis of existing modeling language, their c= haracteristics, possible transport protocols and how they compare to the SU= PA requirements.

-   Produce a document specifying the model for a generic multi-l= ayer network graph.

-   Produce several documents describing different levels of abst= ract views using the network graph model defined above, including physical = view, logical view, layer-3 view, configuration view, performance probing v= iew, service view and other such as L3VPN, L2VPN, datacenters and traffic engineering.  

------------


* OPENv6, APONF and SUPA group historic perspective
-------------------------------------------------------------------------
Most IETF working groups are formed in the interest of solving some actual = real-world problem from network operators, developers or manufacturers and = the initial work from the OPENv6 group was no exception. Some operators saw= a common interest in defining a common approach for the deployment of IPv6 transition tools. Although the = preferred way of deploying IPv6 remains by dual-stacking, several operators= have deployed additional transition tools such as 6RD (RFC5969), DS-Lite (= RFC6333), NAT64 (RFC6146) and others with the intent of speeding up or to provide more flexibility in their IPv= 6 services. Each of these protocols presents its own set of deployment chal= lenges and failure modes for users, either because of unsupported applicati= ons, partial implementations in some off-the-shelf devices such as home routers or some limitations of the= protocols themselves to name a few cases.

The fact these protocols are often deployed with techniques targeting the e= xtension of IPv4 service, such as Carrier Grade NAT, making their deploymen= t even more complex, especially when targeting minimal end-user impact. Alt= hough some approaches in solving this were proposed, for example in RFC6264, the market hasn't seen the adv= ent of configurable CGN devices or adaptive home gateways. The only solutio= n for operators is to have an agile way to provision rapidly and easily any= type of IPv6 or IPv4 service depending of the specific needs of each end-user and their device. These changes mus= t be performed with respect to the operator existing policies regarding the= network, billing, security and other constraints.

While exploring these issues, it became clear the best way to address them = would be to use a central controller that would be able to coordinate the d= eployment of different protocols amongst several devices in a consistent fa= shion. Such a controller would receive high-level policy information from a management application, transform it = in network-level configuration and apply it to physical or virtual devices.= At that point, several other use cases outside of the deployment of IPv6 s= tarted to emerge, for example for the control of data center traffic steering, for the creation of tunnels a= nd the provisioning of L3VPN. The group decided to rename its activities un= der the acronym APONF, for Application Policy on Network Functions, which s= eemed a more fitting name. The definition of policies by a management application toward a network controller would = be at the center of the work for the group. Several group documents were cr= eated around this concept.

When presented at a bar bof during IETF-90 in Toronto, most of the feedback= was positive, but the scope of the work was often judged too large in scop= e. It wasn't clear either how much overlap there was with other IETF groups= . A better analysis of this aspect in the following weeks revealed some level of overlap with other groups, b= ut also where deficiencies exist. The two aspects where IETF work seems to = be lacking are in the definition of high-level policy language for applicat= ions and also in a standard model to describe network topologies at different levels of granularity, or abst= raction. Some existing working groups have published work on the latter. Fo= r example, the ALTO working group defined a way to describe network functio= ns at different level of granularity using cost maps, but this approach does not seem practical for the descrip= tion of complex network topologies to and from a central controller. A topo= logy draft exists in the I2RS group, but it is very centered !
around ro
uting protocols and L2-L3 links.

The group has recently renamed its activities under the SUPA (Shared Unifie= d Policy Automation) acronym with the intention of defining a standard way = to push policies to a central controller. It appears, however, that in orde= r to define such policies, the definition of a standard multi-layer model for the description of networks of all typ= es would be desirable. Therefore the initial work for the SUPA group would = be to select an existing modeling language and define a clear multi-layer m= odel able to describe network or service information at any level of granularity or complexity.
--------------


Thank you,
Tina

-----Original Message-----
From: Supa [mailto:supa-bounces@ie= tf.org] On Behalf Of Spencer Dawkins
Sent: Friday, September 12, 2014 9:42 AM
To: supa@ietf.org
Cc: Benoit Claise
Subject: [Supa] Area hand-off, and some friendly advice ...

Dear SUPA friends,

Several IESG members had a chat earlier this week, and decided that SUPA re= ally belongs in OPS. I've requested that the area affiliation in http://www.ietf.org/list/no= nwg.html be updated to reflect that.

Benoit will be your AD for additional charter discussion.

If I might offer some friendly advice, several ADs are fairly confused abou= t the relationship between openv6, APONF, and SUPA. If you could put togeth= er a short paragraph that's something like "we started openv6 to do X,= then we realized we needed to do Y so we proposed APONF, and after discussions in Toronto, we chose a different = direction with SUPA because of Z", that would be very helpful.

I also have a request from Benoit (and Adrian, and Joel) to make the descri= ption at https://www.ietf.org= /mailman/listinfo/supa more understandable for people who haven't been = following the work - if you intend to charter a working group, you'll want = people to understand what you're proposing.

You should probably keep in mind that people who talk over a long period of= time are likely to develop a shared understanding that people who weren't = involved don't understand clearly. If there's a smart newcomer who could lo= ok over problem statements, proposed charters and see what's not clear to newcomers, that would likely be helpf= ul as well.

Thanks, and best wishes. I'll see you in the hallways of Honolulu, where al= l ADs lurk sooner or later ...

Spencer

_______________________________________________
Supa mailing list
Supa@ietf.org
https://www.ietf.org= /mailman/listinfo/supa

_______________________________________________
Supa mailing list
Supa@ietf.org
https://www.ietf.org= /mailman/listinfo/supa

--_000_C5034E44CD620A44971BAAEB372655DC63488ALHREML516MBXchina_-- From nobody Thu Sep 18 00:54:18 2014 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 948711A7113 for ; Thu, 18 Sep 2014 00:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.553 X-Spam-Level: X-Spam-Status: No, score=-3.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.652, 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 9i09Dsnhwyr2 for ; Thu, 18 Sep 2014 00:54:13 -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 A6EE01A7034 for ; Thu, 18 Sep 2014 00:54:11 -0700 (PDT) Received: from smtptc.telefonica.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 29E203A0187; Thu, 18 Sep 2014 09:54:09 +0200 (CEST) Received: from ESTGVMSP101.EUROPE.telefonica.corp (unknown [10.92.4.9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtptc.telefonica.com (Postfix) with ESMTPS id 137B13A014F; Thu, 18 Sep 2014 09:54:09 +0200 (CEST) Received: from emea01-db3-obe.outbound.protection.outlook.com (10.92.5.139) by tls.telefonica.com (10.92.6.49) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 18 Sep 2014 09:54:08 +0200 Received: from DB4PR06MB575.eurprd06.prod.outlook.com (10.242.192.156) by DB4PR06MB409.eurprd06.prod.outlook.com (10.141.236.11) with Microsoft SMTP Server (TLS) id 15.0.1029.13; Thu, 18 Sep 2014 07:54:07 +0000 Received: from DB4PR06MB576.eurprd06.prod.outlook.com (10.242.192.23) by DB4PR06MB575.eurprd06.prod.outlook.com (10.242.192.156) with Microsoft SMTP Server (TLS) id 15.0.1024.12; Thu, 18 Sep 2014 07:54:06 +0000 Received: from DB4PR06MB576.eurprd06.prod.outlook.com ([10.242.192.23]) by DB4PR06MB576.eurprd06.prod.outlook.com ([10.242.192.23]) with mapi id 15.00.1034.003; Thu, 18 Sep 2014 07:54:06 +0000 From: LUIS MIGUEL CONTRERAS MURILLO To: "supa@ietf.org" Thread-Topic: New Version Notification for draft-contreras-supa-yang-network-topo-00.txt Thread-Index: AQHP0xTtYNoV/hmyG0eLnhFczRTp4pwGg71A Date: Thu, 18 Sep 2014 07:54:06 +0000 Message-ID: <716e56912f124e2d8c13148c5b83f1f5@DB4PR06MB576.eurprd06.prod.outlook.com> References: <20140918074811.15859.74757.idtracker@ietfa.amsl.com> In-Reply-To: <20140918074811.15859.74757.idtracker@ietfa.amsl.com> Accept-Language: es-ES, en-US Content-Language: es-ES X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [195.235.92.25] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:;UriScan:; x-forefront-prvs: 033857D0BD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(59124003)(189002)(377424004)(199003)(229853001)(106116001)(19580405001)(106356001)(105586002)(2351001)(107046002)(83322001)(19580395003)(110136001)(21056001)(20776003)(74316001)(76576001)(33646002)(80022003)(108616004)(79102003)(85306004)(230783001)(90102001)(101416001)(81542003)(31966008)(74502003)(15975445006)(77982003)(81342003)(74662003)(46102003)(4396001)(64706001)(54356999)(15202345003)(50986999)(87936001)(76176999)(95666004)(2501002)(2656002)(76482002)(83072002)(86362001)(92566001)(66066001)(97736003)(99396002)(85852003)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR06MB575; H:DB4PR06MB576.eurprd06.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:; X-OriginatorOrg: telefonica.com X-TM-AS-MML: No Archived-At: http://mailarchive.ietf.org/arch/msg/supa/lE0pY1atBZSF4uPav6sjRA4eaD0 Cc: "andrew.qu@mediatek.com" Subject: [Supa] RV: New Version Notification for draft-contreras-supa-yang-network-topo-00.txt X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 07:54:16 -0000 RGVhciBjb2xsZWFndWVzLA0KDQpQbGVhc2Ugbm90ZSBhIG5ldyBkcmFmdCBkb2N1bWVudCBhZGRy ZXNzaW5nIFlBTkcgbW9kZWxsaW5nIG9mIG5ldHdvcmsgdG9wb2xvZ3kgaGFzIGJlZW4ganVzdCB1 cGxvYWRlZC4gQW55IGNvbW1lbnQgaXMgbW9yZSB0aGFuIHdlbGNvbWUuDQoNClRoYW5rcw0KDQpC ZXN0IHJlZ2FyZHMNCg0KTHVpcw0KDQotLS0tLU1lbnNhamUgb3JpZ2luYWwtLS0tLQ0KRGU6IGlu dGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10N CkVudmlhZG8gZWw6IGp1ZXZlcywgMTggZGUgc2VwdGllbWJyZSBkZSAyMDE0IDk6NDgNClBhcmE6 IExVSVMgTUlHVUVMIENPTlRSRVJBUyBNVVJJTExPOyBBbmRyZXcgUXU7IExVSVMgTUlHVUVMIENP TlRSRVJBUyBNVVJJTExPOyBBbmRyZXcgUXUNCkFzdW50bzogTmV3IFZlcnNpb24gTm90aWZpY2F0 aW9uIGZvciBkcmFmdC1jb250cmVyYXMtc3VwYS15YW5nLW5ldHdvcmstdG9wby0wMC50eHQNCg0K DQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtY29udHJlcmFzLXN1cGEteWFuZy1uZXR3b3Jr LXRvcG8tMDAudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEx1aXMgTS4g Q29udHJlcmFzIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZTogICAg ICAgICAgIGRyYWZ0LWNvbnRyZXJhcy1zdXBhLXlhbmctbmV0d29yay10b3BvDQpSZXZpc2lvbjog ICAgICAgMDANClRpdGxlOiAgICAgICAgICBBIFlBTkcgRGF0YSBNb2RlbCBmb3IgTmV0d29yayBU b3BvbG9naWVzDQpEb2N1bWVudCBkYXRlOiAgMjAxNC0wOS0xOA0KR3JvdXA6ICAgICAgICAgIElu ZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6ICAgICAgICAgIDIzDQpVUkw6ICAgICAgICAgICAg aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtY29udHJlcmFzLXN1cGEt eWFuZy1uZXR3b3JrLXRvcG8tMDAudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtY29udHJlcmFzLXN1cGEteWFuZy1uZXR3b3JrLXRvcG8v DQpIdG1saXplZDogICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY29udHJl cmFzLXN1cGEteWFuZy1uZXR3b3JrLXRvcG8tMDANCg0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9j dW1lbnQgZGVmaW5lcyBhIFlBTkcgZGF0YSBtb2RlbCBmb3IgbmV0d29yayB0b3BvbG9naWVzLg0K DQoNCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMg ZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFu ZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3Jl dGFyaWF0DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KRXN0ZSBtZW5z YWplIHkgc3VzIGFkanVudG9zIHNlIGRpcmlnZW4gZXhjbHVzaXZhbWVudGUgYSBzdSBkZXN0aW5h dGFyaW8sIHB1ZWRlIGNvbnRlbmVyIGluZm9ybWFjacOzbiBwcml2aWxlZ2lhZGEgbyBjb25maWRl bmNpYWwgeSBlcyBwYXJhIHVzbyBleGNsdXNpdm8gZGUgbGEgcGVyc29uYSBvIGVudGlkYWQgZGUg ZGVzdGluby4gU2kgbm8gZXMgdXN0ZWQuIGVsIGRlc3RpbmF0YXJpbyBpbmRpY2FkbywgcXVlZGEg bm90aWZpY2FkbyBkZSBxdWUgbGEgbGVjdHVyYSwgdXRpbGl6YWNpw7NuLCBkaXZ1bGdhY2nDs24g eS9vIGNvcGlhIHNpbiBhdXRvcml6YWNpw7NuIHB1ZWRlIGVzdGFyIHByb2hpYmlkYSBlbiB2aXJ0 dWQgZGUgbGEgbGVnaXNsYWNpw7NuIHZpZ2VudGUuIFNpIGhhIHJlY2liaWRvIGVzdGUgbWVuc2Fq ZSBwb3IgZXJyb3IsIGxlIHJvZ2Ftb3MgcXVlIG5vcyBsbyBjb211bmlxdWUgaW5tZWRpYXRhbWVu dGUgcG9yIGVzdGEgbWlzbWEgdsOtYSB5IHByb2NlZGEgYSBzdSBkZXN0cnVjY2nDs24uDQoNClRo ZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyB0cmFuc21pc3Npb24gaXMgcHJpdmlsZWdl ZCBhbmQgY29uZmlkZW50aWFsIGluZm9ybWF0aW9uIGludGVuZGVkIG9ubHkgZm9yIHRoZSB1c2Ug b2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IG5hbWVkIGFib3ZlLiBJZiB0aGUgcmVhZGVyIG9m IHRoaXMgbWVzc2FnZSBpcyBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBoZXJl Ynkgbm90aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uIG9yIGNvcHlp bmcgb2YgdGhpcyBjb21tdW5pY2F0aW9uIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIElmIHlvdSBo YXZlIHJlY2VpdmVkIHRoaXMgdHJhbnNtaXNzaW9uIGluIGVycm9yLCBkbyBub3QgcmVhZCBpdC4g UGxlYXNlIGltbWVkaWF0ZWx5IHJlcGx5IHRvIHRoZSBzZW5kZXIgdGhhdCB5b3UgaGF2ZSByZWNl aXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IgYW5kIHRoZW4gZGVsZXRlIGl0Lg0KDQpF c3RhIG1lbnNhZ2VtIGUgc2V1cyBhbmV4b3Mgc2UgZGlyaWdlbSBleGNsdXNpdmFtZW50ZSBhbyBz ZXUgZGVzdGluYXTDoXJpbywgcG9kZSBjb250ZXIgaW5mb3JtYcOnw6NvIHByaXZpbGVnaWFkYSBv dSBjb25maWRlbmNpYWwgZSDDqSBwYXJhIHVzbyBleGNsdXNpdm8gZGEgcGVzc29hIG91IGVudGlk YWRlIGRlIGRlc3Rpbm8uIFNlIG7Do28gw6kgdm9zc2Egc2VuaG9yaWEgbyBkZXN0aW5hdMOhcmlv IGluZGljYWRvLCBmaWNhIG5vdGlmaWNhZG8gZGUgcXVlIGEgbGVpdHVyYSwgdXRpbGl6YcOnw6Nv LCBkaXZ1bGdhw6fDo28gZS9vdSBjw7NwaWEgc2VtIGF1dG9yaXphw6fDo28gcG9kZSBlc3RhciBw cm9pYmlkYSBlbSB2aXJ0dWRlIGRhIGxlZ2lzbGHDp8OjbyB2aWdlbnRlLiBTZSByZWNlYmV1IGVz dGEgbWVuc2FnZW0gcG9yIGVycm8sIHJvZ2Ftb3MtbGhlIHF1ZSBub3MgbyBjb211bmlxdWUgaW1l ZGlhdGFtZW50ZSBwb3IgZXN0YSBtZXNtYSB2aWEgZSBwcm9jZWRhIGEgc3VhIGRlc3RydWnDp8Oj bw0K From nobody Thu Sep 18 02:52:24 2014 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F22591A872D for ; Thu, 18 Sep 2014 02:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.202 X-Spam-Level: X-Spam-Status: No, score=-3.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-1.652] 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 82jObmrWMcpz for ; Thu, 18 Sep 2014 02:52:17 -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 50D101A032A for ; Thu, 18 Sep 2014 02:52:17 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id E6AFFF66; Thu, 18 Sep 2014 11:52:14 +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 ocm_WSlxYni0; Thu, 18 Sep 2014 11:51:58 +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; Thu, 18 Sep 2014 11:52:14 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 41A4420036; Thu, 18 Sep 2014 11:52:14 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id nHlCdnMgDC39; Thu, 18 Sep 2014 11:52:13 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3BDF220035; Thu, 18 Sep 2014 11:52:13 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 086DF2E6786D; Thu, 18 Sep 2014 11:52:12 +0200 (CEST) Date: Thu, 18 Sep 2014 11:52:12 +0200 From: Juergen Schoenwaelder To: JF Tremblay Message-ID: <20140918095212.GA19626@elstar.local> Mail-Followup-To: JF Tremblay , supa@ietf.org References: <002c01cfc688$b6d618d0$24824a70$@cernet.edu.cn> <8ECF7AE3-6C16-4E8B-B842-22ABB36B2990@viagenie.ca> <000201cfc71c$e261ddb0$a7259910$@cernet.edu.cn> <20140903214437.GA81569@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/supa/epw4OSFJ2TIKGzJaMyJSSkbnt9Y Cc: supa@ietf.org Subject: Re: [Supa] Any example of "network service graph"? X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 09:52:20 -0000 On Fri, Sep 05, 2014 at 10:18:39AM -0400, JF Tremblay wrote: > > On Sep 3, 2014, at 5:44 PM, Juergen Schoenwaelder wrote: > > > On Wed, Sep 03, 2014 at 04:30:09PM -0400, JF Tremblay wrote: > >> > >> - Define how the model will be defined and transported, if possible with an existing protocol (could be YANG for example) > >> > > > > YANG is a data modeling language, not a protocol. NETCONF and RESTCONF > > are protocols to access and manipulate data defined in YANG data > > models. I assume people understand that but then I also see these > > terms messed up more than occasionally… > > Ok, I agree this sentence was poorly worded. YANG applied to the model definition, not the protocol, of course. The point was that *both* a modelling language AND a transport have to be chosen or defined, but that depending of the choice of the modelling language, the transport might already be defined. > > If YANG is chosen as a modelling langage, then NETCONF or RESTCONF are a given as the protocols. > You may save a lot of time if the selection is made now rather than later in the process. /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 Thu Sep 18 03:31:39 2014 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D31121A8745 for ; Thu, 18 Sep 2014 03:31:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.731 X-Spam-Level: X-Spam-Status: No, score=-0.731 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-1.652, 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 apZeUDPgzUsW for ; Thu, 18 Sep 2014 03:31:34 -0700 (PDT) Received: from cmccmta1.chinamobile.com (cmccmta1.chinamobile.com [221.176.66.79]) by ietfa.amsl.com (Postfix) with SMTP id AC3521A872E for ; Thu, 18 Sep 2014 03:31:33 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.121.9]) by rmmx-syy-dmz-app01-12001 (RichMail) with SMTP id 2ee1541ab482f30-4c11b; Thu, 18 Sep 2014 18:31:31 +0800 (CST) X-RM-TRANSID: 2ee1541ab482f30-4c11b X-RM-SPAM-FLAG: 00000000 Received: from vicwork (unknown[183.243.249.172]) by rmsmtp-syy-appsvr05-12005 (RichMail) with SMTP id 2ee5541ab482980-1be37; Thu, 18 Sep 2014 18:31:31 +0800 (CST) X-RM-TRANSID: 2ee5541ab482980-1be37 From: "Vic Liu" To: Date: Thu, 18 Sep 2014 18:32:19 +0800 Message-ID: <001801cfd32b$d34e9230$79ebb690$@chinamobile.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: Ac/TK6JQt6Twos9OSBGyQjcd0YKMWw== Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/supa/keH1lH99Qyk642gl97o4kq_-Zfg Subject: Re: [Supa] Area hand-off, and some friendly advice ... X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 10:31:38 -0000 Dear SUPA Automation of configuration sounds interesting to operators and DC network managers. If I understand correctly, do you mean higher level simplified configuration can be translated into detailed ones by a controller-like agent and then dispatched to the data plane? However, before reading your PS and use case drafts, I'm not sure the meaning of your abstraction. Can you elaborate it? Thank You All the best! ------------------------------------- Vic Liu China Mobile -----Original Message----- From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Tina TSOU Sent: Tuesday, September 16, 2014 4:58 AM To: Spencer Dawkins; supa@ietf.org Cc: Benoit Claise Subject: Re: [Supa] Area hand-off, and some friendly advice ... Dear Spencer, Benoit et al, Thank you for your friendly advice. Below are SUPA draft charter, and OPENv6, APONF and SUPA group historic perspective, based on the list discussion. Look forward to more opinions and discussions on the list. * SUPA draft charter: -------------- SUPA (Shared Unified Policy Automation) Target Area: OPS Description of Working Group: Network operators are faced with networks of increasing size and complexity while trying to improve their quality and availability, as more and more services depend on them. Programmatic ways to configure networks, often called software-defined, are considered by many network operators in order to shift the balance in their favor. Automation of configuration may provide significant improvements in configuration agility, error detection and uptime for operators. However the real value behind central configuration schemes lies within the possible simplification through abstraction provided by such systems to applications running above them (on the so-called northbound side). Well-designed abstractions are able to provide a wide range of granularity for various applications needs, from the lower-level physical network to high-level application services. Although several organizations outside of the IETF have defined various schemes for the configuration of network devices and specific network controllers, none of them offer a vendor-neutral standardized way for applications to transmit their needs to controllers. The SUPA (Shared Unified Policy Automation) working group will work on the definition of such as standardized interface for applications to communicate with network controllers of all types. The interface definitions will be based on the concept of network graph, an entity describing an arbitrary topology of nodes and links at any level of abstraction and granularity. Such a graph may describe, for example, a physical topology, a L2 network, a service topology or the relationships between datacenters. Although some IETF working groups have started work relating to the description of various topologies such as I2RS (L3 and routing topologies), ALTO (cost maps), SFC (service chain), none of these groups aim at offering a truly generic multi-layer and abstract topology for standard northbound configuration. Work items for SUPA include: 1) Choice of a modeling language used by the group to describe the network graph. Existing modeling languages such as YANG will be considered for this purpose unless no suitable one is found. 2) Choice of a transport protocol for the modeling language mentioned above. The group will re-use a protocol already defined as a transport for the modeling language, such as NETCONF or RESTCONF in the case of YANG. 3) The definition of a standardized model for a network topology graph. This model may be used to describe topologies at any functional layer, from physical networks to network services and higher abstractions. The nodes of this graph may describe physical nodes as well as virtualized ones. 4) The definition and standardization of a number of basic abstracted models using network graphs. These might include, but are not limited to, L3VPNs, L2VPNs, datacenters, traffic engineering, implementation of IPv6 transition mechanism and their enforcement to users. 5) Guidelines for the mapping of abstract model information to physical or virtualized network components. Proposed milestones for the working group: - Produce a problem statement document for SUPA. - Produce a gap analysis for SUPA in order to verify overlap with the work of other IETF groups. - Produce a requirement document describing the desired properties of an abstract multi-layer network graph definition. - Produce a gap analysis of existing modeling language, their characteristics, possible transport protocols and how they compare to the SUPA requirements. - Produce a document specifying the model for a generic multi-layer network graph. - Produce several documents describing different levels of abstract views using the network graph model defined above, including physical view, logical view, layer-3 view, configuration view, performance probing view, service view and other such as L3VPN, L2VPN, datacenters and traffic engineering. ------------ * OPENv6, APONF and SUPA group historic perspective ------------------------------------------------------------------------- Most IETF working groups are formed in the interest of solving some actual real-world problem from network operators, developers or manufacturers and the initial work from the OPENv6 group was no exception. Some operators saw a common interest in defining a common approach for the deployment of IPv6 transition tools. Although the preferred way of deploying IPv6 remains by dual-stacking, several operators have deployed additional transition tools such as 6RD (RFC5969), DS-Lite (RFC6333), NAT64 (RFC6146) and others with the intent of speeding up or to provide more flexibility in their IPv6 services. Each of these protocols presents its own set of deployment challenges and failure modes for users, either because of unsupported applications, partial implementations in some off-the-shelf devices such as home routers or some limitations of the protocols themselves to name a few cases. The fact these protocols are often deployed with techniques targeting the extension of IPv4 service, such as Carrier Grade NAT, making their deployment even more complex, especially when targeting minimal end-user impact. Although some approaches in solving this were proposed, for example in RFC6264, the market hasn't seen the advent of configurable CGN devices or adaptive home gateways. The only solution for operators is to have an agile way to provision rapidly and easily any type of IPv6 or IPv4 service depending of the specific needs of each end-user and their device. These changes must be performed with respect to the operator existing policies regarding the network, billing, security and other constraints. While exploring these issues, it became clear the best way to address them would be to use a central controller that would be able to coordinate the deployment of different protocols amongst several devices in a consistent fashion. Such a controller would receive high-level policy information from a management application, transform it in network-level configuration and apply it to physical or virtual devices. At that point, several other use cases outside of the deployment of IPv6 started to emerge, for example for the control of data center traffic steering, for the creation of tunnels and the provisioning of L3VPN. The group decided to rename its activities under the acronym APONF, for Application Policy on Network Functions, which seemed a more fitting name. The definition of policies by a management application toward a network controller would be at the center of the work for the group. Several group documents were created around this concept. When presented at a bar bof during IETF-90 in Toronto, most of the feedback was positive, but the scope of the work was often judged too large in scope. It wasn't clear either how much overlap there was with other IETF groups. A better analysis of this aspect in the following weeks revealed some level of overlap with other groups, but also where deficiencies exist. The two aspects where IETF work seems to be lacking are in the definition of high-level policy language for applications and also in a standard model to describe network topologies at different levels of granularity, or abstraction. Some existing working groups have published work on the latter. For example, the ALTO working group defined a way to describe network functions at different level of granularity using cost maps, but this approach does not seem practical for the description of complex network topologies to and from a central controller. A topology draft exists in the I2RS group, but it is very centered ! around ro uting protocols and L2-L3 links. The group has recently renamed its activities under the SUPA (Shared Unified Policy Automation) acronym with the intention of defining a standard way to push policies to a central controller. It appears, however, that in order to define such policies, the definition of a standard multi-layer model for the description of networks of all types would be desirable. Therefore the initial work for the SUPA group would be to select an existing modeling language and define a clear multi-layer model able to describe network or service information at any level of granularity or complexity. -------------- Thank you, Tina -----Original Message----- From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Spencer Dawkins Sent: Friday, September 12, 2014 9:42 AM To: supa@ietf.org Cc: Benoit Claise Subject: [Supa] Area hand-off, and some friendly advice ... Dear SUPA friends, Several IESG members had a chat earlier this week, and decided that SUPA really belongs in OPS. I've requested that the area affiliation in http://www.ietf.org/list/nonwg.html be updated to reflect that. Benoit will be your AD for additional charter discussion. If I might offer some friendly advice, several ADs are fairly confused about the relationship between openv6, APONF, and SUPA. If you could put together a short paragraph that's something like "we started openv6 to do X, then we realized we needed to do Y so we proposed APONF, and after discussions in Toronto, we chose a different direction with SUPA because of Z", that would be very helpful. I also have a request from Benoit (and Adrian, and Joel) to make the description at https://www.ietf.org/mailman/listinfo/supa more understandable for people who haven't been following the work - if you intend to charter a working group, you'll want people to understand what you're proposing. You should probably keep in mind that people who talk over a long period of time are likely to develop a shared understanding that people who weren't involved don't understand clearly. If there's a smart newcomer who could look over problem statements, proposed charters and see what's not clear to newcomers, that would likely be helpful as well. Thanks, and best wishes. I'll see you in the hallways of Honolulu, where all ADs lurk sooner or later ... Spencer _______________________________________________ Supa mailing list Supa@ietf.org https://www.ietf.org/mailman/listinfo/supa _______________________________________________ Supa mailing list Supa@ietf.org https://www.ietf.org/mailman/listinfo/supa From nobody Thu Sep 18 04:23:48 2014 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 014741A017C for ; Thu, 18 Sep 2014 04:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.253 X-Spam-Level: X-Spam-Status: No, score=-5.253 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, 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 BNBpVTPx5e0b for ; Thu, 18 Sep 2014 04:23:41 -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 457201A014D for ; Thu, 18 Sep 2014 04:23:40 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJO99427; Thu, 18 Sep 2014 11:23:33 +0000 (GMT) Received: from LHREML516-MBX.china.huawei.com ([169.254.1.85]) by lhreml405-hub.china.huawei.com ([10.201.5.242]) with mapi id 14.03.0158.001; Thu, 18 Sep 2014 12:23:27 +0100 From: Georgios Karagiannis To: Vic Liu , "supa@ietf.org" Thread-Topic: [Supa] Area hand-off, and some friendly advice ... Thread-Index: Ac/TK6JQUs1IwolkWUGUssV+Mn5WLgABJEtw Date: Thu, 18 Sep 2014 11:23:27 +0000 Message-ID: References: <001801cfd32b$d34e9230$79ebb690$@chinamobile.com> In-Reply-To: <001801cfd32b$d34e9230$79ebb690$@chinamobile.com> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.92.237] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/supa/KpZkfwAKvidt66XSNyQNaycjIC0 Subject: Re: [Supa] Area hand-off, and some friendly advice ... X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 11:23:47 -0000 Dear Vic, Thank you very much for your email! IMHO, the scope of SUPA is to work on (1) modeling different abstraction le= vels of the configuration (by using e.g., YANG) (2) by using configuration = based policy translate a higher abstraction level and simplified configura= tion into a detailed one, (3) northbound interface (NETCONF or RESTCONF) th= at can be used to realize/maintain the translation mentioned in bullet (2). Best regards, Georgios -----Original Message----- From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Vic Liu Sent: Thursday, September 18, 2014 11:32 AM To: supa@ietf.org Subject: Re: [Supa] Area hand-off, and some friendly advice ... Dear SUPA Automation of configuration sounds interesting to operators and DC network = managers. If I understand correctly, do you mean higher level simplified co= nfiguration can be translated into detailed ones by a controller-like agent= and then dispatched to the data plane? However, before reading your PS and= use case drafts, I'm not sure the meaning of your abstraction. Can you ela= borate it? Thank You All the best! ------------------------------------- Vic Liu China Mobile -----Original Message----- From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Tina TSOU Sent: Tuesday, September 16, 2014 4:58 AM To: Spencer Dawkins; supa@ietf.org Cc: Benoit Claise Subject: Re: [Supa] Area hand-off, and some friendly advice ... Dear Spencer, Benoit et al, Thank you for your friendly advice.=20 Below are SUPA draft charter, and OPENv6, APONF and SUPA group historic per= spective, based on the list discussion. Look forward to more opinions and d= iscussions on the list. * SUPA draft charter: -------------- SUPA (Shared Unified Policy Automation) Target Area: OPS Description of Working Group: Network operators are faced with networks of increasing size and complexity= while trying to improve their quality and availability, as more and more s= ervices depend on them. Programmatic ways to configure networks, often call= ed software-defined, are considered by many network operators in order to s= hift the balance in their favor. =20 Automation of configuration may provide significant improvements in configu= ration agility, error detection and uptime for operators. However the real = value behind central configuration schemes lies within the possible simplif= ication through abstraction provided by such systems to applications runnin= g above them (on the so-called northbound side). Well-designed abstractions= are able to provide a wide range of granularity for various applications n= eeds, from the lower-level physical network to high-level application servi= ces. =20 Although several organizations outside of the IETF have defined various sch= emes for the configuration of network devices and specific network controll= ers, none of them offer a vendor-neutral standardized way for applications = to transmit their needs to controllers. The SUPA (Shared Unified Policy Aut= omation) working group will work on the definition of such as standardized = interface for applications to communicate with network controllers of all t= ypes. =20 The interface definitions will be based on the concept of network graph, an= entity describing an arbitrary topology of nodes and links at any level of= abstraction and granularity. Such a graph may describe, for example, a phy= sical topology, a L2 network, a service topology or the relationships betwe= en datacenters. Although some IETF working groups have started work relatin= g to the description of various topologies such as I2RS (L3 and routing top= ologies), ALTO (cost maps), SFC (service chain), none of these groups aim a= t offering a truly generic multi-layer and abstract topology for standard n= orthbound configuration. =20 Work items for SUPA include: =20 1) Choice of a modeling language used by the group to describe the network = graph. Existing modeling languages such as YANG will be considered for this= purpose unless no suitable one is found. =20 2) Choice of a transport protocol for the modeling language mentioned above= . The group will re-use a protocol already defined as a transport for the mod= eling language, such as NETCONF or RESTCONF in the case of YANG. =20 3) The definition of a standardized model for a network topology graph. Thi= s model may be used to describe topologies at any functional layer, from ph= ysical networks to network services and higher abstractions. The nodes of t= his graph may describe physical nodes as well as virtualized ones. =20 4) The definition and standardization of a number of basic abstracted model= s using network graphs. These might include, but are not limited to, L3VPNs= , L2VPNs, datacenters, traffic engineering, implementation of IPv6 transiti= on mechanism and their enforcement to users. =20 =20 5) Guidelines for the mapping of abstract model information to physical or = virtualized network components. =20 Proposed milestones for the working group: =20 - Produce a problem statement document for SUPA. - Produce a gap analysis for SUPA in order to verify overlap with the wor= k of other IETF groups. - Produce a requirement document describing the desired properties of an abstract multi-layer network graph definition. - Produce a gap analysis of existing modeling language, their characteristics, possible transport protocols and how they compare to the S= UPA requirements. - Produce a document specifying the model for a generic multi-layer network graph. - Produce several documents describing different levels of abstract views using the network graph model defined above, including physical view, logic= al view, layer-3 view, configuration view, performance probing view, servic= e view and other such as L3VPN, L2VPN, datacenters and traffic engineering.= =20 ------------ * OPENv6, APONF and SUPA group historic perspective ------------------------------------------------------------------------- Most IETF working groups are formed in the interest of solving some actual = real-world problem from network operators, developers or manufacturers and = the initial work from the OPENv6 group was no exception. Some operators saw= a common interest in defining a common approach for the deployment of IPv6= transition tools. Although the preferred way of deploying IPv6 remains by = dual-stacking, several operators have deployed additional transition tools = such as 6RD (RFC5969), DS-Lite (RFC6333), NAT64 (RFC6146) and others with t= he intent of speeding up or to provide more flexibility in their IPv6 servi= ces. Each of these protocols presents its own set of deployment challenges = and failure modes for users, either because of unsupported applications, pa= rtial implementations in some off-the-shelf devices such as home routers or= some limitations of the protocols themselves to name a few cases.=20 The fact these protocols are often deployed with techniques targeting the e= xtension of IPv4 service, such as Carrier Grade NAT, making their deploymen= t even more complex, especially when targeting minimal end-user impact. Alt= hough some approaches in solving this were proposed, for example in RFC6264= , the market hasn't seen the advent of configurable CGN devices or adaptive= home gateways. The only solution for operators is to have an agile way to = provision rapidly and easily any type of IPv6 or IPv4 service depending of = the specific needs of each end-user and their device. These changes must be= performed with respect to the operator existing policies regarding the net= work, billing, security and other constraints.=20 While exploring these issues, it became clear the best way to address them = would be to use a central controller that would be able to coordinate the d= eployment of different protocols amongst several devices in a consistent fa= shion. Such a controller would receive high-level policy information from a= management application, transform it in network-level configuration and ap= ply it to physical or virtual devices. At that point, several other use cas= es outside of the deployment of IPv6 started to emerge, for example for the= control of data center traffic steering, for the creation of tunnels and t= he provisioning of L3VPN. The group decided to rename its activities under = the acronym APONF, for Application Policy on Network Functions, which seeme= d a more fitting name. The definition of policies by a management applicati= on toward a network controller would be at the center of the work for the g= roup. Several group documents were created around this concept.=20 When presented at a bar bof during IETF-90 in Toronto, most of the feedback= was positive, but the scope of the work was often judged too large in scop= e. It wasn't clear either how much overlap there was with other IETF groups. A= better analysis of this aspect in the following weeks revealed some level = of overlap with other groups, but also where deficiencies exist. The two as= pects where IETF work seems to be lacking are in the definition of high-lev= el policy language for applications and also in a standard model to describ= e network topologies at different levels of granularity, or abstraction. So= me existing working groups have published work on the latter. For example, the ALTO working group defined a way to describe network funct= ions at different level of granularity using cost maps, but this approach d= oes not seem practical for the description of complex network topologies to= and from a central controller. A topology draft exists in the I2RS group, = but it is very centered ! around ro uting protocols and L2-L3 links.=20 The group has recently renamed its activities under the SUPA (Shared Unifie= d Policy Automation) acronym with the intention of defining a standard way = to push policies to a central controller. It appears, however, that in orde= r to define such policies, the definition of a standard multi-layer model f= or the description of networks of all types would be desirable. Therefore t= he initial work for the SUPA group would be to select an existing modeling = language and define a clear multi-layer model able to describe network or s= ervice information at any level of granularity or complexity. -------------- Thank you, Tina -----Original Message----- From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Spencer Dawkins Sent: Friday, September 12, 2014 9:42 AM To: supa@ietf.org Cc: Benoit Claise Subject: [Supa] Area hand-off, and some friendly advice ... Dear SUPA friends, Several IESG members had a chat earlier this week, and decided that SUPA re= ally belongs in OPS. I've requested that the area affiliation in http://www= .ietf.org/list/nonwg.html be updated to reflect that. Benoit will be your AD for additional charter discussion. If I might offer some friendly advice, several ADs are fairly confused abou= t the relationship between openv6, APONF, and SUPA. If you could put togeth= er a short paragraph that's something like "we started openv6 to do X, then= we realized we needed to do Y so we proposed APONF, and after discussions = in Toronto, we chose a different direction with SUPA because of Z", that wo= uld be very helpful. I also have a request from Benoit (and Adrian, and Joel) to make the descri= ption at https://www.ietf.org/mailman/listinfo/supa more understandable for= people who haven't been following the work - if you intend to charter a wo= rking group, you'll want people to understand what you're proposing. You should probably keep in mind that people who talk over a long period of= time are likely to develop a shared understanding that people who weren't = involved don't understand clearly. If there's a smart newcomer who could lo= ok over problem statements, proposed charters and see what's not clear to n= ewcomers, that would likely be helpful as well. Thanks, and best wishes. I'll see you in the hallways of Honolulu, where al= l ADs lurk sooner or later ... Spencer _______________________________________________ Supa mailing list Supa@ietf.org https://www.ietf.org/mailman/listinfo/supa _______________________________________________ Supa mailing list Supa@ietf.org https://www.ietf.org/mailman/listinfo/supa _______________________________________________ Supa mailing list Supa@ietf.org https://www.ietf.org/mailman/listinfo/supa From nobody Thu Sep 18 07:35:35 2014 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 069391A8828 for ; Thu, 18 Sep 2014 07:35:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.652, 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 tLrnvF3Jp856 for ; Thu, 18 Sep 2014 07:35:32 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 982791A87F1 for ; Thu, 18 Sep 2014 07:35:32 -0700 (PDT) Received: from h229.viagenie.ca (h229.viagenie.ca [206.123.31.229]) by jazz.viagenie.ca (Postfix) with ESMTPSA id E5B754041B; Thu, 18 Sep 2014 10:35:30 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_38F5BFF7-6454-4F37-AFB5-60F6FBB5F314" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: JF Tremblay In-Reply-To: <20140918095212.GA19626@elstar.local> Date: Thu, 18 Sep 2014 10:35:29 -0400 Message-Id: <183A6916-0430-492B-8565-B0B8849F5F3B@viagenie.ca> References: <002c01cfc688$b6d618d0$24824a70$@cernet.edu.cn> <8ECF7AE3-6C16-4E8B-B842-22ABB36B2990@viagenie.ca> <000201cfc71c$e261ddb0$a7259910$@cernet.edu.cn> <20140903214437.GA81569@elstar.local> <20140918095212.GA19626@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/supa/WHc0yZjYjib73g87hE-Q7fEx5nM Cc: supa@ietf.org Subject: Re: [Supa] Any example of "network service graph"? X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 14:35:34 -0000 --Apple-Mail=_38F5BFF7-6454-4F37-AFB5-60F6FBB5F314 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Sep 18, 2014, at 5:52 AM, Juergen Schoenwaelder = wrote: >> If YANG is chosen as a modelling langage, then NETCONF or RESTCONF = are a given as the protocols.=20 >>=20 >=20 > You may save a lot of time if the selection is made now rather than > later in the process. >=20 > /js Agreed. If there=92s no sensible other choice, let=92s cut the chase and = just say the modelling aspects will be done in YANG for SUPA.=20 Any opinion on NETCONF vs RESTCONF?=20 They are not complete replacements for each others. RESTCONF seems = simpler to implement, especially for smaller apps. NETCONF seems more = efficient for larger data sets, but I might be wrong on these two = things, feel free to straighten my views here.=20 JF --Apple-Mail=_38F5BFF7-6454-4F37-AFB5-60F6FBB5F314 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 On Sep = 18, 2014, at 5:52 AM, Juergen Schoenwaelder <j.schoenwaelder@jacob= s-university.de> wrote:

If YANG is = chosen as a modelling langage, then NETCONF or RESTCONF are a given as = the protocols. 


You = may save a lot of time if the selection is made now rather than
later = in the process.

/js

Agreed. = If there=92s no sensible other choice, let=92s cut the chase and just = say the modelling aspects will be done in YANG for = SUPA. 

Any opinion on NETCONF vs = RESTCONF? 

They are not complete = replacements for each others. RESTCONF seems simpler to implement, = especially for smaller apps. NETCONF seems more efficient for larger = data sets, but I might be wrong on these two things, feel free to = straighten my views = here. 

JF

= --Apple-Mail=_38F5BFF7-6454-4F37-AFB5-60F6FBB5F314-- From nobody Thu Sep 18 07:54:05 2014 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61BEB1A8844 for ; Thu, 18 Sep 2014 07:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.652, 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 AhCvaiKvO6Tl for ; Thu, 18 Sep 2014 07:54:01 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id F14E01A883C for ; Thu, 18 Sep 2014 07:53:53 -0700 (PDT) Received: from h229.viagenie.ca (h229.viagenie.ca [206.123.31.229]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 35A974041B; Thu, 18 Sep 2014 10:53:52 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_44FA8E3E-9322-490A-8966-8E55313F39E5" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: JF Tremblay In-Reply-To: Date: Thu, 18 Sep 2014 10:53:49 -0400 Message-Id: References: <001801cfd32b$d34e9230$79ebb690$@chinamobile.com> To: Georgios Karagiannis X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/supa/zjz0rT2pWrW_vQ4EU6HTQ2Zzm0U Cc: "supa@ietf.org" Subject: Re: [Supa] SUPA's scope of work X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 14:54:03 -0000 --Apple-Mail=_44FA8E3E-9322-490A-8966-8E55313F39E5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Thank you Vic for your interest. More below. I took the liberty of = changing the topic to reflect the actual discussion.=20 On Sep 18, 2014, at 7:23 AM, Georgios Karagiannis = wrote: >=20 > IMHO, the scope of SUPA is to work on (1) modeling different = abstraction levels of the configuration (by using e.g., YANG) Georgios, I have trouble parsing some of your sentences. I=92m good with = =93modelling different abstraction levels=94, this makes perfect sense. = But the =93of the configuration=94 just throws me off. For me, = =93configuration=94 is synonym with a non-abstracted view of the = network. Configuration is what a physical controller manipulates and = pushes to devices. By =93configuration=94 here, do you mean the = parameters of the model? > (2) by using configuration based policy translate a higher = abstraction level and simplified configuration into a detailed one, Again, problems parsing. What is =93configuration based policy=94? What = does that mean? Why does it =93translate a higher abstraction level=94?=20 I think I have a glimpse of what you are trying to say. Is it that = higher abstractions have simplified configuration models and that these = will get translated by the controller into a physical-level non-abstract = configuration? > (3) northbound interface (NETCONF or RESTCONF) that can be used to = realize/maintain the translation mentioned in bullet (2). Again, I get the idea, but this wording is a bit weird. It=92s not the = northbound interface that translates anything. An interface exposes an = API and/or a model. Could we rather say that the northbound interfaces = defined in SUPA will expose models for different levels of abstractions? = And then that these abstract models will get translated within the = controller in a non-abstract model? This would be nice, but what is SUPA planning exactly within the scope = of work? To define a number of possible abstract models for the = northbound? To only define a mechanism by which any model can be = defined?=20 I guess we=92d want a way to define abstract models on the northbound = side without going through standardization within a workgroup each time. = I=92m not sure this would be desirable. =20 Opinions on the list? JF= --Apple-Mail=_44FA8E3E-9322-490A-8966-8E55313F39E5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Thank you Vic for your interest. More below. I = took the liberty of changing the topic to reflect the actual = discussion. 

On Sep 18, = 2014, at 7:23 AM, Georgios Karagiannis <georgios.karagiannis@huawe= i.com> wrote:

IMHO, the scope = of SUPA is to work on (1) modeling different abstraction levels of the = configuration (by using e.g., YANG) =

Georgios, I have trouble parsing some = of your sentences. I=92m good with =93modelling different abstraction = levels=94, this makes perfect sense. But the =93of the configuration=94 = just throws me off. For me, =93configuration=94 is synonym with a = non-abstracted view of the network. Configuration is what a physical = controller manipulates and pushes to devices. By =93configuration=94 = here, do you mean the parameters of the = model?


(2) by using = configuration based policy translate a  higher abstraction level = and simplified configuration into a detailed one, =

Again, problems parsing. What is = =93configuration based policy=94? What does that mean?
Why = does it =93translate a higher abstraction = level=94? 

I think I have a glimpse of = what you are trying to say. Is it that higher abstractions have = simplified configuration models and that these will get translated by = the controller into a physical-level non-abstract = configuration?


(3) = northbound interface (NETCONF or RESTCONF) that can be used to = realize/maintain the translation mentioned in bullet = (2).

Again, I get the idea, but this = wording is a bit weird. It=92s not the northbound interface that = translates anything. An interface exposes an API and/or a model. Could = we rather say that the northbound interfaces defined in SUPA will expose = models for different levels of abstractions? And then that these = abstract models will get translated within the controller in a = non-abstract model?

This would be nice, but = what is SUPA planning exactly within the scope of work? To define a = number of possible abstract models for the northbound? To only define a = mechanism by which any model can be = defined? 

I guess we=92d want a way to = define abstract models on the northbound side without going through = standardization within a workgroup each time. I=92m not sure this would = be desirable.  

Opinions on the = list?

JF
= --Apple-Mail=_44FA8E3E-9322-490A-8966-8E55313F39E5-- From nobody Thu Sep 18 07:55:00 2014 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30B3B1A8843 for ; Thu, 18 Sep 2014 07:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.202 X-Spam-Level: X-Spam-Status: No, score=-3.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-1.652] 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 CJMACD4tXCrV for ; Thu, 18 Sep 2014 07:54:46 -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 6FBBE1A0097 for ; Thu, 18 Sep 2014 07:54:44 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 38BE66D5; Thu, 18 Sep 2014 16:54:43 +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 Fc66o3Zsh7tX; Thu, 18 Sep 2014 16:54:25 +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; Thu, 18 Sep 2014 16:54:42 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8F77020036; Thu, 18 Sep 2014 16:54:42 +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 fpCj48L6g6Ix; Thu, 18 Sep 2014 16:54:42 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BA53B20035; Thu, 18 Sep 2014 16:54:41 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C6BF52E67ACB; Thu, 18 Sep 2014 16:54:40 +0200 (CEST) Date: Thu, 18 Sep 2014 16:54:40 +0200 From: Juergen Schoenwaelder To: JF Tremblay Message-ID: <20140918145439.GA20165@elstar.local> Mail-Followup-To: JF Tremblay , supa@ietf.org References: <002c01cfc688$b6d618d0$24824a70$@cernet.edu.cn> <8ECF7AE3-6C16-4E8B-B842-22ABB36B2990@viagenie.ca> <000201cfc71c$e261ddb0$a7259910$@cernet.edu.cn> <20140903214437.GA81569@elstar.local> <20140918095212.GA19626@elstar.local> <183A6916-0430-492B-8565-B0B8849F5F3B@viagenie.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <183A6916-0430-492B-8565-B0B8849F5F3B@viagenie.ca> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/supa/CHaKh65taYC10uUnRjiNdrFaaw4 Cc: supa@ietf.org Subject: Re: [Supa] Any example of "network service graph"? X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 14:54:55 -0000 On Thu, Sep 18, 2014 at 10:35:29AM -0400, JF Tremblay wrote: > Any opinion on NETCONF vs RESTCONF? > > They are not complete replacements for each others. RESTCONF seems simpler to implement, especially for smaller apps. NETCONF seems more efficient for larger data sets, but I might be wrong on these two things, feel free to straighten my views here. > I think a major functional difference is that RESTCONF does not support transactions. draft-ietf-netconf-restconf-01.txt section 1.2 may be relevant to read. It says among other things: A simplified transaction model is needed that allows basic CRUD operations on a hierarchy of conceptual resources. This represents a limited subset of the transaction capabilities of the NETCONF protocol. Applications that require more complex transaction capabilities might consider NETCONF instead of RESTCONF. The following transaction features are not directly provided in RESTCONF: o datastore locking (full or partial) o candidate datastore o startup datastore o validate operation o confirmed-commit procedure So it primarily boils down to the question whether a more complete transaction model is needed. /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 Thu Sep 18 08:09:53 2014 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAB181A058E for ; Thu, 18 Sep 2014 08:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.553 X-Spam-Level: X-Spam-Status: No, score=-3.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652, 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 lfLriQ9W0W4f for ; Thu, 18 Sep 2014 08:09:44 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 98D121A047B for ; Thu, 18 Sep 2014 08:09:44 -0700 (PDT) Received: from h229.viagenie.ca (h229.viagenie.ca [206.123.31.229]) by jazz.viagenie.ca (Postfix) with ESMTPSA id F41594041B; Thu, 18 Sep 2014 11:09:42 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: JF Tremblay In-Reply-To: <20140918145439.GA20165@elstar.local> Date: Thu, 18 Sep 2014 11:09:41 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1377E927-EED2-4D65-9C22-C4A2B3CAAC39@viagenie.ca> References: <002c01cfc688$b6d618d0$24824a70$@cernet.edu.cn> <8ECF7AE3-6C16-4E8B-B842-22ABB36B2990@viagenie.ca> <000201cfc71c$e261ddb0$a7259910$@cernet.edu.cn> <20140903214437.GA81569@elstar.local> <20140918095212.GA19626@elstar.local> <183A6916-0430-492B-8565-B0B8849F5F3B@viagenie.ca> <20140918145439.GA20165@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/supa/0HLuDKg3QGPgI68dbdwITc49rhk Cc: supa@ietf.org Subject: Re: [Supa] Any example of "network service graph"? X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 15:09:46 -0000 On Sep 18, 2014, at 10:54 AM, Juergen Schoenwaelder = wrote: > On Thu, Sep 18, 2014 at 10:35:29AM -0400, JF Tremblay wrote: > I think a major functional difference is that RESTCONF does not > support transactions. draft-ietf-netconf-restconf-01.txt section 1.2 > may be relevant to read. It says among other things: >=20 > A simplified transaction model is needed that allows basic CRUD > operations on a hierarchy of conceptual resources. This represents = a > limited subset of the transaction capabilities of the NETCONF > protocol. >=20 > Applications that require more complex transaction capabilities = might > consider NETCONF instead of RESTCONF. The following transaction > features are not directly provided in RESTCONF: >=20 > o datastore locking (full or partial) >=20 > o candidate datastore >=20 > o startup datastore >=20 > o validate operation >=20 > o confirmed-commit procedure >=20 > So it primarily boils down to the question whether a more complete > transaction model is needed. >=20 > /js Great, thanks for pointing out this relevant section.=20 In my view of things, more complex transactions are required because = management apps could use SUPA interfaces on the northbound side. On the = other hand, simpler is better for smaller apps, if we want to allow = smaller user apps to use the same SUPA interface set. I don=92t know if = there=92s room to allow both, but this could be considered.=20 I=92ll educate myself and read the RESTCONF draft more thoroughly.=20 JF From nobody Thu Sep 18 09:38:25 2014 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A51A61A887D for ; Thu, 18 Sep 2014 09:38:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.852 X-Spam-Level: X-Spam-Status: No, score=-5.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, 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 7ZB-ZhWbQKdN for ; Thu, 18 Sep 2014 09:38: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 DA4711A0141 for ; Thu, 18 Sep 2014 09:38:12 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJP28241; Thu, 18 Sep 2014 16:38:11 +0000 (GMT) Received: from LHREML516-MBX.china.huawei.com ([169.254.1.85]) by lhreml404-hub.china.huawei.com ([::1]) with mapi id 14.03.0158.001; Thu, 18 Sep 2014 17:38:07 +0100 From: Georgios Karagiannis To: JF Tremblay Thread-Topic: [Supa] SUPA's scope of work Thread-Index: AQHP01Bjaw9E2Sg0aU+y1ec7Kv1M/5wHDY6g Date: Thu, 18 Sep 2014 16:38:07 +0000 Message-ID: References: <001801cfd32b$d34e9230$79ebb690$@chinamobile.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.89.45] Content-Type: multipart/alternative; boundary="_000_C5034E44CD620A44971BAAEB372655DC634AF4LHREML516MBXchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/supa/risEvH14XNc1NromRPGNGP_hbWA Cc: "supa@ietf.org" Subject: Re: [Supa] SUPA's scope of work X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 16:38:22 -0000 --_000_C5034E44CD620A44971BAAEB372655DC634AF4LHREML516MBXchina_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear JF, Comments in line! From: JF Tremblay [mailto:jean-francois.tremblay@viagenie.ca] Sent: Thursday, September 18, 2014 3:54 PM To: Georgios Karagiannis Cc: supa@ietf.org Subject: Re: [Supa] SUPA's scope of work Thank you Vic for your interest. More below. I took the liberty of changing= the topic to reflect the actual discussion. On Sep 18, 2014, at 7:23 AM, Georgios Karagiannis > wrote: IMHO, the scope of SUPA is to work on (1) modeling different abstraction le= vels of the configuration (by using e.g., YANG) JF: Georgios, I have trouble parsing some of your sentences. I'm good with = "modelling different abstraction levels", this makes perfect sense. But the= "of the configuration" just throws me off. For me, "configuration" is syno= nym with a non-abstracted view of the network. Configuration is what a phys= ical controller manipulates and pushes to devices. By "configuration" here,= do you mean the parameters of the model? Georgios: Configuration in this context is network topology! Doe to use the= same terminology used by Vic. JF: (2) by using configuration based policy translate a higher abstraction= level and simplified configuration into a detailed one, Again, problems parsing. What is "configuration based policy"? What does th= at mean? Why does it "translate a higher abstraction level"? Georgios: This term is associated with the comments on the charter: "Such application based demands are: *) Configuration types: o) request to dynamically configure e.g., (virtualized) L2= VPN, a (virtualized L3VPN), a service topology, the relationships between datacentre= s o) request to place the configuration, e.g., a service topo= logy on physical locations, e.g., on VMs (virtual Machines)" JF: I think I have a glimpse of what you are trying to say. Is it that high= er abstractions have simplified configuration models and that these will ge= t translated by the controller into a physical-level non-abstract configura= tion? (3) northbound interface (NETCONF or RESTCONF) that can be used to realize/= maintain the translation mentioned in bullet (2). Again, I get the idea, but this wording is a bit weird. It's not the northb= ound interface that translates anything. An interface exposes an API and/or= a model. Could we rather say that the northbound interfaces defined in SUP= A will expose models for different levels of abstractions? And then that th= ese abstract models will get translated within the controller in a non-abst= ract model? This would be nice, but what is SUPA planning exactly within the scope of w= ork? To define a number of possible abstract models for the northbound? To = only define a mechanism by which any model can be defined? I guess we'd want a way to define abstract models on the northbound side wi= thout going through standardization within a workgroup each time. I'm not s= ure this would be desirable. Georgios: You are jumping in conclusions too fast. The exact description of what I mean will be written in the problem stateme= nt draft. What I wanted to say here is exactly (note the term: can be used to realize= /maintain the translation) northbound interface (NETCONF or RESTCONF) that can be used to realize/main= tain the translation mentioned in bullet The text is not mentioning anything about "SUPA will expose models for diff= erent levels of abstractions" Best regards, Georgios Opinions on the list? JF --_000_C5034E44CD620A44971BAAEB372655DC634AF4LHREML516MBXchina_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear JF,

 <= /p>

Comments in line!

 <= /p>

 <= /p>

From: JF Tremb= lay [mailto:jean-francois.tremblay@viagenie.ca]
Sent: Thursday, September 18, 2014 3:54 PM
To: Georgios Karagiannis
Cc: supa@ietf.org
Subject: Re: [Supa] SUPA's scope of work

 

Thank you Vic for your i= nterest. More below. I took the liberty of changing the topic to reflect th= e actual discussion. 

 =

On Sep 18, 2014, at 7:23 AM, Georgios Karagiannis &l= t;georgios.karagiannis@h= uawei.com> wrote:


IMHO, the scope of SUPA is to work on (1) modeling different abstraction le= vels of the configuration (by using e.g., YANG)

 

JF: Georgios, I= have trouble parsing some of your sentences. I’m good with “mo= delling different abstraction levels”, this makes perfect sense. But = the “of the configuration” just throws me off. For me, “configuration” is synonym with a non-abstracted view of the n= etwork. Configuration is what a physical controller manipulates and pushes = to devices. By “configuration” here, do you mean the parameters= of the model?

 <= /p>

Georgios: Configuration i= n this context is network topology! Doe to use the same terminology used by= Vic.



JF: (2) by usin= g configuration based policy translate a  higher abstraction level and= simplified configuration into a detailed one,

 

Again, problems parsing. What is “configuratio= n based policy”? What does that mean?

Why does it “translate a higher abstraction le= vel”? 

 <= /p>

Georgios: This term is as= sociated with the comments on the charter:

 

“Such applicatio= n based demands are:

   &nbs= p;        *) Configuration types:

   &nbs= p;             = o) request to dynamically configure e.g., (virtualized) L2VPN, a (virtualiz= ed L3VPN),  

   &nbs= p;            &= nbsp; a service topology, the  relationships between datacentres<= o:p>

   &nbs= p;            o) req= uest to place the configuration, e.g., a service topology on physical locat= ions, e.g.,

   &nbs= p;            &= nbsp;   on VMs (virtual Machines)”

 

JF: I think I h= ave a glimpse of what you are trying to say. Is it that higher abstractions= have simplified configuration models and that these will get translated by= the controller into a physical-level non-abstract configuration?

 



(3) northbound interface (NETCONF or RESTCONF) that = can be used to realize/maintain the translation mentioned in bullet (2).

 

Again, I get the idea, but this wording is a bit wei= rd. It’s not the northbound interface that translates anything. An in= terface exposes an API and/or a model. Could we rather say that the northbo= und interfaces defined in SUPA will expose models for different levels of abstractions? And then that these abstract = models will get translated within the controller in a non-abstract model?

 

This would be nice, but what is SUPA planning exactl= y within the scope of work? To define a number of possible abstract models = for the northbound? To only define a mechanism by which any model can be de= fined? 

 

I guess we’d want a way to define abstract mod= els on the northbound side without going through standardization within a w= orkgroup each time. I’m not sure this would be desirable.  =

 <= /p>

Georgios: You are jumping= in conclusions too fast.

The exact description of = what I mean will be written in the problem statement draft.

What I wanted to say here= is exactly (note the term: can be used to realize/maintain the translation)

northbound interface (NETCONF or RESTCONF) that can = be used to realize/maintain the translation mentioned in bullet

The text is not mentionin= g anything about “SUPA will expose models for different levels= of abstractions”

 

Best regards,

Georgios

 <= /p>

Opinions on the list?

 

JF

--_000_C5034E44CD620A44971BAAEB372655DC634AF4LHREML516MBXchina_-- From nobody Thu Sep 18 13:23:44 2014 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9CC91A0AE5 for ; Thu, 18 Sep 2014 13:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.652, 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 fUu5VvTSmVmf for ; Thu, 18 Sep 2014 13:23:37 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 311651A06B6 for ; Thu, 18 Sep 2014 13:23:37 -0700 (PDT) Received: from h200.viagenie.ca (h200.viagenie.ca [206.123.31.200]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 7542A4032E; Thu, 18 Sep 2014 16:23:35 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_49698B96-763D-4A5A-8AD7-F6B2B766D355" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: JF Tremblay In-Reply-To: <716e56912f124e2d8c13148c5b83f1f5@DB4PR06MB576.eurprd06.prod.outlook.com> Date: Thu, 18 Sep 2014 16:23:35 -0400 Message-Id: References: <20140918074811.15859.74757.idtracker@ietfa.amsl.com> <716e56912f124e2d8c13148c5b83f1f5@DB4PR06MB576.eurprd06.prod.outlook.com> To: LUIS MIGUEL CONTRERAS MURILLO X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/supa/EX6o5yOeUdyYPDMAPmsFKsQOZfc Cc: "andrew.qu@mediatek.com" , "supa@ietf.org" Subject: Re: [Supa] New Version Notification for draft-contreras-supa-yang-network-topo-00.txt X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 20:23:40 -0000 --Apple-Mail=_49698B96-763D-4A5A-8AD7-F6B2B766D355 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Luis,=20 Thanks to you and Andrew for writing this. Very interesting and quite in = line with the conception of a multi-layer topology model I was myself = trying to express. A few questions:=20 You limited the scope of the topology information to layer-3 and = beneath. Was it because you don=92t believe such a topology could be = applicable at higher levels?=20 In my mind, such a generic topology model could apply to higher layers. = For example, a host-server relationship could be a very basic topology = with a link between two nodes. It would allow later on to define = policies or parameters on such a session/link. =20 =20 Another point: I do like the idea of hierarchizing the topologies, but = I=92m not sure I understand it the way you described it. Reading the = document, it seemed at first that a parent topology would be a = lower-abstraction (lower-level) topology object. Topologies of different = levels would be linked through a parent-children relationship. But then = the text mentions =93The parent topology has a container node that maps = a sub topology.=94, it sounds like you=92re defining a topology embedded = in a topology of the same layer. Do I get this right? Both concepts are = interesting, maybe a way could be found to differentiate them in the = text. The second one sounds more like a container-contained relationship = rather than parent-children.=20 Also, could a topology be a parent to more than one higher-level = topology? I guess it does, but I haven=92t seen it clearly mentioned in = the text. An example would be a single physical topology with several = different logical topologies on top of it.=20 Btw, you might want to take a look at = http://tools.ietf.org/html/draft-edprop-opsawg-multi-layer-oam-ps-00. It = describes a multi-layer OAM model. Not exactly the same concepts, but it = describes interesting ideas too.=20 JF Tremblay=20 Viagenie On Sep 18, 2014, at 3:54 AM, LUIS MIGUEL CONTRERAS MURILLO = wrote: > Dear colleagues, >=20 > Please note a new draft document addressing YANG modelling of network = topology has been just uploaded. Any comment is more than welcome. >=20 > Thanks >=20 > Best regards >=20 > Luis >=20 > -----Mensaje original----- > De: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Enviado el: jueves, 18 de septiembre de 2014 9:48 > Para: LUIS MIGUEL CONTRERAS MURILLO; Andrew Qu; LUIS MIGUEL CONTRERAS = MURILLO; Andrew Qu > Asunto: New Version Notification for = draft-contreras-supa-yang-network-topo-00.txt >=20 >=20 > A new version of I-D, draft-contreras-supa-yang-network-topo-00.txt > has been successfully submitted by Luis M. Contreras and posted to the = IETF repository. >=20 > Name: draft-contreras-supa-yang-network-topo > Revision: 00 > Title: A YANG Data Model for Network Topologies > Document date: 2014-09-18 > Group: Individual Submission > Pages: 23 > URL: = http://www.ietf.org/internet-drafts/draft-contreras-supa-yang-network-topo= -00.txt > Status: = https://datatracker.ietf.org/doc/draft-contreras-supa-yang-network-topo/ > Htmlized: = http://tools.ietf.org/html/draft-contreras-supa-yang-network-topo-00 >=20 >=20 > Abstract: > This document defines a YANG data model for network topologies. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at = tools.ietf.org. >=20 > The IETF Secretariat >=20 >=20 > ________________________________ >=20 > Este mensaje y sus adjuntos se dirigen exclusivamente a su = destinatario, puede contener informaci=F3n privilegiada o confidencial y = es para uso exclusivo de la persona o entidad de destino. Si no es = usted. el destinatario indicado, queda notificado de que la lectura, = utilizaci=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. >=20 > The information contained in this transmission is privileged and = confidential information intended only for the use of the individual or = entity named above. If the reader of this message is not the intended = recipient, you are hereby notified that any dissemination, distribution = or copying of this communication is strictly prohibited. If you have = received this transmission in error, do not read it. Please immediately = reply to the sender that you have received this communication in error = and then delete it. >=20 > Esta mensagem e seus anexos se dirigem exclusivamente ao seu = destinat=E1rio, pode conter informa=E7=E3o privilegiada ou confidencial = e =E9 para uso exclusivo da pessoa ou entidade de destino. Se n=E3o =E9 = vossa senhoria o destinat=E1rio indicado, fica notificado de que a = leitura, utiliza=E7=E3o, divulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o = pode estar proibida em virtude da legisla=E7=E3o vigente. Se recebeu = esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente = por esta mesma via e proceda a sua destrui=E7=E3o > _______________________________________________ > Supa mailing list > Supa@ietf.org > https://www.ietf.org/mailman/listinfo/supa --Apple-Mail=_49698B96-763D-4A5A-8AD7-F6B2B766D355 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Luis, 
Thanks to you and Andrew = for writing this. Very interesting and quite in line with the conception = of a multi-layer topology model I was myself trying to = express.

A few questions: 
You = limited the scope of the topology information to layer-3 and beneath. = Was it because you don=92t believe such a topology could be applicable = at higher levels? 
In my mind, such a generic topology = model could apply to higher layers. For example, a host-server = relationship could be a very basic topology with a link between two = nodes. It would allow later on to define policies or parameters on such = a session/link.  
  
Another point: I = do like the idea of hierarchizing the topologies, but I=92m not sure I = understand it the way you described it. Reading the document, it seemed = at first that a parent topology would be a lower-abstraction = (lower-level) topology object. Topologies of different levels would be = linked through a parent-children relationship. But then the text = mentions =93The parent topology has a container node that maps a sub = topology.=94, it sounds like you=92re defining a topology embedded in a = topology of the same layer. Do I get this right? Both concepts are = interesting, maybe a way could be found to differentiate them in the = text. The second one sounds more like a container-contained relationship = rather than parent-children. 

Also, could = a topology be a parent to more than one higher-level topology? I guess = it does, but I haven=92t seen it clearly mentioned in the text. An = example would be a single physical topology with several different = logical topologies on top of it. 


JF = Tremblay 
Viagenie





Dear = colleagues,

Please note a new draft document addressing YANG = modelling of network topology has been just uploaded. Any comment is = more than welcome.

Thanks

Best = regards

Luis

-----Mensaje original-----
De: internet-drafts@ietf.org = [mailto:internet-drafts@ietf.org]
Enviado el: jueves, 18 de septiembre de 2014 9:48
Para: LUIS = MIGUEL CONTRERAS MURILLO; Andrew Qu; LUIS MIGUEL CONTRERAS MURILLO; = Andrew Qu
Asunto: New Version Notification for = draft-contreras-supa-yang-network-topo-00.txt


A new version = of I-D, draft-contreras-supa-yang-network-topo-00.txt
has been = successfully submitted by Luis M. Contreras and posted to the IETF = repository.

Name: =           draft-contrera= s-supa-yang-network-topo
Revision: =       00
Title: =          A YANG Data Model = for Network Topologies
Document date:  2014-09-18
Group: =          Individual = Submission
Pages: =          23
URL: =            http://www.ietf.org/internet-drafts/draft-contreras-supa-= yang-network-topo-00.txt
Status: =         https://datatracker.ietf.org/doc/draft-contreras-supa-yang-network= -topo/
Htmlized:       http://tools.ietf.org/html/draft-contreras-supa-yang-network-topo-00


Abstract:
  This document defines a YANG = data model for network topologies.




Please note that = it may take a couple of minutes from the time of submission until the = htmlized version and diff are available at tools.ietf.org.

The IETF = Secretariat


________________________________

Este = mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, = puede contener informaci=F3n privilegiada o confidencial y es para uso = exclusivo de la persona o entidad de destino. Si no es usted. el = destinatario indicado, queda notificado de que la lectura, utilizaci=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 confidential information intended only = for the use of the individual or entity named above. If the reader of = this message is not the intended recipient, you are hereby notified that = any dissemination, distribution or copying of this communication is = strictly prohibited. If you have received this transmission in error, do = not read it. Please immediately reply to the sender that you have = received this communication in error and then delete it.

Esta = mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio, = pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso = exclusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria = o destinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3= o, divulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o pode estar proibida = em virtude da legisla=E7=E3o vigente. Se recebeu esta mensagem por erro, = rogamos-lhe que nos o comunique imediatamente por esta mesma via e = proceda a sua = destrui=E7=E3o
_______________________________________________
Supa = mailing list
Supa@ietf.org
https://www.ietf.org/ma= ilman/listinfo/supa

= --Apple-Mail=_49698B96-763D-4A5A-8AD7-F6B2B766D355-- From nobody Fri Sep 19 07:14:29 2014 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F9E11A01A5 for ; Fri, 19 Sep 2014 07:14:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.652, 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 bQ2Qbyp075tu for ; Fri, 19 Sep 2014 07:14:19 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id CAF991A0193 for ; Fri, 19 Sep 2014 07:14:15 -0700 (PDT) Received: from h200.viagenie.ca (h200.viagenie.ca [206.123.31.200]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 619484041A for ; Fri, 19 Sep 2014 10:14:14 -0400 (EDT) From: JF Tremblay Content-Type: multipart/alternative; boundary="Apple-Mail=_71AE25FE-6DD2-444E-9795-150E605A4083" Message-Id: <960BE5BF-9CFA-48A1-971F-DE4EAFD8DFDA@viagenie.ca> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Date: Fri, 19 Sep 2014 10:14:13 -0400 References: <001801cfd32b$d34e9230$79ebb690$@chinamobile.com> To: "supa@ietf.org" In-Reply-To: X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/supa/Wu6us3roq3Ybl3BxeXwyhpLS5oU Subject: Re: [Supa] SUPA's scope of work X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 14:14:23 -0000 --Apple-Mail=_71AE25FE-6DD2-444E-9795-150E605A4083 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Sep 18, 2014, at 12:38 PM, Georgios Karagiannis = wrote:=20 > On Sep 18, 2014, at 7:23 AM, Georgios Karagiannis = wrote: > IMHO, the scope of SUPA is to work on (1) modeling different = abstraction levels of the configuration (by using e.g., YANG) > =20 > JF: Georgios, I have trouble parsing some of your sentences. I=92m = good with =93modelling different abstraction levels=94, this makes = perfect sense. But the =93of the configuration=94 just throws me off. = For me, =93configuration=94 is synonym with a non-abstracted view of the = network. Configuration is what a physical controller manipulates and = pushes to devices. By =93configuration=94 here, do you mean the = parameters of the model? > =20 > Georgios: Configuration in this context is network topology! Doe to = use the same terminology used by Vic. Georgios, you say =93Configuration [=85] is network topology!=94. I=92m = not sure this makes things clearer. Interfaces are usually either = API-based or model-driven. In the case of SUPA, we=92re obviously = discussing model-driven interfaces on the northbound side. I guess that = by =93configuration=94 here you mean the content of the model, but you = may be using the word "configuration" a bit too liberally.=20 > JF: (2) by using configuration based policy translate a higher = abstraction level and simplified configuration into a detailed one, > =20 > Again, problems parsing. What is =93configuration based policy=94? = What does that mean? > Why does it =93translate a higher abstraction level=94?=20 > =20 > Georgios: This term is associated with the comments on the charter: > =93Such application based demands are: > *) Configuration types: > o) request to dynamically configure e.g., = (virtualized) L2VPN, a (virtualized L3VPN), =20 > a service topology, the relationships between = datacentres > o) request to place the configuration, e.g., a service = topology on physical locations, e.g., > on VMs (virtual Machines)=94 Ok, I get it. You=92re calling a model instance with its data a = =93configuration=94. Not my favorite choice of words, but I=92ll wait to = hear form others on the list.=20 JF= --Apple-Mail=_71AE25FE-6DD2-444E-9795-150E605A4083 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Sep 18, 2014, at 12:38 PM, Georgios = Karagiannis <georgios.karagiannis@huawe= i.com> wrote: 
On = Sep 18, 2014, at 7:23 AM, Georgios Karagiannis <georgios.karagiannis@huawei.com> = wrote:
IMHO, the scope of SUPA is to = work on (1) modeling different abstraction levels of the configuration = (by using e.g., YANG)
 
JF: Georgios, I have = trouble parsing some of your sentences. I=92m good with =93modelling = different abstraction levels=94, this makes perfect sense. But the =93of = the configuration=94 just throws me off. For me, =93configuration=94 is = synonym with a non-abstracted view of the network. Configuration is what = a physical controller manipulates and pushes to devices. By = =93configuration=94 here, do you mean the parameters of the = model?
 
Georgios: Configuration in this context is network = topology! Doe to use the same terminology used by = Vic.

= Georgios, you say =93Configuration [=85] is network topology!=94. I=92m = not sure this makes things clearer. Interfaces are usually either = API-based or model-driven. In the case of SUPA, we=92re obviously = discussing model-driven interfaces on the northbound side. I guess that = by =93configuration=94 here you mean the content of the model, but you = may be using the word "configuration" a bit too = liberally. 


JF: (2) by using = configuration based policy translate a  higher abstraction level = and simplified configuration into a detailed one,
 
Again, problems parsing. What is =93configuration based policy=94?= What does that mean?
Why does it =93translate a higher abstraction = level=94? 
 
Georgios: This term is associated with the comments = on the charter:
=93Such application based demands = are:
            = *) Configuration types:
           &= nbsp;     o) request to dynamically configure e.g., = (virtualized) L2VPN, a (virtualized = L3VPN),  
           &= nbsp;      a service topology, the  = relationships between datacentres
           &= nbsp;    o) request to place the configuration, e.g., a = service topology on physical locations, = e.g.,
           &= nbsp;        on VMs (virtual = Machines)=94

Ok, I get it. You=92re calling a model instance with its = data a =93configuration=94. Not my favorite choice of words, but I=92ll = wait to hear form others on the = list. 

JF
= --Apple-Mail=_71AE25FE-6DD2-444E-9795-150E605A4083-- From nobody Sat Sep 20 04:08:36 2014 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 476251A0255 for ; Sat, 20 Sep 2014 04:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.252 X-Spam-Level: X-Spam-Status: No, score=-5.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, 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 2XkzU51T8Xek for ; Sat, 20 Sep 2014 04:08:29 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48D061A00E2 for ; Sat, 20 Sep 2014 04:08:28 -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 BJQ70909; Sat, 20 Sep 2014 11:08:26 +0000 (GMT) Received: from SZXEMA410-HUB.china.huawei.com (10.82.72.42) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 20 Sep 2014 12:08:24 +0100 Received: from SZXEMA509-MBS.china.huawei.com ([169.254.2.166]) by SZXEMA410-HUB.china.huawei.com ([10.82.72.42]) with mapi id 14.03.0158.001; Sat, 20 Sep 2014 19:08:18 +0800 From: "Liushucheng (Will)" To: JF Tremblay , "LUIS MIGUEL CONTRERAS MURILLO" Thread-Topic: [Supa] New Version Notification for draft-contreras-supa-yang-network-topo-00.txt Thread-Index: AQHP0xTtYNoV/hmyG0eLnhFczRTp4pwGg71AgABM1YCAAvRtsA== Date: Sat, 20 Sep 2014 11:08:17 +0000 Message-ID: References: <20140918074811.15859.74757.idtracker@ietfa.amsl.com> <716e56912f124e2d8c13148c5b83f1f5@DB4PR06MB576.eurprd06.prod.outlook.com> 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.66.78.79] Content-Type: multipart/alternative; boundary="_000_C9B5F12337F6F841B35C404CF0554ACB5FF944CESZXEMA509MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/supa/ZV2ozW_C_Y4ZyzK4RFFQcD-GztY Cc: "andrew.qu@mediatek.com" , "supa@ietf.org" Subject: Re: [Supa] New Version Notification for draft-contreras-supa-yang-network-topo-00.txt X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2014 11:08:34 -0000 --_000_C9B5F12337F6F841B35C404CF0554ACB5FF944CESZXEMA509MBSchi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi JF, I read this draft and have some comments to yours. Please see below in-line= . Regards, Will From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of JF Tremblay Sent: Friday, September 19, 2014 4:24 AM To: LUIS MIGUEL CONTRERAS MURILLO Cc: andrew.qu@mediatek.com; supa@ietf.org Subject: Re: [Supa] New Version Notification for draft-contreras-supa-yang-= network-topo-00.txt Luis, Thanks to you and Andrew for writing this. Very interesting and quite in li= ne with the conception of a multi-layer topology model I was myself trying = to express. A few questions: You limited the scope of the topology information to layer-3 and beneath. W= as it because you don't believe such a topology could be applicable at high= er levels? In my mind, such a generic topology model could apply to higher layers. For= example, a host-server relationship could be a very basic topology with a = link between two nodes. It would allow later on to define policies or param= eters on such a session/link. [Will] I agree with JF that we should not limit the scope of topology. Actu= ally, I think in the draft they did not limit the scope as I see words like= , "physical, data link and IP and can be extended to layer 4,5 and 7", "T= he model is also capable of depicting the topology at different layers", "= A network at any layer can contain multiple topologies. Each topology is c= aptured in its own list elements, distinguished via a topology ID." Howeve= r, I guess you have such an impression because in section 4, when they give= the detailed examples, they only write about l0-l3. IMHO, the advanced network functions (besides the basic routing and forward= ing functions) for added value services are mostly Layer4 to Layer7 based. = The Layer 4-7 network service function may include (not limited) firewalls,= WAN and application acceleration, Deep Packet Inspection (DPI), server loa= d balancers, NAT,TCP optimizer, etc. Some of them are designed and deployed= to enhance user experience, such as TCP or video optimization, content cat= ching and compression, while others apply actions to data packets, such as = Firewall, Policing (e.g. PCEF/PCRF), Mirroring, statistics collection based= on Layer 4-7 headers, etc. If an application need to control multiple serv= ice functions in network, it may need a topology for Layer 4-7 service func= tion nodes and connections (For example, a traffic steering application may= need to know the L4-L7 topology first. So it can tell network (including n= etwork service function nodes) how to steer a traffic). So, I propose to add following words in the end of page 4, below the senten= ce "ip means layer 3 topology ...": "TCP/UDP or other Layer 4-7 information" means layer 4-7 topology that swit= ch packets by Layer 4-7 information in packet or packet header." I also propose to add description like below(please note that they are jus= t examples and may need to be modified) into "module SUPA-topology": enum ip { value 4; description "L4"; } enum ip { value 5; description "L5"; } enum ip { value 6; description "L6"; } enum ip { value 7; description "L7"; } Another point: I do like the idea of hierarchizing the topologies, but I'm = not sure I understand it the way you described it. Reading the document, it= seemed at first that a parent topology would be a lower-abstraction (lower= -level) topology object. Topologies of different levels would be linked thr= ough a parent-children relationship. But then the text mentions "The parent= topology has a container node that maps a sub topology.", it sounds like y= ou're defining a topology embedded in a topology of the same layer. Do I ge= t this right? Both concepts are interesting, maybe a way could be found to = differentiate them in the text. The second one sounds more like a container= -contained relationship rather than parent-children. Also, could a topology be a parent to more than one higher-level topology? = I guess it does, but I haven't seen it clearly mentioned in the text. An ex= ample would be a single physical topology with several different logical to= pologies on top of it. Btw, you might want to take a look at http://tools.ietf.org/html/draft-edpr= op-opsawg-multi-layer-oam-ps-00. It describes a multi-layer OAM model. Not = exactly the same concepts, but it describes interesting ideas too. JF Tremblay Viagenie On Sep 18, 2014, at 3:54 AM, LUIS MIGUEL CONTRERAS MURILLO > wrote: Dear colleagues, Please note a new draft document addressing YANG modelling of network topol= ogy has been just uploaded. Any comment is more than welcome. Thanks Best regards Luis -----Mensaje original----- De: internet-drafts@ietf.org [mailto:inter= net-drafts@ietf.org] Enviado el: jueves, 18 de septiembre de 2014 9:48 Para: LUIS MIGUEL CONTRERAS MURILLO; Andrew Qu; LUIS MIGUEL CONTRERAS MURIL= LO; Andrew Qu Asunto: New Version Notification for draft-contreras-supa-yang-network-topo= -00.txt A new version of I-D, draft-contreras-supa-yang-network-topo-00.txt has been successfully submitted by Luis M. Contreras and posted to the IETF= repository. Name: draft-contreras-supa-yang-network-topo Revision: 00 Title: A YANG Data Model for Network Topologies Document date: 2014-09-18 Group: Individual Submission Pages: 23 URL: http://www.ietf.org/internet-drafts/draft-contreras-supa-ya= ng-network-topo-00.txt Status: https://datatracker.ietf.org/doc/draft-contreras-supa-yang-= network-topo/ Htmlized: http://tools.ietf.org/html/draft-contreras-supa-yang-networ= k-topo-00 Abstract: This document defines a YANG data model for network topologies. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat ________________________________ 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 _______________________________________________ Supa mailing list Supa@ietf.org https://www.ietf.org/mailman/listinfo/supa --_000_C9B5F12337F6F841B35C404CF0554ACB5FF944CESZXEMA509MBSchi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi JF,

 = ;

I read thi= s draft and have some comments to yours. Please see below in-line.

 = ;

Regards,

Will

 = ;

From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of JF Tremblay
Sent: Friday, September 19, 2014 4:24 AM
To: LUIS MIGUEL CONTRERAS MURILLO
Cc: andrew.qu@mediatek.com; supa@ietf.org
Subject: Re: [Supa] New Version Notification for draft-contreras-sup= a-yang-network-topo-00.txt

 

Luis, 

Thanks to you and Andrew for writing this. Very in= teresting and quite in line with the conception of a multi-layer topology m= odel I was myself trying to express.

 

A few questions: 

You limited the scope of the topology information = to layer-3 and beneath. Was it because you don’t believe such a topol= ogy could be applicable at higher levels? 

In my mind, such a generic topology model could ap= ply to higher layers. For example, a host-server relationship could be a ve= ry basic topology with a link between two nodes. It would allow later on to define policies or parameters on suc= h a session/link.  

 

[Will] = I agree with JF that we should not limit the scope of topology. Actually, I= think in the draft they did not limit the scope as I see words like, “physical, data link and IP and can be extended to =   layer 4,5 and 7”, “The model is also capable of depictin= g the  topology at different layers”, “A network at any la= yer can contain multiple topologies. Each  topology is captured in its= own list elements, distinguished via a  topology ID.” However, I guess y= ou have such an impression because in section 4, when they give the detaile= d examples, they only write about l0-l3.

&n= bsp;

IMHO, t= he advanced network functions (besides the basic routing and forwarding fun= ctions) for added value services are mostly Layer4 to Layer7 based. The Layer 4-7 network service function may include (not limited) fi= rewalls, WAN and application acceleration, Deep Packet Inspection (DPI), se= rver load balancers, NAT,TCP optimizer, etc. Some of them are designed and = deployed to enhance user experience, such as TCP or video optimization, content catching and compression, while= others apply actions to data packets, such as Firewall, Policing (e.g. PCE= F/PCRF), Mirroring, statistics collection based on Layer 4-7 headers, etc. = If an application need to control multiple service functions in network, it may need a topology for Layer 4-= 7 service function nodes and connections (For example, a traffic steering a= pplication may need to know the L4-L7 topology first. So it can tell networ= k (including network service function nodes) how to steer a traffic).

&n= bsp;

So, I p= ropose to add following words in the end of page 4, below the sentence “ip means layer 3 topology …”: <= /p>

"T= CP/UDP or other Layer 4-7 information" means layer 4-7 topology that s= witch packets by Layer 4-7 information in packet or packet header.”

&n= bsp;

I also&= nbsp; propose to add description like below(please note that they are just = examples and may need to be modified) into “module SUPA-topology̶= 1;:

enum ip {

         =       value 4;

         =       description "L4";

         =     }

         =     enum ip {

         =       value 5;

         =       description "L5";

         =     }

         =     enum ip {

         =       value 6;

         =       description "L6";

         =     }

         =     enum ip {

         =       value 7;

         =       description "L7";

 &= nbsp;           }

 = ;

  

Another point: I do like the idea of hierarchizing= the topologies, but I’m not sure I understand it the way you describ= ed it. Reading the document, it seemed at first that a parent topology would be a lower-abstraction (lower-level) topology= object. Topologies of different levels would be linked through a parent-ch= ildren relationship. But then the text mentions “The parent topology = has a container node that maps a sub topology.”, it sounds like you’re defining a topology embedded in a topology of = the same layer. Do I get this right? Both concepts are interesting, maybe a= way could be found to differentiate them in the text. The second one sound= s more like a container-contained relationship rather than parent-children. 

 

Also, could a topology be a parent to more than on= e higher-level topology? I guess it does, but I haven’t seen it clear= ly mentioned in the text. An example would be a single physical topology with several different logical topologies on to= p of it. 

 

Btw, you might want to take a look at h= ttp://tools.ietf.org/html/draft-edprop-opsawg-multi-layer-oam-ps-00. It describes a multi-layer OAM model. Not exactly the same concepts, but i= t describes interesting ideas too. 

 

JF Tremblay =

Viagenie

&nbs= p;

=  

 

On Sep 18, 2014, at 3:54 AM, LU= IS MIGUEL CONTRERAS MURILLO <luismiguel.contrerasmurillo@telefonica.com> wrote= :



Dear colleagues,

Please note a new draft document addressing YANG modelling of network topol= ogy has been just uploaded. Any comment is more than welcome.

Thanks

Best regards

Luis

-----Mensaje original-----
De: internet-drafts@ietf.org [mailto:internet-drafts@ietf.= org]
Enviado el: jueves, 18 de septiembre de 2014 9:48
Para: LUIS MIGUEL CONTRERAS MURILLO; Andrew Qu; LUIS MIGUEL CONTRERAS MURIL= LO; Andrew Qu
Asunto: New Version Notification for draft-contreras-supa-yang-network-topo= -00.txt


A new version of I-D, draft-contreras-supa-yang-network-topo-00.txt
has been successfully submitted by Luis M. Contreras and posted to the IETF= repository.

Name:           draft-con= treras-supa-yang-network-topo
Revision:       00
Title:          A YANG Data Mo= del for Network Topologies
Document date:  2014-09-18
Group:          Individual Sub= mission
Pages:          23
URL:            http://www.ietf.org/internet-drafts/draft-contreras-supa-yan= g-network-topo-00.txt
Status:         https://d= atatracker.ietf.org/doc/draft-contreras-supa-yang-network-topo/
Htmlized:       http://tools.ietf.org/h= tml/draft-contreras-supa-yang-network-topo-00


Abstract:
  This document defines a YANG data model for network topologies.=




Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


________________________________

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
_______________________________________________
Supa mailing list
Supa@ietf.org
https://www.ietf.org= /mailman/listinfo/supa

 

--_000_C9B5F12337F6F841B35C404CF0554ACB5FF944CESZXEMA509MBSchi_-- From nobody Mon Sep 22 05:13:13 2014 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4700C1A1AB9 for ; Mon, 22 Sep 2014 05:13:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.699 X-Spam-Level: X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, 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 VWUJkURRL2hW for ; Mon, 22 Sep 2014 05:13:07 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1AE91A1A97 for ; Mon, 22 Sep 2014 05:13:06 -0700 (PDT) Received: by mail-oi0-f42.google.com with SMTP id u20so3705127oif.29 for ; Mon, 22 Sep 2014 05:13:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mw+W/ZV39Bk8aGLfZv5GMf2ENEQGVSlLJxGfR/92Wl4=; b=HBI1eyTyO/atEpUGGDWEhbJlt6F6Lafzn2PiUVWvT2WFQQq5pzGVIZdSVERYhjutwz /9QizKnqYp1ut2yphCUHFplBr0CrBDOJnlxTPUkAdvSH1lijQhRsN906Jbqipr9V9BV4 A0NYtLJwmsc2+yOwWgyQN2Zyy6jERGxwOVEHn5xXJNxSdvQrtSs9I3exgUh41lVq9pDs zwFfo/TdstHFA8xFqoAA5F2QLn3C2LzSyVN9ai3AebFZ/ZE/2xrSuwLFRyviEQIcw6Js 2XkA7oXbR45sLSPuwSL7ok8hwbptr+K2ZywsLAMTUSHUFtdvdKMtY0WteCgLKShMvy+0 FX+g== MIME-Version: 1.0 X-Received: by 10.60.43.170 with SMTP id x10mr18809907oel.60.1411387986304; Mon, 22 Sep 2014 05:13:06 -0700 (PDT) Received: by 10.202.217.214 with HTTP; Mon, 22 Sep 2014 05:13:06 -0700 (PDT) In-Reply-To: References: <338BDC47F10D414AB0BC843C4D5DCFE085CE25@SJCEML701-CHM.china.huawei.com> Date: Mon, 22 Sep 2014 14:13:06 +0200 Message-ID: From: Zhen Cao To: Tina TSOU Content-Type: multipart/alternative; boundary=001a11330c949066a90503a65fee Archived-At: http://mailarchive.ietf.org/arch/msg/supa/oZAaRupsAqcJWMRL9Ql1joOZdpk Cc: "supa@ietf.org" Subject: Re: [Supa] Area hand-off, and some friendly advice ... X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 12:13:11 -0000 --001a11330c949066a90503a65fee Content-Type: text/plain; charset=UTF-8 Hello Tina and everybody, I have some comments about the scope of SUPA, as a newly coming reader. See the comments in line. Best regards, zhen > SUPA (Shared Unified Policy Automation) > > Target Area: OPS > > Description of Working Group: > > Network operators are faced with networks of increasing size and > complexity while trying to improve their quality and availability, as more > and more services depend on them. Programmatic ways to configure networks, > often called software-defined, are considered by many network operators in > order to shift the balance in their favor. > > Automation of configuration may provide significant improvements in > configuration agility, error detection and uptime for operators. However > the real value behind central configuration schemes lies within the > possible simplification through abstraction provided by such systems to > applications running above them (on the so-called northbound side). > Well-designed abstractions are able to provide a wide range of granularity > for various applications needs, from the lower-level physical network to > high-level application services. > > After the first two paragraph, I am really expecting a full introduction of SUPA, especially what the four-letter abbreviation means physically. > Although several organizations outside of the IETF have defined various > schemes for the configuration of network devices and specific network > controllers, none of them offer a vendor-neutral standardized way for > applications to transmit their needs to controllers. The SUPA (Shared > Unified Policy Automation) working group will work on the definition of > such as standardized interface for applications to communicate with network > controllers of all types. > > > The interface definitions will be based on the concept of network graph, > an entity describing an arbitrary topology of nodes and links at any level > of abstraction and granularity. > > 'Any level of abstraction' is very aggressive to me, good to you guys? What's the level of abstraction will the group focus on? > Such a graph may describe, for example, a physical topology, a L2 network, > a service topology or the relationships between datacenters. Although some > IETF working groups have started work relating to the description of > various topologies such as I2RS (L3 and routing topologies), ALTO (cost > maps), SFC (service chain), none of these groups aim at offering a truly > generic multi-layer and abstract topology for standard northbound > configuration. > > Work items for SUPA include: > > How about moving the easier items to the front, e.g. the problem statement and requirement. Normally these are the prerequisite for any chartered technical items, basic on which the definition/specification/choice making work can kick-off. Btw, the five items charter also seems aggressive too. > > 1) Choice of a modeling language used by the group to describe the network > graph. Existing modeling languages such as YANG will be considered for this > purpose unless no suitable one is found. > > 2) Choice of a transport protocol for the modeling language mentioned > above. The group will re-use a protocol already defined as a transport for > the modeling language, such as NETCONF or RESTCONF in the case of YANG. > > 3) The definition of a standardized model for a network topology graph. > This model may be used to describe topologies at any functional layer, from > physical networks to network services and higher abstractions. The nodes of > this graph may describe physical nodes as well as virtualized ones. > > 4) The definition and standardization of a number of basic abstracted > models using network graphs. These might include, but are not limited to, > L3VPNs, L2VPNs, datacenters, traffic engineering, implementation of IPv6 > transition mechanism and their enforcement to users. > > 5) Guidelines for the mapping of abstract model information to physical or > virtualized network components. > > Proposed milestones for the working group: > > - Produce a problem statement document for SUPA. > > - Produce a gap analysis for SUPA in order to verify overlap with the > work of other IETF groups. > > - Produce a requirement document describing the desired properties of an > abstract multi-layer network graph definition. > > - Produce a gap analysis of existing modeling language, their > characteristics, possible transport protocols and how they compare to the > SUPA requirements. > > - Produce a document specifying the model for a generic multi-layer > network graph. > > - Produce several documents describing different levels of abstract > views using the network graph model defined above, including physical view, > logical view, layer-3 view, configuration view, performance probing view, > service view and other such as L3VPN, L2VPN, datacenters and traffic > engineering. > > ------------ > > > * OPENv6, APONF and SUPA group historic perspective > ------------------------------------------------------------------------- > > Most IETF working groups are formed in the interest of solving some actual > real-world problem from network operators, developers or manufacturers and > the initial work from the OPENv6 group was no exception. Some operators saw > a common interest in defining a common approach for the deployment of IPv6 > transition tools. Although the preferred way of deploying IPv6 remains by > dual-stacking, several operators have deployed additional transition tools > such as 6RD (RFC5969), DS-Lite (RFC6333), NAT64 (RFC6146) and others with > the intent of speeding up or to provide more flexibility in their IPv6 > services. Each of these protocols presents its own set of deployment > challenges and failure modes for users, either because of unsupported > applications, partial implementations in some off-the-shelf devices such as > home routers or some limitations of the protocols themselves to name a few > cases. > > The fact these protocols are often deployed with techniques targeting the > extension of IPv4 service, such as Carrier Grade NAT, making their > deployment even more complex, especially when targeting minimal end-user > impact. Although some approaches in solving this were proposed, for example > in RFC6264, the market hasn't seen the advent of configurable CGN devices > or adaptive home gateways. The only solution for operators is to have an > agile way to provision rapidly and easily any type of IPv6 or IPv4 service > depending of the specific needs of each end-user and their device. These > changes must be performed with respect to the operator existing policies > regarding the network, billing, security and other constraints. > > While exploring these issues, it became clear the best way to address them > would be to use a central controller that would be able to coordinate the > deployment of different protocols amongst several devices in a consistent > fashion. Such a controller would receive high-level policy information from > a management application, transform it in network-level configuration and > apply it to physical or virtual devices. At that point, several other use > cases outside of the deployment of IPv6 started to emerge, for example for > the control of data center traffic steering, for the creation of tunnels > and the provisioning of L3VPN. The group decided to rename its activities > under the acronym APONF, for Application Policy on Network Functions, which > seemed a more fitting name. The definition of policies by a management > application toward a network controller would be at the center of the work > for the group. Several group documents were created around this concept. > > When presented at a bar bof during IETF-90 in Toronto, most of the > feedback was positive, but the scope of the work was often judged too large > in scope. It wasn't clear either how much overlap there was with other IETF > groups. A better analysis of this aspect in the following weeks revealed > some level of overlap with other groups, but also where deficiencies exist. > The two aspects where IETF work seems to be lacking are in the definition > of high-level policy language for applications and also in a standard model > to describe network topologies at different levels of granularity, or > abstraction. Some existing working groups have published work on the > latter. For example, the ALTO working group defined a way to describe > network functions at different level of granularity using cost maps, but > this approach does not seem practical for the description of complex > network topologies to and from a central controller. A topology draft > exists in the I2RS group, but it is very centered ! > around ro > uting protocols and L2-L3 links. > > The group has recently renamed its activities under the SUPA (Shared > Unified Policy Automation) acronym with the intention of defining a > standard way to push policies to a central controller. It appears, however, > that in order to define such policies, the definition of a standard > multi-layer model for the description of networks of all types would be > desirable. Therefore the initial work for the SUPA group would be to select > an existing modeling language and define a clear multi-layer model able to > describe network or service information at any level of granularity or > complexity. > -------------- > > > Thank you, > Tina > > -----Original Message----- > From: Supa [mailto:supa-bounces@ietf.org ] On > Behalf Of Spencer Dawkins > Sent: Friday, September 12, 2014 9:42 AM > To: supa@ietf.org > Cc: Benoit Claise > Subject: [Supa] Area hand-off, and some friendly advice ... > > Dear SUPA friends, > > Several IESG members had a chat earlier this week, and decided that SUPA > really belongs in OPS. I've requested that the area affiliation in > http://www.ietf.org/list/nonwg.html be updated to reflect that. > > Benoit will be your AD for additional charter discussion. > > If I might offer some friendly advice, several ADs are fairly confused > about the relationship between openv6, APONF, and SUPA. If you could put > together a short paragraph that's something like "we started openv6 to do > X, then we realized we needed to do Y so we proposed APONF, and after > discussions in Toronto, we chose a different direction with SUPA because of > Z", that would be very helpful. > > I also have a request from Benoit (and Adrian, and Joel) to make the > description at https://www.ietf.org/mailman/listinfo/supa more > understandable for people who haven't been following the work - if you > intend to charter a working group, you'll want people to understand what > you're proposing. > > You should probably keep in mind that people who talk over a long period > of time are likely to develop a shared understanding that people who > weren't involved don't understand clearly. If there's a smart newcomer who > could look over problem statements, proposed charters and see what's not > clear to newcomers, that would likely be helpful as well. > > Thanks, and best wishes. I'll see you in the hallways of Honolulu, where > all ADs lurk sooner or later ... > > Spencer > > --001a11330c949066a90503a65fee Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Tina and everybody,=C2=A0

I have = some comments about the scope of SUPA, as a newly coming reader.=C2=A0 See = the comments in line.=C2=A0

Best regards,
zhen

SUPA (Shared Unified Policy A= utomation)

Target Area: OPS

Description of Working Group:

Network operators are faced with networks of increasing size and complexity= while trying to improve their quality and availability, as more and more s= ervices depend on them. Programmatic ways to configure networks, often =C2= =A0called software-defined, are considered by many network operators in order to shift the balance in their favor.
Automation of configuration may provide significant improvements in configu= ration agility, error detection and uptime for operators. However the real = value behind central configuration schemes lies within the possible simplif= ication through abstraction provided by such systems to applications running above them (on the so-called north= bound side). Well-designed abstractions are able to provide a wide range of= granularity for various applications needs, from the lower-level physical = network to high-level application services.

<= /blockquote>

After the first two paragraph, I am really = expecting a full introduction of SUPA, especially what the four-letter abbr= eviation means physically. =C2=A0
=C2=A0

Although several organizations outside of the IETF have defined various sch= emes for the configuration of network devices and specific network controll= ers, none of them offer a vendor-neutral standardized way for applications = to transmit their needs to controllers. The SUPA (Shared Unified Policy Automation) working group will work on the= definition of such as standardized interface for applications to communica= te with network controllers of all types.=C2=A0


The interface definitions will be based on the concept of network graph, an= entity describing an arbitrary topology of nodes and links at any level of= abstraction and granularity.

'Any level of abstraction' is very= aggressive to me, good to you guys?=C2=A0 What's the level of abstract= ion will the group focus on?
=C2=A0

Such = a graph may describe, for example, a physical topology, a L2 network, a service topology or the relationships between datacenters. Although some I= ETF working groups have started work relating to the description of various= topologies such as I2RS (L3 and routing topologies), ALTO (cost maps), SFC= (service chain), none of these groups aim at offering a truly generic multi-layer and abstract topology f= or standard northbound configuration.

Work items for SUPA include:


How about moving the easi= er items to the front, e.g. the problem statement and requirement. Normally= these are the prerequisite for any chartered technical items, basic on whi= ch the definition/specification/choice making work can kick-off.=C2=A0 Btw,= the five items charter also seems aggressive too.=C2=A0
=C2=A0


1) Choice of a modeling language used by the group to describe the network = graph. Existing modeling languages such as YANG will be considered for this= purpose unless no suitable one is found.

2) Choice of a transport protocol for the modeling language mentioned above= . The group will re-use a protocol already defined as a transport for the m= odeling language, such as NETCONF or RESTCONF in the case of YANG.

3) The definition of a standardized model for a network topology graph. Thi= s model may be used to describe topologies at any functional layer, from ph= ysical networks to network services and higher abstractions. The nodes of t= his graph may describe physical nodes as well as virtualized ones.

4) The definition and standardization of a number of basic abstracted model= s using network graphs. These might include, but are not limited to, L3VPNs= , L2VPNs, datacenters, traffic engineering, implementation of IPv6 transiti= on mechanism and their enforcement to users. =C2=A0

5) Guidelines for the mapping of abstract model information to physical or = virtualized network components. =C2=A0

Proposed milestones for the working group:

- =C2=A0=C2=A0Produce a problem statement document for SUPA.

- =C2=A0=C2=A0Produce a gap analysis for SUPA in order to verify overlap wi= th the work of other IETF groups.

- =C2=A0=C2=A0Produce a requirement document describing the desired propert= ies of an abstract multi-layer network graph definition.

- =C2=A0=C2=A0Produce a gap analysis of existing modeling language, their c= haracteristics, possible transport protocols and how they compare to the SU= PA requirements.

- =C2=A0=C2=A0Produce a document specifying the model for a generic multi-l= ayer network graph.

- =C2=A0=C2=A0Produce several documents describing different levels of abst= ract views using the network graph model defined above, including physical = view, logical view, layer-3 view, configuration view, performance probing v= iew, service view and other such as L3VPN, L2VPN, datacenters and traffic engineering. =C2=A0

------------


* OPENv6, APONF and SUPA group historic perspective
-------------------------------------------------------------------------
Most IETF working groups are formed in the interest of solving some actual = real-world problem from network operators, developers or manufacturers and = the initial work from the OPENv6 group was no exception. Some operators saw= a common interest in defining a common approach for the deployment of IPv6 transition tools. Although the = preferred way of deploying IPv6 remains by dual-stacking, several operators= have deployed additional transition tools such as 6RD (RFC5969), DS-Lite (= RFC6333), NAT64 (RFC6146) and others with the intent of speeding up or to provide more flexibility in their IPv= 6 services. Each of these protocols presents its own set of deployment chal= lenges and failure modes for users, either because of unsupported applicati= ons, partial implementations in some off-the-shelf devices such as home routers or some limitations of the= protocols themselves to name a few cases.

The fact these protocols are often deployed with techniques targeting the e= xtension of IPv4 service, such as Carrier Grade NAT, making their deploymen= t even more complex, especially when targeting minimal end-user impact. Alt= hough some approaches in solving this were proposed, for example in RFC6264, the market hasn't seen the= advent of configurable CGN devices or adaptive home gateways. The only sol= ution for operators is to have an agile way to provision rapidly and easily= any type of IPv6 or IPv4 service depending of the specific needs of each end-user and their device. These changes mus= t be performed with respect to the operator existing policies regarding the= network, billing, security and other constraints.

While exploring these issues, it became clear the best way to address them = would be to use a central controller that would be able to coordinate the d= eployment of different protocols amongst several devices in a consistent fa= shion. Such a controller would receive high-level policy information from a management application, transform it = in network-level configuration and apply it to physical or virtual devices.= At that point, several other use cases outside of the deployment of IPv6 s= tarted to emerge, for example for the control of data center traffic steering, for the creation of tunnels a= nd the provisioning of L3VPN. The group decided to rename its activities un= der the acronym APONF, for Application Policy on Network Functions, which s= eemed a more fitting name. The definition of policies by a management application toward a network controller would = be at the center of the work for the group. Several group documents were cr= eated around this concept.

When presented at a bar bof during IETF-90 in Toronto, most of the feedback= was positive, but the scope of the work was often judged too large in scop= e. It wasn't clear either how much overlap there was with other IETF gr= oups. A better analysis of this aspect in the following weeks revealed some level of overlap with other groups, b= ut also where deficiencies exist. The two aspects where IETF work seems to = be lacking are in the definition of high-level policy language for applicat= ions and also in a standard model to describe network topologies at different levels of granularity, or abst= raction. Some existing working groups have published work on the latter. Fo= r example, the ALTO working group defined a way to describe network functio= ns at different level of granularity using cost maps, but this approach does not seem practical for the descrip= tion of complex network topologies to and from a central controller. A topo= logy draft exists in the I2RS group, but it is very centered !
around ro
uting protocols and L2-L3 links.

The group has recently renamed its activities under the SUPA (Shared Unifie= d Policy Automation) acronym with the intention of defining a standard way = to push policies to a central controller. It appears, however, that in orde= r to define such policies, the definition of a standard multi-layer model for the description of networks of all typ= es would be desirable. Therefore the initial work for the SUPA group would = be to select an existing modeling language and define a clear multi-layer m= odel able to describe network or service information at any level of granularity or complexity.
--------------


Thank you,
Tina

-----Original Message-----
From: Supa [mail= to:supa-bounces@ietf.org] On Behalf Of Spencer Dawkins
Sent: Friday, September 12, 2014 9:42 AM
To: supa@ietf.org Cc: Benoit Claise
Subject: [Supa] Area hand-off, and some friendly advice ...

Dear SUPA friends,

Several IESG members had a chat earlier this week, and decided that SUPA re= ally belongs in OPS. I've requested that the area affiliation in http://ww= w.ietf.org/list/nonwg.html be updated to reflect that.

Benoit will be your AD for additional charter discussion.

If I might offer some friendly advice, several ADs are fairly confused abou= t the relationship between openv6, APONF, and SUPA. If you could put togeth= er a short paragraph that's something like "we started openv6 to d= o X, then we realized we needed to do Y so we proposed APONF, and after discussions in Toronto, we chose a different = direction with SUPA because of Z", that would be very helpful.

I also have a request from Benoit (and Adrian, and Joel) to make the descri= ption at ht= tps://www.ietf.org/mailman/listinfo/supa more understandable for people= who haven't been following the work - if you intend to charter a worki= ng group, you'll want people to understand what you're proposing.
You should probably keep in mind that people who talk over a long period of= time are likely to develop a shared understanding that people who weren= 9;t involved don't understand clearly. If there's a smart newcomer = who could look over problem statements, proposed charters and see what's not clear to newcomers, that would likely be h= elpful as well.

Thanks, and best wishes. I'll see you in the hallways of Honolulu, wher= e all ADs lurk sooner or later ...

Spencer


--001a11330c949066a90503a65fee-- From nobody Mon Sep 22 06:27:30 2014 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE5BE1A1ADD for ; Mon, 22 Sep 2014 06:27:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.386 X-Spam-Level: X-Spam-Status: No, score=-6.386 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 jWmbsc9CMS02 for ; Mon, 22 Sep 2014 06:27: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 511361A1ADF for ; Mon, 22 Sep 2014 06:27:18 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BMW49283; Mon, 22 Sep 2014 13:27:16 +0000 (GMT) Received: from LHREML516-MBX.china.huawei.com ([169.254.1.85]) by lhreml405-hub.china.huawei.com ([10.201.5.242]) with mapi id 14.03.0158.001; Mon, 22 Sep 2014 14:27:09 +0100 From: Georgios Karagiannis To: Zhen Cao , Tina TSOU Thread-Topic: [Supa] Area hand-off, and some friendly advice ... Thread-Index: AQHPzqh9Us1IwolkWUGUssV+Mn5WLpwFfqEggAAWG8mAAKjywIAG0V4AgAAYJ7A= Date: Mon, 22 Sep 2014 13:27:08 +0000 Message-ID: References: <338BDC47F10D414AB0BC843C4D5DCFE085CE25@SJCEML701-CHM.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.64.41] Content-Type: multipart/alternative; boundary="_000_C5034E44CD620A44971BAAEB372655DC635757LHREML516MBXchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/supa/DVXYLs6EMXy9GLp8nQ6K4Bm-t7s Cc: "supa@ietf.org" Subject: Re: [Supa] Area hand-off, and some friendly advice ... X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 13:27:28 -0000 --_000_C5034E44CD620A44971BAAEB372655DC635757LHREML516MBXchina_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgWmhlbiwNCg0KVGhhbmsgeW91IHZlcnkgbXVjaCBmb3IgdGhlIGNvbW1lbnRzLg0KDQpJbiB0 aGUgbmV4dCB2ZXJzaW9uIG9mIHRoZSBjaGFydGVyLCB3ZSB3aWxsOg0KbykgZW1waGFzaXplIHRo ZSBtYWluIGdvYWwgb2YgU1VQQToNCg0KICAgVGhlIG1haW4gZ29hbCBvZiBTVVBBIGlzIHRvIHBy b3ZpZGUgYSB3YXkgZm9yIGFwcGxpY2F0aW9ucyB0byBzcGVjaWZ5DQogICBwb2xpY2llcyB0byB0 aGUgbmV0d29yayBpbmZyYXN0cnVjdHVyZSB1c2luZyBhIHNpbXBsaWZpZWQgdmlldyBvZg0KICAg bmV0d29yay4gVGhpcyBjYW4gYmUgcmVhbGl6ZWQgYnk6ICgxKSBtb2RlbGluZyB0aGUgbmV0d29y aw0KICAgaW5mcmFzdHJ1Y3R1cmUgYXMgYW4gc2ltcGxpZmllZCBuZXR3b3JrIGdyYXBoIHVzaW5n IGEgbW9kZWxpbmcNCiAgIGxhbmd1YWdlIHN1Y2ggYXMgWUFORyAoMikgdHJhbnNwb3J0aW5nIG1v ZGVsDQogICBpbnN0YW5jZXMgZWl0aGVyIHVzaW5nIE5FVENPTkYgb3IgUkVTVENPTkYgYW5kICgz KSBwcm92aWRpbmcgZ3VpZGVsaW5lcyBvbg0KICAgbWFwcGluZyBwb2xpY2llcyB0byBhdHRyaWJ1 dGVzIG9mIHRoZSBuZXR3b3JrIGdyYXBocy4NCg0KbykgZW1waGFzaXplIHRoYXQgYXMgc3RhcnRp bmcgcG9pbnQsIGZvciBhcHBsaWNhdGlvbnMsIHdlIHdpbGwgZm9jdXMgb25seSBvbiBuZXR3b3Jr IHNlcnZpY2VzDQoNCm8pIGVtcGhhc2l6ZSB0aGF0IHdlIHdpbGwgZm9jdXMgb24gcG9saWN5IGFu ZCBkYXRhIG1vZGVscyB0aGF0IGFyZSBhYmxlIHRvIHByb3ZpZGUgZW5vdWdoIGRldGFpbHMgb24g dGhlIHVzZWQgbmV0d29yayBhbmQgc2VydmljZSB0b3BvbG9neS4NCg0KbykgZW1waGFzaXplIHRo YXQgcmVnYXJkaW5nIHBvbGljeSwgZW5oYW5jZW1lbnRzIG9mIHRoZSBZQU5HIHhQYXRoIGV4cHJl c3Npb24gbWlnaHQgYmUgcmVxdWlyZWQuDQoNCkJlc3QgcmVnYXJkcywNCkdlb3JnaW9zDQoNCg0K DQpGcm9tOiBTdXBhIFttYWlsdG86c3VwYS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg WmhlbiBDYW8NClNlbnQ6IE1vbmRheSwgU2VwdGVtYmVyIDIyLCAyMDE0IDI6MTMgUE0NClRvOiBU aW5hIFRTT1UNCkNjOiBzdXBhQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW1N1cGFdIEFyZWEgaGFu ZC1vZmYsIGFuZCBzb21lIGZyaWVuZGx5IGFkdmljZSAuLi4NCg0KSGVsbG8gVGluYSBhbmQgZXZl cnlib2R5LA0KDQpJIGhhdmUgc29tZSBjb21tZW50cyBhYm91dCB0aGUgc2NvcGUgb2YgU1VQQSwg YXMgYSBuZXdseSBjb21pbmcgcmVhZGVyLiAgU2VlIHRoZSBjb21tZW50cyBpbiBsaW5lLg0KDQpC ZXN0IHJlZ2FyZHMsDQp6aGVuDQpTVVBBIChTaGFyZWQgVW5pZmllZCBQb2xpY3kgQXV0b21hdGlv bikNClRhcmdldCBBcmVhOiBPUFMNCg0KRGVzY3JpcHRpb24gb2YgV29ya2luZyBHcm91cDoNCg0K TmV0d29yayBvcGVyYXRvcnMgYXJlIGZhY2VkIHdpdGggbmV0d29ya3Mgb2YgaW5jcmVhc2luZyBz aXplIGFuZCBjb21wbGV4aXR5IHdoaWxlIHRyeWluZyB0byBpbXByb3ZlIHRoZWlyIHF1YWxpdHkg YW5kIGF2YWlsYWJpbGl0eSwgYXMgbW9yZSBhbmQgbW9yZSBzZXJ2aWNlcyBkZXBlbmQgb24gdGhl bS4gUHJvZ3JhbW1hdGljIHdheXMgdG8gY29uZmlndXJlIG5ldHdvcmtzLCBvZnRlbiAgY2FsbGVk IHNvZnR3YXJlLWRlZmluZWQsIGFyZSBjb25zaWRlcmVkIGJ5IG1hbnkgbmV0d29yayBvcGVyYXRv cnMgaW4gb3JkZXIgdG8gc2hpZnQgdGhlIGJhbGFuY2UgaW4gdGhlaXIgZmF2b3IuDQoNCkF1dG9t YXRpb24gb2YgY29uZmlndXJhdGlvbiBtYXkgcHJvdmlkZSBzaWduaWZpY2FudCBpbXByb3ZlbWVu dHMgaW4gY29uZmlndXJhdGlvbiBhZ2lsaXR5LCBlcnJvciBkZXRlY3Rpb24gYW5kIHVwdGltZSBm b3Igb3BlcmF0b3JzLiBIb3dldmVyIHRoZSByZWFsIHZhbHVlIGJlaGluZCBjZW50cmFsIGNvbmZp Z3VyYXRpb24gc2NoZW1lcyBsaWVzIHdpdGhpbiB0aGUgcG9zc2libGUgc2ltcGxpZmljYXRpb24g dGhyb3VnaCBhYnN0cmFjdGlvbiBwcm92aWRlZCBieSBzdWNoIHN5c3RlbXMgdG8gYXBwbGljYXRp b25zIHJ1bm5pbmcgYWJvdmUgdGhlbSAob24gdGhlIHNvLWNhbGxlZCBub3J0aGJvdW5kIHNpZGUp LiBXZWxsLWRlc2lnbmVkIGFic3RyYWN0aW9ucyBhcmUgYWJsZSB0byBwcm92aWRlIGEgd2lkZSBy YW5nZSBvZiBncmFudWxhcml0eSBmb3IgdmFyaW91cyBhcHBsaWNhdGlvbnMgbmVlZHMsIGZyb20g dGhlIGxvd2VyLWxldmVsIHBoeXNpY2FsIG5ldHdvcmsgdG8gaGlnaC1sZXZlbCBhcHBsaWNhdGlv biBzZXJ2aWNlcy4NCg0KQWZ0ZXIgdGhlIGZpcnN0IHR3byBwYXJhZ3JhcGgsIEkgYW0gcmVhbGx5 IGV4cGVjdGluZyBhIGZ1bGwgaW50cm9kdWN0aW9uIG9mIFNVUEEsIGVzcGVjaWFsbHkgd2hhdCB0 aGUgZm91ci1sZXR0ZXIgYWJicmV2aWF0aW9uIG1lYW5zIHBoeXNpY2FsbHkuDQoNCkFsdGhvdWdo IHNldmVyYWwgb3JnYW5pemF0aW9ucyBvdXRzaWRlIG9mIHRoZSBJRVRGIGhhdmUgZGVmaW5lZCB2 YXJpb3VzIHNjaGVtZXMgZm9yIHRoZSBjb25maWd1cmF0aW9uIG9mIG5ldHdvcmsgZGV2aWNlcyBh bmQgc3BlY2lmaWMgbmV0d29yayBjb250cm9sbGVycywgbm9uZSBvZiB0aGVtIG9mZmVyIGEgdmVu ZG9yLW5ldXRyYWwgc3RhbmRhcmRpemVkIHdheSBmb3IgYXBwbGljYXRpb25zIHRvIHRyYW5zbWl0 IHRoZWlyIG5lZWRzIHRvIGNvbnRyb2xsZXJzLiBUaGUgU1VQQSAoU2hhcmVkIFVuaWZpZWQgUG9s aWN5IEF1dG9tYXRpb24pIHdvcmtpbmcgZ3JvdXAgd2lsbCB3b3JrIG9uIHRoZSBkZWZpbml0aW9u IG9mIHN1Y2ggYXMgc3RhbmRhcmRpemVkIGludGVyZmFjZSBmb3IgYXBwbGljYXRpb25zIHRvIGNv bW11bmljYXRlIHdpdGggbmV0d29yayBjb250cm9sbGVycyBvZiBhbGwgdHlwZXMuDQoNClRoZSBp bnRlcmZhY2UgZGVmaW5pdGlvbnMgd2lsbCBiZSBiYXNlZCBvbiB0aGUgY29uY2VwdCBvZiBuZXR3 b3JrIGdyYXBoLCBhbiBlbnRpdHkgZGVzY3JpYmluZyBhbiBhcmJpdHJhcnkgdG9wb2xvZ3kgb2Yg bm9kZXMgYW5kIGxpbmtzIGF0IGFueSBsZXZlbCBvZiBhYnN0cmFjdGlvbiBhbmQgZ3JhbnVsYXJp dHkuDQonQW55IGxldmVsIG9mIGFic3RyYWN0aW9uJyBpcyB2ZXJ5IGFnZ3Jlc3NpdmUgdG8gbWUs IGdvb2QgdG8geW91IGd1eXM/ICBXaGF0J3MgdGhlIGxldmVsIG9mIGFic3RyYWN0aW9uIHdpbGwg dGhlIGdyb3VwIGZvY3VzIG9uPw0KDQpTdWNoIGEgZ3JhcGggbWF5IGRlc2NyaWJlLCBmb3IgZXhh bXBsZSwgYSBwaHlzaWNhbCB0b3BvbG9neSwgYSBMMiBuZXR3b3JrLCBhIHNlcnZpY2UgdG9wb2xv Z3kgb3IgdGhlIHJlbGF0aW9uc2hpcHMgYmV0d2VlbiBkYXRhY2VudGVycy4gQWx0aG91Z2ggc29t ZSBJRVRGIHdvcmtpbmcgZ3JvdXBzIGhhdmUgc3RhcnRlZCB3b3JrIHJlbGF0aW5nIHRvIHRoZSBk ZXNjcmlwdGlvbiBvZiB2YXJpb3VzIHRvcG9sb2dpZXMgc3VjaCBhcyBJMlJTIChMMyBhbmQgcm91 dGluZyB0b3BvbG9naWVzKSwgQUxUTyAoY29zdCBtYXBzKSwgU0ZDIChzZXJ2aWNlIGNoYWluKSwg bm9uZSBvZiB0aGVzZSBncm91cHMgYWltIGF0IG9mZmVyaW5nIGEgdHJ1bHkgZ2VuZXJpYyBtdWx0 aS1sYXllciBhbmQgYWJzdHJhY3QgdG9wb2xvZ3kgZm9yIHN0YW5kYXJkIG5vcnRoYm91bmQgY29u ZmlndXJhdGlvbi4NCg0KV29yayBpdGVtcyBmb3IgU1VQQSBpbmNsdWRlOg0KDQpIb3cgYWJvdXQg bW92aW5nIHRoZSBlYXNpZXIgaXRlbXMgdG8gdGhlIGZyb250LCBlLmcuIHRoZSBwcm9ibGVtIHN0 YXRlbWVudCBhbmQgcmVxdWlyZW1lbnQuIE5vcm1hbGx5IHRoZXNlIGFyZSB0aGUgcHJlcmVxdWlz aXRlIGZvciBhbnkgY2hhcnRlcmVkIHRlY2huaWNhbCBpdGVtcywgYmFzaWMgb24gd2hpY2ggdGhl IGRlZmluaXRpb24vc3BlY2lmaWNhdGlvbi9jaG9pY2UgbWFraW5nIHdvcmsgY2FuIGtpY2stb2Zm LiAgQnR3LCB0aGUgZml2ZSBpdGVtcyBjaGFydGVyIGFsc28gc2VlbXMgYWdncmVzc2l2ZSB0b28u DQoNCg0KMSkgQ2hvaWNlIG9mIGEgbW9kZWxpbmcgbGFuZ3VhZ2UgdXNlZCBieSB0aGUgZ3JvdXAg dG8gZGVzY3JpYmUgdGhlIG5ldHdvcmsgZ3JhcGguIEV4aXN0aW5nIG1vZGVsaW5nIGxhbmd1YWdl cyBzdWNoIGFzIFlBTkcgd2lsbCBiZSBjb25zaWRlcmVkIGZvciB0aGlzIHB1cnBvc2UgdW5sZXNz IG5vIHN1aXRhYmxlIG9uZSBpcyBmb3VuZC4NCg0KMikgQ2hvaWNlIG9mIGEgdHJhbnNwb3J0IHBy b3RvY29sIGZvciB0aGUgbW9kZWxpbmcgbGFuZ3VhZ2UgbWVudGlvbmVkIGFib3ZlLiBUaGUgZ3Jv dXAgd2lsbCByZS11c2UgYSBwcm90b2NvbCBhbHJlYWR5IGRlZmluZWQgYXMgYSB0cmFuc3BvcnQg Zm9yIHRoZSBtb2RlbGluZyBsYW5ndWFnZSwgc3VjaCBhcyBORVRDT05GIG9yIFJFU1RDT05GIGlu IHRoZSBjYXNlIG9mIFlBTkcuDQoNCjMpIFRoZSBkZWZpbml0aW9uIG9mIGEgc3RhbmRhcmRpemVk IG1vZGVsIGZvciBhIG5ldHdvcmsgdG9wb2xvZ3kgZ3JhcGguIFRoaXMgbW9kZWwgbWF5IGJlIHVz ZWQgdG8gZGVzY3JpYmUgdG9wb2xvZ2llcyBhdCBhbnkgZnVuY3Rpb25hbCBsYXllciwgZnJvbSBw aHlzaWNhbCBuZXR3b3JrcyB0byBuZXR3b3JrIHNlcnZpY2VzIGFuZCBoaWdoZXIgYWJzdHJhY3Rp b25zLiBUaGUgbm9kZXMgb2YgdGhpcyBncmFwaCBtYXkgZGVzY3JpYmUgcGh5c2ljYWwgbm9kZXMg YXMgd2VsbCBhcyB2aXJ0dWFsaXplZCBvbmVzLg0KDQo0KSBUaGUgZGVmaW5pdGlvbiBhbmQgc3Rh bmRhcmRpemF0aW9uIG9mIGEgbnVtYmVyIG9mIGJhc2ljIGFic3RyYWN0ZWQgbW9kZWxzIHVzaW5n IG5ldHdvcmsgZ3JhcGhzLiBUaGVzZSBtaWdodCBpbmNsdWRlLCBidXQgYXJlIG5vdCBsaW1pdGVk IHRvLCBMM1ZQTnMsIEwyVlBOcywgZGF0YWNlbnRlcnMsIHRyYWZmaWMgZW5naW5lZXJpbmcsIGlt cGxlbWVudGF0aW9uIG9mIElQdjYgdHJhbnNpdGlvbiBtZWNoYW5pc20gYW5kIHRoZWlyIGVuZm9y Y2VtZW50IHRvIHVzZXJzLg0KDQo1KSBHdWlkZWxpbmVzIGZvciB0aGUgbWFwcGluZyBvZiBhYnN0 cmFjdCBtb2RlbCBpbmZvcm1hdGlvbiB0byBwaHlzaWNhbCBvciB2aXJ0dWFsaXplZCBuZXR3b3Jr IGNvbXBvbmVudHMuDQoNClByb3Bvc2VkIG1pbGVzdG9uZXMgZm9yIHRoZSB3b3JraW5nIGdyb3Vw Og0KDQotICAgUHJvZHVjZSBhIHByb2JsZW0gc3RhdGVtZW50IGRvY3VtZW50IGZvciBTVVBBLg0K DQotICAgUHJvZHVjZSBhIGdhcCBhbmFseXNpcyBmb3IgU1VQQSBpbiBvcmRlciB0byB2ZXJpZnkg b3ZlcmxhcCB3aXRoIHRoZSB3b3JrIG9mIG90aGVyIElFVEYgZ3JvdXBzLg0KDQotICAgUHJvZHVj ZSBhIHJlcXVpcmVtZW50IGRvY3VtZW50IGRlc2NyaWJpbmcgdGhlIGRlc2lyZWQgcHJvcGVydGll cyBvZiBhbiBhYnN0cmFjdCBtdWx0aS1sYXllciBuZXR3b3JrIGdyYXBoIGRlZmluaXRpb24uDQoN Ci0gICBQcm9kdWNlIGEgZ2FwIGFuYWx5c2lzIG9mIGV4aXN0aW5nIG1vZGVsaW5nIGxhbmd1YWdl LCB0aGVpciBjaGFyYWN0ZXJpc3RpY3MsIHBvc3NpYmxlIHRyYW5zcG9ydCBwcm90b2NvbHMgYW5k IGhvdyB0aGV5IGNvbXBhcmUgdG8gdGhlIFNVUEEgcmVxdWlyZW1lbnRzLg0KDQotICAgUHJvZHVj ZSBhIGRvY3VtZW50IHNwZWNpZnlpbmcgdGhlIG1vZGVsIGZvciBhIGdlbmVyaWMgbXVsdGktbGF5 ZXIgbmV0d29yayBncmFwaC4NCg0KLSAgIFByb2R1Y2Ugc2V2ZXJhbCBkb2N1bWVudHMgZGVzY3Jp YmluZyBkaWZmZXJlbnQgbGV2ZWxzIG9mIGFic3RyYWN0IHZpZXdzIHVzaW5nIHRoZSBuZXR3b3Jr IGdyYXBoIG1vZGVsIGRlZmluZWQgYWJvdmUsIGluY2x1ZGluZyBwaHlzaWNhbCB2aWV3LCBsb2dp Y2FsIHZpZXcsIGxheWVyLTMgdmlldywgY29uZmlndXJhdGlvbiB2aWV3LCBwZXJmb3JtYW5jZSBw cm9iaW5nIHZpZXcsIHNlcnZpY2UgdmlldyBhbmQgb3RoZXIgc3VjaCBhcyBMM1ZQTiwgTDJWUE4s IGRhdGFjZW50ZXJzIGFuZCB0cmFmZmljIGVuZ2luZWVyaW5nLg0KDQotLS0tLS0tLS0tLS0NCg0K DQoqIE9QRU52NiwgQVBPTkYgYW5kIFNVUEEgZ3JvdXAgaGlzdG9yaWMgcGVyc3BlY3RpdmUNCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCg0KTW9zdCBJRVRGIHdvcmtpbmcgZ3JvdXBzIGFyZSBmb3JtZWQgaW4g dGhlIGludGVyZXN0IG9mIHNvbHZpbmcgc29tZSBhY3R1YWwgcmVhbC13b3JsZCBwcm9ibGVtIGZy b20gbmV0d29yayBvcGVyYXRvcnMsIGRldmVsb3BlcnMgb3IgbWFudWZhY3R1cmVycyBhbmQgdGhl IGluaXRpYWwgd29yayBmcm9tIHRoZSBPUEVOdjYgZ3JvdXAgd2FzIG5vIGV4Y2VwdGlvbi4gU29t ZSBvcGVyYXRvcnMgc2F3IGEgY29tbW9uIGludGVyZXN0IGluIGRlZmluaW5nIGEgY29tbW9uIGFw cHJvYWNoIGZvciB0aGUgZGVwbG95bWVudCBvZiBJUHY2IHRyYW5zaXRpb24gdG9vbHMuIEFsdGhv dWdoIHRoZSBwcmVmZXJyZWQgd2F5IG9mIGRlcGxveWluZyBJUHY2IHJlbWFpbnMgYnkgZHVhbC1z dGFja2luZywgc2V2ZXJhbCBvcGVyYXRvcnMgaGF2ZSBkZXBsb3llZCBhZGRpdGlvbmFsIHRyYW5z aXRpb24gdG9vbHMgc3VjaCBhcyA2UkQgKFJGQzU5NjkpLCBEUy1MaXRlIChSRkM2MzMzKSwgTkFU NjQgKFJGQzYxNDYpIGFuZCBvdGhlcnMgd2l0aCB0aGUgaW50ZW50IG9mIHNwZWVkaW5nIHVwIG9y IHRvIHByb3ZpZGUgbW9yZSBmbGV4aWJpbGl0eSBpbiB0aGVpciBJUHY2IHNlcnZpY2VzLiBFYWNo IG9mIHRoZXNlIHByb3RvY29scyBwcmVzZW50cyBpdHMgb3duIHNldCBvZiBkZXBsb3ltZW50IGNo YWxsZW5nZXMgYW5kIGZhaWx1cmUgbW9kZXMgZm9yIHVzZXJzLCBlaXRoZXIgYmVjYXVzZSBvZiB1 bnN1cHBvcnRlZCBhcHBsaWNhdGlvbnMsIHBhcnRpYWwgaW1wbGVtZW50YXRpb25zIGluIHNvbWUg b2ZmLXRoZS1zaGVsZiBkZXZpY2VzIHN1Y2ggYXMgaG9tZSByb3V0ZXJzIG9yIHNvbWUgbGltaXRh dGlvbnMgb2YgdGhlIHByb3RvY29scyB0aGVtc2VsdmVzIHRvIG5hbWUgYSBmZXcgY2FzZXMuDQoN ClRoZSBmYWN0IHRoZXNlIHByb3RvY29scyBhcmUgb2Z0ZW4gZGVwbG95ZWQgd2l0aCB0ZWNobmlx dWVzIHRhcmdldGluZyB0aGUgZXh0ZW5zaW9uIG9mIElQdjQgc2VydmljZSwgc3VjaCBhcyBDYXJy aWVyIEdyYWRlIE5BVCwgbWFraW5nIHRoZWlyIGRlcGxveW1lbnQgZXZlbiBtb3JlIGNvbXBsZXgs IGVzcGVjaWFsbHkgd2hlbiB0YXJnZXRpbmcgbWluaW1hbCBlbmQtdXNlciBpbXBhY3QuIEFsdGhv dWdoIHNvbWUgYXBwcm9hY2hlcyBpbiBzb2x2aW5nIHRoaXMgd2VyZSBwcm9wb3NlZCwgZm9yIGV4 YW1wbGUgaW4gUkZDNjI2NCwgdGhlIG1hcmtldCBoYXNuJ3Qgc2VlbiB0aGUgYWR2ZW50IG9mIGNv bmZpZ3VyYWJsZSBDR04gZGV2aWNlcyBvciBhZGFwdGl2ZSBob21lIGdhdGV3YXlzLiBUaGUgb25s eSBzb2x1dGlvbiBmb3Igb3BlcmF0b3JzIGlzIHRvIGhhdmUgYW4gYWdpbGUgd2F5IHRvIHByb3Zp c2lvbiByYXBpZGx5IGFuZCBlYXNpbHkgYW55IHR5cGUgb2YgSVB2NiBvciBJUHY0IHNlcnZpY2Ug ZGVwZW5kaW5nIG9mIHRoZSBzcGVjaWZpYyBuZWVkcyBvZiBlYWNoIGVuZC11c2VyIGFuZCB0aGVp ciBkZXZpY2UuIFRoZXNlIGNoYW5nZXMgbXVzdCBiZSBwZXJmb3JtZWQgd2l0aCByZXNwZWN0IHRv IHRoZSBvcGVyYXRvciBleGlzdGluZyBwb2xpY2llcyByZWdhcmRpbmcgdGhlIG5ldHdvcmssIGJp bGxpbmcsIHNlY3VyaXR5IGFuZCBvdGhlciBjb25zdHJhaW50cy4NCg0KV2hpbGUgZXhwbG9yaW5n IHRoZXNlIGlzc3VlcywgaXQgYmVjYW1lIGNsZWFyIHRoZSBiZXN0IHdheSB0byBhZGRyZXNzIHRo ZW0gd291bGQgYmUgdG8gdXNlIGEgY2VudHJhbCBjb250cm9sbGVyIHRoYXQgd291bGQgYmUgYWJs ZSB0byBjb29yZGluYXRlIHRoZSBkZXBsb3ltZW50IG9mIGRpZmZlcmVudCBwcm90b2NvbHMgYW1v bmdzdCBzZXZlcmFsIGRldmljZXMgaW4gYSBjb25zaXN0ZW50IGZhc2hpb24uIFN1Y2ggYSBjb250 cm9sbGVyIHdvdWxkIHJlY2VpdmUgaGlnaC1sZXZlbCBwb2xpY3kgaW5mb3JtYXRpb24gZnJvbSBh IG1hbmFnZW1lbnQgYXBwbGljYXRpb24sIHRyYW5zZm9ybSBpdCBpbiBuZXR3b3JrLWxldmVsIGNv bmZpZ3VyYXRpb24gYW5kIGFwcGx5IGl0IHRvIHBoeXNpY2FsIG9yIHZpcnR1YWwgZGV2aWNlcy4g QXQgdGhhdCBwb2ludCwgc2V2ZXJhbCBvdGhlciB1c2UgY2FzZXMgb3V0c2lkZSBvZiB0aGUgZGVw bG95bWVudCBvZiBJUHY2IHN0YXJ0ZWQgdG8gZW1lcmdlLCBmb3IgZXhhbXBsZSBmb3IgdGhlIGNv bnRyb2wgb2YgZGF0YSBjZW50ZXIgdHJhZmZpYyBzdGVlcmluZywgZm9yIHRoZSBjcmVhdGlvbiBv ZiB0dW5uZWxzIGFuZCB0aGUgcHJvdmlzaW9uaW5nIG9mIEwzVlBOLiBUaGUgZ3JvdXAgZGVjaWRl ZCB0byByZW5hbWUgaXRzIGFjdGl2aXRpZXMgdW5kZXIgdGhlIGFjcm9ueW0gQVBPTkYsIGZvciBB cHBsaWNhdGlvbiBQb2xpY3kgb24gTmV0d29yayBGdW5jdGlvbnMsIHdoaWNoIHNlZW1lZCBhIG1v cmUgZml0dGluZyBuYW1lLiBUaGUgZGVmaW5pdGlvbiBvZiBwb2xpY2llcyBieSBhIG1hbmFnZW1l bnQgYXBwbGljYXRpb24gdG93YXJkIGEgbmV0d29yayBjb250cm9sbGVyIHdvdWxkIGJlIGF0IHRo ZSBjZW50ZXIgb2YgdGhlIHdvcmsgZm9yIHRoZSBncm91cC4gU2V2ZXJhbCBncm91cCBkb2N1bWVu dHMgd2VyZSBjcmVhdGVkIGFyb3VuZCB0aGlzIGNvbmNlcHQuDQoNCldoZW4gcHJlc2VudGVkIGF0 IGEgYmFyIGJvZiBkdXJpbmcgSUVURi05MCBpbiBUb3JvbnRvLCBtb3N0IG9mIHRoZSBmZWVkYmFj ayB3YXMgcG9zaXRpdmUsIGJ1dCB0aGUgc2NvcGUgb2YgdGhlIHdvcmsgd2FzIG9mdGVuIGp1ZGdl ZCB0b28gbGFyZ2UgaW4gc2NvcGUuIEl0IHdhc24ndCBjbGVhciBlaXRoZXIgaG93IG11Y2ggb3Zl cmxhcCB0aGVyZSB3YXMgd2l0aCBvdGhlciBJRVRGIGdyb3Vwcy4gQSBiZXR0ZXIgYW5hbHlzaXMg b2YgdGhpcyBhc3BlY3QgaW4gdGhlIGZvbGxvd2luZyB3ZWVrcyByZXZlYWxlZCBzb21lIGxldmVs IG9mIG92ZXJsYXAgd2l0aCBvdGhlciBncm91cHMsIGJ1dCBhbHNvIHdoZXJlIGRlZmljaWVuY2ll cyBleGlzdC4gVGhlIHR3byBhc3BlY3RzIHdoZXJlIElFVEYgd29yayBzZWVtcyB0byBiZSBsYWNr aW5nIGFyZSBpbiB0aGUgZGVmaW5pdGlvbiBvZiBoaWdoLWxldmVsIHBvbGljeSBsYW5ndWFnZSBm b3IgYXBwbGljYXRpb25zIGFuZCBhbHNvIGluIGEgc3RhbmRhcmQgbW9kZWwgdG8gZGVzY3JpYmUg bmV0d29yayB0b3BvbG9naWVzIGF0IGRpZmZlcmVudCBsZXZlbHMgb2YgZ3JhbnVsYXJpdHksIG9y IGFic3RyYWN0aW9uLiBTb21lIGV4aXN0aW5nIHdvcmtpbmcgZ3JvdXBzIGhhdmUgcHVibGlzaGVk IHdvcmsgb24gdGhlIGxhdHRlci4gRm9yIGV4YW1wbGUsIHRoZSBBTFRPIHdvcmtpbmcgZ3JvdXAg ZGVmaW5lZCBhIHdheSB0byBkZXNjcmliZSBuZXR3b3JrIGZ1bmN0aW9ucyBhdCBkaWZmZXJlbnQg bGV2ZWwgb2YgZ3JhbnVsYXJpdHkgdXNpbmcgY29zdCBtYXBzLCBidXQgdGhpcyBhcHByb2FjaCBk b2VzIG5vdCBzZWVtIHByYWN0aWNhbCBmb3IgdGhlIGRlc2NyaXB0aW9uIG9mIGNvbXBsZXggbmV0 d29yayB0b3BvbG9naWVzIHRvIGFuZCBmcm9tIGEgY2VudHJhbCBjb250cm9sbGVyLiBBIHRvcG9s b2d5IGRyYWZ0IGV4aXN0cyBpbiB0aGUgSTJSUyBncm91cCwgYnV0IGl0IGlzIHZlcnkgY2VudGVy ZWQgIQ0KYXJvdW5kIHJvDQp1dGluZyBwcm90b2NvbHMgYW5kIEwyLUwzIGxpbmtzLg0KDQpUaGUg Z3JvdXAgaGFzIHJlY2VudGx5IHJlbmFtZWQgaXRzIGFjdGl2aXRpZXMgdW5kZXIgdGhlIFNVUEEg KFNoYXJlZCBVbmlmaWVkIFBvbGljeSBBdXRvbWF0aW9uKSBhY3JvbnltIHdpdGggdGhlIGludGVu dGlvbiBvZiBkZWZpbmluZyBhIHN0YW5kYXJkIHdheSB0byBwdXNoIHBvbGljaWVzIHRvIGEgY2Vu dHJhbCBjb250cm9sbGVyLiBJdCBhcHBlYXJzLCBob3dldmVyLCB0aGF0IGluIG9yZGVyIHRvIGRl ZmluZSBzdWNoIHBvbGljaWVzLCB0aGUgZGVmaW5pdGlvbiBvZiBhIHN0YW5kYXJkIG11bHRpLWxh eWVyIG1vZGVsIGZvciB0aGUgZGVzY3JpcHRpb24gb2YgbmV0d29ya3Mgb2YgYWxsIHR5cGVzIHdv dWxkIGJlIGRlc2lyYWJsZS4gVGhlcmVmb3JlIHRoZSBpbml0aWFsIHdvcmsgZm9yIHRoZSBTVVBB IGdyb3VwIHdvdWxkIGJlIHRvIHNlbGVjdCBhbiBleGlzdGluZyBtb2RlbGluZyBsYW5ndWFnZSBh bmQgZGVmaW5lIGEgY2xlYXIgbXVsdGktbGF5ZXIgbW9kZWwgYWJsZSB0byBkZXNjcmliZSBuZXR3 b3JrIG9yIHNlcnZpY2UgaW5mb3JtYXRpb24gYXQgYW55IGxldmVsIG9mIGdyYW51bGFyaXR5IG9y IGNvbXBsZXhpdHkuDQotLS0tLS0tLS0tLS0tLQ0KDQoNClRoYW5rIHlvdSwNClRpbmENCg0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFN1cGEgW21haWx0bzpzdXBhLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTcGVuY2VyIERhd2tpbnMNClNlbnQ6IEZyaWRheSwgU2Vw dGVtYmVyIDEyLCAyMDE0IDk6NDIgQU0NClRvOiBzdXBhQGlldGYub3JnPG1haWx0bzpzdXBhQGll dGYub3JnPg0KQ2M6IEJlbm9pdCBDbGFpc2UNClN1YmplY3Q6IFtTdXBhXSBBcmVhIGhhbmQtb2Zm LCBhbmQgc29tZSBmcmllbmRseSBhZHZpY2UgLi4uDQoNCkRlYXIgU1VQQSBmcmllbmRzLA0KDQpT ZXZlcmFsIElFU0cgbWVtYmVycyBoYWQgYSBjaGF0IGVhcmxpZXIgdGhpcyB3ZWVrLCBhbmQgZGVj aWRlZCB0aGF0IFNVUEEgcmVhbGx5IGJlbG9uZ3MgaW4gT1BTLiBJJ3ZlIHJlcXVlc3RlZCB0aGF0 IHRoZSBhcmVhIGFmZmlsaWF0aW9uIGluIGh0dHA6Ly93d3cuaWV0Zi5vcmcvbGlzdC9ub253Zy5o dG1sIGJlIHVwZGF0ZWQgdG8gcmVmbGVjdCB0aGF0Lg0KDQpCZW5vaXQgd2lsbCBiZSB5b3VyIEFE IGZvciBhZGRpdGlvbmFsIGNoYXJ0ZXIgZGlzY3Vzc2lvbi4NCg0KSWYgSSBtaWdodCBvZmZlciBz b21lIGZyaWVuZGx5IGFkdmljZSwgc2V2ZXJhbCBBRHMgYXJlIGZhaXJseSBjb25mdXNlZCBhYm91 dCB0aGUgcmVsYXRpb25zaGlwIGJldHdlZW4gb3BlbnY2LCBBUE9ORiwgYW5kIFNVUEEuIElmIHlv dSBjb3VsZCBwdXQgdG9nZXRoZXIgYSBzaG9ydCBwYXJhZ3JhcGggdGhhdCdzIHNvbWV0aGluZyBs aWtlICJ3ZSBzdGFydGVkIG9wZW52NiB0byBkbyBYLCB0aGVuIHdlIHJlYWxpemVkIHdlIG5lZWRl ZCB0byBkbyBZIHNvIHdlIHByb3Bvc2VkIEFQT05GLCBhbmQgYWZ0ZXIgZGlzY3Vzc2lvbnMgaW4g VG9yb250bywgd2UgY2hvc2UgYSBkaWZmZXJlbnQgZGlyZWN0aW9uIHdpdGggU1VQQSBiZWNhdXNl IG9mIFoiLCB0aGF0IHdvdWxkIGJlIHZlcnkgaGVscGZ1bC4NCg0KSSBhbHNvIGhhdmUgYSByZXF1 ZXN0IGZyb20gQmVub2l0IChhbmQgQWRyaWFuLCBhbmQgSm9lbCkgdG8gbWFrZSB0aGUgZGVzY3Jp cHRpb24gYXQgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdXBhIG1vcmUg dW5kZXJzdGFuZGFibGUgZm9yIHBlb3BsZSB3aG8gaGF2ZW4ndCBiZWVuIGZvbGxvd2luZyB0aGUg d29yayAtIGlmIHlvdSBpbnRlbmQgdG8gY2hhcnRlciBhIHdvcmtpbmcgZ3JvdXAsIHlvdSdsbCB3 YW50IHBlb3BsZSB0byB1bmRlcnN0YW5kIHdoYXQgeW91J3JlIHByb3Bvc2luZy4NCg0KWW91IHNo b3VsZCBwcm9iYWJseSBrZWVwIGluIG1pbmQgdGhhdCBwZW9wbGUgd2hvIHRhbGsgb3ZlciBhIGxv bmcgcGVyaW9kIG9mIHRpbWUgYXJlIGxpa2VseSB0byBkZXZlbG9wIGEgc2hhcmVkIHVuZGVyc3Rh bmRpbmcgdGhhdCBwZW9wbGUgd2hvIHdlcmVuJ3QgaW52b2x2ZWQgZG9uJ3QgdW5kZXJzdGFuZCBj bGVhcmx5LiBJZiB0aGVyZSdzIGEgc21hcnQgbmV3Y29tZXIgd2hvIGNvdWxkIGxvb2sgb3ZlciBw cm9ibGVtIHN0YXRlbWVudHMsIHByb3Bvc2VkIGNoYXJ0ZXJzIGFuZCBzZWUgd2hhdCdzIG5vdCBj bGVhciB0byBuZXdjb21lcnMsIHRoYXQgd291bGQgbGlrZWx5IGJlIGhlbHBmdWwgYXMgd2VsbC4N Cg0KVGhhbmtzLCBhbmQgYmVzdCB3aXNoZXMuIEknbGwgc2VlIHlvdSBpbiB0aGUgaGFsbHdheXMg b2YgSG9ub2x1bHUsIHdoZXJlIGFsbCBBRHMgbHVyayBzb29uZXIgb3IgbGF0ZXIgLi4uDQoNClNw ZW5jZXINCg0K --_000_C5034E44CD620A44971BAAEB372655DC635757LHREML516MBXchina_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QFNpbVN1biI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNv QWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxv b24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNw YW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7 DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQi Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUx OQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41 aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNl Y3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAv Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxh eW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwv bzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVO LVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+SGkgWmhlbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5rIHlvdSB2ZXJ5IG11Y2ggZm9yIHRo ZSBjb21tZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkluIHRoZSBuZXh0IHZlcnNpb24gb2YgdGhlIGNoYXJ0ZXIs IHdlIHdpbGw6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPm8pIGVtcGhhc2l6ZSB0aGUg bWFpbiBnb2FsIG9mIFNVUEE6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9InRleHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hdXRvc3Bh Y2U6bm9uZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBUaGUgbWFpbiBnb2FsIG9mIFNVUEEgaXMg dG8gcHJvdmlkZSBhIHdheSBmb3IgYXBwbGljYXRpb25zIHRvIHNwZWNpZnkNCjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWF1dG9zcGFjZTpu b25lIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7cG9saWNpZXMgdG8gdGhlIG5ldHdvcmsg aW5mcmFzdHJ1Y3R1cmUgdXNpbmcgYSBzaW1wbGlmaWVkIHZpZXcgb2YNCjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWF1dG9zcGFjZTpub25l Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7bmV0d29yay4gVGhpcyBjYW4gYmUgcmVhbGl6 ZWQgYnk6ICgxKSBtb2RlbGluZyB0aGUgbmV0d29yaw0KPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij4mbmJzcDsmbmJzcDsmbmJzcDtpbmZyYXN0cnVjdHVyZSBhcyBhbiBzaW1wbGlmaWVkIG5ldHdv cmsgZ3JhcGggdXNpbmcgYSBtb2RlbGluZw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJz cDsmbmJzcDsmbmJzcDtsYW5ndWFnZSBzdWNoIGFzIFlBTkcgKDIpIHRyYW5zcG9ydGluZyBtb2Rl bA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRl eHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDtpbnN0YW5jZXMg ZWl0aGVyIHVzaW5nIE5FVENPTkYgb3IgUkVTVENPTkYgYW5kICgzKSBwcm92aWRpbmcgZ3VpZGVs aW5lcyBvbg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9InRleHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDttYXBw aW5nIHBvbGljaWVzIHRvIGF0dHJpYnV0ZXMgb2YgdGhlIG5ldHdvcmsgZ3JhcGhzLg0KPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYXV0b3Nw YWNlOm5vbmUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ bykgZW1waGFzaXplIHRoYXQgYXMgc3RhcnRpbmcgcG9pbnQsIGZvciBhcHBsaWNhdGlvbnMsIHdl IHdpbGwgZm9jdXMgb25seSBvbiBuZXR3b3JrIHNlcnZpY2VzPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5vKSBlbXBoYXNp emUgdGhhdCB3ZSB3aWxsIGZvY3VzIG9uIHBvbGljeSBhbmQgZGF0YSBtb2RlbHMgdGhhdCBhcmUg YWJsZSB0byBwcm92aWRlIGVub3VnaCBkZXRhaWxzIG9uIHRoZSB1c2VkIG5ldHdvcmsgYW5kIHNl cnZpY2UgdG9wb2xvZ3kuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5vKSBlbXBoYXNpemUgdGhhdCByZWdhcmRpbmcgcG9s aWN5LCBlbmhhbmNlbWVudHMgb2YgdGhlIFlBTkcgeFBhdGggZXhwcmVzc2lvbiBtaWdodCBiZSBy ZXF1aXJlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPkJlc3QgcmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+R2Vvcmdpb3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gU3VwYSBbbWFpbHRv OnN1cGEtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+WmhlbiBDYW88YnI+ DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBTZXB0ZW1iZXIgMjIsIDIwMTQgMjoxMyBQTTxicj4NCjxi PlRvOjwvYj4gVGluYSBUU09VPGJyPg0KPGI+Q2M6PC9iPiBzdXBhQGlldGYub3JnPGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBbU3VwYV0gQXJlYSBoYW5kLW9mZiwgYW5kIHNvbWUgZnJpZW5kbHkg YWR2aWNlIC4uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SGVsbG8gVGluYSBhbmQgZXZlcnlib2R5LCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBoYXZlIHNvbWUgY29tbWVudHMgYWJvdXQgdGhlIHNjb3Bl IG9mIFNVUEEsIGFzIGEgbmV3bHkgY29taW5nIHJlYWRlci4mbmJzcDsgU2VlIHRoZSBjb21tZW50 cyBpbiBsaW5lLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5CZXN0IHJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj56aGVuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPlNVUEEgKFNoYXJlZCBVbmlmaWVkIFBvbGljeSBB dXRvbWF0aW9uKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRhcmdldCBBcmVhOiBPUFM8YnI+DQo8YnI+DQpEZXNj cmlwdGlvbiBvZiBXb3JraW5nIEdyb3VwOjxicj4NCjxicj4NCk5ldHdvcmsgb3BlcmF0b3JzIGFy ZSBmYWNlZCB3aXRoIG5ldHdvcmtzIG9mIGluY3JlYXNpbmcgc2l6ZSBhbmQgY29tcGxleGl0eSB3 aGlsZSB0cnlpbmcgdG8gaW1wcm92ZSB0aGVpciBxdWFsaXR5IGFuZCBhdmFpbGFiaWxpdHksIGFz IG1vcmUgYW5kIG1vcmUgc2VydmljZXMgZGVwZW5kIG9uIHRoZW0uIFByb2dyYW1tYXRpYyB3YXlz IHRvIGNvbmZpZ3VyZSBuZXR3b3Jrcywgb2Z0ZW4gJm5ic3A7Y2FsbGVkIHNvZnR3YXJlLWRlZmlu ZWQsIGFyZSBjb25zaWRlcmVkDQogYnkgbWFueSBuZXR3b3JrIG9wZXJhdG9ycyBpbiBvcmRlciB0 byBzaGlmdCB0aGUgYmFsYW5jZSBpbiB0aGVpciBmYXZvci48YnI+DQo8YnI+DQpBdXRvbWF0aW9u IG9mIGNvbmZpZ3VyYXRpb24gbWF5IHByb3ZpZGUgc2lnbmlmaWNhbnQgaW1wcm92ZW1lbnRzIGlu IGNvbmZpZ3VyYXRpb24gYWdpbGl0eSwgZXJyb3IgZGV0ZWN0aW9uIGFuZCB1cHRpbWUgZm9yIG9w ZXJhdG9ycy4gSG93ZXZlciB0aGUgcmVhbCB2YWx1ZSBiZWhpbmQgY2VudHJhbCBjb25maWd1cmF0 aW9uIHNjaGVtZXMgbGllcyB3aXRoaW4gdGhlIHBvc3NpYmxlIHNpbXBsaWZpY2F0aW9uIHRocm91 Z2ggYWJzdHJhY3Rpb24gcHJvdmlkZWQNCiBieSBzdWNoIHN5c3RlbXMgdG8gYXBwbGljYXRpb25z IHJ1bm5pbmcgYWJvdmUgdGhlbSAob24gdGhlIHNvLWNhbGxlZCBub3J0aGJvdW5kIHNpZGUpLiBX ZWxsLWRlc2lnbmVkIGFic3RyYWN0aW9ucyBhcmUgYWJsZSB0byBwcm92aWRlIGEgd2lkZSByYW5n ZSBvZiBncmFudWxhcml0eSBmb3IgdmFyaW91cyBhcHBsaWNhdGlvbnMgbmVlZHMsIGZyb20gdGhl IGxvd2VyLWxldmVsIHBoeXNpY2FsIG5ldHdvcmsgdG8gaGlnaC1sZXZlbCBhcHBsaWNhdGlvbg0K IHNlcnZpY2VzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFmdGVyIHRoZSBmaXJzdCB0d28gcGFyYWdyYXBo LCBJIGFtIHJlYWxseSBleHBlY3RpbmcgYSBmdWxsIGludHJvZHVjdGlvbiBvZiBTVVBBLCBlc3Bl Y2lhbGx5IHdoYXQgdGhlIGZvdXItbGV0dGVyIGFiYnJldmlhdGlvbiBtZWFucyBwaHlzaWNhbGx5 LiAmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxk aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BbHRo b3VnaCBzZXZlcmFsIG9yZ2FuaXphdGlvbnMgb3V0c2lkZSBvZiB0aGUgSUVURiBoYXZlIGRlZmlu ZWQgdmFyaW91cyBzY2hlbWVzIGZvciB0aGUgY29uZmlndXJhdGlvbiBvZiBuZXR3b3JrIGRldmlj ZXMgYW5kIHNwZWNpZmljIG5ldHdvcmsgY29udHJvbGxlcnMsIG5vbmUgb2YgdGhlbSBvZmZlciBh IHZlbmRvci1uZXV0cmFsDQogc3RhbmRhcmRpemVkIHdheSBmb3IgYXBwbGljYXRpb25zIHRvIHRy YW5zbWl0IHRoZWlyIG5lZWRzIHRvIGNvbnRyb2xsZXJzLiBUaGUgU1VQQSAoU2hhcmVkIFVuaWZp ZWQgUG9saWN5IEF1dG9tYXRpb24pIHdvcmtpbmcgZ3JvdXAgd2lsbCB3b3JrIG9uIHRoZSBkZWZp bml0aW9uIG9mIHN1Y2ggYXMgc3RhbmRhcmRpemVkIGludGVyZmFjZSBmb3IgYXBwbGljYXRpb25z IHRvIGNvbW11bmljYXRlIHdpdGggbmV0d29yayBjb250cm9sbGVycyBvZiBhbGwNCiB0eXBlcy4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDow aW4iPg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48YnI+DQpUaGUgaW50ZXJmYWNlIGRlZmluaXRpb25zIHdpbGwgYmUgYmFzZWQg b24gdGhlIGNvbmNlcHQgb2YgbmV0d29yayBncmFwaCwgYW4gZW50aXR5IGRlc2NyaWJpbmcgYW4g YXJiaXRyYXJ5IHRvcG9sb2d5IG9mIG5vZGVzIGFuZCBsaW5rcyBhdCBhbnkgbGV2ZWwgb2YgYWJz dHJhY3Rpb24gYW5kIGdyYW51bGFyaXR5Lg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPidBbnkgbGV2ZWwgb2Yg YWJzdHJhY3Rpb24nIGlzIHZlcnkgYWdncmVzc2l2ZSB0byBtZSwgZ29vZCB0byB5b3UgZ3V5cz8m bmJzcDsgV2hhdCdzIHRoZSBsZXZlbCBvZiBhYnN0cmFjdGlvbiB3aWxsIHRoZSBncm91cCBmb2N1 cyBvbj88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGlu IDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5TdWNoIGEg Z3JhcGggbWF5IGRlc2NyaWJlLCBmb3IgZXhhbXBsZSwgYSBwaHlzaWNhbCB0b3BvbG9neSwgYSBM MiBuZXR3b3JrLCBhIHNlcnZpY2UgdG9wb2xvZ3kgb3IgdGhlIHJlbGF0aW9uc2hpcHMgYmV0d2Vl biBkYXRhY2VudGVycy4gQWx0aG91Z2ggc29tZSBJRVRGIHdvcmtpbmcgZ3JvdXBzIGhhdmUgc3Rh cnRlZA0KIHdvcmsgcmVsYXRpbmcgdG8gdGhlIGRlc2NyaXB0aW9uIG9mIHZhcmlvdXMgdG9wb2xv Z2llcyBzdWNoIGFzIEkyUlMgKEwzIGFuZCByb3V0aW5nIHRvcG9sb2dpZXMpLCBBTFRPIChjb3N0 IG1hcHMpLCBTRkMgKHNlcnZpY2UgY2hhaW4pLCBub25lIG9mIHRoZXNlIGdyb3VwcyBhaW0gYXQg b2ZmZXJpbmcgYSB0cnVseSBnZW5lcmljIG11bHRpLWxheWVyIGFuZCBhYnN0cmFjdCB0b3BvbG9n eSBmb3Igc3RhbmRhcmQgbm9ydGhib3VuZCBjb25maWd1cmF0aW9uLjxicj4NCjxicj4NCldvcmsg aXRlbXMgZm9yIFNVUEEgaW5jbHVkZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ib3cgYWJvdXQgbW92aW5n IHRoZSBlYXNpZXIgaXRlbXMgdG8gdGhlIGZyb250LCBlLmcuIHRoZSBwcm9ibGVtIHN0YXRlbWVu dCBhbmQgcmVxdWlyZW1lbnQuIE5vcm1hbGx5IHRoZXNlIGFyZSB0aGUgcHJlcmVxdWlzaXRlIGZv ciBhbnkgY2hhcnRlcmVkIHRlY2huaWNhbCBpdGVtcywgYmFzaWMgb24gd2hpY2ggdGhlIGRlZmlu aXRpb24vc3BlY2lmaWNhdGlvbi9jaG9pY2UgbWFraW5nIHdvcmsgY2FuIGtpY2stb2ZmLiZuYnNw Ow0KIEJ0dywgdGhlIGZpdmUgaXRlbXMgY2hhcnRlciBhbHNvIHNlZW1zIGFnZ3Jlc3NpdmUgdG9v LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAw aW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxicj4N CjEpIENob2ljZSBvZiBhIG1vZGVsaW5nIGxhbmd1YWdlIHVzZWQgYnkgdGhlIGdyb3VwIHRvIGRl c2NyaWJlIHRoZSBuZXR3b3JrIGdyYXBoLiBFeGlzdGluZyBtb2RlbGluZyBsYW5ndWFnZXMgc3Vj aCBhcyBZQU5HIHdpbGwgYmUgY29uc2lkZXJlZCBmb3IgdGhpcyBwdXJwb3NlIHVubGVzcyBubyBz dWl0YWJsZSBvbmUgaXMgZm91bmQuPGJyPg0KPGJyPg0KMikgQ2hvaWNlIG9mIGEgdHJhbnNwb3J0 IHByb3RvY29sIGZvciB0aGUgbW9kZWxpbmcgbGFuZ3VhZ2UgbWVudGlvbmVkIGFib3ZlLiBUaGUg Z3JvdXAgd2lsbCByZS11c2UgYSBwcm90b2NvbCBhbHJlYWR5IGRlZmluZWQgYXMgYSB0cmFuc3Bv cnQgZm9yIHRoZSBtb2RlbGluZyBsYW5ndWFnZSwgc3VjaCBhcyBORVRDT05GIG9yIFJFU1RDT05G IGluIHRoZSBjYXNlIG9mIFlBTkcuPGJyPg0KPGJyPg0KMykgVGhlIGRlZmluaXRpb24gb2YgYSBz dGFuZGFyZGl6ZWQgbW9kZWwgZm9yIGEgbmV0d29yayB0b3BvbG9neSBncmFwaC4gVGhpcyBtb2Rl bCBtYXkgYmUgdXNlZCB0byBkZXNjcmliZSB0b3BvbG9naWVzIGF0IGFueSBmdW5jdGlvbmFsIGxh eWVyLCBmcm9tIHBoeXNpY2FsIG5ldHdvcmtzIHRvIG5ldHdvcmsgc2VydmljZXMgYW5kIGhpZ2hl ciBhYnN0cmFjdGlvbnMuIFRoZSBub2RlcyBvZiB0aGlzIGdyYXBoIG1heSBkZXNjcmliZSBwaHlz aWNhbA0KIG5vZGVzIGFzIHdlbGwgYXMgdmlydHVhbGl6ZWQgb25lcy48YnI+DQo8YnI+DQo0KSBU aGUgZGVmaW5pdGlvbiBhbmQgc3RhbmRhcmRpemF0aW9uIG9mIGEgbnVtYmVyIG9mIGJhc2ljIGFi c3RyYWN0ZWQgbW9kZWxzIHVzaW5nIG5ldHdvcmsgZ3JhcGhzLiBUaGVzZSBtaWdodCBpbmNsdWRl LCBidXQgYXJlIG5vdCBsaW1pdGVkIHRvLCBMM1ZQTnMsIEwyVlBOcywgZGF0YWNlbnRlcnMsIHRy YWZmaWMgZW5naW5lZXJpbmcsIGltcGxlbWVudGF0aW9uIG9mIElQdjYgdHJhbnNpdGlvbiBtZWNo YW5pc20gYW5kIHRoZWlyIGVuZm9yY2VtZW50DQogdG8gdXNlcnMuICZuYnNwOzxicj4NCjxicj4N CjUpIEd1aWRlbGluZXMgZm9yIHRoZSBtYXBwaW5nIG9mIGFic3RyYWN0IG1vZGVsIGluZm9ybWF0 aW9uIHRvIHBoeXNpY2FsIG9yIHZpcnR1YWxpemVkIG5ldHdvcmsgY29tcG9uZW50cy4gJm5ic3A7 PGJyPg0KPGJyPg0KUHJvcG9zZWQgbWlsZXN0b25lcyBmb3IgdGhlIHdvcmtpbmcgZ3JvdXA6PGJy Pg0KPGJyPg0KLSAmbmJzcDsmbmJzcDtQcm9kdWNlIGEgcHJvYmxlbSBzdGF0ZW1lbnQgZG9jdW1l bnQgZm9yIFNVUEEuPGJyPg0KPGJyPg0KLSAmbmJzcDsmbmJzcDtQcm9kdWNlIGEgZ2FwIGFuYWx5 c2lzIGZvciBTVVBBIGluIG9yZGVyIHRvIHZlcmlmeSBvdmVybGFwIHdpdGggdGhlIHdvcmsgb2Yg b3RoZXIgSUVURiBncm91cHMuPGJyPg0KPGJyPg0KLSAmbmJzcDsmbmJzcDtQcm9kdWNlIGEgcmVx dWlyZW1lbnQgZG9jdW1lbnQgZGVzY3JpYmluZyB0aGUgZGVzaXJlZCBwcm9wZXJ0aWVzIG9mIGFu IGFic3RyYWN0IG11bHRpLWxheWVyIG5ldHdvcmsgZ3JhcGggZGVmaW5pdGlvbi48YnI+DQo8YnI+ DQotICZuYnNwOyZuYnNwO1Byb2R1Y2UgYSBnYXAgYW5hbHlzaXMgb2YgZXhpc3RpbmcgbW9kZWxp bmcgbGFuZ3VhZ2UsIHRoZWlyIGNoYXJhY3RlcmlzdGljcywgcG9zc2libGUgdHJhbnNwb3J0IHBy b3RvY29scyBhbmQgaG93IHRoZXkgY29tcGFyZSB0byB0aGUgU1VQQSByZXF1aXJlbWVudHMuPGJy Pg0KPGJyPg0KLSAmbmJzcDsmbmJzcDtQcm9kdWNlIGEgZG9jdW1lbnQgc3BlY2lmeWluZyB0aGUg bW9kZWwgZm9yIGEgZ2VuZXJpYyBtdWx0aS1sYXllciBuZXR3b3JrIGdyYXBoLjxicj4NCjxicj4N Ci0gJm5ic3A7Jm5ic3A7UHJvZHVjZSBzZXZlcmFsIGRvY3VtZW50cyBkZXNjcmliaW5nIGRpZmZl cmVudCBsZXZlbHMgb2YgYWJzdHJhY3Qgdmlld3MgdXNpbmcgdGhlIG5ldHdvcmsgZ3JhcGggbW9k ZWwgZGVmaW5lZCBhYm92ZSwgaW5jbHVkaW5nIHBoeXNpY2FsIHZpZXcsIGxvZ2ljYWwgdmlldywg bGF5ZXItMyB2aWV3LCBjb25maWd1cmF0aW9uIHZpZXcsIHBlcmZvcm1hbmNlIHByb2Jpbmcgdmll dywgc2VydmljZSB2aWV3IGFuZCBvdGhlciBzdWNoIGFzIEwzVlBOLA0KIEwyVlBOLCBkYXRhY2Vu dGVycyBhbmQgdHJhZmZpYyBlbmdpbmVlcmluZy4gJm5ic3A7PGJyPg0KPGJyPg0KLS0tLS0tLS0t LS0tPGJyPg0KPGJyPg0KPGJyPg0KKiBPUEVOdjYsIEFQT05GIGFuZCBTVVBBIGdyb3VwIGhpc3Rv cmljIHBlcnNwZWN0aXZlPGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCjxicj4NCk1vc3QgSUVU RiB3b3JraW5nIGdyb3VwcyBhcmUgZm9ybWVkIGluIHRoZSBpbnRlcmVzdCBvZiBzb2x2aW5nIHNv bWUgYWN0dWFsIHJlYWwtd29ybGQgcHJvYmxlbSBmcm9tIG5ldHdvcmsgb3BlcmF0b3JzLCBkZXZl bG9wZXJzIG9yIG1hbnVmYWN0dXJlcnMgYW5kIHRoZSBpbml0aWFsIHdvcmsgZnJvbSB0aGUgT1BF TnY2IGdyb3VwIHdhcyBubyBleGNlcHRpb24uIFNvbWUgb3BlcmF0b3JzIHNhdyBhIGNvbW1vbiBp bnRlcmVzdCBpbiBkZWZpbmluZyBhDQogY29tbW9uIGFwcHJvYWNoIGZvciB0aGUgZGVwbG95bWVu dCBvZiBJUHY2IHRyYW5zaXRpb24gdG9vbHMuIEFsdGhvdWdoIHRoZSBwcmVmZXJyZWQgd2F5IG9m IGRlcGxveWluZyBJUHY2IHJlbWFpbnMgYnkgZHVhbC1zdGFja2luZywgc2V2ZXJhbCBvcGVyYXRv cnMgaGF2ZSBkZXBsb3llZCBhZGRpdGlvbmFsIHRyYW5zaXRpb24gdG9vbHMgc3VjaCBhcyA2UkQg KFJGQzU5NjkpLCBEUy1MaXRlIChSRkM2MzMzKSwgTkFUNjQgKFJGQzYxNDYpIGFuZCBvdGhlcnMN CiB3aXRoIHRoZSBpbnRlbnQgb2Ygc3BlZWRpbmcgdXAgb3IgdG8gcHJvdmlkZSBtb3JlIGZsZXhp YmlsaXR5IGluIHRoZWlyIElQdjYgc2VydmljZXMuIEVhY2ggb2YgdGhlc2UgcHJvdG9jb2xzIHBy ZXNlbnRzIGl0cyBvd24gc2V0IG9mIGRlcGxveW1lbnQgY2hhbGxlbmdlcyBhbmQgZmFpbHVyZSBt b2RlcyBmb3IgdXNlcnMsIGVpdGhlciBiZWNhdXNlIG9mIHVuc3VwcG9ydGVkIGFwcGxpY2F0aW9u cywgcGFydGlhbCBpbXBsZW1lbnRhdGlvbnMgaW4NCiBzb21lIG9mZi10aGUtc2hlbGYgZGV2aWNl cyBzdWNoIGFzIGhvbWUgcm91dGVycyBvciBzb21lIGxpbWl0YXRpb25zIG9mIHRoZSBwcm90b2Nv bHMgdGhlbXNlbHZlcyB0byBuYW1lIGEgZmV3IGNhc2VzLg0KPGJyPg0KPGJyPg0KVGhlIGZhY3Qg dGhlc2UgcHJvdG9jb2xzIGFyZSBvZnRlbiBkZXBsb3llZCB3aXRoIHRlY2huaXF1ZXMgdGFyZ2V0 aW5nIHRoZSBleHRlbnNpb24gb2YgSVB2NCBzZXJ2aWNlLCBzdWNoIGFzIENhcnJpZXIgR3JhZGUg TkFULCBtYWtpbmcgdGhlaXIgZGVwbG95bWVudCBldmVuIG1vcmUgY29tcGxleCwgZXNwZWNpYWxs eSB3aGVuIHRhcmdldGluZyBtaW5pbWFsIGVuZC11c2VyIGltcGFjdC4gQWx0aG91Z2ggc29tZSBh cHByb2FjaGVzIGluIHNvbHZpbmcNCiB0aGlzIHdlcmUgcHJvcG9zZWQsIGZvciBleGFtcGxlIGlu IFJGQzYyNjQsIHRoZSBtYXJrZXQgaGFzbid0IHNlZW4gdGhlIGFkdmVudCBvZiBjb25maWd1cmFi bGUgQ0dOIGRldmljZXMgb3IgYWRhcHRpdmUgaG9tZSBnYXRld2F5cy4gVGhlIG9ubHkgc29sdXRp b24gZm9yIG9wZXJhdG9ycyBpcyB0byBoYXZlIGFuIGFnaWxlIHdheSB0byBwcm92aXNpb24gcmFw aWRseSBhbmQgZWFzaWx5IGFueSB0eXBlIG9mIElQdjYgb3IgSVB2NCBzZXJ2aWNlIGRlcGVuZGlu Zw0KIG9mIHRoZSBzcGVjaWZpYyBuZWVkcyBvZiBlYWNoIGVuZC11c2VyIGFuZCB0aGVpciBkZXZp Y2UuIFRoZXNlIGNoYW5nZXMgbXVzdCBiZSBwZXJmb3JtZWQgd2l0aCByZXNwZWN0IHRvIHRoZSBv cGVyYXRvciBleGlzdGluZyBwb2xpY2llcyByZWdhcmRpbmcgdGhlIG5ldHdvcmssIGJpbGxpbmcs IHNlY3VyaXR5IGFuZCBvdGhlciBjb25zdHJhaW50cy4NCjxicj4NCjxicj4NCldoaWxlIGV4cGxv cmluZyB0aGVzZSBpc3N1ZXMsIGl0IGJlY2FtZSBjbGVhciB0aGUgYmVzdCB3YXkgdG8gYWRkcmVz cyB0aGVtIHdvdWxkIGJlIHRvIHVzZSBhIGNlbnRyYWwgY29udHJvbGxlciB0aGF0IHdvdWxkIGJl IGFibGUgdG8gY29vcmRpbmF0ZSB0aGUgZGVwbG95bWVudCBvZiBkaWZmZXJlbnQgcHJvdG9jb2xz IGFtb25nc3Qgc2V2ZXJhbCBkZXZpY2VzIGluIGEgY29uc2lzdGVudCBmYXNoaW9uLiBTdWNoIGEg Y29udHJvbGxlciB3b3VsZCByZWNlaXZlDQogaGlnaC1sZXZlbCBwb2xpY3kgaW5mb3JtYXRpb24g ZnJvbSBhIG1hbmFnZW1lbnQgYXBwbGljYXRpb24sIHRyYW5zZm9ybSBpdCBpbiBuZXR3b3JrLWxl dmVsIGNvbmZpZ3VyYXRpb24gYW5kIGFwcGx5IGl0IHRvIHBoeXNpY2FsIG9yIHZpcnR1YWwgZGV2 aWNlcy4gQXQgdGhhdCBwb2ludCwgc2V2ZXJhbCBvdGhlciB1c2UgY2FzZXMgb3V0c2lkZSBvZiB0 aGUgZGVwbG95bWVudCBvZiBJUHY2IHN0YXJ0ZWQgdG8gZW1lcmdlLCBmb3IgZXhhbXBsZSBmb3IN CiB0aGUgY29udHJvbCBvZiBkYXRhIGNlbnRlciB0cmFmZmljIHN0ZWVyaW5nLCBmb3IgdGhlIGNy ZWF0aW9uIG9mIHR1bm5lbHMgYW5kIHRoZSBwcm92aXNpb25pbmcgb2YgTDNWUE4uIFRoZSBncm91 cCBkZWNpZGVkIHRvIHJlbmFtZSBpdHMgYWN0aXZpdGllcyB1bmRlciB0aGUgYWNyb255bSBBUE9O RiwgZm9yIEFwcGxpY2F0aW9uIFBvbGljeSBvbiBOZXR3b3JrIEZ1bmN0aW9ucywgd2hpY2ggc2Vl bWVkIGEgbW9yZSBmaXR0aW5nIG5hbWUuIFRoZSBkZWZpbml0aW9uDQogb2YgcG9saWNpZXMgYnkg YSBtYW5hZ2VtZW50IGFwcGxpY2F0aW9uIHRvd2FyZCBhIG5ldHdvcmsgY29udHJvbGxlciB3b3Vs ZCBiZSBhdCB0aGUgY2VudGVyIG9mIHRoZSB3b3JrIGZvciB0aGUgZ3JvdXAuIFNldmVyYWwgZ3Jv dXAgZG9jdW1lbnRzIHdlcmUgY3JlYXRlZCBhcm91bmQgdGhpcyBjb25jZXB0Lg0KPGJyPg0KPGJy Pg0KV2hlbiBwcmVzZW50ZWQgYXQgYSBiYXIgYm9mIGR1cmluZyBJRVRGLTkwIGluIFRvcm9udG8s IG1vc3Qgb2YgdGhlIGZlZWRiYWNrIHdhcyBwb3NpdGl2ZSwgYnV0IHRoZSBzY29wZSBvZiB0aGUg d29yayB3YXMgb2Z0ZW4ganVkZ2VkIHRvbyBsYXJnZSBpbiBzY29wZS4gSXQgd2Fzbid0IGNsZWFy IGVpdGhlciBob3cgbXVjaCBvdmVybGFwIHRoZXJlIHdhcyB3aXRoIG90aGVyIElFVEYgZ3JvdXBz LiBBIGJldHRlciBhbmFseXNpcyBvZiB0aGlzIGFzcGVjdA0KIGluIHRoZSBmb2xsb3dpbmcgd2Vl a3MgcmV2ZWFsZWQgc29tZSBsZXZlbCBvZiBvdmVybGFwIHdpdGggb3RoZXIgZ3JvdXBzLCBidXQg YWxzbyB3aGVyZSBkZWZpY2llbmNpZXMgZXhpc3QuIFRoZSB0d28gYXNwZWN0cyB3aGVyZSBJRVRG IHdvcmsgc2VlbXMgdG8gYmUgbGFja2luZyBhcmUgaW4gdGhlIGRlZmluaXRpb24gb2YgaGlnaC1s ZXZlbCBwb2xpY3kgbGFuZ3VhZ2UgZm9yIGFwcGxpY2F0aW9ucyBhbmQgYWxzbyBpbiBhIHN0YW5k YXJkIG1vZGVsDQogdG8gZGVzY3JpYmUgbmV0d29yayB0b3BvbG9naWVzIGF0IGRpZmZlcmVudCBs ZXZlbHMgb2YgZ3JhbnVsYXJpdHksIG9yIGFic3RyYWN0aW9uLiBTb21lIGV4aXN0aW5nIHdvcmtp bmcgZ3JvdXBzIGhhdmUgcHVibGlzaGVkIHdvcmsgb24gdGhlIGxhdHRlci4gRm9yIGV4YW1wbGUs IHRoZSBBTFRPIHdvcmtpbmcgZ3JvdXAgZGVmaW5lZCBhIHdheSB0byBkZXNjcmliZSBuZXR3b3Jr IGZ1bmN0aW9ucyBhdCBkaWZmZXJlbnQgbGV2ZWwgb2YgZ3JhbnVsYXJpdHkNCiB1c2luZyBjb3N0 IG1hcHMsIGJ1dCB0aGlzIGFwcHJvYWNoIGRvZXMgbm90IHNlZW0gcHJhY3RpY2FsIGZvciB0aGUg ZGVzY3JpcHRpb24gb2YgY29tcGxleCBuZXR3b3JrIHRvcG9sb2dpZXMgdG8gYW5kIGZyb20gYSBj ZW50cmFsIGNvbnRyb2xsZXIuIEEgdG9wb2xvZ3kgZHJhZnQgZXhpc3RzIGluIHRoZSBJMlJTIGdy b3VwLCBidXQgaXQgaXMgdmVyeSBjZW50ZXJlZCAhPGJyPg0KYXJvdW5kIHJvPGJyPg0KdXRpbmcg cHJvdG9jb2xzIGFuZCBMMi1MMyBsaW5rcy4gPGJyPg0KPGJyPg0KVGhlIGdyb3VwIGhhcyByZWNl bnRseSByZW5hbWVkIGl0cyBhY3Rpdml0aWVzIHVuZGVyIHRoZSBTVVBBIChTaGFyZWQgVW5pZmll ZCBQb2xpY3kgQXV0b21hdGlvbikgYWNyb255bSB3aXRoIHRoZSBpbnRlbnRpb24gb2YgZGVmaW5p bmcgYSBzdGFuZGFyZCB3YXkgdG8gcHVzaCBwb2xpY2llcyB0byBhIGNlbnRyYWwgY29udHJvbGxl ci4gSXQgYXBwZWFycywgaG93ZXZlciwgdGhhdCBpbiBvcmRlciB0byBkZWZpbmUgc3VjaCBwb2xp Y2llcywgdGhlIGRlZmluaXRpb24NCiBvZiBhIHN0YW5kYXJkIG11bHRpLWxheWVyIG1vZGVsIGZv ciB0aGUgZGVzY3JpcHRpb24gb2YgbmV0d29ya3Mgb2YgYWxsIHR5cGVzIHdvdWxkIGJlIGRlc2ly YWJsZS4gVGhlcmVmb3JlIHRoZSBpbml0aWFsIHdvcmsgZm9yIHRoZSBTVVBBIGdyb3VwIHdvdWxk IGJlIHRvIHNlbGVjdCBhbiBleGlzdGluZyBtb2RlbGluZyBsYW5ndWFnZSBhbmQgZGVmaW5lIGEg Y2xlYXIgbXVsdGktbGF5ZXIgbW9kZWwgYWJsZSB0byBkZXNjcmliZSBuZXR3b3JrIG9yDQogc2Vy dmljZSBpbmZvcm1hdGlvbiBhdCBhbnkgbGV2ZWwgb2YgZ3JhbnVsYXJpdHkgb3IgY29tcGxleGl0 eS48YnI+DQotLS0tLS0tLS0tLS0tLTxicj4NCjxicj4NCjxicj4NClRoYW5rIHlvdSw8YnI+DQpU aW5hPGJyPg0KPGJyPg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQpGcm9tOiBTdXBh IFs8YSBocmVmPSJtYWlsdG86c3VwYS1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ bWFpbHRvOnN1cGEtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBTcGVuY2VyIERh d2tpbnM8YnI+DQpTZW50OiBGcmlkYXksIFNlcHRlbWJlciAxMiwgMjAxNCA5OjQyIEFNPGJyPg0K VG86IDxhIGhyZWY9Im1haWx0bzpzdXBhQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c3VwYUBp ZXRmLm9yZzwvYT48YnI+DQpDYzogQmVub2l0IENsYWlzZTxicj4NClN1YmplY3Q6IFtTdXBhXSBB cmVhIGhhbmQtb2ZmLCBhbmQgc29tZSBmcmllbmRseSBhZHZpY2UgLi4uPGJyPg0KPGJyPg0KRGVh ciBTVVBBIGZyaWVuZHMsPGJyPg0KPGJyPg0KU2V2ZXJhbCBJRVNHIG1lbWJlcnMgaGFkIGEgY2hh dCBlYXJsaWVyIHRoaXMgd2VlaywgYW5kIGRlY2lkZWQgdGhhdCBTVVBBIHJlYWxseSBiZWxvbmdz IGluIE9QUy4gSSd2ZSByZXF1ZXN0ZWQgdGhhdCB0aGUgYXJlYSBhZmZpbGlhdGlvbiBpbg0KPGEg aHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9saXN0L25vbndnLmh0bWwiIHRhcmdldD0iX2JsYW5r Ij5odHRwOi8vd3d3LmlldGYub3JnL2xpc3Qvbm9ud2cuaHRtbDwvYT4gYmUgdXBkYXRlZCB0byBy ZWZsZWN0IHRoYXQuPGJyPg0KPGJyPg0KQmVub2l0IHdpbGwgYmUgeW91ciBBRCBmb3IgYWRkaXRp b25hbCBjaGFydGVyIGRpc2N1c3Npb24uPGJyPg0KPGJyPg0KSWYgSSBtaWdodCBvZmZlciBzb21l IGZyaWVuZGx5IGFkdmljZSwgc2V2ZXJhbCBBRHMgYXJlIGZhaXJseSBjb25mdXNlZCBhYm91dCB0 aGUgcmVsYXRpb25zaGlwIGJldHdlZW4gb3BlbnY2LCBBUE9ORiwgYW5kIFNVUEEuIElmIHlvdSBj b3VsZCBwdXQgdG9nZXRoZXIgYSBzaG9ydCBwYXJhZ3JhcGggdGhhdCdzIHNvbWV0aGluZyBsaWtl ICZxdW90O3dlIHN0YXJ0ZWQgb3BlbnY2IHRvIGRvIFgsIHRoZW4gd2UgcmVhbGl6ZWQgd2UgbmVl ZGVkIHRvIGRvIFkgc28NCiB3ZSBwcm9wb3NlZCBBUE9ORiwgYW5kIGFmdGVyIGRpc2N1c3Npb25z IGluIFRvcm9udG8sIHdlIGNob3NlIGEgZGlmZmVyZW50IGRpcmVjdGlvbiB3aXRoIFNVUEEgYmVj YXVzZSBvZiBaJnF1b3Q7LCB0aGF0IHdvdWxkIGJlIHZlcnkgaGVscGZ1bC48YnI+DQo8YnI+DQpJ IGFsc28gaGF2ZSBhIHJlcXVlc3QgZnJvbSBCZW5vaXQgKGFuZCBBZHJpYW4sIGFuZCBKb2VsKSB0 byBtYWtlIHRoZSBkZXNjcmlwdGlvbiBhdA0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9zdXBhIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9zdXBhPC9hPiBtb3JlIHVuZGVyc3RhbmRhYmxlIGZvciBwZW9w bGUgd2hvIGhhdmVuJ3QgYmVlbiBmb2xsb3dpbmcgdGhlIHdvcmsgLSBpZiB5b3UgaW50ZW5kIHRv IGNoYXJ0ZXIgYSB3b3JraW5nIGdyb3VwLCB5b3UnbGwgd2FudCBwZW9wbGUgdG8gdW5kZXJzdGFu ZA0KIHdoYXQgeW91J3JlIHByb3Bvc2luZy48YnI+DQo8YnI+DQpZb3Ugc2hvdWxkIHByb2JhYmx5 IGtlZXAgaW4gbWluZCB0aGF0IHBlb3BsZSB3aG8gdGFsayBvdmVyIGEgbG9uZyBwZXJpb2Qgb2Yg dGltZSBhcmUgbGlrZWx5IHRvIGRldmVsb3AgYSBzaGFyZWQgdW5kZXJzdGFuZGluZyB0aGF0IHBl b3BsZSB3aG8gd2VyZW4ndCBpbnZvbHZlZCBkb24ndCB1bmRlcnN0YW5kIGNsZWFybHkuIElmIHRo ZXJlJ3MgYSBzbWFydCBuZXdjb21lciB3aG8gY291bGQgbG9vayBvdmVyIHByb2JsZW0gc3RhdGVt ZW50cywgcHJvcG9zZWQNCiBjaGFydGVycyBhbmQgc2VlIHdoYXQncyBub3QgY2xlYXIgdG8gbmV3 Y29tZXJzLCB0aGF0IHdvdWxkIGxpa2VseSBiZSBoZWxwZnVsIGFzIHdlbGwuPGJyPg0KPGJyPg0K VGhhbmtzLCBhbmQgYmVzdCB3aXNoZXMuIEknbGwgc2VlIHlvdSBpbiB0aGUgaGFsbHdheXMgb2Yg SG9ub2x1bHUsIHdoZXJlIGFsbCBBRHMgbHVyayBzb29uZXIgb3IgbGF0ZXIgLi4uPGJyPg0KPGJy Pg0KU3BlbmNlcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_C5034E44CD620A44971BAAEB372655DC635757LHREML516MBXchina_-- From nobody Mon Sep 22 06:59:14 2014 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDD751A1ACB for ; Mon, 22 Sep 2014 06:59:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.786] 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 huokGn0GUN_o for ; Mon, 22 Sep 2014 06:59:01 -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 615F41A1AD2 for ; Mon, 22 Sep 2014 06:41:50 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 2B2E073E; Mon, 22 Sep 2014 15:41:49 +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 r_FedII6tR5S; Mon, 22 Sep 2014 15:41:48 +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; Mon, 22 Sep 2014 15:41:48 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id C4EC320036; Mon, 22 Sep 2014 15:41:48 +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 xxhAedTudzw5; Mon, 22 Sep 2014 15:41:48 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0FEE120035; Mon, 22 Sep 2014 15:41:48 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 2FD742E85617; Mon, 22 Sep 2014 15:41:45 +0200 (CEST) Date: Mon, 22 Sep 2014 15:41:45 +0200 From: Juergen Schoenwaelder To: Georgios Karagiannis Message-ID: <20140922134145.GC18011@elstar.local> Mail-Followup-To: Georgios Karagiannis , Zhen Cao , Tina TSOU , "supa@ietf.org" References: <338BDC47F10D414AB0BC843C4D5DCFE085CE25@SJCEML701-CHM.china.huawei.com> 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: http://mailarchive.ietf.org/arch/msg/supa/U-7Q6XCVxsSNTNxeDTmAFgl-7OU Cc: Zhen Cao , "supa@ietf.org" , Tina TSOU Subject: Re: [Supa] Area hand-off, and some friendly advice ... X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 13:59:04 -0000 On Mon, Sep 22, 2014 at 01:27:08PM +0000, Georgios Karagiannis wrote: > > o) emphasize that regarding policy, enhancements of the YANG xPath expression might be required. > I am wondering what this is or why this would be needed. At the charter level, you may need to talk about defining data models to express policy. I do not see why that would need to enhancements of YANG's usage of xpath. /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 Mon Sep 22 13:17:52 2014 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC8BA1A1B0E for ; Mon, 22 Sep 2014 13:17:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.987 X-Spam-Level: X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 M-a2cxV_t-ZK for ; Mon, 22 Sep 2014 13:17:47 -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 9272F1A0367 for ; Mon, 22 Sep 2014 13:17:46 -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 BMW78039; Mon, 22 Sep 2014 20:17:42 +0000 (GMT) Received: from LHREML516-MBX.china.huawei.com ([169.254.1.85]) by lhreml404-hub.china.huawei.com ([::1]) with mapi id 14.03.0158.001; Mon, 22 Sep 2014 21:17:35 +0100 From: Georgios Karagiannis To: Juergen Schoenwaelder Thread-Topic: [Supa] Area hand-off, and some friendly advice ... Thread-Index: AQHPzqh9Us1IwolkWUGUssV+Mn5WLpwFfqEggAAWG8mAAKjywIAG0V4AgAAYJ7CAAACegIAAfwWQ Date: Mon, 22 Sep 2014 20:17:35 +0000 Message-ID: References: <338BDC47F10D414AB0BC843C4D5DCFE085CE25@SJCEML701-CHM.china.huawei.com> <20140922134145.GC18011@elstar.local> In-Reply-To: <20140922134145.GC18011@elstar.local> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.81.145] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/supa/k3qpPi4kjxUxWHjgJtuoAWrrSTs Cc: Zhen Cao , "supa@ietf.org" , Tina TSOU Subject: Re: [Supa] Area hand-off, and some friendly advice ... X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 20:17:49 -0000 Hi Juergen, Okay, thanks for your recommendation! Best regards, Georgios -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Monday, September 22, 2014 3:42 PM To: Georgios Karagiannis Cc: Zhen Cao; Tina TSOU; supa@ietf.org Subject: Re: [Supa] Area hand-off, and some friendly advice ... On Mon, Sep 22, 2014 at 01:27:08PM +0000, Georgios Karagiannis wrote: >=20 > o) emphasize that regarding policy, enhancements of the YANG xPath expres= sion might be required. >=20 I am wondering what this is or why this would be needed. At the charter lev= el, you may need to talk about defining data models to express policy. I do= not see why that would need to enhancements of YANG's usage of xpath. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Mon Sep 22 22:27:10 2014 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC6811A1A93 for ; Mon, 22 Sep 2014 22:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.987 X-Spam-Level: X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 qD0RKzQRayAF for ; Mon, 22 Sep 2014 22:27:08 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95C651A1A7B for ; Mon, 22 Sep 2014 22:27:07 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJS88573; Tue, 23 Sep 2014 05:27:06 +0000 (GMT) Received: from LHREML516-MBX.china.huawei.com ([169.254.1.85]) by lhreml404-hub.china.huawei.com ([::1]) with mapi id 14.03.0158.001; Tue, 23 Sep 2014 06:27:02 +0100 From: Georgios Karagiannis To: "supa@ietf.org" Thread-Topic: New Version Notification for draft-karagiannis-supa-problem-statement-00.txt Thread-Index: AQHP1u6VdExT8DNx/06P1LMj87cqfJwOL8Bw Date: Tue, 23 Sep 2014 05:27:02 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.89.197] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/supa/6rL4XaVOyW14lfXIeTZEYteJpaw Subject: [Supa] FW: New Version Notification for draft-karagiannis-supa-problem-statement-00.txt X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Sep 2014 05:27:09 -0000 SGkgYWxsLA0KDQpQbGVhc2Ugbm90ZSB0aGF0IHRoZSBTVVBBIHByb2JsZW0gc3RhdGVtZW50IGRy YWZ0IGhhdmUganVzdCBiZWVuIHN1Ym1pdHRlZCwgc2VlIGJlbG93IQ0KDQpCZXN0IHJlZ2FyZHMs DQpHZW9yZ2lvcw0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5l dC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2Vu dDogVHVlc2RheSwgU2VwdGVtYmVyIDIzLCAyMDE0IDc6MjQgQU0NClRvOiBRaW9uZyBTdW47IExp dXNodWNoZW5nIChXaWxsKTsgUWlvbmcgU3VuOyBHZW9yZ2lvcyBLYXJhZ2lhbm5pczsgVGluYSBU U09VOyBMaXVzaHVjaGVuZyAoV2lsbCk7IFRpbmEgVFNPVTsgUGFydml6IFllZ2FuaTsgRGllZ28g Ui4gTG9wZXo7IERpZWdvIExvcGV6OyBHZW9yZ2lvcyBLYXJhZ2lhbm5pczsgUGFydml6IFllZ2Fu aQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1rYXJhZ2lhbm5p cy1zdXBhLXByb2JsZW0tc3RhdGVtZW50LTAwLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1E LCBkcmFmdC1rYXJhZ2lhbm5pcy1zdXBhLXByb2JsZW0tc3RhdGVtZW50LTAwLnR4dA0KaGFzIGJl ZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBHZW9yZ2lvcyBLYXJhZ2lhbm5pcyBhbmQgcG9z dGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFmdC1rYXJhZ2lhbm5pcy1z dXBhLXByb2JsZW0tc3RhdGVtZW50DQpSZXZpc2lvbjoJMDANClRpdGxlOgkJUHJvYmxlbSBTdGF0 ZW1lbnQgZm9yIFNoYXJlZCBVbmlmaWVkIFBvbGljeSBBdXRvbWF0aW9uIChTVVBBKQ0KRG9jdW1l bnQgZGF0ZToJMjAxNC0wOS0yMA0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2Vz OgkJMTANClVSTDogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1rYXJhZ2lhbm5pcy1zdXBhLXByb2JsZW0tc3RhdGVtZW50LTAwLnR4dA0KU3RhdHVz OiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWthcmFnaWFu bmlzLXN1cGEtcHJvYmxlbS1zdGF0ZW1lbnQvDQpIdG1saXplZDogICAgICAgaHR0cDovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQta2FyYWdpYW5uaXMtc3VwYS1wcm9ibGVtLXN0YXRlbWVudC0w MA0KDQoNCkFic3RyYWN0Og0KICAgQXMgbW9kZXJuIG5ldHdvcmsgbWFuYWdlbWVudCBhcHBsaWNh dGlvbnMgZ3JvdyBpbiBzY2FsZQ0KICAgYW5kIGNvbXBsZXhpdHksIHRoZWlyIGRlbWFuZHMgYW5k IHJlcXVpcmVtZW50cyBvbiB0aGUgc3VwcG9ydGluZw0KICAgY29tbXVuaWNhdGlvbiBuZXR3b3Jr IGluY3JlYXNlLg0KICAgSW4gcGFydGljdWxhciwgbmV0d29yayBvcGVyYXRvcnMgYXJlIGNoYWxs ZW5nZWQgdG8gY3JlYXRlIGENCiAgIHNpbXBsaWZpZWQgdmlldyBvZiB0aGVpciBuZXR3b3JrIGlu ZnJhc3RydWN0dXJlIGFuZCBoZWxwIHNlcnZpY2UNCiAgIGRldmVsb3BlcnMgb24gdXNpbmcgYW5k IHByb2dyYW1taW5nIHRoaXMgc2ltcGxpZmllZCB2aWV3IHJhdGhlciB0aGFuDQogICBtYW5pcHVs YXRpbmcgaW5kaXZpZHVhbCBkZXZpY2VzLiBJbiB0aGlzIGNvbnRleHQsIHByb3ZpZGluZyBzZXJ2 aWNlDQogICBkZXZlbG9wZXJzIHdpdGggYSBzZXQgb2Ygc3RhbmRhcmQgaW50ZXJmYWNlcyB0byBj b25maWd1cmUgYW5kIHNldA0KICAgcG9saWNpZXMgb24gdGhlIG5ldHdvcmsgaXMgZXNzZW50aWFs Lg0KICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgd2hhdCBoYXMgdG8gYmUgYWRkcmVzc2VkIGlu IG9yZGVyIHRvIGVxdWlwDQogICBzZXJ2aWNlIHByb3ZpZGVycyB3aXRoIHN0YW5kYXJkaXplZCBh cHBsaWNhdGlvbi1iYXNlZCBpbnRlcmZhY2VzIHVzZWQNCiAgIHRvIGV4cG9zZSBhbmQgZGVmaW5l IHBvbGljaWVzIGFuZCBhIHNpbXBsaWZpZWQgdmlldyBvZiBuZXR3b3JrDQogICBpbmZyYXN0cnVj dHVyZS4NCg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhh dCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlz c2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0 IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Tue Sep 23 00:14:24 2014 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3A5F1A1BAF for ; Tue, 23 Sep 2014 00:14:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.387 X-Spam-Level: X-Spam-Status: No, score=-4.387 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 5RB630dL0Ocq for ; Tue, 23 Sep 2014 00:14: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 CC0D11A1A29 for ; Tue, 23 Sep 2014 00:14:12 -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 BJS97555; Tue, 23 Sep 2014 07:14:11 +0000 (GMT) Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 23 Sep 2014 08:14:10 +0100 Received: from szxeml557-mbs.china.huawei.com ([169.254.6.57]) by szxeml401-hub.china.huawei.com ([::1]) with mapi id 14.03.0158.001; Tue, 23 Sep 2014 15:13:53 +0800 From: Tina TSOU To: Georgios Karagiannis , "Juergen Schoenwaelder" Thread-Topic: [Supa] Area hand-off, and some friendly advice ... Thread-Index: AQHPzqh9GTuRDclUaESQdripqpP+jZwFfqEggAAWG8mAACvmgIAG2RIAgAAUrwCAAAQVgIAAbpmAgAE7Y1A= Date: Tue, 23 Sep 2014 07:13:53 +0000 Message-ID: References: <338BDC47F10D414AB0BC843C4D5DCFE085CE25@SJCEML701-CHM.china.huawei.com> <20140922134145.GC18011@elstar.local> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.46.142.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/supa/XNoJc3WTMKIE05WL-xU4ruxpWsU Cc: Zhen Cao , "supa@ietf.org" Subject: Re: [Supa] Area hand-off, and some friendly advice ... X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Sep 2014 07:14:20 -0000 Dear all, Hope this version of draft charter address most of the comments from the li= st. ------ SUPA (Shared Unified Policy Automation) Target Area: OPS=20 Description of Working Group: Network operators are faced with networks of increasing size and complexity= while trying to improve their quality and availability, as more and more s= ervices depend on them. Programmatic ways to configure networks, often call= ed software-defined, are considered by many network operators in order to s= hift the balance in their favor. Automating the way of exposing a view of the network to applications may pr= ovide significant improvements in configuration agility, error detection an= d uptime for operators. However the real value behind central configuration= schemes lies within the possible simplification through models provided by= such systems to applications and network services running above them (on t= he so-called northbound side). Well-designed models are able to provide a w= ide range of granularity for various applications and network services need= s, from the lower-level physical network to high-level application services= .=20 Although several organizations outside of the IETF have defined various sch= emes for the configuration of network devices and specific network controll= ers, none of them offer a vendor-neutral standardized way for applications = and network services to transmit their needs to controllers. The SUPA (Shar= ed Unified Policy Automation) working group will work on the definition of = such as standardized interface for applications and network services to com= municate with network controllers of all types. The specification of the interface towards end user apllications is initial= ly not in the scope of SUPA. In particular, as starting point, SUPA will on= ly focus on network services, which are enhanced Operational Support System= (OSS) like services that help a communication service provider to monitor,= control, analyze and manage a communication network. The systems that are = runniung such network services are denoted in this document as Network Serv= ice Systems.=20 Each network service can be represented by a classified application based P= OLICY model, since it can model the group of demands which are SHARED and U= NIFIED and are coming from a bundle of applications that impose similar req= uirements on the communication network.=20 The main goal of SUPA is to provide a way for applications and for network = services to specify SHARED application based POLICIES to the network infras= tructure using a simplified view of the network. This can be realized by:=20 (1) modeling the network infrastructure as an simplified network graph usin= g a modeling language such=20 as YANG, (2) transporting model instances either using NETCONF or RESTCONF = and (3) providing guidelines on AUTOMATICALLY mapping policies to attribute= s of the network graphs. Although some IETF working groups have started work relating to the descrip= tion of various topologies such as I2RS (L3and routing topologies), ALTO (c= ost maps), SFC (service chain), none of these groups aim at offering truly = generic topology models for the standard northbound interface. SUPA will work on defining interfaces based on the concept of network graph= , an entity describing an arbitrary topology of nodes and links at any leve= l of granularity. Such a graph may describe, for example, a physical topolo= gy, a service topology or the relationships between datacenters. Any networ= k topology data models or policy models that have been defined (or are bein= g defined) within the IETF will be reused in SUPA as much as possible. In addition to the above, policies may be defined and applied to a network = graph. These application based policies are actions or constraints generate= d by Network Service Systems. They are then mapped from the network graph i= nstance into specific network management policies toward network components= .=20 =20 Work items for SUPA include: 1) The definition of a standardized model for a network graph, using YANG. = This model may be used to describe topologies at any functional layer, from= physical networks to network services.=20 Any network topology data models or policy models that have been defined (o= r are being defined) within the IETF will be reused in SUPA as much as poss= ible. 2) The definition and standardization of a number of basic policy and data = models using network graphs. These might include, but are not limited to L3= VPNs, datacenters, traffic engineering, implementation of IPv6 transition m= echanism and their enforcement to users. =20 3) Guidelines on how to use NETCONF (or RESTCONF) authentication and author= ization mechanisms to achieve protection and isolation 4) Guidelines for automatic mapping policies to attributes of the network g= raphs. The following items are out of the SUPA scope: o) specification of the network management and controlling policies and the= ir associated device configuration models Milestones: o) Produce 'Problem Statement and Use Cases' as an Informational RFC. o) Produce a document specifying the YANG models for a generic multi-layer = network graph, as Protocol Specification' Standards Track RFC. o) Produce several documents describing different views of a communication = network by using the network graph model defined above, which includes poli= cy and data models, as Protocol Specifications' Standards Track RFCs. o) Produce a document on defining the SUPA NETCON/YANG or RESTCONF (or REST= CONF/YANG) containers, as Protocol Specification' Standards Track RFC. =20 o) Produce a document that provides the guidelines on using NETCONF (or RES= TCONF) authentication and authorization mechanisms to achieve security prot= ection and isolation' as an Informational RFC. o) Produce a document that provides the guidelines for for automatic mappin= g policies to attributes of the network graphs. ----------- Thank you, Tina -----Original Message----- From: Georgios Karagiannis=20 Sent: Tuesday, September 23, 2014 4:18 AM To: Juergen Schoenwaelder Cc: Zhen Cao; Tina TSOU; supa@ietf.org Subject: RE: [Supa] Area hand-off, and some friendly advice ... Hi Juergen, Okay, thanks for your recommendation! Best regards, Georgios -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Monday, September 22, 2014 3:42 PM To: Georgios Karagiannis Cc: Zhen Cao; Tina TSOU; supa@ietf.org Subject: Re: [Supa] Area hand-off, and some friendly advice ... On Mon, Sep 22, 2014 at 01:27:08PM +0000, Georgios Karagiannis wrote: >=20 > o) emphasize that regarding policy, enhancements of the YANG xPath expres= sion might be required. >=20 I am wondering what this is or why this would be needed. At the charter lev= el, you may need to talk about defining data models to express policy. I do= not see why that would need to enhancements of YANG's usage of xpath. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Tue Sep 23 02:03:46 2014 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06F6B1A6F86 for ; Tue, 23 Sep 2014 02:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.036 X-Spam-Level: X-Spam-Status: No, score=-3.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.786] 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 BMDHJGyHkqz9 for ; Tue, 23 Sep 2014 02:03:43 -0700 (PDT) Received: from mx2.eict.de (mx2.eict.de [212.91.241.168]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD0B1A6F81 for ; Tue, 23 Sep 2014 02:03:43 -0700 (PDT) Received: by mx2.eict.de (Postfix, from userid 481) id F12581FF47; Tue, 23 Sep 2014 11:03:41 +0200 (CEST) Received: from mail.eict.de (mx1 [172.16.6.1]) by mx2.eict.de (Postfix) with ESMTP id 9C8CC1FF44 for ; Tue, 23 Sep 2014 11:03:41 +0200 (CEST) Received: from sbs2008.eict.local (sbs2008.intern.eict.de [192.168.2.11]) by mail.eict.de (Postfix) with ESMTP id 42BB9378210 for ; Tue, 23 Sep 2014 11:03:41 +0200 (CEST) Received: from SBS2008.eict.local ([fe80::2051:ef24:c7c9:f298]) by SBS2008.eict.local ([fe80::2051:ef24:c7c9:f298%13]) with mapi; Tue, 23 Sep 2014 11:03:41 +0200 From: Kostas Pentikousis To: "supa@ietf.org" Date: Tue, 23 Sep 2014 11:03:41 +0200 Thread-Topic: SUPA configuration Thread-Index: Ac/XDUV2WRG39A2RRhulmslaxrwgbQ== Message-ID: <0C7EDCF89AB9E2478B5D010026CFF4AEA10C72AAB7@SBS2008.eict.local> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/supa/BdJ0f7wRLg1unKCUtmTRR3qcnPM Subject: [Supa] SUPA configuration X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Sep 2014 09:03:45 -0000 Dear All, We have been working on two drafts on SUPA configuration. The first one (SU= PA Configuration and Policy Mapping, http://datatracker.ietf.org/doc/draft-= pentikousis-supa-mapping/) discusses mapping of an abstract view to device-= level configuration. The second one (YANG Data Model for Configuration of S= hared Unified Policy Automation (SUPA), https://datatracker.ietf.org/doc/dr= aft-zaalouk-supa-configuration-model/) introduces our early stage work on a= few YANG models for L3VPN, IP TE etc. We're looking forward to your comments and suggestions.=20 Best regards, Kostas From nobody Tue Sep 23 06:38:45 2014 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B6E61A1AC4 for ; Tue, 23 Sep 2014 06:38:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.736 X-Spam-Level: X-Spam-Status: No, score=-1.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_14=0.6, RP_MATCHES_RCVD=-0.786] 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 v-1nj6eVwAQ4 for ; Tue, 23 Sep 2014 06:38:41 -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 38BB61A8028 for ; Tue, 23 Sep 2014 06:38:41 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id AFBA5751; Tue, 23 Sep 2014 15:38:39 +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 l-doWDwClreP; Tue, 23 Sep 2014 15:38:37 +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; Tue, 23 Sep 2014 15:38:38 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7457D20036; Tue, 23 Sep 2014 15:38:38 +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 W4wrOawlsoAy; Tue, 23 Sep 2014 15:38:37 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5E5CC20035; Tue, 23 Sep 2014 15:38:36 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 4D2002E86ABA; Tue, 23 Sep 2014 15:38:36 +0200 (CEST) Date: Tue, 23 Sep 2014 15:38:36 +0200 From: Juergen Schoenwaelder To: Tina TSOU Message-ID: <20140923133836.GC21261@elstar.local> Mail-Followup-To: Tina TSOU , Georgios Karagiannis , Zhen Cao , "supa@ietf.org" References: <338BDC47F10D414AB0BC843C4D5DCFE085CE25@SJCEML701-CHM.china.huawei.com> <20140922134145.GC18011@elstar.local> 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: http://mailarchive.ietf.org/arch/msg/supa/CJPQJMp6afY_Akjh8JpFcuBgB_o Cc: Georgios Karagiannis , Zhen Cao , "supa@ietf.org" Subject: Re: [Supa] Area hand-off, and some friendly advice ... X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Sep 2014 13:38:43 -0000 On Tue, Sep 23, 2014 at 07:13:53AM +0000, Tina TSOU wrote: > Dear all, > > Hope this version of draft charter address most of the comments from the list. > Each network service can be represented by a classified application based POLICY model, since it can model the group of demands which are SHARED and UNIFIED and are coming from a bundle of applications that impose similar requirements on the communication network. I am lost here. Thanks for trying to explain shared and unified but this text does not explain things to me. I also have no clue what a 'classified' policy model is. Perhaps it is a phrasing issue, I do not know. > The main goal of SUPA is to provide a way for applications and for network services to specify SHARED application based POLICIES to the network infrastructure using a simplified view of the network. This can be realized by: > (1) modeling the network infrastructure as an simplified network graph using a modeling language such > as YANG, (2) transporting model instances either using NETCONF or RESTCONF and (3) providing guidelines on AUTOMATICALLY mapping policies to attributes of the network graphs. I am still unclear what "shared" here implies/means. I also learn from this text that policies are not expressed as attributes of network graphs. Why is this so? Is your idea that a policy exists between say to endpoints of a virtual link and the attributes are the concrete properties of the collection of links and nodes making up the virtual link? Are these guidelines expected to go N layers deep or do we stop somewhere (e.g. when we leave the "territory of IETF protocols")? If this is a correct understanding of the intention, I think this should be clarified. If this is not a correct understanding of the intention, this must be clarified. ;-) > Although some IETF working groups have started work relating to the description of various topologies such as I2RS (L3and routing topologies), ALTO (cost maps), SFC (service chain), none of these groups aim at offering truly generic topology models for the standard northbound interface. > SUPA will work on defining interfaces based on the concept of network graph, an entity describing an arbitrary topology of nodes and links at any level of granularity. Such a graph may describe, for example, a physical topology, a service topology or the relationships between datacenters. Any network topology data models or policy models that have been defined (or are being defined) within the IETF will be reused in SUPA as much as possible. > In addition to the above, policies may be defined and applied to a network graph. These application based policies are actions or constraints generated by Network Service Systems. They are then mapped from the network graph instance into specific network management policies toward network components. Here I get lost again. Here it says "policies may be defined and applied to a network graph". Above, you wrote "guidelines on AUTOMATICALLY mapping policies to attributes of the network graphs". Here you write "They are then mapped from the network graph instance to specific network management policies toward network components". How does that related to your previous text? Is it useful to call device configurations policies as well?0 > Work items for SUPA include: > > 1) The definition of a standardized model for a network graph, using YANG. This model may be used to describe topologies at any functional layer, from physical networks to network services. > Any network topology data models or policy models that have been defined (or are being defined) within the IETF will be reused in SUPA as much as possible. If you shoot for a generic model and the other models are indeed not generic (not sure yet this will be true but too early to tell), then how can you incorporate them? Perhaps it is more honest to say that mappings to other network topology data models will be defined or something like that. > 2) The definition and standardization of a number of basic policy and data models using network graphs. These might include, but are not limited to L3VPNs, datacenters, traffic engineering, implementation of IPv6 transition mechanism and their enforcement to users. Again, I consider data centers to be problematic. Is your idea to leave it in on purpose so that people have something to argue against and you finally take it out later? > o) Produce a document on defining the SUPA NETCON/YANG or RESTCONF (or RESTCONF/YANG) containers, as Protocol Specification' Standards Track RFC. I have no clue what this would be or why it is needed. A YANG data model does not need any extra definitions to be usable. /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 Tue Sep 23 09:31:42 2014 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC1D71A8721 for ; Tue, 23 Sep 2014 09:31:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.6 X-Spam-Level: X-Spam-Status: No, score=-5.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, 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 UyMlAmSEaO9G for ; Tue, 23 Sep 2014 09:31:30 -0700 (PDT) Received: from st11p01mm-asmtp002.mac.com (st11p01mm-asmtp002.mac.com [17.172.204.237]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3FDE1A1B18 for ; Tue, 23 Sep 2014 09:31:29 -0700 (PDT) Received: from [10.1.1.30] (162-211-8-194.aereotv.net [162.211.8.194]) by st11p01mm-asmtp002.mac.com (Oracle Communications Messaging Server 7u4-27.10(7.0.4.27.9) 64bit (built Jun 6 2014)) with ESMTPSA id <0NCD001GF4KFXX80@st11p01mm-asmtp002.mac.com> for supa@ietf.org; Tue, 23 Sep 2014 16:31:29 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52,1.0.28,0.0.0000 definitions=2014-09-23_06:2014-09-23,2014-09-23,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=1 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1409230153 From: Marie-Jose Montpetit Content-type: multipart/alternative; boundary="Apple-Mail=_A983977C-E212-46F0-8033-8515B5CEFDAF" Message-id: <2A1C1DCE-7839-47C1-8E53-1635BE932E7D@me.com> MIME-version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Date: Tue, 23 Sep 2014 12:31:26 -0400 References: To: supa@ietf.org In-reply-to: X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/supa/WblnmX0eWiFY8Ocf7j2MeaGkLpQ Subject: Re: [Supa] Supa Digest, Vol 2, Issue 22 X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Sep 2014 16:31:37 -0000 --Apple-Mail=_A983977C-E212-46F0-8033-8515B5CEFDAF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Some comments on comments below. > From: Zhen Cao > Subject: Re: [Supa] Area hand-off, and some friendly advice ... > Date: September 22, 2014 at 8:13:06 AM EDT > To: Tina TSOU > Cc: "supa@ietf.org" >=20 >=20 > Hello Tina and everybody,=20 >=20 > I have some comments about the scope of SUPA, as a newly coming = reader. See the comments in line.=20 >=20 > Best regards, > zhen > SUPA (Shared Unified Policy Automation) >=20 > Target Area: OPS >=20 > Description of Working Group: >=20 > Network operators are faced with networks of increasing size and = complexity while trying to improve their quality and availability, as = more and more services depend on them. Programmatic ways to configure = networks, often called software-defined, are considered by many network = operators in order to shift the balance in their favor. This seems vague - what size? Shift which balance in their favor? What = do you mean by that? >=20 > Automation of configuration may provide significant improvements in = configuration agility, error detection and uptime for operators. However = the real value behind central configuration schemes lies within the = possible simplification through abstraction provided by such systems to = applications running above them (on the so-called northbound side). = Well-designed abstractions are able to provide a wide range of = granularity for various applications needs, from the lower-level = physical network to high-level application services. >=20 > After the first two paragraph, I am really expecting a full = introduction of SUPA, especially what the four-letter abbreviation means = physically. =20 I agree what is supa and what is targeting in the above. > =20 > Although several organizations outside of the IETF have defined = various schemes for the configuration of network devices and specific = network controllers, none of them offer a vendor-neutral standardized = way for applications to transmit their needs to controllers. The SUPA = (Shared Unified Policy Automation) working group will work on the = definition of such as standardized interface for applications to = communicate with network controllers of all types.=20 Several, various.. please specify.=20 >=20 > The interface definitions will be based on the concept of network = graph, an entity describing an arbitrary topology of nodes and links at = any level of abstraction and granularity. > 'Any level of abstraction' is very aggressive to me, good to you guys? = What's the level of abstraction will the group focus on? Agree - this needs a more focused scope. > =20 > Such a graph may describe, for example, a physical topology, a L2 = network, a service topology or the relationships between datacenters. = Although some IETF working groups have started work relating to the = description of various topologies such as I2RS (L3 and routing = topologies), ALTO (cost maps), SFC (service chain), none of these groups = aim at offering a truly generic multi-layer and abstract topology for = standard northbound configuration. There could be a reason for this... Maybe we need words that say why we = think supa will be able to create some umbrella architecture and = protocols superseeding all of these. >=20 > Work items for SUPA include: >=20 > How about moving the easier items to the front, e.g. the problem = statement and requirement. Normally these are the prerequisite for any = chartered technical items, basic on which the = definition/specification/choice making work can kick-off. Btw, the five = items charter also seems aggressive too.=20 > =20 >=20 > 1) Choice of a modeling language used by the group to describe the = network graph. Existing modeling languages such as YANG will be = considered for this purpose unless no suitable one is found. Can there be a pointer to YANG? Is there IPR attached to it that needs = disclosure? >=20 > 2) Choice of a transport protocol for the modeling language mentioned = above. The group will re-use a protocol already defined as a transport = for the modeling language, such as NETCONF or RESTCONF in the case of = YANG. >=20 > 3) The definition of a standardized model for a network topology = graph. This model may be used to describe topologies at any functional = layer, from physical networks to network services and higher = abstractions. The nodes of this graph may describe physical nodes as = well as virtualized ones. Great goal but again seems overly ambitious. >=20 > 4) The definition and standardization of a number of basic abstracted = models using network graphs. These might include, but are not limited = to, L3VPNs, L2VPNs, datacenters, traffic engineering, implementation of = IPv6 transition mechanism and their enforcement to users. Again very wide and most likely not achievable in a group based on = concenssus. I would suggest focusing on 2 max. > =20 >=20 > 5) Guidelines for the mapping of abstract model information to = physical or virtualized network components. =20 >=20 > Proposed milestones for the working group: >=20 > - Produce a problem statement document for SUPA. >=20 > - Produce a gap analysis for SUPA in order to verify overlap with = the work of other IETF groups. >=20 > - Produce a requirement document describing the desired properties = of an abstract multi-layer network graph definition. >=20 > - Produce a gap analysis of existing modeling language, their = characteristics, possible transport protocols and how they compare to = the SUPA requirements. >=20 > - Produce a document specifying the model for a generic multi-layer = network graph. >=20 > - Produce several documents describing different levels of abstract = views using the network graph model defined above, including physical = view, logical view, layer-3 view, configuration view, performance = probing view, service view and other such as L3VPN, L2VPN, datacenters = and traffic engineering. =20 >=20 > ------------ >=20 >=20 > * OPENv6, APONF and SUPA group historic perspective > = ------------------------------------------------------------------------- >=20 > Most IETF working groups are formed in the interest of solving some = actual real-world problem from network operators, developers or = manufacturers and the initial work from the OPENv6 group was no = exception. Some operators saw a common interest in defining a common = approach for the deployment of IPv6 transition tools. Although the = preferred way of deploying IPv6 remains by dual-stacking, several = operators have deployed additional transition tools such as 6RD = (RFC5969), DS-Lite (RFC6333), NAT64 (RFC6146) and others with the intent = of speeding up or to provide more flexibility in their IPv6 services. = Each of these protocols presents its own set of deployment challenges = and failure modes for users, either because of unsupported applications, = partial implementations in some off-the-shelf devices such as home = routers or some limitations of the protocols themselves to name a few = cases.=20 >=20 > The fact these protocols are often deployed with techniques targeting = the extension of IPv4 service, such as Carrier Grade NAT, making their = deployment even more complex, especially when targeting minimal end-user = impact. Although some approaches in solving this were proposed, for = example in RFC6264, the market hasn't seen the advent of configurable = CGN devices or adaptive home gateways. The only solution for operators = is to have an agile way to provision rapidly and easily any type of IPv6 = or IPv4 service depending of the specific needs of each end-user and = their device. These changes must be performed with respect to the = operator existing policies regarding the network, billing, security and = other constraints.=20 >=20 > While exploring these issues, it became clear the best way to address = them would be to use a central controller that would be able to = coordinate the deployment of different protocols amongst several devices = in a consistent fashion. Such a controller would receive high-level = policy information from a management application, transform it in = network-level configuration and apply it to physical or virtual devices. = At that point, several other use cases outside of the deployment of IPv6 = started to emerge, for example for the control of data center traffic = steering, for the creation of tunnels and the provisioning of L3VPN. The = group decided to rename its activities under the acronym APONF, for = Application Policy on Network Functions, which seemed a more fitting = name. The definition of policies by a management application toward a = network controller would be at the center of the work for the group. = Several group documents were created around this concept.=20 >=20 > When presented at a bar bof during IETF-90 in Toronto, most of the = feedback was positive, but the scope of the work was often judged too = large in scope. It wasn't clear either how much overlap there was with = other IETF groups. A better analysis of this aspect in the following = weeks revealed some level of overlap with other groups, but also where = deficiencies exist. The two aspects where IETF work seems to be lacking = are in the definition of high-level policy language for applications and = also in a standard model to describe network topologies at different = levels of granularity, or abstraction. Some existing working groups have = published work on the latter. For example, the ALTO working group = defined a way to describe network functions at different level of = granularity using cost maps, but this approach does not seem practical = for the description of complex network topologies to and from a central = controller. A topology draft exists in the I2RS group, but it is very = centered ! > around ro > uting protocols and L2-L3 links.=20 >=20 > The group has recently renamed its activities under the SUPA (Shared = Unified Policy Automation) acronym with the intention of defining a = standard way to push policies to a central controller. It appears, = however, that in order to define such policies, the definition of a = standard multi-layer model for the description of networks of all types = would be desirable. Therefore the initial work for the SUPA group would = be to select an existing modeling language and define a clear = multi-layer model able to describe network or service information at any = level of granularity or complexity. > -------------- >=20 >=20 > Thank you, > Tina >=20 > -----Original Message----- > From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Spencer Dawkins > Sent: Friday, September 12, 2014 9:42 AM > To: supa@ietf.org > Cc: Benoit Claise > Subject: [Supa] Area hand-off, and some friendly advice ... >=20 > Dear SUPA friends, >=20 > Several IESG members had a chat earlier this week, and decided that = SUPA really belongs in OPS. I've requested that the area affiliation in = http://www.ietf.org/list/nonwg.html be updated to reflect that. >=20 > Benoit will be your AD for additional charter discussion. >=20 > If I might offer some friendly advice, several ADs are fairly confused = about the relationship between openv6, APONF, and SUPA. If you could put = together a short paragraph that's something like "we started openv6 to = do X, then we realized we needed to do Y so we proposed APONF, and after = discussions in Toronto, we chose a different direction with SUPA because = of Z", that would be very helpful. >=20 > I also have a request from Benoit (and Adrian, and Joel) to make the = description athttps://www.ietf.org/mailman/listinfo/supa more = understandable for people who haven't been following the work - if you = intend to charter a working group, you'll want people to understand what = you're proposing. >=20 > You should probably keep in mind that people who talk over a long = period of time are likely to develop a shared understanding that people = who weren't involved don't understand clearly. If there's a smart = newcomer who could look over problem statements, proposed charters and = see what's not clear to newcomers, that would likely be helpful as well. >=20 > Thanks, and best wishes. I'll see you in the hallways of Honolulu, = where all ADs lurk sooner or later ... >=20 > Spencer >=20 >=20 >=20 >=20 > From: Georgios Karagiannis > Subject: Re: [Supa] Area hand-off, and some friendly advice ... > Date: September 22, 2014 at 9:27:08 AM EDT > To: Zhen Cao , Tina TSOU = > Cc: "supa@ietf.org" >=20 >=20 > Hi Zhen, > =20 > Thank you very much for the comments. > =20 > In the next version of the charter, we will: > o) emphasize the main goal of SUPA: > =20 > The main goal of SUPA is to provide a way for applications to = specify > policies to the network infrastructure using a simplified view of > network. This can be realized by: (1) modeling the network > infrastructure as an simplified network graph using a modeling > language such as YANG (2) transporting model > instances either using NETCONF or RESTCONF and (3) providing = guidelines on > mapping policies to attributes of the network graphs. > =20 > o) emphasize that as starting point, for applications, we will focus = only on network services > =20 > o) emphasize that we will focus on policy and data models that are = able to provide enough details on the used network and service topology. > =20 > o) emphasize that regarding policy, enhancements of the YANG xPath = expression might be required. > =20 > Best regards, > Georgios > =20 > =20 > =20 > From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Zhen Cao > Sent: Monday, September 22, 2014 2:13 PM > To: Tina TSOU > Cc: supa@ietf.org > Subject: Re: [Supa] Area hand-off, and some friendly advice ... > =20 > Hello Tina and everybody,=20 > =20 > I have some comments about the scope of SUPA, as a newly coming = reader. See the comments in line.=20 > =20 > Best regards, > zhen > SUPA (Shared Unified Policy Automation) >=20 > Target Area: OPS >=20 > Description of Working Group: >=20 > Network operators are faced with networks of increasing size and = complexity while trying to improve their quality and availability, as = more and more services depend on them. Programmatic ways to configure = networks, often called software-defined, are considered by many network = operators in order to shift the balance in their favor. >=20 > Automation of configuration may provide significant improvements in = configuration agility, error detection and uptime for operators. However = the real value behind central configuration schemes lies within the = possible simplification through abstraction provided by such systems to = applications running above them (on the so-called northbound side). = Well-designed abstractions are able to provide a wide range of = granularity for various applications needs, from the lower-level = physical network to high-level application services. > =20 > After the first two paragraph, I am really expecting a full = introduction of SUPA, especially what the four-letter abbreviation means = physically. =20 > =20 > Although several organizations outside of the IETF have defined = various schemes for the configuration of network devices and specific = network controllers, none of them offer a vendor-neutral standardized = way for applications to transmit their needs to controllers. The SUPA = (Shared Unified Policy Automation) working group will work on the = definition of such as standardized interface for applications to = communicate with network controllers of all types.=20 >=20 > The interface definitions will be based on the concept of network = graph, an entity describing an arbitrary topology of nodes and links at = any level of abstraction and granularity. > 'Any level of abstraction' is very aggressive to me, good to you guys? = What's the level of abstraction will the group focus on? > =20 > Such a graph may describe, for example, a physical topology, a L2 = network, a service topology or the relationships between datacenters. = Although some IETF working groups have started work relating to the = description of various topologies such as I2RS (L3 and routing = topologies), ALTO (cost maps), SFC (service chain), none of these groups = aim at offering a truly generic multi-layer and abstract topology for = standard northbound configuration. >=20 > Work items for SUPA include: > =20 > How about moving the easier items to the front, e.g. the problem = statement and requirement. Normally these are the prerequisite for any = chartered technical items, basic on which the = definition/specification/choice making work can kick-off. Btw, the five = items charter also seems aggressive too.=20 > =20 >=20 > 1) Choice of a modeling language used by the group to describe the = network graph. Existing modeling languages such as YANG will be = considered for this purpose unless no suitable one is found. >=20 > 2) Choice of a transport protocol for the modeling language mentioned = above. The group will re-use a protocol already defined as a transport = for the modeling language, such as NETCONF or RESTCONF in the case of = YANG. >=20 > 3) The definition of a standardized model for a network topology = graph. This model may be used to describe topologies at any functional = layer, from physical networks to network services and higher = abstractions. The nodes of this graph may describe physical nodes as = well as virtualized ones. >=20 > 4) The definition and standardization of a number of basic abstracted = models using network graphs. These might include, but are not limited = to, L3VPNs, L2VPNs, datacenters, traffic engineering, implementation of = IPv6 transition mechanism and their enforcement to users. =20 >=20 > 5) Guidelines for the mapping of abstract model information to = physical or virtualized network components. =20 >=20 > Proposed milestones for the working group: >=20 > - Produce a problem statement document for SUPA. >=20 > - Produce a gap analysis for SUPA in order to verify overlap with = the work of other IETF groups. >=20 > - Produce a requirement document describing the desired properties = of an abstract multi-layer network graph definition. >=20 > - Produce a gap analysis of existing modeling language, their = characteristics, possible transport protocols and how they compare to = the SUPA requirements. >=20 > - Produce a document specifying the model for a generic multi-layer = network graph. >=20 > - Produce several documents describing different levels of abstract = views using the network graph model defined above, including physical = view, logical view, layer-3 view, configuration view, performance = probing view, service view and other such as L3VPN, L2VPN, datacenters = and traffic engineering. =20 >=20 > ------------ >=20 >=20 > * OPENv6, APONF and SUPA group historic perspective > = ------------------------------------------------------------------------- >=20 > Most IETF working groups are formed in the interest of solving some = actual real-world problem from network operators, developers or = manufacturers and the initial work from the OPENv6 group was no = exception. Some operators saw a common interest in defining a common = approach for the deployment of IPv6 transition tools. Although the = preferred way of deploying IPv6 remains by dual-stacking, several = operators have deployed additional transition tools such as 6RD = (RFC5969), DS-Lite (RFC6333), NAT64 (RFC6146) and others with the intent = of speeding up or to provide more flexibility in their IPv6 services. = Each of these protocols presents its own set of deployment challenges = and failure modes for users, either because of unsupported applications, = partial implementations in some off-the-shelf devices such as home = routers or some limitations of the protocols themselves to name a few = cases.=20 >=20 > The fact these protocols are often deployed with techniques targeting = the extension of IPv4 service, such as Carrier Grade NAT, making their = deployment even more complex, especially when targeting minimal end-user = impact. Although some approaches in solving this were proposed, for = example in RFC6264, the market hasn't seen the advent of configurable = CGN devices or adaptive home gateways. The only solution for operators = is to have an agile way to provision rapidly and easily any type of IPv6 = or IPv4 service depending of the specific needs of each end-user and = their device. These changes must be performed with respect to the = operator existing policies regarding the network, billing, security and = other constraints.=20 >=20 > While exploring these issues, it became clear the best way to address = them would be to use a central controller that would be able to = coordinate the deployment of different protocols amongst several devices = in a consistent fashion. Such a controller would receive high-level = policy information from a management application, transform it in = network-level configuration and apply it to physical or virtual devices. = At that point, several other use cases outside of the deployment of IPv6 = started to emerge, for example for the control of data center traffic = steering, for the creation of tunnels and the provisioning of L3VPN. The = group decided to rename its activities under the acronym APONF, for = Application Policy on Network Functions, which seemed a more fitting = name. The definition of policies by a management application toward a = network controller would be at the center of the work for the group. = Several group documents were created around this concept.=20 >=20 > When presented at a bar bof during IETF-90 in Toronto, most of the = feedback was positive, but the scope of the work was often judged too = large in scope. It wasn't clear either how much overlap there was with = other IETF groups. A better analysis of this aspect in the following = weeks revealed some level of overlap with other groups, but also where = deficiencies exist. The two aspects where IETF work seems to be lacking = are in the definition of high-level policy language for applications and = also in a standard model to describe network topologies at different = levels of granularity, or abstraction. Some existing working groups have = published work on the latter. For example, the ALTO working group = defined a way to describe network functions at different level of = granularity using cost maps, but this approach does not seem practical = for the description of complex network topologies to and from a central = controller. A topology draft exists in the I2RS group, but it is very = centered ! > around ro > uting protocols and L2-L3 links.=20 >=20 > The group has recently renamed its activities under the SUPA (Shared = Unified Policy Automation) acronym with the intention of defining a = standard way to push policies to a central controller. It appears, = however, that in order to define such policies, the definition of a = standard multi-layer model for the description of networks of all types = would be desirable. Therefore the initial work for the SUPA group would = be to select an existing modeling language and define a clear = multi-layer model able to describe network or service information at any = level of granularity or complexity. > -------------- >=20 >=20 > Thank you, > Tina >=20 > -----Original Message----- > From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Spencer Dawkins > Sent: Friday, September 12, 2014 9:42 AM > To: supa@ietf.org > Cc: Benoit Claise > Subject: [Supa] Area hand-off, and some friendly advice ... >=20 > Dear SUPA friends, >=20 > Several IESG members had a chat earlier this week, and decided that = SUPA really belongs in OPS. I've requested that the area affiliation in = http://www.ietf.org/list/nonwg.html be updated to reflect that. >=20 > Benoit will be your AD for additional charter discussion. >=20 > If I might offer some friendly advice, several ADs are fairly confused = about the relationship between openv6, APONF, and SUPA. If you could put = together a short paragraph that's something like "we started openv6 to = do X, then we realized we needed to do Y so we proposed APONF, and after = discussions in Toronto, we chose a different direction with SUPA because = of Z", that would be very helpful. >=20 > I also have a request from Benoit (and Adrian, and Joel) to make the = description athttps://www.ietf.org/mailman/listinfo/supa more = understandable for people who haven't been following the work - if you = intend to charter a working group, you'll want people to understand what = you're proposing. >=20 > You should probably keep in mind that people who talk over a long = period of time are likely to develop a shared understanding that people = who weren't involved don't understand clearly. If there's a smart = newcomer who could look over problem statements, proposed charters and = see what's not clear to newcomers, that would likely be helpful as well. >=20 > Thanks, and best wishes. I'll see you in the hallways of Honolulu, = where all ADs lurk sooner or later ... >=20 > Spencer > =20 >=20 >=20 > _______________________________________________ > Supa mailing list > Supa@ietf.org > https://www.ietf.org/mailman/listinfo/supa --Apple-Mail=_A983977C-E212-46F0-8033-8515B5CEFDAF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Some comments on comments = below.

From: Zhen Cao <zhencao.ietf@gmail.com>
Subject: Re: [Supa] Area hand-off, and some = friendly advice ...
Date: September 22, 2014 at 8:13:06 AM = EDT


Hello Tina and everybody, 

I have = some comments about the scope of SUPA, as a newly coming reader.  = See the comments in line. 

Best = regards,
zhen

SUPA (Shared Unified Policy = Automation)

Target Area: = OPS

Description of Working Group:

Network operators are = faced with networks of increasing size and complexity while trying to = improve their quality and availability, as more and more services depend = on them. Programmatic ways to configure networks, often  called = software-defined, are considered by many network operators in order to = shift the balance in their = favor.
<= /div>
This seems vague - what size? Shift which = balance in their favor? What do you mean by that?

Automation of configuration may provide significant = improvements in configuration agility, error detection and uptime for = operators. However the real value behind central configuration schemes = lies within the possible simplification through abstraction provided by = such systems to applications running above them (on the so-called = northbound side). Well-designed abstractions are able to provide a wide = range of granularity for various applications needs, from the = lower-level physical network to high-level application = services.

<= /div>
After the first two paragraph, I am really expecting a full = introduction of SUPA, especially what the four-letter abbreviation means = physically.  
I = agree what is supa and what is targeting in the above.
 
Although several = organizations outside of the IETF have defined various schemes for the = configuration of network devices and specific network controllers, none = of them offer a vendor-neutral standardized way for applications to = transmit their needs to controllers. The SUPA (Shared Unified Policy = Automation) working group will work on the definition of such as = standardized interface for applications to communicate with network = controllers of all = types. 
Several, various.. please = specify. 

The interface definitions will be based on the concept of = network graph, an entity describing an arbitrary topology of nodes and = links at any level of abstraction and = granularity.
'Any = level of abstraction' is very aggressive to me, good to you guys?  = What's the level of abstraction will the group focus = on?
Agree - this needs a = more focused scope.
 
Such a graph may describe, = for example, a physical topology, a L2 network, a service topology or = the relationships between datacenters. Although some IETF working groups = have started work relating to the description of various topologies such = as I2RS (L3 and routing topologies), ALTO (cost maps), SFC (service = chain), none of these groups aim at offering a truly generic multi-layer = and abstract topology for standard northbound = configuration.
There could be a reason for = this... Maybe we need words that say why we think supa will be able to = create some umbrella architecture and protocols superseeding all of = these.

Work items for SUPA = include:

How about moving the easier items to the front, e.g. the = problem statement and requirement. Normally these are the prerequisite = for any chartered technical items, basic on which the = definition/specification/choice making work can kick-off.  Btw, the = five items charter also seems aggressive = too. 
 

1) Choice of a = modeling language used by the group to describe the network graph. = Existing modeling languages such as YANG will be considered for this = purpose unless no suitable one is = found.
<= /div>
Can there be a pointer to YANG? Is there = IPR attached to it that needs disclosure?

2) Choice of a transport protocol for the modeling language = mentioned above. The group will re-use a protocol already defined as a = transport for the modeling language, such as NETCONF or RESTCONF in the = case of YANG.

3) The definition of a standardized model for a = network topology graph. This model may be used to describe topologies at = any functional layer, from physical networks to network services and = higher abstractions. The nodes of this graph may describe physical nodes = as well as virtualized = ones.
Great goal but again seems overly = ambitious.

4) The definition and standardization of a = number of basic abstracted models using network graphs. These might = include, but are not limited to, L3VPNs, L2VPNs, datacenters, traffic = engineering, implementation of IPv6 transition mechanism and their = enforcement to users. =
Again very wide and most likely not achievable in a = group based on concenssus. I would suggest focusing on 2 = max.
 

5) Guidelines for the mapping of = abstract model information to physical or virtualized network = components.  

Proposed milestones for the working = group:

-   Produce a problem statement document for = SUPA.

-   Produce a gap analysis for SUPA in order to = verify overlap with the work of other IETF groups.

- =   Produce a requirement document describing the desired = properties of an abstract multi-layer network graph definition.

- =   Produce a gap analysis of existing modeling language, their = characteristics, possible transport protocols and how they compare to = the SUPA requirements.

-   Produce a document = specifying the model for a generic multi-layer network graph.

- =   Produce several documents describing different levels of = abstract views using the network graph model defined above, including = physical view, logical view, layer-3 view, configuration view, = performance probing view, service view and other such as L3VPN, L2VPN, = datacenters and traffic engineering. =  

------------


* OPENv6, APONF and SUPA group = historic = perspective
-----------------------------------------------------------= --------------

Most IETF working groups are formed in the = interest of solving some actual real-world problem from network = operators, developers or manufacturers and the initial work from the = OPENv6 group was no exception. Some operators saw a common interest in = defining a common approach for the deployment of IPv6 transition tools. = Although the preferred way of deploying IPv6 remains by dual-stacking, = several operators have deployed additional transition tools such as 6RD = (RFC5969), DS-Lite (RFC6333), NAT64 (RFC6146) and others with the intent = of speeding up or to provide more flexibility in their IPv6 services. = Each of these protocols presents its own set of deployment challenges = and failure modes for users, either because of unsupported applications, = partial implementations in some off-the-shelf devices such as home = routers or some limitations of the protocols themselves to name a few = cases. 

The = fact these protocols are often deployed with techniques targeting the = extension of IPv4 service, such as Carrier Grade NAT, making their = deployment even more complex, especially when targeting minimal end-user = impact. Although some approaches in solving this were proposed, for = example in RFC6264, the market hasn't seen the advent of configurable = CGN devices or adaptive home gateways. The only solution for operators = is to have an agile way to provision rapidly and easily any type of IPv6 = or IPv4 service depending of the specific needs of each end-user and = their device. These changes must be performed with respect to the = operator existing policies regarding the network, billing, security and = other constraints. 

While exploring = these issues, it became clear the best way to address them would be to = use a central controller that would be able to coordinate the deployment = of different protocols amongst several devices in a consistent fashion. = Such a controller would receive high-level policy information from a = management application, transform it in network-level configuration and = apply it to physical or virtual devices. At that point, several other = use cases outside of the deployment of IPv6 started to emerge, for = example for the control of data center traffic steering, for the = creation of tunnels and the provisioning of L3VPN. The group decided to = rename its activities under the acronym APONF, for Application Policy on = Network Functions, which seemed a more fitting name. The definition of = policies by a management application toward a network controller would = be at the center of the work for the group. Several group documents were = created around this concept. 

When presented at a = bar bof during IETF-90 in Toronto, most of the feedback was positive, = but the scope of the work was often judged too large in scope. It wasn't = clear either how much overlap there was with other IETF groups. A better = analysis of this aspect in the following weeks revealed some level of = overlap with other groups, but also where deficiencies exist. The two = aspects where IETF work seems to be lacking are in the definition of = high-level policy language for applications and also in a standard model = to describe network topologies at different levels of granularity, or = abstraction. Some existing working groups have published work on the = latter. For example, the ALTO working group defined a way to describe = network functions at different level of granularity using cost maps, but = this approach does not seem practical for the description of complex = network topologies to and from a central controller. A topology draft = exists in the I2RS group, but it is very centered !
around = ro
uting protocols and L2-L3 links. 

The group has = recently renamed its activities under the SUPA (Shared Unified Policy = Automation) acronym with the intention of defining a standard way to = push policies to a central controller. It appears, however, that in = order to define such policies, the definition of a standard multi-layer = model for the description of networks of all types would be desirable. = Therefore the initial work for the SUPA group would be to select an = existing modeling language and define a clear multi-layer model able to = describe network or service information at any level of granularity or = complexity.
--------------


Thank = you,
Tina

-----Original Message-----
From: Supa [mailto:supa-bounces@ietf.org] = On Behalf Of Spencer Dawkins
Sent: Friday, September 12, 2014 9:42 = AM
To: supa@ietf.org
Cc: Benoit = Claise
Subject: [Supa] Area hand-off, and some friendly advice = ...

Dear SUPA friends,

Several IESG members had a chat = earlier this week, and decided that SUPA really belongs in OPS. I've = requested that the area affiliation in http://www.ietf.org/list/nonwg.html be updated to reflect = that.

Benoit will be your AD for additional charter = discussion.

If I might offer some friendly advice, several ADs = are fairly confused about the relationship between openv6, APONF, and = SUPA. If you could put together a short paragraph that's something like = "we started openv6 to do X, then we realized we needed to do Y so we = proposed APONF, and after discussions in Toronto, we chose a different = direction with SUPA because of Z", that would be very helpful.

I = also have a request from Benoit (and Adrian, and Joel) to make the = description athttps://www.ietf.org/mailman/listinfo/supa more understandable for = people who haven't been following the work - if you intend to charter a = working group, you'll want people to understand what you're = proposing.

You should probably keep in mind that people who talk = over a long period of time are likely to develop a shared understanding = that people who weren't involved don't understand clearly. If there's a = smart newcomer who could look over problem statements, proposed charters = and see what's not clear to newcomers, that would likely be helpful as = well.

Thanks, and best wishes. I'll see you in the hallways of = Honolulu, where all ADs lurk sooner or later = ...

Spencer




From: Georgios Karagiannis <georgios.karagiannis@huawei.com>
Subject: Re: [Supa] Area hand-off, and some = friendly advice ...
Date: September 22, 2014 at 9:27:08 AM = EDT


Hi = Zhen,
 
Thank you very much for the = comments.
 
In the next version of the charter, we = will:
o) emphasize the main goal of = SUPA:
 
   The = main goal of SUPA is to provide a way for applications to = specify
   policies to the network infrastructure using a = simplified view of
   network. This can be realized by: (1) modeling = the network
   infrastructure as an simplified network graph = using a modeling
   language such as YANG (2) transporting = model
   instances either using NETCONF or RESTCONF and = (3) providing guidelines on
   mapping policies to attributes of the network = graphs.
 
o) emphasize that as starting point, for = applications, we will focus only on network = services
 
o) emphasize that we will focus on policy and data = models that are able to provide enough details on the used network and = service topology.
 
o) emphasize that regarding policy, enhancements of = the YANG xPath expression might be required.
 
Best = regards,
Georgios
 
 
 
From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Zhen = Cao
Sent: Monday, September 22, 2014 = 2:13 PM
To: Tina = TSOU
Cc: supa@ietf.org
Subject: Re: [Supa] Area hand-off, = and some friendly advice ...
 
Hello Tina and everybody, 
 
I have some comments about the scope of SUPA, as a = newly coming reader.  See the comments in = line. 
 
Best = regards,
zhen

SUPA = (Shared Unified Policy = Automation)

Target Area: = OPS

Description of Working Group:

Network operators are = faced with networks of increasing size and complexity while trying to = improve their quality and availability, as more and more services depend = on them. Programmatic ways to configure networks, often  called = software-defined, are considered by many network operators in order to = shift the balance in their favor.

Automation of configuration may = provide significant improvements in configuration agility, error = detection and uptime for operators. However the real value behind = central configuration schemes lies within the possible simplification = through abstraction provided by such systems to applications running = above them (on the so-called northbound side). Well-designed = abstractions are able to provide a wide range of granularity for various = applications needs, from the lower-level physical network to high-level = application = services.
 
After the first two paragraph, I am really expecting = a full introduction of SUPA, especially what the four-letter = abbreviation means physically.  
 
Although several = organizations outside of the IETF have defined various schemes for the = configuration of network devices and specific network controllers, none = of them offer a vendor-neutral standardized way for applications to = transmit their needs to controllers. The SUPA (Shared Unified Policy = Automation) working group will work on the definition of such as = standardized interface for applications to communicate with network = controllers of all = types. 

The interface = definitions will be based on the concept of network graph, an entity = describing an arbitrary topology of nodes and links at any level of = abstraction and = granularity.
<= div style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: = 'Times New Roman', serif;">'Any level of abstraction' is very aggressive = to me, good to you guys?  What's the level of abstraction will the = group focus on?
 
Such a graph may describe, for example, a physical = topology, a L2 network, a service topology or the relationships between = datacenters. Although some IETF working groups have started work = relating to the description of various topologies such as I2RS (L3 and = routing topologies), ALTO (cost maps), SFC (service chain), none of = these groups aim at offering a truly generic multi-layer and abstract = topology for standard northbound configuration.

Work items for = SUPA = include:
 
How about moving the easier items to the front, e.g. = the problem statement and requirement. Normally these are the = prerequisite for any chartered technical items, basic on which the = definition/specification/choice making work can kick-off.  Btw, the = five items charter also seems aggressive = too. 
 

1) Choice of a modeling language used by the = group to describe the network graph. Existing modeling languages such as = YANG will be considered for this purpose unless no suitable one is = found.

2) Choice of a transport protocol for the modeling = language mentioned above. The group will re-use a protocol already = defined as a transport for the modeling language, such as NETCONF or = RESTCONF in the case of YANG.

3) The definition of a standardized = model for a network topology graph. This model may be used to describe = topologies at any functional layer, from physical networks to network = services and higher abstractions. The nodes of this graph may describe = physical nodes as well as virtualized ones.

4) The definition and = standardization of a number of basic abstracted models using network = graphs. These might include, but are not limited to, L3VPNs, L2VPNs, = datacenters, traffic engineering, implementation of IPv6 transition = mechanism and their enforcement to users.  

5) Guidelines = for the mapping of abstract model information to physical or virtualized = network components.  

Proposed milestones for the working = group:

-   Produce a problem statement document for = SUPA.

-   Produce a gap analysis for SUPA in order to = verify overlap with the work of other IETF groups.

- =   Produce a requirement document describing the desired = properties of an abstract multi-layer network graph definition.

- =   Produce a gap analysis of existing modeling language, their = characteristics, possible transport protocols and how they compare to = the SUPA requirements.

-   Produce a document = specifying the model for a generic multi-layer network graph.

- =   Produce several documents describing different levels of = abstract views using the network graph model defined above, including = physical view, logical view, layer-3 view, configuration view, = performance probing view, service view and other such as L3VPN, L2VPN, = datacenters and traffic engineering. =  

------------


* OPENv6, APONF and SUPA group = historic = perspective
-----------------------------------------------------------= --------------

Most IETF working groups are formed in the = interest of solving some actual real-world problem from network = operators, developers or manufacturers and the initial work from the = OPENv6 group was no exception. Some operators saw a common interest in = defining a common approach for the deployment of IPv6 transition tools. = Although the preferred way of deploying IPv6 remains by dual-stacking, = several operators have deployed additional transition tools such as 6RD = (RFC5969), DS-Lite (RFC6333), NAT64 (RFC6146) and others with the intent = of speeding up or to provide more flexibility in their IPv6 services. = Each of these protocols presents its own set of deployment challenges = and failure modes for users, either because of unsupported applications, = partial implementations in some off-the-shelf devices such as home = routers or some limitations of the protocols themselves to name a few = cases. 

The = fact these protocols are often deployed with techniques targeting the = extension of IPv4 service, such as Carrier Grade NAT, making their = deployment even more complex, especially when targeting minimal end-user = impact. Although some approaches in solving this were proposed, for = example in RFC6264, the market hasn't seen the advent of configurable = CGN devices or adaptive home gateways. The only solution for operators = is to have an agile way to provision rapidly and easily any type of IPv6 = or IPv4 service depending of the specific needs of each end-user and = their device. These changes must be performed with respect to the = operator existing policies regarding the network, billing, security and = other constraints. 

While exploring = these issues, it became clear the best way to address them would be to = use a central controller that would be able to coordinate the deployment = of different protocols amongst several devices in a consistent fashion. = Such a controller would receive high-level policy information from a = management application, transform it in network-level configuration and = apply it to physical or virtual devices. At that point, several other = use cases outside of the deployment of IPv6 started to emerge, for = example for the control of data center traffic steering, for the = creation of tunnels and the provisioning of L3VPN. The group decided to = rename its activities under the acronym APONF, for Application Policy on = Network Functions, which seemed a more fitting name. The definition of = policies by a management application toward a network controller would = be at the center of the work for the group. Several group documents were = created around this concept. 

When presented at a = bar bof during IETF-90 in Toronto, most of the feedback was positive, = but the scope of the work was often judged too large in scope. It wasn't = clear either how much overlap there was with other IETF groups. A better = analysis of this aspect in the following weeks revealed some level of = overlap with other groups, but also where deficiencies exist. The two = aspects where IETF work seems to be lacking are in the definition of = high-level policy language for applications and also in a standard model = to describe network topologies at different levels of granularity, or = abstraction. Some existing working groups have published work on the = latter. For example, the ALTO working group defined a way to describe = network functions at different level of granularity using cost maps, but = this approach does not seem practical for the description of complex = network topologies to and from a central controller. A topology draft = exists in the I2RS group, but it is very centered !
around = ro
uting protocols and L2-L3 links. 

The group has = recently renamed its activities under the SUPA (Shared Unified Policy = Automation) acronym with the intention of defining a standard way to = push policies to a central controller. It appears, however, that in = order to define such policies, the definition of a standard multi-layer = model for the description of networks of all types would be desirable. = Therefore the initial work for the SUPA group would be to select an = existing modeling language and define a clear multi-layer model able to = describe network or service information at any level of granularity or = complexity.
--------------


Thank = you,
Tina

-----Original Message-----
From: Supa [mailto:supa-bounces@ietf.org] = On Behalf Of Spencer Dawkins
Sent: Friday, September 12, 2014 9:42 = AM
To: supa@ietf.org
Cc: Benoit = Claise
Subject: [Supa] Area hand-off, and some friendly advice = ...

Dear SUPA friends,

Several IESG members had a chat = earlier this week, and decided that SUPA really belongs in OPS. I've = requested that the area affiliation in http://www.ietf.org/list/nonwg.html be updated to reflect = that.

Benoit will be your AD for additional charter = discussion.

If I might offer some friendly advice, several ADs = are fairly confused about the relationship between openv6, APONF, and = SUPA. If you could put together a short paragraph that's something like = "we started openv6 to do X, then we realized we needed to do Y so we = proposed APONF, and after discussions in Toronto, we chose a different = direction with SUPA because of Z", that would be very helpful.

I = also have a request from Benoit (and Adrian, and Joel) to make the = description athttps://www.ietf.org/mailman/listinfo/supa more understandable for = people who haven't been following the work - if you intend to charter a = working group, you'll want people to understand what you're = proposing.

You should probably keep in mind that people who talk = over a long period of time are likely to develop a shared understanding = that people who weren't involved don't understand clearly. If there's a = smart newcomer who could look over problem statements, proposed charters = and see what's not clear to newcomers, that would likely be helpful as = well.

Thanks, and best wishes. I'll see you in the hallways of = Honolulu, where all ADs lurk sooner or later = ...

Spencer
=
 


_________________= ______________________________
Supa mailing list
Supa@ietf.org
https://www.ietf.org/mailman/listinfo/supa
= --Apple-Mail=_A983977C-E212-46F0-8033-8515B5CEFDAF-- From nobody Tue Sep 23 15:57:52 2014 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FAE01A8954 for ; Tue, 23 Sep 2014 15:57:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.687 X-Spam-Level: X-Spam-Status: No, score=-14.687 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_14=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, 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 5eNGGxI0eoYc for ; Tue, 23 Sep 2014 15:57:48 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21E131A8907 for ; Tue, 23 Sep 2014 15:57:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9020; q=dns/txt; s=iport; t=1411513068; x=1412722668; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=kmweUuLBXCzmLgABDyVJREYFd9USCrMYdZXkcTUVVaI=; b=glsZKLMT1SGhXY9uLq0BdAd0uRPlPQAD53nJMeTZ3XikndUEFbIg8WwW ISmHnLyy89Wy3uRuopK0kwxiF5P3cCMy/UEmCiiwCsbBMFnCbVIx9xlZQ d0uZ7grZkZu4TZi3cTFCGI1++jbtpknmEVXV7kpBXRSj75iyyFLwa0Lzw 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqoEANT5IVStJssW/2dsb2JhbABgg2FXyWWHSwGBIwF6hAMBAQEDAQ4kAQUtDQYBBQcECxABBAEBAQkWCAcJAwIBAgE0CQgGAQwBBQIBAYgyCA3CUgEXjyUKBwFQBwaERQEEhiKPcoI+hEqBYYVrjgeBcRiBWzsvgQYJF4EkAQEB X-IronPort-AV: E=Sophos;i="5.04,583,1406592000"; d="scan'208";a="182717227" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 23 Sep 2014 22:57:45 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s8NMvjHo016915; Tue, 23 Sep 2014 22:57:45 GMT Message-ID: <5421FAE9.1070105@cisco.com> Date: Wed, 24 Sep 2014 00:57:45 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: Tina TSOU , Georgios Karagiannis , Juergen Schoenwaelder References: <338BDC47F10D414AB0BC843C4D5DCFE085CE25@SJCEML701-CHM.china.huawei.com> <20140922134145.GC18011@elstar.local> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/supa/TQC5wZ3ljsDXqD1KbEuno4FIqXI Cc: Zhen Cao , "supa@ietf.org" Subject: Re: [Supa] Area hand-off, and some friendly advice ... X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Sep 2014 22:57:51 -0000 Tina, all, To make sure this comment is not lost at the end of this email, let me make it upfront. I invite you to submit a BoF request to make your case. Note: the deadline is Sept 26th. Let's start from this figure, where NE= Network Element --------------------- | applications | --------------------- | <--- service YANG models /NETCONF interface --------------------- | controller | <--- mapping services to topology --------------------- | | | <--- device/feature specific YANG models / NETCONF interface NE1 NE2 NEn What can the IETF possibly standardize? 1. Service YANG models /NETCONF? Yes, for sure, and we should do this full speed 2. Mapping services to topology? Potentially, but that's not an easy task 3. service YANG models /NETCONF? I'm not convinced we could standardize them, as they are operators specific, and will be evolving along the time. There are many different ways to configure a VPN, for example. See in-line > Dear all, > > Hope this version of draft charter address most of the comments from the list. > > ------ > > SUPA (Shared Unified Policy Automation) > Target Area: OPS > > > Description of Working Group: > > Network operators are faced with networks of increasing size and complexity while trying to improve their quality and availability, as more and more services depend on them. Programmatic ways to configure networks, often called software-defined, are considered by many network operators in order to shift the balance in their favor. > > Automating the way of exposing a view of the network to applications may provide significant improvements in configuration agility, error detection and uptime for operators. However the real value behind central configuration schemes lies within the possible simplification through models provided by such systems to applications and network services running above them (on the so-called northbound side). Well-designed models are able to provide a wide range of granularity for various applications and network services needs, from the lower-level physical network to high-level application services. > > Although several organizations outside of the IETF have defined various schemes for the configuration of network devices and specific network controllers, none of them offer a vendor-neutral standardized way for applications and network services to transmit their needs to controllers. Isn't it simply because the industry has not standardized their services? See above. > The SUPA (Shared Unified Policy Automation) working group will work on the definition of such as standardized interface for applications and network services to communicate with network controllers of all types. What is a standardized interface? Is "service YANG models /NETCONF (or potentially RESTCONF)"? Or is it something else? > > The specification of the interface towards end user apllications is initially not in the scope of SUPA. Here you lost me. Which interface do you mean in figure above? > In particular, as starting point, SUPA will only focus on network services, which are enhanced Operational Support System (OSS) like services that help a communication service provider to monitor, control, analyze and manage a communication network. The systems that are runniung such network services are denoted in this document as Network Service Systems. > Each network service can be represented by a classified application based POLICY model, since it can model the group of demands which are SHARED and UNIFIED and are coming from a bundle of applications that impose similar requirements on the communication network. I'm afraid I don't understand (like Jürgen) > > The main goal of SUPA is to provide a way for applications and for network services to specify SHARED application based POLICIES to the network infrastructure using a simplified view of the network. This can be realized by: > (1) modeling the network infrastructure as an simplified network graph using a modeling language such > as YANG, > (2) transporting model instances either using NETCONF or RESTCONF and (3) providing guidelines on AUTOMATICALLY mapping policies to attributes of the network graphs. > > Although some IETF working groups have started work relating to the description of various topologies such as I2RS (L3and routing topologies), ALTO (cost maps), SFC (service chain), none of these groups aim at offering truly generic topology models for the standard northbound interface. > SUPA will work on defining interfaces based on the concept of network graph, an entity describing an arbitrary topology of nodes and links at any level of granularity. Such a graph may describe, for example, a physical topology, a service topology or the relationships between datacenters. Any network topology data models or policy models that have been defined (or are being defined) within the IETF will be reused in SUPA as much as possible. > In addition to the above, policies may be defined and applied to a network graph. These application based policies are actions or constraints generated by Network Service Systems. They are then mapped from the network graph instance into specific network management policies toward network components. > > > Work items for SUPA include: > > 1) The definition of a standardized model for a network graph, using YANG. This model may be used to describe topologies at any functional layer, from physical networks to network services. > Any network topology data models or policy models that have been defined (or are being defined) within the IETF will be reused in SUPA as much as possible. So basically, you "just" want a topology database ... http://tools.ietf.org/html/draft-clemm-netmod-yang-network-topo-01 http://datatracker.ietf.org/doc/draft-contreras-supa-yang-network-topo/ ... and a way to map services to it. The topology is kind of easy, the mapping is way harder! > > 2) The definition and standardization of a number of basic policy and data models using network graphs. These might include, but are not limited to L3VPNs, datacenters, traffic engineering, implementation of IPv6 transition mechanism and their enforcement to users. Are these examples of SHARED and UNIFIED policies? Regards, Benoit (OPS AD) > > > 3) Guidelines on how to use NETCONF (or RESTCONF) authentication and authorization mechanisms to achieve protection and isolation > > 4) Guidelines for automatic mapping policies to attributes of the network graphs. > > > The following items are out of the SUPA scope: > > o) specification of the network management and controlling policies and their associated device configuration models > > > Milestones: > > o) Produce 'Problem Statement and Use Cases' as an Informational RFC. > > o) Produce a document specifying the YANG models for a generic multi-layer network graph, as Protocol Specification' Standards Track RFC. > > o) Produce several documents describing different views of a communication network by using the network graph model defined above, which includes policy and data models, as Protocol Specifications' Standards Track RFCs. > > o) Produce a document on defining the SUPA NETCON/YANG or RESTCONF (or RESTCONF/YANG) containers, as Protocol Specification' Standards Track RFC. > > o) Produce a document that provides the guidelines on using NETCONF (or RESTCONF) authentication and authorization mechanisms to achieve security protection and isolation' as an Informational RFC. > > o) Produce a document that provides the guidelines for for automatic mapping policies to attributes of the network graphs. > > ----------- > > > Thank you, > Tina > > > -----Original Message----- > From: Georgios Karagiannis > Sent: Tuesday, September 23, 2014 4:18 AM > To: Juergen Schoenwaelder > Cc: Zhen Cao; Tina TSOU; supa@ietf.org > Subject: RE: [Supa] Area hand-off, and some friendly advice ... > > Hi Juergen, > > Okay, thanks for your recommendation! > > Best regards, > Georgios > > > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Monday, September 22, 2014 3:42 PM > To: Georgios Karagiannis > Cc: Zhen Cao; Tina TSOU; supa@ietf.org > Subject: Re: [Supa] Area hand-off, and some friendly advice ... > > On Mon, Sep 22, 2014 at 01:27:08PM +0000, Georgios Karagiannis wrote: >> o) emphasize that regarding policy, enhancements of the YANG xPath expression might be required. >> > I am wondering what this is or why this would be needed. At the charter level, you may need to talk about defining data models to express policy. I do not see why that would need to enhancements of YANG's usage of xpath. > > /js > From nobody Tue Sep 23 23:00:35 2014 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18E7E1A1AA9 for ; Tue, 23 Sep 2014 23:00:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.387 X-Spam-Level: X-Spam-Status: No, score=-4.387 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 jN9r0ZOa4Qqs for ; Tue, 23 Sep 2014 23:00: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 9FF9B1A1A45 for ; Tue, 23 Sep 2014 23:00:28 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BMY17209; Wed, 24 Sep 2014 06:00:19 +0000 (GMT) Received: from LHREML516-MBX.china.huawei.com ([169.254.1.85]) by lhreml406-hub.china.huawei.com ([10.201.5.243]) with mapi id 14.03.0158.001; Wed, 24 Sep 2014 07:00:09 +0100 From: Georgios Karagiannis To: Benoit Claise , Tina TSOU , Juergen Schoenwaelder Thread-Topic: [Supa] Area hand-off, and some friendly advice ... Thread-Index: AQHPzqh9Us1IwolkWUGUssV+Mn5WLpwFfqEggAAWG8mAAKjywIAG0V4AgAAYJ7CAAACegIAAfwWQgACm8oCAAQe2gIAAfqkw Date: Wed, 24 Sep 2014 06:00:08 +0000 Message-ID: References: <338BDC47F10D414AB0BC843C4D5DCFE085CE25@SJCEML701-CHM.china.huawei.com> <20140922134145.GC18011@elstar.local> <5421FAE9.1070105@cisco.com> In-Reply-To: <5421FAE9.1070105@cisco.com> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.83.48] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/supa/iHflgb7U4a8WVjaAoKjW0DVDNnA Cc: Zhen Cao , "supa@ietf.org" Subject: Re: [Supa] Area hand-off, and some friendly advice ... X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2014 06:00:33 -0000 Hi Benoit, Thanks for your comments! Please see in line. >-----Original Message----- >From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Benoit Claise >Sent: Wednesday, September 24, 2014 12:58 AM >To: Tina TSOU; Georgios Karagiannis; Juergen Schoenwaelder >Cc: Zhen Cao; supa@ietf.org >Subject: Re: [Supa] Area hand-off, and some friendly advice ... >Tina, all, >To make sure this comment is not lost at the end of this email, let me mak= e it upfront. I invite you to submit a BoF >request to make your case. >Note: the deadline is Sept 26th. >Let's start from this figure, where NE=3D Network Element --------------------- | applications | --------------------- | <--- service=20 >YANG models /NETCONF interface --------------------- | controller | <--- mapping services=20 >to topology --------------------- | | | <---=20 >device/feature specific YANG models / NETCONF interface NE1 NE2 NEn Georgios: Please note that we are referring to the following figure: --------------------------------------- =20 | applications | --------------------------------------- | <---end use. Appl. | --------------------- |<---end use. Appl. =20 | enhanced OSS | | --------------------- | | <--- network service | YANG models /NETCONF interface | -------------------------------------- | controller | <--- map= ping network services=20 to topology -------------------------------------- | | | <---=20 device/feature specific YANG models / NETCONF interface NE1 NE2 NEn What can the IETF possibly standardize? 1. Service YANG models /NETCONF? Yes, for sure, and we should do this full= speed 2. Mapping services to topology? Potentially, but that's not an easy= task 3. service YANG models /NETCONF? I'm not convinced we could standard= ize them, as they are operators specific, and will be evolving along the ti= me. There are many different ways to configure a VPN, for example. Georgios: According to the provided figure: 1) need to work on network serv= ice Yang models, 2 mapping network services to topology, 3. Device/feature = specific Yang Models, 4) end user specific Yank Models (out of scope). The = interface between end user applications and a controller, and interface bet= ween end user application and enhanced OSS, are also out of scope. Regarding your comment, " I'm not convinced we could standardize them, as t= hey are operators specific, and will be evolving along the time. There are = many different ways to configure a VPN, for example." Were you referring to= : 3. Device/feature specific Yang Models? >See in-line > Dear all, > > Hope this version of draft charter address most of the comments from the = list. > > ------ > > SUPA (Shared Unified Policy Automation) Target Area: OPS > > > Description of Working Group: > > Network operators are faced with networks of increasing size and complexi= ty while trying to improve their quality and availability, as more and more= services depend on them. Programmatic ways to configure networks, often ca= lled software-defined, are considered by many network operators in order to= shift the balance in their favor. > > Automating the way of exposing a view of the network to applications may = provide significant improvements in configuration agility, error detection = and uptime for operators. However the real value behind central configurati= on schemes lies within the possible simplification through models provided = by such systems to applications and network services running above them (on= the so-called northbound side). Well-designed models are able to provide a= wide range of granularity for various applications and network services ne= eds, from the lower-level physical network to high-level application servic= es. > > Although several organizations outside of the IETF have defined various s= chemes for the configuration of network devices and specific network contro= llers, none of them offer a vendor-neutral standardized way for application= s and network services to transmit their needs to controllers. Isn't it simply because the industry has not standardized their=20 services? See above. > The SUPA (Shared Unified Policy Automation) working group will work on th= e definition of such as standardized interface for applications and network= services to communicate with network controllers of all types. What is a standardized interface? Is "service YANG models /NETCONF (or potentially RESTCONF)"? Or is it=20 something else? Georgios: yes they are: network service YANG models /NETCONF (or potential= ly RESTCONF)" > > The specification of the interface towards end user apllications is initi= ally not in the scope of SUPA. Here you lost me. Which interface do you mean in figure above? > In particular, as starting point, SUPA will only focus on network service= s, which are enhanced Operational Support System (OSS) like services that h= elp a communication service provider to monitor, control, analyze and manag= e a communication network. The systems that are runniung such network servi= ces are denoted in this document as Network Service Systems. > Each network service can be represented by a classified application based= POLICY model, since it can model the group of demands which are SHARED and= UNIFIED and are coming from a bundle of applications that impose similar r= equirements on the communication network. I'm afraid I don't understand (like J=FCrgen) Georgios: Thanks for the suggestion, the text needs to be rephrased, see be= low: Each network service can be represented by an application based POLICY mode= l, which is UNIFIED and SHARED, since it can model the group of demands (i.= e, actions and constraints) that are coming from a bundle of applications t= hat impose similar requirements on the communication network. > > The main goal of SUPA is to provide a way for applications and for networ= k services to specify SHARED application based POLICIES to the network infr= astructure using a simplified view of the network. This can be realized by: > (1) modeling the network infrastructure as an simplified network graph us= ing a modeling language such > as YANG, > (2) transporting model instances either using NETCONF or RESTCONF and (3)= providing guidelines on AUTOMATICALLY mapping policies to attributes of th= e network graphs. > > Although some IETF working groups have started work relating to the descr= iption of various topologies such as I2RS (L3and routing topologies), ALTO = (cost maps), SFC (service chain), none of these groups aim at offering trul= y generic topology models for the standard northbound interface. > SUPA will work on defining interfaces based on the concept of network gra= ph, an entity describing an arbitrary topology of nodes and links at any le= vel of granularity. Such a graph may describe, for example, a physical topo= logy, a service topology or the relationships between datacenters. Any netw= ork topology data models or policy models that have been defined (or are be= ing defined) within the IETF will be reused in SUPA as much as possible. > In addition to the above, policies may be defined and applied to a networ= k graph. These application based policies are actions or constraints genera= ted by Network Service Systems. They are then mapped from the network graph= instance into specific network management policies toward network componen= ts. Georgios: the above text is not clear. Therefore, I am rephrasing it: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The main goal of SUPA is to provide application based policies and means to= model and program the abstract view of network infrastructure and service = function interdependencies in order to support and AUTOMATICALLY feed netwo= rk management and controlling policies. This can be realized by: (1) modeling the network graph, which among others include policy models, d= ata models and application based policies, using YANG,=20 (2) applying NETCONF (or RESTCONF) to enable dissemination of up to date (f= resh) network graphs in a secure and efficient manner between network servi= ce systems and network management and controlling systems,=20 (3) providing guidelines on mapping attributes of network graphs provided b= y network service systems into specific network management and controlling = policies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D >> =20 >> >> Work items for SUPA include: >> >> 1) The definition of a standardized model for a network graph, using YAN= G. This model may be used to describe topologies at any functional layer, f= rom physical networks to network services. >> Any network topology data models or policy models that have been defined= (or are being defined) within the IETF will be reused in SUPA as much as p= ossible. So basically, you "just" want a topology database ... http://tools.ietf.org/html/draft-clemm-netmod-yang-network-topo-01 http://datatracker.ietf.org/doc/draft-contreras-supa-yang-network-topo/ ... and a way to map services to it. The topology is kind of easy, the mapping is way harder! >> >> 2) The definition and standardization of a number of basic policy and da= ta models using network graphs. These might include, but are not limited to= L3VPNs, datacenters, traffic engineering, implementation of IPv6 transitio= n mechanism and their enforcement to users. > Are these examples of SHARED and UNIFIED policies? Georgios: yes, that is what we mean. Regarding work items, I agree that they were not clear.=20 Below I am rephrasing the work items and milestones: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Work items related to SUPA include: o) specify the network graph based on YANG policy and data models o) specify and standardize how NETCONF/YANG (or RESTCONF/YANG) can be used = to securely and efficiently distribute up to date (fresh) network graphs be= tween network service systems and network management and controlling system= s o) provide guidelines for mechanisms that can dynamically and automatically= map attributes, including application based policies, of network graphs in= to specific network management and controlling policies =20 o) document how to use NETCONF (or RESTCONF) authentication and authorizati= on mechanisms to achieve protection and isolation The following items are out of the SUPA scope: o) specification of the network management and controlling policies and the= ir associated device configuration models Milestones: I-D 'Problem Statement and Use Cases' as an Informational RFC. I-D 'Guidelines on mapping network graphs into specific network =20 management and controlling policies' as an Informational RFC. I-D 'Guidelines on using NETCONF (or RESTCONF) authentication and=20 authorization mechanisms to achieve security protection and isolation'= =20 as an Informational RFC. I-D 'SUPA NETCONF/YANG (or RESTCONF/YANG) model and Protocol=20 Specification' Standards Track RFC. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Georgios: Regarding your concern about mapping, yes I agree. Please note that we aim to generate guidelines on mapping of the network gr= aphs into specific network =20 management and controlling policies'. Regards, Benoit (OPS AD) > =20 > > 3) Guidelines on how to use NETCONF (or RESTCONF) authentication and auth= orization mechanisms to achieve protection and isolation > > 4) Guidelines for automatic mapping policies to attributes of the network= graphs. > > > The following items are out of the SUPA scope: > > o) specification of the network management and controlling policies and t= heir associated device configuration models > > > Milestones: > > o) Produce 'Problem Statement and Use Cases' as an Informational RFC. > > o) Produce a document specifying the YANG models for a generic multi-laye= r network graph, as Protocol Specification' Standards Track RFC. > > o) Produce several documents describing different views of a communicatio= n network by using the network graph model defined above, which includes po= licy and data models, as Protocol Specifications' Standards Track RFCs. > > o) Produce a document on defining the SUPA NETCON/YANG or RESTCONF (or RE= STCONF/YANG) containers, as Protocol Specification' Standards Track RFC. > =20 > o) Produce a document that provides the guidelines on using NETCONF (or R= ESTCONF) authentication and authorization mechanisms to achieve security pr= otection and isolation' as an Informational RFC. > > o) Produce a document that provides the guidelines for for automatic mapp= ing policies to attributes of the network graphs. > > ----------- > > > Thank you, > Tina > > > -----Original Message----- > From: Georgios Karagiannis > Sent: Tuesday, September 23, 2014 4:18 AM > To: Juergen Schoenwaelder > Cc: Zhen Cao; Tina TSOU; supa@ietf.org > Subject: RE: [Supa] Area hand-off, and some friendly advice ... > > Hi Juergen, > > Okay, thanks for your recommendation! > > Best regards, > Georgios > > > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Monday, September 22, 2014 3:42 PM > To: Georgios Karagiannis > Cc: Zhen Cao; Tina TSOU; supa@ietf.org > Subject: Re: [Supa] Area hand-off, and some friendly advice ... > > On Mon, Sep 22, 2014 at 01:27:08PM +0000, Georgios Karagiannis wrote: >> o) emphasize that regarding policy, enhancements of the YANG xPath expre= ssion might be required. >> > I am wondering what this is or why this would be needed. At the charter l= evel, you may need to talk about defining data models to express policy. I = do not see why that would need to enhancements of YANG's usage of xpath. > > /js > _______________________________________________ Supa mailing list Supa@ietf.org https://www.ietf.org/mailman/listinfo/supa From nobody Wed Sep 24 02:41:01 2014 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD2B1A891B for ; Wed, 24 Sep 2014 02:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.286 X-Spam-Level: X-Spam-Status: No, score=-15.286 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, 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 CAskMHgnHwr8 for ; Wed, 24 Sep 2014 02:40:58 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8162C1A6FBB for ; Wed, 24 Sep 2014 02:40:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12898; q=dns/txt; s=iport; t=1411551657; x=1412761257; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=2KwyI6gvSaCbiY4ku0ltFqsndbWeZRa50htQYN6BPJM=; b=fN5b1eWMSHA2rzthFIZdFdYBwzi9FchQffijkPJoWm4PcsJE5BrKsfAN hG1bB6TaA4+F3CgizX+u+EKZn4OC92uZqvCFb8DDhR2VOx/3Der4R862D dwk2yiaSnPdJoKoc/i5vzyFBvq44GkMfjJB290gs3X01GR2nqgdGAntdm I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqQEAAORIlStJssW/2dsb2JhbABfjRTJMwGBHgF6hAQBAQMBcgYBEAshFg8JAwIBAgFFBgEMAQcBAYgyCMJbAReQHgeESwEEhiOSMIRKh0yOCIFxGIFbO4J5AQEB X-IronPort-AV: E=Sophos;i="5.04,588,1406592000"; d="scan'208,217";a="187922112" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 24 Sep 2014 09:40:55 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s8O9es5x023901; Wed, 24 Sep 2014 09:40:55 GMT Message-ID: <542291A6.1000506@cisco.com> Date: Wed, 24 Sep 2014 11:40:54 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: Georgios Karagiannis , Tina TSOU , Juergen Schoenwaelder References: <338BDC47F10D414AB0BC843C4D5DCFE085CE25@SJCEML701-CHM.china.huawei.com> <20140922134145.GC18011@elstar.local> <5421FAE9.1070105@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010906030300070901040403" Archived-At: http://mailarchive.ietf.org/arch/msg/supa/dNfY-4krC51XYJhn9RKst9OMTj8 Cc: Zhen Cao , "supa@ietf.org" Subject: Re: [Supa] Area hand-off, and some friendly advice ... X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2014 09:41:00 -0000 This is a multi-part message in MIME format. --------------010906030300070901040403 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi Georgios, > Hi Benoit, > > Thanks for your comments! > Please see in line. > > > Georgios: Please note that we are referring to the following figure: > --------------------------------------- > | applications | > --------------------------------------- > | <---end use. Appl. | > --------------------- |<---end use. Appl. > | enhanced OSS | | > --------------------- | > | <--- network service | > YANG models /NETCONF interface | > -------------------------------------- > | controller | <--- mapping network services > to topology > -------------------------------------- > | | | <--- > device/feature specific YANG models / NETCONF interface > NE1 NE2 NEn It's not obvious what an "enhanced OSS" is? > Georgios: According to the provided figure: 1) need to work on network service Yang models, 2 mapping network services to topology, 3. Device/feature specific Yang Models, 4) end user specific Yank Models (out of scope). The interface between end user applications and a controller, and interface between end user application and enhanced OSS, are also out of scope. Concerning your last sentence. I'm confused. What does the following deliverable mean then? o) specify and standardize how NETCONF/YANG (or RESTCONF/YANG) can be used to securely and efficiently distribute up to date (fresh) network graphs between network service systems and network management and controlling systems > > Regarding your comment, " I'm not convinced we could standardize them, as they are operators specific, and will be evolving along the time. There are many different ways to configure a VPN, for example." Were you referring to: > 3. Device/feature specific Yang Models? No, the service YANG models > >> See in-line >> Dear all, >> >> Hope this version of draft charter address most of the comments from the list. >> >> ------ >> >> >> >> >> In particular, as starting point, SUPA will only focus on network services, which are enhanced Operational Support System (OSS) like services that help a communication service provider to monitor, control, analyze and manage a communication network. The systems that are runniung such network services are denoted in this document as Network Service Systems. >> Each network service can be represented by a classified application based POLICY model, since it can model the group of demands which are SHARED and UNIFIED and are coming from a bundle of applications that impose similar requirements on the communication network. > I'm afraid I don't understand (like Jürgen) > > Georgios: Thanks for the suggestion, the text needs to be rephrased, see below: > Each network service can be represented by an application based POLICY model, which is UNIFIED and SHARED, since it can model the group of demands (i.e, actions and constraints) that are coming from a bundle of applications that impose similar requirements on the communication network. I still don't understand what "UNIFIED and SHARED" mean. >> (2) transporting model instances either using NETCONF or RESTCONF and (3) providing guidelines on AUTOMATICALLY mapping policies to attributes of the network graphs. >> >> Although some IETF working groups have started work relating to the description of various topologies such as I2RS (L3and routing topologies), ALTO (cost maps), SFC (service chain), none of these groups aim at offering truly generic topology models for the standard northbound interface. >> SUPA will work on defining interfaces based on the concept of network graph, an entity describing an arbitrary topology of nodes and links at any level of granularity. Such a graph may describe, for example, a physical topology, a service topology or the relationships between datacenters. Any network topology data models or policy models that have been defined (or are being defined) within the IETF will be reused in SUPA as much as possible. >> In addition to the above, policies may be defined and applied to a network graph. These application based policies are actions or constraints generated by Network Service Systems. They are then mapped from the network graph instance into specific network management policies toward network components. > > Georgios: the above text is not clear. Therefore, I am rephrasing it: > ============================================= > The main goal of SUPA is to provide application based policies and means to model and program the abstract view of network infrastructure and service function interdependencies in order to support and AUTOMATICALLY feed network management and controlling policies. This can be realized by: > > (1) modeling the network graph, which among others include policy models, data models and application based policies, using YANG, > > (2) applying NETCONF (or RESTCONF) to enable dissemination of up to date (fresh) network graphs in a secure and efficient manner between network service systems and network management and controlling systems, "between network service systems and network management and controlling system". What are those? I don't see them in your figure. Also, why should all of these need to know about the topology? Regards, Benoit --------------010906030300070901040403 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Georgios,
Hi Benoit,

Thanks for your comments!
Please see in line.


Georgios: Please note that we are referring to the following figure:
             ---------------------------------------  
             | applications                        |
             ---------------------------------------
                       |  <---end use. Appl.   |
             ---------------------             |<---end use. Appl.   
             | enhanced OSS      |             |
             ---------------------             |
                      |   <--- network service |
YANG models  /NETCONF interface                |
             --------------------------------------
             |   controller                       |               <---  mapping network services 
to topology
             --------------------------------------
                 |       |        |                    <--- 
device/feature specific YANG models / NETCONF interface
             NE1    NE2   NEn
It's not obvious what an "enhanced OSS" is?
Georgios: According to the provided figure: 1) need to work on network service Yang models, 2 mapping network services to topology, 3. Device/feature specific Yang Models, 4) end user specific Yank Models (out of scope). The interface between end user applications and a controller, and interface between end user application and enhanced OSS, are also out of scope.
Concerning your last sentence. I'm confused.
What does the following deliverable mean then?
o) specify and standardize how NETCONF/YANG (or RESTCONF/YANG) can be used to securely and efficiently distribute up to date (fresh) network graphs between network service systems and network management and controlling systems


Regarding your comment, " I'm not convinced we could standardize them, as they are operators specific, and will be evolving along the time. There are many different ways to configure a VPN, for example." Were you referring to:
3. Device/feature specific Yang Models?
No, the service YANG models 


See in-line
Dear all,

Hope this version of draft charter address most of the comments from the list.

------





In particular, as starting point, SUPA will only focus on network services, which are enhanced Operational Support System (OSS) like services that help a communication service provider to monitor, control, analyze and manage a communication network. The systems that are runniung such network services are denoted in this document as Network Service Systems.
Each network service can be represented by a classified application based POLICY model, since it can model the group of demands which are SHARED and UNIFIED and are coming from a bundle of applications that impose similar requirements on the communication network.

I'm afraid I don't understand (like Jürgen)

Georgios: Thanks for the suggestion, the text needs to be rephrased, see below:
Each network service can be represented by an application based POLICY model, which is UNIFIED and SHARED, since it can model the group of demands (i.e, actions and constraints) that are coming from a bundle of applications that impose similar requirements on the communication network.
I still don't understand what "UNIFIED and SHARED" mean.

      

        
(2) transporting model instances either using NETCONF or RESTCONF and (3) providing guidelines on AUTOMATICALLY mapping policies to attributes of the network graphs.

Although some IETF working groups have started work relating to the description of various topologies such as I2RS (L3and routing topologies), ALTO (cost maps), SFC (service chain), none of these groups aim at offering truly generic topology models for the standard northbound interface.
SUPA will work on defining interfaces based on the concept of network graph, an entity describing an arbitrary topology of nodes and links at any level of granularity. Such a graph may describe, for example, a physical topology, a service topology or the relationships between datacenters. Any network topology data models or policy models that have been defined (or are being defined) within the IETF will be reused in SUPA as much as possible.
In addition to the above, policies may be defined and applied to a network graph. These application based policies are actions or constraints generated by Network Service Systems. They are then mapped from the network graph instance into specific network management policies toward network components.


      

      

Georgios: the above text is not clear. Therefore, I am rephrasing it:
=============================================
The main goal of SUPA is to provide application based policies and means to model and program the abstract view of network infrastructure and service function interdependencies in order to support and AUTOMATICALLY feed network management and controlling policies. This can be realized by:

(1) modeling the network graph, which among others include policy models, data models and application based policies, using YANG, 

(2) applying NETCONF (or RESTCONF) to enable dissemination of up to date (fresh) network graphs in a secure and efficient manner between network service systems and network management and controlling systems, 

    

    "between network service systems and network management and
    controlling system". What are those? I don't see them in your
    figure.

    Also, why should all of these need to know about the topology?

    

    Regards, Benoit

    

  


--------------010906030300070901040403--


From nobody Wed Sep 24 03:51:47 2014
Return-Path: 
X-Original-To: supa@ietfa.amsl.com
Delivered-To: supa@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B3CB1A1BB5 for ; Wed, 24 Sep 2014 03:51:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.986
X-Spam-Level: 
X-Spam-Status: No, score=-6.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 kNy6u-SWC1WW for ; Wed, 24 Sep 2014 03:51:42 -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 1EAD81A1A7E for ; Wed, 24 Sep 2014 03:51:41 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BMY50164; Wed, 24 Sep 2014 10:51:40 +0000 (GMT)
Received: from SZXEMA406-HUB.china.huawei.com (10.82.72.38) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 24 Sep 2014 11:51:39 +0100
Received: from SZXEMA509-MBS.china.huawei.com ([169.254.2.166]) by SZXEMA406-HUB.china.huawei.com ([10.82.72.38]) with mapi id 14.03.0158.001; Wed, 24 Sep 2014 18:51:35 +0800
From: "Liushucheng (Will)" 
To: "supa@ietf.org" 
Thread-Topic: online discussion invitation
Thread-Index: Ac/X49o+4OqyFL2xREOBkM6VeDaSQQ==
Date: Wed, 24 Sep 2014 10:51:34 +0000
Message-ID: 
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.66.78.79]
Content-Type: multipart/alternative; boundary="_000_C9B5F12337F6F841B35C404CF0554ACB5FF997EESZXEMA509MBSchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/supa/yrM5nqvgOL0O-uo95mch09tnujQ
Subject: [Supa] online discussion invitation
X-BeenThere: supa@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Sep 2014 10:51:45 -0000

--_000_C9B5F12337F6F841B35C404CF0554ACB5FF997EESZXEMA509MBSchi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi all,

Thank you for your previous efforts. I'd like to invite people who are inte=
rested in SUPA to have an online discussion about the charter and related s=
tuff. The time proposed by Georgios is Thursday 12:20(UTC) (i.e. 1320 CEST,=
 19:20 China), which is 25 hours from Now. Please find the telephone meetin=
g bridge below (if there is a better one or if you need to be called, pleas=
e let me know):
Access Number:

+8675528560663

Guest Passcode:

836811792


Please let me know whether you are able to join. Really sorry for the late =
notification.

Regards,
Will


--_000_C9B5F12337F6F841B35C404CF0554ACB5FF997EESZXEMA509MBSchi_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi all,


 


Thank you for your previous eff=
orts. I’d like to invite people who are interested in SUPA to have an=
 online discussion about the charter and related stuff. The time proposed b=
y Georgios is
Thursd=
ay 12:20(UTC) (i.e. 1320 CEST, 19:20 China), which is 25 hours from Now. Pl=
ease find the telephone meeting bridge below (if there is a better one or i=
f you need to be called, please let
 me know):










Access Number: 





+86=
75528560663 
 








Guest Passcode:
<=
o:p>




8368117=
92     










 


Please let me know whether you are able to join. Really sorry for=
 the late notification.



 


Regards,


Will


 






--_000_C9B5F12337F6F841B35C404CF0554ACB5FF997EESZXEMA509MBSchi_--


From nobody Wed Sep 24 04:30:01 2014
Return-Path: 
X-Original-To: supa@ietfa.amsl.com
Delivered-To: supa@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60E7F1A7020 for ; Wed, 24 Sep 2014 04:29:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.986
X-Spam-Level: 
X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 zkLBylziW9TD for ; Wed, 24 Sep 2014 04:29: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 A5ACB1A701C for ; Wed, 24 Sep 2014 04:29:53 -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 BMY53991; Wed, 24 Sep 2014 11:29:42 +0000 (GMT)
Received: from LHREML516-MBX.china.huawei.com ([169.254.1.85]) by lhreml404-hub.china.huawei.com ([::1]) with mapi id 14.03.0158.001; Wed, 24 Sep 2014 12:29:34 +0100
From: Georgios Karagiannis 
To: Benoit Claise , Tina TSOU , Juergen Schoenwaelder 
Thread-Topic: [Supa] Area hand-off, and some friendly advice ...
Thread-Index: AQHPzqh9Us1IwolkWUGUssV+Mn5WLpwFfqEggAAWG8mAAKjywIAG0V4AgAAYJ7CAAACegIAAfwWQgACm8oCAAQe2gIAAfqkwgAA1CQCAABXdgA==
Date: Wed, 24 Sep 2014 11:29:34 +0000
Message-ID: 
References:   <338BDC47F10D414AB0BC843C4D5DCFE085CE25@SJCEML701-CHM.china.huawei.com>     <20140922134145.GC18011@elstar.local>   <5421FAE9.1070105@cisco.com>  <542291A6.1000506@cisco.com>
In-Reply-To: <542291A6.1000506@cisco.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.216.47.3]
Content-Type: multipart/alternative; boundary="_000_C5034E44CD620A44971BAAEB372655DC635F49LHREML516MBXchina_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/supa/IN0SWST1mnWtuP-dFUZz_GuXMts
Cc: Zhen Cao , "supa@ietf.org" 
Subject: Re: [Supa] Area hand-off, and some friendly advice ...
X-BeenThere: supa@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Sep 2014 11:29:59 -0000

--_000_C5034E44CD620A44971BAAEB372655DC635F49LHREML516MBXchina_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Benoit,

Thank you for your comments.
Please see in line,

From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Benoit Claise
Sent: Wednesday, September 24, 2014 10:41 AM
To: Georgios Karagiannis; Tina TSOU; Juergen Schoenwaelder
Cc: Zhen Cao; supa@ietf.org
Subject: Re: [Supa] Area hand-off, and some friendly advice ...

Hi Georgios,

Hi Benoit,



Thanks for your comments!

Please see in line.





Georgios: Please note that we are referring to the following figure:

             ---------------------------------------

             | applications                        |

             ---------------------------------------

                       |  <---end use. Appl.   |

             ---------------------             |<---end use. Appl.

             | enhanced OSS      |             |

             ---------------------             |

                      |   <--- network service |

YANG models  /NETCONF interface                |

             --------------------------------------

             |   controller                       |               <---  map=
ping network services

to topology

             --------------------------------------

                 |       |        |                    <---

device/feature specific YANG models / NETCONF interface

             NE1    NE2   NEn
It's not obvious what an "enhanced OSS" is?

Georgios: it relates to the system that runs network services. These servic=
es are enhanced Operational Support System (OSS) like services that help a =
communication service provider to monitor, control, analyze and manage a co=
mmunication network.



Georgios: According to the provided figure: 1) need to work on network serv=
ice Yang models, 2 mapping network services to topology, 3. Device/feature =
specific Yang Models, 4) end user specific Yank Models (out of scope). The =
interface between end user applications and a controller, and interface bet=
ween end user application and enhanced OSS, are also out of scope.
Concerning your last sentence. I'm confused.
What does the following deliverable mean then?

o) specify and standardize how NETCONF/YANG (or RESTCONF/YANG) can be used =
to securely and efficiently distribute up to date (fresh) network graphs be=
tween network service systems and network management and controlling system=
s

It relates to the interface between the network service system (enhanced OS=
S in the above figure.
Please note that we say that we initially only focus on this interface, in =
order to narrow down the scope of this activity

However, if there are supports that think we should initially focus also on=
 the interface between end user application and controller we will also inc=
lude this interface in the scope.







Regarding your comment, " I'm not convinced we could standardize them, as t=
hey are operators specific, and will be evolving along the time. There are =
many different ways to configure a VPN, for example." Were you referring to=
:

3. Device/feature specific Yang Models?
No, the service YANG models

Georgios: I see, but we can work on YANG models that can be used for a numb=
er of main network services, which are essential for operators and that the=
y would like to have them standardized.






See in-line

Dear all,



Hope this version of draft charter address most of the comments from the li=
st.



------









In particular, as starting point, SUPA will only focus on network services,=
 which are enhanced Operational Support System (OSS) like services that hel=
p a communication service provider to monitor, control, analyze and manage =
a communication network. The systems that are runniung such network service=
s are denoted in this document as Network Service Systems.

Each network service can be represented by a classified application based P=
OLICY model, since it can model the group of demands which are SHARED and U=
NIFIED and are coming from a bundle of applications that impose similar req=
uirements on the communication network.

I'm afraid I don't understand (like J=FCrgen)



Georgios: What we want to say is that there are applications that impose si=
milar requirements on the communication network. For each group of such bul=
k of applications a network service can be defined that can be represented =
by a service policy model (i.e., its actions and constraints).





Georgios: Thanks for the suggestion, the text needs to be rephrased, see be=
low:

Each network service can be represented by an application based POLICY mode=
l, which is UNIFIED and SHARED, since it can model the group of demands (i.=
e, actions and constraints) that are coming from a bundle of applications t=
hat impose similar requirements on the communication network.
I still don't understand. what "UNIFIED and SHARED" mean.

Georgios: the terms "UNIFIED" and "SHARED"" relate to the way of how the se=
rvice policy model is generated, since it groups and it unifies and shares =
the similar requirements imposed by a bulk of applications.










(2) transporting model instances either using NETCONF or RESTCONF and (3) p=
roviding guidelines on AUTOMATICALLY mapping policies to attributes of the =
network graphs.



Although some IETF working groups have started work relating to the descrip=
tion of various topologies such as I2RS (L3and routing topologies), ALTO (c=
ost maps), SFC (service chain), none of these groups aim at offering truly =
generic topology models for the standard northbound interface.

SUPA will work on defining interfaces based on the concept of network graph=
, an entity describing an arbitrary topology of nodes and links at any leve=
l of granularity. Such a graph may describe, for example, a physical topolo=
gy, a service topology or the relationships between datacenters. Any networ=
k topology data models or policy models that have been defined (or are bein=
g defined) within the IETF will be reused in SUPA as much as possible.

In addition to the above, policies may be defined and applied to a network =
graph. These application based policies are actions or constraints generate=
d by Network Service Systems. They are then mapped from the network graph i=
nstance into specific network management policies toward network components=
.





Georgios: the above text is not clear. Therefore, I am rephrasing it:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

The main goal of SUPA is to provide application based policies and means to=
 model and program the abstract view of network infrastructure and service =
function interdependencies in order to support and AUTOMATICALLY feed netwo=
rk management and controlling policies. This can be realized by:



(1) modeling the network graph, which among others include policy models, d=
ata models and application based policies, using YANG,



(2) applying NETCONF (or RESTCONF) to enable dissemination of up to date (f=
resh) network graphs in a secure and efficient manner between network servi=
ce systems and network management and controlling systems,
"between network service systems and network management and controlling sys=
tem". What are those? I don't see them in your figure.
Also, why should all of these need to know about the topology?

Georgios: In the figure, the enhanced OSS represents the network service sy=
stem and the controller represents the network management and controlling s=
ystem.
In this context, network services can be used to provide the required  conf=
iguration and application programming interfaces to service developers. Sub=
sequently, a network service can use the application based demands (for act=
ions and constraints) and possibly update its associated network service  a=
ttributes. Examples of network services that can modify  the network servic=
e attributes are for example, L3VPN configuration and IPv6 transitions.
For each network service instance a network graph needs to be generated and=
 maintained.
The up to date network graph needs to (1) be communicated between the  netw=
ork service systems and the network   management and controlling systems, (=
2) map the attributes of the network service graph into specific network ma=
nagement policies.

Best regards,
Georgios





Regards, Benoit

--_000_C5034E44CD620A44971BAAEB372655DC635F49LHREML516MBXchina_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hi Benoit,


 <=
/p>

Thank you for your commen=
ts.


Please see in line,<=
/o:p>


 <=
/p>





From: Supa [mailto:supa-bounces@ietf.org]
On Behalf Of Benoit Claise

Sent: Wednesday, September 24, 2014 10:41 AM

To: Georgios Karagiannis; Tina TSOU; Juergen Schoenwaelder

Cc: Zhen Cao; supa@ietf.org

Subject: Re: [Supa] Area hand-off, and some friendly advice ...=







 




Hi Georgios,






Hi Benoit,


 


Thanks for your comments!


Please see in line.


 


 


Georgios: Please note that we are referring to the following figure:


           &nbs=
p; ---------------------------------------  


           &nbs=
p; | applications         =
;            &n=
bsp;  |


           &nbs=
p; ---------------------------------------


           &nbs=
p;           |  <=
---end use. Appl.   |


           &nbs=
p; ---------------------        &nb=
sp;    |<---end use. Appl.   


           &nbs=
p; | enhanced OSS      |   &nb=
sp;         |


           &nbs=
p; ---------------------        &nb=
sp;    |


            &nb=
sp;         |   <=
--- network service |


YANG models  /NETCONF interface     &nbs=
p;          |


           &nbs=
p; --------------------------------------


           &nbs=
p; |   controller        =
            &nb=
sp;  |          &nbs=
p;    <---  mapping network services 

to topology


           &nbs=
p; --------------------------------------


           &nbs=
p;     |       | &nb=
sp;      |      &nbs=
p;             =
<--- 


device/feature specific YANG models / NETCONF interface

           &nbs=
p; NE1    NE2   NEn




It's not obvious what an "enhanced OSS" is=
?


 <=
/p>

Georgios: it relates to t=
he system that runs network services. These services are enhanced Operation=
al Support System (OSS) like services that help a communication
 service provider to monitor, control, analyze and manage a communication n=
etwork.










Georgios: According to the provided figure: 1) need to work on network=
 service Yang models, 2 mapping network services to topology, 3. Device/fea=
ture specific Yang Models, 4) end user specific Yank Models (out of scope).=
 The interface between end user applications and a controller, and interfac=
e between end user application and enhanced OSS, are also out of scope.


Concerning your last sentence. I'm confused.

What does the following deliverable mean then?


o) specify and standardize how NETCONF/YANG (or RESTCONF/YANG) can be =
used to securely and efficiently distribute up to date (fresh) network grap=
hs between network service systems and network management and controlling s=
ystems


 


It relates to the interfa=
ce between the network service system (enhanced OSS in the above figure.


Please note that we say t=
hat we initially only focus on this interface, in order to narrow down the =
scope of this activity


 <=
/p>

However, if there are sup=
ports that think we should initially focus also on the interface between en=
d user application and controller we will also include this
 interface in the scope.









 


 


Regarding your comment, " I'm not convinced we could standardize =
them, as they are operators specific, and will be evolving along the time. =
There are many different ways to configure a VPN, for example." Were y=
ou referring to:


3. Device/feature specific Yang Models?


No, the service YANG models 


 <=
/p>

Georgios: I see, but we c=
an work on YANG models that can be used for a number of main network servic=
es, which are essential for operators and that they would
 like to have them standardized.


 <=
/p>

 


 




See in-line


Dear all,


 


Hope this version of draft charter address most of the comments from t=
he list.


 


------


 


 


 


 






In particular, as starting point, SUPA will only focus on network serv=
ices, which are enhanced Operational Support System (OSS) like services tha=
t help a communication service provider to monitor, control, analyze and ma=
nage a communication network. The systems that are runniung such network se=
rvices are denoted in this document as Network Service Systems.<=
/pre>

Each network service can be represented by a classified application ba=
sed POLICY model, since it can model the group of demands which are SHARED =
and UNIFIED and are coming from a bundle of applications that impose simila=
r requirements on the communication network.




I'm afraid I don't understand (like J=FCrgen)


 


Georgios: What we want to say is that there=
 are applications that impose similar requirements on the communication net=
work. For each group of such bulk of applications a network service can be =
defined that can be represented by a service policy model (i.e., its action=
s and constraints).


 


 


Georgios: Thanks for the suggestion, the text needs to be rephrased, s=
ee below:


Each network service can be represented by an application based POLICY=
 model, which is UNIFIED and SHARED, since it can model the group of demand=
s (i.e, actions and constraints) that are coming from a bundle of applicati=
ons that impose similar requirements on the communication network.


I still don't understand. what "UNIFIED and SHARED" mean.


 <=
/p>

Georgios: the terms ̶=
0;UNIFIED” and “SHARED”” relate to the way of how t=
he service policy model is generated, since it groups and it unifies and sh=
ares the similar
 requirements imposed by a bulk of applications.


 <=
/p>

 <=
/p>

 <=
/p>

 <=
/p>

 <=
/p>








 




(2) transporting model instances either using NETCONF or RESTCONF and =
(3) providing guidelines on AUTOMATICALLY mapping policies to attributes of=
 the network graphs.


 


Although some IETF working groups have started work relating to the de=
scription of various topologies such as I2RS (L3and routing topologies), AL=
TO (cost maps), SFC (service chain), none of these groups aim at offering t=
ruly generic topology models for the standard northbound interface.


SUPA will work on defining interfaces based on the concept of network =
graph, an entity describing an arbitrary topology of nodes and links at any=
 level of granularity. Such a graph may describe, for example, a physical t=
opology, a service topology or the relationships between datacenters. Any n=
etwork topology data models or policy models that have been defined (or are=
 being defined) within the IETF will be reused in SUPA as much as possible.=



In addition to the above, policies may be defined and applied to a net=
work graph. These application based policies are actions or constraints gen=
erated by Network Service Systems. They are then mapped from the network gr=
aph instance into specific network management policies toward network compo=
nents.




 


 


Georgios: the above text is not clear. Therefore, I am rephrasing it:<=
o:p>


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


The main goal of SUPA is to provide application based policies and mea=
ns to model and program the abstract view of network infrastructure and ser=
vice function interdependencies in order to support and AUTOMATICALLY feed =
network management and controlling policies. This can be realized by:<=
/o:p>


 


(1) modeling the network graph, which among others include policy mode=
ls, data models and application based policies, using YANG, 

 


(2) applying NETCONF (or RESTCONF) to enable dissemination of up to da=
te (fresh) network graphs in a secure and efficient manner between network =
service systems and network management and controlling systems, =



"between network=
 service systems and network management and controlling system". What =
are those? I don't see them in your figure.

Also, why should all of these need to know about the topology?


 


Georgios: In the figure, the enhanced OSS represents the network serv=
ice system and the controller represents the network management
 and controlling system.


In this context, network services can be used to provide the required=
  configuration and application programming interfaces to
 service developers. Subsequently, a network service can use the applicatio=
n based demands (for actions and constraints) and possibly update its assoc=
iated network service  attributes. Examples of network services that c=
an modify  the network service attributes
 are for example, L3VPN configuration and IPv6 transitions. 


For each network service instance a network graph needs to be generat=
ed and maintained.



The up to date network graph needs to (1) be communicated between the=
  network service systems and the network   management and
 controlling systems, (2) map the attributes of the network service graph i=
nto specific network management policies.


  



Best regards,


Georgios


 


 


 






Regards, Benoit






--_000_C5034E44CD620A44971BAAEB372655DC635F49LHREML516MBXchina_--


From nobody Wed Sep 24 06:13:24 2014
Return-Path: 
X-Original-To: supa@ietfa.amsl.com
Delivered-To: supa@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 842471A00DC for ; Wed, 24 Sep 2014 06:13:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.987
X-Spam-Level: 
X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 PxirZszDtYAl for ; Wed, 24 Sep 2014 06:13:12 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D6BF1A00FC for ; Wed, 24 Sep 2014 06:13:12 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BMY65228; Wed, 24 Sep 2014 13:13:11 +0000 (GMT)
Received: from LHREML513-MBB.china.huawei.com ([fe80::b810:863:a57e:3ff]) by lhreml406-hub.china.huawei.com ([10.201.5.243]) with mapi id 14.03.0158.001; Wed, 24 Sep 2014 14:13:09 +0100
From: Hosnieh Rafiee 
To: "supa@ietf.org" 
Thread-Topic: [Supa] Discussion on SUPA draft chatter
Thread-Index: Ac/Egg4rnM3Ac+nuTf6RywsQVZWuJwTdD/qw
Date: Wed, 24 Sep 2014 13:13:08 +0000
Message-ID: <814D0BFB77D95844A01CA29B44CBF8A7A43A9E@lhreml513-mbb.china.huawei.com>
References: <008201cfc482$191b5d10$4b521730$@tsinghua.edu.cn>
In-Reply-To: <008201cfc482$191b5d10$4b521730$@tsinghua.edu.cn>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.221.82.100]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/supa/ryVH5OeimYDpKPjTLC5UPEWmKqY
Subject: Re: [Supa] Discussion on SUPA draft chatter
X-BeenThere: supa@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Sep 2014 13:13:17 -0000

Hi,

I actually only skimmed the previous discussion on the charter so maybe oth=
er people already suggested what I am suggesting here... =20


>>=A0=A0=A0 I-D 'Guidelines on using NETCONF (or RESTCONF) authentication a=
nd=20
=A0=A0=A0=A0authorization mechanisms to achieve security protection and iso=
lation'=20
=A0=A0=A0=A0as an Informational RFC.

Just a quick idea. Probably  you heard about secauth. It is for authenticat=
ion and authorization.
Maybe secauth can be used in this purpose and the informational draft can b=
e about how to use that?

Other suggestions:
- maybe it is good to also include data privacy as a requirement part of th=
e charter. privacy Because it appears that there are some important control=
 data will be exchanged between the devices.
- What about performance and optimizations. By looking at the charter, you =
tried to have automation but what is the cost of this automation. There mig=
ht be different solution later that increases traffic on the network and th=
erefore decrease the performance. So it might be good to also explicitly co=
ver optimization not only as an automation but also considering other facto=
rs.



I also take a quick look on the problem statement draft=20
http://tools.ietf.org/html/draft-karagiannis-supa-problem-statement-00=20

>>Currently, the separation of development and operation of network
   technologies leads to slow deployment of network functions/devices
   and poor user experiences.

I think another problem might be that different network providers might use=
 different architecture for their software defined based systems. so there =
might be no orchestration between them.=20

Thanks,
Best,
Hosnieh



From nobody Wed Sep 24 07:25:33 2014
Return-Path: 
X-Original-To: supa@ietfa.amsl.com
Delivered-To: supa@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C2681A01E0 for ; Wed, 24 Sep 2014 07:25:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.986
X-Spam-Level: 
X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 230oVUqh1nHZ for ; Wed, 24 Sep 2014 07:25: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 4932D1A0190 for ; Wed, 24 Sep 2014 07:24:40 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BMY72644; Wed, 24 Sep 2014 14:24:39 +0000 (GMT)
Received: from SZXEMA407-HUB.china.huawei.com (10.82.72.39) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 24 Sep 2014 15:24:37 +0100
Received: from SZXEMA509-MBS.china.huawei.com ([169.254.2.166]) by SZXEMA407-HUB.china.huawei.com ([10.82.72.39]) with mapi id 14.03.0158.001; Wed, 24 Sep 2014 22:24:33 +0800
From: "Liushucheng (Will)" 
To: "supa@ietf.org" 
Thread-Topic: bof request text
Thread-Index: Ac/YAy09696cAFlgTtaF9cU29rHdGA==
Date: Wed, 24 Sep 2014 14:24:33 +0000
Message-ID: 
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.66.78.79]
Content-Type: multipart/alternative; boundary="_000_C9B5F12337F6F841B35C404CF0554ACB5FF9998DSZXEMA509MBSchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/supa/a0NzjVE13HE5fnyEWs2TvMLsAP0
Subject: [Supa] bof request text
X-BeenThere: supa@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Sep 2014 14:25:17 -0000

--_000_C9B5F12337F6F841B35C404CF0554ACB5FF9998DSZXEMA509MBSchi_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgYWxsLA0KDQpJ4oCZbSBzZW5kaW5nIHlvdSB0aGUgdXBkYXRlZCB2ZXJzaW9uIG9mIGJvZiBy
ZXF1ZXN0LiBQbGVhc2UgcmV2aWV3IGl0IGFuZCBsZXQgbWUga25vdyB5b3VyIHRob3VnaHQuDQoN
Cg0KVGhlIG1haW4gY2hhbmdlcyBhcmU6DQoNCkkgY3V0IHRoZSByZXF1ZXN0IHNob3J0IGJ5IHJl
bW92aW5nIHRoZSAnJ1dvcmsgaXRlbXMgcmVsYXRlZCB0byBTVVBBIGluY2x1ZGU6JycgYW5kICcn
TWlsZXN0b25lczonJywgd2hpY2ggYXJlIHVzdWFsbHkgbm90IHB1dCBpbiB0aGUgcmVxdWVzdC4g
KFF1ZXN0aW9uOiBzaG91bGQgSSByZW1vdmUgdGhlbT8pDQoNCkkgdXBkYXRlZCB0aGUgbGlua3Mg
YW5kIHRoZSByZXNwb25zaWJsZSBBRCwgYW5kIG1ha2UgdGhlIGZvcm1hdCBuZWF0Lg0KDQoNCg0K
U1VQQQ0KDQogICogICBMb25nIG5hbWUgYW5kIGFiYnJldmlhdGlvbjogU1VQQSAoU2hhcmVkIFVu
aWZpZWQgUG9saWN5IEF1dG9tYXRpb24pDQogICogICBEZXNjcmlwdGlvbjogTmV0d29yayBvcGVy
YXRvcnMgYXJlIGZhY2VkIHdpdGggbmV0d29ya3Mgb2YgaW5jcmVhc2luZyBzaXplIGFuZCBjb21w
bGV4aXR5IHdoaWxlIHRyeWluZyB0byBpbXByb3ZlIHRoZWlyIHF1YWxpdHkgYW5kIGF2YWlsYWJp
bGl0eSwgYXMgbW9yZSBhbmQgbW9yZSBzZXJ2aWNlcyBkZXBlbmQgb24gdGhlbS4gQXV0b21hdGlu
ZyB0aGUgd2F5IG9mIGV4cG9zaW5nIGEgdmlldyBvZiB0aGUgbmV0d29yayB0byBhcHBsaWNhdGlv
bnMgbWF5IHByb3ZpZGUgc2lnbmlmaWNhbnQgaW1wcm92ZW1lbnRzIGluIGNvbmZpZ3VyYXRpb24g
YWdpbGl0eSwgZXJyb3IgZGV0ZWN0aW9uIGFuZCB1cHRpbWUgZm9yIG9wZXJhdG9ycy4gSG93ZXZl
ciB0aGUgcmVhbCB2YWx1ZSBiZWhpbmQgY2VudHJhbCBjb25maWd1cmF0aW9uIHNjaGVtZXMgbGll
cyB3aXRoaW4gdGhlIHBvc3NpYmxlIHNpbXBsaWZpY2F0aW9uIHRocm91Z2ggbW9kZWxzIHByb3Zp
ZGVkIGJ5IHN1Y2ggc3lzdGVtcyB0byBhcHBsaWNhdGlvbnMgYW5kIG5ldHdvcmsgc2VydmljZXMg
cnVubmluZyBhYm92ZSB0aGVtIChvbiB0aGUgc28tY2FsbGVkIG5vcnRoYm91bmQgc2lkZSkuIFdl
bGwtZGVzaWduZWQgbW9kZWxzIGFyZSBhYmxlIHRvIHByb3ZpZGUgYSB3aWRlIHJhbmdlIG9mIGdy
YW51bGFyaXR5IGZvciB2YXJpb3VzIGFwcGxpY2F0aW9ucyBhbmQgbmV0d29yayBzZXJ2aWNlcyBu
ZWVkcywgZnJvbSB0aGUgbG93ZXItbGV2ZWwgcGh5c2ljYWwgbmV0d29yayB0byBoaWdoLWxldmVs
IGFwcGxpY2F0aW9uIHNlcnZpY2VzLg0KDQpQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgaXMgYSBuZXcg
dmVyc2lvbiBvZiBhcG9uZiBib2YgcHJvcG9zYWwgYmFzZWQgb24gY29tbWVudHMgcmVjZWl2ZWQu
DQoNClRoZSBtYWluIGdvYWwgb2YgU1VQQSBpcyB0byBwcm92aWRlIGEgd2F5IGZvciBhcHBsaWNh
dGlvbnMgYW5kIGZvciBuZXR3b3JrIHNlcnZpY2VzIHRvIHNwZWNpZnkgU0hBUkVEIGFwcGxpY2F0
aW9uIGJhc2VkIFBPTElDSUVTIHRvIHRoZSBuZXR3b3JrIGluZnJhc3RydWN0dXJlIHVzaW5nIGEg
c2ltcGxpZmllZCB2aWV3IG9mIHRoZSBuZXR3b3JrLiBUaGlzIGNhbiBiZSByZWFsaXplZCBieTog
KDEpIG1vZGVsaW5nIHRoZSBuZXR3b3JrIGluZnJhc3RydWN0dXJlIGFzIGFuIHNpbXBsaWZpZWQg
bmV0d29yayBncmFwaCB1c2luZyBhIG1vZGVsaW5nIGxhbmd1YWdlIHN1Y2ggYXMgWUFORywgKDIp
IHRyYW5zcG9ydGluZyBtb2RlbCBpbnN0YW5jZXMgZWl0aGVyIHVzaW5nIE5FVENPTkYgb3IgUkVT
VENPTkYgYW5kICgzKSBwcm92aWRpbmcgZ3VpZGVsaW5lcyBvbiBBVVRPTUFUSUNBTExZIG1hcHBp
bmcgcG9saWNpZXMgdG8gYXR0cmlidXRlcyBvZiB0aGUgbmV0d29yayBncmFwaHMuDQoNCiAgKiAg
IEFnZW5kYTogVEJEDQogICogICBTdGF0dXM6IFdHIEZvcm1pbmcNCiAgKiAgIFJlc3BvbnNpYmxl
IEFEOiBCZW5vaXQgQ2xhaXNlDQogICogICBCb0YgcHJvcG9uZW50czogVEJEDQogICogICBCb0Yg
Q2hhaXJzOiBUQkQNCiAgKiAgIE51bWJlciBvZiBwZW9wbGUgZXhwZWN0ZWQgdG8gYXR0ZW5kOiAx
MDANCiAgKiAgIExlbmd0aCBvZiBzZXNzaW9uICgxLCAxLjUsIDIsIG9yIDIuNSBob3Vycyk6IDEu
NSBob3Vycw0KICAqICAgQ29uZmxpY3RzIHRvIGF2b2lkICh3aG9sZSBBcmVhcyBhbmQvb3IgV0dz
KToNCiAgKiAgIERvZXMgaXQgcmVxdWlyZSBXZWJFWD8gSWYgc28sIHdoeT86IG5vDQogICogICBE
b2VzIGl0IHJlcXVpcmUgTWVldGVjaG8/IElmIHNvLCB3aHk/OiBubw0KICAqICAgTGlua3MgdG8g
dGhlIG1haWxpbmcgbGlzdCwgZHJhZnQgY2hhcnRlciBpZiBhbnksIHJlbGV2YW50IEludGVybmV0
LURyYWZ0cywgZXRjLg0KICAgICAqICAgQm9GIEluZm8gUGFnZTog4oCLaHR0cDovL2xpdXNodWNo
ZW5nLmdpdGh1Yi5pby9TVVBBLzxodHRwOi8vbGl1c2h1Y2hlbmcuZ2l0aHViLmlvL1NVUEEvPg0K
ICAgICAqICAgTWFpbGluZyBsaXN0IGFuZCBpbmZvIHBhZ2U6IOKAi3N1cGFAaWV0Zi5vcmc8bWFp
bHRvOnN1cGFAaWV0Zi5vcmc+OyDigItodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp
bmZvL3N1cGE8aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdXBhPjsNCiAg
ICAgKiAgIERyYWZ0IGNoYXJ0ZXI6IOKAi2h0dHBzOi8vZ2l0aHViLmNvbS9saXVzaHVjaGVuZy9T
VVBBL3dpa2kvU1VQQS1DaGFydGVyPGh0dHBzOi8vZ2l0aHViLmNvbS9saXVzaHVjaGVuZy9TVVBB
L3dpa2kvU1VQQS1DaGFydGVyPiA74oCLaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUv
d2ViL3N1cGEvY3VycmVudC9tc2cwMDA1MS5odG1sPGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1h
cmNoaXZlL3dlYi9zdXBhL2N1cnJlbnQvbXNnMDAwNTEuaHRtbD4NCiAgICAgKiAgIFJlbGV2YW50
IGRyYWZ0czoNCiAgICAgICAgKiAgIGRyYWZ0LWthcmFnaWFubmlzLXN1cGEtcHJvYmxlbS1zdGF0
ZW1lbnQ8aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQta2FyYWdpYW5uaXMtc3VwYS1w
cm9ibGVtLXN0YXRlbWVudD4NCiAgICAgICAgKiAgIGRyYWZ0LWNoZW5nLXN1cGEtZGRjLXVzZS1j
YXNlczxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1jaGVuZy1zdXBhLWRkYy11c2Ut
Y2FzZXM+DQogICAgICAgICogICBkcmFmdC1wZW50aWtvdXNpcy1zdXBhLW1hcHBpbmc8aHR0cDov
L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcGVudGlrb3VzaXMtc3VwYS1tYXBwaW5nPg0KICAg
ICAgICAqICAgZHJhZnQtY29udHJlcmFzLXN1cGEteWFuZy1uZXR3b3JrLXRvcG88aHR0cDovL3Rv
b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY29udHJlcmFzLXN1cGEteWFuZy1uZXR3b3JrLXRvcG8+
DQogICAgICAgICogICBkcmFmdC16YWFsb3VrLXN1cGEtY29uZmlndXJhdGlvbi1tb2RlbDxodHRw
Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16YWFsb3VrLXN1cGEtY29uZmlndXJhdGlvbi1t
b2RlbD4NCg0KDQpSZWdhcmRzLA0KU2h1Y2hlbmcgTElVIChXaWxsKQ0KLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0NClNodWNoZW5nIExJVSAoV2lsbCksIFBoLkQuDQpSZXNlYXJjaGVyICYgU3Rh
bmRhcmQgUmVwcmVzZW50YXRpdmUNCkh1YXdlaSBUZWNobm9sb2dpZXMgQ28uLEx0ZA0KbGl1c2h1
Y2hlbmdAaHVhd2VpLmNvbTxtYWlsdG86bGl1c2h1Y2hlbmdAaHVhd2VpLmNvbT4NCmh0dHA6Ly93
d3cubGlua2VkaW4uY29tL2luL3NodWNoZW5nDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K
DQo=

--_000_C9B5F12337F6F841B35C404CF0554ACB5FF9998DSZXEMA509MBSchi_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K
CXtmb250LWZhbWlseTrlrovkvZM7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpA
Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1
IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBh
bm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IlxA5a6L5L2TIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UN
Cgl7Zm9udC1mYW1pbHk66buY6K6k5a2X5L2TO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpw
Lk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJ
bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCXRleHQtYWxpZ246anVzdGlmeTsNCgl0ZXh0LWp1c3Rp
Znk6aW50ZXItaWRlb2dyYXBoOw0KCWZvbnQtc2l6ZToxMC41cHQ7DQoJZm9udC1mYW1pbHk6IkNh
bGlicmkiLCJzYW5zLXNlcmlmIjt9DQpoNA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTsNCgltc28t
c3R5bGUtbGluazoi5qCH6aKYIDQgQ2hhciI7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJ
bWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4t
bGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7DQoJZm9u
dC13ZWlnaHQ6Ym9sZDt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w
cmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7
fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlv
cml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K
cC5Nc29QbGFpblRleHQsIGxpLk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28t
c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6Iue6r+aWh+acrCBDaGFyIjsNCglt
YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuNXB0Ow0K
CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KcA0KCXttc28tc3R5bGUtcHJp
b3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsN
Cgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1z
aXplOjEyLjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7
bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs
InNhbnMtc2VyaWYiOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi40Q2hhcg0KCXttc28tc3R5
bGUtbmFtZToi5qCH6aKYIDQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk7DQoJbXNvLXN0
eWxlLWxpbms6Iuagh+mimCA0IjsNCglmb250LWZhbWlseTrlrovkvZM7DQoJZm9udC13ZWlnaHQ6
Ym9sZDt9DQpzcGFuLkNoYXINCgl7bXNvLXN0eWxlLW5hbWU6Iue6r+aWh+acrCBDaGFyIjsNCglt
c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms657qv5paH5pysOw0KCWZvbnQt
ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5hcHBsZS1jb252ZXJ0ZWQtc3Bh
Y2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVkLXNwYWNlO30NCnNwYW4uaWNvbg0K
CXttc28tc3R5bGUtbmFtZTppY29uO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl
OmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KLyog
UGFnZSBEZWZpbml0aW9ucyAqLw0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3
OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRT
ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpA
bGlzdCBsMA0KCXttc28tbGlzdC1pZDo2Mjk4MTkwMjA7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRz
Ojg0NzkyNTYyODt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6
YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MzYuMHB0
Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0
Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs
aXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl
dmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NzIuMHB0Ow0KCW1zby1sZXZlbC1udW1i
ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQt
c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250
LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVs
LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt
dGFiLXN0b3A6MTA4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4
dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt
aWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt
YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTQ0
LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4
LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5n
czt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K
CW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTgwLjBwdDsNCgltc28t
bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28t
YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBs
MDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10
ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MjE2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVy
LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNp
emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7
bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt
c28tbGV2ZWwtdGFiLXN0b3A6MjUyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl
ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K
CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51
bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi
LXN0b3A6Mjg4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p
bmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5
OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6
YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MzI0LjBw
dDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw
dDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9
DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDoxODM5MzAwMTYwOw0KCW1zby1saXN0LXRlbXBsYXRl
LWlkczoxNDc3NzM5OTc0O30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv
cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoz
Ni4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0x
OC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7
fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt
c28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDo3Mi4wcHQ7DQoJbXNvLWxldmVs
LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2kt
Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1iaWRp
LWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28t
bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1s
ZXZlbC10YWItc3RvcDoxMDguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN
Cgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u
dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVy
LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv
cDoxNDQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu
dDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2lu
Z2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs
ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxODAuMHB0Ow0K
CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0K
CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBs
aXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl
dmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyMTYuMHB0Ow0KCW1zby1sZXZlbC1u
dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZv
bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVs
Nw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn
Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyNTIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp
b246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w
cHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2
ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl
bC10YWItc3RvcDoyODguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0
ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m
YW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv
cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoz
MjQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot
MTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rp
bmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGNt
O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz
IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp
ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h
cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp
Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IlpILUNOIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0i
Izk1NEY3MiIgc3R5bGU9InRleHQtanVzdGlmeS10cmltOnB1bmN0dWF0aW9uIj4NCjxkaXYgY2xh
c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V
UyI+SGkgYWxsLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SeKAmW0gc2VuZGluZyB5b3UgdGhlIHVwZGF0
ZWQgdmVyc2lvbiBvZiBib2YgcmVxdWVzdC4gUGxlYXNlIHJldmlldyBpdCBhbmQgbGV0IG1lIGtu
b3cgeW91ciB0aG91Z2h0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+VGhlIG1haW4gY2hhbmdlcyBh
cmU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g
bGFuZz0iRU4tVVMiPkkgY3V0IHRoZSByZXF1ZXN0IHNob3J0IGJ5IHJlbW92aW5nIHRoZSAnJ1dv
cmsgaXRlbXMgcmVsYXRlZCB0byBTVVBBIGluY2x1ZGU6JycgYW5kICcnTWlsZXN0b25lczonJywg
d2hpY2ggYXJlIHVzdWFsbHkgbm90IHB1dCBpbiB0aGUgcmVxdWVzdC4gKFF1ZXN0aW9uOiBzaG91
bGQgSSByZW1vdmUgdGhlbT8pPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs
YWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPkkgdXBkYXRlZCB0aGUgbGlua3MgYW5kIHRoZSBy
ZXNwb25zaWJsZSBBRCwgYW5kIG1ha2UgdGhlIGZvcm1hdCBuZWF0LjxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8aDQgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDo1LjRw
dDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206MGNtO21hcmdpbi1sZWZ0OjBjbTttYXJn
aW4tYm90dG9tOi4wMDAxcHQ7cGFnZS1icmVhay1hZnRlcjphdm9pZDtiYWNrZ3JvdW5kOndoaXRl
Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTrpu5jorqTlrZfkvZM7Y29sb3I6YmxhY2siPlNVUEE8bzpwPjwvbzpwPjwvc3Bhbj48L2g0Pg0K
PHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjpibGFj
azttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0
LWFsaWduOmxlZnQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzE7YmFja2dyb3VuZDp3aGl0ZSI+DQo8
c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk66buY
6K6k5a2X5L2TIj5Mb25nIG5hbWUgYW5kIGFiYnJldmlhdGlvbjogU1VQQSAoU2hhcmVkIFVuaWZp
ZWQgUG9saWN5IEF1dG9tYXRpb24pPG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9ImNvbG9yOmJsYWNrO21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQtYWxpZ246bGVmdDttc28tbGlzdDpsMCBsZXZlbDEg
bGZvMTtiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTrpu5jorqTlrZfkvZMiPkRlc2NyaXB0aW9uOiBOZXR3b3Jr
IG9wZXJhdG9ycyBhcmUgZmFjZWQgd2l0aCBuZXR3b3JrcyBvZiBpbmNyZWFzaW5nIHNpemUgYW5k
IGNvbXBsZXhpdHkgd2hpbGUgdHJ5aW5nIHRvIGltcHJvdmUgdGhlaXIgcXVhbGl0eSBhbmQgYXZh
aWxhYmlsaXR5LCBhcyBtb3JlIGFuZCBtb3JlIHNlcnZpY2VzIGRlcGVuZCBvbiB0aGVtLiBBdXRv
bWF0aW5nDQogdGhlIHdheSBvZiBleHBvc2luZyBhIHZpZXcgb2YgdGhlIG5ldHdvcmsgdG8gYXBw
bGljYXRpb25zIG1heSBwcm92aWRlIHNpZ25pZmljYW50IGltcHJvdmVtZW50cyBpbiBjb25maWd1
cmF0aW9uIGFnaWxpdHksIGVycm9yIGRldGVjdGlvbiBhbmQgdXB0aW1lIGZvciBvcGVyYXRvcnMu
IEhvd2V2ZXIgdGhlIHJlYWwgdmFsdWUgYmVoaW5kIGNlbnRyYWwgY29uZmlndXJhdGlvbiBzY2hl
bWVzIGxpZXMgd2l0aGluIHRoZSBwb3NzaWJsZSBzaW1wbGlmaWNhdGlvbg0KIHRocm91Z2ggbW9k
ZWxzIHByb3ZpZGVkIGJ5IHN1Y2ggc3lzdGVtcyB0byBhcHBsaWNhdGlvbnMgYW5kIG5ldHdvcmsg
c2VydmljZXMgcnVubmluZyBhYm92ZSB0aGVtIChvbiB0aGUgc28tY2FsbGVkIG5vcnRoYm91bmQg
c2lkZSkuIFdlbGwtZGVzaWduZWQgbW9kZWxzIGFyZSBhYmxlIHRvIHByb3ZpZGUgYSB3aWRlIHJh
bmdlIG9mIGdyYW51bGFyaXR5IGZvciB2YXJpb3VzIGFwcGxpY2F0aW9ucyBhbmQgbmV0d29yayBz
ZXJ2aWNlcyBuZWVkcywgZnJvbQ0KIHRoZSBsb3dlci1sZXZlbCBwaHlzaWNhbCBuZXR3b3JrIHRv
IGhpZ2gtbGV2ZWwgYXBwbGljYXRpb24gc2VydmljZXMuPG86cD48L286cD48L3NwYW4+PC9saT48
L3VsPg0KPHAgc3R5bGU9Im1hcmdpbi1sZWZ0OjIxLjBwdDttc28tcGFyYS1tYXJnaW4tbGVmdDoy
LjBnZDtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk66buY6K6k5a2X5L2TO2NvbG9yOmJsYWNrIj5QbGVhc2Ugbm90
ZSB0aGF0IHRoaXMgaXMgYSBuZXcgdmVyc2lvbiBvZiBhcG9uZiBib2YgcHJvcG9zYWwgYmFzZWQg
b24gY29tbWVudHMgcmVjZWl2ZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1h
cmdpbi1sZWZ0OjIxLjBwdDttc28tcGFyYS1tYXJnaW4tbGVmdDoyLjBnZDtiYWNrZ3JvdW5kOndo
aXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk66buY6K6k5a2X5L2TO2NvbG9yOmJsYWNrIj5UaGUgbWFpbiBnb2FsIG9mIFNVUEEgaXMgdG8g
cHJvdmlkZSBhIHdheSBmb3IgYXBwbGljYXRpb25zIGFuZCBmb3IgbmV0d29yayBzZXJ2aWNlcyB0
byBzcGVjaWZ5IFNIQVJFRCBhcHBsaWNhdGlvbg0KIGJhc2VkIFBPTElDSUVTIHRvIHRoZSBuZXR3
b3JrIGluZnJhc3RydWN0dXJlIHVzaW5nIGEgc2ltcGxpZmllZCB2aWV3IG9mIHRoZSBuZXR3b3Jr
LiBUaGlzIGNhbiBiZSByZWFsaXplZCBieTogKDEpIG1vZGVsaW5nIHRoZSBuZXR3b3JrIGluZnJh
c3RydWN0dXJlIGFzIGFuIHNpbXBsaWZpZWQgbmV0d29yayBncmFwaCB1c2luZyBhIG1vZGVsaW5n
IGxhbmd1YWdlIHN1Y2ggYXMgWUFORywgKDIpIHRyYW5zcG9ydGluZyBtb2RlbCBpbnN0YW5jZXMg
ZWl0aGVyDQogdXNpbmcgTkVUQ09ORiBvciBSRVNUQ09ORiBhbmQgKDMpIHByb3ZpZGluZyBndWlk
ZWxpbmVzIG9uIEFVVE9NQVRJQ0FMTFkgbWFwcGluZyBwb2xpY2llcyB0byBhdHRyaWJ1dGVzIG9m
IHRoZSBuZXR3b3JrIGdyYXBocy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8dWwgdHlwZT0iZGlz
YyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOmJsYWNrO21zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQtYWxpZ246bGVmdDtt
c28tbGlzdDpsMSBsZXZlbDEgbGZvMjtiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIGxhbmc9IkVO
LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTrpu5jorqTlrZfkvZMiPkFn
ZW5kYTogVEJEPG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9ImNvbG9yOmJsYWNrO21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvO3RleHQtYWxpZ246bGVmdDttc28tbGlzdDpsMSBsZXZlbDEgbGZvMjtiYWNrZ3Jv
dW5kOndoaXRlIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTrpu5jorqTlrZfkvZMiPlN0YXR1czogV0cgRm9ybWluZzxvOnA+PC9vOnA+PC9z
cGFuPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjpibGFjazttc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOmxl
ZnQ7bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzI7YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBsYW5n
PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk66buY6K6k5a2X5L2T
Ij5SZXNwb25zaWJsZSBBRDogQmVub2l0IENsYWlzZTxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxp
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjpibGFjazttc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOmxlZnQ7bXNvLWxpc3Q6
bDEgbGV2ZWwxIGxmbzI7YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk66buY6K6k5a2X5L2TIj5Cb0YgcHJvcG9u
ZW50czogVEJEPG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9ImNvbG9yOmJsYWNrO21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvO3RleHQtYWxpZ246bGVmdDttc28tbGlzdDpsMSBsZXZlbDEgbGZvMjtiYWNrZ3Jv
dW5kOndoaXRlIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTrpu5jorqTlrZfkvZMiPkJvRiBDaGFpcnM6IFRCRDxvOnA+PC9vOnA+PC9zcGFu
PjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjpibGFjazttc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOmxlZnQ7
bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzI7YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBsYW5nPSJF
Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk66buY6K6k5a2X5L2TIj5O
dW1iZXIgb2YgcGVvcGxlIGV4cGVjdGVkIHRvIGF0dGVuZDogMTAwPG86cD48L286cD48L3NwYW4+
PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOmJsYWNrO21zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQtYWxpZ246bGVmdDtt
c28tbGlzdDpsMSBsZXZlbDEgbGZvMjtiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIGxhbmc9IkVO
LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTrpu5jorqTlrZfkvZMiPkxl
bmd0aCBvZiBzZXNzaW9uICgxLCAxLjUsIDIsIG9yIDIuNSBob3Vycyk6IDEuNSBob3VyczxvOnA+
PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjpibGFj
azttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0
LWFsaWduOmxlZnQ7bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzI7YmFja2dyb3VuZDp3aGl0ZSI+DQo8
c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk66buY
6K6k5a2X5L2TIj5Db25mbGljdHMgdG8gYXZvaWQgKHdob2xlIEFyZWFzIGFuZC9vciBXR3MpOjxv
OnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjpi
bGFjazttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0
ZXh0LWFsaWduOmxlZnQ7bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzI7YmFja2dyb3VuZDp3aGl0ZSI+
DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
6buY6K6k5a2X5L2TIj5Eb2VzIGl0IHJlcXVpcmUgV2ViRVg/IElmIHNvLCB3aHk/OiBubzxvOnA+
PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjpibGFj
azttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0
LWFsaWduOmxlZnQ7bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzI7YmFja2dyb3VuZDp3aGl0ZSI+DQo8
c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk66buY
6K6k5a2X5L2TIj5Eb2VzIGl0IHJlcXVpcmUgTWVldGVjaG8/IElmIHNvLCB3aHk/OiBubzxvOnA+
PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjpibGFj
azttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0
LWFsaWduOmxlZnQ7bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzI7YmFja2dyb3VuZDp3aGl0ZSI+DQo8
c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk66buY
6K6k5a2X5L2TIj5MaW5rcyB0byB0aGUgbWFpbGluZyBsaXN0LCBkcmFmdCBjaGFydGVyIGlmIGFu
eSwgcmVsZXZhbnQgSW50ZXJuZXQtRHJhZnRzLCBldGMuPG86cD48L286cD48L3NwYW4+DQo8dWwg
dHlwZT0iY2lyY2xlIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6YmxhY2s7
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1h
bGlnbjpsZWZ0O21zby1saXN0OmwxIGxldmVsMiBsZm8yO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNw
YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5Oum7mOiu
pOWtl+S9kyI+Qm9GIEluZm8gUGFnZTo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl
Ij4mbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cDovL2xpdXNodWNoZW5nLmdpdGh1Yi5pby9TVVBB
LyI+PHNwYW4gY2xhc3M9Imljb24iPjxzcGFuIHN0eWxlPSJjb2xvcjojNDQwMDg4Ij7igIs8L3Nw
YW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojNDQwMDg4Ij5odHRwOi8vbGl1c2h1Y2hlbmcu
Z2l0aHViLmlvL1NVUEEvPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6YmxhY2s7bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1hbGlnbjpsZWZ0O21zby1saXN0OmwxIGxl
dmVsMiBsZm8yO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5Oum7mOiupOWtl+S9kyI+TWFpbGluZyBsaXN0IGFu
ZCBpbmZvIHBhZ2U6PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z
cGFuPjxhIGhyZWY9Im1haWx0bzpzdXBhQGlldGYub3JnIj48c3BhbiBjbGFzcz0iaWNvbiI+PHNw
YW4gc3R5bGU9ImNvbG9yOiM0NDAwODgiPuKAizwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImNv
bG9yOiM0NDAwODgiPnN1cGFAaWV0Zi5vcmc8L3NwYW4+PC9hPjs8c3BhbiBjbGFzcz0iYXBwbGUt
Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v
cmcvbWFpbG1hbi9saXN0aW5mby9zdXBhIj48c3BhbiBjbGFzcz0iaWNvbiI+PHNwYW4gc3R5bGU9
ImNvbG9yOiM0NDAwODgiPuKAizwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiM0NDAw
ODgiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3VwYTwvc3Bhbj48L2E+
OzxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xv
cjpibGFjazttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
bzt0ZXh0LWFsaWduOmxlZnQ7bXNvLWxpc3Q6bDEgbGV2ZWwyIGxmbzI7YmFja2dyb3VuZDp3aGl0
ZSI+DQo8c3BhbiBsYW5nPSJERSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
6buY6K6k5a2X5L2TIj5EcmFmdCBjaGFydGVyOjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt
c3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5Oum7mOiupOWtl+S9kyI+PGEgaHJlZj0iaHR0cHM6Ly9n
aXRodWIuY29tL2xpdXNodWNoZW5nL1NVUEEvd2lraS9TVVBBLUNoYXJ0ZXIiPjxzcGFuIGNsYXNz
PSJpY29uIj48c3BhbiBsYW5nPSJERSIgc3R5bGU9ImNvbG9yOiM0NDAwODgiPuKAizwvc3Bhbj48
L3NwYW4+PHNwYW4gbGFuZz0iREUiIHN0eWxlPSJjb2xvcjojNDQwMDg4Ij5odHRwczovL2dpdGh1
Yi5jb20vbGl1c2h1Y2hlbmcvU1VQQS93aWtpL1NVUEEtQ2hhcnRlcjwvc3Bhbj48L2E+PC9zcGFu
PjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIGxhbmc9IkRFIiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTrpu5jorqTlrZfkvZMiPiZuYnNwOzwvc3Bh
bj48L3NwYW4+PHNwYW4gbGFuZz0iREUiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5Oum7mOiupOWtl+S9kyI+Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk66buY6K6k5a2X5L2TIj48YSBocmVmPSJodHRwOi8vd3d3
LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvc3VwYS9jdXJyZW50L21zZzAwMDUxLmh0bWwiPjxz
cGFuIGNsYXNzPSJpY29uIj48c3BhbiBsYW5nPSJERSIgc3R5bGU9ImNvbG9yOiM0NDAwODgiPuKA
izwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iREUiIHN0eWxlPSJjb2xvcjojNDQwMDg4Ij5odHRw
Oi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvc3VwYS9jdXJyZW50L21zZzAwMDUxLmh0
bWw8L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBsYW5nPSJERSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk66buY6K6k5a2X5L2TIj48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6YmxhY2s7bXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1hbGlnbjpsZWZ0O21zby1saXN0Omwx
IGxldmVsMiBsZm8yO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5Oum7mOiupOWtl+S9kyI+UmVsZXZhbnQgZHJh
ZnRzOjxvOnA+PC9vOnA+PC9zcGFuPg0KPHVsIHR5cGU9InNxdWFyZSI+DQo8bGkgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9ImNvbG9yOmJsYWNrO21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQtYWxpZ246bGVmdDttc28tbGlzdDpsMSBsZXZlbDMg
bGZvMjtiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTrpu5jorqTlrZfkvZMiPjxhIGhyZWY9Imh0dHA6Ly90b29s
cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWthcmFnaWFubmlzLXN1cGEtcHJvYmxlbS1zdGF0ZW1lbnQi
PjxzcGFuIHN0eWxlPSJjb2xvcjojNDQwMDg4Ij5kcmFmdC1rYXJhZ2lhbm5pcy1zdXBhLXByb2Js
ZW0tc3RhdGVtZW50PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6YmxhY2s7bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1hbGlnbjpsZWZ0O21zby1saXN0OmwxIGxldmVs
MyBsZm8yO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5Oum7mOiupOWtl+S9kyI+PGEgaHJlZj0iaHR0cDovL3Rv
b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2hlbmctc3VwYS1kZGMtdXNlLWNhc2VzIj48c3BhbiBz
dHlsZT0iY29sb3I6IzQ0MDA4OCI+ZHJhZnQtY2hlbmctc3VwYS1kZGMtdXNlLWNhc2VzPC9zcGFu
PjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
Y29sb3I6YmxhY2s7bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG87dGV4dC1hbGlnbjpsZWZ0O21zby1saXN0OmwxIGxldmVsMyBsZm8yO2JhY2tncm91bmQ6
d2hpdGUiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5Oum7mOiupOWtl+S9kyI+PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv
ZHJhZnQtcGVudGlrb3VzaXMtc3VwYS1tYXBwaW5nIj48c3BhbiBzdHlsZT0iY29sb3I6IzQ0MDA4
OCI+ZHJhZnQtcGVudGlrb3VzaXMtc3VwYS1tYXBwaW5nPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwv
c3Bhbj48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6YmxhY2s7bXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1hbGlnbjps
ZWZ0O21zby1saXN0OmwxIGxldmVsMyBsZm8yO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gbGFu
Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5Oum7mOiupOWtl+S9
kyI+PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY29udHJlcmFzLXN1
cGEteWFuZy1uZXR3b3JrLXRvcG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojNDQwMDg4Ij5kcmFmdC1j
b250cmVyYXMtc3VwYS15YW5nLW5ldHdvcmstdG9wbzwvc3Bhbj48L2E+PG86cD48L286cD48L3Nw
YW4+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOmJsYWNrO21zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQtYWxpZ246bGVm
dDttc28tbGlzdDpsMSBsZXZlbDMgbGZvMjtiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIGxhbmc9
IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTrpu5jorqTlrZfkvZMi
PjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXphYWxvdWstc3VwYS1j
b25maWd1cmF0aW9uLW1vZGVsIj48c3BhbiBzdHlsZT0iY29sb3I6IzQ0MDA4OCI+ZHJhZnQtemFh
bG91ay1zdXBhLWNvbmZpZ3VyYXRpb24tbW9kZWw8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFu
PjwvbGk+PC91bD4NCjwvbGk+PC91bD4NCjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlJlZ2FyZHMsPC9z
cGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlNo
dWNoZW5nIExJVSAoV2lsbCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48aT48c3BhbiBsYW5nPSJFTi1V
UyI+U2h1Y2hlbmcgTElVIChXaWxsKSwgUGguRC48bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGk+PHNwYW4gbGFuZz0iRU4tVVMiPlJlc2VhcmNoZXIgJmFt
cDsgU3RhbmRhcmQgUmVwcmVzZW50YXRpdmUgPG86cD4NCjwvbzpwPjwvc3Bhbj48L2k+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGk+PHNwYW4gbGFuZz0iREUiPkh1YXdlaSBUZWNobm9sb2dp
ZXMgQ28uLEx0ZDxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48aT48c3BhbiBsYW5nPSJFTi1VUyI+PGEgaHJlZj0ibWFpbHRvOmxpdXNodWNoZW5nQGh1YXdl
aS5jb20iPjxzcGFuIGxhbmc9IkRFIiBzdHlsZT0iY29sb3I6Ymx1ZSI+bGl1c2h1Y2hlbmdAaHVh
d2VpLmNvbTwvc3Bhbj48L2E+PC9zcGFuPjwvaT48aT48c3BhbiBsYW5nPSJERSI+PG86cD48L286
cD48L3NwYW4+PC9pPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxpPjxzcGFuIGxhbmc9IkVO
LVVTIj48YSBocmVmPSJodHRwOi8vd3d3LmxpbmtlZGluLmNvbS9pbi9zaHVjaGVuZyI+PHNwYW4g
bGFuZz0iREUiIHN0eWxlPSJjb2xvcjpibHVlIj5odHRwOi8vd3d3LmxpbmtlZGluLmNvbS9pbi9z
aHVjaGVuZzwvc3Bhbj48L2E+PC9zcGFuPjwvaT48aT48c3BhbiBsYW5nPSJERSI+PG86cD48L286
cD48L3NwYW4+PC9pPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT
Ij4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_C9B5F12337F6F841B35C404CF0554ACB5FF9998DSZXEMA509MBSchi_--


From nobody Wed Sep 24 07:30:57 2014
Return-Path: 
X-Original-To: supa@ietfa.amsl.com
Delivered-To: supa@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16AC51A01AE for ; Wed, 24 Sep 2014 07:30:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.035
X-Spam-Level: 
X-Spam-Status: No, score=-3.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.786] 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 YoqaPIGp-dwN for ; Wed, 24 Sep 2014 07:30:53 -0700 (PDT)
Received: from mx2.eict.de (mx2.eict.de [212.91.241.168]) by ietfa.amsl.com (Postfix) with ESMTP id E5D591A01A5 for ; Wed, 24 Sep 2014 07:30:52 -0700 (PDT)
Received: by mx2.eict.de (Postfix, from userid 481) id 0A5101FF47; Wed, 24 Sep 2014 16:30:52 +0200 (CEST)
Received: from mail.eict.de (mx1 [172.16.6.1]) by mx2.eict.de (Postfix) with ESMTP id 7FE9E1FF42; Wed, 24 Sep 2014 16:30:50 +0200 (CEST)
Received: from sbs2008.eict.local (sbs2008.intern.eict.de [192.168.2.11]) by mail.eict.de (Postfix) with ESMTP id 30FAB378210; Wed, 24 Sep 2014 16:30:50 +0200 (CEST)
Received: from SBS2008.eict.local ([fe80::2051:ef24:c7c9:f298]) by SBS2008.eict.local ([fe80::2051:ef24:c7c9:f298%13]) with mapi; Wed, 24 Sep 2014 16:30:50 +0200
From: Kostas Pentikousis 
To: "Liushucheng (Will)" , "supa@ietf.org" 
Date: Wed, 24 Sep 2014 16:30:49 +0200
Thread-Topic: [Supa] bof request text
Thread-Index: Ac/YA26gNbLiEu7wSzayawp2LmU/FQAAHy9A
Message-ID: <0C7EDCF89AB9E2478B5D010026CFF4AEA10C72ABF0@SBS2008.eict.local>
References: 
In-Reply-To: 
Accept-Language: en-US, de-DE
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, de-DE
Content-Type: multipart/alternative; boundary="_000_0C7EDCF89AB9E2478B5D010026CFF4AEA10C72ABF0SBS2008eictlo_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/supa/dviSH1x0SNF5s5zrArBZo5r5X3E
Subject: Re: [Supa] bof request text
X-BeenThere: supa@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Sep 2014 14:30:56 -0000

--_000_0C7EDCF89AB9E2478B5D010026CFF4AEA10C72ABF0SBS2008eictlo_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgV2lsbCwgYWxsLA0KDQpHaXZlbiB0aGF0IHRoZSBtZWV0aW5nIGlzIGluIEhhd2FpaSwgcmVt
b3RlIHBhcnRpY2lwYXRpb24gd291bGQgYmUgaGlnaGx5IGRlc2lyYWJsZSBpbW8uIFNvIEkgd291
bGQgc2F5IOKAnHllc+KAnSBmb3Igd2ViZXgvbWVldGVjaG8uDQoNCkJlc3QgcmVnYXJkcywNCg0K
S29zdGFzDQoNClZvbjogTGl1c2h1Y2hlbmcgKFdpbGwpIFttYWlsdG86bGl1c2h1Y2hlbmdAaHVh
d2VpLmNvbV0NCkdlc2VuZGV0OiBNaXR0d29jaCwgMjQuIFNlcHRlbWJlciAyMDE0IDE2OjI1DQpB
bjogc3VwYUBpZXRmLm9yZw0KQmV0cmVmZjogW1N1cGFdIGJvZiByZXF1ZXN0IHRleHQNCg0KSGkg
YWxsLA0KDQpJ4oCZbSBzZW5kaW5nIHlvdSB0aGUgdXBkYXRlZCB2ZXJzaW9uIG9mIGJvZiByZXF1
ZXN0LiBQbGVhc2UgcmV2aWV3IGl0IGFuZCBsZXQgbWUga25vdyB5b3VyIHRob3VnaHQuDQoNCg0K
VGhlIG1haW4gY2hhbmdlcyBhcmU6DQoNCkkgY3V0IHRoZSByZXF1ZXN0IHNob3J0IGJ5IHJlbW92
aW5nIHRoZSAnJ1dvcmsgaXRlbXMgcmVsYXRlZCB0byBTVVBBIGluY2x1ZGU6JycgYW5kICcnTWls
ZXN0b25lczonJywgd2hpY2ggYXJlIHVzdWFsbHkgbm90IHB1dCBpbiB0aGUgcmVxdWVzdC4gKFF1
ZXN0aW9uOiBzaG91bGQgSSByZW1vdmUgdGhlbT8pDQoNCkkgdXBkYXRlZCB0aGUgbGlua3MgYW5k
IHRoZSByZXNwb25zaWJsZSBBRCwgYW5kIG1ha2UgdGhlIGZvcm1hdCBuZWF0Lg0KDQoNCg0KU1VQ
QQ0KDQogKiAgIExvbmcgbmFtZSBhbmQgYWJicmV2aWF0aW9uOiBTVVBBIChTaGFyZWQgVW5pZmll
ZCBQb2xpY3kgQXV0b21hdGlvbikNCiAqICAgRGVzY3JpcHRpb246IE5ldHdvcmsgb3BlcmF0b3Jz
IGFyZSBmYWNlZCB3aXRoIG5ldHdvcmtzIG9mIGluY3JlYXNpbmcgc2l6ZSBhbmQgY29tcGxleGl0
eSB3aGlsZSB0cnlpbmcgdG8gaW1wcm92ZSB0aGVpciBxdWFsaXR5IGFuZCBhdmFpbGFiaWxpdHks
IGFzIG1vcmUgYW5kIG1vcmUgc2VydmljZXMgZGVwZW5kIG9uIHRoZW0uIEF1dG9tYXRpbmcgdGhl
IHdheSBvZiBleHBvc2luZyBhIHZpZXcgb2YgdGhlIG5ldHdvcmsgdG8gYXBwbGljYXRpb25zIG1h
eSBwcm92aWRlIHNpZ25pZmljYW50IGltcHJvdmVtZW50cyBpbiBjb25maWd1cmF0aW9uIGFnaWxp
dHksIGVycm9yIGRldGVjdGlvbiBhbmQgdXB0aW1lIGZvciBvcGVyYXRvcnMuIEhvd2V2ZXIgdGhl
IHJlYWwgdmFsdWUgYmVoaW5kIGNlbnRyYWwgY29uZmlndXJhdGlvbiBzY2hlbWVzIGxpZXMgd2l0
aGluIHRoZSBwb3NzaWJsZSBzaW1wbGlmaWNhdGlvbiB0aHJvdWdoIG1vZGVscyBwcm92aWRlZCBi
eSBzdWNoIHN5c3RlbXMgdG8gYXBwbGljYXRpb25zIGFuZCBuZXR3b3JrIHNlcnZpY2VzIHJ1bm5p
bmcgYWJvdmUgdGhlbSAob24gdGhlIHNvLWNhbGxlZCBub3J0aGJvdW5kIHNpZGUpLiBXZWxsLWRl
c2lnbmVkIG1vZGVscyBhcmUgYWJsZSB0byBwcm92aWRlIGEgd2lkZSByYW5nZSBvZiBncmFudWxh
cml0eSBmb3IgdmFyaW91cyBhcHBsaWNhdGlvbnMgYW5kIG5ldHdvcmsgc2VydmljZXMgbmVlZHMs
IGZyb20gdGhlIGxvd2VyLWxldmVsIHBoeXNpY2FsIG5ldHdvcmsgdG8gaGlnaC1sZXZlbCBhcHBs
aWNhdGlvbiBzZXJ2aWNlcy4NCg0KUGxlYXNlIG5vdGUgdGhhdCB0aGlzIGlzIGEgbmV3IHZlcnNp
b24gb2YgYXBvbmYgYm9mIHByb3Bvc2FsIGJhc2VkIG9uIGNvbW1lbnRzIHJlY2VpdmVkLg0KDQpU
aGUgbWFpbiBnb2FsIG9mIFNVUEEgaXMgdG8gcHJvdmlkZSBhIHdheSBmb3IgYXBwbGljYXRpb25z
IGFuZCBmb3IgbmV0d29yayBzZXJ2aWNlcyB0byBzcGVjaWZ5IFNIQVJFRCBhcHBsaWNhdGlvbiBi
YXNlZCBQT0xJQ0lFUyB0byB0aGUgbmV0d29yayBpbmZyYXN0cnVjdHVyZSB1c2luZyBhIHNpbXBs
aWZpZWQgdmlldyBvZiB0aGUgbmV0d29yay4gVGhpcyBjYW4gYmUgcmVhbGl6ZWQgYnk6ICgxKSBt
b2RlbGluZyB0aGUgbmV0d29yayBpbmZyYXN0cnVjdHVyZSBhcyBhbiBzaW1wbGlmaWVkIG5ldHdv
cmsgZ3JhcGggdXNpbmcgYSBtb2RlbGluZyBsYW5ndWFnZSBzdWNoIGFzIFlBTkcsICgyKSB0cmFu
c3BvcnRpbmcgbW9kZWwgaW5zdGFuY2VzIGVpdGhlciB1c2luZyBORVRDT05GIG9yIFJFU1RDT05G
IGFuZCAoMykgcHJvdmlkaW5nIGd1aWRlbGluZXMgb24gQVVUT01BVElDQUxMWSBtYXBwaW5nIHBv
bGljaWVzIHRvIGF0dHJpYnV0ZXMgb2YgdGhlIG5ldHdvcmsgZ3JhcGhzLg0KDQogKiAgIEFnZW5k
YTogVEJEDQogKiAgIFN0YXR1czogV0cgRm9ybWluZw0KICogICBSZXNwb25zaWJsZSBBRDogQmVu
b2l0IENsYWlzZQ0KICogICBCb0YgcHJvcG9uZW50czogVEJEDQogKiAgIEJvRiBDaGFpcnM6IFRC
RA0KICogICBOdW1iZXIgb2YgcGVvcGxlIGV4cGVjdGVkIHRvIGF0dGVuZDogMTAwDQogKiAgIExl
bmd0aCBvZiBzZXNzaW9uICgxLCAxLjUsIDIsIG9yIDIuNSBob3Vycyk6IDEuNSBob3Vycw0KICog
ICBDb25mbGljdHMgdG8gYXZvaWQgKHdob2xlIEFyZWFzIGFuZC9vciBXR3MpOg0KICogICBEb2Vz
IGl0IHJlcXVpcmUgV2ViRVg/IElmIHNvLCB3aHk/OiBubw0KICogICBEb2VzIGl0IHJlcXVpcmUg
TWVldGVjaG8/IElmIHNvLCB3aHk/OiBubw0KICogICBMaW5rcyB0byB0aGUgbWFpbGluZyBsaXN0
LCBkcmFmdCBjaGFydGVyIGlmIGFueSwgcmVsZXZhbnQgSW50ZXJuZXQtRHJhZnRzLCBldGMuDQoN
CiAgICAqICAgQm9GIEluZm8gUGFnZTog4oCLaHR0cDovL2xpdXNodWNoZW5nLmdpdGh1Yi5pby9T
VVBBLzxodHRwOi8vbGl1c2h1Y2hlbmcuZ2l0aHViLmlvL1NVUEEvPg0KICAgICogICBNYWlsaW5n
IGxpc3QgYW5kIGluZm8gcGFnZTog4oCLc3VwYUBpZXRmLm9yZzxtYWlsdG86c3VwYUBpZXRmLm9y
Zz47IOKAi2h0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3VwYTxodHRwczov
L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N1cGE+Ow0KICAgICogICBEcmFmdCBjaGFy
dGVyOiDigItodHRwczovL2dpdGh1Yi5jb20vbGl1c2h1Y2hlbmcvU1VQQS93aWtpL1NVUEEtQ2hh
cnRlcjxodHRwczovL2dpdGh1Yi5jb20vbGl1c2h1Y2hlbmcvU1VQQS93aWtpL1NVUEEtQ2hhcnRl
cj4gO+KAi2h0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9zdXBhL2N1cnJlbnQv
bXNnMDAwNTEuaHRtbDxodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvc3VwYS9j
dXJyZW50L21zZzAwMDUxLmh0bWw+DQogICAgKiAgIFJlbGV2YW50IGRyYWZ0czoNCg0KICAgICAg
ICogICBkcmFmdC1rYXJhZ2lhbm5pcy1zdXBhLXByb2JsZW0tc3RhdGVtZW50PGh0dHA6Ly90b29s
cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWthcmFnaWFubmlzLXN1cGEtcHJvYmxlbS1zdGF0ZW1lbnQ+
DQogICAgICAgKiAgIGRyYWZ0LWNoZW5nLXN1cGEtZGRjLXVzZS1jYXNlczxodHRwOi8vdG9vbHMu
aWV0Zi5vcmcvaHRtbC9kcmFmdC1jaGVuZy1zdXBhLWRkYy11c2UtY2FzZXM+DQogICAgICAgKiAg
IGRyYWZ0LXBlbnRpa291c2lzLXN1cGEtbWFwcGluZzxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt
bC9kcmFmdC1wZW50aWtvdXNpcy1zdXBhLW1hcHBpbmc+DQogICAgICAgKiAgIGRyYWZ0LWNvbnRy
ZXJhcy1zdXBhLXlhbmctbmV0d29yay10b3BvPGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry
YWZ0LWNvbnRyZXJhcy1zdXBhLXlhbmctbmV0d29yay10b3BvPg0KICAgICAgICogICBkcmFmdC16
YWFsb3VrLXN1cGEtY29uZmlndXJhdGlvbi1tb2RlbDxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt
bC9kcmFmdC16YWFsb3VrLXN1cGEtY29uZmlndXJhdGlvbi1tb2RlbD4NCg0KDQpSZWdhcmRzLA0K
U2h1Y2hlbmcgTElVIChXaWxsKQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClNodWNoZW5n
IExJVSAoV2lsbCksIFBoLkQuDQpSZXNlYXJjaGVyICYgU3RhbmRhcmQgUmVwcmVzZW50YXRpdmUN
Ckh1YXdlaSBUZWNobm9sb2dpZXMgQ28uLEx0ZA0KbGl1c2h1Y2hlbmdAaHVhd2VpLmNvbTxtYWls
dG86bGl1c2h1Y2hlbmdAaHVhd2VpLmNvbT4NCmh0dHA6Ly93d3cubGlua2VkaW4uY29tL2luL3No
dWNoZW5nDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQo=

--_000_0C7EDCF89AB9E2478B5D010026CFF4AEA10C72ABF0SBS2008eictlo_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu
dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50
PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv
bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K
CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls
eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250
LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAz
IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDEx
IDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0K
CXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p
bHk65a6L5L2TO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk66buY6K6k5a2X5L2TO30NCi8q
IFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNv
Tm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCXRleHQtYWxp
Z246anVzdGlmeTsNCglmb250LXNpemU6MTAuNXB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi
c2Fucy1zZXJpZiI7fQ0KaDQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk7DQoJbXNvLXN0eWxlLWxp
bms6IsOcYmVyc2NocmlmdCA0IFpjaG4iOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1h
cmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxl
ZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk65a6L5L2TOw0KCWZvbnQt
d2VpZ2h0OmJvbGQ7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJp
b3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N
CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp
dHk6OTk7DQoJY29sb3I6Izk1NEY3MjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAu
TXNvUGxhaW5UZXh0LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRleHQNCgl7bXNvLXN0
eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJOdXIgVGV4dCBaY2huIjsNCgltYXJn
aW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuNXB0Ow0KCWZv
bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3Jp
dHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCglt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXpl
OjEyLjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0Kc3Bhbi5iZXJzY2hyaWZ0NFpjaG4NCgl7
bXNvLXN0eWxlLW5hbWU6IsOcYmVyc2NocmlmdCA0IFpjaG4iOw0KCW1zby1zdHlsZS1wcmlvcml0
eTo5Ow0KCW1zby1zdHlsZS1saW5rOiLDnGJlcnNjaHJpZnQgNCI7DQoJZm9udC1mYW1pbHk6IkNh
bWJyaWEiLCJzZXJpZiI7DQoJY29sb3I6IzRGODFCRDsNCglmb250LXdlaWdodDpib2xkOw0KCWZv
bnQtc3R5bGU6aXRhbGljO30NCnNwYW4uTnVyVGV4dFpjaG4NCgl7bXNvLXN0eWxlLW5hbWU6Ik51
ciBUZXh0IFpjaG4iOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi
TnVyIFRleHQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uRS1NYWlsRm9ybWF0dm9y
bGFnZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp
Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6d2luZG93dGV4dDt9DQpwLjQsIGxpLjQsIGRpdi40DQoJ
e21zby1zdHlsZS1uYW1lOiLmoIfpopggNCI7DQoJbXNvLXN0eWxlLWxpbms6Iuagh+mimCA0IENo
YXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCXRleHQtYWxpZ246
anVzdGlmeTsNCglmb250LXNpemU6MTAuNXB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu
cy1zZXJpZiI7fQ0Kc3Bhbi40Q2hhcg0KCXttc28tc3R5bGUtbmFtZToi5qCH6aKYIDQgQ2hhciI7
DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk7DQoJbXNvLXN0eWxlLWxpbms6Iuagh+mimCA0IjsNCglm
b250LWZhbWlseTrlrovkvZM7DQoJZm9udC13ZWlnaHQ6Ym9sZDt9DQpwLmEsIGxpLmEsIGRpdi5h
DQoJe21zby1zdHlsZS1uYW1lOue6r+aWh+acrDsNCgltc28tc3R5bGUtbGluazoi57qv5paH5pys
IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCXRleHQtYWxp
Z246anVzdGlmeTsNCglmb250LXNpemU6MTAuNXB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi
c2Fucy1zZXJpZiI7fQ0Kc3Bhbi5DaGFyDQoJe21zby1zdHlsZS1uYW1lOiLnuq/mlofmnKwgQ2hh
ciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOue6r+aWh+acrDsN
Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCnNwYW4uYXBwbGUtY29udmVy
dGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFu
Lmljb24NCgl7bXNvLXN0eWxlLW5hbWU6aWNvbjt9DQpzcGFuLkUtTWFpbEZvcm1hdHZvcmxhZ2Uy
OA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJy
aSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv
LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3Jk
U2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQg
NzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N
Ci8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjc1OTEwODk5
MTsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTExNjQ4MjY5NzQ7fQ0KQGxpc3QgbDA6bGV2ZWwx
DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7
DQoJbXNvLWxldmVsLXRhYi1zdG9wOjM2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u
OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0
Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDoxMjA0NjM2
Mzc5Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotNzkxODgyMzk4O30NCkBsaXN0IGwxOmxldmVs
MQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3
Ow0KCW1zby1sZXZlbC10YWItc3RvcDozNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv
bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw
dDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1u
dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWIt
c3RvcDo3Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k
ZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToi
Q291cmllciBOZXciOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30N
CkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv
LWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxMDguMHB0Ow0KCW1zby1sZXZl
bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNp
LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdp
bi1ib3R0b206MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+PCEt
LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk
bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+
DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0
YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkg
bGFuZz1ERSBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiIgc3R5bGU9J3RleHQtanVzdGlm
eS10cmltOnB1bmN0dWF0aW9uJz48ZGl2IGNsYXNzPVdvcmRTZWN0aW9uMT48cCBjbGFzcz1Nc29O
b3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0
OTdEJz5IaSBXaWxsLCBhbGwsPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h
bD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0Qn
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFu
Zz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEJz5HaXZlbiB0aGF0
IHRoZSBtZWV0aW5nIGlzIGluIEhhd2FpaSwgcmVtb3RlIHBhcnRpY2lwYXRpb24gd291bGQgYmUg
aGlnaGx5IGRlc2lyYWJsZSBpbW8uIFNvIEkgd291bGQgc2F5IOKAnHllc+KAnSBmb3Igd2ViZXgv
bWVldGVjaG8uPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBs
YW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBhbGlnbj1sZWZ0IHN0
eWxlPSd0ZXh0LWFsaWduOmxlZnQnPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZTox
MS4wcHQ7Y29sb3I6IzFGNDk3RCc+QmVzdCByZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48
cCBjbGFzcz1Nc29Ob3JtYWwgYWxpZ249bGVmdCBzdHlsZT0ndGV4dC1hbGlnbjpsZWZ0Jz48c3Bh
biBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QnPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgYWxpZ249bGVmdCBzdHls
ZT0ndGV4dC1hbGlnbjpsZWZ0Jz48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEu
MHB0O2NvbG9yOiMxRjQ5N0QnPktvc3RhczxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48cCBj
bGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtj
b2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRpdiBzdHlsZT0nYm9y
ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNt
IDQuMHB0Jz48ZGl2PjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1
QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtJz48cCBjbGFzcz1Nc29Ob3JtYWwg
YWxpZ249bGVmdCBzdHlsZT0ndGV4dC1hbGlnbjpsZWZ0Jz48Yj48c3BhbiBzdHlsZT0nZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPlZvbjo8L3NwYW4+
PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJz
YW5zLXNlcmlmIic+IExpdXNodWNoZW5nIChXaWxsKSBbbWFpbHRvOmxpdXNodWNoZW5nQGh1YXdl
aS5jb21dIDxicj48Yj5HZXNlbmRldDo8L2I+IE1pdHR3b2NoLCAyNC4gU2VwdGVtYmVyIDIwMTQg
MTY6MjU8YnI+PGI+QW46PC9iPiBzdXBhQGlldGYub3JnPGJyPjxiPkJldHJlZmY6PC9iPiBbU3Vw
YV0gYm9mIHJlcXVlc3QgdGV4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48cCBj
bGFzcz1Nc29Ob3JtYWwgYWxpZ249bGVmdCBzdHlsZT0ndGV4dC1hbGlnbjpsZWZ0Jz48bzpwPiZu
YnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUz5IaSBhbGws
PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVT
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFu
Zz1FTi1VUz5J4oCZbSBzZW5kaW5nIHlvdSB0aGUgdXBkYXRlZCB2ZXJzaW9uIG9mIGJvZiByZXF1
ZXN0LiBQbGVhc2UgcmV2aWV3IGl0IGFuZCBsZXQgbWUga25vdyB5b3VyIHRob3VnaHQuPG86cD48
L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gbGFuZz1F
Ti1VUz5UaGUgbWFpbiBjaGFuZ2VzIGFyZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9
TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVM+SSBjdXQgdGhlIHJlcXVlc3Qgc2hvcnQgYnkg
cmVtb3ZpbmcgdGhlICcnV29yayBpdGVtcyByZWxhdGVkIHRvIFNVUEEgaW5jbHVkZTonJyBhbmQg
JydNaWxlc3RvbmVzOicnLCB3aGljaCBhcmUgdXN1YWxseSBub3QgcHV0IGluIHRoZSByZXF1ZXN0
LiAoUXVlc3Rpb246IHNob3VsZCBJIHJlbW92ZSB0aGVtPyk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+
PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIGxhbmc9RU4tVVM+SSB1cGRhdGVkIHRoZSBsaW5r
cyBhbmQgdGhlIHJlc3BvbnNpYmxlIEFELCBhbmQgbWFrZSB0aGUgZm9ybWF0IG5lYXQuPG86cD48
L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBsYW5nPUVOLVVTPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48aDQgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDo1
LjRwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206MGNtO21hcmdpbi1sZWZ0OjBjbTtt
YXJnaW4tYm90dG9tOi4wMDAxcHQ7cGFnZS1icmVhay1hZnRlcjphdm9pZDtiYWNrZ3JvdW5kOndo
aXRlJz48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
Oum7mOiupOWtl+S9kztjb2xvcjpibGFjayc+U1VQQTxvOnA+PC9vOnA+PC9zcGFuPjwvaDQ+PHVs
IHR5cGU9ZGlzYz48bGkgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdjb2xvcjpibGFjazttc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOmxl
ZnQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzE7YmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gbGFuZz1F
Ti1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTrpu5jorqTlrZfkvZMnPkxv
bmcgbmFtZSBhbmQgYWJicmV2aWF0aW9uOiBTVVBBIChTaGFyZWQgVW5pZmllZCBQb2xpY3kgQXV0
b21hdGlvbik8bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9
J2NvbG9yOmJsYWNrO21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvO3RleHQtYWxpZ246bGVmdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMTtiYWNrZ3JvdW5k
OndoaXRlJz48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5Oum7mOiupOWtl+S9kyc+RGVzY3JpcHRpb246IE5ldHdvcmsgb3BlcmF0b3JzIGFyZSBmYWNl
ZCB3aXRoIG5ldHdvcmtzIG9mIGluY3JlYXNpbmcgc2l6ZSBhbmQgY29tcGxleGl0eSB3aGlsZSB0
cnlpbmcgdG8gaW1wcm92ZSB0aGVpciBxdWFsaXR5IGFuZCBhdmFpbGFiaWxpdHksIGFzIG1vcmUg
YW5kIG1vcmUgc2VydmljZXMgZGVwZW5kIG9uIHRoZW0uIEF1dG9tYXRpbmcgdGhlIHdheSBvZiBl
eHBvc2luZyBhIHZpZXcgb2YgdGhlIG5ldHdvcmsgdG8gYXBwbGljYXRpb25zIG1heSBwcm92aWRl
IHNpZ25pZmljYW50IGltcHJvdmVtZW50cyBpbiBjb25maWd1cmF0aW9uIGFnaWxpdHksIGVycm9y
IGRldGVjdGlvbiBhbmQgdXB0aW1lIGZvciBvcGVyYXRvcnMuIEhvd2V2ZXIgdGhlIHJlYWwgdmFs
dWUgYmVoaW5kIGNlbnRyYWwgY29uZmlndXJhdGlvbiBzY2hlbWVzIGxpZXMgd2l0aGluIHRoZSBw
b3NzaWJsZSBzaW1wbGlmaWNhdGlvbiB0aHJvdWdoIG1vZGVscyBwcm92aWRlZCBieSBzdWNoIHN5
c3RlbXMgdG8gYXBwbGljYXRpb25zIGFuZCBuZXR3b3JrIHNlcnZpY2VzIHJ1bm5pbmcgYWJvdmUg
dGhlbSAob24gdGhlIHNvLWNhbGxlZCBub3J0aGJvdW5kIHNpZGUpLiBXZWxsLWRlc2lnbmVkIG1v
ZGVscyBhcmUgYWJsZSB0byBwcm92aWRlIGEgd2lkZSByYW5nZSBvZiBncmFudWxhcml0eSBmb3Ig
dmFyaW91cyBhcHBsaWNhdGlvbnMgYW5kIG5ldHdvcmsgc2VydmljZXMgbmVlZHMsIGZyb20gdGhl
IGxvd2VyLWxldmVsIHBoeXNpY2FsIG5ldHdvcmsgdG8gaGlnaC1sZXZlbCBhcHBsaWNhdGlvbiBz
ZXJ2aWNlcy48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvdWw+PHAgc3R5bGU9J21hcmdpbi1sZWZ0
OjIxLjBwdDttc28tcGFyYS1tYXJnaW4tbGVmdDoyLjBnZDtiYWNrZ3JvdW5kOndoaXRlJz48c3Bh
biBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5Oum7mOiupOWt
l+S9kztjb2xvcjpibGFjayc+UGxlYXNlIG5vdGUgdGhhdCB0aGlzIGlzIGEgbmV3IHZlcnNpb24g
b2YgYXBvbmYgYm9mIHByb3Bvc2FsIGJhc2VkIG9uIGNvbW1lbnRzIHJlY2VpdmVkLjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD48cCBzdHlsZT0nbWFyZ2luLWxlZnQ6MjEuMHB0O21zby1wYXJhLW1hcmdp
bi1sZWZ0OjIuMGdkO2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2Zv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk66buY6K6k5a2X5L2TO2NvbG9yOmJsYWNrJz5UaGUg
bWFpbiBnb2FsIG9mIFNVUEEgaXMgdG8gcHJvdmlkZSBhIHdheSBmb3IgYXBwbGljYXRpb25zIGFu
ZCBmb3IgbmV0d29yayBzZXJ2aWNlcyB0byBzcGVjaWZ5IFNIQVJFRCBhcHBsaWNhdGlvbiBiYXNl
ZCBQT0xJQ0lFUyB0byB0aGUgbmV0d29yayBpbmZyYXN0cnVjdHVyZSB1c2luZyBhIHNpbXBsaWZp
ZWQgdmlldyBvZiB0aGUgbmV0d29yay4gVGhpcyBjYW4gYmUgcmVhbGl6ZWQgYnk6ICgxKSBtb2Rl
bGluZyB0aGUgbmV0d29yayBpbmZyYXN0cnVjdHVyZSBhcyBhbiBzaW1wbGlmaWVkIG5ldHdvcmsg
Z3JhcGggdXNpbmcgYSBtb2RlbGluZyBsYW5ndWFnZSBzdWNoIGFzIFlBTkcsICgyKSB0cmFuc3Bv
cnRpbmcgbW9kZWwgaW5zdGFuY2VzIGVpdGhlciB1c2luZyBORVRDT05GIG9yIFJFU1RDT05GIGFu
ZCAoMykgcHJvdmlkaW5nIGd1aWRlbGluZXMgb24gQVVUT01BVElDQUxMWSBtYXBwaW5nIHBvbGlj
aWVzIHRvIGF0dHJpYnV0ZXMgb2YgdGhlIG5ldHdvcmsgZ3JhcGhzLjxvOnA+PC9vOnA+PC9zcGFu
PjwvcD48dWwgdHlwZT1kaXNjPjxsaSBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2NvbG9yOmJsYWNr
O21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQt
YWxpZ246bGVmdDttc28tbGlzdDpsMSBsZXZlbDEgbGZvMjtiYWNrZ3JvdW5kOndoaXRlJz48c3Bh
biBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5Oum7mOiupOWt
l+S9kyc+QWdlbmRhOiBUQkQ8bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz1Nc29Ob3Jt
YWwgc3R5bGU9J2NvbG9yOmJsYWNrO21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvO3RleHQtYWxpZ246bGVmdDttc28tbGlzdDpsMSBsZXZlbDEgbGZvMjti
YWNrZ3JvdW5kOndoaXRlJz48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5Oum7mOiupOWtl+S9kyc+U3RhdHVzOiBXRyBGb3JtaW5nPG86cD48L286cD48
L3NwYW4+PC9saT48bGkgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdjb2xvcjpibGFjazttc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOmxl
ZnQ7bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzI7YmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gbGFuZz1F
Ti1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTrpu5jorqTlrZfkvZMnPlJl
c3BvbnNpYmxlIEFEOiBCZW5vaXQgQ2xhaXNlPG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xh
c3M9TXNvTm9ybWFsIHN0eWxlPSdjb2xvcjpibGFjazttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOmxlZnQ7bXNvLWxpc3Q6bDEgbGV2
ZWwxIGxmbzI7YmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTrpu5jorqTlrZfkvZMnPkJvRiBwcm9wb25lbnRzOiBUQkQ8
bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2NvbG9yOmJs
YWNrO21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3Rl
eHQtYWxpZ246bGVmdDttc28tbGlzdDpsMSBsZXZlbDEgbGZvMjtiYWNrZ3JvdW5kOndoaXRlJz48
c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5Oum7mOiu
pOWtl+S9kyc+Qm9GIENoYWlyczogVEJEPG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9
TXNvTm9ybWFsIHN0eWxlPSdjb2xvcjpibGFjazttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOmxlZnQ7bXNvLWxpc3Q6bDEgbGV2ZWwx
IGxmbzI7YmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTrpu5jorqTlrZfkvZMnPk51bWJlciBvZiBwZW9wbGUgZXhwZWN0
ZWQgdG8gYXR0ZW5kOiAxMDA8bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz1Nc29Ob3Jt
YWwgc3R5bGU9J2NvbG9yOmJsYWNrO21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvO3RleHQtYWxpZ246bGVmdDttc28tbGlzdDpsMSBsZXZlbDEgbGZvMjti
YWNrZ3JvdW5kOndoaXRlJz48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5Oum7mOiupOWtl+S9kyc+TGVuZ3RoIG9mIHNlc3Npb24gKDEsIDEuNSwgMiwg
b3IgMi41IGhvdXJzKTogMS41IGhvdXJzPG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9
TXNvTm9ybWFsIHN0eWxlPSdjb2xvcjpibGFjazttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOmxlZnQ7bXNvLWxpc3Q6bDEgbGV2ZWwx
IGxmbzI7YmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTrpu5jorqTlrZfkvZMnPkNvbmZsaWN0cyB0byBhdm9pZCAod2hv
bGUgQXJlYXMgYW5kL29yIFdHcyk6PG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9TXNv
Tm9ybWFsIHN0eWxlPSdjb2xvcjpibGFjazttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOmxlZnQ7bXNvLWxpc3Q6bDEgbGV2ZWwxIGxm
bzI7YmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTrpu5jorqTlrZfkvZMnPkRvZXMgaXQgcmVxdWlyZSBXZWJFWD8gSWYg
c28sIHdoeT86IG5vPG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9TXNvTm9ybWFsIHN0
eWxlPSdjb2xvcjpibGFjazttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0bzt0ZXh0LWFsaWduOmxlZnQ7bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzI7YmFja2dy
b3VuZDp3aGl0ZSc+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTrpu5jorqTlrZfkvZMnPkRvZXMgaXQgcmVxdWlyZSBNZWV0ZWNobz8gSWYgc28sIHdo
eT86IG5vPG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdj
b2xvcjpibGFjazttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0bzt0ZXh0LWFsaWduOmxlZnQ7bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzI7YmFja2dyb3VuZDp3
aGl0ZSc+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTrpu5jorqTlrZfkvZMnPkxpbmtzIHRvIHRoZSBtYWlsaW5nIGxpc3QsIGRyYWZ0IGNoYXJ0ZXIg
aWYgYW55LCByZWxldmFudCBJbnRlcm5ldC1EcmFmdHMsIGV0Yy48L3NwYW4+PHNwYW4gbGFuZz1F
Ti1VUz4gPC9zcGFuPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk66buY6K6k5a2X5L2TJz48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvdWw+PHVsIHR5
cGU9ZGlzYz48dWwgdHlwZT1jaXJjbGU+PGxpIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nY29sb3I6
YmxhY2s7bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87
dGV4dC1hbGlnbjpsZWZ0O21zby1saXN0OmwxIGxldmVsMiBsZm8yO2JhY2tncm91bmQ6d2hpdGUn
PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk66buY
6K6k5a2X5L2TJz5Cb0YgSW5mbyBQYWdlOjxzcGFuIGNsYXNzPWFwcGxlLWNvbnZlcnRlZC1zcGFj
ZT4mbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cDovL2xpdXNodWNoZW5nLmdpdGh1Yi5pby9TVVBB
LyI+PHNwYW4gY2xhc3M9aWNvbj48c3BhbiBzdHlsZT0nY29sb3I6IzQ0MDA4OCc+4oCLPC9zcGFu
Pjwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6IzQ0MDA4OCc+aHR0cDovL2xpdXNodWNoZW5nLmdp
dGh1Yi5pby9TVVBBLzwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9
TXNvTm9ybWFsIHN0eWxlPSdjb2xvcjpibGFjazttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOmxlZnQ7bXNvLWxpc3Q6bDEgbGV2ZWwy
IGxmbzI7YmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTrpu5jorqTlrZfkvZMnPk1haWxpbmcgbGlzdCBhbmQgaW5mbyBw
YWdlOjxzcGFuIGNsYXNzPWFwcGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L3NwYW4+PGEgaHJl
Zj0ibWFpbHRvOnN1cGFAaWV0Zi5vcmciPjxzcGFuIGNsYXNzPWljb24+PHNwYW4gc3R5bGU9J2Nv
bG9yOiM0NDAwODgnPuKAizwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOiM0NDAwODgn
PnN1cGFAaWV0Zi5vcmc8L3NwYW4+PC9hPjs8c3BhbiBjbGFzcz1hcHBsZS1jb252ZXJ0ZWQtc3Bh
Y2U+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz
dGluZm8vc3VwYSI+PHNwYW4gY2xhc3M9aWNvbj48c3BhbiBzdHlsZT0nY29sb3I6IzQ0MDA4OCc+
4oCLPC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6IzQ0MDA4OCc+aHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdXBhPC9zcGFuPjwvYT47PG86cD48L286cD48L3Nw
YW4+PC9saT48bGkgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdjb2xvcjpibGFjazttc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOmxlZnQ7
bXNvLWxpc3Q6bDEgbGV2ZWwyIGxmbzI7YmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2Zv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk66buY6K6k5a2X5L2TJz5EcmFmdCBjaGFydGVyOjxz
cGFuIGNsYXNzPWFwcGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFu
IGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk66buY6K6k5a2X
5L2TJz48YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vbGl1c2h1Y2hlbmcvU1VQQS93aWtpL1NV
UEEtQ2hhcnRlciI+PHNwYW4gY2xhc3M9aWNvbj48c3BhbiBsYW5nPURFIHN0eWxlPSdjb2xvcjoj
NDQwMDg4Jz7igIs8L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9REUgc3R5bGU9J2NvbG9yOiM0NDAw
ODgnPmh0dHBzOi8vZ2l0aHViLmNvbS9saXVzaHVjaGVuZy9TVVBBL3dpa2kvU1VQQS1DaGFydGVy
PC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gY2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPjxzcGFu
IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5Oum7mOiupOWtl+S9kyc+Jm5ic3A7
PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTrp
u5jorqTlrZfkvZMnPjs8L3NwYW4+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTrpu5jorqTlrZfkvZMnPjxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5v
cmcvbWFpbC1hcmNoaXZlL3dlYi9zdXBhL2N1cnJlbnQvbXNnMDAwNTEuaHRtbCI+PHNwYW4gY2xh
c3M9aWNvbj48c3BhbiBsYW5nPURFIHN0eWxlPSdjb2xvcjojNDQwMDg4Jz7igIs8L3NwYW4+PC9z
cGFuPjxzcGFuIGxhbmc9REUgc3R5bGU9J2NvbG9yOiM0NDAwODgnPmh0dHA6Ly93d3cuaWV0Zi5v
cmcvbWFpbC1hcmNoaXZlL3dlYi9zdXBhL2N1cnJlbnQvbXNnMDAwNTEuaHRtbDwvc3Bhbj48L2E+
PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5Oum7mOiupOWt
l+S9kyc+PG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdj
b2xvcjpibGFjazttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0bzt0ZXh0LWFsaWduOmxlZnQ7bXNvLWxpc3Q6bDEgbGV2ZWwyIGxmbzI7YmFja2dyb3VuZDp3
aGl0ZSc+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTrpu5jorqTlrZfkvZMnPlJlbGV2YW50IGRyYWZ0czo8L3NwYW4+PHNwYW4gbGFuZz1FTi1VUz4g
PC9zcGFuPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk66buY6K6k5a2X5L2TJz48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvdWw+PC91bD48dWwgdHlw
ZT1kaXNjPjx1bCB0eXBlPWNpcmNsZT48dWwgdHlwZT1zcXVhcmU+PGxpIGNsYXNzPU1zb05vcm1h
bCBzdHlsZT0nY29sb3I6YmxhY2s7bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i
b3R0b20tYWx0OmF1dG87dGV4dC1hbGlnbjpsZWZ0O21zby1saXN0OmwxIGxldmVsMyBsZm8yO2Jh
Y2tncm91bmQ6d2hpdGUnPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk66buY6K6k5a2X5L2TJz48YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcv
aHRtbC9kcmFmdC1rYXJhZ2lhbm5pcy1zdXBhLXByb2JsZW0tc3RhdGVtZW50Ij48c3BhbiBzdHls
ZT0nY29sb3I6IzQ0MDA4OCc+ZHJhZnQta2FyYWdpYW5uaXMtc3VwYS1wcm9ibGVtLXN0YXRlbWVu
dDwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9TXNvTm9ybWFsIHN0
eWxlPSdjb2xvcjpibGFjazttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0bzt0ZXh0LWFsaWduOmxlZnQ7bXNvLWxpc3Q6bDEgbGV2ZWwzIGxmbzI7YmFja2dy
b3VuZDp3aGl0ZSc+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTrpu5jorqTlrZfkvZMnPjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s
L2RyYWZ0LWNoZW5nLXN1cGEtZGRjLXVzZS1jYXNlcyI+PHNwYW4gc3R5bGU9J2NvbG9yOiM0NDAw
ODgnPmRyYWZ0LWNoZW5nLXN1cGEtZGRjLXVzZS1jYXNlczwvc3Bhbj48L2E+PG86cD48L286cD48
L3NwYW4+PC9saT48bGkgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdjb2xvcjpibGFjazttc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOmxl
ZnQ7bXNvLWxpc3Q6bDEgbGV2ZWwzIGxmbzI7YmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gbGFuZz1F
Ti1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTrpu5jorqTlrZfkvZMnPjxh
IGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXBlbnRpa291c2lzLXN1cGEt
bWFwcGluZyI+PHNwYW4gc3R5bGU9J2NvbG9yOiM0NDAwODgnPmRyYWZ0LXBlbnRpa291c2lzLXN1
cGEtbWFwcGluZzwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9TXNv
Tm9ybWFsIHN0eWxlPSdjb2xvcjpibGFjazttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOmxlZnQ7bXNvLWxpc3Q6bDEgbGV2ZWwzIGxm
bzI7YmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTrpu5jorqTlrZfkvZMnPjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRm
Lm9yZy9odG1sL2RyYWZ0LWNvbnRyZXJhcy1zdXBhLXlhbmctbmV0d29yay10b3BvIj48c3BhbiBz
dHlsZT0nY29sb3I6IzQ0MDA4OCc+ZHJhZnQtY29udHJlcmFzLXN1cGEteWFuZy1uZXR3b3JrLXRv
cG88L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPU1zb05vcm1hbCBz
dHlsZT0nY29sb3I6YmxhY2s7bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG87dGV4dC1hbGlnbjpsZWZ0O21zby1saXN0OmwxIGxldmVsMyBsZm8yO2JhY2tn
cm91bmQ6d2hpdGUnPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk66buY6K6k5a2X5L2TJz48YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt
bC9kcmFmdC16YWFsb3VrLXN1cGEtY29uZmlndXJhdGlvbi1tb2RlbCI+PHNwYW4gc3R5bGU9J2Nv
bG9yOiM0NDAwODgnPmRyYWZ0LXphYWxvdWstc3VwYS1jb25maWd1cmF0aW9uLW1vZGVsPC9zcGFu
PjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvdWw+PC91bD48L3VsPjxwIGNsYXNzPU1zb05v
cm1hbD48c3BhbiBsYW5nPUVOLVVTPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz
cz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+
PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVM+UmVnYXJkcyw8L3NwYW4+PHNwYW4g
bGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdCc+PG86cD48L286cD48L3NwYW4+PC9w
PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTPlNodWNoZW5nIExJVSAoV2lsbCk8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVM+
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9
TXNvTm9ybWFsPjxpPjxzcGFuIGxhbmc9RU4tVVM+U2h1Y2hlbmcgTElVIChXaWxsKSwgUGguRC48
bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48aT48c3BhbiBsYW5n
PUVOLVVTPlJlc2VhcmNoZXIgJmFtcDsgU3RhbmRhcmQgUmVwcmVzZW50YXRpdmUgPG86cD48L286
cD48L3NwYW4+PC9pPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PGk+SHVhd2VpIFRlY2hub2xvZ2ll
cyBDby4sTHRkPG86cD48L286cD48L2k+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48aT48c3BhbiBs
YW5nPUVOLVVTPjxhIGhyZWY9Im1haWx0bzpsaXVzaHVjaGVuZ0BodWF3ZWkuY29tIj48c3BhbiBs
YW5nPURFIHN0eWxlPSdjb2xvcjpibHVlJz5saXVzaHVjaGVuZ0BodWF3ZWkuY29tPC9zcGFuPjwv
YT48L3NwYW4+PC9pPjxpPjxvOnA+PC9vOnA+PC9pPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PGk+
PHNwYW4gbGFuZz1FTi1VUz48YSBocmVmPSJodHRwOi8vd3d3LmxpbmtlZGluLmNvbS9pbi9zaHVj
aGVuZyI+PHNwYW4gbGFuZz1ERSBzdHlsZT0nY29sb3I6Ymx1ZSc+aHR0cDovL3d3dy5saW5rZWRp
bi5jb20vaW4vc2h1Y2hlbmc8L3NwYW4+PC9hPjwvc3Bhbj48L2k+PGk+PG86cD48L286cD48L2k+
PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTPi0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBs
YW5nPUVOLVVTPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48L2JvZHk+
PC9odG1sPg==

--_000_0C7EDCF89AB9E2478B5D010026CFF4AEA10C72ABF0SBS2008eictlo_--


From nobody Wed Sep 24 08:01:17 2014
Return-Path: 
X-Original-To: supa@ietfa.amsl.com
Delivered-To: supa@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC61E1A0115 for ; Wed, 24 Sep 2014 08:01:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.336
X-Spam-Level: 
X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.786] 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 hqz7R_Y9SLwk for ; Wed, 24 Sep 2014 08:01:11 -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 1ACDC1A0114 for ; Wed, 24 Sep 2014 08:01:11 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 8AC92123D; Wed, 24 Sep 2014 17:01:09 +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 HizfAof4pzoF; Wed, 24 Sep 2014 17:01:06 +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, 24 Sep 2014 17:01:08 +0200 (CEST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7B33720036; Wed, 24 Sep 2014 17:01:08 +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 7mBomgvjGGSh; Wed, 24 Sep 2014 17:01:07 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7FE3C20035; Wed, 24 Sep 2014 17:01:07 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id C56152E884A1; Wed, 24 Sep 2014 17:01:05 +0200 (CEST)
Date: Wed, 24 Sep 2014 17:01:05 +0200
From: Juergen Schoenwaelder 
To: Hosnieh Rafiee 
Message-ID: <20140924150105.GA24664@elstar.local>
Mail-Followup-To: Hosnieh Rafiee , "supa@ietf.org" 
References: <008201cfc482$191b5d10$4b521730$@tsinghua.edu.cn> <814D0BFB77D95844A01CA29B44CBF8A7A43A9E@lhreml513-mbb.china.huawei.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <814D0BFB77D95844A01CA29B44CBF8A7A43A9E@lhreml513-mbb.china.huawei.com>
User-Agent: Mutt/1.4.2.3i
Archived-At: http://mailarchive.ietf.org/arch/msg/supa/t7-1wh54lNX1NYayGAJi7J1-yTs
Cc: "supa@ietf.org" 
Subject: Re: [Supa] Discussion on SUPA draft chatter
X-BeenThere: supa@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Sep 2014 15:01:16 -0000

On Wed, Sep 24, 2014 at 01:13:08PM +0000, Hosnieh Rafiee wrote:
> Hi,
> 
> I actually only skimmed the previous discussion on the charter so maybe other people already suggested what I am suggesting here...  
> 
> 
> >>    I-D 'Guidelines on using NETCONF (or RESTCONF) authentication and 
>     authorization mechanisms to achieve security protection and isolation' 
>     as an Informational RFC.
> 
> Just a quick idea. Probably  you heard about secauth. It is for authentication and authorization.
> Maybe secauth can be used in this purpose and the informational draft can be about how to use that?

Frankly, it is completely unclear what the issue here is and as a
consequence it is hard to say that throwing in secauth is of any help.
I understand that you push secauth and thus you propose to add it in
here as well. But I do not think this is helpful for any of the BOFs
proposed. NETCONF runs over SSH and TLS, RESTCONF over TLS. If secauth
is useful, it should be useful for SSH and/or TLS and thus any
protocol running over SSH and TLS may benefit without requiring
protocol specific work for the protocols running over the security
layers. I guess I am strongly against the proposal.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         


From nobody Wed Sep 24 08:26:01 2014
Return-Path: 
X-Original-To: supa@ietfa.amsl.com
Delivered-To: supa@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83D4C1A00B9 for ; Wed, 24 Sep 2014 08:25:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.336
X-Spam-Level: 
X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.786] 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 GpJC8i9QwtPt for ; Wed, 24 Sep 2014 08:25:55 -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 0E19A1A016D for ; Wed, 24 Sep 2014 08:25:54 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id C26AA115C; Wed, 24 Sep 2014 17:25:52 +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 Qg-yu4iNOEux; Wed, 24 Sep 2014 17:25:48 +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, 24 Sep 2014 17:25:50 +0200 (CEST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2B83E20036; Wed, 24 Sep 2014 17:25:50 +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 jGdBhUyY9Rat; Wed, 24 Sep 2014 17:25:48 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C39EC20035; Wed, 24 Sep 2014 17:25:47 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id BBA732E88675; Wed, 24 Sep 2014 17:25:47 +0200 (CEST)
Date: Wed, 24 Sep 2014 17:25:47 +0200
From: Juergen Schoenwaelder 
To: Georgios Karagiannis 
Message-ID: <20140924152547.GB24877@elstar.local>
Mail-Followup-To: Georgios Karagiannis , Benoit Claise , Tina TSOU , Zhen Cao , "supa@ietf.org" 
References:    <20140922134145.GC18011@elstar.local>   <5421FAE9.1070105@cisco.com>  <542291A6.1000506@cisco.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
User-Agent: Mutt/1.4.2.3i
Archived-At: http://mailarchive.ietf.org/arch/msg/supa/7VKeJze4RKm4FMJzgRIJCBcGduA
Cc: Benoit Claise , Zhen Cao , "supa@ietf.org" , Tina TSOU 
Subject: Re: [Supa] Area hand-off, and some friendly advice ...
X-BeenThere: supa@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Sep 2014 15:25:57 -0000

Hi,

I can't decipher this. Can people please configure their email clients
such that they do good old quotation instead of using different fonts
and colors that are only visible in HTML?

Thanks,

/js

On Wed, Sep 24, 2014 at 11:29:34AM +0000, Georgios Karagiannis wrote:
> Hi Benoit,
> 
> Thank you for your comments.
> Please see in line,
> 
> From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Benoit Claise
> Sent: Wednesday, September 24, 2014 10:41 AM
> To: Georgios Karagiannis; Tina TSOU; Juergen Schoenwaelder
> Cc: Zhen Cao; supa@ietf.org
> Subject: Re: [Supa] Area hand-off, and some friendly advice ...
> 
> Hi Georgios,
> 
> Hi Benoit,
> 
> 
> 
> Thanks for your comments!
> 
> Please see in line.
> 
> 
> 
> 
> 
> Georgios: Please note that we are referring to the following figure:
> 
>              ---------------------------------------
> 
>              | applications                        |
> 
>              ---------------------------------------
> 
>                        |  <---end use. Appl.   |
> 
>              ---------------------             |<---end use. Appl.
> 
>              | enhanced OSS      |             |
> 
>              ---------------------             |
> 
>                       |   <--- network service |
> 
> YANG models  /NETCONF interface                |
> 
>              --------------------------------------
> 
>              |   controller                       |               <---  mapping network services
> 
> to topology
> 
>              --------------------------------------
> 
>                  |       |        |                    <---
> 
> device/feature specific YANG models / NETCONF interface
> 
>              NE1    NE2   NEn
> It's not obvious what an "enhanced OSS" is?
> 
> Georgios: it relates to the system that runs network services. These services are enhanced Operational Support System (OSS) like services that help a communication service provider to monitor, control, analyze and manage a communication network.
> 
> 
> 
> Georgios: According to the provided figure: 1) need to work on network service Yang models, 2 mapping network services to topology, 3. Device/feature specific Yang Models, 4) end user specific Yank Models (out of scope). The interface between end user applications and a controller, and interface between end user application and enhanced OSS, are also out of scope.
> Concerning your last sentence. I'm confused.
> What does the following deliverable mean then?
> 
> o) specify and standardize how NETCONF/YANG (or RESTCONF/YANG) can be used to securely and efficiently distribute up to date (fresh) network graphs between network service systems and network management and controlling systems
> 
> It relates to the interface between the network service system (enhanced OSS in the above figure.
> Please note that we say that we initially only focus on this interface, in order to narrow down the scope of this activity
> 
> However, if there are supports that think we should initially focus also on the interface between end user application and controller we will also include this interface in the scope.
> 
> 
> 
> 
> 
> 
> 
> Regarding your comment, " I'm not convinced we could standardize them, as they are operators specific, and will be evolving along the time. There are many different ways to configure a VPN, for example." Were you referring to:
> 
> 3. Device/feature specific Yang Models?
> No, the service YANG models
> 
> Georgios: I see, but we can work on YANG models that can be used for a number of main network services, which are essential for operators and that they would like to have them standardized.
> 
> 
> 
> 
> 
> 
> See in-line
> 
> Dear all,
> 
> 
> 
> Hope this version of draft charter address most of the comments from the list.
> 
> 
> 
> ------
> 
> 
> 
> 
> 
> 
> 
> 
> 
> In particular, as starting point, SUPA will only focus on network services, which are enhanced Operational Support System (OSS) like services that help a communication service provider to monitor, control, analyze and manage a communication network. The systems that are runniung such network services are denoted in this document as Network Service Systems.
> 
> Each network service can be represented by a classified application based POLICY model, since it can model the group of demands which are SHARED and UNIFIED and are coming from a bundle of applications that impose similar requirements on the communication network.
> 
> I'm afraid I don't understand (like Jürgen)
> 
> 
> 
> Georgios: What we want to say is that there are applications that impose similar requirements on the communication network. For each group of such bulk of applications a network service can be defined that can be represented by a service policy model (i.e., its actions and constraints).
> 
> 
> 
> 
> 
> Georgios: Thanks for the suggestion, the text needs to be rephrased, see below:
> 
> Each network service can be represented by an application based POLICY model, which is UNIFIED and SHARED, since it can model the group of demands (i.e, actions and constraints) that are coming from a bundle of applications that impose similar requirements on the communication network.
> I still don't understand. what "UNIFIED and SHARED" mean.
> 
> Georgios: the terms "UNIFIED" and "SHARED"" relate to the way of how the service policy model is generated, since it groups and it unifies and shares the similar requirements imposed by a bulk of applications.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> (2) transporting model instances either using NETCONF or RESTCONF and (3) providing guidelines on AUTOMATICALLY mapping policies to attributes of the network graphs.
> 
> 
> 
> Although some IETF working groups have started work relating to the description of various topologies such as I2RS (L3and routing topologies), ALTO (cost maps), SFC (service chain), none of these groups aim at offering truly generic topology models for the standard northbound interface.
> 
> SUPA will work on defining interfaces based on the concept of network graph, an entity describing an arbitrary topology of nodes and links at any level of granularity. Such a graph may describe, for example, a physical topology, a service topology or the relationships between datacenters. Any network topology data models or policy models that have been defined (or are being defined) within the IETF will be reused in SUPA as much as possible.
> 
> In addition to the above, policies may be defined and applied to a network graph. These application based policies are actions or constraints generated by Network Service Systems. They are then mapped from the network graph instance into specific network management policies toward network components.
> 
> 
> 
> 
> 
> Georgios: the above text is not clear. Therefore, I am rephrasing it:
> 
> =============================================
> 
> The main goal of SUPA is to provide application based policies and means to model and program the abstract view of network infrastructure and service function interdependencies in order to support and AUTOMATICALLY feed network management and controlling policies. This can be realized by:
> 
> 
> 
> (1) modeling the network graph, which among others include policy models, data models and application based policies, using YANG,
> 
> 
> 
> (2) applying NETCONF (or RESTCONF) to enable dissemination of up to date (fresh) network graphs in a secure and efficient manner between network service systems and network management and controlling systems,
> "between network service systems and network management and controlling system". What are those? I don't see them in your figure.
> Also, why should all of these need to know about the topology?
> 
> Georgios: In the figure, the enhanced OSS represents the network service system and the controller represents the network management and controlling system.
> In this context, network services can be used to provide the required  configuration and application programming interfaces to service developers. Subsequently, a network service can use the application based demands (for actions and constraints) and possibly update its associated network service  attributes. Examples of network services that can modify  the network service attributes are for example, L3VPN configuration and IPv6 transitions.
> For each network service instance a network graph needs to be generated and maintained.
> The up to date network graph needs to (1) be communicated between the  network service systems and the network   management and controlling systems, (2) map the attributes of the network service graph into specific network management policies.
> 
> Best regards,
> Georgios
> 
> 
> 
> 
> 
> Regards, Benoit

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         


From nobody Wed Sep 24 08:39:29 2014
Return-Path: 
X-Original-To: supa@ietfa.amsl.com
Delivered-To: supa@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 578E91A01DD for ; Wed, 24 Sep 2014 08:39:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.987
X-Spam-Level: 
X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 pjXB0L0XATtZ for ; Wed, 24 Sep 2014 08:39:26 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBD1F1A01C6 for ; Wed, 24 Sep 2014 08:39:25 -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 BJW69081; Wed, 24 Sep 2014 15:38:52 +0000 (GMT)
Received: from LHREML513-MBB.china.huawei.com ([fe80::b810:863:a57e:3ff]) by lhreml401-hub.china.huawei.com ([10.201.5.240]) with mapi id 14.03.0158.001; Wed, 24 Sep 2014 16:38:48 +0100
From: Hosnieh Rafiee 
To: Juergen Schoenwaelder 
Thread-Topic: [Supa] Discussion on SUPA draft chatter
Thread-Index: Ac/Egg4rnM3Ac+nuTf6RywsQVZWuJwTdD/qwAAJrT4AAArLoEA==
Date: Wed, 24 Sep 2014 15:38:47 +0000
Message-ID: <814D0BFB77D95844A01CA29B44CBF8A7A43C83@lhreml513-mbb.china.huawei.com>
References: <008201cfc482$191b5d10$4b521730$@tsinghua.edu.cn> <814D0BFB77D95844A01CA29B44CBF8A7A43A9E@lhreml513-mbb.china.huawei.com> <20140924150105.GA24664@elstar.local>
In-Reply-To: <20140924150105.GA24664@elstar.local>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.221.82.100]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/supa/z6kclY140d9T2zdktIhuX63-4TU
Cc: "supa@ietf.org" 
Subject: Re: [Supa] Discussion on SUPA draft chatter
X-BeenThere: supa@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Sep 2014 15:39:27 -0000

> Frankly, it is completely unclear what the issue here is and as a
> consequence it is hard to say that throwing in secauth is of any help.

I am not quite sure about your question, if your question is that why this =
point is in the charter, I guess in any charter, they can explicitly define=
 the document and scope they work on or the protocols or mechanisms they wo=
uld use. =20

>If secauth
> is useful, it should be useful for SSH and/or TLS and thus any protocol
> running over SSH and TLS may benefit without requiring protocol
> specific work for the protocols running over the security layers.


Secauth is not by default combined to any protocol or does not update TLS o=
r SSH specifications so that you can easily say whatever protocols work on =
TLS, then they by default use it and so no need to mention that. This is no=
t true. In other word, it is independent to those security approaches but a=
ble to work with other protocols.=20
NETCOnf explicitly said that it runs over SSH but does not mean that it sup=
ports the secure authentication and authorization as is the scope of secaut=
h.=20

Second point is that, this was about charter, not about BoF contents and wh=
at scope the WG plans to handle later or what document plans to explain.

Hosnieh







From nobody Wed Sep 24 09:26:22 2014
Return-Path: 
X-Original-To: supa@ietfa.amsl.com
Delivered-To: supa@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 323281A00D6 for ; Wed, 24 Sep 2014 09:26:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.987
X-Spam-Level: 
X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 926EcDXluahR for ; Wed, 24 Sep 2014 09:26:16 -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 15B231A020B for ; Wed, 24 Sep 2014 09:24:50 -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 BJW72433; Wed, 24 Sep 2014 16:24:42 +0000 (GMT)
Received: from LHREML516-MBX.china.huawei.com ([169.254.1.85]) by lhreml401-hub.china.huawei.com ([10.201.5.240]) with mapi id 14.03.0158.001; Wed, 24 Sep 2014 17:22:57 +0100
From: Georgios Karagiannis 
To: Juergen Schoenwaelder 
Thread-Topic: [Supa] Area hand-off, and some friendly advice ...
Thread-Index: AQHPzqh9Us1IwolkWUGUssV+Mn5WLpwFfqEggAAWG8mAAKjywIAG0V4AgAAYJ7CAAACegIAAfwWQgACm8oCAAQe2gIAAfqkwgAA1CQCAABXdgIAASn+AgAAgXCA=
Date: Wed, 24 Sep 2014 16:22:56 +0000
Message-ID: 
References:    <20140922134145.GC18011@elstar.local>   <5421FAE9.1070105@cisco.com>  <542291A6.1000506@cisco.com>  <20140924152547.GB24877@elstar.local>
In-Reply-To: <20140924152547.GB24877@elstar.local>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.203.124.231]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/supa/ICqvFuOM3c5orjgrhmn1Oiqtp_s
Cc: Benoit Claise , Zhen Cao , "supa@ietf.org" , Tina TSOU 
Subject: Re: [Supa] Area hand-off, and some friendly advice ...
X-BeenThere: supa@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Sep 2014 16:26:19 -0000

Hi Juergen,

Thank you very much!
Your comments are noted!
Please see in line!

The text without > is the text that I sent during my last email to Benoit!

Best regards,
Georgios'

> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]
> Sent: Wednesday, September 24, 2014 4:26 PM
> To: Georgios Karagiannis
> Cc: Benoit Claise; Tina TSOU; Zhen Cao; supa@ietf.org
> Subject: Re: [Supa] Area hand-off, and some friendly advice ...
>=20
> Hi,
>=20
> I can't decipher this. Can people please configure their email clients su=
ch
> that they do good old quotation instead of using different fonts and colo=
rs
> that are only visible in HTML?
>=20
> Thanks,
>=20
> /js
>=20
> On Wed, Sep 24, 2014 at 11:29:34AM +0000, Georgios Karagiannis wrote:
 Hi Benoit,

Thank you for your comments.
Please see in line,

> > From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Benoit Claise
> > Sent: Wednesday, September 24, 2014 10:41 AM
> > To: Georgios Karagiannis; Tina TSOU; Juergen Schoenwaelder
> > Cc: Zhen Cao; supa@ietf.org
> > Subject: Re: [Supa] Area hand-off, and some friendly advice ...
> >
> > Hi Georgios,
> >
> > Hi Benoit,
> >
> >
> >
> > Thanks for your comments!
> >
> > Please see in line.
> >
> >
> >
> >
> >
> > Georgios: Please note that we are referring to the following figure:
> >
> >              ---------------------------------------
> >
> >              | applications                        |
> >
> >              ---------------------------------------
> >
> >                        |  <---end use. Appl.   |
> >
> >              ---------------------             |<---end use. Appl.
> >
> >              | enhanced OSS      |             |
> >
> >              ---------------------             |
> >
> >                       |   <--- network service |
> >
> > YANG models  /NETCONF interface                |
> >
> >              --------------------------------------
> >
> >              |   controller                       |               <---
> mapping network services
> >
> > to topology
> >
> >              --------------------------------------
> >
> >                  |       |        |                    <---
> >
> > device/feature specific YANG models / NETCONF interface
> >
> >              NE1    NE2   NEn
> > It's not obvious what an "enhanced OSS" is?
> >
> > Georgios: it relates to the system that runs network services. These
> services are enhanced Operational Support System (OSS) like services that=
 help
> a communication service provider to monitor, control, analyze and manage =
a
> communication network.
> >
> >
> >
> > Georgios: According to the provided figure: 1) need to work on network
> service Yang models, 2 mapping network services to topology, 3. Device/fe=
ature
> specific Yang Models, 4) end user specific Yank Models (out of scope). Th=
e
> interface between end user applications and a controller, and interface
> between end user application and enhanced OSS, are also out of scope.

> Concerning your last sentence. I'm confused.
> What does the following deliverable mean then?
>=20
>  o) specify and standardize how NETCONF/YANG (or RESTCONF/YANG) can be
>  used to securely and efficiently distribute up to date (fresh) network
>  graphs between network service systems and network management and
> controlling systems
=20

Georgios: It relates to the interface between the network service system (e=
nhanced OSS
 and controller in the above figure.

 Please note that we say that we initially only focus on this
interface, in order to narrow down the scope of this activity

 However, if there are supports that think we should initially focus also o=
n
the interface between end user application and controller we will also incl=
ude
this interface in the scope.


> >
> >
> >
> >
> >
> >
> >
> > Regarding your comment, " I'm not convinced we could standardize them, =
as
> they are operators specific, and will be evolving along the time. There a=
re
> many different ways to configure a VPN, for example." Were you referring =
to:
> >
> > 3. Device/feature specific Yang Models?
>  No, the service YANG models
> >

 Georgios: I see, but we can work on YANG models that can be used for a
number of main network services, which are essential for operators and that
they would like to have them standardized.
> >
> >
> >
> >
> >
> >
> > See in-line
> >
> > Dear all,
> >
> >
> >
> > Hope this version of draft charter address most of the comments from th=
e
> list.
> >
> >
> >
> > ------
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > In particular, as starting point, SUPA will only focus on network servi=
ces,
> which are enhanced Operational Support System (OSS) like services that he=
lp a
> communication service provider to monitor, control, analyze and manage a
> communication network. The systems that are runniung such network service=
s are
> denoted in this document as Network Service Systems.
> >
> > Each network service can be represented by a classified application bas=
ed
> POLICY model, since it can model the group of demands which are SHARED an=
d
> UNIFIED and are coming from a bundle of applications that impose similar
> requirements on the communication network.
> >
> I'm afraid I don't understand (like J=FCrgen)
> >
> >
> >
Georgios: What we want to say is that there are applications that impose
similar requirements on the communication network. For each group of such b=
ulk
of applications a network service can be defined that can be represented by=
 a
service policy model (i.e., its actions and constraints).
> >
> >
> >
> >
> >
> > Georgios: Thanks for the suggestion, the text needs to be rephrased, se=
e
> below:
> >
> > Each network service can be represented by an application based POLICY =
model,
> which is UNIFIED and SHARED, since it can model the group of demands (i.e=
,
> actions and constraints) that are coming from a bundle of applications th=
at
> impose similar requirements on the communication network.
> I still don't understand. what "UNIFIED and SHARED" mean.


Georgios: the terms "UNIFIED" and "SHARED"" relate to the way of how the
service policy model is generated, since it groups and it unifies and share=
s
the similar requirements imposed by a bulk of applications.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > (2) transporting model instances either using NETCONF or RESTCONF and (=
3)
> providing guidelines on AUTOMATICALLY mapping policies to attributes of t=
he
> network graphs.
> >
> >
> >
> > Although some IETF working groups have started work relating to the
> description of various topologies such as I2RS (L3and routing topologies)=
,
> ALTO (cost maps), SFC (service chain), none of these groups aim at offeri=
ng
> truly generic topology models for the standard northbound interface.
> >
> > SUPA will work on defining interfaces based on the concept of network g=
raph,
> an entity describing an arbitrary topology of nodes and links at any leve=
l of
> granularity. Such a graph may describe, for example, a physical topology,=
 a
> service topology or the relationships between datacenters. Any network
> topology data models or policy models that have been defined (or are bein=
g
> defined) within the IETF will be reused in SUPA as much as possible.
> >
> > In addition to the above, policies may be defined and applied to a netw=
ork
> graph. These application based policies are actions or constraints genera=
ted
> by Network Service Systems. They are then mapped from the network graph
> instance into specific network management policies toward network compone=
nts.
> >
> >
> >
> >
> >
> > Georgios: the above text is not clear. Therefore, I am rephrasing it:
> >
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> >
> > The main goal of SUPA is to provide application based policies and mean=
s to
> model and program the abstract view of network infrastructure and service
> function interdependencies in order to support and AUTOMATICALLY feed net=
work
> management and controlling policies. This can be realized by:
> >
> >
> >
> > (1) modeling the network graph, which among others include policy
> > models, data models and application based policies, using YANG,
> >
> >
> >
> > (2) applying NETCONF (or RESTCONF) to enable dissemination of up to
> > date (fresh) network graphs in a secure and efficient manner between ne=
twork
> service systems and network management and controlling systems, "between
> network service systems and network management and controlling system".

> Whatare those? I don't see them in your figure.
> Also, why should all of these need to know about the topology?

 Georgios: In the figure, the enhanced OSS represents the network service
system and the controller represents the network management and controlling
system. In this context, network services can be used to provide the requir=
ed
configuration and application programming interfaces to service developers.
Subsequently, a network service can use the application based demands (for
actions and constraints) and possibly update its associated network service
attributes. Examples of network services that can modify  the network servi=
ce
attributes are for example, L3VPN configuration and IPv6 transitions.
 For each network service instance a network graph needs to be generated an=
dmaintained.
The up to date network graph needs to (1) be communicated between the
network service systems and the network   management and controlling system=
s,
(2) map the attributes of the network service graph into specific network m=
anagement policies.


Best regards,
 Georgios
> >
> >
> >

> >
> >
> > Regards, Benoit
>=20
> --
>=20
> On Wed, Sep 24, 2014 at 11:29:34AM +0000, Georgios Karagiannis wrote:
> > Hi Benoit,
> >
> > Thank you for your comments.
> > Please see in line,
> >
> > From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Benoit Claise
> > Sent: Wednesday, September 24, 2014 10:41 AM
> > To: Georgios Karagiannis; Tina TSOU; Juergen Schoenwaelder
> > Cc: Zhen Cao; supa@ietf.org
> > Subject: Re: [Supa] Area hand-off, and some friendly advice ...
> >
> > Hi Georgios,
> >
> > Hi Benoit,
> >
> >
> >
> > Thanks for your comments!
> >
> > Please see in line.
> >
> >
> >
> >
> >
> > Georgios: Please note that we are referring to the following figure:
> >
> >              ---------------------------------------
> >
> >              | applications                        |
> >
> >              ---------------------------------------
> >
> >                        |  <---end use. Appl.   |
> >
> >              ---------------------             |<---end use. Appl.
> >
> >              | enhanced OSS      |             |
> >
> >              ---------------------             |
> >
> >                       |   <--- network service |
> >
> > YANG models  /NETCONF interface                |
> >
> >              --------------------------------------
> >
> >              |   controller                       |               <---
> mapping network services
> >
> > to topology
> >
> >              --------------------------------------
> >
> >                  |       |        |                    <---
> >
> > device/feature specific YANG models / NETCONF interface
> >
> >              NE1    NE2   NEn
> > It's not obvious what an "enhanced OSS" is?
> >
> > Georgios: it relates to the system that runs network services. These
> services are enhanced Operational Support System (OSS) like services that=
 help
> a communication service provider to monitor, control, analyze and manage =
a
> communication network.
> >
> >
> >
> > Georgios: According to the provided figure: 1) need to work on network
> service Yang models, 2 mapping network services to topology, 3. Device/fe=
ature
> specific Yang Models, 4) end user specific Yank Models (out of scope). Th=
e
> interface between end user applications and a controller, and interface
> between end user application and enhanced OSS, are also out of scope.
> > Concerning your last sentence. I'm confused.
> > What does the following deliverable mean then?
> >
> > o) specify and standardize how NETCONF/YANG (or RESTCONF/YANG) can be
> > used to securely and efficiently distribute up to date (fresh) network
> > graphs between network service systems and network management and
> > controlling systems
> >
> > It relates to the interface between the network service system (enhance=
d OSS
> in the above figure.
> > Please note that we say that we initially only focus on this
> > interface, in order to narrow down the scope of this activity
> >
> > However, if there are supports that think we should initially focus als=
o on
> the interface between end user application and controller we will also in=
clude
> this interface in the scope.
> >
> >
> >
> >
> >
> >
> >
> > Regarding your comment, " I'm not convinced we could standardize them, =
as
> they are operators specific, and will be evolving along the time. There a=
re
> many different ways to configure a VPN, for example." Were you referring =
to:
> >
> > 3. Device/feature specific Yang Models?
> > No, the service YANG models
> >
> > Georgios: I see, but we can work on YANG models that can be used for a
> number of main network services, which are essential for operators and th=
at
> they would like to have them standardized.
> >
> >
> >
> >
> >
> >
> > See in-line
> >
> > Dear all,
> >
> >
> >
> > Hope this version of draft charter address most of the comments from th=
e
> list.
> >
> >
> >
> > ------
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > In particular, as starting point, SUPA will only focus on network servi=
ces,
> which are enhanced Operational Support System (OSS) like services that he=
lp a
> communication service provider to monitor, control, analyze and manage a
> communication network. The systems that are runniung such network service=
s are
> denoted in this document as Network Service Systems.
> >
> > Each network service can be represented by a classified application bas=
ed
> POLICY model, since it can model the group of demands which are SHARED an=
d
> UNIFIED and are coming from a bundle of applications that impose similar
> requirements on the communication network.
> >
> > I'm afraid I don't understand (like J=FCrgen)
> >
> >
> >
> > Georgios: What we want to say is that there are applications that impos=
e
> similar requirements on the communication network. For each group of such=
 bulk
> of applications a network service can be defined that can be represented =
by a
> service policy model (i.e., its actions and constraints).
> >
> >
> >
> >
> >
> > Georgios: Thanks for the suggestion, the text needs to be rephrased, se=
e
> below:
> >
> > Each network service can be represented by an application based POLICY =
model,
> which is UNIFIED and SHARED, since it can model the group of demands (i.e=
,
> actions and constraints) that are coming from a bundle of applications th=
at
> impose similar requirements on the communication network.
> > I still don't understand. what "UNIFIED and SHARED" mean.
> >
> > Georgios: the terms "UNIFIED" and "SHARED"" relate to the way of how th=
e
> service policy model is generated, since it groups and it unifies and sha=
res
> the similar requirements imposed by a bulk of applications.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > (2) transporting model instances either using NETCONF or RESTCONF and (=
3)
> providing guidelines on AUTOMATICALLY mapping policies to attributes of t=
he
> network graphs.
> >
> >
> >
> > Although some IETF working groups have started work relating to the
> description of various topologies such as I2RS (L3and routing topologies)=
,
> ALTO (cost maps), SFC (service chain), none of these groups aim at offeri=
ng
> truly generic topology models for the standard northbound interface.
> >
> > SUPA will work on defining interfaces based on the concept of network g=
raph,
> an entity describing an arbitrary topology of nodes and links at any leve=
l of
> granularity. Such a graph may describe, for example, a physical topology,=
 a
> service topology or the relationships between datacenters. Any network
> topology data models or policy models that have been defined (or are bein=
g
> defined) within the IETF will be reused in SUPA as much as possible.
> >
> > In addition to the above, policies may be defined and applied to a netw=
ork
> graph. These application based policies are actions or constraints genera=
ted
> by Network Service Systems. They are then mapped from the network graph
> instance into specific network management policies toward network compone=
nts.
> >
> >
> >
> >
> >
> > Georgios: the above text is not clear. Therefore, I am rephrasing it:
> >
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> >
> > The main goal of SUPA is to provide application based policies and mean=
s to
> model and program the abstract view of network infrastructure and service
> function interdependencies in order to support and AUTOMATICALLY feed net=
work
> management and controlling policies. This can be realized by:
> >
> >
> >
> > (1) modeling the network graph, which among others include policy
> > models, data models and application based policies, using YANG,
> >
> >
> >
> > (2) applying NETCONF (or RESTCONF) to enable dissemination of up to
> > date (fresh) network graphs in a secure and efficient manner between ne=
twork
> service systems and network management and controlling systems, "between
> network service systems and network management and controlling system". W=
hat
> are those? I don't see them in your figure.
> > Also, why should all of these need to know about the topology?
> >
> > Georgios: In the figure, the enhanced OSS represents the network servic=
e
> system and the controller represents the network management and controlli=
ng
> system.
> > In this context, network services can be used to provide the required
> configuration and application programming interfaces to service developer=
s.
> Subsequently, a network service can use the application based demands (fo=
r
> actions and constraints) and possibly update its associated network servi=
ce
> attributes. Examples of network services that can modify  the network ser=
vice
> attributes are for example, L3VPN configuration and IPv6 transitions.
> > For each network service instance a network graph needs to be generated=
 and
> maintained.
> > The up to date network graph needs to (1) be communicated between the
> network service systems and the network   management and controlling syst=
ems,
> (2) map the attributes of the network service graph into specific network
> management policies.
> >
> > Best regards,
> > Georgios
> >
> >
> >
> >
> >
> > Regards, Benoit
>=20
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> Fax:   +49 421 200 3103         


From nobody Wed Sep 24 23:07:26 2014
Return-Path: 
X-Original-To: supa@ietfa.amsl.com
Delivered-To: supa@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FBF01A6F45 for ; Wed, 24 Sep 2014 23:07:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.387
X-Spam-Level: 
X-Spam-Status: No, score=-4.387 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 e3xo2bszwwud for ; Wed, 24 Sep 2014 23:07:21 -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 35EAE1A1A8C for ; Wed, 24 Sep 2014 23:07:21 -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 BJX15104; Thu, 25 Sep 2014 06:07:14 +0000 (GMT)
Received: from LHREML516-MBX.china.huawei.com ([169.254.1.85]) by lhreml402-hub.china.huawei.com ([10.201.5.241]) with mapi id 14.03.0158.001; Thu, 25 Sep 2014 07:07:07 +0100
From: Georgios Karagiannis 
To: Benoit Claise , Tina TSOU , Juergen Schoenwaelder 
Thread-Topic: [Supa] Area hand-off, and some friendly advice ... (using three tier architecture instead of four)
Thread-Index: AQHP2IbvTfqg7wBjvkqLxgki9ig8nw==
Date: Thu, 25 Sep 2014 06:07:06 +0000
Message-ID: 
References:   <338BDC47F10D414AB0BC843C4D5DCFE085CE25@SJCEML701-CHM.china.huawei.com>     <20140922134145.GC18011@elstar.local>   <5421FAE9.1070105@cisco.com>  <542291A6.1000506@cisco.com> 
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.85.101]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/supa/fuNxJ6dES_oEMHudruxZmibB4Vs
Cc: Zhen Cao , "supa@ietf.org" 
Subject: Re: [Supa] Area hand-off, and some friendly advice ... (using three tier architecture instead of four)
X-BeenThere: supa@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Sep 2014 06:07:24 -0000

Hi Benoit,

Based on your comments, I realized that it will be clearer if SUPA should u=
se a three tier architecture instead of a four tier architecture.

I am also proposing to include the following figure in the problem statemen=
t draft.

             --------------------------------------- =20
             | Applications                        |
             ---------------------------------------
                              |   <--- network service=20
                              |        YANG models  /NETCONF interface     =
          =20
             --------------------------------------
             |   controller                       | <---  mapping network s=
ervices to topology
             --------------------------------------
                 |       |        |                 <--- device/feature spe=
cific YANG models / NETCONF interface
             NE1    NE2   NEn


Please note however, "Applications" represent an entity that generates and =
maintains network services and is administrated by a service provider."


Regarding the SUPA main goal, work items and milestones, I would like to pr=
opose the following:
Please let me know if the below addresses your concerns?

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D
The main goal of SUPA is to provide service specific models that allow appl=
ications to request network services to be created/deleted/modified. This c=
an be realized by:
  o) model multiple topologies at different levels of abstraction using a n=
etwork graph,
  o) model the relationships between the abstraction levels.
  o) transporting model instances using either NETCONF or RESTCONF=20

A network service can for example be a virtual link between two endpoints t=
hat uses certain properties, traffic engineering, implementation of IPv6 tr=
ansition mechanism and their enforcement to users.

SUPA will ensure that In case any specific NETCONF/RESTCONF protocol requir=
ements are identified, they will be communicated in a timely manner to the =
NETCONF working group.=20

Work items for SUPA include:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D

1) The definition of a standardized model for a network graph, using YANG. =
This model may be used to describe topologies at any functional layer, from=
 physical networks to network services.=20

2) The definition and standardization of a number of basic policy and data =
models using network graphs. These might include, but are not limited to L3=
VPNs, traffic engineering, implementation of IPv6 transition mechanism and =
their enforcement to users. =20

3) Provide guidelines for mechanisms that can dynamically and automatically=
 map services and policies defined on an abstract topology graph down to mo=
re detailed network graphs and specific network management and controlling =
policies.

4) Guidelines on how to use NETCONF (or RESTCONF) authentication and author=
ization mechanisms to achieve protection and isolation

Milestones:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

o) Produce an I-D  "Problem Statement and Use Cases".

o) Produce an I-D that specifies the YANG models for a generic multi-layer =
network graph.

o) Produce I-Ds that specify extensions for the generic YANG models defined=
 above for network services that manage virtual links, traffic engineering =
and implementation of IPv6 transition mechanism and their enforcement to us=
ers.

o) Produce an I-D that provides the guidelines for mechanisms that can dyna=
mically and automatically map services and policies defined on an abstract =
topology graph down to more detailed network graphs and specific network ma=
nagement and controlling policies.

o) Produce an I-D that provides the guidelines on using NETCONF (or RESTCON=
F) authentication and authorization mechanisms to achieve security protecti=
on and isolation' as an Informational RFC.


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D

Best regards,
Georgios


From nobody Thu Sep 25 00:31:35 2014
Return-Path: 
X-Original-To: supa@ietfa.amsl.com
Delivered-To: supa@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A24D1A006B for ; Thu, 25 Sep 2014 00:31:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.336
X-Spam-Level: 
X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.786] 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 4JyRh2NHpIgp for ; Thu, 25 Sep 2014 00:31:30 -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 AD3D51A0067 for ; Thu, 25 Sep 2014 00:31:29 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 72E281147; Thu, 25 Sep 2014 09:31:28 +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 b2ndw5uzidgc; Thu, 25 Sep 2014 09:31:24 +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; Thu, 25 Sep 2014 09:31:27 +0200 (CEST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5785520036; Thu, 25 Sep 2014 09:31:27 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id CL_3u3w9TkmC; Thu, 25 Sep 2014 09:31:26 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B9EFB20035; Thu, 25 Sep 2014 09:31:25 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id B503A2E88FB0; Thu, 25 Sep 2014 09:31:25 +0200 (CEST)
Date: Thu, 25 Sep 2014 09:31:25 +0200
From: Juergen Schoenwaelder 
To: Hosnieh Rafiee 
Message-ID: <20140925073125.GB26401@elstar.local>
Mail-Followup-To: Hosnieh Rafiee , "supa@ietf.org" 
References: <008201cfc482$191b5d10$4b521730$@tsinghua.edu.cn> <814D0BFB77D95844A01CA29B44CBF8A7A43A9E@lhreml513-mbb.china.huawei.com> <20140924150105.GA24664@elstar.local> <814D0BFB77D95844A01CA29B44CBF8A7A43C83@lhreml513-mbb.china.huawei.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <814D0BFB77D95844A01CA29B44CBF8A7A43C83@lhreml513-mbb.china.huawei.com>
User-Agent: Mutt/1.4.2.3i
Archived-At: http://mailarchive.ietf.org/arch/msg/supa/LsjA6C8ggPJnxKk7Az2eokE8sz8
Cc: "supa@ietf.org" 
Subject: Re: [Supa] Discussion on SUPA draft chatter
X-BeenThere: supa@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Sep 2014 07:31:34 -0000

On Wed, Sep 24, 2014 at 03:38:47PM +0000, Hosnieh Rafiee wrote:
> 
> > Frankly, it is completely unclear what the issue here is and as a
> > consequence it is hard to say that throwing in secauth is of any help.
> 
> I am not quite sure about your question, if your question is that why this point is in the charter, I guess in any charter, they can explicitly define the document and scope they work on or the protocols or mechanisms they would use.  
> 

I said I do not understand that this item really refers to and hence I
can't tell whether secauth is of any relevance. Your response does not
change my observation. Sure, people can write anything they like in a
charter proposal. But then they might be challenged what it means what
they wrote. So you better be prepared to explain what exactly this
charter item means and why secauth is of any help.

> >If secauth
> > is useful, it should be useful for SSH and/or TLS and thus any protocol
> > running over SSH and TLS may benefit without requiring protocol
> > specific work for the protocols running over the security layers.
> 
> 
> Secauth is not by default combined to any protocol or does not update TLS or SSH specifications so that you can easily say whatever protocols work on TLS, then they by default use it and so no need to mention that. This is not true. In other word, it is independent to those security approaches but able to work with other protocols. 
> NETCOnf explicitly said that it runs over SSH but does not mean that it supports the secure authentication and authorization as is the scope of secauth. 
> 
> Second point is that, this was about charter, not about BoF contents and what scope the WG plans to handle later or what document plans to explain.
> 

I am lost. NETCONF runs over SSH or TLS, RESTCONF over TLS. If you
want to run NETCONF over something else, you have to go to the NETCONF
working group. SUPA for sure is not the place to do NETCONF/RESTCONF
security work. If you want to add new authentication mechanisms to SSH
or TLS, you have to go to the respective WGs (where they exist).

/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 Thu Sep 25 02:50:32 2014
Return-Path: 
X-Original-To: supa@ietfa.amsl.com
Delivered-To: supa@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0B8B1A1B91 for ; Thu, 25 Sep 2014 02:50:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 739qNmBgtFy0 for ; Thu, 25 Sep 2014 02:50:24 -0700 (PDT)
Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002:c07::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23A8A1A1C03 for ; Thu, 25 Sep 2014 02:50:20 -0700 (PDT)
Received: by mail-yk0-f174.google.com with SMTP id q9so2654091ykb.19 for ; Thu, 25 Sep 2014 02:50:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=TBO4ziYeM7PcWo5p3LV7zaRsOgL2+Hd/PNqR8wdFXfE=; b=Fkp+Bwtv5NGEtiiimG0TN6rem8n1eVEji1jiOshfDMiQz2n6VXvWI+e524zhYhQATB GW47/6WrI5af1lxP7wsbtM2WvbfwWjpaOxe3/EI0gdEuK8CVX360Jd8Z9UEfTrGPE3ef VAgVAG5B1HqkOKGsdicxhNsVaDBH15j5z61SGkIo/oVF4jcmwG4fXFitKJia7TOd3Hh9 KPOszquvR0g+eYKdjvrdol/LjKAgnXDLd/2PWw+zgJdACThGZZAeTHn/SSun9f2m6ugq TrSOWgIWur5QtLq/3IDtKrbxMulLdIqNUXR/u0QfzAOFqsIVJHyesGRsJ9f6BjaWwWSD B+GA==
X-Received: by 10.236.114.19 with SMTP id b19mr3114118yhh.90.1411638619403; Thu, 25 Sep 2014 02:50:19 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.170.133.207 with HTTP; Thu, 25 Sep 2014 02:49:39 -0700 (PDT)
In-Reply-To: <54132250.5070701@gmail.com>
References: <54132250.5070701@gmail.com>
From: Qiong 
Date: Thu, 25 Sep 2014 17:49:39 +0800
Message-ID: 
To: Spencer Dawkins , Benoit Claise 
Content-Type: multipart/alternative; boundary=14dae9d70d8a75fd2f0503e0baea
Archived-At: http://mailarchive.ietf.org/arch/msg/supa/yjJxaIVjp9oZ_PGbYUc7hXxKP2g
Cc: supa@ietf.org
Subject: Re: [Supa] Area hand-off, and some friendly advice ...
X-BeenThere: supa@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Sep 2014 09:50:27 -0000

--14dae9d70d8a75fd2f0503e0baea
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Benoit and all,



>From the perspective of an operator, I support this work and believe it=E2=
=80=99s
meaningful for our network operation and management. I tried to study all
the thread on the mailing list. However, I wonder if I missed something as
I got a little confused reading your two emails.



In your first email, you wrote:

What can the IETF possibly standardize?

1. **Service YANG models**  /NETCONF? Yes, for sure, and we should do this
full speed 2. Mapping services to topology? Potentially, but that's not an
easy task 3. **service YANG models**  /NETCONF? I'm not convinced we could
standardize them, as they are operators specific, and will be evolving
along the time. There are many different ways to configure a VPN, for
example.



In your second email replying to Georgios, you wrote.

Regarding your comment, " I'm not convinced we could standardize them, as
they are operators specific, and will be evolving along the time. There are
many different ways to configure a VPN, for example." Were you referring to=
:

3. Device/feature specific Yang Models?

No, the **service YANG models**



There are two =E2=80=9Cservice YANG models=E2=80=9D in your first email and=
 you used this
term again in your second email (marked with *). I wonder are you referring
to the same thing, the interface between applications and controller in you
3 layers figure,  by using three of them? As it seems to me that in your
first email, point 1 and point 3 are describing different interfaces with
the same term.


Best wishes

Qiong


China Telecom Beijing Research Institute





*From:* Supa [mailto:supa-bounces@ietf.org ] *On
Behalf Of *Benoit Claise
*Sent:* Wednesday, September 24, 2014 5:41 PM
*To:* Georgios Karagiannis; Tina TSOU; Juergen Schoenwaelder
*Cc:* Zhen Cao; supa@ietf.org
*Subject:* Re: [Supa] Area hand-off, and some friendly advice ...



Hi Georgios,

Hi Benoit,



Thanks for your comments!

Please see in line.





Georgios: Please note that we are referring to the following figure:

             ---------------------------------------

             | applications                        |

             ---------------------------------------

                       |  <---end use. Appl.   |

             ---------------------             |<---end use. Appl.

             | enhanced OSS      |             |

             ---------------------             |

                      |   <--- network service |

YANG models  /NETCONF interface                |

             --------------------------------------

             |   controller                       |               <---
 mapping network services

to topology

             --------------------------------------

                 |       |        |                    <---

device/feature specific YANG models / NETCONF interface

             NE1    NE2   NEn

It's not obvious what an "enhanced OSS" is?

Georgios: According to the provided figure: 1) need to work on network
service Yang models, 2 mapping network services to topology, 3.
Device/feature specific Yang Models, 4) end user specific Yank Models
(out of scope). The interface between end user applications and a
controller, and interface between end user application and enhanced
OSS, are also out of scope.

Concerning your last sentence. I'm confused.
What does the following deliverable mean then?

o) specify and standardize how NETCONF/YANG (or RESTCONF/YANG) can be
used to securely and efficiently distribute up to date (fresh) network
graphs between network service systems and network management and
controlling systems







Regarding your comment, " I'm not convinced we could standardize them,
as they are operators specific, and will be evolving along the time.
There are many different ways to configure a VPN, for example." Were
you referring to:

3. Device/feature specific Yang Models?

No, the service YANG models





See in-line

Dear all,



Hope this version of draft charter address most of the comments from the li=
st.



------









In particular, as starting point, SUPA will only focus on network
services, which are enhanced Operational Support System (OSS) like
services that help a communication service provider to monitor,
control, analyze and manage a communication network. The systems that
are runniung such network services are denoted in this document as
Network Service Systems.

Each network service can be represented by a classified application
based POLICY model, since it can model the group of demands which are
SHARED and UNIFIED and are coming from a bundle of applications that
impose similar requirements on the communication network.

I'm afraid I don't understand (like J=C3=BCrgen)



Georgios: Thanks for the suggestion, the text needs to be rephrased, see be=
low:

Each network service can be represented by an application based POLICY
model, which is UNIFIED and SHARED, since it can model the group of
demands (i.e, actions and constraints) that are coming from a bundle
of applications that impose similar requirements on the communication
network.

I still don't understand what "UNIFIED and SHARED" mean.



(2) transporting model instances either using NETCONF or RESTCONF and
(3) providing guidelines on AUTOMATICALLY mapping policies to
attributes of the network graphs.



Although some IETF working groups have started work relating to the
description of various topologies such as I2RS (L3and routing
topologies), ALTO (cost maps), SFC (service chain), none of these
groups aim at offering truly generic topology models for the standard
northbound interface.

SUPA will work on defining interfaces based on the concept of network
graph, an entity describing an arbitrary topology of nodes and links
at any level of granularity. Such a graph may describe, for example, a
physical topology, a service topology or the relationships between
datacenters. Any network topology data models or policy models that
have been defined (or are being defined) within the IETF will be
reused in SUPA as much as possible.

In addition to the above, policies may be defined and applied to a
network graph. These application based policies are actions or
constraints generated by Network Service Systems. They are then mapped
from the network graph instance into specific network management
policies toward network components.





Georgios: the above text is not clear. Therefore, I am rephrasing it:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

The main goal of SUPA is to provide application based policies and
means to model and program the abstract view of network infrastructure
and service function interdependencies in order to support and
AUTOMATICALLY feed network management and controlling policies. This
can be realized by:



(1) modeling the network graph, which among others include policy
models, data models and application based policies, using YANG,



(2) applying NETCONF (or RESTCONF) to enable dissemination of up to
date (fresh) network graphs in a secure and efficient manner between
network service systems and network management and controlling
systems,

"between network service systems and network management and controlling
system". What are those? I don't see them in your figure.
Also, why should all of these need to know about the topology?

Regards, Benoit

--14dae9d70d8a75fd2f0503e0baea
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
















Hi Benoit and all,


=C2=
=A0


Fro=
m the perspective of an operator, I support this work and believe=20
it=E2=80=99s meaningful for our network operation and management. I tried t=
o study all=20
the thread on the mailing list. However, I wonder if I missed something as =
I got=20
a little confused reading your two emails. 


=C2=
=A0


In your first=
 email, you=20
wrote:


What can the =
IETF possibly=20
standardize?


1. *Servic=
e YANG models*=C2=A0 /NETCONF?=20
Yes, for sure, and we should do this full speed 2. Mapping services to topo=
logy?=20
Potentially, but that's not an easy task 3. *service YANG models=
*=C2=A0=20
/NETCONF? I'm not convinced we could standardize them, as they are oper=
ators=20
specific, and will be evolving along the time. There are many different way=
s to=20
configure a VPN, for example.


=C2=A0


In your second email replying to Georgios, you=20
wrote.


Regarding your=20
comment, " I'm not convinced we could standardize them, as they ar=
e operators=20
specific, and will be evolving along the time. There are many different way=
s to=20
configure a VPN, for example." Were you referring to:


3. Device/feature=
=20
specific Yang Models?


No, =
the *service YANG models* 


=C2=
=A0


The=
re are two =E2=80=9Cservice YANG models=E2=80=9D in your first email and yo=
u used=20
this term again in your second email (marked with *). I wonder are you refe=
rring=20
to the same thing, the interface between applications and controller in you=
 3=20
layers figure, =C2=A0by using three of them? As it seems to me that in your=
 first=20
email, point 1 and point 3 are describing different interfaces with the sam=
e=20
term. 

Best wishes
=
Qiong



China Telecom Beijing Research Institute
=C2=A0








=C2=A0


From: Supa [mailto:supa-bounces@ie=
tf.org] On=20
Behalf Of Benoit Claise
Sent: Wednesday, September 24, 2014 5=
:41=20
PM
To: Georgios Karagiannis; Tina TSOU; Juergen=20
Schoenwaelder
Cc: Zhen Cao; supa=
@ietf.org
Subject: Re: [Supa] Area=20
hand-off, and some friendly advice ...


=C2=
=A0




Hi G=
eorgios,


Hi Benoit,
=C2=A0
Thanks for your comments!
Please see in line.
=C2=A0
=C2=A0
Georgios: Please note th=
at we are referring to the following figure:
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ---------------------------------------=
=C2=A0 
=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0| applications=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 |
=
=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0--=
-------------------------------------
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 |=C2=A0 <---end use. Appl.=C2=A0=C2=A0 |
=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ---------------------=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |<---=
end use. Appl.=C2=A0=C2=A0 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0| enhanced OSS=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=

=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -----------------=
----=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0|
=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0 <--- netw=
ork service |
YANG models=C2=A0 /NETCONF interface=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |
=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 --------------------------=
------------
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 |=C2=A0=C2=A0 controller=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 <---=C2=A0 mapping network services 
<=
pre style=3D"margin-left:21pt">to topology
=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -----------------------=
---------------
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 <--- 
device/feature specific YANG models / NETCONF interface
=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 NE1=C2=A0=C2=A0=C2=A0 NE2=
=C2=A0=C2=A0 NEn


It's not obvious what an "enhanced=
 OSS"=20
is?


Georgios: According to the provided figure=
: 1) need to work on network service Yang models, 2 mapping network service=
s to topology, 3. Device/feature specific Yang Models, 4) end user specific=
 Yank Models (out of scope). The interface between end user applications an=
d a controller, and interface between end user application and enhanced OSS=
, are also out of scope.


Conc=
erning your last sentence. I'm confused.
What does the=20
following deliverable mean then?


o) specify and standardize how NETCONF/YAN=
G (or RESTCONF/YANG) can be used to securely and efficiently distribute up =
to date (fresh) network graphs between network service systems and network =
management and controlling systems


=C2=A0


=C2=A0
=C2=A0
Regarding your comment, " I'm not convi=
nced we could standardize them, as they are operators specific, and will be=
 evolving along the time. There are many different ways to configure a VPN,=
 for example." Were you referring to:
3. Device/feature specific Yang Models?


No, =
the service YANG models 


=C2=A0
=C2=A0


See in-line
Dear all,
=C2=A0
Hope this version of draft charter address =
most of the comments from the list.
=C2=A0
------
<=
span lang=3D"EN-US">=C2=A0
=C2=A0
=C2=A0
=C2=A0


In particular, as starting point, SUPA wil=
l only focus on network services, which are enhanced Operational Support Sy=
stem (OSS) like services that help a communication service provider to moni=
tor, control, analyze and manage a communication network. The systems that =
are runniung such network services are denoted in this document as Network =
Service Systems.
Each network service can be represented by a classified application =
based POLICY model, since it can model the group of demands which are SHARE=
D and UNIFIED and are coming from a bundle of applications that impose simi=
lar requirements on the communication network.
I'm afraid I don'=
t understand (like J=C3=BCrgen)
=C2=A0
Georgios: Thanks for the suggestion, the text needs to b=
e rephrased, see below:
Each network service can be represented by an application bas=
ed POLICY model, which is UNIFIED and SHARED, since it can model the group =
of demands (i.e, actions and constraints) that are coming from a bundle of =
applications that impose similar requirements on the communication network.=



I still don't understand what "UNI=
FIED and=20
SHARED" mean.


=C2=A0


(2) transporting model instances either us=
ing NETCONF or RESTCONF and (3) providing guidelines on AUTOMATICALLY mappi=
ng policies to attributes of the network graphs.
=C2=A0
Although some IETF working groups have =
started work relating to the description of various topologies such as I2RS=
 (L3and routing topologies), ALTO (cost maps), SFC (service chain), none of=
 these groups aim at offering truly generic topology models for the standar=
d northbound interface.
SUPA will work on defining interfaces based on the concept of=
 network graph, an entity describing an arbitrary topology of nodes and lin=
ks at any level of granularity. Such a graph may describe, for example, a p=
hysical topology, a service topology or the relationships between datacente=
rs. Any network topology data models or policy models that have been define=
d (or are being defined) within the IETF will be reused in SUPA as much as =
possible.
=
In addition to the above, policies may be defined and applied to a network =
graph. These application based policies are actions or constraints generate=
d by Network Service Systems. They are then mapped from the network graph i=
nstance into specific network management policies toward network components=
.
=C2=A0
=C2=A0
G=
eorgios: the above text is not clear. Therefore, I am rephrasing it:=

=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
The main goal of SUPA is to provide app=
lication based policies and means to model and program the abstract view of=
 network infrastructure and service function interdependencies in order to =
support and AUTOMATICALLY feed network management and controlling policies.=
 This can be realized by:
=C2=A0
(1) modeling the network graph, which among others include pol=
icy models, data models and application based policies, using YANG, =

=C2=A0
(2) applying NETCON=
F (or RESTCONF) to enable dissemination of up to date (fresh) network graph=
s in a secure and efficient manner between network service systems and netw=
ork management and controlling systems, 


"between network service systems and n=
etwork=20
management and controlling system". What are those? I don't see th=
em in your=20
figure.
Also, why should all of these need to know about the=20
topology?

Regards,=20
Benoit






--14dae9d70d8a75fd2f0503e0baea--


From nobody Thu Sep 25 04:36:10 2014
Return-Path: 
X-Original-To: supa@ietfa.amsl.com
Delivered-To: supa@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E556E1A6F6F for ; Thu, 25 Sep 2014 04:36:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.986
X-Spam-Level: 
X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 AGn594PoG3Ex for ; Thu, 25 Sep 2014 04:36:05 -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 41A301A6F87 for ; Thu, 25 Sep 2014 04:36:04 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJX50888; Thu, 25 Sep 2014 11:36:02 +0000 (GMT)
Received: from SZXEMA403-HUB.china.huawei.com (10.82.72.35) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 25 Sep 2014 12:36:01 +0100
Received: from SZXEMA509-MBS.china.huawei.com ([169.254.2.166]) by SZXEMA403-HUB.china.huawei.com ([10.82.72.35]) with mapi id 14.03.0158.001; Thu, 25 Sep 2014 19:35:56 +0800
From: "Liushucheng (Will)" 
To: Benoit Claise 
Thread-Topic: [Supa] Area hand-off, and some friendly advice ...
Thread-Index: Ac/YtN3W6WlYPTJ8Su+P0Z5ILzAI6Q==
Date: Thu, 25 Sep 2014 11:35:55 +0000
Message-ID: 
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.66.78.79]
Content-Type: multipart/alternative; boundary="_000_C9B5F12337F6F841B35C404CF0554ACB5FF9B336SZXEMA509MBSchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/supa/KXNfiVcrVnukoqrvNhZ5gplgjXo
Cc: "supa@ietf.org" 
Subject: Re: [Supa] Area hand-off, and some friendly advice ...
X-BeenThere: supa@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Sep 2014 11:36:10 -0000

--_000_C9B5F12337F6F841B35C404CF0554ACB5FF9B336SZXEMA509MBSchi_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Benoit,

Below inline please see two pieces of complementary answer from my team (st=
arts with [Will]). Thank you!

Regards,
Will

From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Georgios Karagiannis
Sent: Wednesday, September 24, 2014 7:30 PM
To: Benoit Claise; Tina TSOU; Juergen Schoenwaelder
Cc: Zhen Cao; supa@ietf.org
Subject: Re: [Supa] Area hand-off, and some friendly advice ...

Hi Benoit,

Thank you for your comments.
Please see in line,

From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Benoit Claise
Sent: Wednesday, September 24, 2014 10:41 AM
To: Georgios Karagiannis; Tina TSOU; Juergen Schoenwaelder
Cc: Zhen Cao; supa@ietf.org
Subject: Re: [Supa] Area hand-off, and some friendly advice ...

Hi Georgios,

Hi Benoit,



Thanks for your comments!

Please see in line.





Georgios: Please note that we are referring to the following figure:

             ---------------------------------------

             | applications                        |

             ---------------------------------------

                       |  <---end use. Appl.   |

             ---------------------             |<---end use. Appl.

             | enhanced OSS      |             |

             ---------------------             |

                      |   <--- network service |

YANG models  /NETCONF interface                |

             --------------------------------------

             |   controller                       |               <---  map=
ping network services

to topology

             --------------------------------------

                 |       |        |                    <---

device/feature specific YANG models / NETCONF interface

             NE1    NE2   NEn
It's not obvious what an "enhanced OSS" is?

Georgios: it relates to the system that runs network services. These servic=
es are enhanced Operational Support System (OSS) like services that help a =
communication service provider to monitor, control, analyze and manage a co=
mmunication network.


Georgios: According to the provided figure: 1) need to work on network serv=
ice Yang models, 2 mapping network services to topology, 3. Device/feature =
specific Yang Models, 4) end user specific Yank Models (out of scope). The =
interface between end user applications and a controller, and interface bet=
ween end user application and enhanced OSS, are also out of scope.
Concerning your last sentence. I'm confused.
What does the following deliverable mean then?

o) specify and standardize how NETCONF/YANG (or RESTCONF/YANG) can be used =
to securely and efficiently distribute up to date (fresh) network graphs be=
tween network service systems and network management and controlling system=
s

It relates to the interface between the network service system (enhanced OS=
S in the above figure.
Please note that we say that we initially only focus on this interface, in =
order to narrow down the scope of this activity

However, if there are supports that think we should initially focus also on=
 the interface between end user application and controller we will also inc=
lude this interface in the scope.



[Will]: First of all, IMOH, the figures from Benoit and Georgios are not in=
compatible. From the perspective of controller, they are different latitude=
s of northband. The application and enhanced OSS in Georgios figure can be =
put together into an larger application* layer of Benoit's figure. The netw=
ork graph is proposed to provide network-wide configuration containing the =
key information for service instances. One example is, for the DDC use case=
, the network graph contains the key information such as the key node infor=
mation of the path and the key requirement of traffic steering.



Regarding to the app, management app, end user app here, I want to add some=
thing related to the history of this work. At the very beginning, when this=
 work is call APONF before Toronto IETF meeting, the end user app is in the=
 scope. However, there are mainly three reasons that we remove this point:

1.      The confliction with AECON, we discussed with proponents of AECON a=
nd to avoid the conflict as at that time they were proposing the interface =
from end user app to network devices. Later in the IESG meeting in Toronto,=
 we successfully clarified the differences and got the suggestion to focus =
on management app.

2.      Lars Eggert showed his concerning about the interface between end u=
ser app and network devices may lead to security issue.  Kostas Pentikousis=
 also mentioned this to me.



However, these are old stories. During the Toronto BoF, someone also sugges=
ted us re-put the end user app into cope. A large app layer containing both=
 end user app and management app may replace the first two layers in the ol=
d 4 layers figure. Here, my question is, are you in favor of adding end use=
r app into SUPA scope or not?





Regarding your comment, " I'm not convinced we could standardize them, as t=
hey are operators specific, and will be evolving along the time. There are =
many different ways to configure a VPN, for example." Were you referring to=
:

3. Device/feature specific Yang Models?
No, the service YANG models

Georgios: I see, but we can work on YANG models that can be used for a numb=
er of main network services, which are essential for operators and that the=
y would like to have them standardized.






See in-line

Dear all,



Hope this version of draft charter address most of the comments from the li=
st.



------









In particular, as starting point, SUPA will only focus on network services,=
 which are enhanced Operational Support System (OSS) like services that hel=
p a communication service provider to monitor, control, analyze and manage =
a communication network. The systems that are runniung such network service=
s are denoted in this document as Network Service Systems.

Each network service can be represented by a classified application based P=
OLICY model, since it can model the group of demands which are SHARED and U=
NIFIED and are coming from a bundle of applications that impose similar req=
uirements on the communication network.

I'm afraid I don't understand (like J=FCrgen)



Georgios: What we want to say is that there are applications that impose si=
milar requirements on the communication network. For each group of such bul=
k of applications a network service can be defined that can be represented =
by a service policy model (i.e., its actions and constraints).





Georgios: Thanks for the suggestion, the text needs to be rephrased, see be=
low:

Each network service can be represented by an application based POLICY mode=
l, which is UNIFIED and SHARED, since it can model the group of demands (i.=
e, actions and constraints) that are coming from a bundle of applications t=
hat impose similar requirements on the communication network.
I still don't understand. what "UNIFIED and SHARED" mean.

Georgios: the terms "UNIFIED" and "SHARED"" relate to the way of how the se=
rvice policy model is generated, since it groups and it unifies and shares =
the similar requirements imposed by a bulk of applications.









(2) transporting model instances either using NETCONF or RESTCONF and (3) p=
roviding guidelines on AUTOMATICALLY mapping policies to attributes of the =
network graphs.



Although some IETF working groups have started work relating to the descrip=
tion of various topologies such as I2RS (L3and routing topologies), ALTO (c=
ost maps), SFC (service chain), none of these groups aim at offering truly =
generic topology models for the standard northbound interface.

SUPA will work on defining interfaces based on the concept of network graph=
, an entity describing an arbitrary topology of nodes and links at any leve=
l of granularity. Such a graph may describe, for example, a physical topolo=
gy, a service topology or the relationships between datacenters. Any networ=
k topology data models or policy models that have been defined (or are bein=
g defined) within the IETF will be reused in SUPA as much as possible.

In addition to the above, policies may be defined and applied to a network =
graph. These application based policies are actions or constraints generate=
d by Network Service Systems. They are then mapped from the network graph i=
nstance into specific network management policies toward network components=
.





Georgios: the above text is not clear. Therefore, I am rephrasing it:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

The main goal of SUPA is to provide application based policies and means to=
 model and program the abstract view of network infrastructure and service =
function interdependencies in order to support and AUTOMATICALLY feed netwo=
rk management and controlling policies. This can be realized by:



(1) modeling the network graph, which among others include policy models, d=
ata models and application based policies, using YANG,



(2) applying NETCONF (or RESTCONF) to enable dissemination of up to date (f=
resh) network graphs in a secure and efficient manner between network servi=
ce systems and network management and controlling systems,
"between network service systems and network management and controlling sys=
tem". What are those? I don't see them in your figure.
Also, why should all of these need to know about the topology?

Georgios: In the figure, the enhanced OSS represents the network service sy=
stem and the controller represents the network management and controlling s=
ystem.
In this context, network services can be used to provide the required  conf=
iguration and application programming interfaces to service developers. Sub=
sequently, a network service can use the application based demands (for act=
ions and constraints) and possibly update its associated network service  a=
ttributes. Examples of network services that can modify  the network servic=
e attributes are for example, L3VPN configuration and IPv6 transitions.
For each network service instance a network graph needs to be generated and=
 maintained.
The up to date network graph needs to (1) be communicated between the  netw=
ork service systems and the network   management and controlling systems, (=
2) map the attributes of the network service graph into specific network ma=
nagement policies.
[Will] To modeling service requirement and create service instances, APP ne=
eds a view of topology to form network configuration according to the key i=
nformation of devices topology. This configuration is eventually mapped to =
the selected network devices according to topology provided by SUPA.

Best regards,
Georgios





Regards, Benoit

--_000_C9B5F12337F6F841B35C404CF0554ACB5FF9B336SZXEMA509MBSchi_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hi Benoit,=



 


Below inli=
ne please see two pieces of complementary answer from my team (starts with
[Will]). Thank you!


 




Regards,


Will




 








From:
 Supa [mailto:supa-bounces@ietf.or=
g] 
On Behalf Of Georgios Karagiannis

Sent: Wednesday, September 24, 2014 7:30 PM

To: Benoit Claise; Tina TSOU; Juergen Schoenwaelder

Cc: Zhen Cao; supa@ietf.org

Subject: Re: [Supa] Area hand-off, and some friendly advice ...=







 


Hi Benoit,=



 


Thank you for your comments.=



Please see in line,


 






From:
 Supa [mailto:supa-bounces@ietf.or=
g] 
On Behalf Of Benoit Claise

Sent: Wednesday, September 24, 2014 10:41 AM

To: Georgios Karagiannis; Tina TSOU; Juergen Schoenwaelder

Cc: Zhen Cao; supa@ietf.org

Subject: Re: [Supa] Area hand-off, and some friendly advice ...=







 




Hi Georgios,






Hi Benoit,


 


Thanks for your comments!


Please see in line.


 


 


Georgios: Please note that we are referring to the following figure=
:


           &=
nbsp; ---------------------------------------  

           &=
nbsp; | applications        &n=
bsp;            =
;   |


           &=
nbsp; ---------------------------------------


           &=
nbsp;           |  &=
lt;---end use. Appl.   |


           &=
nbsp; ---------------------        =
     |<---end use. Appl.   


           &=
nbsp; | enhanced OSS      |   =
          |<=
/pre>

           &=
nbsp; ---------------------        =
     |


            =
          |   &=
lt;--- network service |


YANG models  /NETCONF interface     &=
nbsp;          |


           &=
nbsp; --------------------------------------


           &=
nbsp; |   controller       &nb=
sp;            =
   |          &=
nbsp;    <---  mapping network services <=
/span>


to topology


           &=
nbsp; --------------------------------------


           &=
nbsp;     |       | =
       |      &=
nbsp;           &nbs=
p; <--- 


device/feature specific YANG models / NETCONF interface<=
/span>


           &=
nbsp; NE1    NE2   NEn




It's not obvious what an "enhanced OSS"=
 is?<=
/p>

 


Georgios: it relates to the =
system that runs network services. These services are enhanced
 Operational Support System (OSS) like services that help a communication s=
ervice provider to monitor, control, analyze and manage a communication net=
work.




 


Georgios: According to the provided figure: 1) need to work on netw=
ork service Yang models, 2 mapping network services to topology, 3. Device/=
feature specific Yang Models, 4) end user specific Yank Models (out of scop=
e). The interface between end user applications and a controller, and inter=
face between end user application and enhanced OSS, are also out of scope.<=
o:p>


Concerning your last sentence. I'm confused.

What does the following deliverable mean then?


o) specify and standardize how NETCONF/YANG (or RESTCONF/YANG) can =
be used to securely and efficiently distribute up to date (fresh) network g=
raphs between network service systems and network management and controllin=
g systems


 <=
/p>

It relates to the interface =
between the network service system (enhanced OSS in the above
 figure.


Please note that we say that=
 we initially only focus on this interface, in order to narrow
 down the scope of this activity


 


However, if there are suppor=
ts that think we should initially focus also on the interface
 between end user application and controller we will also include this inte=
rface in the scope.


 


[Will]: First of all, IMOH, the figures =
from Benoit and Georgios are not incompatible. From the perspective of cont=
roller, they are different latitudes of northband. The application and enhanced OSS in Georgios fig=
ure can be put together into an larger application* layer of Benoit’s=
 figure. The network graph is proposed to provide network-wide configuratio=
n containing the key information for service instances. One example is, for=
 the DDC use case, the network graph contains the key information such as t=
he key node information of the path and the key requirement of traffic stee=
ring. 


 


Regarding to the app, management app, en=
d user app here, I want to add something related to the history of this wor=
k. At the very beginning, when this work is call APONF before Toronto IETF =
meeting, the end user app is in the scope. However, there are mainly three =
reasons that we remove this point:


1.      The confliction with AECON, we discussed with proponents of AECON an=
d to avoid the conflict as at that time they were proposing the interface f=
rom end user app to network devices. Later in the IESG meeting in Toronto, =
we successfully clarified the differences and got the suggestion to focus o=
n management app.


2.      Lars Eggert showed his concerning about the interface between end us=
er app and network devices may lead to security issue.  Kostas Pentiko=
usis also mentioned this to me. 


 


However, these are old stories. During t=
he Toronto BoF, someone also suggested us re-put the end user app into cope=
. A large app layer containing both end user app and management app may rep=
lace the first two layers in the old 4 layers figure. Here, my question is,=
 are you in favor of adding end user app into SUPA scope or not?=



 


 


Regarding your comment, " I'm not convinced we could standardi=
ze them, as they are operators specific, and will be evolving along the tim=
e. There are many different ways to configure a VPN, for example." Wer=
e you referring to:


3. Device/feature specific Yang Models?


No, the service YANG models



 


Georgios: I see, but we can =
work on YANG models that can be used for a number of main network
 services, which are essential for operators and that they would like to ha=
ve them standardized.


 


 


 




See in-line


Dear all,


 


Hope this version of draft charter address most of the comments fro=
m the list.


 


------


 


 


 


 






In particular, as starting point, SUPA will only focus on network s=
ervices, which are enhanced Operational Support System (OSS) like services =
that help a communication service provider to monitor, control, analyze and=
 manage a communication network. The systems that are runniung such network=
 services are denoted in this document as Network Service Systems.


Each network service can be represented by a classified application=
 based POLICY model, since it can model the group of demands which are SHAR=
ED and UNIFIED and are coming from a bundle of applications that impose sim=
ilar requirements on the communication network.




I'm afraid I don't understand (like J=FCrgen)

 


Georgios: What we want to say is that there ar=
e applications that impose similar requirements on the communication networ=
k. For each group of such bulk of applications a network service can be def=
ined that can be represented by a service policy model (i.e., its actions a=
nd constraints).


 


 


Georgios: Thanks for the suggestion, the text needs to be rephrased=
, see below:


Each network service can be represented by an application based POL=
ICY model, which is UNIFIED and SHARED, since it can model the group of dem=
ands (i.e, actions and constraints) that are coming from a bundle of applic=
ations that impose similar requirements on the communication network.<=
/o:p>


I still don't understand. what "UNIFIED=
 and SHARED" mean.=



 


Georgios: the terms “U=
NIFIED” and “SHARED”” relate to the way of how the =
service policy
 model is generated, since it groups and it unifies and shares the similar =
requirements imposed by a bulk of applications.


 


 


 


 


 



 


 




(2) transporting model instances either using NETCONF or RESTCONF a=
nd (3) providing guidelines on AUTOMATICALLY mapping policies to attributes=
 of the network graphs.


 


Although some IETF working groups have started work relating to the=
 description of various topologies such as I2RS (L3and routing topologies),=
 ALTO (cost maps), SFC (service chain), none of these groups aim at offerin=
g truly generic topology models for the standard northbound interface.=



SUPA will work on defining interfaces based on the concept of netwo=
rk graph, an entity describing an arbitrary topology of nodes and links at =
any level of granularity. Such a graph may describe, for example, a physica=
l topology, a service topology or the relationships between datacenters. An=
y network topology data models or policy models that have been defined (or =
are being defined) within the IETF will be reused in SUPA as much as possib=
le.


In addition to the above, policies may be defined and applied to a =
network graph. These application based policies are actions or constraints =
generated by Network Service Systems. They are then mapped from the network=
 graph instance into specific network management policies toward network co=
mponents.




 


 


Georgios: the above text is not clear. Therefore, I am rephrasing i=
t:


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<=
/o:p>


The main goal of SUPA is to provide application based policies and =
means to model and program the abstract view of network infrastructure and =
service function interdependencies in order to support and AUTOMATICALLY fe=
ed network management and controlling policies. This can be realized by:


 


(1) modeling the network graph, which among others include policy m=
odels, data models and application based policies, using YANG, <=
/span>


 


(2) applying NETCONF (or RESTCONF) to enable dissemination of up to=
 date (fresh) network graphs in a secure and efficient manner between netwo=
rk service systems and network management and controlling systems, 



"between network service systems and network mana=
gement and controlling system". What are those? I don't see them in yo=
ur figure.

Also, why should all of these need to know about the topology?



 



Georgios: In the figure, the enha=
nced OSS represents the network service system and the controller represent=
s the network management and controlling system.



In this context, network services=
 can be used to provide the required  configuration and application pr=
ogramming interfaces to service developers. Subsequently, a network
 service can use the application based demands (for actions and constraints=
) and possibly update its associated network service  attributes. Exam=
ples of network services that can modify  the network service attribut=
es are for example, L3VPN configuration and
 IPv6 transitions. 



For each network service instance=
 a network graph needs to be generated and maintained.




The up to date network graph need=
s to (1) be communicated between the  network service systems and the =
network   management and controlling systems, (2) map the attribu=
tes
 of the network service graph into specific network management policies.



[Will] To modeling service =
requirement and create service instances, APP needs a view of topology to f=
orm network configuration according to the key information
 of devices topology. This configuration is eventually mapped to the select=
ed network devices according to topology provided by SUPA.



 



Best regards,



Georgios



 



 



 







Regards, Benoit








--_000_C9B5F12337F6F841B35C404CF0554ACB5FF9B336SZXEMA509MBSchi_--


From nobody Thu Sep 25 17:01:55 2014
Return-Path: 
X-Original-To: supa@ietfa.amsl.com
Delivered-To: supa@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC7921A008F for ; Thu, 25 Sep 2014 17:01:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.987
X-Spam-Level: 
X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 wd99l8LXQiYx for ; Thu, 25 Sep 2014 17:01:51 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86C6B1A0056 for ; Thu, 25 Sep 2014 17:01:50 -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 BNA12690; Fri, 26 Sep 2014 00:01:49 +0000 (GMT)
Received: from LHREML516-MBX.china.huawei.com ([169.254.1.85]) by lhreml402-hub.china.huawei.com ([10.201.5.241]) with mapi id 14.03.0158.001; Fri, 26 Sep 2014 01:01:48 +0100
From: Georgios Karagiannis 
To: "supa@ietf.org" 
Thread-Topic: New Version Notification for draft-karagiannis-supa-problem-statement-01.txt
Thread-Index: AQHP2RzY1MjCEot2FEq6LcavURC535wSh4Xw
Date: Fri, 26 Sep 2014 00:01:48 +0000
Message-ID: 
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.89.243]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/supa/PMvHpPUFYWMAHOPoJ46lPXXwrwo
Subject: [Supa] FW: New Version Notification for draft-karagiannis-supa-problem-statement-01.txt
X-BeenThere: supa@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Sep 2014 00:01:54 -0000

SGkgYWxsLA0KDQpXZSBoYXZlIHdvcmtlZCBvdXQgYWxsIGNvbW1lbnRzIHRoYXQgd2UgcmVjZWl2
ZWQgb24gdGhlIFNVUEEgbGlzdCBhbmQgdXBkYXRlZCB0aGUgcHJvYmxlbSBzdGF0ZW1lbnQgZHJh
ZnQsIHNlZSBiZWxvdy4NCg0KQmVzdCByZWdhcmRzLA0KR2Vvcmdpb3MNCg0KPiAtLS0tLU9yaWdp
bmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0
bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddDQo+IFNlbnQ6IEZyaWRheSwgU2VwdGVtYmVyIDI2
LCAyMDE0IDE6MDAgQU0NCj4gVG86IFFpb25nIFN1bjsgTGl1c2h1Y2hlbmcgKFdpbGwpOyBRaW9u
ZyBTdW47IEdlb3JnaW9zIEthcmFnaWFubmlzOyBUaW5hIFRTT1U7DQo+IExpdXNodWNoZW5nIChX
aWxsKTsgVGluYSBUU09VOyBQYXJ2aXogWWVnYW5pOyBEaWVnbyBSLiBMb3BlejsgRGllZ28gTG9w
ZXo7DQo+IEdlb3JnaW9zIEthcmFnaWFubmlzOyBQYXJ2aXogWWVnYW5pDQo+IFN1YmplY3Q6IE5l
dyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQta2FyYWdpYW5uaXMtc3VwYS1wcm9ibGVt
LQ0KPiBzdGF0ZW1lbnQtMDEudHh0DQo+IA0KPiANCj4gQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRy
YWZ0LWthcmFnaWFubmlzLXN1cGEtcHJvYmxlbS1zdGF0ZW1lbnQtMDEudHh0DQo+IGhhcyBiZWVu
IHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgR2Vvcmdpb3MgS2FyYWdpYW5uaXMgYW5kIHBvc3Rl
ZCB0byB0aGUgSUVURg0KPiByZXBvc2l0b3J5Lg0KPiANCj4gTmFtZToJCWRyYWZ0LWthcmFnaWFu
bmlzLXN1cGEtcHJvYmxlbS1zdGF0ZW1lbnQNCj4gUmV2aXNpb246CTAxDQo+IFRpdGxlOgkJUHJv
YmxlbSBTdGF0ZW1lbnQgZm9yIFNoYXJlZCBVbmlmaWVkIFBvbGljeSBBdXRvbWF0aW9uIChTVVBB
KQ0KPiBEb2N1bWVudCBkYXRlOgkyMDE0LTA5LTI1DQo+IEdyb3VwOgkJSW5kaXZpZHVhbCBTdWJt
aXNzaW9uDQo+IFBhZ2VzOgkJOQ0KPiBVUkw6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9y
Zy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQta2FyYWdpYW5uaXMtc3VwYS0NCj4gcHJvYmxlbS1zdGF0
ZW1lbnQtMDEudHh0DQo+IFN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYu
b3JnL2RvYy9kcmFmdC1rYXJhZ2lhbm5pcy1zdXBhLQ0KPiBwcm9ibGVtLXN0YXRlbWVudC8NCj4g
SHRtbGl6ZWQ6ICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWthcmFnaWFu
bmlzLXN1cGEtcHJvYmxlbS0NCj4gc3RhdGVtZW50LTAxDQo+IERpZmY6ICAgICAgICAgICBodHRw
Oi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1rYXJhZ2lhbm5pcy1zdXBhLQ0KPiBw
cm9ibGVtLXN0YXRlbWVudC0wMQ0KPiANCj4gQWJzdHJhY3Q6DQo+ICAgIEFzIG1vZGVybiBuZXR3
b3JrIG1hbmFnZW1lbnQgYXBwbGljYXRpb25zIGdyb3cgaW4gc2NhbGUNCj4gICAgYW5kIGNvbXBs
ZXhpdHksIHRoZWlyIGRlbWFuZHMgYW5kIHJlcXVpcmVtZW50cyBvbiB0aGUgc3VwcG9ydGluZw0K
PiAgICBjb21tdW5pY2F0aW9uIG5ldHdvcmsgaW5jcmVhc2UuDQo+ICAgIEluIHBhcnRpY3VsYXIs
IG5ldHdvcmsgb3BlcmF0b3JzIGFyZSBjaGFsbGVuZ2VkIHRvIGNyZWF0ZSBhDQo+ICAgIHNpbXBs
aWZpZWQgdmlldyBvZiB0aGVpciBuZXR3b3JrIGluZnJhc3RydWN0dXJlIGFuZCBoZWxwIHNlcnZp
Y2UNCj4gICAgZGV2ZWxvcGVycyBvbiB1c2luZyBhbmQgcHJvZ3JhbW1pbmcgdGhpcyBzaW1wbGlm
aWVkIHZpZXcgcmF0aGVyIHRoYW4NCj4gICAgbWFuaXB1bGF0aW5nIGluZGl2aWR1YWwgZGV2aWNl
cy4gSW4gdGhpcyBjb250ZXh0LCBwcm92aWRpbmcgc2VydmljZQ0KPiAgICBkZXZlbG9wZXJzIHdp
dGggYSBzZXQgb2Ygc3RhbmRhcmQgaW50ZXJmYWNlcyB0byBjb25maWd1cmUgYW5kIHNldA0KPiAg
ICBwb2xpY2llcyBvbiB0aGUgbmV0d29yayBpcyBlc3NlbnRpYWwuDQo+ICAgIFRoaXMgZG9jdW1l
bnQgZGVzY3JpYmVzIHdoYXQgaGFzIHRvIGJlIGFkZHJlc3NlZCBpbiBvcmRlciB0byBlcXVpcA0K
PiAgICBzZXJ2aWNlIHByb3ZpZGVycyB3aXRoICBhIHZlbmRvciBuZXV0cmFsIHN0YW5kYXJkaXpl
ZCBhcHBsaWNhdGlvbi0NCj4gICAgYmFzZWQgaW50ZXJmYWNlcyB1c2VkIHRvIGV4cG9zZSBhbmQg
ZGVmaW5lIHBvbGljaWVzIGFuZCBuIGFic3RyYWN0DQo+ICAgIHZpZXcgb2YgbmV0d29yayBpbmZy
YXN0cnVjdHVyZS4NCj4gDQo+IA0KPiANCj4gDQo+IA0KPiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1h
eSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQo+
IHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9v
bHMuaWV0Zi5vcmcuDQo+IA0KPiBUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo=


From nobody Thu Sep 25 17:23:03 2014
Return-Path: 
X-Original-To: supa@ietfa.amsl.com
Delivered-To: supa@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8482E1A007C for ; Thu, 25 Sep 2014 17:23:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.987
X-Spam-Level: 
X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 kQfZr1MsQATa for ; Thu, 25 Sep 2014 17:23:01 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD2F91A0004 for ; Thu, 25 Sep 2014 17:23:00 -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 BJX99688; Fri, 26 Sep 2014 00:22:59 +0000 (GMT)
Received: from LHREML516-MBX.china.huawei.com ([169.254.1.85]) by lhreml403-hub.china.huawei.com ([::1]) with mapi id 14.03.0158.001; Fri, 26 Sep 2014 01:22:54 +0100
From: Georgios Karagiannis 
To: "supa@ietf.org" 
Thread-Topic: New Version Notification for draft-karagiannis-supa-problem-statement-01.txt
Thread-Index: AQHP2RzY1MjCEot2FEq6LcavURC535wSjUpQ
Date: Fri, 26 Sep 2014 00:22:54 +0000
Message-ID: 
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.89.243]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/supa/DRyTTyblTcaFaFtU6_F1cZ6kkDY
Subject: [Supa] FW: New Version Notification for draft-karagiannis-supa-problem-statement-01.txt
X-BeenThere: supa@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Sep 2014 00:23:02 -0000

SGkgYWxsLA0KDQpXZSBoYXZlIHdvcmtlZCBvdXQgYWxsIGNvbW1lbnRzIHRoYXQgd2UgcmVjZWl2
ZWQgb24gdGhlIFNVUEEgbGlzdCBhbmQgdXBkYXRlZCB0aGUgcHJvYmxlbSBzdGF0ZW1lbnQgZHJh
ZnQsIHNlZSBiZWxvdy4NCg0KQmVzdCByZWdhcmRzLA0KR2Vvcmdpb3MNCg0KPiAtLS0tLU9yaWdp
bmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0
bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddDQo+IFNlbnQ6IEZyaWRheSwgU2VwdGVtYmVyIDI2
LCAyMDE0IDE6MDAgQU0NCj4gVG86IFFpb25nIFN1bjsgTGl1c2h1Y2hlbmcgKFdpbGwpOyBRaW9u
ZyBTdW47IEdlb3JnaW9zIEthcmFnaWFubmlzOyBUaW5hIFRTT1U7DQo+IExpdXNodWNoZW5nIChX
aWxsKTsgVGluYSBUU09VOyBQYXJ2aXogWWVnYW5pOyBEaWVnbyBSLiBMb3BlejsgRGllZ28gTG9w
ZXo7DQo+IEdlb3JnaW9zIEthcmFnaWFubmlzOyBQYXJ2aXogWWVnYW5pDQo+IFN1YmplY3Q6IE5l
dyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQta2FyYWdpYW5uaXMtc3VwYS1wcm9ibGVt
LQ0KPiBzdGF0ZW1lbnQtMDEudHh0DQo+IA0KPiANCj4gQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRy
YWZ0LWthcmFnaWFubmlzLXN1cGEtcHJvYmxlbS1zdGF0ZW1lbnQtMDEudHh0DQo+IGhhcyBiZWVu
IHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgR2Vvcmdpb3MgS2FyYWdpYW5uaXMgYW5kIHBvc3Rl
ZCB0byB0aGUgSUVURg0KPiByZXBvc2l0b3J5Lg0KPiANCj4gTmFtZToJCWRyYWZ0LWthcmFnaWFu
bmlzLXN1cGEtcHJvYmxlbS1zdGF0ZW1lbnQNCj4gUmV2aXNpb246CTAxDQo+IFRpdGxlOgkJUHJv
YmxlbSBTdGF0ZW1lbnQgZm9yIFNoYXJlZCBVbmlmaWVkIFBvbGljeSBBdXRvbWF0aW9uIChTVVBB
KQ0KPiBEb2N1bWVudCBkYXRlOgkyMDE0LTA5LTI1DQo+IEdyb3VwOgkJSW5kaXZpZHVhbCBTdWJt
aXNzaW9uDQo+IFBhZ2VzOgkJOQ0KPiBVUkw6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9y
Zy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQta2FyYWdpYW5uaXMtc3VwYS0NCj4gcHJvYmxlbS1zdGF0
ZW1lbnQtMDEudHh0DQo+IFN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYu
b3JnL2RvYy9kcmFmdC1rYXJhZ2lhbm5pcy1zdXBhLQ0KPiBwcm9ibGVtLXN0YXRlbWVudC8NCj4g
SHRtbGl6ZWQ6ICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWthcmFnaWFu
bmlzLXN1cGEtcHJvYmxlbS0NCj4gc3RhdGVtZW50LTAxDQo+IERpZmY6ICAgICAgICAgICBodHRw
Oi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1rYXJhZ2lhbm5pcy1zdXBhLQ0KPiBw
cm9ibGVtLXN0YXRlbWVudC0wMQ0KPiANCj4gQWJzdHJhY3Q6DQo+ICAgIEFzIG1vZGVybiBuZXR3
b3JrIG1hbmFnZW1lbnQgYXBwbGljYXRpb25zIGdyb3cgaW4gc2NhbGUNCj4gICAgYW5kIGNvbXBs
ZXhpdHksIHRoZWlyIGRlbWFuZHMgYW5kIHJlcXVpcmVtZW50cyBvbiB0aGUgc3VwcG9ydGluZw0K
PiAgICBjb21tdW5pY2F0aW9uIG5ldHdvcmsgaW5jcmVhc2UuDQo+ICAgIEluIHBhcnRpY3VsYXIs
IG5ldHdvcmsgb3BlcmF0b3JzIGFyZSBjaGFsbGVuZ2VkIHRvIGNyZWF0ZSBhDQo+ICAgIHNpbXBs
aWZpZWQgdmlldyBvZiB0aGVpciBuZXR3b3JrIGluZnJhc3RydWN0dXJlIGFuZCBoZWxwIHNlcnZp
Y2UNCj4gICAgZGV2ZWxvcGVycyBvbiB1c2luZyBhbmQgcHJvZ3JhbW1pbmcgdGhpcyBzaW1wbGlm
aWVkIHZpZXcgcmF0aGVyIHRoYW4NCj4gICAgbWFuaXB1bGF0aW5nIGluZGl2aWR1YWwgZGV2aWNl
cy4gSW4gdGhpcyBjb250ZXh0LCBwcm92aWRpbmcgc2VydmljZQ0KPiAgICBkZXZlbG9wZXJzIHdp
dGggYSBzZXQgb2Ygc3RhbmRhcmQgaW50ZXJmYWNlcyB0byBjb25maWd1cmUgYW5kIHNldA0KPiAg
ICBwb2xpY2llcyBvbiB0aGUgbmV0d29yayBpcyBlc3NlbnRpYWwuDQo+ICAgIFRoaXMgZG9jdW1l
bnQgZGVzY3JpYmVzIHdoYXQgaGFzIHRvIGJlIGFkZHJlc3NlZCBpbiBvcmRlciB0byBlcXVpcA0K
PiAgICBzZXJ2aWNlIHByb3ZpZGVycyB3aXRoICBhIHZlbmRvciBuZXV0cmFsIHN0YW5kYXJkaXpl
ZCBhcHBsaWNhdGlvbi0NCj4gICAgYmFzZWQgaW50ZXJmYWNlcyB1c2VkIHRvIGV4cG9zZSBhbmQg
ZGVmaW5lIHBvbGljaWVzIGFuZCBuIGFic3RyYWN0DQo+ICAgIHZpZXcgb2YgbmV0d29yayBpbmZy
YXN0cnVjdHVyZS4NCj4gDQo+IA0KPiANCj4gDQo+IA0KPiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1h
eSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQo+
IHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9v
bHMuaWV0Zi5vcmcuDQo+IA0KPiBUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo=


From nobody Thu Sep 25 17:32:09 2014
Return-Path: 
X-Original-To: supa@ietfa.amsl.com
Delivered-To: supa@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A1111A00B0 for ; Thu, 25 Sep 2014 17:32:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.386
X-Spam-Level: 
X-Spam-Status: No, score=-4.386 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 suDsVKVnICu6 for ; Thu, 25 Sep 2014 17:32:05 -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 48BE81A008B for ; Thu, 25 Sep 2014 17:32:04 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJY00069; Fri, 26 Sep 2014 00:32:02 +0000 (GMT)
Received: from LHREML516-MBX.china.huawei.com ([169.254.1.85]) by lhreml404-hub.china.huawei.com ([::1]) with mapi id 14.03.0158.001; Fri, 26 Sep 2014 01:31:57 +0100
From: Georgios Karagiannis 
To: "supa@ietf.org" 
Thread-Topic: New SUPA charter
Thread-Index: Ac/ZIUcaEK+SU+lYTNqeRV6T6bQAHw==
Date: Fri, 26 Sep 2014 00:31:57 +0000
Message-ID: 
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.89.243]
Content-Type: multipart/alternative; boundary="_000_C5034E44CD620A44971BAAEB372655DC636315LHREML516MBXchina_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/supa/_40CEHLi3poQiFDqy9cMbx32ILo
Subject: [Supa] New SUPA charter
X-BeenThere: supa@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Sep 2014 00:32:07 -0000

--_000_C5034E44CD620A44971BAAEB372655DC636315LHREML516MBXchina_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi all,

We have worked out all comments that we have received on the previous versi=
on of the SUPA charter.
The new version of the charter can be seen below:

Best regards,
Georgios


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
SUPA (Shared Unified Policy Automation) charter v1.12
Target Area: Operations and Management

Description of Working Group:

Programmatic ways to configure networks, often called software-defined, are=
 considered by many network operators in order to shift the balance in thei=
r favor.
Automating the way of exposing a view of the network to applications may pr=
ovide significant improvements in configuration agility, error detection an=
d uptime for operators. However the real value behind central configuration=
 schemes lies within the possible simplification through models provided by=
 such systems to applications and network services running above them (on t=
he so-called northbound side). Well-designed models are able to provide a w=
ide range of granularity for various applications and network services need=
s, from the lower-level physical network to high-level application services=
.

Several organizations outside of the IETF have defined various schemes for =
the configuration of network devices and specific network controllers, but =
none of them offer a vendor-neutral standardized way for applications and n=
etwork services to transmit their needs to network controllers. The SUPA (S=
hared Unified Policy Automation) working group will work on the definition =
of such as standardized interface for applications and network services to =
communicate with network controllers of all types. In particular, SUPA will=
 focus on service specific models that allow applications to request certai=
n network services to be created/deleted/modified. A network service can fo=
r example be a virtual link between two endpoints that uses certain propert=
ies, traffic engineering, implementation of IPv6 transition mechanism and t=
heir enforcement to users.

Each network service can be represented by a service based POLICY model tha=
t can model a group of demands (i.e., actions and constraints) that are bei=
ng initiated by applications that impose similar requirements on the commun=
ication network. The terms "UNIFIED" and "SHARED" used in the SUPA abbrevia=
tion, relate to the way of how the service policy model is generated, since=
 it groups, unifies and shares the similar requirements imposed by a bulk o=
f applications. SUPA will provide guidelines for mechanisms that can dynami=
cally and on an interoperable manner, AUTOMATICALLY map services and polici=
es defined on an abstract topology graph down to more detailed network grap=
hs and specific network management and controlling policies.

Some IETF working groups have started work relating to the description of v=
arious topologies such as I2RS (L3 and routing topologies), ALTO (cost maps=
), SFC (service chain), none of these groups aim (1) at offering truly gene=
ric topology models for the standard northbound interface, and (2) that an =
application can communicate with network boxes, such as network controllers=
, and NEs, developed by different vendors.
SUPA will work on defining vendor-neutral standardized interfaces based on =
the concept of network graph, an entity describing an arbitrary topology of=
 nodes and links at any level of granularity. Such a network graph describe=
s (1) topologies at different levels of abstraction, (2) the relationships =
between the abstraction levels and (3) applied service based policy, which =
are actions and constraints applied on these topologies.
SUPA may also define any mappings to any other network topology data models=
 defined within the IETF.

The main goal of SUPA is to provide service specific models that allow appl=
ications to request network services to be created/deleted/modified. This c=
an be realized by:
  o) model multiple topologies at different levels of abstraction using a n=
etwork graph,
  o) model the relationships between the abstraction levels.
  o) transporting model instances using either NETCONF or RESTCONF

SUPA will ensure that in case any specific NETCONF/RESTCONF protocol requir=
ements are identified, they will be communicated in a timely manner to the =
NETCONF working group. SUPA will consult with the YANG doctors to ensure th=
at data models follow common practices.

Work items for SUPA include:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D
1) The definition of a standardized model for a network graph, using YANG. =
This model may be used to describe topologies at any functional layer, from=
 physical networks to network services.
2) The definition and standardization of a number of basic policy and data =
models using network graphs. These might include, but are not limited to L3=
VPNs, traffic engineering, implementation of IPv6 transition mechanism and =
their enforcement to users.
3) Provide guidelines for mechanisms that can dynamically and on an interop=
erable manner, automatically map services and policies defined on an abstra=
ct topology graph down to more detailed network graphs and specific network=
 management and controlling policies.
4) Guidelines on how to use NETCONF (or RESTCONF) authentication and author=
ization mechanisms to achieve protection and isolation

Deliverables:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
o) Produce an informational RFC "Problem Statement and Use Cases".
o) Produce a standards-track RFC that specifies YANG models for a generic m=
ulti-layer network graph.
o) Produce standards-track RFCs that specify extensions for the generic YAN=
G models defined above for network services that manage virtual links, traf=
fic engineering and implementation of IPv6 transition mechanism and their e=
nforcement to users.
o) Produce an informational RFC that provides the guidelines for mechanisms=
 that can dynamically and on interoperable manner, automatically map servic=
es and policies defined on an abstract topology graph down to more detailed=
 network graphs and specific network management and controlling policies.
o) Produce an informational RFC that provides the guidelines on using NETCO=
NF (or RESTCONF) authentication and authorization mechanisms to achieve sec=
urity protection and isolation' as an Informational RFC.

Milestones:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Dec 2014  Initial "Problem Statement and Use Cases" WG I-D
Feb 2015  Initial "Multi-layer Network Graph YANG Model" WG I-D
Apr 2015  Initial service specific data model WG I-Ds
May 2015  Initial "Mapping Guidelines" WG I-D
Jun 2015  Submit "Problem Statement and Use Cases" I-D to IESG
Jul 2015  Initial "Authentication and Authorization" WG I-D
Sep 2015  Submit "Multi-layer Network Graph YANG Model" I-D to IESG
Nov 2015  Submit service specific data model I-Ds to IESG
Feb 2016  Submit "Mapping Guidelines" I-D to IESG
Apr 2016  Submit "Authentication and Authorization" I-D to IESG




--_000_C5034E44CD620A44971BAAEB372655DC636315LHREML516MBXchina_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi all,


 


We have worked out all comments that we have receive=
d on the previous version of the SUPA charter.


The new version of the charter can be seen below:


 


Best regards,


Georgios


 


 


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D


SUPA (Shared Unified Policy Automation) charter v1.1=
2


Target Area: Operations and Management

 


Description of Working Group:


 


Programmatic ways to configure networks, often calle=
d software-defined, are considered by many network operators in order to sh=
ift the balance in their favor.


Automating the way of exposing a view of the network=
 to applications may provide significant improvements in configuration agil=
ity, error detection and uptime for operators. However the real value behin=
d central configuration schemes lies
 within the possible simplification through models provided by such systems=
 to applications and network services running above them (on the so-called =
northbound side). Well-designed models are able to provide a wide range of =
granularity for various applications
 and network services needs, from the lower-level physical network to high-=
level application services.



 


Several organizations outside of the IETF have defin=
ed various schemes for the configuration of network devices and specific ne=
twork controllers, but none of them offer a vendor-neutral standardized way=
 for applications and network services
 to transmit their needs to network controllers. The SUPA (Shared Unified P=
olicy Automation) working group will work on the definition of such as stan=
dardized interface for applications and network services to communicate wit=
h network controllers of all types.
 In particular, SUPA will focus on service specific models that allow appli=
cations to request certain network services to be created/deleted/modified.=
 A network service can for example be a virtual link between two endpoints =
that uses certain properties, traffic
 engineering, implementation of IPv6 transition mechanism and their enforce=
ment to users.


 


Each network service can be represented by a service=
 based POLICY model that can model a group of demands (i.e., actions and co=
nstraints) that are being initiated by applications that impose similar req=
uirements on the communication network.
 The terms "UNIFIED" and "SHARED" used in the SUPA abbr=
eviation, relate to the way of how the service policy model is generated, s=
ince it groups, unifies and shares the similar requirements imposed by a bu=
lk of applications. SUPA will provide guidelines for
 mechanisms that can dynamically and on an interoperable manner, AUTOMATICA=
LLY map services and policies defined on an abstract topology graph down to=
 more detailed network graphs and specific network management and controlli=
ng policies.


 


Some IETF working groups have started work relating =
to the description of various topologies such as I2RS (L3 and routing topol=
ogies), ALTO (cost maps), SFC (service chain), none of these groups aim (1)=
 at offering truly generic topology
 models for the standard northbound interface, and (2) that an application =
can communicate with network boxes, such as network controllers, and NEs, d=
eveloped by different vendors.


SUPA will work on defining vendor-neutral standardiz=
ed interfaces based on the concept of network graph, an entity describing a=
n arbitrary topology of nodes and links at any level of granularity. Such a=
 network graph describes (1) topologies
 at different levels of abstraction, (2) the relationships between the abst=
raction levels and (3) applied service based policy, which are actions and =
constraints applied on these topologies.



SUPA may also define any mappings to any other netwo=
rk topology data models defined within the IETF.


 


The main goal of SUPA is to provide service specific=
 models that allow applications to request network services to be created/d=
eleted/modified. This can be realized by:


  o) model multiple topologies at different lev=
els of abstraction using a network graph,



  o) model the relationships between the a=
bstraction levels.


  o) transporting model instances using either =
NETCONF or RESTCONF



 


SUPA will ensure that in case any specific NETCONF/R=
ESTCONF protocol requirements are identified, they will be communicated in =
a timely manner to the NETCONF working group. SUPA will consult with the YA=
NG doctors to ensure that data models
 follow common practices.


 


Work items for SUPA include:


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


1) The definition of a standardized model for a netw=
ork graph, using YANG. This model may be used to describe topologies at any=
 functional layer, from physical networks to network services.



2) The definition and standardization of a number of=
 basic policy and data models using network graphs. These might include, bu=
t are not limited to L3VPNs, traffic engineering, implementation of IPv6 tr=
ansition mechanism and their enforcement
 to users.  


3) Provide guidelines for mechanisms that can dynami=
cally and on an interoperable manner, automatically map services and polici=
es defined on an abstract topology graph down to more detailed network grap=
hs and specific network management
 and controlling policies.


4) Guidelines on how to use NETCONF (or RESTCONF) au=
thentication and authorization mechanisms to achieve protection and isolati=
on


 


Deliverables:


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

o) Produce an informational RFC "Problem Statem=
ent and Use Cases".


o) Produce a standards-track RFC that specifies YANG=
 models for a generic multi-layer network graph.


o) Produce standards-track RFCs that specify extensi=
ons for the generic YANG models defined above for network services that man=
age virtual links, traffic engineering and implementation of IPv6 transitio=
n mechanism and their enforcement
 to users.


o) Produce an informational RFC that provides the gu=
idelines for mechanisms that can dynamically and on interoperable manner, a=
utomatically map services and policies defined on an abstract topology grap=
h down to more detailed network graphs
 and specific network management and controlling policies.


o) Produce an informational RFC that provides the gu=
idelines on using NETCONF (or RESTCONF) authentication and authorization me=
chanisms to achieve security protection and isolation' as an Informational =
RFC.


 


Milestones:


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


Dec 2014  Initial "Problem Statement and U=
se Cases" WG I-D


Feb 2015  Initial "Multi-layer Network Gra=
ph YANG Model" WG I-D


Apr 2015  Initial service specific data model W=
G I-Ds 


May 2015  Initial "Mapping Guidelines"=
; WG I-D


Jun 2015  Submit "Problem Statement and Us=
e Cases" I-D to IESG


Jul 2015  Initial "Authentication and Auth=
orization" WG I-D


Sep 2015  Submit "Multi-layer Network Grap=
h YANG Model" I-D to IESG


Nov 2015  Submit service specific data model I-=
Ds to IESG


Feb 2016  Submit "Mapping Guidelines"=
 I-D to IESG


Apr 2016  Submit "Authentication and Autho=
rization" I-D to IESG


 


 


 






--_000_C5034E44CD620A44971BAAEB372655DC636315LHREML516MBXchina_--


From nobody Thu Sep 25 17:50:30 2014
Return-Path: 
X-Original-To: supa@ietfa.amsl.com
Delivered-To: supa@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B34B61A010D for ; Thu, 25 Sep 2014 17:50:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.386
X-Spam-Level: 
X-Spam-Status: No, score=-4.386 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 liMWCOgI4KQU for ; Thu, 25 Sep 2014 17:50: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 56D681A007F for ; Thu, 25 Sep 2014 17:50:16 -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 BNA14807; Fri, 26 Sep 2014 00:50:15 +0000 (GMT)
Received: from szxeml459-hub.china.huawei.com (10.82.67.202) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 26 Sep 2014 01:50:13 +0100
Received: from szxeml557-mbs.china.huawei.com ([169.254.6.57]) by szxeml459-hub.china.huawei.com ([10.82.67.202]) with mapi id 14.03.0158.001; Fri, 26 Sep 2014 08:50:10 +0800
From: Tina TSOU 
To: Benoit Claise 
Thread-Topic: Draft charter v1.12//RE: [Supa] Area hand-off, and some friendly advice ...
Thread-Index: Ac/YtN3WGTuRDclUaESQdripqpP+jQAbsWHg
Date: Fri, 26 Sep 2014 00:50:09 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.66.87.91]
Content-Type: multipart/alternative; boundary="_000_C0E0A32284495243BDE0AC8A066631A81859D0C0szxeml557mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/supa/kIE07ITJ64NQRxGqxfDiEdssfJs
Cc: "supa@ietf.org" 
Subject: [Supa] Draft charter v1.12//RE:  Area hand-off, and some friendly advice ...
X-BeenThere: supa@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Sep 2014 00:50:28 -0000

--_000_C0E0A32284495243BDE0AC8A066631A81859D0C0szxeml557mbschi_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Dear Benoit et al,

Here comes latest version. The list discussion helps a lot to make it clear=
er.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
SUPA (Shared Unified Policy Automation) charter v1.12
Target Area: Operations and Management

Description of Working Group:

Programmatic ways to configure networks, often called software-defined, are=
 considered by many network operators in order to shift the balance in thei=
r favor.
Automating the way of exposing a view of the network to applications may pr=
ovide significant improvements in configuration agility, error detection an=
d uptime for operators. However the real value behind central configuration=
 schemes lies within the possible simplification through models provided by=
 such systems to applications and network services running above them (on t=
he so-called northbound side). Well-designed models are able to provide a w=
ide range of granularity for various applications and network services need=
s, from the lower-level physical network to high-level application services=
.
Several organizations outside of the IETF have defined various schemes for =
the configuration of network devices and specific network controllers, but =
none of them offer a vendor-neutral standardized way for applications and n=
etwork services to transmit their needs to network controllers. The SUPA (S=
hared Unified Policy Automation) working group will work on the definition =
of such as standardized interface for applications and network services to =
communicate with network controllers of all types. In particular, SUPA will=
 focus on service specific models that allow applications to request certai=
n network services to be created/deleted/modified. A network service can fo=
r example be a virtual link between two endpoints that uses certain propert=
ies, traffic engineering, implementation of IPv6 transition mechanism and t=
heir enforcement to users.
Each network service can be represented by a service based POLICY model tha=
t can model a group of demands (i.e., actions and constraints) that are bei=
ng initiated by applications that impose similar requirements on the commun=
ication network. The terms "UNIFIED" and "SHARED" used in the SUPA abbrevia=
tion, relate to the way of how the service policy model is generated, since=
 it groups, unifies and shares the similar requirements imposed by a bulk o=
f applications. SUPA will provide guidelines for mechanisms that can dynami=
cally and on an interoperable manner, AUTOMATICALLY map services and polici=
es defined on an abstract topology graph down to more detailed network grap=
hs and specific network management and controlling policies.
Some IETF working groups have started work relating to the description of v=
arious topologies such as I2RS (L3 and routing topologies), ALTO (cost maps=
), SFC (service chain), none of these groups aim (1) at offering truly gene=
ric topology models for the standard northbound interface, and (2) that an =
application can communicate with network boxes, such as network controllers=
, and NEs, developed by different vendors.
SUPA will work on defining vendor-neutral standardized interfaces based on =
the concept of network graph, an entity describing an arbitrary topology of=
 nodes and links at any level of granularity. Such a network graph describe=
s (1) topologies at different levels of abstraction, (2) the relationships =
between the abstraction levels and (3) applied service based policy, which =
are actions and constraints applied on these topologies. SUPA may also defi=
ne any mappings to any other network topology data models defined within th=
e IETF.
The main goal of SUPA is to provide service specific models that allow appl=
ications to request network services to be created/deleted/modified. This c=
an be realized by:
  o) model multiple topologies at different levels of abstraction using a n=
etwork graph,
  o) model the relationships between the abstraction levels.
  o) transporting model instances using either NETCONF or RESTCONF

SUPA will ensure that in case any specific NETCONF/RESTCONF protocol requir=
ements are identified, they will be communicated in a timely manner to the =
NETCONF working group. SUPA will consult with the YANG doctors to ensure th=
at data models follow common practices.

Work items for SUPA include:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D
1) The definition of a standardized model for a network graph, using YANG. =
This model may be used to describe topologies at any functional layer, from=
 physical networks to network services.
2) The definition and standardization of a number of basic policy and data =
models using network graphs. These might include, but are not limited to L3=
VPNs, traffic engineering, implementation of IPv6 transition mechanism and =
their enforcement to users.
3) Provide guidelines for mechanisms that can dynamically and on an interop=
erable manner, automatically map services and policies defined on an abstra=
ct topology graph down to more detailed network graphs and specific network=
 management and controlling policies.
4) Guidelines on how to use NETCONF (or RESTCONF) authentication and author=
ization mechanisms to achieve protection and isolation

Deliverables:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
o) Produce an informational RFC "Problem Statement and Use Cases".
o) Produce a standards-track RFC that specifies YANG models for a generic m=
ulti-layer network graph.
o) Produce standards-track RFCs that specify extensions for the generic YAN=
G models defined above for network services that manage virtual links, traf=
fic engineering and implementation of IPv6 transition mechanism and their e=
nforcement to users.
o) Produce an informational RFC that provides the guidelines for mechanisms=
 that can dynamically and on interoperable manner, automatically map servic=
es and policies defined on an abstract topology graph down to more detailed=
 network graphs and specific network management and controlling policies.
o) Produce an informational RFC that provides the guidelines on using NETCO=
NF (or RESTCONF) authentication and authorization mechanisms to achieve sec=
urity protection and isolation' as an Informational RFC.

Milestones:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Dec 2014  Initial "Problem Statement and Use Cases" WG I-D
Feb 2015  Initial "Multi-layer Network Graph YANG Model" WG I-D
Apr 2015  Initial service specific data model WG I-Ds
May 2015  Initial "Mapping Guidelines" WG I-D
Jun 2015  Submit "Problem Statement and Use Cases" I-D to IESG
Jul 2015  Initial "Authentication and Authorization" WG I-D
Sep 2015  Submit "Multi-layer Network Graph YANG Model" I-D to IESG
Nov 2015  Submit service specific data model I-Ds to IESG
Feb 2016  Submit "Mapping Guidelines" I-D to IESG
Apr 2016  Submit "Authentication and Authorization" I-D to IESG


Thank you,
Tina

From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Liushucheng (Will)
Sent: Thursday, September 25, 2014 7:36 PM
To: Benoit Claise
Cc: supa@ietf.org
Subject: Re: [Supa] Area hand-off, and some friendly advice ...

Hi Benoit,

Below inline please see two pieces of complementary answer from my team (st=
arts with [Will]). Thank you!

Regards,
Will

From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Georgios Karagiannis
Sent: Wednesday, September 24, 2014 7:30 PM
To: Benoit Claise; Tina TSOU; Juergen Schoenwaelder
Cc: Zhen Cao; supa@ietf.org
Subject: Re: [Supa] Area hand-off, and some friendly advice ...

Hi Benoit,

Thank you for your comments.
Please see in line,

From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Benoit Claise
Sent: Wednesday, September 24, 2014 10:41 AM
To: Georgios Karagiannis; Tina TSOU; Juergen Schoenwaelder
Cc: Zhen Cao; supa@ietf.org
Subject: Re: [Supa] Area hand-off, and some friendly advice ...

Hi Georgios,

Hi Benoit,



Thanks for your comments!

Please see in line.





Georgios: Please note that we are referring to the following figure:

             ---------------------------------------

             | applications                        |

             ---------------------------------------

                       |  <---end use. Appl.   |

             ---------------------             |<---end use. Appl.

             | enhanced OSS      |             |

             ---------------------             |

                      |   <--- network service |

YANG models  /NETCONF interface                |

             --------------------------------------

             |   controller                       |               <---  map=
ping network services

to topology

             --------------------------------------

                 |       |        |                    <---

device/feature specific YANG models / NETCONF interface

             NE1    NE2   NEn
It's not obvious what an "enhanced OSS" is?

Georgios: it relates to the system that runs network services. These servic=
es are enhanced Operational Support System (OSS) like services that help a =
communication service provider to monitor, control, analyze and manage a co=
mmunication network.


Georgios: According to the provided figure: 1) need to work on network serv=
ice Yang models, 2 mapping network services to topology, 3. Device/feature =
specific Yang Models, 4) end user specific Yank Models (out of scope). The =
interface between end user applications and a controller, and interface bet=
ween end user application and enhanced OSS, are also out of scope.
Concerning your last sentence. I'm confused.
What does the following deliverable mean then?

o) specify and standardize how NETCONF/YANG (or RESTCONF/YANG) can be used =
to securely and efficiently distribute up to date (fresh) network graphs be=
tween network service systems and network management and controlling system=
s

It relates to the interface between the network service system (enhanced OS=
S in the above figure.
Please note that we say that we initially only focus on this interface, in =
order to narrow down the scope of this activity

However, if there are supports that think we should initially focus also on=
 the interface between end user application and controller we will also inc=
lude this interface in the scope.



[Will]: First of all, IMOH, the figures from Benoit and Georgios are not in=
compatible. From the perspective of controller, they are different latitude=
s of northband. The application and enhanced OSS in Georgios figure can be =
put together into an larger application* layer of Benoit's figure. The netw=
ork graph is proposed to provide network-wide configuration containing the =
key information for service instances. One example is, for the DDC use case=
, the network graph contains the key information such as the key node infor=
mation of the path and the key requirement of traffic steering.



Regarding to the app, management app, end user app here, I want to add some=
thing related to the history of this work. At the very beginning, when this=
 work is call APONF before Toronto IETF meeting, the end user app is in the=
 scope. However, there are mainly three reasons that we remove this point:

1.      The confliction with AECON, we discussed with proponents of AECON a=
nd to avoid the conflict as at that time they were proposing the interface =
from end user app to network devices. Later in the IESG meeting in Toronto,=
 we successfully clarified the differences and got the suggestion to focus =
on management app.

2.      Lars Eggert showed his concerning about the interface between end u=
ser app and network devices may lead to security issue.  Kostas Pentikousis=
 also mentioned this to me.



However, these are old stories. During the Toronto BoF, someone also sugges=
ted us re-put the end user app into cope. A large app layer containing both=
 end user app and management app may replace the first two layers in the ol=
d 4 layers figure. Here, my question is, are you in favor of adding end use=
r app into SUPA scope or not?





Regarding your comment, " I'm not convinced we could standardize them, as t=
hey are operators specific, and will be evolving along the time. There are =
many different ways to configure a VPN, for example." Were you referring to=
:

3. Device/feature specific Yang Models?
No, the service YANG models

Georgios: I see, but we can work on YANG models that can be used for a numb=
er of main network services, which are essential for operators and that the=
y would like to have them standardized.






See in-line

Dear all,



Hope this version of draft charter address most of the comments from the li=
st.



------









In particular, as starting point, SUPA will only focus on network services,=
 which are enhanced Operational Support System (OSS) like services that hel=
p a communication service provider to monitor, control, analyze and manage =
a communication network. The systems that are runniung such network service=
s are denoted in this document as Network Service Systems.

Each network service can be represented by a classified application based P=
OLICY model, since it can model the group of demands which are SHARED and U=
NIFIED and are coming from a bundle of applications that impose similar req=
uirements on the communication network.

I'm afraid I don't understand (like J=FCrgen)



Georgios: What we want to say is that there are applications that impose si=
milar requirements on the communication network. For each group of such bul=
k of applications a network service can be defined that can be represented =
by a service policy model (i.e., its actions and constraints).





Georgios: Thanks for the suggestion, the text needs to be rephrased, see be=
low:

Each network service can be represented by an application based POLICY mode=
l, which is UNIFIED and SHARED, since it can model the group of demands (i.=
e, actions and constraints) that are coming from a bundle of applications t=
hat impose similar requirements on the communication network.
I still don't understand. what "UNIFIED and SHARED" mean.

Georgios: the terms "UNIFIED" and "SHARED"" relate to the way of how the se=
rvice policy model is generated, since it groups and it unifies and shares =
the similar requirements imposed by a bulk of applications.









(2) transporting model instances either using NETCONF or RESTCONF and (3) p=
roviding guidelines on AUTOMATICALLY mapping policies to attributes of the =
network graphs.



Although some IETF working groups have started work relating to the descrip=
tion of various topologies such as I2RS (L3and routing topologies), ALTO (c=
ost maps), SFC (service chain), none of these groups aim at offering truly =
generic topology models for the standard northbound interface.

SUPA will work on defining interfaces based on the concept of network graph=
, an entity describing an arbitrary topology of nodes and links at any leve=
l of granularity. Such a graph may describe, for example, a physical topolo=
gy, a service topology or the relationships between datacenters. Any networ=
k topology data models or policy models that have been defined (or are bein=
g defined) within the IETF will be reused in SUPA as much as possible.

In addition to the above, policies may be defined and applied to a network =
graph. These application based policies are actions or constraints generate=
d by Network Service Systems. They are then mapped from the network graph i=
nstance into specific network management policies toward network components=
.





Georgios: the above text is not clear. Therefore, I am rephrasing it:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

The main goal of SUPA is to provide application based policies and means to=
 model and program the abstract view of network infrastructure and service =
function interdependencies in order to support and AUTOMATICALLY feed netwo=
rk management and controlling policies. This can be realized by:



(1) modeling the network graph, which among others include policy models, d=
ata models and application based policies, using YANG,



(2) applying NETCONF (or RESTCONF) to enable dissemination of up to date (f=
resh) network graphs in a secure and efficient manner between network servi=
ce systems and network management and controlling systems,
"between network service systems and network management and controlling sys=
tem". What are those? I don't see them in your figure.
Also, why should all of these need to know about the topology?

Georgios: In the figure, the enhanced OSS represents the network service sy=
stem and the controller represents the network management and controlling s=
ystem.
In this context, network services can be used to provide the required  conf=
iguration and application programming interfaces to service developers. Sub=
sequently, a network service can use the application based demands (for act=
ions and constraints) and possibly update its associated network service  a=
ttributes. Examples of network services that can modify  the network servic=
e attributes are for example, L3VPN configuration and IPv6 transitions.
For each network service instance a network graph needs to be generated and=
 maintained.
The up to date network graph needs to (1) be communicated between the  netw=
ork service systems and the network   management and controlling systems, (=
2) map the attributes of the network service graph into specific network ma=
nagement policies.
[Will] To modeling service requirement and create service instances, APP ne=
eds a view of topology to form network configuration according to the key i=
nformation of devices topology. This configuration is eventually mapped to =
the selected network devices according to topology provided by SUPA.

Best regards,
Georgios





Regards, Benoit

--_000_C0E0A32284495243BDE0AC8A066631A81859D0C0szxeml557mbschi_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Dear Benoit et al,


 


Here comes latest version. The list discussion helps a l=
ot to make it clearer.


 


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D


SUPA (Shared Unified Policy Automation) charter v1.12


Target Area: Operations and Management=



 


Description of Working Group:


 


Programmatic ways to configure networks, often called so=
ftware-defined, are considered by many network operators in
 order to shift the balance in their favor.


Automating the way of exposing a view of the network to =
applications may provide significant improvements in configuration
 agility, error detection and uptime for operators. However the real value =
behind central configuration schemes lies within the possible simplificatio=
n through models provided by such systems to applications and network servi=
ces running above them (on the so-called
 northbound side). Well-designed models are able to provide a wide range of=
 granularity for various applications and network services needs, from the =
lower-level physical network to high-level application services.



Several organizations outside of the IETF have defined v=
arious schemes for the configuration of network devices and
 specific network controllers, but none of them offer a vendor-neutral stan=
dardized way for applications and network services to transmit their needs =
to network controllers. The SUPA (Shared Unified Policy Automation) working=
 group will work on the definition
 of such as standardized interface for applications and network services to=
 communicate with network controllers of all types. In particular, SUPA wil=
l focus on service specific models that allow applications to request certa=
in network services to be created/deleted/modified.
 A network service can for example be a virtual link between two endpoints =
that uses certain properties, traffic engineering, implementation of IPv6 t=
ransition mechanism and their enforcement to users.


Each network service can be represented by a service bas=
ed POLICY model that can model a group of demands (i.e., actions
 and constraints) that are being initiated by applications that impose simi=
lar requirements on the communication network. The terms "UNIFIED"=
; and "SHARED" used in the SUPA abbreviation, relate to the way o=
f how the service policy model is generated, since it
 groups, unifies and shares the similar requirements imposed by a bulk of a=
pplications. SUPA will provide guidelines for mechanisms that can dynamical=
ly and on an interoperable manner, AUTOMATICALLY map services and policies =
defined on an abstract topology
 graph down to more detailed network graphs and specific network management=
 and controlling policies.


Some IETF working groups have started work relating to t=
he description of various topologies such as I2RS (L3 and routing
 topologies), ALTO (cost maps), SFC (service chain), none of these groups a=
im (1) at offering truly generic topology models for the standard northboun=
d interface, and (2) that an application can communicate with network boxes=
, such as network controllers, and
 NEs, developed by different vendors.


SUPA will work on defining vendor-neutral standardized i=
nterfaces based on the concept of network graph, an entity describing
 an arbitrary topology of nodes and links at any level of granularity. Such=
 a network graph describes (1) topologies at different levels of abstractio=
n, (2) the relationships between the abstraction levels and (3) applied ser=
vice based policy, which are actions
 and constraints applied on these topologies. SUPA may also define any mapp=
ings to any other network topology data models defined within the IETF.


The main goal of SUPA is to provide service specific mod=
els that allow applications to request network services to be
 created/deleted/modified. This can be realized by:


  o) model multiple topologies at different levels =
of abstraction using a network graph,



  o) model the relationships between the abstr=
action levels.


  o) transporting model instances using either NETC=
ONF or RESTCONF



 


SUPA will ensure that in case any specific NETCONF/RESTC=
ONF protocol requirements are identified, they will be communicated
 in a timely manner to the NETCONF working group. SUPA will consult with th=
e YANG doctors to ensure that data models follow common practices.


 


Work items for SUPA include:


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


1) The definition of a standardized model for a network =
graph, using YANG. This model may be used to describe topologies
 at any functional layer, from physical networks to network services. =



2) The definition and standardization of a number of bas=
ic policy and data models using network graphs. These might
 include, but are not limited to L3VPNs, traffic engineering, implementatio=
n of IPv6 transition mechanism and their enforcement to users. 



3) Provide guidelines for mechanisms that can dynamicall=
y and on an interoperable manner, automatically map services
 and policies defined on an abstract topology graph down to more detailed n=
etwork graphs and specific network management and controlling policies.


4) Guidelines on how to use NETCONF (or RESTCONF) authen=
tication and authorization mechanisms to achieve protection
 and isolation


 


Deliverables:


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


o) Produce an informational RFC "Problem Statement =
and Use Cases".


o) Produce a standards-track RFC that specifies YANG mod=
els for a generic multi-layer network graph.


o) Produce standards-track RFCs that specify extensions =
for the generic YANG models defined above for network services
 that manage virtual links, traffic engineering and implementation of IPv6 =
transition mechanism and their enforcement to users.


o) Produce an informational RFC that provides the guidel=
ines for mechanisms that can dynamically and on interoperable
 manner, automatically map services and policies defined on an abstract top=
ology graph down to more detailed network graphs and specific network manag=
ement and controlling policies.


o) Produce an informational RFC that provides the guidel=
ines on using NETCONF (or RESTCONF) authentication and authorization
 mechanisms to achieve security protection and isolation' as an Information=
al RFC.


 


Milestones:


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


Dec 2014  Initial "Problem Statement and Use C=
ases" WG I-D


Feb 2015  Initial "Multi-layer Network Graph Y=
ANG Model" WG I-D


Apr 2015  Initial service specific data model WG I-=
Ds



May 2015  Initial "Mapping Guidelines" WG=
 I-D


Jun 2015  Submit "Problem Statement and Use Ca=
ses" I-D to IESG


Jul 2015  Initial "Authentication and Authoriz=
ation" WG I-D


Sep 2015  Submit "Multi-layer Network Graph YA=
NG Model" I-D to IESG


Nov 2015  Submit service specific data model I-Ds t=
o IESG


Feb 2016  Submit "Mapping Guidelines" I-D=
 to IESG


Apr 2016  Submit "Authentication and Authoriza=
tion" I-D to IESG


 



 


Thank you,


Tina


<=
o:p> 






From:=
 Supa [mailto:supa-b=
ounces@ietf.org]
On Behalf Of Liushucheng (Will)

Sent: Thursday, September 25, 2014 7:36 PM

To: Benoit Claise

Cc: supa@ietf.org

Subject: Re: [Supa] Area hand-off, and some friendly advice ...=







 


Hi Benoit,=



 


Below inli=
ne please see two pieces of complementary answer from my team (starts with
[Will]). Thank you!


 




Regards,


Will




 








From:
 Supa [mailto:supa-bounces@ietf.or=
g] 
On Behalf Of Georgios Karagiannis

Sent: Wednesday, September 24, 2014 7:30 PM

To: Benoit Claise; Tina TSOU; Juergen Schoenwaelder

Cc: Zhen Cao; supa@ietf.org

Subject: Re: [Supa] Area hand-off, and some friendly advice ...=







 


Hi Benoit,=



 


Thank you for your comments.=



Please see in line,


 






From:
 Supa [mailto:supa-bounces@ietf.or=
g] 
On Behalf Of Benoit Claise

Sent: Wednesday, September 24, 2014 10:41 AM

To: Georgios Karagiannis; Tina TSOU; Juergen Schoenwaelder

Cc: Zhen Cao; supa@ietf.org

Subject: Re: [Supa] Area hand-off, and some friendly advice ...=







 




Hi Georgios,






Hi B=
enoit,


 


Than=
ks for your comments!


Plea=
se see in line.


 


 


Geor=
gios: Please note that we are referring to the following figure:=



&nbs=
p;            ------=
---------------------------------  


&nbs=
p;            |=
 applications          &n=
bsp;            =
; |


&nbs=
p;            ------=
---------------------------------


&nbs=
p;            &=
nbsp;         |  <---end us=
e. Appl.   |


&nbs=
p;            ------=
---------------          =
   |<---end use. Appl.   


&nbs=
p;            |=
 enhanced OSS      |     =
        |


&nbs=
p;            ------=
---------------          =
   |


&nbs=
p;             =
        |   <--- netwo=
rk service |


YANG=
 models  /NETCONF interface       &=
nbsp;        |


&nbs=
p;            ------=
--------------------------------


&nbs=
p;            | =
;  controller         &nb=
sp;            =
 |            &=
nbsp;  <---  mapping network services 


to t=
opology


&nbs=
p;            ------=
--------------------------------


&nbs=
p;            &=
nbsp;   |       |   =
     |        &=
nbsp;           <--- <=
o:p>


devi=
ce/feature specific YANG models / NETCONF interface


&nbs=
p;            NE1&nb=
sp;   NE2   NEn




It's not obvious what an "enhanced OSS"=
 is?<=
/p>

 


Georgios: it relates to the =
system that runs network services. These services are enhanced
 Operational Support System (OSS) like services that help a communication s=
ervice provider to monitor, control, analyze and manage a communication net=
work.




 


Geor=
gios: According to the provided figure: 1) need to work on network service =
Yang models, 2 mapping network services to topology, 3. Device/feature spec=
ific Yang Models, 4) end user specific Yank Models (out of scope). The inte=
rface between end user applications and a controller, and interface between=
 end user application and enhanced OSS, are also out of scope.


Concerning your last sentence. I'm confused.

What does the following deliverable mean then?


o) s=
pecify and standardize how NETCONF/YANG (or RESTCONF/YANG) can be used to s=
ecurely and efficiently distribute up to date (fresh) network graphs betwee=
n network service systems and network management and controlling systems


 <=
/p>

It relates to the interface =
between the network service system (enhanced OSS in the above
 figure.


Please note that we say that=
 we initially only focus on this interface, in order to narrow
 down the scope of this activity


 


However, if there are suppor=
ts that think we should initially focus also on the interface
 between end user application and controller we will also include this inte=
rface in the scope.


 


[Will]: First of all, IMOH, the figures =
from Benoit and Georgios are not incompatible. From the perspective of cont=
roller, they are different latitudes of northband. The application and enhanced OSS in Georgios fig=
ure can be put together into an larger application* layer of Benoit’s=
 figure. The network graph is proposed to provide network-wide configuratio=
n containing the key information for service instances. One example is, for=
 the DDC use case, the network graph contains the key information such as t=
he key node information of the path and the key requirement of traffic stee=
ring. 


 


Regarding to the app, management app, en=
d user app here, I want to add something related to the history of this wor=
k. At the very beginning, when this work is call APONF before Toronto IETF =
meeting, the end user app is in the scope. However, there are mainly three =
reasons that we remove this point:


1.=
  =
;    The confliction with AECON, we discussed with proponents of AECON a=
nd to avoid the conflict as at that time they were proposing the interface =
from end user app to network devices. Later in the IESG meeting in Toronto,=
 we successfully clarified the differences and got the suggestion to focus =
on management app.


2.=
  =
;    Lars Eggert showed his concerning about the interface between end u=
ser app and network devices may lead to security issue.  Kostas Pentik=
ousis also mentioned this to me. 


 


However, these are old stories. During t=
he Toronto BoF, someone also suggested us re-put the end user app into cope=
. A large app layer containing both end user app and management app may rep=
lace the first two layers in the old 4 layers figure. Here, my question is,=
 are you in favor of adding end user app into SUPA scope or not?=



 


 


Rega=
rding your comment, " I'm not convinced we could standardize them, as =
they are operators specific, and will be evolving along the time. There are=
 many different ways to configure a VPN, for example." Were you referr=
ing to:


3. D=
evice/feature specific Yang Models?


No, the service YANG models



 


Georgios: I see, but we can =
work on YANG models that can be used for a number of main network
 services, which are essential for operators and that they would like to ha=
ve them standardized.


 


 


 




See =
in-line


Dear=
 all,


 


Hope=
 this version of draft charter address most of the comments from the list.<=
o:p>


 


----=
--


 


 


 


 






In p=
articular, as starting point, SUPA will only focus on network services, whi=
ch are enhanced Operational Support System (OSS) like services that help a =
communication service provider to monitor, control, analyze and manage a co=
mmunication network. The systems that are runniung such network services ar=
e denoted in this document as Network Service Systems.

Each=
 network service can be represented by a classified application based POLIC=
Y model, since it can model the group of demands which are SHARED and UNIFI=
ED and are coming from a bundle of applications that impose similar require=
ments on the communication network.




I'm =
afraid I don't understand (like J=FCrgen)


 


Georgios: What we want to say is that there ar=
e applications that impose similar requirements on the communication networ=
k. For each group of such bulk of applications a network service can be def=
ined that can be represented by a service policy model (i.e., its actions a=
nd constraints).


 


 


Geor=
gios: Thanks for the suggestion, the text needs to be rephrased, see below:=



Each=
 network service can be represented by an application based POLICY model, w=
hich is UNIFIED and SHARED, since it can model the group of demands (i.e, a=
ctions and constraints) that are coming from a bundle of applications that =
impose similar requirements on the communication network.=



I still don't understand. what "UNIFIED=
 and SHARED" mean.=



 


Georgios: the terms “U=
NIFIED” and “SHARED”” relate to the way of how the =
service policy
 model is generated, since it groups and it unifies and shares the similar =
requirements imposed by a bulk of applications.


 


 


 


 


 



 


 




(2) =
transporting model instances either using NETCONF or RESTCONF and (3) provi=
ding guidelines on AUTOMATICALLY mapping policies to attributes of the netw=
ork graphs.


 


Alth=
ough some IETF working groups have started work relating to the description=
 of various topologies such as I2RS (L3and routing topologies), ALTO (cost =
maps), SFC (service chain), none of these groups aim at offering truly gene=
ric topology models for the standard northbound interface.


SUPA=
 will work on defining interfaces based on the concept of network graph, an=
 entity describing an arbitrary topology of nodes and links at any level of=
 granularity. Such a graph may describe, for example, a physical topology, =
a service topology or the relationships between datacenters. Any network to=
pology data models or policy models that have been defined (or are being de=
fined) within the IETF will be reused in SUPA as much as possible.


In a=
ddition to the above, policies may be defined and applied to a network grap=
h. These application based policies are actions or constraints generated by=
 Network Service Systems. They are then mapped from the network graph insta=
nce into specific network management policies toward network components.




 


 


Geor=
gios: the above text is not clear. Therefore, I am rephrasing it:


=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=



The =
main goal of SUPA is to provide application based policies and means to mod=
el and program the abstract view of network infrastructure and service func=
tion interdependencies in order to support and AUTOMATICALLY feed network m=
anagement and controlling policies. This can be realized by:


 


(1) =
modeling the network graph, which among others include policy models, data =
models and application based policies, using YANG, 


 


(2) =
applying NETCONF (or RESTCONF) to enable dissemination of up to date (fresh=
) network graphs in a secure and efficient manner between network service s=
ystems and network management and controlling systems, 


"between network service systems and network mana=
gement and controlling system". What are those? I don't see them in yo=
ur figure.

Also, why should all of these need to know about the topology?



 



Georgios: In the figure, the enha=
nced OSS represents the network service system and the controller represent=
s the network management and controlling system.



In this context, network services=
 can be used to provide the required  configuration and application pr=
ogramming interfaces to service developers. Subsequently, a network
 service can use the application based demands (for actions and constraints=
) and possibly update its associated network service  attributes. Exam=
ples of network services that can modify  the network service attribut=
es are for example, L3VPN configuration and
 IPv6 transitions. 



For each network service instance=
 a network graph needs to be generated and maintained.




The up to date network graph need=
s to (1) be communicated between the  network service systems and the =
network   management and controlling systems, (2) map the attribu=
tes
 of the network service graph into specific network management policies.



[Will] To modeling service =
requirement and create service instances, APP needs a view of topology to f=
orm network configuration according to the key information
 of devices topology. This configuration is eventually mapped to the select=
ed network devices according to topology provided by SUPA.



 



Best regards,



Georgios



 



 



 







Regards, Benoit








--_000_C0E0A32284495243BDE0AC8A066631A81859D0C0szxeml557mbschi_--


From nobody Thu Sep 25 18:05:24 2014
Return-Path: 
X-Original-To: supa@ietfa.amsl.com
Delivered-To: supa@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E590A1A0258 for ; Thu, 25 Sep 2014 18:05:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.386
X-Spam-Level: 
X-Spam-Status: No, score=-4.386 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 iyRntSk_DD8Q for ; Thu, 25 Sep 2014 18:05: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 E531A1A01F9 for ; Thu, 25 Sep 2014 18:05:16 -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 BJY01633; Fri, 26 Sep 2014 01:05:15 +0000 (GMT)
Received: from SZXEML419-HUB.china.huawei.com (10.82.67.158) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 26 Sep 2014 02:05:14 +0100
Received: from szxeml557-mbs.china.huawei.com ([169.254.6.57]) by szxeml419-hub.china.huawei.com ([10.82.67.158]) with mapi id 14.03.0158.001; Fri, 26 Sep 2014 09:05:00 +0800
From: Tina TSOU 
To: Georgios Karagiannis , "supa@ietf.org" 
Thread-Topic: New SUPA charter
Thread-Index: Ac/ZIUcaEK+SU+lYTNqeRV6T6bQAHwABFarw
Date: Fri, 26 Sep 2014 01:05:00 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.66.87.91]
Content-Type: multipart/alternative; boundary="_000_C0E0A32284495243BDE0AC8A066631A81859D1F3szxeml557mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/supa/joMXkOptS1u93OzLkVnzBVocCRo
Subject: Re: [Supa] New SUPA charter
X-BeenThere: supa@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Sep 2014 01:05:22 -0000

--_000_C0E0A32284495243BDE0AC8A066631A81859D1F3szxeml557mbschi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Dear all,

Sorry for confusion. The version Georgios and I sent out just now are the s=
ame, it came out of yesterday's (today's) group online discussion meeting.


Thank you,
Tina

From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Georgios Karagiannis
Sent: Friday, September 26, 2014 8:32 AM
To: supa@ietf.org
Subject: [Supa] New SUPA charter

Hi all,

We have worked out all comments that we have received on the previous versi=
on of the SUPA charter.
The new version of the charter can be seen below:

Best regards,
Georgios


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
SUPA (Shared Unified Policy Automation) charter v1.12
Target Area: Operations and Management

Description of Working Group:

Programmatic ways to configure networks, often called software-defined, are=
 considered by many network operators in order to shift the balance in thei=
r favor.
Automating the way of exposing a view of the network to applications may pr=
ovide significant improvements in configuration agility, error detection an=
d uptime for operators. However the real value behind central configuration=
 schemes lies within the possible simplification through models provided by=
 such systems to applications and network services running above them (on t=
he so-called northbound side). Well-designed models are able to provide a w=
ide range of granularity for various applications and network services need=
s, from the lower-level physical network to high-level application services=
.

Several organizations outside of the IETF have defined various schemes for =
the configuration of network devices and specific network controllers, but =
none of them offer a vendor-neutral standardized way for applications and n=
etwork services to transmit their needs to network controllers. The SUPA (S=
hared Unified Policy Automation) working group will work on the definition =
of such as standardized interface for applications and network services to =
communicate with network controllers of all types. In particular, SUPA will=
 focus on service specific models that allow applications to request certai=
n network services to be created/deleted/modified. A network service can fo=
r example be a virtual link between two endpoints that uses certain propert=
ies, traffic engineering, implementation of IPv6 transition mechanism and t=
heir enforcement to users.

Each network service can be represented by a service based POLICY model tha=
t can model a group of demands (i.e., actions and constraints) that are bei=
ng initiated by applications that impose similar requirements on the commun=
ication network. The terms "UNIFIED" and "SHARED" used in the SUPA abbrevia=
tion, relate to the way of how the service policy model is generated, since=
 it groups, unifies and shares the similar requirements imposed by a bulk o=
f applications. SUPA will provide guidelines for mechanisms that can dynami=
cally and on an interoperable manner, AUTOMATICALLY map services and polici=
es defined on an abstract topology graph down to more detailed network grap=
hs and specific network management and controlling policies.

Some IETF working groups have started work relating to the description of v=
arious topologies such as I2RS (L3 and routing topologies), ALTO (cost maps=
), SFC (service chain), none of these groups aim (1) at offering truly gene=
ric topology models for the standard northbound interface, and (2) that an =
application can communicate with network boxes, such as network controllers=
, and NEs, developed by different vendors.
SUPA will work on defining vendor-neutral standardized interfaces based on =
the concept of network graph, an entity describing an arbitrary topology of=
 nodes and links at any level of granularity. Such a network graph describe=
s (1) topologies at different levels of abstraction, (2) the relationships =
between the abstraction levels and (3) applied service based policy, which =
are actions and constraints applied on these topologies.
SUPA may also define any mappings to any other network topology data models=
 defined within the IETF.

The main goal of SUPA is to provide service specific models that allow appl=
ications to request network services to be created/deleted/modified. This c=
an be realized by:
  o) model multiple topologies at different levels of abstraction using a n=
etwork graph,
  o) model the relationships between the abstraction levels.
  o) transporting model instances using either NETCONF or RESTCONF

SUPA will ensure that in case any specific NETCONF/RESTCONF protocol requir=
ements are identified, they will be communicated in a timely manner to the =
NETCONF working group. SUPA will consult with the YANG doctors to ensure th=
at data models follow common practices.

Work items for SUPA include:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D
1) The definition of a standardized model for a network graph, using YANG. =
This model may be used to describe topologies at any functional layer, from=
 physical networks to network services.
2) The definition and standardization of a number of basic policy and data =
models using network graphs. These might include, but are not limited to L3=
VPNs, traffic engineering, implementation of IPv6 transition mechanism and =
their enforcement to users.
3) Provide guidelines for mechanisms that can dynamically and on an interop=
erable manner, automatically map services and policies defined on an abstra=
ct topology graph down to more detailed network graphs and specific network=
 management and controlling policies.
4) Guidelines on how to use NETCONF (or RESTCONF) authentication and author=
ization mechanisms to achieve protection and isolation

Deliverables:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
o) Produce an informational RFC "Problem Statement and Use Cases".
o) Produce a standards-track RFC that specifies YANG models for a generic m=
ulti-layer network graph.
o) Produce standards-track RFCs that specify extensions for the generic YAN=
G models defined above for network services that manage virtual links, traf=
fic engineering and implementation of IPv6 transition mechanism and their e=
nforcement to users.
o) Produce an informational RFC that provides the guidelines for mechanisms=
 that can dynamically and on interoperable manner, automatically map servic=
es and policies defined on an abstract topology graph down to more detailed=
 network graphs and specific network management and controlling policies.
o) Produce an informational RFC that provides the guidelines on using NETCO=
NF (or RESTCONF) authentication and authorization mechanisms to achieve sec=
urity protection and isolation' as an Informational RFC.

Milestones:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Dec 2014  Initial "Problem Statement and Use Cases" WG I-D
Feb 2015  Initial "Multi-layer Network Graph YANG Model" WG I-D
Apr 2015  Initial service specific data model WG I-Ds
May 2015  Initial "Mapping Guidelines" WG I-D
Jun 2015  Submit "Problem Statement and Use Cases" I-D to IESG
Jul 2015  Initial "Authentication and Authorization" WG I-D
Sep 2015  Submit "Multi-layer Network Graph YANG Model" I-D to IESG
Nov 2015  Submit service specific data model I-Ds to IESG
Feb 2016  Submit "Mapping Guidelines" I-D to IESG
Apr 2016  Submit "Authentication and Authorization" I-D to IESG




--_000_C0E0A32284495243BDE0AC8A066631A81859D1F3szxeml557mbschi_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable













Dear al=
l,


&n=
bsp;


Sorry f=
or confusion. The version Georgios and I sent out just now are the same, it=
 came out of yesterday’s (today’s) group
 online discussion meeting.


&n=
bsp;


&n=
bsp;


Thank you,


Tina




 <=
/span>






From: Supa [mailto:supa-bounces@ietf.org]
On Behalf Of Georgios Karagiannis

Sent: Friday, September 26, 2014 8:32 AM

To: supa@ietf.org

Subject: [Supa] New SUPA charter






 


Hi all,


 


We have worked out all comments=
 that we have received on the previous version of the SUPA charter.


The new version of the charter =
can be seen below:


 


Best regards,=



Georgios


 


 


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


SUPA (Shared Unified Policy Aut=
omation) charter v1.12


Target Area: Operations and Man=
agement


 


Description of Working Group:


 


Programmatic ways to configure =
networks, often called software-defined, are considered by many network ope=
rators in order to shift the balance in their favor.


Automating the way of exposing =
a view of the network to applications may provide significant improvements =
in configuration agility, error detection and uptime for operators. However=
 the real value behind central configuration
 schemes lies within the possible simplification through models provided by=
 such systems to applications and network services running above them (on t=
he so-called northbound side). Well-designed models are able to provide a w=
ide range of granularity for various
 applications and network services needs, from the lower-level physical net=
work to high-level application services.



 


Several organizations outside o=
f the IETF have defined various schemes for the configuration of network de=
vices and specific network controllers, but none of them offer a vendor-neu=
tral standardized way for applications
 and network services to transmit their needs to network controllers. The S=
UPA (Shared Unified Policy Automation) working group will work on the defin=
ition of such as standardized interface for applications and network servic=
es to communicate with network controllers
 of all types. In particular, SUPA will focus on service specific models th=
at allow applications to request certain network services to be created/del=
eted/modified. A network service can for example be a virtual link between =
two endpoints that uses certain
 properties, traffic engineering, implementation of IPv6 transition mechani=
sm and their enforcement to users.


 


Each network service can be rep=
resented by a service based POLICY model that can model a group of demands =
(i.e., actions and constraints) that are being initiated by applications th=
at impose similar requirements on the
 communication network. The terms "UNIFIED" and "SHARED"=
; used in the SUPA abbreviation, relate to the way of how the service polic=
y model is generated, since it groups, unifies and shares the similar requi=
rements imposed by a bulk of applications. SUPA will
 provide guidelines for mechanisms that can dynamically and on an interoper=
able manner, AUTOMATICALLY map services and policies defined on an abstract=
 topology graph down to more detailed network graphs and specific network m=
anagement and controlling policies.


 


Some IETF working groups have s=
tarted work relating to the description of various topologies such as I2RS =
(L3 and routing topologies), ALTO (cost maps), SFC (service chain), none of=
 these groups aim (1) at offering truly
 generic topology models for the standard northbound interface, and (2) tha=
t an application can communicate with network boxes, such as network contro=
llers, and NEs, developed by different vendors.


SUPA will work on defining vend=
or-neutral standardized interfaces based on the concept of network graph, a=
n entity describing an arbitrary topology of nodes and links at any level o=
f granularity. Such a network graph
 describes (1) topologies at different levels of abstraction, (2) the relat=
ionships between the abstraction levels and (3) applied service based polic=
y, which are actions and constraints applied on these topologies.



SUPA may also define any mappin=
gs to any other network topology data models defined within the IETF.<=
/o:p>


 


The main goal of SUPA is to pro=
vide service specific models that allow applications to request network ser=
vices to be created/deleted/modified. This can be realized by:


  o) model multiple topolo=
gies at different levels of abstraction using a network graph,



  o) model the relati=
onships between the abstraction levels.


  o) transporting model in=
stances using either NETCONF or RESTCONF



 


SUPA will ensure that in case a=
ny specific NETCONF/RESTCONF protocol requirements are identified, they wil=
l be communicated in a timely manner to the NETCONF working group. SUPA wil=
l consult with the YANG doctors to ensure
 that data models follow common practices.


 


Work items for SUPA include:


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

1) The definition of a standard=
ized model for a network graph, using YANG. This model may be used to descr=
ibe topologies at any functional layer, from physical networks to network s=
ervices.



2) The definition and standardi=
zation of a number of basic policy and data models using network graphs. Th=
ese might include, but are not limited to L3VPNs, traffic engineering, impl=
ementation of IPv6 transition mechanism
 and their enforcement to users.  


3) Provide guidelines for mecha=
nisms that can dynamically and on an interoperable manner, automatically ma=
p services and policies defined on an abstract topology graph down to more =
detailed network graphs and specific
 network management and controlling policies.


4) Guidelines on how to use NET=
CONF (or RESTCONF) authentication and authorization mechanisms to achieve p=
rotection and isolation


 


Deliverables:=



=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D


o) Produce an informational RFC=
 "Problem Statement and Use Cases".


o) Produce a standards-track RF=
C that specifies YANG models for a generic multi-layer network graph.<=
/o:p>


o) Produce standards-track RFCs=
 that specify extensions for the generic YANG models defined above for netw=
ork services that manage virtual links, traffic engineering and implementat=
ion of IPv6 transition mechanism and
 their enforcement to users.


o) Produce an informational RFC=
 that provides the guidelines for mechanisms that can dynamically and on in=
teroperable manner, automatically map services and policies defined on an a=
bstract topology graph down to more
 detailed network graphs and specific network management and controlling po=
licies.


o) Produce an informational RFC=
 that provides the guidelines on using NETCONF (or RESTCONF) authentication=
 and authorization mechanisms to achieve security protection and isolation'=
 as an Informational RFC.


 


Milestones:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D


Dec 2014  Initial "Pr=
oblem Statement and Use Cases" WG I-D


Feb 2015  Initial "Mu=
lti-layer Network Graph YANG Model" WG I-D


Apr 2015  Initial service =
specific data model WG I-Ds



May 2015  Initial "Ma=
pping Guidelines" WG I-D


Jun 2015  Submit "Pro=
blem Statement and Use Cases" I-D to IESG


Jul 2015  Initial "Au=
thentication and Authorization" WG I-D


Sep 2015  Submit "Mul=
ti-layer Network Graph YANG Model" I-D to IESG


Nov 2015  Submit service s=
pecific data model I-Ds to IESG


Feb 2016  Submit "Map=
ping Guidelines" I-D to IESG


Apr 2016  Submit "Aut=
hentication and Authorization" I-D to IESG


 


 


 






--_000_C0E0A32284495243BDE0AC8A066631A81859D1F3szxeml557mbschi_--


From nobody Thu Sep 25 19:05:09 2014
Return-Path: 
X-Original-To: supa@ietfa.amsl.com
Delivered-To: supa@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D67C1A031D for ; Thu, 25 Sep 2014 19:05:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level: 
X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_14=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 yNRONQlin6uO for ; Thu, 25 Sep 2014 19:05:03 -0700 (PDT)
Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA8691A0334 for ; Thu, 25 Sep 2014 19:05:03 -0700 (PDT)
Received: by mail-ie0-f176.google.com with SMTP id ar1so15065077iec.35 for ; Thu, 25 Sep 2014 19:05:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=6+qC9fcuiNVePdQCdDGTKxQT3miRuIpyoT02/c7kqPY=; b=MEmdAXmoRDwgr0RQGCIiTaOcn847U7vlmcm7PVnTo5XfOJq4wdyYMy0Ikn4PfTQzCY QJxjRm9yDlRojlTFqpBa7q/kLNqymTm4e5GbFyflv7cIe8R3xQtPDfgpJ5verkqFBQb7 /bSZ4aOn2fJSgCKLBMlai/ekMY10WpBMg+94GhNEYEz3K3EA3grWZpvcV23HS08Xw0p5 lwHTFjtFkRibIkPSv+Q/iEdEiMba5ceenbNRRLpNX5Fbdv4xYQImJEDHwKghEjdlfCQ3 hEbuUcWikVA8fq1c5/2M9C4KH6QXV2rycpyA6VFXe4K3l5Ac8HjqAceSZAVjCqQ2G/f6 LOtQ==
X-Received: by 10.42.101.77 with SMTP id d13mr16727233ico.53.1411697103161; Thu, 25 Sep 2014 19:05:03 -0700 (PDT)
Received: from [192.168.0.103] (dsl-173-206-87-185.tor.primus.ca. [173.206.87.185]) by mx.google.com with ESMTPSA id z5sm680606igl.21.2014.09.25.19.05.02 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 25 Sep 2014 19:05:02 -0700 (PDT)
Message-ID: <5424C9CF.4060904@gmail.com>
Date: Thu, 25 Sep 2014 22:05:03 -0400
From: Tom Taylor 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Tina TSOU ,  Benoit Claise 
References:  
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/supa/Dr5h8zpcTrPNR1GrErEY2Y-lsnI
Cc: "supa@ietf.org" 
Subject: Re: [Supa] Draft charter v1.12//RE:  Area hand-off, and some friendly advice ...
X-BeenThere: supa@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Sep 2014 02:05:07 -0000

May I offer a purely editorial rewrite of this? (Mostly just breaking it 
into bite-sized paragraphs):

=================================================
SUPA (Shared Unified Policy Automation) charter v1.12
Target Area: Operations and Management

Description of Working Group:

Many network operators are considering programmatic ways, often called 
software-defined, to configure networks, to shift the balance [of 
costs?] in their favor. Automating the way to expose a view of the 
network to applications may provide significant improvements in 
configuration agility, error detection and uptime for operators. However 
the real value behind central configuration schemes lies
with possible simplification through models provided by such systems to 
applications and network services running above them (on the so-called 
northbound side).

Well-designed models are able to provide a wide range of granularity for
various applications and network service needs, from the lower-level 
physical network to high-level application services. Several 
organizations outside of the IETF have defined various schemes for the 
configuration of network devices and specific network controllers, but 
none of them offer a vendor-neutral standardized way for applications 
and network services to transmit their needs to network controllers. The 
SUPA (Shared Unified Policy Automation) working group will work on the 
definition of such a standardized interface for applications and network 
services to communicate with network controllers of all types.

In particular, SUPA will focus on service specific models that allow
applications to request certain network services to be 
created/deleted/modified. A network service can for example be a virtual 
link between two endpoints that uses certain properties, traffic 
engineering, implementation of IPv6 transition mechanism and their 
enforcement to users. Each network service can be represented by a 
service based POLICY model that can model a group of demands (i.e., 
actions and constraints) that are being initiated by applications that 
impose similar requirements on the communication network.

The terms "UNIFIED" and "SHARED" used in the SUPA abbreviation, relate
to the way the service policy model is generated, since it groups,
unifies and shares the similar requirements imposed by a bulk of 
applications. SUPA will provide guidelines for mechanisms that can 
dynamically and in an interoperable manner, AUTOMATICALLY map services 
and policies defined on an abstract topology graph down to more detailed 
network graphs and specific network management and controlling policies.

Some IETF working groups such as I2RS (L3 and routing topologies), ALTO 
(cost maps), and SFC (service chain) have started work relating to the 
description of various topologies. None of these groups aim:
  (1) at offering truly generic topology models for the standard
      northbound interface, and
  (2) to allow an application to communicate with network
      boxes, such as network controllers, and NEs, developed by
      different vendors.

SUPA will work on defining vendor-neutral standardized interfaces based 
on the concept of network graph, an entity describing an arbitrary 
topology of nodes and links at any level of granularity. Such a network 
graph describes:
  (1) topologies at different levels of abstraction,
  (2) the relationships between the abstraction levels and
  (3) applied service based policy, which is a set of actions and
      constraints applied on these topologies.
SUPA may also define any mappings to any other network topology data
models defined within the IETF.

The main goal of SUPA is to provide service specific models that allow 
applications to request network services to be created/deleted/modified. 
This can be realized by:
   o) modelling multiple topologies at different levels of abstraction
      using a network graph,
   o) modelling the relationships between the abstraction levels;
   o) transporting model instances using either NETCONF or RESTCONF

SUPA will ensure that in case any specific NETCONF/RESTCONF protocol
requirements are identified, they will be communicated in a timely
manner to the NETCONF working group. SUPA will consult with the YANG
doctors to ensure that data models follow common practices.

Work items for SUPA include:
============================
1) The definition of a standardized model for a network graph, using 
YANG. This model may be used to describe topologies at any functional 
layer, from physical networks to network services.

2) The definition and standardization of a number of basic policy and 
data models using network graphs. These might include, but are not 
limited to L3VPNs, traffic engineering, implementation of IPv6 
transition mechanisms and their enforcement to users.

3) Provide guidelines for mechanisms that can dynamically and on an
interoperable manner, automatically map services and policies defined
on an abstract topology graph down to more detailed network graphs and
specific network management and controlling policies.

4) Guidelines on how to use NETCONF (or RESTCONF) authentication
and authorization mechanisms to achieve protection and isolation.

Deliverables:
=============
  o) Produce an informational RFC "Problem Statement and Use Cases".
  o) Produce a standards-track RFC that specifies YANG models
     for a generic multi-layer network graph.
  o) Produce standards-track RFCs that specify extensions for
     the generic YANG models defined above for network services
     that manage virtual links, traffic engineering and implementation
     of IPv6 transition mechanism and their enforcement to users.
  o) Produce an informational RFC that provides the guidelines
     for mechanisms that can dynamically and on interoperable manner,
     automatically map services and policies defined on an abstract
     topology graph down to more detailed network graphs and specific
     network management and controlling policies.
  o) Produce an informational RFC that provides the guidelines on
     using NETCONF (or RESTCONF) authentication and authorization
     mechanisms to achieve security protection and isolation' as
     an Informational RFC.

Milestones:
===========
Dec 2014  Initial "Problem Statement and Use Cases" WG I-D
Feb 2015  Initial "Multi-layer Network Graph YANG Model" WG I-D
Apr 2015  Initial service specific data model WG I-Ds
May 2015  Initial "Mapping Guidelines" WG I-D
Jun 2015  Submit "Problem Statement and Use Cases" I-D to IESG
Jul 2015  Initial "Authentication and Authorization" WG I-D
Sep 2015  Submit "Multi-layer Network Graph YANG Model" I-D to IESG
Nov 2015  Submit service specific data model I-Ds to IESG
Feb 2016  Submit "Mapping Guidelines" I-D to IESG
Apr 2016  Submit "Authentication and Authorization" I-D to IESG


On 25/09/2014 8:50 PM, Tina TSOU wrote:
> Dear Benoit et al,
>
> Here comes latest version. The list discussion helps a lot to make it
> clearer.
>
> ================================================= SUPA (Shared
> Unified Policy Automation) charter v1.12 Target Area: Operations and
> Management
>
> Description of Working Group:
>
> Programmatic ways to configure networks, often called
> software-defined, are considered by many network operators in order
> to shift the balance in their favor. Automating the way of exposing a
> view of the network to applications may provide significant
> improvements in configuration agility, error detection and uptime for
> operators. However the real value behind central configuration
> schemes lies within the possible simplification through models
> provided by such systems to applications and network services running
> above them (on the so-called northbound side). Well-designed models
> are able to provide a wide range of granularity for various
> applications and network services needs, from the lower-level
> physical network to high-level application services. Several
> organizations outside of the IETF have defined various schemes for
> the configuration of network devices and specific network
> controllers, but none of them offer a vendor-neutral standardized way
> for applications and network services to transmit their needs to
> network controllers. The SUPA (Shared Unified Policy Automation)
> working group will work on the definition of such as standardized
> interface for applications and network services to communicate with
> network controllers of all types. In particular, SUPA will focus on
> service specific models that allow applications to request certain
> network services to be created/deleted/modified. A network service
> can for example be a virtual link between two endpoints that uses
> certain properties, traffic engineering, implementation of IPv6
> transition mechanism and their enforcement to users. Each network
> service can be represented by a service based POLICY model that can
> model a group of demands (i.e., actions and constraints) that are
> being initiated by applications that impose similar requirements on
> the communication network. The terms "UNIFIED" and "SHARED" used in
> the SUPA abbreviation, relate to the way of how the service policy
> model is generated, since it groups, unifies and shares the similar
> requirements imposed by a bulk of applications. SUPA will provide
> guidelines for mechanisms that can dynamically and on an
> interoperable manner, AUTOMATICALLY map services and policies defined
> on an abstract topology graph down to more detailed network graphs
> and specific network management and controlling policies. Some IETF
> working groups have started work relating to the description of
> various topologies such as I2RS (L3 and routing topologies), ALTO
> (cost maps), SFC (service chain), none of these groups aim (1) at
> offering truly generic topology models for the standard northbound
> interface, and (2) that an application can communicate with network
> boxes, such as network controllers, and NEs, developed by different
> vendors. SUPA will work on defining vendor-neutral standardized
> interfaces based on the concept of network graph, an entity
> describing an arbitrary topology of nodes and links at any level of
> granularity. Such a network graph describes (1) topologies at
> different levels of abstraction, (2) the relationships between the
> abstraction levels and (3) applied service based policy, which are
> actions and constraints applied on these topologies. SUPA may also
> define any mappings to any other network topology data models defined
> within the IETF. The main goal of SUPA is to provide service specific
> models that allow applications to request network services to be
> created/deleted/modified. This can be realized by: o) model multiple
> topologies at different levels of abstraction using a network graph,
> o) model the relationships between the abstraction levels. o)
> transporting model instances using either NETCONF or RESTCONF
>
> SUPA will ensure that in case any specific NETCONF/RESTCONF protocol
> requirements are identified, they will be communicated in a timely
> manner to the NETCONF working group. SUPA will consult with the YANG
> doctors to ensure that data models follow common practices.
>
> Work items for SUPA include: ============================ 1) The
> definition of a standardized model for a network graph, using YANG.
> This model may be used to describe topologies at any functional
> layer, from physical networks to network services. 2) The definition
> and standardization of a number of basic policy and data models using
> network graphs. These might include, but are not limited to L3VPNs,
> traffic engineering, implementation of IPv6 transition mechanism and
> their enforcement to users. 3) Provide guidelines for mechanisms that
> can dynamically and on an interoperable manner, automatically map
> services and policies defined on an abstract topology graph down to
> more detailed network graphs and specific network management and
> controlling policies. 4) Guidelines on how to use NETCONF (or
> RESTCONF) authentication and authorization mechanisms to achieve
> protection and isolation
>
> Deliverables: ============= o) Produce an informational RFC "Problem
> Statement and Use Cases". o) Produce a standards-track RFC that
> specifies YANG models for a generic multi-layer network graph. o)
> Produce standards-track RFCs that specify extensions for the generic
> YANG models defined above for network services that manage virtual
> links, traffic engineering and implementation of IPv6 transition
> mechanism and their enforcement to users. o) Produce an informational
> RFC that provides the guidelines for mechanisms that can dynamically
> and on interoperable manner, automatically map services and policies
> defined on an abstract topology graph down to more detailed network
> graphs and specific network management and controlling policies. o)
> Produce an informational RFC that provides the guidelines on using
> NETCONF (or RESTCONF) authentication and authorization mechanisms to
> achieve security protection and isolation' as an Informational RFC.
>
> Milestones: =========== Dec 2014  Initial "Problem Statement and Use
> Cases" WG I-D Feb 2015  Initial "Multi-layer Network Graph YANG
> Model" WG I-D Apr 2015  Initial service specific data model WG I-Ds
> May 2015  Initial "Mapping Guidelines" WG I-D Jun 2015  Submit
> "Problem Statement and Use Cases" I-D to IESG Jul 2015  Initial
> "Authentication and Authorization" WG I-D Sep 2015  Submit
> "Multi-layer Network Graph YANG Model" I-D to IESG Nov 2015  Submit
> service specific data model I-Ds to IESG Feb 2016  Submit "Mapping
> Guidelines" I-D to IESG Apr 2016  Submit "Authentication and
> Authorization" I-D to IESG
>
>
> Thank you, Tina
>
> From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Liushucheng
> (Will) Sent: Thursday, September 25, 2014 7:36 PM To: Benoit Claise
> Cc: supa@ietf.org Subject: Re: [Supa] Area hand-off, and some
> friendly advice ...
>
> Hi Benoit,
>
> Below inline please see two pieces of complementary answer from my
> team (starts with [Will]). Thank you!
>
> Regards, Will
>
> From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Georgios
> Karagiannis Sent: Wednesday, September 24, 2014 7:30 PM To: Benoit
> Claise; Tina TSOU; Juergen Schoenwaelder Cc: Zhen Cao;
> supa@ietf.org Subject: Re: [Supa] Area
> hand-off, and some friendly advice ...
>
> Hi Benoit,
>
> Thank you for your comments. Please see in line,
>
> From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Benoit Claise
> Sent: Wednesday, September 24, 2014 10:41 AM To: Georgios
> Karagiannis; Tina TSOU; Juergen Schoenwaelder Cc: Zhen Cao;
> supa@ietf.org Subject: Re: [Supa] Area
> hand-off, and some friendly advice ...
>
> Hi Georgios,
>
> Hi Benoit,
>
>
>
> Thanks for your comments!
>
> Please see in line.
>
>
>
>
>
> Georgios: Please note that we are referring to the following figure:
>
> ---------------------------------------
>
> | applications                        |
>
> ---------------------------------------
>
> |  <---end use. Appl.   |
>
> ---------------------             |<---end use. Appl.
>
> | enhanced OSS      |             |
>
> ---------------------             |
>
> |   <--- network service |
>
> YANG models  /NETCONF interface                |
>
> --------------------------------------
>
> |   controller                       |               <---  mapping
> network services
>
> to topology
>
> --------------------------------------
>
> |       |        |                    <---
>
> device/feature specific YANG models / NETCONF interface
>
> NE1    NE2   NEn It's not obvious what an "enhanced OSS" is?
>
> Georgios: it relates to the system that runs network services. These
> services are enhanced Operational Support System (OSS) like services
> that help a communication service provider to monitor, control,
> analyze and manage a communication network.
>
>
> Georgios: According to the provided figure: 1) need to work on
> network service Yang models, 2 mapping network services to topology,
> 3. Device/feature specific Yang Models, 4) end user specific Yank
> Models (out of scope). The interface between end user applications
> and a controller, and interface between end user application and
> enhanced OSS, are also out of scope. Concerning your last sentence.
> I'm confused. What does the following deliverable mean then?
>
> o) specify and standardize how NETCONF/YANG (or RESTCONF/YANG) can be
> used to securely and efficiently distribute up to date (fresh)
> network graphs between network service systems and network management
> and controlling systems
>
> It relates to the interface between the network service system
> (enhanced OSS in the above figure. Please note that we say that we
> initially only focus on this interface, in order to narrow down the
> scope of this activity
>
> However, if there are supports that think we should initially focus
> also on the interface between end user application and controller we
> will also include this interface in the scope.
>
>
>
> [Will]: First of all, IMOH, the figures from Benoit and Georgios are
> not incompatible. From the perspective of controller, they are
> different latitudes of northband. The application and enhanced OSS in
> Georgios figure can be put together into an larger application* layer
> of Benoit's figure. The network graph is proposed to provide
> network-wide configuration containing the key information for service
> instances. One example is, for the DDC use case, the network graph
> contains the key information such as the key node information of the
> path and the key requirement of traffic steering.
>
>
>
> Regarding to the app, management app, end user app here, I want to
> add something related to the history of this work. At the very
> beginning, when this work is call APONF before Toronto IETF meeting,
> the end user app is in the scope. However, there are mainly three
> reasons that we remove this point:
>
> 1.      The confliction with AECON, we discussed with proponents of
> AECON and to avoid the conflict as at that time they were proposing
> the interface from end user app to network devices. Later in the IESG
> meeting in Toronto, we successfully clarified the differences and got
> the suggestion to focus on management app.
>
> 2.      Lars Eggert showed his concerning about the interface between
> end user app and network devices may lead to security issue.  Kostas
> Pentikousis also mentioned this to me.
>
>
>
> However, these are old stories. During the Toronto BoF, someone also
> suggested us re-put the end user app into cope. A large app layer
> containing both end user app and management app may replace the first
> two layers in the old 4 layers figure. Here, my question is, are you
> in favor of adding end user app into SUPA scope or not?
>
>
>
>
>
> Regarding your comment, " I'm not convinced we could standardize
> them, as they are operators specific, and will be evolving along the
> time. There are many different ways to configure a VPN, for example."
> Were you referring to:
>
> 3. Device/feature specific Yang Models? No, the service YANG models
>
> Georgios: I see, but we can work on YANG models that can be used for
> a number of main network services, which are essential for operators
> and that they would like to have them standardized.
>
>
>
>
>
>
> See in-line
>
> Dear all,
>
>
>
> Hope this version of draft charter address most of the comments from
> the list.
>
>
>
> ------
>
>
>
>
>
>
>
>
>
> In particular, as starting point, SUPA will only focus on network
> services, which are enhanced Operational Support System (OSS) like
> services that help a communication service provider to monitor,
> control, analyze and manage a communication network. The systems that
> are runniung such network services are denoted in this document as
> Network Service Systems.
>
> Each network service can be represented by a classified application
> based POLICY model, since it can model the group of demands which are
> SHARED and UNIFIED and are coming from a bundle of applications that
> impose similar requirements on the communication network.
>
> I'm afraid I don't understand (like Jürgen)
>
>
>
> Georgios: What we want to say is that there are applications that
> impose similar requirements on the communication network. For each
> group of such bulk of applications a network service can be defined
> that can be represented by a service policy model (i.e., its actions
> and constraints).
>
>
>
>
>
> Georgios: Thanks for the suggestion, the text needs to be rephrased,
> see below:
>
> Each network service can be represented by an application based
> POLICY model, which is UNIFIED and SHARED, since it can model the
> group of demands (i.e, actions and constraints) that are coming from
> a bundle of applications that impose similar requirements on the
> communication network. I still don't understand. what "UNIFIED and
> SHARED" mean.
>
> Georgios: the terms "UNIFIED" and "SHARED"" relate to the way of how
> the service policy model is generated, since it groups and it unifies
> and shares the similar requirements imposed by a bulk of
> applications.
>
>
>
>
>
>
>
>
>
> (2) transporting model instances either using NETCONF or RESTCONF and
> (3) providing guidelines on AUTOMATICALLY mapping policies to
> attributes of the network graphs.
>
>
>
> Although some IETF working groups have started work relating to the
> description of various topologies such as I2RS (L3and routing
> topologies), ALTO (cost maps), SFC (service chain), none of these
> groups aim at offering truly generic topology models for the standard
> northbound interface.
>
> SUPA will work on defining interfaces based on the concept of network
> graph, an entity describing an arbitrary topology of nodes and links
> at any level of granularity. Such a graph may describe, for example,
> a physical topology, a service topology or the relationships between
> datacenters. Any network topology data models or policy models that
> have been defined (or are being defined) within the IETF will be
> reused in SUPA as much as possible.
>
> In addition to the above, policies may be defined and applied to a
> network graph. These application based policies are actions or
> constraints generated by Network Service Systems. They are then
> mapped from the network graph instance into specific network
> management policies toward network components.
>
>
>
>
>
> Georgios: the above text is not clear. Therefore, I am rephrasing
> it:
>
> =============================================
>
> The main goal of SUPA is to provide application based policies and
> means to model and program the abstract view of network
> infrastructure and service function interdependencies in order to
> support and AUTOMATICALLY feed network management and controlling
> policies. This can be realized by:
>
>
>
> (1) modeling the network graph, which among others include policy
> models, data models and application based policies, using YANG,
>
>
>
> (2) applying NETCONF (or RESTCONF) to enable dissemination of up to
> date (fresh) network graphs in a secure and efficient manner between
> network service systems and network management and controlling
> systems, "between network service systems and network management and
> controlling system". What are those? I don't see them in your
> figure. Also, why should all of these need to know about the
> topology?
>
> Georgios: In the figure, the enhanced OSS represents the network
> service system and the controller represents the network management
> and controlling system. In this context, network services can be used
> to provide the required  configuration and application programming
> interfaces to service developers. Subsequently, a network service can
> use the application based demands (for actions and constraints) and
> possibly update its associated network service  attributes. Examples
> of network services that can modify  the network service attributes
> are for example, L3VPN configuration and IPv6 transitions. For each
> network service instance a network graph needs to be generated and
> maintained. The up to date network graph needs to (1) be communicated
> between the  network service systems and the network   management and
> controlling systems, (2) map the attributes of the network service
> graph into specific network management policies. [Will] To modeling
> service requirement and create service instances, APP needs a view of
> topology to form network configuration according to the key
> information of devices topology. This configuration is eventually
> mapped to the selected network devices according to topology provided
> by SUPA.
>
> Best regards, Georgios
>
>
>
>
>
> Regards, Benoit
>
>
>
> _______________________________________________ Supa mailing list
> Supa@ietf.org https://www.ietf.org/mailman/listinfo/supa
>


From nobody Thu Sep 25 21:38:49 2014
Return-Path: 
X-Original-To: supa@ietfa.amsl.com
Delivered-To: supa@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 539591A19FC for ; Thu, 25 Sep 2014 21:38:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.387
X-Spam-Level: 
X-Spam-Status: No, score=-4.387 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 fdrZsKCW8WnN for ; Thu, 25 Sep 2014 21:38:19 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DB611A19F4 for ; Thu, 25 Sep 2014 21:38:18 -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 BNA28013; Fri, 26 Sep 2014 04:38:16 +0000 (GMT)
Received: from LHREML516-MBX.china.huawei.com ([169.254.1.85]) by lhreml402-hub.china.huawei.com ([10.201.5.241]) with mapi id 14.03.0158.001; Fri, 26 Sep 2014 05:34:15 +0100
From: Georgios Karagiannis 
To: Tom Taylor 
Thread-Topic: [Supa] Draft charter v1.12//RE:  Area hand-off, and some friendly advice ...
Thread-Index: AQHP2SVFkVx+MKXdc0qefGpE8bFbEpwSmYOAgAA6IQA=
Date: Fri, 26 Sep 2014 04:34:15 +0000
Message-ID: 
References:   <5424C9CF.4060904@gmail.com>
In-Reply-To: <5424C9CF.4060904@gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.87.176]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/supa/FC4s0IJdEZxZ8KsfxGg0-swM-H4
Cc: Benoit Claise , "supa@ietf.org" , Tina TSOU 
Subject: Re: [Supa] Draft charter v1.12//RE:  Area hand-off, and some friendly advice ...
X-BeenThere: supa@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Sep 2014 04:38:48 -0000

Hi Tom,

Thank you very much!
We will upload this version in the github!

Best regards,
Georgios

> -----Original Message-----
> From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Tom Taylor
> Sent: Friday, September 26, 2014 3:05 AM
> To: Tina TSOU; Benoit Claise
> Cc: supa@ietf.org
> Subject: Re: [Supa] Draft charter v1.12//RE: Area hand-off, and some frie=
ndly
> advice ...
>=20
> May I offer a purely editorial rewrite of this? (Mostly just breaking it =
into
> bite-sized paragraphs):
>=20
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> SUPA (Shared Unified Policy Automation) charter v1.12 Target Area: Operat=
ions
> and Management
>=20
> Description of Working Group:
>=20
> Many network operators are considering programmatic ways, often called
> software-defined, to configure networks, to shift the balance [of costs?]=
 in
> their favor. Automating the way to expose a view of the network to
> applications may provide significant improvements in configuration agilit=
y,
> error detection and uptime for operators. However the real value behind
> central configuration schemes lies with possible simplification through m=
odels
> provided by such systems to applications and network services running abo=
ve
> them (on the so-called northbound side).
>=20
> Well-designed models are able to provide a wide range of granularity for
> various applications and network service needs, from the lower-level phys=
ical
> network to high-level application services. Several organizations outside=
 of
> the IETF have defined various schemes for the configuration of network de=
vices
> and specific network controllers, but none of them offer a vendor-neutral
> standardized way for applications and network services to transmit their =
needs
> to network controllers. The SUPA (Shared Unified Policy Automation) worki=
ng
> group will work on the definition of such a standardized interface for
> applications and network services to communicate with network controllers=
 of
> all types.
>=20
> In particular, SUPA will focus on service specific models that allow
> applications to request certain network services to be
> created/deleted/modified. A network service can for example be a virtual =
link
> between two endpoints that uses certain properties, traffic engineering,
> implementation of IPv6 transition mechanism and their enforcement to user=
s.
> Each network service can be represented by a service based POLICY model t=
hat
> can model a group of demands (i.e., actions and constraints) that are bei=
ng
> initiated by applications that impose similar requirements on the
> communication network.
>=20
> The terms "UNIFIED" and "SHARED" used in the SUPA abbreviation, relate to=
 the
> way the service policy model is generated, since it groups, unifies and s=
hares
> the similar requirements imposed by a bulk of applications. SUPA will pro=
vide
> guidelines for mechanisms that can dynamically and in an interoperable ma=
nner,
> AUTOMATICALLY map services and policies defined on an abstract topology g=
raph
> down to more detailed network graphs and specific network management and
> controlling policies.
>=20
> Some IETF working groups such as I2RS (L3 and routing topologies), ALTO (=
cost
> maps), and SFC (service chain) have started work relating to the descript=
ion
> of various topologies. None of these groups aim:
>   (1) at offering truly generic topology models for the standard
>       northbound interface, and
>   (2) to allow an application to communicate with network
>       boxes, such as network controllers, and NEs, developed by
>       different vendors.
>=20
> SUPA will work on defining vendor-neutral standardized interfaces based o=
n the
> concept of network graph, an entity describing an arbitrary topology of n=
odes
> and links at any level of granularity. Such a network graph describes:
>   (1) topologies at different levels of abstraction,
>   (2) the relationships between the abstraction levels and
>   (3) applied service based policy, which is a set of actions and
>       constraints applied on these topologies.
> SUPA may also define any mappings to any other network topology data mode=
ls
> defined within the IETF.
>=20
> The main goal of SUPA is to provide service specific models that allow
> applications to request network services to be created/deleted/modified.
> This can be realized by:
>    o) modelling multiple topologies at different levels of abstraction
>       using a network graph,
>    o) modelling the relationships between the abstraction levels;
>    o) transporting model instances using either NETCONF or RESTCONF
>=20
> SUPA will ensure that in case any specific NETCONF/RESTCONF protocol
> requirements are identified, they will be communicated in a timely manner=
 to
> the NETCONF working group. SUPA will consult with the YANG doctors to ens=
ure
> that data models follow common practices.
>=20
> Work items for SUPA include:
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D
> 1) The definition of a standardized model for a network graph, using YANG=
.
> This model may be used to describe topologies at any functional layer, fr=
om
> physical networks to network services.
>=20
> 2) The definition and standardization of a number of basic policy and dat=
a
> models using network graphs. These might include, but are not limited to
> L3VPNs, traffic engineering, implementation of IPv6 transition mechanisms=
 and
> their enforcement to users.
>=20
> 3) Provide guidelines for mechanisms that can dynamically and on an
> interoperable manner, automatically map services and policies defined on =
an
> abstract topology graph down to more detailed network graphs and specific
> network management and controlling policies.
>=20
> 4) Guidelines on how to use NETCONF (or RESTCONF) authentication and
> authorization mechanisms to achieve protection and isolation.
>=20
> Deliverables:
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>   o) Produce an informational RFC "Problem Statement and Use Cases".
>   o) Produce a standards-track RFC that specifies YANG models
>      for a generic multi-layer network graph.
>   o) Produce standards-track RFCs that specify extensions for
>      the generic YANG models defined above for network services
>      that manage virtual links, traffic engineering and implementation
>      of IPv6 transition mechanism and their enforcement to users.
>   o) Produce an informational RFC that provides the guidelines
>      for mechanisms that can dynamically and on interoperable manner,
>      automatically map services and policies defined on an abstract
>      topology graph down to more detailed network graphs and specific
>      network management and controlling policies.
>   o) Produce an informational RFC that provides the guidelines on
>      using NETCONF (or RESTCONF) authentication and authorization
>      mechanisms to achieve security protection and isolation' as
>      an Informational RFC.
>=20
> Milestones:
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> Dec 2014  Initial "Problem Statement and Use Cases" WG I-D Feb 2015  Init=
ial
> "Multi-layer Network Graph YANG Model" WG I-D Apr 2015  Initial service
> specific data model WG I-Ds May 2015  Initial "Mapping Guidelines" WG I-D=
 Jun
> 2015  Submit "Problem Statement and Use Cases" I-D to IESG Jul 2015  Init=
ial
> "Authentication and Authorization" WG I-D Sep 2015  Submit "Multi-layer
> Network Graph YANG Model" I-D to IESG Nov 2015  Submit service specific d=
ata
> model I-Ds to IESG Feb 2016  Submit "Mapping Guidelines" I-D to IESG Apr =
2016
> Submit "Authentication and Authorization" I-D to IESG
>=20
>=20
> On 25/09/2014 8:50 PM, Tina TSOU wrote:
> > Dear Benoit et al,
> >
> > Here comes latest version. The list discussion helps a lot to make it
> > clearer.
> >
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D SUPA (Shared Unified
> > Policy Automation) charter v1.12 Target Area: Operations and
> > Management
> >
> > Description of Working Group:
> >
> > Programmatic ways to configure networks, often called
> > software-defined, are considered by many network operators in order to
> > shift the balance in their favor. Automating the way of exposing a
> > view of the network to applications may provide significant
> > improvements in configuration agility, error detection and uptime for
> > operators. However the real value behind central configuration schemes
> > lies within the possible simplification through models provided by
> > such systems to applications and network services running above them
> > (on the so-called northbound side). Well-designed models are able to
> > provide a wide range of granularity for various applications and
> > network services needs, from the lower-level physical network to
> > high-level application services. Several organizations outside of the
> > IETF have defined various schemes for the configuration of network
> > devices and specific network controllers, but none of them offer a
> > vendor-neutral standardized way for applications and network services
> > to transmit their needs to network controllers. The SUPA (Shared
> > Unified Policy Automation) working group will work on the definition
> > of such as standardized interface for applications and network
> > services to communicate with network controllers of all types. In
> > particular, SUPA will focus on service specific models that allow
> > applications to request certain network services to be
> > created/deleted/modified. A network service can for example be a
> > virtual link between two endpoints that uses certain properties,
> > traffic engineering, implementation of IPv6 transition mechanism and
> > their enforcement to users. Each network service can be represented by
> > a service based POLICY model that can model a group of demands (i.e.,
> > actions and constraints) that are being initiated by applications that
> > impose similar requirements on the communication network. The terms
> > "UNIFIED" and "SHARED" used in the SUPA abbreviation, relate to the
> > way of how the service policy model is generated, since it groups,
> > unifies and shares the similar requirements imposed by a bulk of
> > applications. SUPA will provide guidelines for mechanisms that can
> > dynamically and on an interoperable manner, AUTOMATICALLY map services
> > and policies defined on an abstract topology graph down to more
> > detailed network graphs and specific network management and
> > controlling policies. Some IETF working groups have started work
> > relating to the description of various topologies such as I2RS (L3 and
> > routing topologies), ALTO (cost maps), SFC (service chain), none of
> > these groups aim (1) at offering truly generic topology models for the
> > standard northbound interface, and (2) that an application can
> > communicate with network boxes, such as network controllers, and NEs,
> > developed by different vendors. SUPA will work on defining
> > vendor-neutral standardized interfaces based on the concept of network
> > graph, an entity describing an arbitrary topology of nodes and links
> > at any level of granularity. Such a network graph describes (1)
> > topologies at different levels of abstraction, (2) the relationships
> > between the abstraction levels and (3) applied service based policy,
> > which are actions and constraints applied on these topologies. SUPA
> > may also define any mappings to any other network topology data models
> > defined within the IETF. The main goal of SUPA is to provide service
> > specific models that allow applications to request network services to
> > be created/deleted/modified. This can be realized by: o) model
> > multiple topologies at different levels of abstraction using a network
> > graph,
> > o) model the relationships between the abstraction levels. o)
> > transporting model instances using either NETCONF or RESTCONF
> >
> > SUPA will ensure that in case any specific NETCONF/RESTCONF protocol
> > requirements are identified, they will be communicated in a timely
> > manner to the NETCONF working group. SUPA will consult with the YANG
> > doctors to ensure that data models follow common practices.
> >
> > Work items for SUPA include: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 1) The
> > definition of a standardized model for a network graph, using YANG.
> > This model may be used to describe topologies at any functional layer,
> > from physical networks to network services. 2) The definition and
> > standardization of a number of basic policy and data models using
> > network graphs. These might include, but are not limited to L3VPNs,
> > traffic engineering, implementation of IPv6 transition mechanism and
> > their enforcement to users. 3) Provide guidelines for mechanisms that
> > can dynamically and on an interoperable manner, automatically map
> > services and policies defined on an abstract topology graph down to
> > more detailed network graphs and specific network management and
> > controlling policies. 4) Guidelines on how to use NETCONF (or
> > RESTCONF) authentication and authorization mechanisms to achieve
> > protection and isolation
> >
> > Deliverables: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D o) Produce an inf=
ormational RFC "Problem
> > Statement and Use Cases". o) Produce a standards-track RFC that
> > specifies YANG models for a generic multi-layer network graph. o)
> > Produce standards-track RFCs that specify extensions for the generic
> > YANG models defined above for network services that manage virtual
> > links, traffic engineering and implementation of IPv6 transition
> > mechanism and their enforcement to users. o) Produce an informational
> > RFC that provides the guidelines for mechanisms that can dynamically
> > and on interoperable manner, automatically map services and policies
> > defined on an abstract topology graph down to more detailed network
> > graphs and specific network management and controlling policies. o)
> > Produce an informational RFC that provides the guidelines on using
> > NETCONF (or RESTCONF) authentication and authorization mechanisms to
> > achieve security protection and isolation' as an Informational RFC.
> >
> > Milestones: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dec 2014  Initial "Proble=
m Statement and Use
> > Cases" WG I-D Feb 2015  Initial "Multi-layer Network Graph YANG Model"
> > WG I-D Apr 2015  Initial service specific data model WG I-Ds May 2015
> > Initial "Mapping Guidelines" WG I-D Jun 2015  Submit "Problem
> > Statement and Use Cases" I-D to IESG Jul 2015  Initial "Authentication
> > and Authorization" WG I-D Sep 2015  Submit "Multi-layer Network Graph
> > YANG Model" I-D to IESG Nov 2015  Submit service specific data model
> > I-Ds to IESG Feb 2016  Submit "Mapping Guidelines" I-D to IESG Apr
> > 2016  Submit "Authentication and Authorization" I-D to IESG
> >
> >
> > Thank you, Tina
> >
> > From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Liushucheng
> > (Will) Sent: Thursday, September 25, 2014 7:36 PM To: Benoit Claise
> > Cc: supa@ietf.org Subject: Re: [Supa] Area hand-off, and some friendly
> > advice ...
> >
> > Hi Benoit,
> >
> > Below inline please see two pieces of complementary answer from my
> > team (starts with [Will]). Thank you!
> >
> > Regards, Will
> >
> > From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Georgios
> > Karagiannis Sent: Wednesday, September 24, 2014 7:30 PM To: Benoit
> > Claise; Tina TSOU; Juergen Schoenwaelder Cc: Zhen Cao;
> > supa@ietf.org Subject: Re: [Supa] Area hand-off,
> > and some friendly advice ...
> >
> > Hi Benoit,
> >
> > Thank you for your comments. Please see in line,
> >
> > From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Benoit Claise
> > Sent: Wednesday, September 24, 2014 10:41 AM To: Georgios Karagiannis;
> > Tina TSOU; Juergen Schoenwaelder Cc: Zhen Cao;
> > supa@ietf.org Subject: Re: [Supa] Area hand-off,
> > and some friendly advice ...
> >
> > Hi Georgios,
> >
> > Hi Benoit,
> >
> >
> >
> > Thanks for your comments!
> >
> > Please see in line.
> >
> >
> >
> >
> >
> > Georgios: Please note that we are referring to the following figure:
> >
> > ---------------------------------------
> >
> > | applications                        |
> >
> > ---------------------------------------
> >
> > |  <---end use. Appl.   |
> >
> > ---------------------             |<---end use. Appl.
> >
> > | enhanced OSS      |             |
> >
> > ---------------------             |
> >
> > |   <--- network service |
> >
> > YANG models  /NETCONF interface                |
> >
> > --------------------------------------
> >
> > |   controller                       |               <---  mapping
> > network services
> >
> > to topology
> >
> > --------------------------------------
> >
> > |       |        |                    <---
> >
> > device/feature specific YANG models / NETCONF interface
> >
> > NE1    NE2   NEn It's not obvious what an "enhanced OSS" is?
> >
> > Georgios: it relates to the system that runs network services. These
> > services are enhanced Operational Support System (OSS) like services
> > that help a communication service provider to monitor, control,
> > analyze and manage a communication network.
> >
> >
> > Georgios: According to the provided figure: 1) need to work on network
> > service Yang models, 2 mapping network services to topology, 3.
> > Device/feature specific Yang Models, 4) end user specific Yank Models
> > (out of scope). The interface between end user applications and a
> > controller, and interface between end user application and enhanced
> > OSS, are also out of scope. Concerning your last sentence.
> > I'm confused. What does the following deliverable mean then?
> >
> > o) specify and standardize how NETCONF/YANG (or RESTCONF/YANG) can be
> > used to securely and efficiently distribute up to date (fresh) network
> > graphs between network service systems and network management and
> > controlling systems
> >
> > It relates to the interface between the network service system
> > (enhanced OSS in the above figure. Please note that we say that we
> > initially only focus on this interface, in order to narrow down the
> > scope of this activity
> >
> > However, if there are supports that think we should initially focus
> > also on the interface between end user application and controller we
> > will also include this interface in the scope.
> >
> >
> >
> > [Will]: First of all, IMOH, the figures from Benoit and Georgios are
> > not incompatible. From the perspective of controller, they are
> > different latitudes of northband. The application and enhanced OSS in
> > Georgios figure can be put together into an larger application* layer
> > of Benoit's figure. The network graph is proposed to provide
> > network-wide configuration containing the key information for service
> > instances. One example is, for the DDC use case, the network graph
> > contains the key information such as the key node information of the
> > path and the key requirement of traffic steering.
> >
> >
> >
> > Regarding to the app, management app, end user app here, I want to add
> > something related to the history of this work. At the very beginning,
> > when this work is call APONF before Toronto IETF meeting, the end user
> > app is in the scope. However, there are mainly three reasons that we
> > remove this point:
> >
> > 1.      The confliction with AECON, we discussed with proponents of
> > AECON and to avoid the conflict as at that time they were proposing
> > the interface from end user app to network devices. Later in the IESG
> > meeting in Toronto, we successfully clarified the differences and got
> > the suggestion to focus on management app.
> >
> > 2.      Lars Eggert showed his concerning about the interface between
> > end user app and network devices may lead to security issue.  Kostas
> > Pentikousis also mentioned this to me.
> >
> >
> >
> > However, these are old stories. During the Toronto BoF, someone also
> > suggested us re-put the end user app into cope. A large app layer
> > containing both end user app and management app may replace the first
> > two layers in the old 4 layers figure. Here, my question is, are you
> > in favor of adding end user app into SUPA scope or not?
> >
> >
> >
> >
> >
> > Regarding your comment, " I'm not convinced we could standardize them,
> > as they are operators specific, and will be evolving along the time.
> > There are many different ways to configure a VPN, for example."
> > Were you referring to:
> >
> > 3. Device/feature specific Yang Models? No, the service YANG models
> >
> > Georgios: I see, but we can work on YANG models that can be used for a
> > number of main network services, which are essential for operators and
> > that they would like to have them standardized.
> >
> >
> >
> >
> >
> >
> > See in-line
> >
> > Dear all,
> >
> >
> >
> > Hope this version of draft charter address most of the comments from
> > the list.
> >
> >
> >
> > ------
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > In particular, as starting point, SUPA will only focus on network
> > services, which are enhanced Operational Support System (OSS) like
> > services that help a communication service provider to monitor,
> > control, analyze and manage a communication network. The systems that
> > are runniung such network services are denoted in this document as
> > Network Service Systems.
> >
> > Each network service can be represented by a classified application
> > based POLICY model, since it can model the group of demands which are
> > SHARED and UNIFIED and are coming from a bundle of applications that
> > impose similar requirements on the communication network.
> >
> > I'm afraid I don't understand (like J=FCrgen)
> >
> >
> >
> > Georgios: What we want to say is that there are applications that
> > impose similar requirements on the communication network. For each
> > group of such bulk of applications a network service can be defined
> > that can be represented by a service policy model (i.e., its actions
> > and constraints).
> >
> >
> >
> >
> >
> > Georgios: Thanks for the suggestion, the text needs to be rephrased,
> > see below:
> >
> > Each network service can be represented by an application based POLICY
> > model, which is UNIFIED and SHARED, since it can model the group of
> > demands (i.e, actions and constraints) that are coming from a bundle
> > of applications that impose similar requirements on the communication
> > network. I still don't understand. what "UNIFIED and SHARED" mean.
> >
> > Georgios: the terms "UNIFIED" and "SHARED"" relate to the way of how
> > the service policy model is generated, since it groups and it unifies
> > and shares the similar requirements imposed by a bulk of applications.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > (2) transporting model instances either using NETCONF or RESTCONF and
> > (3) providing guidelines on AUTOMATICALLY mapping policies to
> > attributes of the network graphs.
> >
> >
> >
> > Although some IETF working groups have started work relating to the
> > description of various topologies such as I2RS (L3and routing
> > topologies), ALTO (cost maps), SFC (service chain), none of these
> > groups aim at offering truly generic topology models for the standard
> > northbound interface.
> >
> > SUPA will work on defining interfaces based on the concept of network
> > graph, an entity describing an arbitrary topology of nodes and links
> > at any level of granularity. Such a graph may describe, for example, a
> > physical topology, a service topology or the relationships between
> > datacenters. Any network topology data models or policy models that
> > have been defined (or are being defined) within the IETF will be
> > reused in SUPA as much as possible.
> >
> > In addition to the above, policies may be defined and applied to a
> > network graph. These application based policies are actions or
> > constraints generated by Network Service Systems. They are then mapped
> > from the network graph instance into specific network management
> > policies toward network components.
> >
> >
> >
> >
> >
> > Georgios: the above text is not clear. Therefore, I am rephrasing
> > it:
> >
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> >
> > The main goal of SUPA is to provide application based policies and
> > means to model and program the abstract view of network infrastructure
> > and service function interdependencies in order to support and
> > AUTOMATICALLY feed network management and controlling policies. This
> > can be realized by:
> >
> >
> >
> > (1) modeling the network graph, which among others include policy
> > models, data models and application based policies, using YANG,
> >
> >
> >
> > (2) applying NETCONF (or RESTCONF) to enable dissemination of up to
> > date (fresh) network graphs in a secure and efficient manner between
> > network service systems and network management and controlling
> > systems, "between network service systems and network management and
> > controlling system". What are those? I don't see them in your figure.
> > Also, why should all of these need to know about the topology?
> >
> > Georgios: In the figure, the enhanced OSS represents the network
> > service system and the controller represents the network management
> > and controlling system. In this context, network services can be used
> > to provide the required  configuration and application programming
> > interfaces to service developers. Subsequently, a network service can
> > use the application based demands (for actions and constraints) and
> > possibly update its associated network service  attributes. Examples
> > of network services that can modify  the network service attributes
> > are for example, L3VPN configuration and IPv6 transitions. For each
> > network service instance a network graph needs to be generated and
> > maintained. The up to date network graph needs to (1) be communicated
> > between the  network service systems and the network   management and
> > controlling systems, (2) map the attributes of the network service
> > graph into specific network management policies. [Will] To modeling
> > service requirement and create service instances, APP needs a view of
> > topology to form network configuration according to the key
> > information of devices topology. This configuration is eventually
> > mapped to the selected network devices according to topology provided
> > by SUPA.
> >
> > Best regards, Georgios
> >
> >
> >
> >
> >
> > Regards, Benoit
> >
> >
> >
> > _______________________________________________ Supa mailing list
> > Supa@ietf.org https://www.ietf.org/mailman/listinfo/supa
> >
>=20
> _______________________________________________
> Supa mailing list
> Supa@ietf.org
> https://www.ietf.org/mailman/listinfo/supa


From nobody Thu Sep 25 21:44:54 2014
Return-Path: 
X-Original-To: supa@ietfa.amsl.com
Delivered-To: supa@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 948421A1A02 for ; Thu, 25 Sep 2014 21:44:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.731
X-Spam-Level: ***
X-Spam-Status: No, score=3.731 tagged_above=-999 required=5 tests=[BAYES_50=0.8, CN_BODY_103=0.327, CN_BODY_35=0.339, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, MIME_CHARSET_FARAWAY=2.45, RP_MATCHES_RCVD=-0.786] 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 NdNXxGieUN8e for ; Thu, 25 Sep 2014 21:44:48 -0700 (PDT)
Received: from sendg.mailex.chinaunicom.cn (sendg.mailex.chinaunicom.cn [210.53.66.230]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CADCC1A1A03 for ; Thu, 25 Sep 2014 21:44:45 -0700 (PDT)
Received: from SBG8380-4.chinaunicom.cn (10.0.15.35) by M10-HQ-MLOUT01.cnc.intra (10.0.15.20) with Microsoft SMTP Server id 8.2.254.0; Fri, 26 Sep 2014 12:44:35 +0800
X-AuditID: 0a000f23-b7f696d000002d7c-39-5424ef3a545e
Received: from M10-CEN-MLHUB01.cnc.intra ( [10.0.192.41])	by SBG8380-4.chinaunicom.cn (Symantec Messaging Gateway) with SMTP id 96.29.11644.A3FE4245; Fri, 26 Sep 2014 12:44:42 +0800 (HKT)
Received: from m10-hq-mlch01.hq.cnc.intra (10.0.15.26) by M10-CEN-MLHUB01.cnc.intra (10.0.192.41) with Microsoft SMTP Server (TLS) id 8.2.213.0; Fri, 26 Sep 2014 12:44:42 +0800
Received: from YingCheng-PC (114.255.193.232) by m10-hq-mlch01.hq.cnc.intra (10.0.15.26) with Microsoft SMTP Server id 8.2.213.0; Fri, 26 Sep 2014 12:44:41 +0800
Date: Fri, 26 Sep 2014 12:44:38 +0800
From: Ying Cheng 
To: supa 
References: 
Message-ID: <201409261244369676994@chinaunicom.cn>
X-mailer: Foxmail 6, 15, 201, 26 [cn]
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=====003_Dragon126160820723_====="
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNKsWRmVeSWpSXmKPExsXCxXBAU9fqvUqIwcEtphZHH0tYzN6yitni 6O+1rA7MHlN+b2T1aDnyltVjyZKfTAHMUXU2iXl5+SWJJakKKanFybZKwZnpeYklpUWpCv6l JUn5pXkpSgqZKbZKxkoKBTmJyam5qXkltkqJBQWpQBk7LgUMYANUlpmnkJqXnJ+SmZduqxQa 4qZroWT3dFnTs3lznjWteDll5ov165/1LX02ZVvCFZaMPw+nsBSs2Mpecf5JTQPjsznsXYyc HBICJhKnrh9nhLDFJC7cW8/WxcjFISSwl1Gi98xEJghnC6NE2+8mZghnKaPE8ntHgRwODhYB VYk5m9hBTDYBXYne9UYgg0QEpCTO7JwBNpRZIFTifNMLJhBbCMje++ERM4gtLBAh8axxLZjN K2Aksf7OXCaII1Qlrrb1gdksAm4S/++1MEHUCEqcnPmEBWQVs0CwxKp7mSCmkIC6xPJbdhMY BWchKZqFUDQL7AYtiXkNv5kgbEWJKd0P2SFsTYkrkw+xI4svYGRbxSgR7ORuYWxhoGuil5yR mZdYmpeZnJ+rl5y3iREc9fzKOxgfnLA8xCjAwajEw7tvn0qIEGtiWXFl7iFGCQ5mJRHeyDdA Id6UxMqq1KL8+KLSnNTiQ4zJQB9NZJYSTc4HJqS8knhDYwsLc2NjUxNjI2Mz0oSVxHlrTsiH CAmkA5NUdmpqQWoRzBYmDk6pBkYXsdJQp69tm0oXf3yxakGVbJ7hS2uVdSyijSleAV+UOA91 HeVMOFndGeYzK/6qX0FQ+14GocMem+32/ZrBG7Z5Xt+6wEPxLwtuKDTLTS4N8A6tuxAtKJU2 O8Q9tOD2pSvlh+Xz360oNM/NzQq8tHpZytTFbuoCi15HJ+3Xvu80tXfbDIHWy0osxRmJhlrM RcWJAFzwnk0+AwAA
Archived-At: http://mailarchive.ietf.org/arch/msg/supa/gmiL07R0y5jzTPwYbg_wn1IZWxw
Cc: Benoit Claise , Tina TSOU 
Subject: Re: [Supa] Draft charter v1.12//RE:  Area hand-off, and some friendlyadvice ...
X-BeenThere: supa@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Sep 2014 04:44:53 -0000

--=====003_Dragon126160820723_=====
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64

SGkgYWxsLA0KIA0KSSBhdHRlbmRlZCB0aGUgZS1tZWV0aW5nIGxhc3QgbmlnaHQgYW5kIGxl
YXJuZWQgYSBsb3QuIFRoYW5rIHlvdSBmb3IgeW91ciBlZmZvcnRzLiBUaGUgbGF0ZXN0IGNo
YXJ0ZXIgaXMgbm93IGNsZWFyZXIgYW5kIGZpbmUgZnJvbSBteSBzaWRlLiBMYXRlciBJIHBs
YW4gdG8gdXBkYXRlIHRoZSBEREMgdXNlIGNhc2UgYWNjb3JkaW5nbHkuDQogDQpTb21lIHF1
aWNrIGNvbW1lbnRzOg0KIA0KU29tZSBJRVRGIHdvcmtpbmcgZ3JvdXBzIGhhdmUgc3RhcnRl
ZCB3b3JrIHJlbGF0aW5nIHRvIHRoZSBkZXNjcmlwdGlvbiBvZiB2YXJpb3VzIHRvcG9sb2dp
ZXMgc3VjaCBhcyBJMlJTIChMMyBhbmQgcm91dGluZyB0b3BvbG9naWVzKSwgQUxUTyAoY29z
dCBtYXBzKSwgU0ZDIChzZXJ2aWNlIGNoYWluKSwgbm9uZSBvZiB0aGVzZSBncm91cHMgYWlt
ICgxKSBhdCBvZmZlcmluZyB0cnVseSBnZW5lcmljIHRvcG9sb2d5IG1vZGVscyBmb3IgdGhl
IHN0YW5kYXJkIG5vcnRoYm91bmQgaW50ZXJmYWNlLCBhbmQgKDIpIHRoYXQgYW4gYXBwbGlj
YXRpb24gY2FuIGNvbW11bmljYXRlIHdpdGggbmV0d29yayBib3hlcywgc3VjaCBhcyBuZXR3
b3JrIGNvbnRyb2xsZXJzLCBhbmQgTkVzLCBkZXZlbG9wZWQgYnkgZGlmZmVyZW50IHZlbmRv
cnMuDQogDQpIZXJlIGRvIHlvdSBtZWFuIHRob3NlIHdvcmtpbmcgZ3JvdXAgZGlkbqGvdCBk
byB5b3VyICgyKS4gSWYgbm8sIEkgZ3Vlc3MgeW91IHNob3VsZCB1c2UgobBuZWl0aGVyobEg
aW5zdGVhZC4gDQogDQpJbiBhZGRpdGlvbiwgZ2l2ZW4gdGhhdCB0aGVyZSB3ZXJlIHNvbWUg
ZGlzY3Vzc2lvbnMgcmVsYXRlZCB0byBlbmQgdXNlciBhcHAgYW5kIG1hbmFnZW1lbnQgYXBw
LiBZb3UgbWlnaHQgd2FudCB0byBzcGVjaWZ5IHRoZSBhcHAgaW4gdGhpcyBzZW50ZW5jZSB0
byBlbGltaW5hdGUgY29uZnVzaW9uLg0KIA0KT25lIG1vcmUgY29tbWVudCwgSSBzYXcgeW91
IGFkZCB0aGUgdGVybSChsWludGVyb3BlcmFibGUgbWFubmVyobEgaW4gc2V2ZXJhbCBwbGFj
ZXMuIENvdWxkIHlvdSBwbGVhc2UgZWxhYm9yYXRlPw0KDQpCUiwNCllpbmcNCg0KMjAxNC0w
OS0yNiANCg0KDQoNCllpbmcgQ0hFTkcgILPM06gNCkNoaW5hIFVuaWNvbSBOZXR3b3JrIFRl
Y2hub2xvZ3kgUmVzZWFyY2ggSW5zdGl0dXRlINbQufrBqs2ozfjC57y8yvXR0L6/1LoNClRl
bDogKzg2LTEwLTY4Nzk5OTk5LTc3MDINCk1vYmlsZTogKzg2LTE4NjAxMTAyOTcxDQoNCg0K
DQoNCg0Kt6K8/sjLo7ogVGluYSBUU09VIA0Kt6LLzcqxvOSjuiAyMDE0LTA5LTI2ICAwODo1
Mzo0NyANCsrVvP7Iy6O6IEJlbm9pdCBDbGFpc2UgDQqzrcvNo7ogc3VwYUBpZXRmLm9yZyAN
Ctb3zOKjuiBbU3VwYV0gRHJhZnQgY2hhcnRlciB2MS4xMi8vUkU6IEFyZWEgaGFuZC1vZmYs
IGFuZCBzb21lIGZyaWVuZGx5YWR2aWNlIC4uLiANCiANCkRlYXIgQmVub2l0IGV0IGFsLA0K
IA0KSGVyZSBjb21lcyBsYXRlc3QgdmVyc2lvbi4gVGhlIGxpc3QgZGlzY3Vzc2lvbiBoZWxw
cyBhIGxvdCB0byBtYWtlIGl0IGNsZWFyZXIuDQogDQo9PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpTVVBBIChTaGFyZWQgVW5pZmllZCBQb2xp
Y3kgQXV0b21hdGlvbikgY2hhcnRlciB2MS4xMg0KVGFyZ2V0IEFyZWE6IE9wZXJhdGlvbnMg
YW5kIE1hbmFnZW1lbnQNCiANCkRlc2NyaXB0aW9uIG9mIFdvcmtpbmcgR3JvdXA6DQogDQpQ
cm9ncmFtbWF0aWMgd2F5cyB0byBjb25maWd1cmUgbmV0d29ya3MsIG9mdGVuIGNhbGxlZCBz
b2Z0d2FyZS1kZWZpbmVkLCBhcmUgY29uc2lkZXJlZCBieSBtYW55IG5ldHdvcmsgb3BlcmF0
b3JzIGluIG9yZGVyIHRvIHNoaWZ0IHRoZSBiYWxhbmNlIGluIHRoZWlyIGZhdm9yLg0KQXV0
b21hdGluZyB0aGUgd2F5IG9mIGV4cG9zaW5nIGEgdmlldyBvZiB0aGUgbmV0d29yayB0byBh
cHBsaWNhdGlvbnMgbWF5IHByb3ZpZGUgc2lnbmlmaWNhbnQgaW1wcm92ZW1lbnRzIGluIGNv
bmZpZ3VyYXRpb24gYWdpbGl0eSwgZXJyb3IgZGV0ZWN0aW9uIGFuZCB1cHRpbWUgZm9yIG9w
ZXJhdG9ycy4gSG93ZXZlciB0aGUgcmVhbCB2YWx1ZSBiZWhpbmQgY2VudHJhbCBjb25maWd1
cmF0aW9uIHNjaGVtZXMgbGllcyB3aXRoaW4gdGhlIHBvc3NpYmxlIHNpbXBsaWZpY2F0aW9u
IHRocm91Z2ggbW9kZWxzIHByb3ZpZGVkIGJ5IHN1Y2ggc3lzdGVtcyB0byBhcHBsaWNhdGlv
bnMgYW5kIG5ldHdvcmsgc2VydmljZXMgcnVubmluZyBhYm92ZSB0aGVtIChvbiB0aGUgc28t
Y2FsbGVkIG5vcnRoYm91bmQgc2lkZSkuIFdlbGwtZGVzaWduZWQgbW9kZWxzIGFyZSBhYmxl
IHRvIHByb3ZpZGUgYSB3aWRlIHJhbmdlIG9mIGdyYW51bGFyaXR5IGZvciB2YXJpb3VzIGFw
cGxpY2F0aW9ucyBhbmQgbmV0d29yayBzZXJ2aWNlcyBuZWVkcywgZnJvbSB0aGUgbG93ZXIt
bGV2ZWwgcGh5c2ljYWwgbmV0d29yayB0byBoaWdoLWxldmVsIGFwcGxpY2F0aW9uIHNlcnZp
Y2VzLiANClNldmVyYWwgb3JnYW5pemF0aW9ucyBvdXRzaWRlIG9mIHRoZSBJRVRGIGhhdmUg
ZGVmaW5lZCB2YXJpb3VzIHNjaGVtZXMgZm9yIHRoZSBjb25maWd1cmF0aW9uIG9mIG5ldHdv
cmsgZGV2aWNlcyBhbmQgc3BlY2lmaWMgbmV0d29yayBjb250cm9sbGVycywgYnV0IG5vbmUg
b2YgdGhlbSBvZmZlciBhIHZlbmRvci1uZXV0cmFsIHN0YW5kYXJkaXplZCB3YXkgZm9yIGFw
cGxpY2F0aW9ucyBhbmQgbmV0d29yayBzZXJ2aWNlcyB0byB0cmFuc21pdCB0aGVpciBuZWVk
cyB0byBuZXR3b3JrIGNvbnRyb2xsZXJzLiBUaGUgU1VQQSAoU2hhcmVkIFVuaWZpZWQgUG9s
aWN5IEF1dG9tYXRpb24pIHdvcmtpbmcgZ3JvdXAgd2lsbCB3b3JrIG9uIHRoZSBkZWZpbml0
aW9uIG9mIHN1Y2ggYXMgc3RhbmRhcmRpemVkIGludGVyZmFjZSBmb3IgYXBwbGljYXRpb25z
IGFuZCBuZXR3b3JrIHNlcnZpY2VzIHRvIGNvbW11bmljYXRlIHdpdGggbmV0d29yayBjb250
cm9sbGVycyBvZiBhbGwgdHlwZXMuIEluIHBhcnRpY3VsYXIsIFNVUEEgd2lsbCBmb2N1cyBv
biBzZXJ2aWNlIHNwZWNpZmljIG1vZGVscyB0aGF0IGFsbG93IGFwcGxpY2F0aW9ucyB0byBy
ZXF1ZXN0IGNlcnRhaW4gbmV0d29yayBzZXJ2aWNlcyB0byBiZSBjcmVhdGVkL2RlbGV0ZWQv
bW9kaWZpZWQuIEEgbmV0d29yayBzZXJ2aWNlIGNhbiBmb3IgZXhhbXBsZSBiZSBhIHZpcnR1
YWwgbGluayBiZXR3ZWVuIHR3byBlbmRwb2ludHMgdGhhdCB1c2VzIGNlcnRhaW4gcHJvcGVy
dGllcywgdHJhZmZpYyBlbmdpbmVlcmluZywgaW1wbGVtZW50YXRpb24gb2YgSVB2NiB0cmFu
c2l0aW9uIG1lY2hhbmlzbSBhbmQgdGhlaXIgZW5mb3JjZW1lbnQgdG8gdXNlcnMuDQpFYWNo
IG5ldHdvcmsgc2VydmljZSBjYW4gYmUgcmVwcmVzZW50ZWQgYnkgYSBzZXJ2aWNlIGJhc2Vk
IFBPTElDWSBtb2RlbCB0aGF0IGNhbiBtb2RlbCBhIGdyb3VwIG9mIGRlbWFuZHMgKGkuZS4s
IGFjdGlvbnMgYW5kIGNvbnN0cmFpbnRzKSB0aGF0IGFyZSBiZWluZyBpbml0aWF0ZWQgYnkg
YXBwbGljYXRpb25zIHRoYXQgaW1wb3NlIHNpbWlsYXIgcmVxdWlyZW1lbnRzIG9uIHRoZSBj
b21tdW5pY2F0aW9uIG5ldHdvcmsuIFRoZSB0ZXJtcyAiVU5JRklFRCIgYW5kICJTSEFSRUQi
IHVzZWQgaW4gdGhlIFNVUEEgYWJicmV2aWF0aW9uLCByZWxhdGUgdG8gdGhlIHdheSBvZiBo
b3cgdGhlIHNlcnZpY2UgcG9saWN5IG1vZGVsIGlzIGdlbmVyYXRlZCwgc2luY2UgaXQgZ3Jv
dXBzLCB1bmlmaWVzIGFuZCBzaGFyZXMgdGhlIHNpbWlsYXIgcmVxdWlyZW1lbnRzIGltcG9z
ZWQgYnkgYSBidWxrIG9mIGFwcGxpY2F0aW9ucy4gU1VQQSB3aWxsIHByb3ZpZGUgZ3VpZGVs
aW5lcyBmb3IgbWVjaGFuaXNtcyB0aGF0IGNhbiBkeW5hbWljYWxseSBhbmQgb24gYW4gaW50
ZXJvcGVyYWJsZSBtYW5uZXIsIEFVVE9NQVRJQ0FMTFkgbWFwIHNlcnZpY2VzIGFuZCBwb2xp
Y2llcyBkZWZpbmVkIG9uIGFuIGFic3RyYWN0IHRvcG9sb2d5IGdyYXBoIGRvd24gdG8gbW9y
ZSBkZXRhaWxlZCBuZXR3b3JrIGdyYXBocyBhbmQgc3BlY2lmaWMgbmV0d29yayBtYW5hZ2Vt
ZW50IGFuZCBjb250cm9sbGluZyBwb2xpY2llcy4NClNvbWUgSUVURiB3b3JraW5nIGdyb3Vw
cyBoYXZlIHN0YXJ0ZWQgd29yayByZWxhdGluZyB0byB0aGUgZGVzY3JpcHRpb24gb2YgdmFy
aW91cyB0b3BvbG9naWVzIHN1Y2ggYXMgSTJSUyAoTDMgYW5kIHJvdXRpbmcgdG9wb2xvZ2ll
cyksIEFMVE8gKGNvc3QgbWFwcyksIFNGQyAoc2VydmljZSBjaGFpbiksIG5vbmUgb2YgdGhl
c2UgZ3JvdXBzIGFpbSAoMSkgYXQgb2ZmZXJpbmcgdHJ1bHkgZ2VuZXJpYyB0b3BvbG9neSBt
b2RlbHMgZm9yIHRoZSBzdGFuZGFyZCBub3J0aGJvdW5kIGludGVyZmFjZSwgYW5kICgyKSB0
aGF0IGFuIGFwcGxpY2F0aW9uIGNhbiBjb21tdW5pY2F0ZSB3aXRoIG5ldHdvcmsgYm94ZXMs
IHN1Y2ggYXMgbmV0d29yayBjb250cm9sbGVycywgYW5kIE5FcywgZGV2ZWxvcGVkIGJ5IGRp
ZmZlcmVudCB2ZW5kb3JzLg0KU1VQQSB3aWxsIHdvcmsgb24gZGVmaW5pbmcgdmVuZG9yLW5l
dXRyYWwgc3RhbmRhcmRpemVkIGludGVyZmFjZXMgYmFzZWQgb24gdGhlIGNvbmNlcHQgb2Yg
bmV0d29yayBncmFwaCwgYW4gZW50aXR5IGRlc2NyaWJpbmcgYW4gYXJiaXRyYXJ5IHRvcG9s
b2d5IG9mIG5vZGVzIGFuZCBsaW5rcyBhdCBhbnkgbGV2ZWwgb2YgZ3JhbnVsYXJpdHkuIFN1
Y2ggYSBuZXR3b3JrIGdyYXBoIGRlc2NyaWJlcyAoMSkgdG9wb2xvZ2llcyBhdCBkaWZmZXJl
bnQgbGV2ZWxzIG9mIGFic3RyYWN0aW9uLCAoMikgdGhlIHJlbGF0aW9uc2hpcHMgYmV0d2Vl
biB0aGUgYWJzdHJhY3Rpb24gbGV2ZWxzIGFuZCAoMykgYXBwbGllZCBzZXJ2aWNlIGJhc2Vk
IHBvbGljeSwgd2hpY2ggYXJlIGFjdGlvbnMgYW5kIGNvbnN0cmFpbnRzIGFwcGxpZWQgb24g
dGhlc2UgdG9wb2xvZ2llcy4gU1VQQSBtYXkgYWxzbyBkZWZpbmUgYW55IG1hcHBpbmdzIHRv
IGFueSBvdGhlciBuZXR3b3JrIHRvcG9sb2d5IGRhdGEgbW9kZWxzIGRlZmluZWQgd2l0aGlu
IHRoZSBJRVRGLg0KVGhlIG1haW4gZ29hbCBvZiBTVVBBIGlzIHRvIHByb3ZpZGUgc2Vydmlj
ZSBzcGVjaWZpYyBtb2RlbHMgdGhhdCBhbGxvdyBhcHBsaWNhdGlvbnMgdG8gcmVxdWVzdCBu
ZXR3b3JrIHNlcnZpY2VzIHRvIGJlIGNyZWF0ZWQvZGVsZXRlZC9tb2RpZmllZC4gVGhpcyBj
YW4gYmUgcmVhbGl6ZWQgYnk6DQogIG8pIG1vZGVsIG11bHRpcGxlIHRvcG9sb2dpZXMgYXQg
ZGlmZmVyZW50IGxldmVscyBvZiBhYnN0cmFjdGlvbiB1c2luZyBhIG5ldHdvcmsgZ3JhcGgs
IA0KICBvKSBtb2RlbCB0aGUgcmVsYXRpb25zaGlwcyBiZXR3ZWVuIHRoZSBhYnN0cmFjdGlv
biBsZXZlbHMuDQogIG8pIHRyYW5zcG9ydGluZyBtb2RlbCBpbnN0YW5jZXMgdXNpbmcgZWl0
aGVyIE5FVENPTkYgb3IgUkVTVENPTkYgDQogDQpTVVBBIHdpbGwgZW5zdXJlIHRoYXQgaW4g
Y2FzZSBhbnkgc3BlY2lmaWMgTkVUQ09ORi9SRVNUQ09ORiBwcm90b2NvbCByZXF1aXJlbWVu
dHMgYXJlIGlkZW50aWZpZWQsIHRoZXkgd2lsbCBiZSBjb21tdW5pY2F0ZWQgaW4gYSB0aW1l
bHkgbWFubmVyIHRvIHRoZSBORVRDT05GIHdvcmtpbmcgZ3JvdXAuIFNVUEEgd2lsbCBjb25z
dWx0IHdpdGggdGhlIFlBTkcgZG9jdG9ycyB0byBlbnN1cmUgdGhhdCBkYXRhIG1vZGVscyBm
b2xsb3cgY29tbW9uIHByYWN0aWNlcy4NCiANCldvcmsgaXRlbXMgZm9yIFNVUEEgaW5jbHVk
ZToNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCjEpIFRoZSBkZWZpbml0aW9uIG9m
IGEgc3RhbmRhcmRpemVkIG1vZGVsIGZvciBhIG5ldHdvcmsgZ3JhcGgsIHVzaW5nIFlBTkcu
IFRoaXMgbW9kZWwgbWF5IGJlIHVzZWQgdG8gZGVzY3JpYmUgdG9wb2xvZ2llcyBhdCBhbnkg
ZnVuY3Rpb25hbCBsYXllciwgZnJvbSBwaHlzaWNhbCBuZXR3b3JrcyB0byBuZXR3b3JrIHNl
cnZpY2VzLiANCjIpIFRoZSBkZWZpbml0aW9uIGFuZCBzdGFuZGFyZGl6YXRpb24gb2YgYSBu
dW1iZXIgb2YgYmFzaWMgcG9saWN5IGFuZCBkYXRhIG1vZGVscyB1c2luZyBuZXR3b3JrIGdy
YXBocy4gVGhlc2UgbWlnaHQgaW5jbHVkZSwgYnV0IGFyZSBub3QgbGltaXRlZCB0byBMM1ZQ
TnMsIHRyYWZmaWMgZW5naW5lZXJpbmcsIGltcGxlbWVudGF0aW9uIG9mIElQdjYgdHJhbnNp
dGlvbiBtZWNoYW5pc20gYW5kIHRoZWlyIGVuZm9yY2VtZW50IHRvIHVzZXJzLiAgDQozKSBQ
cm92aWRlIGd1aWRlbGluZXMgZm9yIG1lY2hhbmlzbXMgdGhhdCBjYW4gZHluYW1pY2FsbHkg
YW5kIG9uIGFuIGludGVyb3BlcmFibGUgbWFubmVyLCBhdXRvbWF0aWNhbGx5IG1hcCBzZXJ2
aWNlcyBhbmQgcG9saWNpZXMgZGVmaW5lZCBvbiBhbiBhYnN0cmFjdCB0b3BvbG9neSBncmFw
aCBkb3duIHRvIG1vcmUgZGV0YWlsZWQgbmV0d29yayBncmFwaHMgYW5kIHNwZWNpZmljIG5l
dHdvcmsgbWFuYWdlbWVudCBhbmQgY29udHJvbGxpbmcgcG9saWNpZXMuDQo0KSBHdWlkZWxp
bmVzIG9uIGhvdyB0byB1c2UgTkVUQ09ORiAob3IgUkVTVENPTkYpIGF1dGhlbnRpY2F0aW9u
IGFuZCBhdXRob3JpemF0aW9uIG1lY2hhbmlzbXMgdG8gYWNoaWV2ZSBwcm90ZWN0aW9uIGFu
ZCBpc29sYXRpb24NCiANCkRlbGl2ZXJhYmxlczoNCj09PT09PT09PT09PT0NCm8pIFByb2R1
Y2UgYW4gaW5mb3JtYXRpb25hbCBSRkMgIlByb2JsZW0gU3RhdGVtZW50IGFuZCBVc2UgQ2Fz
ZXMiLg0KbykgUHJvZHVjZSBhIHN0YW5kYXJkcy10cmFjayBSRkMgdGhhdCBzcGVjaWZpZXMg
WUFORyBtb2RlbHMgZm9yIGEgZ2VuZXJpYyBtdWx0aS1sYXllciBuZXR3b3JrIGdyYXBoLg0K
bykgUHJvZHVjZSBzdGFuZGFyZHMtdHJhY2sgUkZDcyB0aGF0IHNwZWNpZnkgZXh0ZW5zaW9u
cyBmb3IgdGhlIGdlbmVyaWMgWUFORyBtb2RlbHMgZGVmaW5lZCBhYm92ZSBmb3IgbmV0d29y
ayBzZXJ2aWNlcyB0aGF0IG1hbmFnZSB2aXJ0dWFsIGxpbmtzLCB0cmFmZmljIGVuZ2luZWVy
aW5nIGFuZCBpbXBsZW1lbnRhdGlvbiBvZiBJUHY2IHRyYW5zaXRpb24gbWVjaGFuaXNtIGFu
ZCB0aGVpciBlbmZvcmNlbWVudCB0byB1c2Vycy4NCm8pIFByb2R1Y2UgYW4gaW5mb3JtYXRp
b25hbCBSRkMgdGhhdCBwcm92aWRlcyB0aGUgZ3VpZGVsaW5lcyBmb3IgbWVjaGFuaXNtcyB0
aGF0IGNhbiBkeW5hbWljYWxseSBhbmQgb24gaW50ZXJvcGVyYWJsZSBtYW5uZXIsIGF1dG9t
YXRpY2FsbHkgbWFwIHNlcnZpY2VzIGFuZCBwb2xpY2llcyBkZWZpbmVkIG9uIGFuIGFic3Ry
YWN0IHRvcG9sb2d5IGdyYXBoIGRvd24gdG8gbW9yZSBkZXRhaWxlZCBuZXR3b3JrIGdyYXBo
cyBhbmQgc3BlY2lmaWMgbmV0d29yayBtYW5hZ2VtZW50IGFuZCBjb250cm9sbGluZyBwb2xp
Y2llcy4NCm8pIFByb2R1Y2UgYW4gaW5mb3JtYXRpb25hbCBSRkMgdGhhdCBwcm92aWRlcyB0
aGUgZ3VpZGVsaW5lcyBvbiB1c2luZyBORVRDT05GIChvciBSRVNUQ09ORikgYXV0aGVudGlj
YXRpb24gYW5kIGF1dGhvcml6YXRpb24gbWVjaGFuaXNtcyB0byBhY2hpZXZlIHNlY3VyaXR5
IHByb3RlY3Rpb24gYW5kIGlzb2xhdGlvbicgYXMgYW4gSW5mb3JtYXRpb25hbCBSRkMuDQog
DQpNaWxlc3RvbmVzOg0KPT09PT09PT09PT0NCkRlYyAyMDE0ICBJbml0aWFsICJQcm9ibGVt
IFN0YXRlbWVudCBhbmQgVXNlIENhc2VzIiBXRyBJLUQNCkZlYiAyMDE1ICBJbml0aWFsICJN
dWx0aS1sYXllciBOZXR3b3JrIEdyYXBoIFlBTkcgTW9kZWwiIFdHIEktRA0KQXByIDIwMTUg
IEluaXRpYWwgc2VydmljZSBzcGVjaWZpYyBkYXRhIG1vZGVsIFdHIEktRHMgDQpNYXkgMjAx
NSAgSW5pdGlhbCAiTWFwcGluZyBHdWlkZWxpbmVzIiBXRyBJLUQNCkp1biAyMDE1ICBTdWJt
aXQgIlByb2JsZW0gU3RhdGVtZW50IGFuZCBVc2UgQ2FzZXMiIEktRCB0byBJRVNHDQpKdWwg
MjAxNSAgSW5pdGlhbCAiQXV0aGVudGljYXRpb24gYW5kIEF1dGhvcml6YXRpb24iIFdHIEkt
RA0KU2VwIDIwMTUgIFN1Ym1pdCAiTXVsdGktbGF5ZXIgTmV0d29yayBHcmFwaCBZQU5HIE1v
ZGVsIiBJLUQgdG8gSUVTRw0KTm92IDIwMTUgIFN1Ym1pdCBzZXJ2aWNlIHNwZWNpZmljIGRh
dGEgbW9kZWwgSS1EcyB0byBJRVNHDQpGZWIgMjAxNiAgU3VibWl0ICJNYXBwaW5nIEd1aWRl
bGluZXMiIEktRCB0byBJRVNHDQpBcHIgMjAxNiAgU3VibWl0ICJBdXRoZW50aWNhdGlvbiBh
bmQgQXV0aG9yaXphdGlvbiIgSS1EIHRvIElFU0cNCiAgDQogDQpUaGFuayB5b3UsDQpUaW5h
DQogDQpGcm9tOiBTdXBhIFttYWlsdG86c3VwYS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh
bGYgT2YgTGl1c2h1Y2hlbmcgKFdpbGwpDQpTZW50OiBUaHVyc2RheSwgU2VwdGVtYmVyIDI1
LCAyMDE0IDc6MzYgUE0NClRvOiBCZW5vaXQgQ2xhaXNlDQpDYzogc3VwYUBpZXRmLm9yZw0K
U3ViamVjdDogUmU6IFtTdXBhXSBBcmVhIGhhbmQtb2ZmLCBhbmQgc29tZSBmcmllbmRseSBh
ZHZpY2UgLi4uDQogDQpIaSBCZW5vaXQsDQogDQpCZWxvdyBpbmxpbmUgcGxlYXNlIHNlZSB0
d28gcGllY2VzIG9mIGNvbXBsZW1lbnRhcnkgYW5zd2VyIGZyb20gbXkgdGVhbSAoc3RhcnRz
IHdpdGggW1dpbGxdKS4gVGhhbmsgeW91IQ0KIA0KUmVnYXJkcywNCldpbGwNCiANCkZyb206
IFN1cGEgW21haWx0bzpzdXBhLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBHZW9y
Z2lvcyBLYXJhZ2lhbm5pcw0KU2VudDogV2VkbmVzZGF5LCBTZXB0ZW1iZXIgMjQsIDIwMTQg
NzozMCBQTQ0KVG86IEJlbm9pdCBDbGFpc2U7IFRpbmEgVFNPVTsgSnVlcmdlbiBTY2hvZW53
YWVsZGVyDQpDYzogWmhlbiBDYW87IHN1cGFAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbU3Vw
YV0gQXJlYSBoYW5kLW9mZiwgYW5kIHNvbWUgZnJpZW5kbHkgYWR2aWNlIC4uLg0KIA0KSGkg
QmVub2l0LA0KIA0KVGhhbmsgeW91IGZvciB5b3VyIGNvbW1lbnRzLg0KUGxlYXNlIHNlZSBp
biBsaW5lLA0KIA0KRnJvbTogU3VwYSBbbWFpbHRvOnN1cGEtYm91bmNlc0BpZXRmLm9yZ10g
T24gQmVoYWxmIE9mIEJlbm9pdCBDbGFpc2UNClNlbnQ6IFdlZG5lc2RheSwgU2VwdGVtYmVy
IDI0LCAyMDE0IDEwOjQxIEFNDQpUbzogR2Vvcmdpb3MgS2FyYWdpYW5uaXM7IFRpbmEgVFNP
VTsgSnVlcmdlbiBTY2hvZW53YWVsZGVyDQpDYzogWmhlbiBDYW87IHN1cGFAaWV0Zi5vcmcN
ClN1YmplY3Q6IFJlOiBbU3VwYV0gQXJlYSBoYW5kLW9mZiwgYW5kIHNvbWUgZnJpZW5kbHkg
YWR2aWNlIC4uLg0KIA0KSGkgR2Vvcmdpb3MsDQpIaSBCZW5vaXQsDQogDQpUaGFua3MgZm9y
IHlvdXIgY29tbWVudHMhDQpQbGVhc2Ugc2VlIGluIGxpbmUuDQogDQogDQpHZW9yZ2lvczog
UGxlYXNlIG5vdGUgdGhhdCB3ZSBhcmUgcmVmZXJyaW5nIHRvIHRoZSBmb2xsb3dpbmcgZmln
dXJlOg0KICAgICAgICAgICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLSAgDQogICAgICAgICAgICAgfCBhcHBsaWNhdGlvbnMgICAgICAgICAgICAgICAgICAg
ICAgICB8DQogICAgICAgICAgICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tDQogICAgICAgICAgICAgICAgICAgICAgIHwgIDwtLS1lbmQgdXNlLiBBcHBsLiAg
IHwNCiAgICAgICAgICAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0gICAgICAgICAgICAgfDwt
LS1lbmQgdXNlLiBBcHBsLiAgIA0KICAgICAgICAgICAgIHwgZW5oYW5jZWQgT1NTICAgICAg
fCAgICAgICAgICAgICB8DQogICAgICAgICAgICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tICAg
ICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICB8ICAgPC0tLSBuZXR3b3JrIHNl
cnZpY2UgfA0KWUFORyBtb2RlbHMgIC9ORVRDT05GIGludGVyZmFjZSAgICAgICAgICAgICAg
ICB8DQogICAgICAgICAgICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0NCiAgICAgICAgICAgICB8ICAgY29udHJvbGxlciAgICAgICAgICAgICAgICAgICAgICAg
fCAgICAgICAgICAgICAgIDwtLS0gIG1hcHBpbmcgbmV0d29yayBzZXJ2aWNlcyANCnRvIHRv
cG9sb2d5DQogICAgICAgICAgICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0NCiAgICAgICAgICAgICAgICAgfCAgICAgICB8ICAgICAgICB8ICAgICAgICAgICAg
ICAgICAgICA8LS0tIA0KZGV2aWNlL2ZlYXR1cmUgc3BlY2lmaWMgWUFORyBtb2RlbHMgLyBO
RVRDT05GIGludGVyZmFjZQ0KICAgICAgICAgICAgIE5FMSAgICBORTIgICBORW4NCkl0J3Mg
bm90IG9idmlvdXMgd2hhdCBhbiAiZW5oYW5jZWQgT1NTIiBpcz8NCiANCkdlb3JnaW9zOiBp
dCByZWxhdGVzIHRvIHRoZSBzeXN0ZW0gdGhhdCBydW5zIG5ldHdvcmsgc2VydmljZXMuIFRo
ZXNlIHNlcnZpY2VzIGFyZSBlbmhhbmNlZCBPcGVyYXRpb25hbCBTdXBwb3J0IFN5c3RlbSAo
T1NTKSBsaWtlIHNlcnZpY2VzIHRoYXQgaGVscCBhIGNvbW11bmljYXRpb24gc2VydmljZSBw
cm92aWRlciB0byBtb25pdG9yLCBjb250cm9sLCBhbmFseXplIGFuZCBtYW5hZ2UgYSBjb21t
dW5pY2F0aW9uIG5ldHdvcmsuIA0KIA0KR2Vvcmdpb3M6IEFjY29yZGluZyB0byB0aGUgcHJv
dmlkZWQgZmlndXJlOiAxKSBuZWVkIHRvIHdvcmsgb24gbmV0d29yayBzZXJ2aWNlIFlhbmcg
bW9kZWxzLCAyIG1hcHBpbmcgbmV0d29yayBzZXJ2aWNlcyB0byB0b3BvbG9neSwgMy4gRGV2
aWNlL2ZlYXR1cmUgc3BlY2lmaWMgWWFuZyBNb2RlbHMsIDQpIGVuZCB1c2VyIHNwZWNpZmlj
IFlhbmsgTW9kZWxzIChvdXQgb2Ygc2NvcGUpLiBUaGUgaW50ZXJmYWNlIGJldHdlZW4gZW5k
IHVzZXIgYXBwbGljYXRpb25zIGFuZCBhIGNvbnRyb2xsZXIsIGFuZCBpbnRlcmZhY2UgYmV0
d2VlbiBlbmQgdXNlciBhcHBsaWNhdGlvbiBhbmQgZW5oYW5jZWQgT1NTLCBhcmUgYWxzbyBv
dXQgb2Ygc2NvcGUuDQpDb25jZXJuaW5nIHlvdXIgbGFzdCBzZW50ZW5jZS4gSSdtIGNvbmZ1
c2VkLg0KV2hhdCBkb2VzIHRoZSBmb2xsb3dpbmcgZGVsaXZlcmFibGUgbWVhbiB0aGVuPw0K
bykgc3BlY2lmeSBhbmQgc3RhbmRhcmRpemUgaG93IE5FVENPTkYvWUFORyAob3IgUkVTVENP
TkYvWUFORykgY2FuIGJlIHVzZWQgdG8gc2VjdXJlbHkgYW5kIGVmZmljaWVudGx5IGRpc3Ry
aWJ1dGUgdXAgdG8gZGF0ZSAoZnJlc2gpIG5ldHdvcmsgZ3JhcGhzIGJldHdlZW4gbmV0d29y
ayBzZXJ2aWNlIHN5c3RlbXMgYW5kIG5ldHdvcmsgbWFuYWdlbWVudCBhbmQgY29udHJvbGxp
bmcgc3lzdGVtcw0KIA0KSXQgcmVsYXRlcyB0byB0aGUgaW50ZXJmYWNlIGJldHdlZW4gdGhl
IG5ldHdvcmsgc2VydmljZSBzeXN0ZW0gKGVuaGFuY2VkIE9TUyBpbiB0aGUgYWJvdmUgZmln
dXJlLg0KUGxlYXNlIG5vdGUgdGhhdCB3ZSBzYXkgdGhhdCB3ZSBpbml0aWFsbHkgb25seSBm
b2N1cyBvbiB0aGlzIGludGVyZmFjZSwgaW4gb3JkZXIgdG8gbmFycm93IGRvd24gdGhlIHNj
b3BlIG9mIHRoaXMgYWN0aXZpdHkNCiANCkhvd2V2ZXIsIGlmIHRoZXJlIGFyZSBzdXBwb3J0
cyB0aGF0IHRoaW5rIHdlIHNob3VsZCBpbml0aWFsbHkgZm9jdXMgYWxzbyBvbiB0aGUgaW50
ZXJmYWNlIGJldHdlZW4gZW5kIHVzZXIgYXBwbGljYXRpb24gYW5kIGNvbnRyb2xsZXIgd2Ug
d2lsbCBhbHNvIGluY2x1ZGUgdGhpcyBpbnRlcmZhY2UgaW4gdGhlIHNjb3BlLg0KIA0KW1dp
bGxdOiBGaXJzdCBvZiBhbGwsIElNT0gsIHRoZSBmaWd1cmVzIGZyb20gQmVub2l0IGFuZCBH
ZW9yZ2lvcyBhcmUgbm90IGluY29tcGF0aWJsZS4gRnJvbSB0aGUgcGVyc3BlY3RpdmUgb2Yg
Y29udHJvbGxlciwgdGhleSBhcmUgZGlmZmVyZW50IGxhdGl0dWRlcyBvZiBub3J0aGJhbmQu
IFRoZSBhcHBsaWNhdGlvbiBhbmQgZW5oYW5jZWQgT1NTIGluIEdlb3JnaW9zIGZpZ3VyZSBj
YW4gYmUgcHV0IHRvZ2V0aGVyIGludG8gYW4gbGFyZ2VyIGFwcGxpY2F0aW9uKiBsYXllciBv
ZiBCZW5vaXShr3MgZmlndXJlLiBUaGUgbmV0d29yayBncmFwaCBpcyBwcm9wb3NlZCB0byBw
cm92aWRlIG5ldHdvcmstd2lkZSBjb25maWd1cmF0aW9uIGNvbnRhaW5pbmcgdGhlIGtleSBp
bmZvcm1hdGlvbiBmb3Igc2VydmljZSBpbnN0YW5jZXMuIE9uZSBleGFtcGxlIGlzLCBmb3Ig
dGhlIEREQyB1c2UgY2FzZSwgdGhlIG5ldHdvcmsgZ3JhcGggY29udGFpbnMgdGhlIGtleSBp
bmZvcm1hdGlvbiBzdWNoIGFzIHRoZSBrZXkgbm9kZSBpbmZvcm1hdGlvbiBvZiB0aGUgcGF0
aCBhbmQgdGhlIGtleSByZXF1aXJlbWVudCBvZiB0cmFmZmljIHN0ZWVyaW5nLiANCiANClJl
Z2FyZGluZyB0byB0aGUgYXBwLCBtYW5hZ2VtZW50IGFwcCwgZW5kIHVzZXIgYXBwIGhlcmUs
IEkgd2FudCB0byBhZGQgc29tZXRoaW5nIHJlbGF0ZWQgdG8gdGhlIGhpc3Rvcnkgb2YgdGhp
cyB3b3JrLiBBdCB0aGUgdmVyeSBiZWdpbm5pbmcsIHdoZW4gdGhpcyB3b3JrIGlzIGNhbGwg
QVBPTkYgYmVmb3JlIFRvcm9udG8gSUVURiBtZWV0aW5nLCB0aGUgZW5kIHVzZXIgYXBwIGlz
IGluIHRoZSBzY29wZS4gSG93ZXZlciwgdGhlcmUgYXJlIG1haW5seSB0aHJlZSByZWFzb25z
IHRoYXQgd2UgcmVtb3ZlIHRoaXMgcG9pbnQ6DQoxLiAgICAgIFRoZSBjb25mbGljdGlvbiB3
aXRoIEFFQ09OLCB3ZSBkaXNjdXNzZWQgd2l0aCBwcm9wb25lbnRzIG9mIEFFQ09OIGFuZCB0
byBhdm9pZCB0aGUgY29uZmxpY3QgYXMgYXQgdGhhdCB0aW1lIHRoZXkgd2VyZSBwcm9wb3Np
bmcgdGhlIGludGVyZmFjZSBmcm9tIGVuZCB1c2VyIGFwcCB0byBuZXR3b3JrIGRldmljZXMu
IExhdGVyIGluIHRoZSBJRVNHIG1lZXRpbmcgaW4gVG9yb250bywgd2Ugc3VjY2Vzc2Z1bGx5
IGNsYXJpZmllZCB0aGUgZGlmZmVyZW5jZXMgYW5kIGdvdCB0aGUgc3VnZ2VzdGlvbiB0byBm
b2N1cyBvbiBtYW5hZ2VtZW50IGFwcC4NCjIuICAgICAgTGFycyBFZ2dlcnQgc2hvd2VkIGhp
cyBjb25jZXJuaW5nIGFib3V0IHRoZSBpbnRlcmZhY2UgYmV0d2VlbiBlbmQgdXNlciBhcHAg
YW5kIG5ldHdvcmsgZGV2aWNlcyBtYXkgbGVhZCB0byBzZWN1cml0eSBpc3N1ZS4gIEtvc3Rh
cyBQZW50aWtvdXNpcyBhbHNvIG1lbnRpb25lZCB0aGlzIHRvIG1lLiANCiANCkhvd2V2ZXIs
IHRoZXNlIGFyZSBvbGQgc3Rvcmllcy4gRHVyaW5nIHRoZSBUb3JvbnRvIEJvRiwgc29tZW9u
ZSBhbHNvIHN1Z2dlc3RlZCB1cyByZS1wdXQgdGhlIGVuZCB1c2VyIGFwcCBpbnRvIGNvcGUu
IEEgbGFyZ2UgYXBwIGxheWVyIGNvbnRhaW5pbmcgYm90aCBlbmQgdXNlciBhcHAgYW5kIG1h
bmFnZW1lbnQgYXBwIG1heSByZXBsYWNlIHRoZSBmaXJzdCB0d28gbGF5ZXJzIGluIHRoZSBv
bGQgNCBsYXllcnMgZmlndXJlLiBIZXJlLCBteSBxdWVzdGlvbiBpcywgYXJlIHlvdSBpbiBm
YXZvciBvZiBhZGRpbmcgZW5kIHVzZXIgYXBwIGludG8gU1VQQSBzY29wZSBvciBub3Q/DQog
DQogDQpSZWdhcmRpbmcgeW91ciBjb21tZW50LCAiIEknbSBub3QgY29udmluY2VkIHdlIGNv
dWxkIHN0YW5kYXJkaXplIHRoZW0sIGFzIHRoZXkgYXJlIG9wZXJhdG9ycyBzcGVjaWZpYywg
YW5kIHdpbGwgYmUgZXZvbHZpbmcgYWxvbmcgdGhlIHRpbWUuIFRoZXJlIGFyZSBtYW55IGRp
ZmZlcmVudCB3YXlzIHRvIGNvbmZpZ3VyZSBhIFZQTiwgZm9yIGV4YW1wbGUuIiBXZXJlIHlv
dSByZWZlcnJpbmcgdG86DQozLiBEZXZpY2UvZmVhdHVyZSBzcGVjaWZpYyBZYW5nIE1vZGVs
cz8NCk5vLCB0aGUgc2VydmljZSBZQU5HIG1vZGVscyANCiANCkdlb3JnaW9zOiBJIHNlZSwg
YnV0IHdlIGNhbiB3b3JrIG9uIFlBTkcgbW9kZWxzIHRoYXQgY2FuIGJlIHVzZWQgZm9yIGEg
bnVtYmVyIG9mIG1haW4gbmV0d29yayBzZXJ2aWNlcywgd2hpY2ggYXJlIGVzc2VudGlhbCBm
b3Igb3BlcmF0b3JzIGFuZCB0aGF0IHRoZXkgd291bGQgbGlrZSB0byBoYXZlIHRoZW0gc3Rh
bmRhcmRpemVkLg0KIA0KIA0KIA0KU2VlIGluLWxpbmUNCkRlYXIgYWxsLA0KIA0KSG9wZSB0
aGlzIHZlcnNpb24gb2YgZHJhZnQgY2hhcnRlciBhZGRyZXNzIG1vc3Qgb2YgdGhlIGNvbW1l
bnRzIGZyb20gdGhlIGxpc3QuDQogDQotLS0tLS0NCiANCiANCiANCiANCkluIHBhcnRpY3Vs
YXIsIGFzIHN0YXJ0aW5nIHBvaW50LCBTVVBBIHdpbGwgb25seSBmb2N1cyBvbiBuZXR3b3Jr
IHNlcnZpY2VzLCB3aGljaCBhcmUgZW5oYW5jZWQgT3BlcmF0aW9uYWwgU3VwcG9ydCBTeXN0
ZW0gKE9TUykgbGlrZSBzZXJ2aWNlcyB0aGF0IGhlbHAgYSBjb21tdW5pY2F0aW9uIHNlcnZp
Y2UgcHJvdmlkZXIgdG8gbW9uaXRvciwgY29udHJvbCwgYW5hbHl6ZSBhbmQgbWFuYWdlIGEg
Y29tbXVuaWNhdGlvbiBuZXR3b3JrLiBUaGUgc3lzdGVtcyB0aGF0IGFyZSBydW5uaXVuZyBz
dWNoIG5ldHdvcmsgc2VydmljZXMgYXJlIGRlbm90ZWQgaW4gdGhpcyBkb2N1bWVudCBhcyBO
ZXR3b3JrIFNlcnZpY2UgU3lzdGVtcy4NCkVhY2ggbmV0d29yayBzZXJ2aWNlIGNhbiBiZSBy
ZXByZXNlbnRlZCBieSBhIGNsYXNzaWZpZWQgYXBwbGljYXRpb24gYmFzZWQgUE9MSUNZIG1v
ZGVsLCBzaW5jZSBpdCBjYW4gbW9kZWwgdGhlIGdyb3VwIG9mIGRlbWFuZHMgd2hpY2ggYXJl
IFNIQVJFRCBhbmQgVU5JRklFRCBhbmQgYXJlIGNvbWluZyBmcm9tIGEgYnVuZGxlIG9mIGFw
cGxpY2F0aW9ucyB0aGF0IGltcG9zZSBzaW1pbGFyIHJlcXVpcmVtZW50cyBvbiB0aGUgY29t
bXVuaWNhdGlvbiBuZXR3b3JrLg0KSSdtIGFmcmFpZCBJIGRvbid0IHVuZGVyc3RhbmQgKGxp
a2UgSqi5cmdlbikNCiANCkdlb3JnaW9zOiBXaGF0IHdlIHdhbnQgdG8gc2F5IGlzIHRoYXQg
dGhlcmUgYXJlIGFwcGxpY2F0aW9ucyB0aGF0IGltcG9zZSBzaW1pbGFyIHJlcXVpcmVtZW50
cyBvbiB0aGUgY29tbXVuaWNhdGlvbiBuZXR3b3JrLiBGb3IgZWFjaCBncm91cCBvZiBzdWNo
IGJ1bGsgb2YgYXBwbGljYXRpb25zIGEgbmV0d29yayBzZXJ2aWNlIGNhbiBiZSBkZWZpbmVk
IHRoYXQgY2FuIGJlIHJlcHJlc2VudGVkIGJ5IGEgc2VydmljZSBwb2xpY3kgbW9kZWwgKGku
ZS4sIGl0cyBhY3Rpb25zIGFuZCBjb25zdHJhaW50cykuDQogDQogDQpHZW9yZ2lvczogVGhh
bmtzIGZvciB0aGUgc3VnZ2VzdGlvbiwgdGhlIHRleHQgbmVlZHMgdG8gYmUgcmVwaHJhc2Vk
LCBzZWUgYmVsb3c6DQpFYWNoIG5ldHdvcmsgc2VydmljZSBjYW4gYmUgcmVwcmVzZW50ZWQg
YnkgYW4gYXBwbGljYXRpb24gYmFzZWQgUE9MSUNZIG1vZGVsLCB3aGljaCBpcyBVTklGSUVE
IGFuZCBTSEFSRUQsIHNpbmNlIGl0IGNhbiBtb2RlbCB0aGUgZ3JvdXAgb2YgZGVtYW5kcyAo
aS5lLCBhY3Rpb25zIGFuZCBjb25zdHJhaW50cykgdGhhdCBhcmUgY29taW5nIGZyb20gYSBi
dW5kbGUgb2YgYXBwbGljYXRpb25zIHRoYXQgaW1wb3NlIHNpbWlsYXIgcmVxdWlyZW1lbnRz
IG9uIHRoZSBjb21tdW5pY2F0aW9uIG5ldHdvcmsuDQpJIHN0aWxsIGRvbid0IHVuZGVyc3Rh
bmQuIHdoYXQgIlVOSUZJRUQgYW5kIFNIQVJFRCIgbWVhbi4NCiANCkdlb3JnaW9zOiB0aGUg
dGVybXMgobBVTklGSUVEobEgYW5kIKGwU0hBUkVEobGhsSByZWxhdGUgdG8gdGhlIHdheSBv
ZiBob3cgdGhlIHNlcnZpY2UgcG9saWN5IG1vZGVsIGlzIGdlbmVyYXRlZCwgc2luY2UgaXQg
Z3JvdXBzIGFuZCBpdCB1bmlmaWVzIGFuZCBzaGFyZXMgdGhlIHNpbWlsYXIgcmVxdWlyZW1l
bnRzIGltcG9zZWQgYnkgYSBidWxrIG9mIGFwcGxpY2F0aW9ucy4NCiANCiANCiANCiANCiAN
CiANCiANCigyKSB0cmFuc3BvcnRpbmcgbW9kZWwgaW5zdGFuY2VzIGVpdGhlciB1c2luZyBO
RVRDT05GIG9yIFJFU1RDT05GIGFuZCAoMykgcHJvdmlkaW5nIGd1aWRlbGluZXMgb24gQVVU
T01BVElDQUxMWSBtYXBwaW5nIHBvbGljaWVzIHRvIGF0dHJpYnV0ZXMgb2YgdGhlIG5ldHdv
cmsgZ3JhcGhzLg0KIA0KQWx0aG91Z2ggc29tZSBJRVRGIHdvcmtpbmcgZ3JvdXBzIGhhdmUg
c3RhcnRlZCB3b3JrIHJlbGF0aW5nIHRvIHRoZSBkZXNjcmlwdGlvbiBvZiB2YXJpb3VzIHRv
cG9sb2dpZXMgc3VjaCBhcyBJMlJTIChMM2FuZCByb3V0aW5nIHRvcG9sb2dpZXMpLCBBTFRP
IChjb3N0IG1hcHMpLCBTRkMgKHNlcnZpY2UgY2hhaW4pLCBub25lIG9mIHRoZXNlIGdyb3Vw
cyBhaW0gYXQgb2ZmZXJpbmcgdHJ1bHkgZ2VuZXJpYyB0b3BvbG9neSBtb2RlbHMgZm9yIHRo
ZSBzdGFuZGFyZCBub3J0aGJvdW5kIGludGVyZmFjZS4NClNVUEEgd2lsbCB3b3JrIG9uIGRl
ZmluaW5nIGludGVyZmFjZXMgYmFzZWQgb24gdGhlIGNvbmNlcHQgb2YgbmV0d29yayBncmFw
aCwgYW4gZW50aXR5IGRlc2NyaWJpbmcgYW4gYXJiaXRyYXJ5IHRvcG9sb2d5IG9mIG5vZGVz
IGFuZCBsaW5rcyBhdCBhbnkgbGV2ZWwgb2YgZ3JhbnVsYXJpdHkuIFN1Y2ggYSBncmFwaCBt
YXkgZGVzY3JpYmUsIGZvciBleGFtcGxlLCBhIHBoeXNpY2FsIHRvcG9sb2d5LCBhIHNlcnZp
Y2UgdG9wb2xvZ3kgb3IgdGhlIHJlbGF0aW9uc2hpcHMgYmV0d2VlbiBkYXRhY2VudGVycy4g
QW55IG5ldHdvcmsgdG9wb2xvZ3kgZGF0YSBtb2RlbHMgb3IgcG9saWN5IG1vZGVscyB0aGF0
IGhhdmUgYmVlbiBkZWZpbmVkIChvciBhcmUgYmVpbmcgZGVmaW5lZCkgd2l0aGluIHRoZSBJ
RVRGIHdpbGwgYmUgcmV1c2VkIGluIFNVUEEgYXMgbXVjaCBhcyBwb3NzaWJsZS4NCkluIGFk
ZGl0aW9uIHRvIHRoZSBhYm92ZSwgcG9saWNpZXMgbWF5IGJlIGRlZmluZWQgYW5kIGFwcGxp
ZWQgdG8gYSBuZXR3b3JrIGdyYXBoLiBUaGVzZSBhcHBsaWNhdGlvbiBiYXNlZCBwb2xpY2ll
cyBhcmUgYWN0aW9ucyBvciBjb25zdHJhaW50cyBnZW5lcmF0ZWQgYnkgTmV0d29yayBTZXJ2
aWNlIFN5c3RlbXMuIFRoZXkgYXJlIHRoZW4gbWFwcGVkIGZyb20gdGhlIG5ldHdvcmsgZ3Jh
cGggaW5zdGFuY2UgaW50byBzcGVjaWZpYyBuZXR3b3JrIG1hbmFnZW1lbnQgcG9saWNpZXMg
dG93YXJkIG5ldHdvcmsgY29tcG9uZW50cy4NCiANCiANCkdlb3JnaW9zOiB0aGUgYWJvdmUg
dGV4dCBpcyBub3QgY2xlYXIuIFRoZXJlZm9yZSwgSSBhbSByZXBocmFzaW5nIGl0Og0KPT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpUaGUgbWFpbiBn
b2FsIG9mIFNVUEEgaXMgdG8gcHJvdmlkZSBhcHBsaWNhdGlvbiBiYXNlZCBwb2xpY2llcyBh
bmQgbWVhbnMgdG8gbW9kZWwgYW5kIHByb2dyYW0gdGhlIGFic3RyYWN0IHZpZXcgb2YgbmV0
d29yayBpbmZyYXN0cnVjdHVyZSBhbmQgc2VydmljZSBmdW5jdGlvbiBpbnRlcmRlcGVuZGVu
Y2llcyBpbiBvcmRlciB0byBzdXBwb3J0IGFuZCBBVVRPTUFUSUNBTExZIGZlZWQgbmV0d29y
ayBtYW5hZ2VtZW50IGFuZCBjb250cm9sbGluZyBwb2xpY2llcy4gVGhpcyBjYW4gYmUgcmVh
bGl6ZWQgYnk6DQogDQooMSkgbW9kZWxpbmcgdGhlIG5ldHdvcmsgZ3JhcGgsIHdoaWNoIGFt
b25nIG90aGVycyBpbmNsdWRlIHBvbGljeSBtb2RlbHMsIGRhdGEgbW9kZWxzIGFuZCBhcHBs
aWNhdGlvbiBiYXNlZCBwb2xpY2llcywgdXNpbmcgWUFORywgDQogDQooMikgYXBwbHlpbmcg
TkVUQ09ORiAob3IgUkVTVENPTkYpIHRvIGVuYWJsZSBkaXNzZW1pbmF0aW9uIG9mIHVwIHRv
IGRhdGUgKGZyZXNoKSBuZXR3b3JrIGdyYXBocyBpbiBhIHNlY3VyZSBhbmQgZWZmaWNpZW50
IG1hbm5lciBiZXR3ZWVuIG5ldHdvcmsgc2VydmljZSBzeXN0ZW1zIGFuZCBuZXR3b3JrIG1h
bmFnZW1lbnQgYW5kIGNvbnRyb2xsaW5nIHN5c3RlbXMsIA0KImJldHdlZW4gbmV0d29yayBz
ZXJ2aWNlIHN5c3RlbXMgYW5kIG5ldHdvcmsgbWFuYWdlbWVudCBhbmQgY29udHJvbGxpbmcg
c3lzdGVtIi4gV2hhdCBhcmUgdGhvc2U/IEkgZG9uJ3Qgc2VlIHRoZW0gaW4geW91ciBmaWd1
cmUuDQpBbHNvLCB3aHkgc2hvdWxkIGFsbCBvZiB0aGVzZSBuZWVkIHRvIGtub3cgYWJvdXQg
dGhlIHRvcG9sb2d5Pw0KIA0KR2Vvcmdpb3M6IEluIHRoZSBmaWd1cmUsIHRoZSBlbmhhbmNl
ZCBPU1MgcmVwcmVzZW50cyB0aGUgbmV0d29yayBzZXJ2aWNlIHN5c3RlbSBhbmQgdGhlIGNv
bnRyb2xsZXIgcmVwcmVzZW50cyB0aGUgbmV0d29yayBtYW5hZ2VtZW50IGFuZCBjb250cm9s
bGluZyBzeXN0ZW0uDQpJbiB0aGlzIGNvbnRleHQsIG5ldHdvcmsgc2VydmljZXMgY2FuIGJl
IHVzZWQgdG8gcHJvdmlkZSB0aGUgcmVxdWlyZWQgIGNvbmZpZ3VyYXRpb24gYW5kIGFwcGxp
Y2F0aW9uIHByb2dyYW1taW5nIGludGVyZmFjZXMgdG8gc2VydmljZSBkZXZlbG9wZXJzLiBT
dWJzZXF1ZW50bHksIGEgbmV0d29yayBzZXJ2aWNlIGNhbiB1c2UgdGhlIGFwcGxpY2F0aW9u
IGJhc2VkIGRlbWFuZHMgKGZvciBhY3Rpb25zIGFuZCBjb25zdHJhaW50cykgYW5kIHBvc3Np
Ymx5IHVwZGF0ZSBpdHMgYXNzb2NpYXRlZCBuZXR3b3JrIHNlcnZpY2UgIGF0dHJpYnV0ZXMu
IEV4YW1wbGVzIG9mIG5ldHdvcmsgc2VydmljZXMgdGhhdCBjYW4gbW9kaWZ5ICB0aGUgbmV0
d29yayBzZXJ2aWNlIGF0dHJpYnV0ZXMgYXJlIGZvciBleGFtcGxlLCBMM1ZQTiBjb25maWd1
cmF0aW9uIGFuZCBJUHY2IHRyYW5zaXRpb25zLiANCkZvciBlYWNoIG5ldHdvcmsgc2Vydmlj
ZSBpbnN0YW5jZSBhIG5ldHdvcmsgZ3JhcGggbmVlZHMgdG8gYmUgZ2VuZXJhdGVkIGFuZCBt
YWludGFpbmVkLiANClRoZSB1cCB0byBkYXRlIG5ldHdvcmsgZ3JhcGggbmVlZHMgdG8gKDEp
IGJlIGNvbW11bmljYXRlZCBiZXR3ZWVuIHRoZSAgbmV0d29yayBzZXJ2aWNlIHN5c3RlbXMg
YW5kIHRoZSBuZXR3b3JrICAgbWFuYWdlbWVudCBhbmQgY29udHJvbGxpbmcgc3lzdGVtcywg
KDIpIG1hcCB0aGUgYXR0cmlidXRlcyBvZiB0aGUgbmV0d29yayBzZXJ2aWNlIGdyYXBoIGlu
dG8gc3BlY2lmaWMgbmV0d29yayBtYW5hZ2VtZW50IHBvbGljaWVzLg0KW1dpbGxdIFRvIG1v
ZGVsaW5nIHNlcnZpY2UgcmVxdWlyZW1lbnQgYW5kIGNyZWF0ZSBzZXJ2aWNlIGluc3RhbmNl
cywgQVBQIG5lZWRzIGEgdmlldyBvZiB0b3BvbG9neSB0byBmb3JtIG5ldHdvcmsgY29uZmln
dXJhdGlvbiBhY2NvcmRpbmcgdG8gdGhlIGtleSBpbmZvcm1hdGlvbiBvZiBkZXZpY2VzIHRv
cG9sb2d5LiBUaGlzIGNvbmZpZ3VyYXRpb24gaXMgZXZlbnR1YWxseSBtYXBwZWQgdG8gdGhl
IHNlbGVjdGVkIG5ldHdvcmsgZGV2aWNlcyBhY2NvcmRpbmcgdG8gdG9wb2xvZ3kgcHJvdmlk
ZWQgYnkgU1VQQS4NCiANCkJlc3QgcmVnYXJkcywNCkdlb3JnaW9zDQogDQogDQogDQoNCg0K
UmVnYXJkcywgQmVub2l0DQoNCsjnufvE+rTtzvO908rVwcu4w9PKvP6jrMfrzai5/bXn19PT
yrz+waK8tM2o1qrO0sPHoaPH67vYuLTTyrz+tb1ocXMtc3BtY0BjaGluYXVuaWNvbS5jbqOs
vLS/ydLUzcu2qbTL08q8/qGjztLDx72rwaK8tL2rxPq1xNDFz6K0087Sw8e1xLeiy83Ev8K8
1tDJvrP9oaMNCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxl
YXNlIG5vdGlmeSB1cyBpbW1lZGlhdGVseSBieSBlLW1haWwuIFBsZWFzZSByZXBseSB0byBo
cXMtc3BtY0BjaGluYXVuaWNvbS5jbiBpZiB5b3Ugd2FudCB0byB1bnN1YnNjcmliZSBmcm9t
IHRoaXMgbWFpbC4gV2Ugd2lsbCBpbW1lZGlhdGVseSByZW1vdmUgeW91ciBpbmZvcm1hdGlv
biBmcm9tIG91ciBzZW5kaW5nIGNhdGFsb2d1ZS4NCg==

--=====003_Dragon126160820723_=====
Content-Type: text/html; charset="gb2312"
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u
YWwvL0VOIj4NCjxIVE1MIHhtbG5zOm8+PEhFQUQ+DQo8TUVUQSBjb250ZW50PSJ0ZXh0L2h0
bWw7IGNoYXJzZXQ9Z2IyMzEyIiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxNRVRBIG5h
bWU9R0VORVJBVE9SIGNvbnRlbnQ9Ik1TSFRNTCA4LjAwLjc2MDEuMTc1MTQiPg0KPFNUWUxF
PkBmb250LWZhY2Ugew0KCWZvbnQtZmFtaWx5OiBTaW1TdW47DQp9DQpAZm9udC1mYWNlIHsN
Cglmb250LWZhbWlseTogQ2FtYnJpYSBNYXRoOw0KfQ0KQGZvbnQtZmFjZSB7DQoJZm9udC1m
YW1pbHk6IEFyaWFsIFVuaWNvZGUgTVM7DQp9DQpAZm9udC1mYWNlIHsNCglmb250LWZhbWls
eTogQ2FsaWJyaTsNCn0NCkBmb250LWZhY2Ugew0KCWZvbnQtZmFtaWx5OiBUYWhvbWE7DQp9
DQpAZm9udC1mYWNlIHsNCglmb250LWZhbWlseTogU2ltU3VuOw0KfQ0KQGZvbnQtZmFjZSB7
DQoJZm9udC1mYW1pbHk6IEZyZWVzdHlsZSBTY3JpcHQ7DQp9DQpAZm9udC1mYWNlIHsNCglm
b250LWZhbWlseTogQEFyaWFsIFVuaWNvZGUgTVM7DQp9DQpAZm9udC1mYWNlIHsNCglmb250
LWZhbWlseTogQ29uc29sYXM7DQp9DQpAcGFnZSBXb3JkU2VjdGlvbjEge3NpemU6IDYxMi4w
cHQgNzkyLjBwdDsgbWFyZ2luOiA3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7IH0NClAu
TXNvTm9ybWFsIHsNCglNQVJHSU46IDBjbSAwY20gMHB0OyBGT05ULUZBTUlMWTogIlRpbWVz
IE5ldyBSb21hbiIsInNlcmlmIjsgQ09MT1I6IGJsYWNrOyBGT05ULVNJWkU6IDEycHQNCn0N
CkxJLk1zb05vcm1hbCB7DQoJTUFSR0lOOiAwY20gMGNtIDBwdDsgRk9OVC1GQU1JTFk6ICJU
aW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7IENPTE9SOiBibGFjazsgRk9OVC1TSVpFOiAxMnB0
DQp9DQpESVYuTXNvTm9ybWFsIHsNCglNQVJHSU46IDBjbSAwY20gMHB0OyBGT05ULUZBTUlM
WTogIlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsgQ09MT1I6IGJsYWNrOyBGT05ULVNJWkU6
IDEycHQNCn0NCkE6bGluayB7DQoJQ09MT1I6IGJsdWU7IFRFWFQtREVDT1JBVElPTjogdW5k
ZXJsaW5lOyBtc28tc3R5bGUtcHJpb3JpdHk6IDk5DQp9DQpTUEFOLk1zb0h5cGVybGluayB7
DQoJQ09MT1I6IGJsdWU7IFRFWFQtREVDT1JBVElPTjogdW5kZXJsaW5lOyBtc28tc3R5bGUt
cHJpb3JpdHk6IDk5DQp9DQpBOnZpc2l0ZWQgew0KCUNPTE9SOiBwdXJwbGU7IFRFWFQtREVD
T1JBVElPTjogdW5kZXJsaW5lOyBtc28tc3R5bGUtcHJpb3JpdHk6IDk5DQp9DQpTUEFOLk1z
b0h5cGVybGlua0ZvbGxvd2VkIHsNCglDT0xPUjogcHVycGxlOyBURVhULURFQ09SQVRJT046
IHVuZGVybGluZTsgbXNvLXN0eWxlLXByaW9yaXR5OiA5OQ0KfQ0KUFJFIHsNCglNQVJHSU46
IDBjbSAwY20gMHB0OyBGT05ULUZBTUlMWTogIlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsg
Q09MT1I6IGJsYWNrOyBGT05ULVNJWkU6IDEycHQ7IG1zby1zdHlsZS1wcmlvcml0eTogOTk7
IG1zby1zdHlsZS1saW5rOiAiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciINCn0NClAuTXNvQWNl
dGF0ZSB7DQoJTUFSR0lOOiAwY20gMGNtIDBwdDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcg
Um9tYW4iLCJzZXJpZiI7IENPTE9SOiBibGFjazsgRk9OVC1TSVpFOiA4cHQ7IG1zby1zdHls
ZS1wcmlvcml0eTogOTk7IG1zby1zdHlsZS1saW5rOiAiQmFsbG9vbiBUZXh0IENoYXIiDQp9
DQpMSS5Nc29BY2V0YXRlIHsNCglNQVJHSU46IDBjbSAwY20gMHB0OyBGT05ULUZBTUlMWTog
IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsgQ09MT1I6IGJsYWNrOyBGT05ULVNJWkU6IDhw
dDsgbXNvLXN0eWxlLXByaW9yaXR5OiA5OTsgbXNvLXN0eWxlLWxpbms6ICJCYWxsb29uIFRl
eHQgQ2hhciINCn0NCkRJVi5Nc29BY2V0YXRlIHsNCglNQVJHSU46IDBjbSAwY20gMHB0OyBG
T05ULUZBTUlMWTogIlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsgQ09MT1I6IGJsYWNrOyBG
T05ULVNJWkU6IDhwdDsgbXNvLXN0eWxlLXByaW9yaXR5OiA5OTsgbXNvLXN0eWxlLWxpbms6
ICJCYWxsb29uIFRleHQgQ2hhciINCn0NClNQQU4uSFRNTFByZWZvcm1hdHRlZENoYXIgew0K
CUZPTlQtRkFNSUxZOiBDb25zb2xhczsgQ09MT1I6IGJsYWNrOyBtc28tc3R5bGUtcHJpb3Jp
dHk6IDk5OyBtc28tc3R5bGUtbGluazogIkhUTUwgUHJlZm9ybWF0dGVkIjsgbXNvLXN0eWxl
LW5hbWU6ICJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIg0KfQ0KUC5IVE1MIHsNCglNQVJHSU46
IDBjbSAwY20gMHB0OyBGT05ULUZBTUlMWTogIlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsg
Q09MT1I6IGJsYWNrOyBGT05ULVNJWkU6IDEycHQ7IG1zby1zdHlsZS1saW5rOiAiSFRNTCDU
pMnouPHKvUNoYXIiOyBtc28tc3R5bGUtbmFtZTogIkhUTUwg1KTJ6Ljxyr0iDQp9DQpMSS5I
VE1MIHsNCglNQVJHSU46IDBjbSAwY20gMHB0OyBGT05ULUZBTUlMWTogIlRpbWVzIE5ldyBS
b21hbiIsInNlcmlmIjsgQ09MT1I6IGJsYWNrOyBGT05ULVNJWkU6IDEycHQ7IG1zby1zdHls
ZS1saW5rOiAiSFRNTCDUpMnouPHKvUNoYXIiOyBtc28tc3R5bGUtbmFtZTogIkhUTUwg1KTJ
6Ljxyr0iDQp9DQpESVYuSFRNTCB7DQoJTUFSR0lOOiAwY20gMGNtIDBwdDsgRk9OVC1GQU1J
TFk6ICJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7IENPTE9SOiBibGFjazsgRk9OVC1TSVpF
OiAxMnB0OyBtc28tc3R5bGUtbGluazogIkhUTUwg1KTJ6Ljxyr1DaGFyIjsgbXNvLXN0eWxl
LW5hbWU6ICJIVE1MINSkyei48cq9Ig0KfQ0KU1BBTi5IVE1MQ2hhciB7DQoJRk9OVC1GQU1J
TFk6ICJDb3VyaWVyIE5ldyI7IENPTE9SOiBibGFjazsgbXNvLXN0eWxlLXByaW9yaXR5OiA5
OTsgbXNvLXN0eWxlLWxpbms6ICJIVE1MINSkyei48cq9IjsgbXNvLXN0eWxlLW5hbWU6ICJI
VE1MINSkyei48cq9Q2hhciINCn0NClNQQU4uRW1haWxTdHlsZTIxIHsNCglGT05ULUZBTUlM
WTogIkNhbGlicmkiLCJzYW5zLXNlcmlmIjsgQ09MT1I6ICMxZjQ5N2Q7IG1zby1zdHlsZS10
eXBlOiBwZXJzb25hbA0KfQ0KU1BBTi5FbWFpbFN0eWxlMjIgew0KCUZPTlQtRkFNSUxZOiAi
Q2FsaWJyaSIsInNhbnMtc2VyaWYiOyBDT0xPUjogIzFmNDk3ZDsgbXNvLXN0eWxlLXR5cGU6
IHBlcnNvbmFsDQp9DQpTUEFOLkVtYWlsU3R5bGUyMyB7DQoJRk9OVC1GQU1JTFk6ICJDYWxp
YnJpIiwic2Fucy1zZXJpZiI7IENPTE9SOiAjMWY0OTdkOyBtc28tc3R5bGUtdHlwZTogcGVy
c29uYWwNCn0NClNQQU4uRW1haWxTdHlsZTI0IHsNCglGT05ULUZBTUlMWTogIkFyaWFsIFVu
aWNvZGUgTVMiLCJzYW5zLXNlcmlmIjsgQ09MT1I6ICMxZjQ5N2Q7IG1zby1zdHlsZS10eXBl
OiBwZXJzb25hbC1yZXBseQ0KfQ0KU1BBTi5CYWxsb29uVGV4dENoYXIgew0KCUZPTlQtRkFN
SUxZOiBTaW1TdW47IENPTE9SOiBibGFjazsgbXNvLXN0eWxlLXByaW9yaXR5OiA5OTsgbXNv
LXN0eWxlLWxpbms6ICJCYWxsb29uIFRleHQiOyBtc28tc3R5bGUtbmFtZTogIkJhbGxvb24g
VGV4dCBDaGFyIg0KfQ0KLk1zb0NocERlZmF1bHQgew0KCUZPTlQtU0laRTogMTBwdDsgbXNv
LXN0eWxlLXR5cGU6IGV4cG9ydC1vbmx5DQp9DQpESVYuV29yZFNlY3Rpb24xIHsNCglwYWdl
OiBXb3JkU2VjdGlvbjENCn0NCjwvU1RZTEU+DQo8IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N
CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht
bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0
IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v
OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPE1FVEEgbmFtZT1HRU5FUkFUT1Ig
Y29udGVudD0iTVNIVE1MIDYuMDAuMjkwMC4yMTgwIj4NCjxTVFlMRT5AZm9udC1mYWNlIHsN
Cglmb250LWZhbWlseTogy87M5TsNCn0NCkBmb250LWZhY2Ugew0KCWZvbnQtZmFtaWx5OiBW
ZXJkYW5hOw0KfQ0KQGZvbnQtZmFjZSB7DQoJZm9udC1mYW1pbHk6IEDLzszlOw0KfQ0KQHBh
Z2UgU2VjdGlvbjEge3NpemU6IDU5NS4zcHQgODQxLjlwdDsgbWFyZ2luOiA3Mi4wcHQgOTAu
MHB0IDcyLjBwdCA5MC4wcHQ7IGxheW91dC1ncmlkOiAxNS42cHQ7IH0NClAuTXNvTm9ybWFs
IHsNCglURVhULUpVU1RJRlk6IGludGVyLWlkZW9ncmFwaDsgVEVYVC1BTElHTjoganVzdGlm
eTsgTUFSR0lOOiAwY20gMGNtIDBwdDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9tYW4i
OyBGT05ULVNJWkU6IDEwLjVwdA0KfQ0KTEkuTXNvTm9ybWFsIHsNCglURVhULUpVU1RJRlk6
IGludGVyLWlkZW9ncmFwaDsgVEVYVC1BTElHTjoganVzdGlmeTsgTUFSR0lOOiAwY20gMGNt
IDBwdDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9tYW4iOyBGT05ULVNJWkU6IDEwLjVw
dA0KfQ0KRElWLk1zb05vcm1hbCB7DQoJVEVYVC1KVVNUSUZZOiBpbnRlci1pZGVvZ3JhcGg7
IFRFWFQtQUxJR046IGp1c3RpZnk7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IEZPTlQtRkFNSUxZ
OiAiVGltZXMgTmV3IFJvbWFuIjsgRk9OVC1TSVpFOiAxMC41cHQNCn0NCkE6bGluayB7DQoJ
Q09MT1I6IGJsdWU7IFRFWFQtREVDT1JBVElPTjogdW5kZXJsaW5lDQp9DQpTUEFOLk1zb0h5
cGVybGluayB7DQoJQ09MT1I6IGJsdWU7IFRFWFQtREVDT1JBVElPTjogdW5kZXJsaW5lDQp9
DQpBOnZpc2l0ZWQgew0KCUNPTE9SOiBwdXJwbGU7IFRFWFQtREVDT1JBVElPTjogdW5kZXJs
aW5lDQp9DQpTUEFOLk1zb0h5cGVybGlua0ZvbGxvd2VkIHsNCglDT0xPUjogcHVycGxlOyBU
RVhULURFQ09SQVRJT046IHVuZGVybGluZQ0KfQ0KU1BBTi5FbWFpbFN0eWxlMTcgew0KCUZP
TlQtU1RZTEU6IG5vcm1hbDsgRk9OVC1GQU1JTFk6IFZlcmRhbmE7IENPTE9SOiB3aW5kb3d0
ZXh0OyBGT05ULVdFSUdIVDogbm9ybWFsOyBURVhULURFQ09SQVRJT046IG5vbmU7IG1zby1z
dHlsZS10eXBlOiBwZXJzb25hbC1jb21wb3NlDQp9DQpESVYuU2VjdGlvbjEgew0KCXBhZ2U6
IFNlY3Rpb24xDQp9DQpVTktOT1dOIHsNCglGT05ULVNJWkU6IDEwcHQNCn0NCkJMT0NLUVVP
VEUgew0KCU1BUkdJTi1UT1A6IDBweDsgTUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tTEVG
VDogMmVtDQp9DQpPTCB7DQoJTUFSR0lOLVRPUDogMHB4OyBNQVJHSU4tQk9UVE9NOiAwcHgN
Cn0NClVMIHsNCglNQVJHSU4tVE9QOiAwcHg7IE1BUkdJTi1CT1RUT006IDBweA0KfQ0KPC9T
VFlMRT4NCjwvSEVBRD4NCjxCT0RZIHN0eWxlPSJNQVJHSU46IDEwcHg7IEZPTlQtRkFNSUxZ
OiB2ZXJkYW5hOyBGT05ULVNJWkU6IDEwcHQiPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMDgw
IHNpemU9MiBmYWNlPVZlcmRhbmE+DQo8UCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdDsg
bXNvLXBhZ2luYXRpb246IHdpZG93LW9ycGhhbiIgDQpjbGFzcz1Nc29Ob3JtYWw+PEZPTlQg
ZmFjZT1DYWxpYnJpPjxTUEFOIA0Kc3R5bGU9IkNPTE9SOiAjMWY0OTdkOyBtc28tYmlkaS1m
b250LXNpemU6IDEwLjVwdDsgbXNvLWFzY2lpLWZvbnQtZmFtaWx5OiBDYWxpYnJpOyBtc28t
ZmFyZWFzdC1mb250LWZhbWlseTogy87M5TsgbXNvLWhhbnNpLWZvbnQtZmFtaWx5OiBDYWxp
YnJpOyBtc28tYmlkaS1mb250LWZhbWlseTogQ2FsaWJyaTsgbXNvLWZvbnQta2VybmluZzog
MHB0IiANCmxhbmc9RU4tVVM+SGkgYWxsLDwvU1BBTj48U1BBTiANCnN0eWxlPSJGT05ULUZB
TUlMWTogJ1RpbWVzIE5ldyBSb21hbicsJ3NlcmlmJzsgQ09MT1I6IGJsYWNrOyBtc28tYmlk
aS1mb250LXNpemU6IDEwLjVwdDsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IMvOzOU7IG1z
by1mb250LWtlcm5pbmc6IDBwdCIgDQpsYW5nPUVOLVVTPjxvOnA+PC9vOnA+PC9TUEFOPjwv
Rk9OVD48L1A+DQo8UCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdDsgbXNvLXBhZ2luYXRp
b246IHdpZG93LW9ycGhhbiIgDQpjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1DYWxpYnJp
PjxTUEFOIA0Kc3R5bGU9IkNPTE9SOiAjMWY0OTdkOyBtc28tYmlkaS1mb250LXNpemU6IDEw
LjVwdDsgbXNvLWFzY2lpLWZvbnQtZmFtaWx5OiBDYWxpYnJpOyBtc28tZmFyZWFzdC1mb250
LWZhbWlseTogy87M5TsgbXNvLWhhbnNpLWZvbnQtZmFtaWx5OiBDYWxpYnJpOyBtc28tYmlk
aS1mb250LWZhbWlseTogQ2FsaWJyaTsgbXNvLWZvbnQta2VybmluZzogMHB0IiANCmxhbmc9
RU4tVVM+Jm5ic3A7PC9TUEFOPjxTUEFOIA0Kc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGltZXMg
TmV3IFJvbWFuJywnc2VyaWYnOyBDT0xPUjogYmxhY2s7IG1zby1iaWRpLWZvbnQtc2l6ZTog
MTAuNXB0OyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogy87M5TsgbXNvLWZvbnQta2Vybmlu
ZzogMHB0IiANCmxhbmc9RU4tVVM+PG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD4NCjxQ
IHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0OyBtc28tcGFnaW5hdGlvbjogd2lkb3ctb3Jw
aGFuIiANCmNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUNhbGlicmk+PFNQQU4gDQpzdHls
ZT0iQ09MT1I6ICMxZjQ5N2Q7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTAuNXB0OyBtc28tYXNj
aWktZm9udC1mYW1pbHk6IENhbGlicmk7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiDLzszl
OyBtc28taGFuc2ktZm9udC1mYW1pbHk6IENhbGlicmk7IG1zby1iaWRpLWZvbnQtZmFtaWx5
OiBDYWxpYnJpOyBtc28tZm9udC1rZXJuaW5nOiAwcHQiIA0KbGFuZz1FTi1VUz5JIGF0dGVu
ZGVkIHRoZSBlLW1lZXRpbmcgbGFzdCBuaWdodCBhbmQgbGVhcm5lZCBhIGxvdC4gVGhhbmsg
eW91IGZvciANCnlvdXIgZWZmb3J0cy4gVGhlIGxhdGVzdCBjaGFydGVyIGlzIG5vdyBjbGVh
cmVyIGFuZCBmaW5lIGZyb20gbXkgc2lkZS4gTGF0ZXIgSSANCnBsYW4gdG8gdXBkYXRlIHRo
ZSBEREMgdXNlIGNhc2UgYWNjb3JkaW5nbHkuPC9TUEFOPjxTUEFOIA0Kc3R5bGU9IkZPTlQt
RkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJywnc2VyaWYnOyBDT0xPUjogYmxhY2s7IG1zby1i
aWRpLWZvbnQtc2l6ZTogMTAuNXB0OyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogy87M5Tsg
bXNvLWZvbnQta2VybmluZzogMHB0IiANCmxhbmc9RU4tVVM+PG86cD48L286cD48L1NQQU4+
PC9GT05UPjwvUD4NCjxQIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0OyBtc28tcGFnaW5h
dGlvbjogd2lkb3ctb3JwaGFuIiANCmNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUNhbGli
cmk+PFNQQU4gDQpzdHlsZT0iQ09MT1I6ICMxZjQ5N2Q7IG1zby1iaWRpLWZvbnQtc2l6ZTog
MTAuNXB0OyBtc28tYXNjaWktZm9udC1mYW1pbHk6IENhbGlicmk7IG1zby1mYXJlYXN0LWZv
bnQtZmFtaWx5OiDLzszlOyBtc28taGFuc2ktZm9udC1mYW1pbHk6IENhbGlicmk7IG1zby1i
aWRpLWZvbnQtZmFtaWx5OiBDYWxpYnJpOyBtc28tZm9udC1rZXJuaW5nOiAwcHQiIA0KbGFu
Zz1FTi1VUz4mbmJzcDs8L1NQQU4+PFNQQU4gDQpzdHlsZT0iRk9OVC1GQU1JTFk6ICdUaW1l
cyBOZXcgUm9tYW4nLCdzZXJpZic7IENPTE9SOiBibGFjazsgbXNvLWJpZGktZm9udC1zaXpl
OiAxMC41cHQ7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiDLzszlOyBtc28tZm9udC1rZXJu
aW5nOiAwcHQiIA0KbGFuZz1FTi1VUz48bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0K
PFAgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQ7IG1zby1wYWdpbmF0aW9uOiB3aWRvdy1v
cnBoYW4iIA0KY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9Q2FsaWJyaT48U1BBTiANCnN0
eWxlPSJDT0xPUjogIzFmNDk3ZDsgbXNvLWJpZGktZm9udC1zaXplOiAxMC41cHQ7IG1zby1h
c2NpaS1mb250LWZhbWlseTogQ2FsaWJyaTsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IMvO
zOU7IG1zby1oYW5zaS1mb250LWZhbWlseTogQ2FsaWJyaTsgbXNvLWJpZGktZm9udC1mYW1p
bHk6IENhbGlicmk7IG1zby1mb250LWtlcm5pbmc6IDBwdCIgDQpsYW5nPUVOLVVTPlNvbWUg
cXVpY2sgY29tbWVudHM6PC9TUEFOPjxTUEFOIA0Kc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGlt
ZXMgTmV3IFJvbWFuJywnc2VyaWYnOyBDT0xPUjogYmxhY2s7IG1zby1iaWRpLWZvbnQtc2l6
ZTogMTAuNXB0OyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogy87M5TsgbXNvLWZvbnQta2Vy
bmluZzogMHB0IiANCmxhbmc9RU4tVVM+PG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD4N
CjxQIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0OyBtc28tcGFnaW5hdGlvbjogd2lkb3ct
b3JwaGFuIiANCmNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUNhbGlicmk+PFNQQU4gDQpz
dHlsZT0iQ09MT1I6ICMxZjQ5N2Q7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTAuNXB0OyBtc28t
YXNjaWktZm9udC1mYW1pbHk6IENhbGlicmk7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiDL
zszlOyBtc28taGFuc2ktZm9udC1mYW1pbHk6IENhbGlicmk7IG1zby1iaWRpLWZvbnQtZmFt
aWx5OiBDYWxpYnJpOyBtc28tZm9udC1rZXJuaW5nOiAwcHQiIA0KbGFuZz1FTi1VUz4mbmJz
cDs8L1NQQU4+PFNQQU4gDQpzdHlsZT0iRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4n
LCdzZXJpZic7IENPTE9SOiBibGFjazsgbXNvLWJpZGktZm9udC1zaXplOiAxMC41cHQ7IG1z
by1mYXJlYXN0LWZvbnQtZmFtaWx5OiDLzszlOyBtc28tZm9udC1rZXJuaW5nOiAwcHQiIA0K
bGFuZz1FTi1VUz48bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KPFAgc3R5bGU9Ik1B
UkdJTjogMGNtIDBjbSAwcHQgMjguNXB0OyBtc28tcGFnaW5hdGlvbjogd2lkb3ctb3JwaGFu
IiANCmNsYXNzPU1zb05vcm1hbD48ST48U1BBTiANCnN0eWxlPSJGT05ULUZBTUlMWTogJ1Rp
bWVzIE5ldyBSb21hbicsJ3NlcmlmJzsgQ09MT1I6IGJsYWNrOyBtc28tYmlkaS1mb250LXNp
emU6IDEwLjVwdDsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IMvOzOU7IG1zby1mb250LWtl
cm5pbmc6IDBwdCIgDQpsYW5nPUVOLVVTPlNvbWUgSUVURiB3b3JraW5nIGdyb3VwcyBoYXZl
IHN0YXJ0ZWQgd29yayByZWxhdGluZyB0byB0aGUgDQpkZXNjcmlwdGlvbiBvZiB2YXJpb3Vz
IHRvcG9sb2dpZXMgc3VjaCBhcyBJMlJTIChMMyBhbmQgcm91dGluZyB0b3BvbG9naWVzKSwg
QUxUTyANCihjb3N0IG1hcHMpLCBTRkMgKHNlcnZpY2UgY2hhaW4pLCBub25lIG9mIHRoZXNl
IGdyb3VwcyBhaW0gKDEpIGF0IG9mZmVyaW5nIHRydWx5IA0KZ2VuZXJpYyB0b3BvbG9neSBt
b2RlbHMgZm9yIHRoZSBzdGFuZGFyZCBub3J0aGJvdW5kIGludGVyZmFjZSwgYW5kICgyKSB0
aGF0IGFuIA0KYXBwbGljYXRpb24gY2FuIGNvbW11bmljYXRlIHdpdGggbmV0d29yayBib3hl
cywgc3VjaCBhcyBuZXR3b3JrIGNvbnRyb2xsZXJzLCBhbmQgDQpORXMsIGRldmVsb3BlZCBi
eSBkaWZmZXJlbnQgdmVuZG9ycy48bzpwPjwvbzpwPjwvU1BBTj48L0k+PC9QPg0KPFAgc3R5
bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQgMjguNXB0OyBtc28tcGFnaW5hdGlvbjogd2lkb3ct
b3JwaGFuIiANCmNsYXNzPU1zb05vcm1hbD48U1BBTiANCnN0eWxlPSJGT05ULUZBTUlMWTog
J1RpbWVzIE5ldyBSb21hbicsJ3NlcmlmJzsgQ09MT1I6IGJsYWNrOyBtc28tYmlkaS1mb250
LXNpemU6IDEwLjVwdDsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IMvOzOU7IG1zby1mb250
LWtlcm5pbmc6IDBwdCIgDQpsYW5nPUVOLVVTPjxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwv
UD4NCjxQIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0OyBtc28tcGFnaW5hdGlvbjogd2lk
b3ctb3JwaGFuIiANCmNsYXNzPU1zb05vcm1hbD48U1BBTiANCnN0eWxlPSJDT0xPUjogIzFm
NDk3ZDsgbXNvLWJpZGktZm9udC1zaXplOiAxMC41cHQ7IG1zby1hc2NpaS1mb250LWZhbWls
eTogQ2FsaWJyaTsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IMvOzOU7IG1zby1oYW5zaS1m
b250LWZhbWlseTogQ2FsaWJyaTsgbXNvLWJpZGktZm9udC1mYW1pbHk6IENhbGlicmk7IG1z
by1mb250LWtlcm5pbmc6IDBwdCIgDQpsYW5nPUVOLVVTPjxGT05UIGZhY2U9Q2FsaWJyaT5I
ZXJlIGRvIHlvdSBtZWFuIHRob3NlIHdvcmtpbmcgZ3JvdXAgZGlkbqGvdCBkbyANCnlvdXIg
KDIpLiBJZiBubywgSSBndWVzcyB5b3Ugc2hvdWxkIHVzZSChsG5laXRoZXKhsSBpbnN0ZWFk
LiANCjxvOnA+PC9vOnA+PC9GT05UPjwvU1BBTj48L1A+DQo8UCBzdHlsZT0iTUFSR0lOOiAw
Y20gMGNtIDBwdDsgbXNvLXBhZ2luYXRpb246IHdpZG93LW9ycGhhbiIgDQpjbGFzcz1Nc29O
b3JtYWw+PFNQQU4gDQpzdHlsZT0iRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nLCdz
ZXJpZic7IENPTE9SOiBibGFjazsgbXNvLWJpZGktZm9udC1zaXplOiAxMC41cHQ7IG1zby1m
YXJlYXN0LWZvbnQtZmFtaWx5OiDLzszlOyBtc28tZm9udC1rZXJuaW5nOiAwcHQiIA0KbGFu
Zz1FTi1VUz48bzpwPiZuYnNwOzwvbzpwPjwvU1BBTj48L1A+DQo8UCBzdHlsZT0iTUFSR0lO
OiAwY20gMGNtIDBwdDsgbXNvLXBhZ2luYXRpb246IHdpZG93LW9ycGhhbiIgDQpjbGFzcz1N
c29Ob3JtYWw+PEZPTlQgZmFjZT1DYWxpYnJpPjxTUEFOIA0Kc3R5bGU9IkNPTE9SOiAjMWY0
OTdkOyBtc28tYmlkaS1mb250LXNpemU6IDEwLjVwdDsgbXNvLWFzY2lpLWZvbnQtZmFtaWx5
OiBDYWxpYnJpOyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogy87M5TsgbXNvLWhhbnNpLWZv
bnQtZmFtaWx5OiBDYWxpYnJpOyBtc28tYmlkaS1mb250LWZhbWlseTogQ2FsaWJyaTsgbXNv
LWZvbnQta2VybmluZzogMHB0IiANCmxhbmc9RU4tVVM+SW4gYWRkaXRpb24sIGdpdmVuIHRo
YXQgdGhlcmUgd2VyZSBzb21lIGRpc2N1c3Npb25zIHJlbGF0ZWQgdG8gZW5kIA0KdXNlciBh
cHAgYW5kIG1hbmFnZW1lbnQgYXBwLiBZb3UgbWlnaHQgd2FudCB0byBzcGVjaWZ5IHRoZSBh
cHAgaW4gdGhpcyBzZW50ZW5jZSANCnRvIGVsaW1pbmF0ZSBjb25mdXNpb24uPC9TUEFOPjxT
UEFOIA0Kc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJywnc2VyaWYnOyBD
T0xPUjogYmxhY2s7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTAuNXB0OyBtc28tZmFyZWFzdC1m
b250LWZhbWlseTogy87M5TsgbXNvLWZvbnQta2VybmluZzogMHB0IiANCmxhbmc9RU4tVVM+
PG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD4NCjxQIHN0eWxlPSJNQVJHSU46IDBjbSAw
Y20gMHB0OyBtc28tcGFnaW5hdGlvbjogd2lkb3ctb3JwaGFuIiANCmNsYXNzPU1zb05vcm1h
bD48Rk9OVCBmYWNlPUNhbGlicmk+PFNQQU4gDQpzdHlsZT0iQ09MT1I6ICMxZjQ5N2Q7IG1z
by1iaWRpLWZvbnQtc2l6ZTogMTAuNXB0OyBtc28tYXNjaWktZm9udC1mYW1pbHk6IENhbGli
cmk7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiDLzszlOyBtc28taGFuc2ktZm9udC1mYW1p
bHk6IENhbGlicmk7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiBDYWxpYnJpOyBtc28tZm9udC1r
ZXJuaW5nOiAwcHQiIA0KbGFuZz1FTi1VUz4mbmJzcDs8L1NQQU4+PFNQQU4gDQpzdHlsZT0i
Rk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nLCdzZXJpZic7IENPTE9SOiBibGFjazsg
bXNvLWJpZGktZm9udC1zaXplOiAxMC41cHQ7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiDL
zszlOyBtc28tZm9udC1rZXJuaW5nOiAwcHQiIA0KbGFuZz1FTi1VUz48bzpwPjwvbzpwPjwv
U1BBTj48L0ZPTlQ+PC9QPg0KPFAgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQ7IG1zby1w
YWdpbmF0aW9uOiB3aWRvdy1vcnBoYW4iIA0KY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9
Q2FsaWJyaT48U1BBTiANCnN0eWxlPSJDT0xPUjogIzFmNDk3ZDsgbXNvLWJpZGktZm9udC1z
aXplOiAxMC41cHQ7IG1zby1hc2NpaS1mb250LWZhbWlseTogQ2FsaWJyaTsgbXNvLWZhcmVh
c3QtZm9udC1mYW1pbHk6IMvOzOU7IG1zby1oYW5zaS1mb250LWZhbWlseTogQ2FsaWJyaTsg
bXNvLWJpZGktZm9udC1mYW1pbHk6IENhbGlicmk7IG1zby1mb250LWtlcm5pbmc6IDBwdCIg
DQpsYW5nPUVOLVVTPk9uZSBtb3JlIGNvbW1lbnQsIEkgc2F3IHlvdSBhZGQgdGhlIHRlcm0g
obE8L1NQQU4+PFNQQU4gDQpzdHlsZT0iQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtU0laRTogMTBw
dDsgbXNvLWFzY2lpLWZvbnQtZmFtaWx5OiBDYWxpYnJpOyBtc28tZmFyZWFzdC1mb250LWZh
bWlseTogy87M5TsgbXNvLWhhbnNpLWZvbnQtZmFtaWx5OiBDYWxpYnJpOyBtc28tYmlkaS1m
b250LWZhbWlseTogQ2FsaWJyaTsgbXNvLWZvbnQta2VybmluZzogMHB0IiANCmxhbmc9RU4t
VVM+aW50ZXJvcGVyYWJsZSBtYW5uZXI8L1NQQU4+PFNQQU4gDQpzdHlsZT0iQ09MT1I6ICMx
ZjQ5N2Q7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTAuNXB0OyBtc28tYXNjaWktZm9udC1mYW1p
bHk6IENhbGlicmk7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiDLzszlOyBtc28taGFuc2kt
Zm9udC1mYW1pbHk6IENhbGlicmk7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiBDYWxpYnJpOyBt
c28tZm9udC1rZXJuaW5nOiAwcHQiIA0KbGFuZz1FTi1VUz6hsSBpbiBzZXZlcmFsIHBsYWNl
cy4gQ291bGQgeW91IHBsZWFzZSBlbGFib3JhdGU/PC9TUEFOPjwvRk9OVD48L1A+DQo8UCBz
dHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdDsgbXNvLXBhZ2luYXRpb246IHdpZG93LW9ycGhh
biIgDQpjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1DYWxpYnJpPjxTUEFOIA0Kc3R5bGU9
IkNPTE9SOiAjMWY0OTdkOyBtc28tYmlkaS1mb250LXNpemU6IDEwLjVwdDsgbXNvLWFzY2lp
LWZvbnQtZmFtaWx5OiBDYWxpYnJpOyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogy87M5Tsg
bXNvLWhhbnNpLWZvbnQtZmFtaWx5OiBDYWxpYnJpOyBtc28tYmlkaS1mb250LWZhbWlseTog
Q2FsaWJyaTsgbXNvLWZvbnQta2VybmluZzogMHB0IiANCmxhbmc9RU4tVVM+PC9TUEFOPjwv
Rk9OVD4mbmJzcDs8L1A+DQo8UCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdDsgbXNvLXBh
Z2luYXRpb246IHdpZG93LW9ycGhhbiIgDQpjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1D
YWxpYnJpPjxTUEFOIA0Kc3R5bGU9IkNPTE9SOiAjMWY0OTdkOyBtc28tYmlkaS1mb250LXNp
emU6IDEwLjVwdDsgbXNvLWFzY2lpLWZvbnQtZmFtaWx5OiBDYWxpYnJpOyBtc28tZmFyZWFz
dC1mb250LWZhbWlseTogy87M5TsgbXNvLWhhbnNpLWZvbnQtZmFtaWx5OiBDYWxpYnJpOyBt
c28tYmlkaS1mb250LWZhbWlseTogQ2FsaWJyaTsgbXNvLWZvbnQta2VybmluZzogMHB0IiAN
Cmxhbmc9RU4tVVM+QlIsPC9TUEFOPjwvRk9OVD48L1A+DQo8UCBzdHlsZT0iTUFSR0lOOiAw
Y20gMGNtIDBwdDsgbXNvLXBhZ2luYXRpb246IHdpZG93LW9ycGhhbiIgDQpjbGFzcz1Nc29O
b3JtYWw+PEZPTlQgZmFjZT1DYWxpYnJpPjxTUEFOIA0Kc3R5bGU9IkNPTE9SOiAjMWY0OTdk
OyBtc28tYmlkaS1mb250LXNpemU6IDEwLjVwdDsgbXNvLWFzY2lpLWZvbnQtZmFtaWx5OiBD
YWxpYnJpOyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogy87M5TsgbXNvLWhhbnNpLWZvbnQt
ZmFtaWx5OiBDYWxpYnJpOyBtc28tYmlkaS1mb250LWZhbWlseTogQ2FsaWJyaTsgbXNvLWZv
bnQta2VybmluZzogMHB0IiANCmxhbmc9RU4tVVM+WWluZzwvU1BBTj48L0ZPTlQ+PC9QPjwv
Rk9OVD48L0RJVj4NCjxESVY+PEZPTlQgY29sb3I9IzAwMDA4MCBzaXplPTIgZmFjZT1WZXJk
YW5hPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgY29sb3I9I2MwYzBjMCBzaXpl
PTIgZmFjZT1WZXJkYW5hPjIwMTQtMDktMjYgPC9GT05UPjwvRElWPjxGT05UIA0KY29sb3I9
IzAwMDA4MCBzaXplPTIgZmFjZT1WZXJkYW5hPg0KPEhSIHN0eWxlPSJXSURUSDogMTAwcHgi
IGFsaWduPWxlZnQgY29sb3I9I2I1YzRkZiBTSVpFPTE+DQo8L0ZPTlQ+DQo8RElWPjxGT05U
IGNvbG9yPSNjMGMwYzAgc2l6ZT0yIGZhY2U9VmVyZGFuYT48U1BBTj4NCjxESVY+WWluZyBD
SEVORyZuYnNwOyCzzNOoPEJSPkNoaW5hIFVuaWNvbSBOZXR3b3JrIFRlY2hub2xvZ3kgUmVz
ZWFyY2ggSW5zdGl0dXRlIA0K1tC5+sGqzajN+MLnvLzK9dHQvr/UujxCUj5UZWw6ICs4Ni0x
MC02ODc5OTk5OS03NzAyPEJSPk1vYmlsZTogDQorODYtMTg2MDExMDI5NzE8QlI+PEJSPjwv
RElWPjwvU1BBTj48L0ZPTlQ+PC9ESVY+DQo8SFIgY29sb3I9I2I1YzRkZiBTSVpFPTE+DQoN
CjxESVY+PEZPTlQgc2l6ZT0yIGZhY2U9VmVyZGFuYT48U1RST05HPreivP7Iy6O6PC9TVFJP
Tkc+IFRpbmEgVFNPVSA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9MiBmYWNlPVZl
cmRhbmE+PFNUUk9ORz63osvNyrG85KO6PC9TVFJPTkc+IDIwMTQtMDktMjYmbmJzcDsgMDg6
NTM6NDcgDQo8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9MiBmYWNlPVZlcmRhbmE+
PFNUUk9ORz7K1bz+yMujujwvU1RST05HPiBCZW5vaXQgQ2xhaXNlIDwvRk9OVD48L0RJVj4N
CjxESVY+PEZPTlQgc2l6ZT0yIGZhY2U9VmVyZGFuYT48U1RST05HPrOty82jujwvU1RST05H
PiBzdXBhQGlldGYub3JnIDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yIGZhY2U9
VmVyZGFuYT48U1RST05HPtb3zOKjujwvU1RST05HPiBbU3VwYV0gRHJhZnQgY2hhcnRlciAN
CnYxLjEyLy9SRTogQXJlYSBoYW5kLW9mZiwgYW5kIHNvbWUgZnJpZW5kbHlhZHZpY2UgLi4u
IDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yIGZhY2U9VmVyZGFuYT48L0ZPTlQ+
IDwvRElWPg0KPERJVj48Rk9OVCBzaXplPTIgZmFjZT1WZXJkYW5hPg0KPERJViBjbGFzcz1X
b3JkU2VjdGlvbjE+DQo8UCBzdHlsZT0iVEVYVC1BTElHTjoganVzdGlmeSIgY2xhc3M9TXNv
Tm9ybWFsPjxTUEFOIA0Kc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ2FsaWJyaScsJ3NhbnMtc2Vy
aWYnOyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMHB0IiANCmxhbmc9RU4tVVM+RGVh
ciBCZW5vaXQgZXQgYWwsPG86cD48L286cD48L1NQQU4+PC9QPg0KPFAgc3R5bGU9IlRFWFQt
QUxJR046IGp1c3RpZnkiIGNsYXNzPU1zb05vcm1hbD48U1BBTiANCnN0eWxlPSJGT05ULUZB
TUlMWTogJ0NhbGlicmknLCdzYW5zLXNlcmlmJzsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtU0la
RTogMTBwdCIgDQpsYW5nPUVOLVVTPjxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwvUD4NCjxQ
IHN0eWxlPSJURVhULUFMSUdOOiBqdXN0aWZ5IiBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQpz
dHlsZT0iRk9OVC1GQU1JTFk6ICdDYWxpYnJpJywnc2Fucy1zZXJpZic7IENPTE9SOiAjMWY0
OTdkOyBGT05ULVNJWkU6IDEwcHQiIA0KbGFuZz1FTi1VUz5IZXJlIGNvbWVzIGxhdGVzdCB2
ZXJzaW9uLiBUaGUgbGlzdCBkaXNjdXNzaW9uIGhlbHBzIGEgbG90IHRvIG1ha2UgaXQgDQpj
bGVhcmVyLjxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCjxQIHN0eWxlPSJURVhULUFMSUdOOiBq
dXN0aWZ5IiBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQpzdHlsZT0iRk9OVC1GQU1JTFk6ICdD
YWxpYnJpJywnc2Fucy1zZXJpZic7IENPTE9SOiAjMWY0OTdkOyBGT05ULVNJWkU6IDEwcHQi
IA0KbGFuZz1FTi1VUz48bzpwPiZuYnNwOzwvbzpwPjwvU1BBTj48L1A+DQo8UCBzdHlsZT0i
VEVYVC1BTElHTjoganVzdGlmeSIgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0Kc3R5bGU9IkZP
TlQtRkFNSUxZOiAnQ2FsaWJyaScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogIzFmNDk3ZDsgRk9O
VC1TSVpFOiAxMHB0IiANCmxhbmc9RU4tVVM+PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PTxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCjxQIHN0eWxl
PSJURVhULUFMSUdOOiBqdXN0aWZ5IiBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQpzdHlsZT0i
Rk9OVC1GQU1JTFk6ICdDYWxpYnJpJywnc2Fucy1zZXJpZic7IENPTE9SOiAjMWY0OTdkOyBG
T05ULVNJWkU6IDEwcHQiIA0KbGFuZz1FTi1VUz5TVVBBIChTaGFyZWQgVW5pZmllZCBQb2xp
Y3kgQXV0b21hdGlvbikgY2hhcnRlciANCnYxLjEyPG86cD48L286cD48L1NQQU4+PC9QPg0K
PFAgc3R5bGU9IlRFWFQtQUxJR046IGp1c3RpZnkiIGNsYXNzPU1zb05vcm1hbD48U1BBTiAN
CnN0eWxlPSJGT05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5zLXNlcmlmJzsgQ09MT1I6ICMx
ZjQ5N2Q7IEZPTlQtU0laRTogMTBwdCIgDQpsYW5nPUVOLVVTPlRhcmdldCBBcmVhOiBPcGVy
YXRpb25zIGFuZCBNYW5hZ2VtZW50PG86cD48L286cD48L1NQQU4+PC9QPg0KPFAgc3R5bGU9
IlRFWFQtQUxJR046IGp1c3RpZnkiIGNsYXNzPU1zb05vcm1hbD48U1BBTiANCnN0eWxlPSJG
T05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5zLXNlcmlmJzsgQ09MT1I6ICMxZjQ5N2Q7IEZP
TlQtU0laRTogMTBwdCIgDQpsYW5nPUVOLVVTPjxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwv
UD4NCjxQIHN0eWxlPSJURVhULUFMSUdOOiBqdXN0aWZ5IiBjbGFzcz1Nc29Ob3JtYWw+PFNQ
QU4gDQpzdHlsZT0iRk9OVC1GQU1JTFk6ICdDYWxpYnJpJywnc2Fucy1zZXJpZic7IENPTE9S
OiAjMWY0OTdkOyBGT05ULVNJWkU6IDEwcHQiIA0KbGFuZz1FTi1VUz5EZXNjcmlwdGlvbiBv
ZiBXb3JraW5nIEdyb3VwOjxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCjxQIHN0eWxlPSJURVhU
LUFMSUdOOiBqdXN0aWZ5IiBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQpzdHlsZT0iRk9OVC1G
QU1JTFk6ICdDYWxpYnJpJywnc2Fucy1zZXJpZic7IENPTE9SOiAjMWY0OTdkOyBGT05ULVNJ
WkU6IDEwcHQiIA0KbGFuZz1FTi1VUz48bzpwPiZuYnNwOzwvbzpwPjwvU1BBTj48L1A+DQo8
UCBzdHlsZT0iVEVYVC1BTElHTjoganVzdGlmeSIgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0K
c3R5bGU9IkZPTlQtRkFNSUxZOiAnQ2FsaWJyaScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogIzFm
NDk3ZDsgRk9OVC1TSVpFOiAxMHB0IiANCmxhbmc9RU4tVVM+UHJvZ3JhbW1hdGljIHdheXMg
dG8gY29uZmlndXJlIG5ldHdvcmtzLCBvZnRlbiBjYWxsZWQgDQpzb2Z0d2FyZS1kZWZpbmVk
LCBhcmUgY29uc2lkZXJlZCBieSBtYW55IG5ldHdvcmsgb3BlcmF0b3JzIGluIG9yZGVyIHRv
IHNoaWZ0IHRoZSANCmJhbGFuY2UgaW4gdGhlaXIgZmF2b3IuPG86cD48L286cD48L1NQQU4+
PC9QPg0KPFAgc3R5bGU9IlRFWFQtQUxJR046IGp1c3RpZnkiIGNsYXNzPU1zb05vcm1hbD48
U1BBTiANCnN0eWxlPSJGT05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5zLXNlcmlmJzsgQ09M
T1I6ICMxZjQ5N2Q7IEZPTlQtU0laRTogMTBwdCIgDQpsYW5nPUVOLVVTPkF1dG9tYXRpbmcg
dGhlIHdheSBvZiBleHBvc2luZyBhIHZpZXcgb2YgdGhlIG5ldHdvcmsgdG8gYXBwbGljYXRp
b25zIA0KbWF5IHByb3ZpZGUgc2lnbmlmaWNhbnQgaW1wcm92ZW1lbnRzIGluIGNvbmZpZ3Vy
YXRpb24gYWdpbGl0eSwgZXJyb3IgZGV0ZWN0aW9uIA0KYW5kIHVwdGltZSBmb3Igb3BlcmF0
b3JzLiBIb3dldmVyIHRoZSByZWFsIHZhbHVlIGJlaGluZCBjZW50cmFsIGNvbmZpZ3VyYXRp
b24gDQpzY2hlbWVzIGxpZXMgd2l0aGluIHRoZSBwb3NzaWJsZSBzaW1wbGlmaWNhdGlvbiB0
aHJvdWdoIG1vZGVscyBwcm92aWRlZCBieSBzdWNoIA0Kc3lzdGVtcyB0byBhcHBsaWNhdGlv
bnMgYW5kIG5ldHdvcmsgc2VydmljZXMgcnVubmluZyBhYm92ZSB0aGVtIChvbiB0aGUgDQpz
by1jYWxsZWQgbm9ydGhib3VuZCBzaWRlKS4gV2VsbC1kZXNpZ25lZCBtb2RlbHMgYXJlIGFi
bGUgdG8gcHJvdmlkZSBhIHdpZGUgDQpyYW5nZSBvZiBncmFudWxhcml0eSBmb3IgdmFyaW91
cyBhcHBsaWNhdGlvbnMgYW5kIG5ldHdvcmsgc2VydmljZXMgbmVlZHMsIGZyb20gDQp0aGUg
bG93ZXItbGV2ZWwgcGh5c2ljYWwgbmV0d29yayB0byBoaWdoLWxldmVsIGFwcGxpY2F0aW9u
IHNlcnZpY2VzLiANCjxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCjxQIHN0eWxlPSJURVhULUFM
SUdOOiBqdXN0aWZ5IiBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQpzdHlsZT0iRk9OVC1GQU1J
TFk6ICdDYWxpYnJpJywnc2Fucy1zZXJpZic7IENPTE9SOiAjMWY0OTdkOyBGT05ULVNJWkU6
IDEwcHQiIA0KbGFuZz1FTi1VUz5TZXZlcmFsIG9yZ2FuaXphdGlvbnMgb3V0c2lkZSBvZiB0
aGUgSUVURiBoYXZlIGRlZmluZWQgdmFyaW91cyANCnNjaGVtZXMgZm9yIHRoZSBjb25maWd1
cmF0aW9uIG9mIG5ldHdvcmsgZGV2aWNlcyBhbmQgc3BlY2lmaWMgbmV0d29yayANCmNvbnRy
b2xsZXJzLCBidXQgbm9uZSBvZiB0aGVtIG9mZmVyIGEgdmVuZG9yLW5ldXRyYWwgc3RhbmRh
cmRpemVkIHdheSBmb3IgDQphcHBsaWNhdGlvbnMgYW5kIG5ldHdvcmsgc2VydmljZXMgdG8g
dHJhbnNtaXQgdGhlaXIgbmVlZHMgdG8gbmV0d29yayANCmNvbnRyb2xsZXJzLiBUaGUgU1VQ
QSAoU2hhcmVkIFVuaWZpZWQgUG9saWN5IEF1dG9tYXRpb24pIHdvcmtpbmcgZ3JvdXAgd2ls
bCB3b3JrIA0Kb24gdGhlIGRlZmluaXRpb24gb2Ygc3VjaCBhcyBzdGFuZGFyZGl6ZWQgaW50
ZXJmYWNlIGZvciBhcHBsaWNhdGlvbnMgYW5kIG5ldHdvcmsgDQpzZXJ2aWNlcyB0byBjb21t
dW5pY2F0ZSB3aXRoIG5ldHdvcmsgY29udHJvbGxlcnMgb2YgYWxsIHR5cGVzLiBJbiBwYXJ0
aWN1bGFyLCANClNVUEEgd2lsbCBmb2N1cyBvbiBzZXJ2aWNlIHNwZWNpZmljIG1vZGVscyB0
aGF0IGFsbG93IGFwcGxpY2F0aW9ucyB0byByZXF1ZXN0IA0KY2VydGFpbiBuZXR3b3JrIHNl
cnZpY2VzIHRvIGJlIGNyZWF0ZWQvZGVsZXRlZC9tb2RpZmllZC4gQSBuZXR3b3JrIHNlcnZp
Y2UgY2FuIA0KZm9yIGV4YW1wbGUgYmUgYSB2aXJ0dWFsIGxpbmsgYmV0d2VlbiB0d28gZW5k
cG9pbnRzIHRoYXQgdXNlcyBjZXJ0YWluIA0KcHJvcGVydGllcywgdHJhZmZpYyBlbmdpbmVl
cmluZywgaW1wbGVtZW50YXRpb24gb2YgSVB2NiB0cmFuc2l0aW9uIG1lY2hhbmlzbSBhbmQg
DQp0aGVpciBlbmZvcmNlbWVudCB0byB1c2Vycy48bzpwPjwvbzpwPjwvU1BBTj48L1A+DQo8
UCBzdHlsZT0iVEVYVC1BTElHTjoganVzdGlmeSIgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0K
c3R5bGU9IkZPTlQtRkFNSUxZOiAnQ2FsaWJyaScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogIzFm
NDk3ZDsgRk9OVC1TSVpFOiAxMHB0IiANCmxhbmc9RU4tVVM+RWFjaCBuZXR3b3JrIHNlcnZp
Y2UgY2FuIGJlIHJlcHJlc2VudGVkIGJ5IGEgc2VydmljZSBiYXNlZCBQT0xJQ1kgDQptb2Rl
bCB0aGF0IGNhbiBtb2RlbCBhIGdyb3VwIG9mIGRlbWFuZHMgKGkuZS4sIGFjdGlvbnMgYW5k
IGNvbnN0cmFpbnRzKSB0aGF0IGFyZSANCmJlaW5nIGluaXRpYXRlZCBieSBhcHBsaWNhdGlv
bnMgdGhhdCBpbXBvc2Ugc2ltaWxhciByZXF1aXJlbWVudHMgb24gdGhlIA0KY29tbXVuaWNh
dGlvbiBuZXR3b3JrLiBUaGUgdGVybXMgIlVOSUZJRUQiIGFuZCAiU0hBUkVEIiB1c2VkIGlu
IHRoZSBTVVBBIA0KYWJicmV2aWF0aW9uLCByZWxhdGUgdG8gdGhlIHdheSBvZiBob3cgdGhl
IHNlcnZpY2UgcG9saWN5IG1vZGVsIGlzIGdlbmVyYXRlZCwgDQpzaW5jZSBpdCBncm91cHMs
IHVuaWZpZXMgYW5kIHNoYXJlcyB0aGUgc2ltaWxhciByZXF1aXJlbWVudHMgaW1wb3NlZCBi
eSBhIGJ1bGsgDQpvZiBhcHBsaWNhdGlvbnMuIFNVUEEgd2lsbCBwcm92aWRlIGd1aWRlbGlu
ZXMgZm9yIG1lY2hhbmlzbXMgdGhhdCBjYW4gDQpkeW5hbWljYWxseSBhbmQgb24gYW4gaW50
ZXJvcGVyYWJsZSBtYW5uZXIsIEFVVE9NQVRJQ0FMTFkgbWFwIHNlcnZpY2VzIGFuZCANCnBv
bGljaWVzIGRlZmluZWQgb24gYW4gYWJzdHJhY3QgdG9wb2xvZ3kgZ3JhcGggZG93biB0byBt
b3JlIGRldGFpbGVkIG5ldHdvcmsgDQpncmFwaHMgYW5kIHNwZWNpZmljIG5ldHdvcmsgbWFu
YWdlbWVudCBhbmQgY29udHJvbGxpbmcgDQpwb2xpY2llcy48bzpwPjwvbzpwPjwvU1BBTj48
L1A+DQo8UCBzdHlsZT0iVEVYVC1BTElHTjoganVzdGlmeSIgY2xhc3M9TXNvTm9ybWFsPjxT
UEFOIA0Kc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ2FsaWJyaScsJ3NhbnMtc2VyaWYnOyBDT0xP
UjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMHB0IiANCmxhbmc9RU4tVVM+U29tZSBJRVRGIHdv
cmtpbmcgZ3JvdXBzIGhhdmUgc3RhcnRlZCB3b3JrIHJlbGF0aW5nIHRvIHRoZSANCmRlc2Ny
aXB0aW9uIG9mIHZhcmlvdXMgdG9wb2xvZ2llcyBzdWNoIGFzIEkyUlMgKEwzIGFuZCByb3V0
aW5nIHRvcG9sb2dpZXMpLCBBTFRPIA0KKGNvc3QgbWFwcyksIFNGQyAoc2VydmljZSBjaGFp
biksIG5vbmUgb2YgdGhlc2UgZ3JvdXBzIGFpbSAoMSkgYXQgb2ZmZXJpbmcgdHJ1bHkgDQpn
ZW5lcmljIHRvcG9sb2d5IG1vZGVscyBmb3IgdGhlIHN0YW5kYXJkIG5vcnRoYm91bmQgaW50
ZXJmYWNlLCBhbmQgKDIpIHRoYXQgYW4gDQphcHBsaWNhdGlvbiBjYW4gY29tbXVuaWNhdGUg
d2l0aCBuZXR3b3JrIGJveGVzLCBzdWNoIGFzIG5ldHdvcmsgY29udHJvbGxlcnMsIGFuZCAN
Ck5FcywgZGV2ZWxvcGVkIGJ5IGRpZmZlcmVudCB2ZW5kb3JzLjxvOnA+PC9vOnA+PC9TUEFO
PjwvUD4NCjxQIHN0eWxlPSJURVhULUFMSUdOOiBqdXN0aWZ5IiBjbGFzcz1Nc29Ob3JtYWw+
PFNQQU4gDQpzdHlsZT0iRk9OVC1GQU1JTFk6ICdDYWxpYnJpJywnc2Fucy1zZXJpZic7IENP
TE9SOiAjMWY0OTdkOyBGT05ULVNJWkU6IDEwcHQiIA0KbGFuZz1FTi1VUz5TVVBBIHdpbGwg
d29yayBvbiBkZWZpbmluZyB2ZW5kb3ItbmV1dHJhbCBzdGFuZGFyZGl6ZWQgaW50ZXJmYWNl
cyANCmJhc2VkIG9uIHRoZSBjb25jZXB0IG9mIG5ldHdvcmsgZ3JhcGgsIGFuIGVudGl0eSBk
ZXNjcmliaW5nIGFuIGFyYml0cmFyeSANCnRvcG9sb2d5IG9mIG5vZGVzIGFuZCBsaW5rcyBh
dCBhbnkgbGV2ZWwgb2YgZ3JhbnVsYXJpdHkuIFN1Y2ggYSBuZXR3b3JrIGdyYXBoIA0KZGVz
Y3JpYmVzICgxKSB0b3BvbG9naWVzIGF0IGRpZmZlcmVudCBsZXZlbHMgb2YgYWJzdHJhY3Rp
b24sICgyKSB0aGUgDQpyZWxhdGlvbnNoaXBzIGJldHdlZW4gdGhlIGFic3RyYWN0aW9uIGxl
dmVscyBhbmQgKDMpIGFwcGxpZWQgc2VydmljZSBiYXNlZCANCnBvbGljeSwgd2hpY2ggYXJl
IGFjdGlvbnMgYW5kIGNvbnN0cmFpbnRzIGFwcGxpZWQgb24gdGhlc2UgdG9wb2xvZ2llcy4g
U1VQQSBtYXkgDQphbHNvIGRlZmluZSBhbnkgbWFwcGluZ3MgdG8gYW55IG90aGVyIG5ldHdv
cmsgdG9wb2xvZ3kgZGF0YSBtb2RlbHMgZGVmaW5lZCANCndpdGhpbiB0aGUgSUVURi48bzpw
PjwvbzpwPjwvU1BBTj48L1A+DQo8UCBzdHlsZT0iVEVYVC1BTElHTjoganVzdGlmeSIgY2xh
c3M9TXNvTm9ybWFsPjxTUEFOIA0Kc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ2FsaWJyaScsJ3Nh
bnMtc2VyaWYnOyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMHB0IiANCmxhbmc9RU4t
VVM+VGhlIG1haW4gZ29hbCBvZiBTVVBBIGlzIHRvIHByb3ZpZGUgc2VydmljZSBzcGVjaWZp
YyBtb2RlbHMgdGhhdCANCmFsbG93IGFwcGxpY2F0aW9ucyB0byByZXF1ZXN0IG5ldHdvcmsg
c2VydmljZXMgdG8gYmUgY3JlYXRlZC9kZWxldGVkL21vZGlmaWVkLiANClRoaXMgY2FuIGJl
IHJlYWxpemVkIGJ5OjxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCjxQIHN0eWxlPSJURVhULUFM
SUdOOiBqdXN0aWZ5IiBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQpzdHlsZT0iRk9OVC1GQU1J
TFk6ICdDYWxpYnJpJywnc2Fucy1zZXJpZic7IENPTE9SOiAjMWY0OTdkOyBGT05ULVNJWkU6
IDEwcHQiIA0KbGFuZz1FTi1VUz4mbmJzcDsgbykgbW9kZWwgbXVsdGlwbGUgdG9wb2xvZ2ll
cyBhdCBkaWZmZXJlbnQgbGV2ZWxzIG9mIA0KYWJzdHJhY3Rpb24gdXNpbmcgYSBuZXR3b3Jr
IGdyYXBoLCA8bzpwPjwvbzpwPjwvU1BBTj48L1A+DQo8UCBzdHlsZT0iVEVYVC1BTElHTjog
anVzdGlmeSIgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0Kc3R5bGU9IkZPTlQtRkFNSUxZOiAn
Q2FsaWJyaScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMHB0
IiANCmxhbmc9RU4tVVM+Jm5ic3A7Jm5ic3A7bykgbW9kZWwgdGhlIHJlbGF0aW9uc2hpcHMg
YmV0d2VlbiB0aGUgYWJzdHJhY3Rpb24gDQpsZXZlbHMuPG86cD48L286cD48L1NQQU4+PC9Q
Pg0KPFAgc3R5bGU9IlRFWFQtQUxJR046IGp1c3RpZnkiIGNsYXNzPU1zb05vcm1hbD48U1BB
TiANCnN0eWxlPSJGT05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5zLXNlcmlmJzsgQ09MT1I6
ICMxZjQ5N2Q7IEZPTlQtU0laRTogMTBwdCIgDQpsYW5nPUVOLVVTPiZuYnNwOyBvKSB0cmFu
c3BvcnRpbmcgbW9kZWwgaW5zdGFuY2VzIHVzaW5nIGVpdGhlciBORVRDT05GIG9yIA0KUkVT
VENPTkYgPG86cD48L286cD48L1NQQU4+PC9QPg0KPFAgc3R5bGU9IlRFWFQtQUxJR046IGp1
c3RpZnkiIGNsYXNzPU1zb05vcm1hbD48U1BBTiANCnN0eWxlPSJGT05ULUZBTUlMWTogJ0Nh
bGlicmknLCdzYW5zLXNlcmlmJzsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtU0laRTogMTBwdCIg
DQpsYW5nPUVOLVVTPjxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwvUD4NCjxQIHN0eWxlPSJU
RVhULUFMSUdOOiBqdXN0aWZ5IiBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQpzdHlsZT0iRk9O
VC1GQU1JTFk6ICdDYWxpYnJpJywnc2Fucy1zZXJpZic7IENPTE9SOiAjMWY0OTdkOyBGT05U
LVNJWkU6IDEwcHQiIA0KbGFuZz1FTi1VUz5TVVBBIHdpbGwgZW5zdXJlIHRoYXQgaW4gY2Fz
ZSBhbnkgc3BlY2lmaWMgTkVUQ09ORi9SRVNUQ09ORiBwcm90b2NvbCANCnJlcXVpcmVtZW50
cyBhcmUgaWRlbnRpZmllZCwgdGhleSB3aWxsIGJlIGNvbW11bmljYXRlZCBpbiBhIHRpbWVs
eSBtYW5uZXIgdG8gdGhlIA0KTkVUQ09ORiB3b3JraW5nIGdyb3VwLiBTVVBBIHdpbGwgY29u
c3VsdCB3aXRoIHRoZSBZQU5HIGRvY3RvcnMgdG8gZW5zdXJlIHRoYXQgDQpkYXRhIG1vZGVs
cyBmb2xsb3cgY29tbW9uIHByYWN0aWNlcy48bzpwPjwvbzpwPjwvU1BBTj48L1A+DQo8UCBz
dHlsZT0iVEVYVC1BTElHTjoganVzdGlmeSIgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0Kc3R5
bGU9IkZPTlQtRkFNSUxZOiAnQ2FsaWJyaScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogIzFmNDk3
ZDsgRk9OVC1TSVpFOiAxMHB0IiANCmxhbmc9RU4tVVM+PG86cD4mbmJzcDs8L286cD48L1NQ
QU4+PC9QPg0KPFAgc3R5bGU9IlRFWFQtQUxJR046IGp1c3RpZnkiIGNsYXNzPU1zb05vcm1h
bD48U1BBTiANCnN0eWxlPSJGT05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5zLXNlcmlmJzsg
Q09MT1I6ICMxZjQ5N2Q7IEZPTlQtU0laRTogMTBwdCIgDQpsYW5nPUVOLVVTPldvcmsgaXRl
bXMgZm9yIFNVUEEgaW5jbHVkZTo8bzpwPjwvbzpwPjwvU1BBTj48L1A+DQo8UCBzdHlsZT0i
VEVYVC1BTElHTjoganVzdGlmeSIgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0Kc3R5bGU9IkZP
TlQtRkFNSUxZOiAnQ2FsaWJyaScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogIzFmNDk3ZDsgRk9O
VC1TSVpFOiAxMHB0IiANCmxhbmc9RU4tVVM+PT09PT09PT09PT09PT09PT09PT09PT09PT09
PTxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCjxQIHN0eWxlPSJURVhULUFMSUdOOiBqdXN0aWZ5
IiBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQpzdHlsZT0iRk9OVC1GQU1JTFk6ICdDYWxpYnJp
Jywnc2Fucy1zZXJpZic7IENPTE9SOiAjMWY0OTdkOyBGT05ULVNJWkU6IDEwcHQiIA0KbGFu
Zz1FTi1VUz4xKSBUaGUgZGVmaW5pdGlvbiBvZiBhIHN0YW5kYXJkaXplZCBtb2RlbCBmb3Ig
YSBuZXR3b3JrIGdyYXBoLCB1c2luZyANCllBTkcuIFRoaXMgbW9kZWwgbWF5IGJlIHVzZWQg
dG8gZGVzY3JpYmUgdG9wb2xvZ2llcyBhdCBhbnkgZnVuY3Rpb25hbCBsYXllciwgDQpmcm9t
IHBoeXNpY2FsIG5ldHdvcmtzIHRvIG5ldHdvcmsgc2VydmljZXMuIDxvOnA+PC9vOnA+PC9T
UEFOPjwvUD4NCjxQIHN0eWxlPSJURVhULUFMSUdOOiBqdXN0aWZ5IiBjbGFzcz1Nc29Ob3Jt
YWw+PFNQQU4gDQpzdHlsZT0iRk9OVC1GQU1JTFk6ICdDYWxpYnJpJywnc2Fucy1zZXJpZic7
IENPTE9SOiAjMWY0OTdkOyBGT05ULVNJWkU6IDEwcHQiIA0KbGFuZz1FTi1VUz4yKSBUaGUg
ZGVmaW5pdGlvbiBhbmQgc3RhbmRhcmRpemF0aW9uIG9mIGEgbnVtYmVyIG9mIGJhc2ljIHBv
bGljeSBhbmQgDQpkYXRhIG1vZGVscyB1c2luZyBuZXR3b3JrIGdyYXBocy4gVGhlc2UgbWln
aHQgaW5jbHVkZSwgYnV0IGFyZSBub3QgbGltaXRlZCB0byANCkwzVlBOcywgdHJhZmZpYyBl
bmdpbmVlcmluZywgaW1wbGVtZW50YXRpb24gb2YgSVB2NiB0cmFuc2l0aW9uIG1lY2hhbmlz
bSBhbmQgDQp0aGVpciBlbmZvcmNlbWVudCB0byB1c2Vycy4mbmJzcDsgPG86cD48L286cD48
L1NQQU4+PC9QPg0KPFAgc3R5bGU9IlRFWFQtQUxJR046IGp1c3RpZnkiIGNsYXNzPU1zb05v
cm1hbD48U1BBTiANCnN0eWxlPSJGT05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5zLXNlcmlm
JzsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtU0laRTogMTBwdCIgDQpsYW5nPUVOLVVTPjMpIFBy
b3ZpZGUgZ3VpZGVsaW5lcyBmb3IgbWVjaGFuaXNtcyB0aGF0IGNhbiBkeW5hbWljYWxseSBh
bmQgb24gYW4gDQppbnRlcm9wZXJhYmxlIG1hbm5lciwgYXV0b21hdGljYWxseSBtYXAgc2Vy
dmljZXMgYW5kIHBvbGljaWVzIGRlZmluZWQgb24gYW4gDQphYnN0cmFjdCB0b3BvbG9neSBn
cmFwaCBkb3duIHRvIG1vcmUgZGV0YWlsZWQgbmV0d29yayBncmFwaHMgYW5kIHNwZWNpZmlj
IA0KbmV0d29yayBtYW5hZ2VtZW50IGFuZCBjb250cm9sbGluZyBwb2xpY2llcy48bzpwPjwv
bzpwPjwvU1BBTj48L1A+DQo8UCBzdHlsZT0iVEVYVC1BTElHTjoganVzdGlmeSIgY2xhc3M9
TXNvTm9ybWFsPjxTUEFOIA0Kc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ2FsaWJyaScsJ3NhbnMt
c2VyaWYnOyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMHB0IiANCmxhbmc9RU4tVVM+
NCkgR3VpZGVsaW5lcyBvbiBob3cgdG8gdXNlIE5FVENPTkYgKG9yIFJFU1RDT05GKSBhdXRo
ZW50aWNhdGlvbiBhbmQgDQphdXRob3JpemF0aW9uIG1lY2hhbmlzbXMgdG8gYWNoaWV2ZSBw
cm90ZWN0aW9uIGFuZCANCmlzb2xhdGlvbjxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCjxQIHN0
eWxlPSJURVhULUFMSUdOOiBqdXN0aWZ5IiBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQpzdHls
ZT0iRk9OVC1GQU1JTFk6ICdDYWxpYnJpJywnc2Fucy1zZXJpZic7IENPTE9SOiAjMWY0OTdk
OyBGT05ULVNJWkU6IDEwcHQiIA0KbGFuZz1FTi1VUz48bzpwPiZuYnNwOzwvbzpwPjwvU1BB
Tj48L1A+DQo8UCBzdHlsZT0iVEVYVC1BTElHTjoganVzdGlmeSIgY2xhc3M9TXNvTm9ybWFs
PjxTUEFOIA0Kc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ2FsaWJyaScsJ3NhbnMtc2VyaWYnOyBD
T0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMHB0IiANCmxhbmc9RU4tVVM+RGVsaXZlcmFi
bGVzOjxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCjxQIHN0eWxlPSJURVhULUFMSUdOOiBqdXN0
aWZ5IiBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQpzdHlsZT0iRk9OVC1GQU1JTFk6ICdDYWxp
YnJpJywnc2Fucy1zZXJpZic7IENPTE9SOiAjMWY0OTdkOyBGT05ULVNJWkU6IDEwcHQiIA0K
bGFuZz1FTi1VUz49PT09PT09PT09PT09PG86cD48L286cD48L1NQQU4+PC9QPg0KPFAgc3R5
bGU9IlRFWFQtQUxJR046IGp1c3RpZnkiIGNsYXNzPU1zb05vcm1hbD48U1BBTiANCnN0eWxl
PSJGT05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5zLXNlcmlmJzsgQ09MT1I6ICMxZjQ5N2Q7
IEZPTlQtU0laRTogMTBwdCIgDQpsYW5nPUVOLVVTPm8pIFByb2R1Y2UgYW4gaW5mb3JtYXRp
b25hbCBSRkMgIlByb2JsZW0gU3RhdGVtZW50IGFuZCBVc2UgDQpDYXNlcyIuPG86cD48L286
cD48L1NQQU4+PC9QPg0KPFAgc3R5bGU9IlRFWFQtQUxJR046IGp1c3RpZnkiIGNsYXNzPU1z
b05vcm1hbD48U1BBTiANCnN0eWxlPSJGT05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5zLXNl
cmlmJzsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtU0laRTogMTBwdCIgDQpsYW5nPUVOLVVTPm8p
IFByb2R1Y2UgYSBzdGFuZGFyZHMtdHJhY2sgUkZDIHRoYXQgc3BlY2lmaWVzIFlBTkcgbW9k
ZWxzIGZvciBhIA0KZ2VuZXJpYyBtdWx0aS1sYXllciBuZXR3b3JrIGdyYXBoLjxvOnA+PC9v
OnA+PC9TUEFOPjwvUD4NCjxQIHN0eWxlPSJURVhULUFMSUdOOiBqdXN0aWZ5IiBjbGFzcz1N
c29Ob3JtYWw+PFNQQU4gDQpzdHlsZT0iRk9OVC1GQU1JTFk6ICdDYWxpYnJpJywnc2Fucy1z
ZXJpZic7IENPTE9SOiAjMWY0OTdkOyBGT05ULVNJWkU6IDEwcHQiIA0KbGFuZz1FTi1VUz5v
KSBQcm9kdWNlIHN0YW5kYXJkcy10cmFjayBSRkNzIHRoYXQgc3BlY2lmeSBleHRlbnNpb25z
IGZvciB0aGUgDQpnZW5lcmljIFlBTkcgbW9kZWxzIGRlZmluZWQgYWJvdmUgZm9yIG5ldHdv
cmsgc2VydmljZXMgdGhhdCBtYW5hZ2UgdmlydHVhbCANCmxpbmtzLCB0cmFmZmljIGVuZ2lu
ZWVyaW5nIGFuZCBpbXBsZW1lbnRhdGlvbiBvZiBJUHY2IHRyYW5zaXRpb24gbWVjaGFuaXNt
IGFuZCANCnRoZWlyIGVuZm9yY2VtZW50IHRvIHVzZXJzLjxvOnA+PC9vOnA+PC9TUEFOPjwv
UD4NCjxQIHN0eWxlPSJURVhULUFMSUdOOiBqdXN0aWZ5IiBjbGFzcz1Nc29Ob3JtYWw+PFNQ
QU4gDQpzdHlsZT0iRk9OVC1GQU1JTFk6ICdDYWxpYnJpJywnc2Fucy1zZXJpZic7IENPTE9S
OiAjMWY0OTdkOyBGT05ULVNJWkU6IDEwcHQiIA0KbGFuZz1FTi1VUz5vKSBQcm9kdWNlIGFu
IGluZm9ybWF0aW9uYWwgUkZDIHRoYXQgcHJvdmlkZXMgdGhlIGd1aWRlbGluZXMgZm9yIA0K
bWVjaGFuaXNtcyB0aGF0IGNhbiBkeW5hbWljYWxseSBhbmQgb24gaW50ZXJvcGVyYWJsZSBt
YW5uZXIsIGF1dG9tYXRpY2FsbHkgbWFwIA0Kc2VydmljZXMgYW5kIHBvbGljaWVzIGRlZmlu
ZWQgb24gYW4gYWJzdHJhY3QgdG9wb2xvZ3kgZ3JhcGggZG93biB0byBtb3JlIA0KZGV0YWls
ZWQgbmV0d29yayBncmFwaHMgYW5kIHNwZWNpZmljIG5ldHdvcmsgbWFuYWdlbWVudCBhbmQg
Y29udHJvbGxpbmcgDQpwb2xpY2llcy48bzpwPjwvbzpwPjwvU1BBTj48L1A+DQo8UCBzdHls
ZT0iVEVYVC1BTElHTjoganVzdGlmeSIgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0Kc3R5bGU9
IkZPTlQtRkFNSUxZOiAnQ2FsaWJyaScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogIzFmNDk3ZDsg
Rk9OVC1TSVpFOiAxMHB0IiANCmxhbmc9RU4tVVM+bykgUHJvZHVjZSBhbiBpbmZvcm1hdGlv
bmFsIFJGQyB0aGF0IHByb3ZpZGVzIHRoZSBndWlkZWxpbmVzIG9uIHVzaW5nIA0KTkVUQ09O
RiAob3IgUkVTVENPTkYpIGF1dGhlbnRpY2F0aW9uIGFuZCBhdXRob3JpemF0aW9uIG1lY2hh
bmlzbXMgdG8gYWNoaWV2ZSANCnNlY3VyaXR5IHByb3RlY3Rpb24gYW5kIGlzb2xhdGlvbicg
YXMgYW4gSW5mb3JtYXRpb25hbCANClJGQy48bzpwPjwvbzpwPjwvU1BBTj48L1A+DQo8UCBz
dHlsZT0iVEVYVC1BTElHTjoganVzdGlmeSIgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0Kc3R5
bGU9IkZPTlQtRkFNSUxZOiAnQ2FsaWJyaScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogIzFmNDk3
ZDsgRk9OVC1TSVpFOiAxMHB0IiANCmxhbmc9RU4tVVM+PG86cD4mbmJzcDs8L286cD48L1NQ
QU4+PC9QPg0KPFAgc3R5bGU9IlRFWFQtQUxJR046IGp1c3RpZnkiIGNsYXNzPU1zb05vcm1h
bD48U1BBTiANCnN0eWxlPSJGT05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5zLXNlcmlmJzsg
Q09MT1I6ICMxZjQ5N2Q7IEZPTlQtU0laRTogMTBwdCIgDQpsYW5nPUVOLVVTPk1pbGVzdG9u
ZXM6PG86cD48L286cD48L1NQQU4+PC9QPg0KPFAgc3R5bGU9IlRFWFQtQUxJR046IGp1c3Rp
ZnkiIGNsYXNzPU1zb05vcm1hbD48U1BBTiANCnN0eWxlPSJGT05ULUZBTUlMWTogJ0NhbGli
cmknLCdzYW5zLXNlcmlmJzsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtU0laRTogMTBwdCIgDQps
YW5nPUVOLVVTPj09PT09PT09PT09PG86cD48L286cD48L1NQQU4+PC9QPg0KPFAgc3R5bGU9
IlRFWFQtQUxJR046IGp1c3RpZnkiIGNsYXNzPU1zb05vcm1hbD48U1BBTiANCnN0eWxlPSJG
T05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5zLXNlcmlmJzsgQ09MT1I6ICMxZjQ5N2Q7IEZP
TlQtU0laRTogMTBwdCIgDQpsYW5nPUVOLVVTPkRlYyAyMDE0Jm5ic3A7IEluaXRpYWwgIlBy
b2JsZW0gU3RhdGVtZW50IGFuZCBVc2UgQ2FzZXMiIFdHIA0KSS1EPG86cD48L286cD48L1NQ
QU4+PC9QPg0KPFAgc3R5bGU9IlRFWFQtQUxJR046IGp1c3RpZnkiIGNsYXNzPU1zb05vcm1h
bD48U1BBTiANCnN0eWxlPSJGT05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5zLXNlcmlmJzsg
Q09MT1I6ICMxZjQ5N2Q7IEZPTlQtU0laRTogMTBwdCIgDQpsYW5nPUVOLVVTPkZlYiAyMDE1
Jm5ic3A7IEluaXRpYWwgIk11bHRpLWxheWVyIE5ldHdvcmsgR3JhcGggWUFORyBNb2RlbCIg
V0cgDQpJLUQ8bzpwPjwvbzpwPjwvU1BBTj48L1A+DQo8UCBzdHlsZT0iVEVYVC1BTElHTjog
anVzdGlmeSIgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0Kc3R5bGU9IkZPTlQtRkFNSUxZOiAn
Q2FsaWJyaScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMHB0
IiANCmxhbmc9RU4tVVM+QXByIDIwMTUmbmJzcDsgSW5pdGlhbCBzZXJ2aWNlIHNwZWNpZmlj
IGRhdGEgbW9kZWwgV0cgSS1EcyANCjxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCjxQIHN0eWxl
PSJURVhULUFMSUdOOiBqdXN0aWZ5IiBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQpzdHlsZT0i
Rk9OVC1GQU1JTFk6ICdDYWxpYnJpJywnc2Fucy1zZXJpZic7IENPTE9SOiAjMWY0OTdkOyBG
T05ULVNJWkU6IDEwcHQiIA0KbGFuZz1FTi1VUz5NYXkgMjAxNSZuYnNwOyBJbml0aWFsICJN
YXBwaW5nIEd1aWRlbGluZXMiIFdHIA0KSS1EPG86cD48L286cD48L1NQQU4+PC9QPg0KPFAg
c3R5bGU9IlRFWFQtQUxJR046IGp1c3RpZnkiIGNsYXNzPU1zb05vcm1hbD48U1BBTiANCnN0
eWxlPSJGT05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5zLXNlcmlmJzsgQ09MT1I6ICMxZjQ5
N2Q7IEZPTlQtU0laRTogMTBwdCIgDQpsYW5nPUVOLVVTPkp1biAyMDE1Jm5ic3A7IFN1Ym1p
dCAiUHJvYmxlbSBTdGF0ZW1lbnQgYW5kIFVzZSBDYXNlcyIgSS1EIHRvIA0KSUVTRzxvOnA+
PC9vOnA+PC9TUEFOPjwvUD4NCjxQIHN0eWxlPSJURVhULUFMSUdOOiBqdXN0aWZ5IiBjbGFz
cz1Nc29Ob3JtYWw+PFNQQU4gDQpzdHlsZT0iRk9OVC1GQU1JTFk6ICdDYWxpYnJpJywnc2Fu
cy1zZXJpZic7IENPTE9SOiAjMWY0OTdkOyBGT05ULVNJWkU6IDEwcHQiIA0KbGFuZz1FTi1V
Uz5KdWwgMjAxNSZuYnNwOyBJbml0aWFsICJBdXRoZW50aWNhdGlvbiBhbmQgQXV0aG9yaXph
dGlvbiIgV0cgDQpJLUQ8bzpwPjwvbzpwPjwvU1BBTj48L1A+DQo8UCBzdHlsZT0iVEVYVC1B
TElHTjoganVzdGlmeSIgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0Kc3R5bGU9IkZPTlQtRkFN
SUxZOiAnQ2FsaWJyaScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpF
OiAxMHB0IiANCmxhbmc9RU4tVVM+U2VwIDIwMTUmbmJzcDsgU3VibWl0ICJNdWx0aS1sYXll
ciBOZXR3b3JrIEdyYXBoIFlBTkcgTW9kZWwiIEktRCB0byANCklFU0c8bzpwPjwvbzpwPjwv
U1BBTj48L1A+DQo8UCBzdHlsZT0iVEVYVC1BTElHTjoganVzdGlmeSIgY2xhc3M9TXNvTm9y
bWFsPjxTUEFOIA0Kc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ2FsaWJyaScsJ3NhbnMtc2VyaWYn
OyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMHB0IiANCmxhbmc9RU4tVVM+Tm92IDIw
MTUmbmJzcDsgU3VibWl0IHNlcnZpY2Ugc3BlY2lmaWMgZGF0YSBtb2RlbCBJLURzIHRvIA0K
SUVTRzxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCjxQIHN0eWxlPSJURVhULUFMSUdOOiBqdXN0
aWZ5IiBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQpzdHlsZT0iRk9OVC1GQU1JTFk6ICdDYWxp
YnJpJywnc2Fucy1zZXJpZic7IENPTE9SOiAjMWY0OTdkOyBGT05ULVNJWkU6IDEwcHQiIA0K
bGFuZz1FTi1VUz5GZWIgMjAxNiZuYnNwOyBTdWJtaXQgIk1hcHBpbmcgR3VpZGVsaW5lcyIg
SS1EIHRvIA0KSUVTRzxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCjxQIHN0eWxlPSJURVhULUFM
SUdOOiBqdXN0aWZ5IiBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQpzdHlsZT0iRk9OVC1GQU1J
TFk6ICdDYWxpYnJpJywnc2Fucy1zZXJpZic7IENPTE9SOiAjMWY0OTdkOyBGT05ULVNJWkU6
IDEwcHQiIA0KbGFuZz1FTi1VUz5BcHIgMjAxNiZuYnNwOyBTdWJtaXQgIkF1dGhlbnRpY2F0
aW9uIGFuZCBBdXRob3JpemF0aW9uIiBJLUQgdG8gDQpJRVNHPG86cD48L286cD48L1NQQU4+
PC9QPg0KPFAgc3R5bGU9IlRFWFQtQUxJR046IGp1c3RpZnkiIGNsYXNzPU1zb05vcm1hbD48
U1BBTiANCnN0eWxlPSJGT05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5zLXNlcmlmJzsgQ09M
T1I6ICMxZjQ5N2Q7IEZPTlQtU0laRTogMTBwdCIgDQpsYW5nPUVOLVVTPiZuYnNwOyA8bzpw
PjwvbzpwPjwvU1BBTj48L1A+DQo8UCBzdHlsZT0iVEVYVC1BTElHTjoganVzdGlmeSIgY2xh
c3M9TXNvTm9ybWFsPjxTUEFOIA0Kc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ2FsaWJyaScsJ3Nh
bnMtc2VyaWYnOyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMHB0IiANCmxhbmc9RU4t
VVM+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9QPg0KPFAgc3R5bGU9IlRFWFQtQUxJR046
IGp1c3RpZnkiIGNsYXNzPU1zb05vcm1hbD48U1BBTiANCnN0eWxlPSJGT05ULUZBTUlMWTog
J0ZyZWVzdHlsZSBTY3JpcHQnOyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMHB0IiAN
Cmxhbmc9RU4tVVM+VGhhbmsgeW91LDxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCjxQIHN0eWxl
PSJURVhULUFMSUdOOiBqdXN0aWZ5IiBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQpzdHlsZT0i
Rk9OVC1GQU1JTFk6ICdGcmVlc3R5bGUgU2NyaXB0JzsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQt
U0laRTogMTBwdCIgDQpsYW5nPUVOLVVTPlRpbmE8bzpwPjwvbzpwPjwvU1BBTj48L1A+DQo8
UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQpzdHlsZT0iRk9OVC1GQU1JTFk6ICdBcmlhbCBV
bmljb2RlIE1TJywnc2Fucy1zZXJpZic7IENPTE9SOiAjMWY0OTdkOyBGT05ULVNJWkU6IDEx
cHQiIA0KbGFuZz1FTi1VUz48bzpwPiZuYnNwOzwvbzpwPjwvU1BBTj48L1A+DQo8RElWPg0K
PERJViANCnN0eWxlPSJCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZTsgQk9SREVSLUxFRlQ6
IG1lZGl1bSBub25lOyBQQURESU5HLUJPVFRPTTogMGNtOyBQQURESU5HLUxFRlQ6IDBjbTsg
UEFERElORy1SSUdIVDogMGNtOyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsgQk9S
REVSLVJJR0hUOiBtZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDNwdCI+DQo8UCBjbGFzcz1N
c29Ob3JtYWw+PEI+PFNQQU4gDQpzdHlsZT0iRk9OVC1GQU1JTFk6ICdUYWhvbWEnLCdzYW5z
LXNlcmlmJzsgQ09MT1I6IHdpbmRvd3RleHQ7IEZPTlQtU0laRTogMTBwdCIgDQpsYW5nPUVO
LVVTPkZyb206PC9TUEFOPjwvQj48U1BBTiANCnN0eWxlPSJGT05ULUZBTUlMWTogJ1RhaG9t
YScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogd2luZG93dGV4dDsgRk9OVC1TSVpFOiAxMHB0IiAN
Cmxhbmc9RU4tVVM+IFN1cGEgW21haWx0bzpzdXBhLWJvdW5jZXNAaWV0Zi5vcmddIDxCPk9u
IEJlaGFsZiBPZiA8L0I+TGl1c2h1Y2hlbmcgDQooV2lsbCk8QlI+PEI+U2VudDo8L0I+IFRo
dXJzZGF5LCBTZXB0ZW1iZXIgMjUsIDIwMTQgNzozNiBQTTxCUj48Qj5Ubzo8L0I+IEJlbm9p
dCANCkNsYWlzZTxCUj48Qj5DYzo8L0I+IHN1cGFAaWV0Zi5vcmc8QlI+PEI+U3ViamVjdDo8
L0I+IFJlOiBbU3VwYV0gQXJlYSBoYW5kLW9mZiwgDQphbmQgc29tZSBmcmllbmRseSBhZHZp
Y2UgLi4uPG86cD48L286cD48L1NQQU4+PC9QPjwvRElWPjwvRElWPg0KPFAgY2xhc3M9TXNv
Tm9ybWFsPjxTUEFOIGxhbmc9RU4tVVM+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9QPg0K
PFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0Kc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ2FsaWJy
aScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMC41cHQiIA0K
bGFuZz1FTi1VUz5IaSBCZW5vaXQsPG86cD48L286cD48L1NQQU4+PC9QPg0KPFAgc3R5bGU9
Ik1BUkdJTi1MRUZUOiAyMXB0OyBtc28tcGFyYS1tYXJnaW4tbGVmdDogMS43NWdkIiBjbGFz
cz1Nc29Ob3JtYWw+PFNQQU4gDQpzdHlsZT0iRk9OVC1GQU1JTFk6ICdDYWxpYnJpJywnc2Fu
cy1zZXJpZic7IENPTE9SOiAjMWY0OTdkOyBGT05ULVNJWkU6IDEwLjVwdCIgDQpsYW5nPUVO
LVVTPjxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbD48
U1BBTiANCnN0eWxlPSJGT05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5zLXNlcmlmJzsgQ09M
T1I6ICMxZjQ5N2Q7IEZPTlQtU0laRTogMTAuNXB0IiANCmxhbmc9RU4tVVM+QmVsb3cgaW5s
aW5lIHBsZWFzZSBzZWUgdHdvIHBpZWNlcyBvZiBjb21wbGVtZW50YXJ5IGFuc3dlciBmcm9t
IG15IA0KdGVhbSAoc3RhcnRzIHdpdGggPEk+W1dpbGxdPC9JPikuIFRoYW5rIHlvdSE8bzpw
PjwvbzpwPjwvU1BBTj48L1A+DQo8UCBzdHlsZT0iTUFSR0lOLUxFRlQ6IDIxcHQ7IG1zby1w
YXJhLW1hcmdpbi1sZWZ0OiAxLjc1Z2QiIGNsYXNzPU1zb05vcm1hbD48U1BBTiANCnN0eWxl
PSJGT05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5zLXNlcmlmJzsgQ09MT1I6ICMxZjQ5N2Q7
IEZPTlQtU0laRTogMTAuNXB0IiANCmxhbmc9RU4tVVM+PG86cD4mbmJzcDs8L286cD48L1NQ
QU4+PC9QPg0KPERJVj4NCjxQIHN0eWxlPSJURVhULUFMSUdOOiBqdXN0aWZ5IiBjbGFzcz1N
c29Ob3JtYWw+PFNQQU4gDQpzdHlsZT0iRk9OVC1GQU1JTFk6ICdDYWxpYnJpJywnc2Fucy1z
ZXJpZic7IENPTE9SOiAjMWY0OTdkOyBGT05ULVNJWkU6IDEwLjVwdCIgDQpsYW5nPUVOLVVT
PlJlZ2FyZHMsPC9TUEFOPjxTUEFOIA0Kc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ2FsaWJyaScs
J3NhbnMtc2VyaWYnOyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMXB0IiANCmxhbmc9
RU4tVVM+PG86cD48L286cD48L1NQQU4+PC9QPg0KPFAgc3R5bGU9IlRFWFQtQUxJR046IGp1
c3RpZnkiIGNsYXNzPU1zb05vcm1hbD48U1BBTiANCnN0eWxlPSJGT05ULUZBTUlMWTogJ0Nh
bGlicmknLCdzYW5zLXNlcmlmJzsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtU0laRTogMTAuNXB0
IiANCmxhbmc9RU4tVVM+V2lsbDxvOnA+PC9vOnA+PC9TUEFOPjwvUD48L0RJVj4NCjxQIHN0
eWxlPSJNQVJHSU4tTEVGVDogNDVwdDsgbXNvLXBhcmEtbWFyZ2luLWxlZnQ6IDMuNzVnZCIg
Y2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0Kc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ2FsaWJyaScs
J3NhbnMtc2VyaWYnOyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMC41cHQiIA0KbGFu
Zz1FTi1VUz48bzpwPiZuYnNwOzwvbzpwPjwvU1BBTj48L1A+DQo8RElWIA0Kc3R5bGU9IkJP
UkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBCT1JERVItTEVGVDogYmx1ZSAxLjVwdCBzb2xp
ZDsgUEFERElORy1CT1RUT006IDBjbTsgUEFERElORy1MRUZUOiA0cHQ7IFBBRERJTkctUklH
SFQ6IDBjbTsgQk9SREVSLVRPUDogbWVkaXVtIG5vbmU7IEJPUkRFUi1SSUdIVDogbWVkaXVt
IG5vbmU7IFBBRERJTkctVE9QOiAwY20iPg0KPERJVj4NCjxESVYgDQpzdHlsZT0iQk9SREVS
LUJPVFRPTTogbWVkaXVtIG5vbmU7IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElO
Ry1CT1RUT006IDBjbTsgUEFERElORy1MRUZUOiAwY207IFBBRERJTkctUklHSFQ6IDBjbTsg
Qk9SREVSLVRPUDogI2UxZTFlMSAxcHQgc29saWQ7IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5v
bmU7IFBBRERJTkctVE9QOiAzcHQiPg0KPFAgc3R5bGU9Ik1BUkdJTi1MRUZUOiA0NXB0OyBt
c28tcGFyYS1tYXJnaW4tbGVmdDogMy43NWdkIiANCmNsYXNzPU1zb05vcm1hbD48Qj48U1BB
TiANCnN0eWxlPSJGT05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5zLXNlcmlmJzsgQ09MT1I6
IHdpbmRvd3RleHQ7IEZPTlQtU0laRTogMTFwdCIgDQpsYW5nPUVOLVVTPkZyb206PC9TUEFO
PjwvQj48U1BBTiANCnN0eWxlPSJGT05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5zLXNlcmlm
JzsgQ09MT1I6IHdpbmRvd3RleHQ7IEZPTlQtU0laRTogMTFwdCIgDQpsYW5nPUVOLVVTPiBT
dXBhIFs8QSANCmhyZWY9Im1haWx0bzpzdXBhLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpz
dXBhLWJvdW5jZXNAaWV0Zi5vcmc8L0E+XSA8Qj5PbiANCkJlaGFsZiBPZiA8L0I+R2Vvcmdp
b3MgS2FyYWdpYW5uaXM8QlI+PEI+U2VudDo8L0I+IFdlZG5lc2RheSwgU2VwdGVtYmVyIDI0
LCAyMDE0IA0KNzozMCBQTTxCUj48Qj5Ubzo8L0I+IEJlbm9pdCBDbGFpc2U7IFRpbmEgVFNP
VTsgSnVlcmdlbiANClNjaG9lbndhZWxkZXI8QlI+PEI+Q2M6PC9CPiBaaGVuIENhbzsgPEEg
DQpocmVmPSJtYWlsdG86c3VwYUBpZXRmLm9yZyI+c3VwYUBpZXRmLm9yZzwvQT48QlI+PEI+
U3ViamVjdDo8L0I+IFJlOiBbU3VwYV0gQXJlYSANCmhhbmQtb2ZmLCBhbmQgc29tZSBmcmll
bmRseSBhZHZpY2UgLi4uPG86cD48L286cD48L1NQQU4+PC9QPjwvRElWPjwvRElWPg0KPFAg
c3R5bGU9Ik1BUkdJTi1MRUZUOiA0NXB0OyBtc28tcGFyYS1tYXJnaW4tbGVmdDogMy43NWdk
IiBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQpsYW5nPUVOLVVTPjxvOnA+Jm5ic3A7PC9vOnA+
PC9TUEFOPjwvUD4NCjxQIHN0eWxlPSJNQVJHSU4tTEVGVDogNDVwdDsgbXNvLXBhcmEtbWFy
Z2luLWxlZnQ6IDMuNzVnZCIgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0Kc3R5bGU9IkZPTlQt
RkFNSUxZOiAnQ2FsaWJyaScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1T
SVpFOiAxMXB0IiANCmxhbmc9RU4tVVM+SGkgQmVub2l0LDxvOnA+PC9vOnA+PC9TUEFOPjwv
UD4NCjxQIHN0eWxlPSJNQVJHSU4tTEVGVDogNDVwdDsgbXNvLXBhcmEtbWFyZ2luLWxlZnQ6
IDMuNzVnZCIgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0Kc3R5bGU9IkZPTlQtRkFNSUxZOiAn
Q2FsaWJyaScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMXB0
IiANCmxhbmc9RU4tVVM+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9QPg0KPFAgc3R5bGU9
Ik1BUkdJTi1MRUZUOiA0NXB0OyBtc28tcGFyYS1tYXJnaW4tbGVmdDogMy43NWdkIiBjbGFz
cz1Nc29Ob3JtYWw+PFNQQU4gDQpzdHlsZT0iRk9OVC1GQU1JTFk6ICdDYWxpYnJpJywnc2Fu
cy1zZXJpZic7IENPTE9SOiAjMWY0OTdkOyBGT05ULVNJWkU6IDExcHQiIA0KbGFuZz1FTi1V
Uz5UaGFuayB5b3UgZm9yIHlvdXIgY29tbWVudHMuPG86cD48L286cD48L1NQQU4+PC9QPg0K
PFAgc3R5bGU9Ik1BUkdJTi1MRUZUOiA0NXB0OyBtc28tcGFyYS1tYXJnaW4tbGVmdDogMy43
NWdkIiBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQpzdHlsZT0iRk9OVC1GQU1JTFk6ICdDYWxp
YnJpJywnc2Fucy1zZXJpZic7IENPTE9SOiAjMWY0OTdkOyBGT05ULVNJWkU6IDExcHQiIA0K
bGFuZz1FTi1VUz5QbGVhc2Ugc2VlIGluIGxpbmUsPG86cD48L286cD48L1NQQU4+PC9QPg0K
PFAgc3R5bGU9Ik1BUkdJTi1MRUZUOiA0NXB0OyBtc28tcGFyYS1tYXJnaW4tbGVmdDogMy43
NWdkIiBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQpzdHlsZT0iRk9OVC1GQU1JTFk6ICdDYWxp
YnJpJywnc2Fucy1zZXJpZic7IENPTE9SOiAjMWY0OTdkOyBGT05ULVNJWkU6IDExcHQiIA0K
bGFuZz1FTi1VUz48bzpwPiZuYnNwOzwvbzpwPjwvU1BBTj48L1A+DQo8RElWPg0KPERJViAN
CnN0eWxlPSJCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZTsgQk9SREVSLUxFRlQ6IG1lZGl1
bSBub25lOyBQQURESU5HLUJPVFRPTTogMGNtOyBQQURESU5HLUxFRlQ6IDBjbTsgUEFERElO
Ry1SSUdIVDogMGNtOyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsgQk9SREVSLVJJ
R0hUOiBtZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDNwdCI+DQo8UCBzdHlsZT0iTUFSR0lO
LUxFRlQ6IDQ1cHQ7IG1zby1wYXJhLW1hcmdpbi1sZWZ0OiAzLjc1Z2QiIA0KY2xhc3M9TXNv
Tm9ybWFsPjxCPjxTUEFOIA0Kc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGFob21hJywnc2Fucy1z
ZXJpZic7IENPTE9SOiB3aW5kb3d0ZXh0OyBGT05ULVNJWkU6IDEwcHQiIA0KbGFuZz1FTi1V
Uz5Gcm9tOjwvU1BBTj48L0I+PFNQQU4gDQpzdHlsZT0iRk9OVC1GQU1JTFk6ICdUYWhvbWEn
LCdzYW5zLXNlcmlmJzsgQ09MT1I6IHdpbmRvd3RleHQ7IEZPTlQtU0laRTogMTBwdCIgDQps
YW5nPUVOLVVTPiBTdXBhIFs8QSANCmhyZWY9Im1haWx0bzpzdXBhLWJvdW5jZXNAaWV0Zi5v
cmciPm1haWx0bzpzdXBhLWJvdW5jZXNAaWV0Zi5vcmc8L0E+XSA8Qj5PbiANCkJlaGFsZiBP
ZiA8L0I+QmVub2l0IENsYWlzZTxCUj48Qj5TZW50OjwvQj4gV2VkbmVzZGF5LCBTZXB0ZW1i
ZXIgMjQsIDIwMTQgMTA6NDEgDQpBTTxCUj48Qj5Ubzo8L0I+IEdlb3JnaW9zIEthcmFnaWFu
bmlzOyBUaW5hIFRTT1U7IEp1ZXJnZW4gDQpTY2hvZW53YWVsZGVyPEJSPjxCPkNjOjwvQj4g
WmhlbiBDYW87IDxBIA0KaHJlZj0ibWFpbHRvOnN1cGFAaWV0Zi5vcmciPnN1cGFAaWV0Zi5v
cmc8L0E+PEJSPjxCPlN1YmplY3Q6PC9CPiBSZTogW1N1cGFdIEFyZWEgDQpoYW5kLW9mZiwg
YW5kIHNvbWUgZnJpZW5kbHkgYWR2aWNlIC4uLjxvOnA+PC9vOnA+PC9TUEFOPjwvUD48L0RJ
Vj48L0RJVj4NCjxQIHN0eWxlPSJNQVJHSU4tTEVGVDogNDVwdDsgbXNvLXBhcmEtbWFyZ2lu
LWxlZnQ6IDMuNzVnZCIgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0KbGFuZz1FTi1VUz48bzpw
PiZuYnNwOzwvbzpwPjwvU1BBTj48L1A+DQo8RElWPg0KPFAgc3R5bGU9Ik1BUkdJTi1MRUZU
OiA0NXB0OyBtc28tcGFyYS1tYXJnaW4tbGVmdDogMy43NWdkIiBjbGFzcz1Nc29Ob3JtYWw+
PFNQQU4gDQpsYW5nPUVOLVVTPkhpIEdlb3JnaW9zLDxvOnA+PC9vOnA+PC9TUEFOPjwvUD48
L0RJVj4NCjxCTE9DS1FVT1RFIHN0eWxlPSJNQVJHSU4tVE9QOiA1cHQ7IE1BUkdJTi1CT1RU
T006IDVwdCI+PFBSRSBzdHlsZT0iTUFSR0lOLUxFRlQ6IDQ1cHQ7IG1zby1wYXJhLW1hcmdp
bi1sZWZ0OiAzLjc1Z2QiPjxTUEFOIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3
JzsgRk9OVC1TSVpFOiAxMHB0IiBsYW5nPUVOLVVTPkhpIEJlbm9pdCw8bzpwPjwvbzpwPjwv
U1BBTj48L1BSRT48UFJFIHN0eWxlPSJNQVJHSU4tTEVGVDogNDVwdDsgbXNvLXBhcmEtbWFy
Z2luLWxlZnQ6IDMuNzVnZCI+PFNQQU4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBO
ZXcnOyBGT05ULVNJWkU6IDEwcHQiIGxhbmc9RU4tVVM+PG86cD4mbmJzcDs8L286cD48L1NQ
QU4+PC9QUkU+PFBSRSBzdHlsZT0iTUFSR0lOLUxFRlQ6IDQ1cHQ7IG1zby1wYXJhLW1hcmdp
bi1sZWZ0OiAzLjc1Z2QiPjxTUEFOIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3
JzsgRk9OVC1TSVpFOiAxMHB0IiBsYW5nPUVOLVVTPlRoYW5rcyBmb3IgeW91ciBjb21tZW50
cyE8bzpwPjwvbzpwPjwvU1BBTj48L1BSRT48UFJFIHN0eWxlPSJNQVJHSU4tTEVGVDogNDVw
dDsgbXNvLXBhcmEtbWFyZ2luLWxlZnQ6IDMuNzVnZCI+PFNQQU4gc3R5bGU9IkZPTlQtRkFN
SUxZOiAnQ291cmllciBOZXcnOyBGT05ULVNJWkU6IDEwcHQiIGxhbmc9RU4tVVM+UGxlYXNl
IHNlZSBpbiBsaW5lLjxvOnA+PC9vOnA+PC9TUEFOPjwvUFJFPjxQUkUgc3R5bGU9Ik1BUkdJ
Ti1MRUZUOiA0NXB0OyBtc28tcGFyYS1tYXJnaW4tbGVmdDogMy43NWdkIj48U1BBTiBzdHls
ZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IEZPTlQtU0laRTogMTBwdCIgbGFuZz1F
Ti1VUz48bzpwPiZuYnNwOzwvbzpwPjwvU1BBTj48L1BSRT48UFJFIHN0eWxlPSJNQVJHSU4t
TEVGVDogNDVwdDsgbXNvLXBhcmEtbWFyZ2luLWxlZnQ6IDMuNzVnZCI+PFNQQU4gc3R5bGU9
IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBGT05ULVNJWkU6IDEwcHQiIGxhbmc9RU4t
VVM+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9QUkU+PFBSRSBzdHlsZT0iTUFSR0lOLUxF
RlQ6IDQ1cHQ7IG1zby1wYXJhLW1hcmdpbi1sZWZ0OiAzLjc1Z2QiPjxTUEFOIHN0eWxlPSJG
T05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JzsgRk9OVC1TSVpFOiAxMHB0IiBsYW5nPUVOLVVT
Pkdlb3JnaW9zOiBQbGVhc2Ugbm90ZSB0aGF0IHdlIGFyZSByZWZlcnJpbmcgdG8gdGhlIGZv
bGxvd2luZyBmaWd1cmU6PG86cD48L286cD48L1NQQU4+PC9QUkU+PFBSRSBzdHlsZT0iTUFS
R0lOLUxFRlQ6IDQ1cHQ7IG1zby1wYXJhLW1hcmdpbi1sZWZ0OiAzLjc1Z2QiPjxTUEFOIHN0
eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JzsgRk9OVC1TSVpFOiAxMHB0IiBsYW5n
PUVOLVVTPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0mbmJzcDsgPG86cD48L286cD48L1NQQU4+PC9QUkU+PFBSRSBzdHlsZT0i
TUFSR0lOLUxFRlQ6IDQ1cHQ7IG1zby1wYXJhLW1hcmdpbi1sZWZ0OiAzLjc1Z2QiPjxTUEFO
IHN0eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JzsgRk9OVC1TSVpFOiAxMHB0IiBs
YW5nPUVOLVVTPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3wgYXBwbGljYXRpb25zJm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8bzpwPjwvbzpwPjwvU1BBTj48L1BSRT48UFJF
IHN0eWxlPSJNQVJHSU4tTEVGVDogNDVwdDsgbXNvLXBhcmEtbWFyZ2luLWxlZnQ6IDMuNzVn
ZCI+PFNQQU4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBGT05ULVNJWkU6
IDEwcHQiIGxhbmc9RU4tVVM+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9TUEFOPjwvUFJFPjxQUkUgc3R5
bGU9Ik1BUkdJTi1MRUZUOiA0NXB0OyBtc28tcGFyYS1tYXJnaW4tbGVmdDogMy43NWdkIj48
U1BBTiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IEZPTlQtU0laRTogMTBw
dCIgbGFuZz1FTi1VUz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyAmbHQ7LS0t
ZW5kIHVzZS4gQXBwbC4mbmJzcDsmbmJzcDsgfDxvOnA+PC9vOnA+PC9TUEFOPjwvUFJFPjxQ
UkUgc3R5bGU9Ik1BUkdJTi1MRUZUOiA0NXB0OyBtc28tcGFyYS1tYXJnaW4tbGVmdDogMy43
NWdkIj48U1BBTiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IEZPTlQtU0la
RTogMTBwdCIgbGFuZz1FTi1VUz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0tLS0tLS0tLS0tLS0t
LS0tLS0tJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbHQ7LS0tZW5kIHVzZS4gQXBwbC4mbmJzcDsm
bmJzcDsgPG86cD48L286cD48L1NQQU4+PC9QUkU+PFBSRSBzdHlsZT0iTUFSR0lOLUxFRlQ6
IDQ1cHQ7IG1zby1wYXJhLW1hcmdpbi1sZWZ0OiAzLjc1Z2QiPjxTUEFOIHN0eWxlPSJGT05U
LUZBTUlMWTogJ0NvdXJpZXIgTmV3JzsgRk9OVC1TSVpFOiAxMHB0IiBsYW5nPUVOLVVTPiZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwO3wgZW5oYW5jZWQgT1NTJm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxvOnA+PC9vOnA+PC9TUEFOPjwv
UFJFPjxQUkUgc3R5bGU9Ik1BUkdJTi1MRUZUOiA0NXB0OyBtc28tcGFyYS1tYXJnaW4tbGVm
dDogMy43NWdkIj48U1BBTiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IEZP
TlQtU0laRTogMTBwdCIgbGFuZz1FTi1VUz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0tLS0tLS0t
LS0tLS0tLS0tLS0tJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8bzpwPjwvbzpwPjwvU1BBTj48L1BS
RT48UFJFIHN0eWxlPSJNQVJHSU4tTEVGVDogNDVwdDsgbXNvLXBhcmEtbWFyZ2luLWxlZnQ6
IDMuNzVnZCI+PFNQQU4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBGT05U
LVNJWkU6IDEwcHQiIGxhbmc9RU4tVVM+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3wmbmJzcDsmbmJz
cDsgJmx0Oy0tLSBuZXR3b3JrIHNlcnZpY2UgfDxvOnA+PC9vOnA+PC9TUEFOPjwvUFJFPjxQ
UkUgc3R5bGU9Ik1BUkdJTi1MRUZUOiA0NXB0OyBtc28tcGFyYS1tYXJnaW4tbGVmdDogMy43
NWdkIj48U1BBTiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IEZPTlQtU0la
RTogMTBwdCIgbGFuZz1FTi1VUz5ZQU5HIG1vZGVscyZuYnNwOyAvTkVUQ09ORiBpbnRlcmZh
Y2UmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxvOnA+PC9vOnA+PC9T
UEFOPjwvUFJFPjxQUkUgc3R5bGU9Ik1BUkdJTi1MRUZUOiA0NXB0OyBtc28tcGFyYS1tYXJn
aW4tbGVmdDogMy43NWdkIj48U1BBTiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5l
dyc7IEZPTlQtU0laRTogMTBwdCIgbGFuZz1FTi1VUz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvU1BBTj48
L1BSRT48UFJFIHN0eWxlPSJNQVJHSU4tTEVGVDogNDVwdDsgbXNvLXBhcmEtbWFyZ2luLWxl
ZnQ6IDMuNzVnZCI+PFNQQU4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBG
T05ULVNJWkU6IDEwcHQiIGxhbmc9RU4tVVM+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsm
bmJzcDsgY29udHJvbGxlciZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDstLS0mbmJzcDsgbWFwcGluZyBuZXR3b3JrIHNlcnZp
Y2VzIDxvOnA+PC9vOnA+PC9TUEFOPjwvUFJFPjxQUkUgc3R5bGU9Ik1BUkdJTi1MRUZUOiA0
NXB0OyBtc28tcGFyYS1tYXJnaW4tbGVmdDogMy43NWdkIj48U1BBTiBzdHlsZT0iRk9OVC1G
QU1JTFk6ICdDb3VyaWVyIE5ldyc7IEZPTlQtU0laRTogMTBwdCIgbGFuZz1FTi1VUz50byB0
b3BvbG9neTxvOnA+PC9vOnA+PC9TUEFOPjwvUFJFPjxQUkUgc3R5bGU9Ik1BUkdJTi1MRUZU
OiA0NXB0OyBtc28tcGFyYS1tYXJnaW4tbGVmdDogMy43NWdkIj48U1BBTiBzdHlsZT0iRk9O
VC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IEZPTlQtU0laRTogMTBwdCIgbGFuZz1FTi1VUz4m
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS08bzpwPjwvbzpwPjwvU1BBTj48L1BSRT48UFJFIHN0eWxlPSJNQVJHSU4tTEVGVDogNDVw
dDsgbXNvLXBhcmEtbWFyZ2luLWxlZnQ6IDMuNzVnZCI+PFNQQU4gc3R5bGU9IkZPTlQtRkFN
SUxZOiAnQ291cmllciBOZXcnOyBGT05ULVNJWkU6IDEwcHQiIGxhbmc9RU4tVVM+Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDstLS0gPG86cD48L286cD48L1NQQU4+PC9QUkU+PFBS
RSBzdHlsZT0iTUFSR0lOLUxFRlQ6IDQ1cHQ7IG1zby1wYXJhLW1hcmdpbi1sZWZ0OiAzLjc1
Z2QiPjxTUEFOIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JzsgRk9OVC1TSVpF
OiAxMHB0IiBsYW5nPUVOLVVTPmRldmljZS9mZWF0dXJlIHNwZWNpZmljIFlBTkcgbW9kZWxz
IC8gTkVUQ09ORiBpbnRlcmZhY2U8bzpwPjwvbzpwPjwvU1BBTj48L1BSRT48UFJFIHN0eWxl
PSJNQVJHSU4tTEVGVDogNDVwdDsgbXNvLXBhcmEtbWFyZ2luLWxlZnQ6IDMuNzVnZCI+PFNQ
QU4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBGT05ULVNJWkU6IDEwcHQi
IGxhbmc9RU4tVVM+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE5FMSZuYnNwOyZuYnNwOyZuYnNwOyBO
RTImbmJzcDsmbmJzcDsgTkVuPG86cD48L286cD48L1NQQU4+PC9QUkU+PC9CTE9DS1FVT1RF
Pg0KPFAgc3R5bGU9Ik1BUkdJTi1MRUZUOiA0NXB0OyBtc28tcGFyYS1tYXJnaW4tbGVmdDog
My43NWdkIiBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQpsYW5nPUVOLVVTPkl0J3Mgbm90IG9i
dmlvdXMgd2hhdCBhbiAiZW5oYW5jZWQgT1NTIiBpcz88L1NQQU4+PFNQQU4gDQpzdHlsZT0i
Q09MT1I6ICMxZjQ5N2QiIGxhbmc9RU4tVVM+PG86cD48L286cD48L1NQQU4+PC9QPg0KPFAg
c3R5bGU9Ik1BUkdJTi1MRUZUOiA0NXB0OyBtc28tcGFyYS1tYXJnaW4tbGVmdDogMy43NWdk
IiBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQpzdHlsZT0iRk9OVC1GQU1JTFk6ICdDYWxpYnJp
Jywnc2Fucy1zZXJpZic7IENPTE9SOiAjMWY0OTdkOyBGT05ULVNJWkU6IDExcHQiIA0KbGFu
Zz1FTi1VUz48bzpwPiZuYnNwOzwvbzpwPjwvU1BBTj48L1A+DQo8UCBzdHlsZT0iTUFSR0lO
LUxFRlQ6IDQ1cHQ7IG1zby1wYXJhLW1hcmdpbi1sZWZ0OiAzLjc1Z2QiIGNsYXNzPU1zb05v
cm1hbD48U1BBTiANCnN0eWxlPSJGT05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5zLXNlcmlm
JzsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtU0laRTogMTFwdCIgDQpsYW5nPUVOLVVTPkdlb3Jn
aW9zOiBpdCByZWxhdGVzIHRvIHRoZSBzeXN0ZW0gdGhhdCBydW5zIG5ldHdvcmsgc2Vydmlj
ZXMuIFRoZXNlIA0Kc2VydmljZXMgYXJlIGVuaGFuY2VkIE9wZXJhdGlvbmFsIFN1cHBvcnQg
U3lzdGVtIChPU1MpIGxpa2Ugc2VydmljZXMgdGhhdCBoZWxwIGEgDQpjb21tdW5pY2F0aW9u
IHNlcnZpY2UgcHJvdmlkZXIgdG8gbW9uaXRvciwgY29udHJvbCwgYW5hbHl6ZSBhbmQgbWFu
YWdlIGEgDQpjb21tdW5pY2F0aW9uIG5ldHdvcmsuIDxvOnA+PC9vOnA+PC9TUEFOPjwvUD4N
CjxQIA0Kc3R5bGU9Ik1BUkdJTi1CT1RUT006IDEycHQ7IE1BUkdJTi1MRUZUOiA0NXB0OyBN
QVJHSU4tUklHSFQ6IDBjbTsgbXNvLXBhcmEtbWFyZ2luLWxlZnQ6IDMuNzVnZDsgbXNvLW1h
cmdpbi10b3AtYWx0OiAwY207IG1zby1wYXJhLW1hcmdpbi1yaWdodDogMGNtOyBtc28tcGFy
YS1tYXJnaW4tYm90dG9tOiAxMi4wcHQiIA0KY2xhc3M9TXNvTm9ybWFsPjxTUEFOIGxhbmc9
RU4tVVM+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9QPjxQUkUgc3R5bGU9Ik1BUkdJTi1M
RUZUOiA0NXB0OyBtc28tcGFyYS1tYXJnaW4tbGVmdDogMy43NWdkIj48U1BBTiBzdHlsZT0i
Rk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IEZPTlQtU0laRTogMTBwdCIgbGFuZz1FTi1V
Uz5HZW9yZ2lvczogQWNjb3JkaW5nIHRvIHRoZSBwcm92aWRlZCBmaWd1cmU6IDEpIG5lZWQg
dG8gd29yayBvbiBuZXR3b3JrIHNlcnZpY2UgWWFuZyBtb2RlbHMsIDIgbWFwcGluZyBuZXR3
b3JrIHNlcnZpY2VzIHRvIHRvcG9sb2d5LCAzLiBEZXZpY2UvZmVhdHVyZSBzcGVjaWZpYyBZ
YW5nIE1vZGVscywgNCkgZW5kIHVzZXIgc3BlY2lmaWMgWWFuayBNb2RlbHMgKG91dCBvZiBz
Y29wZSkuIFRoZSBpbnRlcmZhY2UgYmV0d2VlbiBlbmQgdXNlciBhcHBsaWNhdGlvbnMgYW5k
IGEgY29udHJvbGxlciwgYW5kIGludGVyZmFjZSBiZXR3ZWVuIGVuZCB1c2VyIGFwcGxpY2F0
aW9uIGFuZCBlbmhhbmNlZCBPU1MsIGFyZSBhbHNvIG91dCBvZiBzY29wZS48bzpwPjwvbzpw
PjwvU1BBTj48L1BSRT4NCjxQIHN0eWxlPSJNQVJHSU4tTEVGVDogNDVwdDsgbXNvLXBhcmEt
bWFyZ2luLWxlZnQ6IDMuNzVnZCIgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0KbGFuZz1FTi1V
Uz5Db25jZXJuaW5nIHlvdXIgbGFzdCBzZW50ZW5jZS4gSSdtIGNvbmZ1c2VkLjxCUj5XaGF0
IGRvZXMgdGhlIA0KZm9sbG93aW5nIGRlbGl2ZXJhYmxlIG1lYW4gdGhlbj88bzpwPjwvbzpw
PjwvU1BBTj48L1A+PFBSRSBzdHlsZT0iTUFSR0lOLUxFRlQ6IDQ1cHQ7IG1zby1wYXJhLW1h
cmdpbi1sZWZ0OiAzLjc1Z2QiPjxTUEFOIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJpZXIg
TmV3JzsgRk9OVC1TSVpFOiAxMHB0IiBsYW5nPUVOLVVTPm8pIHNwZWNpZnkgYW5kIHN0YW5k
YXJkaXplIGhvdyBORVRDT05GL1lBTkcgKG9yIFJFU1RDT05GL1lBTkcpIGNhbiBiZSB1c2Vk
IHRvIHNlY3VyZWx5IGFuZCBlZmZpY2llbnRseSBkaXN0cmlidXRlIHVwIHRvIGRhdGUgKGZy
ZXNoKSBuZXR3b3JrIGdyYXBocyBiZXR3ZWVuIG5ldHdvcmsgc2VydmljZSBzeXN0ZW1zIGFu
ZCBuZXR3b3JrIG1hbmFnZW1lbnQgYW5kIGNvbnRyb2xsaW5nIHN5c3RlbXM8bzpwPjwvbzpw
PjwvU1BBTj48L1BSRT4NCjxQIHN0eWxlPSJNQVJHSU4tTEVGVDogNDVwdDsgbXNvLXBhcmEt
bWFyZ2luLWxlZnQ6IDMuNzVnZCIgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0Kc3R5bGU9IkNP
TE9SOiAjMWY0OTdkIiBsYW5nPUVOLVVTPjxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwvUD4N
CjxQIHN0eWxlPSJNQVJHSU4tTEVGVDogNDVwdDsgbXNvLXBhcmEtbWFyZ2luLWxlZnQ6IDMu
NzVnZCIgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0Kc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ2Fs
aWJyaScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMXB0IiAN
Cmxhbmc9RU4tVVM+SXQgcmVsYXRlcyB0byB0aGUgaW50ZXJmYWNlIGJldHdlZW4gdGhlIG5l
dHdvcmsgc2VydmljZSBzeXN0ZW0gDQooZW5oYW5jZWQgT1NTIGluIHRoZSBhYm92ZSBmaWd1
cmUuPG86cD48L286cD48L1NQQU4+PC9QPg0KPFAgc3R5bGU9Ik1BUkdJTi1MRUZUOiA0NXB0
OyBtc28tcGFyYS1tYXJnaW4tbGVmdDogMy43NWdkIiBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4g
DQpzdHlsZT0iRk9OVC1GQU1JTFk6ICdDYWxpYnJpJywnc2Fucy1zZXJpZic7IENPTE9SOiAj
MWY0OTdkOyBGT05ULVNJWkU6IDExcHQiIA0KbGFuZz1FTi1VUz5QbGVhc2Ugbm90ZSB0aGF0
IHdlIHNheSB0aGF0IHdlIGluaXRpYWxseSBvbmx5IGZvY3VzIG9uIHRoaXMgDQppbnRlcmZh
Y2UsIGluIG9yZGVyIHRvIG5hcnJvdyBkb3duIHRoZSBzY29wZSBvZiB0aGlzIA0KYWN0aXZp
dHk8bzpwPjwvbzpwPjwvU1BBTj48L1A+DQo8UCBzdHlsZT0iTUFSR0lOLUxFRlQ6IDQ1cHQ7
IG1zby1wYXJhLW1hcmdpbi1sZWZ0OiAzLjc1Z2QiIGNsYXNzPU1zb05vcm1hbD48U1BBTiAN
CnN0eWxlPSJGT05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5zLXNlcmlmJzsgQ09MT1I6ICMx
ZjQ5N2Q7IEZPTlQtU0laRTogMTFwdCIgDQpsYW5nPUVOLVVTPjxvOnA+Jm5ic3A7PC9vOnA+
PC9TUEFOPjwvUD4NCjxQIHN0eWxlPSJNQVJHSU4tTEVGVDogNDVwdDsgbXNvLXBhcmEtbWFy
Z2luLWxlZnQ6IDMuNzVnZCIgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0Kc3R5bGU9IkZPTlQt
RkFNSUxZOiAnQ2FsaWJyaScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1T
SVpFOiAxMXB0IiANCmxhbmc9RU4tVVM+SG93ZXZlciwgaWYgdGhlcmUgYXJlIHN1cHBvcnRz
IHRoYXQgdGhpbmsgd2Ugc2hvdWxkIGluaXRpYWxseSBmb2N1cyANCmFsc28gb24gdGhlIGlu
dGVyZmFjZSBiZXR3ZWVuIGVuZCB1c2VyIGFwcGxpY2F0aW9uIGFuZCBjb250cm9sbGVyIHdl
IHdpbGwgYWxzbyANCmluY2x1ZGUgdGhpcyBpbnRlcmZhY2UgaW4gdGhlIHNjb3BlLjxvOnA+
PC9vOnA+PC9TUEFOPjwvUD48UFJFIHN0eWxlPSJNQVJHSU4tTEVGVDogMjFwdDsgbXNvLXBh
cmEtbWFyZ2luLWxlZnQ6IDEuNzVnZCI+PFNQQU4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291
cmllciBOZXcnOyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMHB0IiBsYW5nPUVOLVVT
PjxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwvUFJFPjxQUkUgc3R5bGU9Ik1BUkdJTi1MRUZU
OiAyMXB0OyBtc28tcGFyYS1tYXJnaW4tbGVmdDogMS43NWdkIj48Qj48ST48U1BBTiBzdHls
ZT0iRk9OVC1GQU1JTFk6ICdDYWxpYnJpJywnc2Fucy1zZXJpZic7IENPTE9SOiAjMWY0OTdk
OyBGT05ULVNJWkU6IDEwLjVwdCIgbGFuZz1FTi1VUz5bV2lsbF06IEZpcnN0IG9mIGFsbCwg
SU1PSCwgdGhlIGZpZ3VyZXMgZnJvbSBCZW5vaXQgYW5kIEdlb3JnaW9zIGFyZSBub3QgaW5j
b21wYXRpYmxlLiBGcm9tIHRoZSBwZXJzcGVjdGl2ZSBvZiBjb250cm9sbGVyLCB0aGV5IGFy
ZSBkaWZmZXJlbnQgbGF0aXR1ZGVzIG9mIG5vcnRoYmFuZC4gVGhlIGFwcGxpY2F0aW9uIGFu
ZCA8L1NQQU4+PC9JPjwvQj48Qj48ST48U1BBTiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDYWxp
YnJpJywnc2Fucy1zZXJpZic7IENPTE9SOiAjMWY0OTdkOyBGT05ULVNJWkU6IDExcHQiIGxh
bmc9RU4tVVM+ZW5oYW5jZWQgT1NTPC9TUEFOPjwvST48L0I+PEI+PEk+PFNQQU4gc3R5bGU9
IkZPTlQtRkFNSUxZOiAnQ2FsaWJyaScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogIzFmNDk3ZDsg
Rk9OVC1TSVpFOiAxMC41cHQiIGxhbmc9RU4tVVM+IGluIEdlb3JnaW9zIGZpZ3VyZSBjYW4g
YmUgcHV0IHRvZ2V0aGVyIGludG8gYW4gbGFyZ2VyIGFwcGxpY2F0aW9uKiBsYXllciBvZiBC
ZW5vaXShr3MgZmlndXJlLiBUaGUgbmV0d29yayBncmFwaCBpcyBwcm9wb3NlZCB0byBwcm92
aWRlIG5ldHdvcmstd2lkZSBjb25maWd1cmF0aW9uIGNvbnRhaW5pbmcgdGhlIGtleSBpbmZv
cm1hdGlvbiBmb3Igc2VydmljZSBpbnN0YW5jZXMuIE9uZSBleGFtcGxlIGlzLCBmb3IgdGhl
IEREQyB1c2UgY2FzZSwgdGhlIG5ldHdvcmsgZ3JhcGggY29udGFpbnMgdGhlIGtleSBpbmZv
cm1hdGlvbiBzdWNoIGFzIHRoZSBrZXkgbm9kZSBpbmZvcm1hdGlvbiBvZiB0aGUgcGF0aCBh
bmQgdGhlIGtleSByZXF1aXJlbWVudCBvZiB0cmFmZmljIHN0ZWVyaW5nLiA8bzpwPjwvbzpw
PjwvU1BBTj48L0k+PC9CPjwvUFJFPjxQUkUgc3R5bGU9Ik1BUkdJTi1MRUZUOiAyMXB0OyBt
c28tcGFyYS1tYXJnaW4tbGVmdDogMS43NWdkIj48Qj48ST48U1BBTiBzdHlsZT0iRk9OVC1G
QU1JTFk6ICdDYWxpYnJpJywnc2Fucy1zZXJpZic7IENPTE9SOiAjMWY0OTdkOyBGT05ULVNJ
WkU6IDEwLjVwdCIgbGFuZz1FTi1VUz48bzpwPiZuYnNwOzwvbzpwPjwvU1BBTj48L0k+PC9C
PjwvUFJFPjxQUkUgc3R5bGU9Ik1BUkdJTi1MRUZUOiAyMXB0OyBtc28tcGFyYS1tYXJnaW4t
bGVmdDogMS43NWdkIj48Qj48ST48U1BBTiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDYWxpYnJp
Jywnc2Fucy1zZXJpZic7IENPTE9SOiAjMWY0OTdkOyBGT05ULVNJWkU6IDEwLjVwdCIgbGFu
Zz1FTi1VUz5SZWdhcmRpbmcgdG8gdGhlIGFwcCwgbWFuYWdlbWVudCBhcHAsIGVuZCB1c2Vy
IGFwcCBoZXJlLCBJIHdhbnQgdG8gYWRkIHNvbWV0aGluZyByZWxhdGVkIHRvIHRoZSBoaXN0
b3J5IG9mIHRoaXMgd29yay4gQXQgdGhlIHZlcnkgYmVnaW5uaW5nLCB3aGVuIHRoaXMgd29y
ayBpcyBjYWxsIEFQT05GIGJlZm9yZSBUb3JvbnRvIElFVEYgbWVldGluZywgdGhlIGVuZCB1
c2VyIGFwcCBpcyBpbiB0aGUgc2NvcGUuIEhvd2V2ZXIsIHRoZXJlIGFyZSBtYWlubHkgdGhy
ZWUgcmVhc29ucyB0aGF0IHdlIHJlbW92ZSB0aGlzIHBvaW50OjxvOnA+PC9vOnA+PC9TUEFO
PjwvST48L0I+PC9QUkU+PFBSRSBzdHlsZT0iVEVYVC1JTkRFTlQ6IC0xOHB0OyBNQVJHSU4t
TEVGVDogMzlwdDsgbXNvLXBhcmEtbWFyZ2luLWxlZnQ6IDEuNzVnZCI+PEI+PEk+PFNQQU4g
c3R5bGU9IkZPTlQtRkFNSUxZOiAnQ2FsaWJyaScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogIzFm
NDk3ZDsgRk9OVC1TSVpFOiAxMC41cHQiIGxhbmc9RU4tVVM+MS48L1NQQU4+PC9JPjwvQj48
Qj48ST48U1BBTiBzdHlsZT0iQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtU0laRTogN3B0IiBsYW5n
PUVOLVVTPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L1NQQU4+PC9JPjwvQj48
Qj48ST48U1BBTiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDYWxpYnJpJywnc2Fucy1zZXJpZic7
IENPTE9SOiAjMWY0OTdkOyBGT05ULVNJWkU6IDEwLjVwdCIgbGFuZz1FTi1VUz5UaGUgY29u
ZmxpY3Rpb24gd2l0aCBBRUNPTiwgd2UgZGlzY3Vzc2VkIHdpdGggcHJvcG9uZW50cyBvZiBB
RUNPTiBhbmQgdG8gYXZvaWQgdGhlIGNvbmZsaWN0IGFzIGF0IHRoYXQgdGltZSB0aGV5IHdl
cmUgcHJvcG9zaW5nIHRoZSBpbnRlcmZhY2UgZnJvbSBlbmQgdXNlciBhcHAgdG8gbmV0d29y
ayBkZXZpY2VzLiBMYXRlciBpbiB0aGUgSUVTRyBtZWV0aW5nIGluIFRvcm9udG8sIHdlIHN1
Y2Nlc3NmdWxseSBjbGFyaWZpZWQgdGhlIGRpZmZlcmVuY2VzIGFuZCBnb3QgdGhlIHN1Z2dl
c3Rpb24gdG8gZm9jdXMgb24gbWFuYWdlbWVudCBhcHAuPG86cD48L286cD48L1NQQU4+PC9J
PjwvQj48L1BSRT48UFJFIHN0eWxlPSJURVhULUlOREVOVDogLTE4cHQ7IE1BUkdJTi1MRUZU
OiAzOXB0OyBtc28tcGFyYS1tYXJnaW4tbGVmdDogMS43NWdkIj48Qj48ST48U1BBTiBzdHls
ZT0iRk9OVC1GQU1JTFk6ICdDYWxpYnJpJywnc2Fucy1zZXJpZic7IENPTE9SOiAjMWY0OTdk
OyBGT05ULVNJWkU6IDEwLjVwdCIgbGFuZz1FTi1VUz4yLjwvU1BBTj48L0k+PC9CPjxCPjxJ
PjxTUEFOIHN0eWxlPSJDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiA3cHQiIGxhbmc9RU4t
VVM+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvU1BBTj48L0k+PC9CPjxCPjxJ
PjxTUEFOIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5zLXNlcmlmJzsgQ09M
T1I6ICMxZjQ5N2Q7IEZPTlQtU0laRTogMTAuNXB0IiBsYW5nPUVOLVVTPkxhcnMgRWdnZXJ0
IHNob3dlZCBoaXMgY29uY2VybmluZyBhYm91dCB0aGUgaW50ZXJmYWNlIGJldHdlZW4gZW5k
IHVzZXIgYXBwIGFuZCBuZXR3b3JrIGRldmljZXMgbWF5IGxlYWQgdG8gc2VjdXJpdHkgaXNz
dWUuICZuYnNwO0tvc3RhcyBQZW50aWtvdXNpcyBhbHNvIG1lbnRpb25lZCB0aGlzIHRvIG1l
LiA8bzpwPjwvbzpwPjwvU1BBTj48L0k+PC9CPjwvUFJFPjxQUkUgc3R5bGU9Ik1BUkdJTi1M
RUZUOiAyMXB0OyBtc28tcGFyYS1tYXJnaW4tbGVmdDogMS43NWdkIj48Qj48ST48U1BBTiBz
dHlsZT0iRk9OVC1GQU1JTFk6ICdDYWxpYnJpJywnc2Fucy1zZXJpZic7IENPTE9SOiAjMWY0
OTdkOyBGT05ULVNJWkU6IDEwLjVwdCIgbGFuZz1FTi1VUz48bzpwPiZuYnNwOzwvbzpwPjwv
U1BBTj48L0k+PC9CPjwvUFJFPjxQUkUgc3R5bGU9Ik1BUkdJTi1MRUZUOiAyMXB0OyBtc28t
cGFyYS1tYXJnaW4tbGVmdDogMS43NWdkIj48Qj48ST48U1BBTiBzdHlsZT0iRk9OVC1GQU1J
TFk6ICdDYWxpYnJpJywnc2Fucy1zZXJpZic7IENPTE9SOiAjMWY0OTdkOyBGT05ULVNJWkU6
IDEwLjVwdCIgbGFuZz1FTi1VUz5Ib3dldmVyLCB0aGVzZSBhcmUgb2xkIHN0b3JpZXMuIER1
cmluZyB0aGUgVG9yb250byBCb0YsIHNvbWVvbmUgYWxzbyBzdWdnZXN0ZWQgdXMgcmUtcHV0
IHRoZSBlbmQgdXNlciBhcHAgaW50byBjb3BlLiBBIGxhcmdlIGFwcCBsYXllciBjb250YWlu
aW5nIGJvdGggZW5kIHVzZXIgYXBwIGFuZCBtYW5hZ2VtZW50IGFwcCBtYXkgcmVwbGFjZSB0
aGUgZmlyc3QgdHdvIGxheWVycyBpbiB0aGUgb2xkIDQgbGF5ZXJzIGZpZ3VyZS4gSGVyZSwg
bXkgcXVlc3Rpb24gaXMsIGFyZSB5b3UgaW4gZmF2b3Igb2YgYWRkaW5nIGVuZCB1c2VyIGFw
cCBpbnRvIFNVUEEgc2NvcGUgb3Igbm90PzxvOnA+PC9vOnA+PC9TUEFOPjwvST48L0I+PC9Q
UkU+PFBSRSBzdHlsZT0iTUFSR0lOLUxFRlQ6IDIxcHQ7IG1zby1wYXJhLW1hcmdpbi1sZWZ0
OiAxLjc1Z2QiPjxTUEFOIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5zLXNl
cmlmJzsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtU0laRTogMTAuNXB0IiBsYW5nPUVOLVVTPjxv
OnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwvUFJFPjxQUkUgc3R5bGU9Ik1BUkdJTi1MRUZUOiA0
NXB0OyBtc28tcGFyYS1tYXJnaW4tbGVmdDogMy43NWdkIj48U1BBTiBzdHlsZT0iRk9OVC1G
QU1JTFk6ICdDb3VyaWVyIE5ldyc7IEZPTlQtU0laRTogMTBwdCIgbGFuZz1FTi1VUz48bzpw
PiZuYnNwOzwvbzpwPjwvU1BBTj48L1BSRT48UFJFIHN0eWxlPSJNQVJHSU4tTEVGVDogNDVw
dDsgbXNvLXBhcmEtbWFyZ2luLWxlZnQ6IDMuNzVnZCI+PFNQQU4gc3R5bGU9IkZPTlQtRkFN
SUxZOiAnQ291cmllciBOZXcnOyBGT05ULVNJWkU6IDEwcHQiIGxhbmc9RU4tVVM+UmVnYXJk
aW5nIHlvdXIgY29tbWVudCwgIiBJJ20gbm90IGNvbnZpbmNlZCB3ZSBjb3VsZCBzdGFuZGFy
ZGl6ZSB0aGVtLCBhcyB0aGV5IGFyZSBvcGVyYXRvcnMgc3BlY2lmaWMsIGFuZCB3aWxsIGJl
IGV2b2x2aW5nIGFsb25nIHRoZSB0aW1lLiBUaGVyZSBhcmUgbWFueSBkaWZmZXJlbnQgd2F5
cyB0byBjb25maWd1cmUgYSBWUE4sIGZvciBleGFtcGxlLiIgV2VyZSB5b3UgcmVmZXJyaW5n
IHRvOjxvOnA+PC9vOnA+PC9TUEFOPjwvUFJFPjxQUkUgc3R5bGU9Ik1BUkdJTi1MRUZUOiA0
NXB0OyBtc28tcGFyYS1tYXJnaW4tbGVmdDogMy43NWdkIj48U1BBTiBzdHlsZT0iRk9OVC1G
QU1JTFk6ICdDb3VyaWVyIE5ldyc7IEZPTlQtU0laRTogMTBwdCIgbGFuZz1FTi1VUz4zLiBE
ZXZpY2UvZmVhdHVyZSBzcGVjaWZpYyBZYW5nIE1vZGVscz88bzpwPjwvbzpwPjwvU1BBTj48
L1BSRT4NCjxQIHN0eWxlPSJNQVJHSU4tTEVGVDogNDVwdDsgbXNvLXBhcmEtbWFyZ2luLWxl
ZnQ6IDMuNzVnZCIgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0KbGFuZz1FTi1VUz5ObywgdGhl
IHNlcnZpY2UgWUFORyBtb2RlbHMgPG86cD48L286cD48L1NQQU4+PC9QPg0KPFAgc3R5bGU9
Ik1BUkdJTi1MRUZUOiA0NXB0OyBtc28tcGFyYS1tYXJnaW4tbGVmdDogMy43NWdkIiBjbGFz
cz1Nc29Ob3JtYWw+PFNQQU4gDQpzdHlsZT0iRk9OVC1GQU1JTFk6ICdDYWxpYnJpJywnc2Fu
cy1zZXJpZic7IENPTE9SOiAjMWY0OTdkOyBGT05ULVNJWkU6IDExcHQiIA0KbGFuZz1FTi1V
Uz48bzpwPiZuYnNwOzwvbzpwPjwvU1BBTj48L1A+DQo8UCBzdHlsZT0iTUFSR0lOLUxFRlQ6
IDQ1cHQ7IG1zby1wYXJhLW1hcmdpbi1sZWZ0OiAzLjc1Z2QiIGNsYXNzPU1zb05vcm1hbD48
U1BBTiANCnN0eWxlPSJGT05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5zLXNlcmlmJzsgQ09M
T1I6ICMxZjQ5N2Q7IEZPTlQtU0laRTogMTFwdCIgDQpsYW5nPUVOLVVTPkdlb3JnaW9zOiBJ
IHNlZSwgYnV0IHdlIGNhbiB3b3JrIG9uIFlBTkcgbW9kZWxzIHRoYXQgY2FuIGJlIHVzZWQg
Zm9yIA0KYSBudW1iZXIgb2YgbWFpbiBuZXR3b3JrIHNlcnZpY2VzLCB3aGljaCBhcmUgZXNz
ZW50aWFsIGZvciBvcGVyYXRvcnMgYW5kIHRoYXQgDQp0aGV5IHdvdWxkIGxpa2UgdG8gaGF2
ZSB0aGVtIHN0YW5kYXJkaXplZC48bzpwPjwvbzpwPjwvU1BBTj48L1A+DQo8UCBzdHlsZT0i
TUFSR0lOLUxFRlQ6IDQ1cHQ7IG1zby1wYXJhLW1hcmdpbi1sZWZ0OiAzLjc1Z2QiIGNsYXNz
PU1zb05vcm1hbD48U1BBTiANCnN0eWxlPSJGT05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5z
LXNlcmlmJzsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtU0laRTogMTFwdCIgDQpsYW5nPUVOLVVT
PjxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwvUD48UFJFIHN0eWxlPSJNQVJHSU4tTEVGVDog
NDVwdDsgbXNvLXBhcmEtbWFyZ2luLWxlZnQ6IDMuNzVnZCI+PFNQQU4gc3R5bGU9IkZPTlQt
RkFNSUxZOiAnQ291cmllciBOZXcnOyBGT05ULVNJWkU6IDEwcHQiIGxhbmc9RU4tVVM+PG86
cD4mbmJzcDs8L286cD48L1NQQU4+PC9QUkU+PFBSRSBzdHlsZT0iTUFSR0lOLUxFRlQ6IDQ1
cHQ7IG1zby1wYXJhLW1hcmdpbi1sZWZ0OiAzLjc1Z2QiPjxTUEFOIHN0eWxlPSJGT05ULUZB
TUlMWTogJ0NvdXJpZXIgTmV3JzsgRk9OVC1TSVpFOiAxMHB0IiBsYW5nPUVOLVVTPjxvOnA+
Jm5ic3A7PC9vOnA+PC9TUEFOPjwvUFJFPg0KPEJMT0NLUVVPVEUgc3R5bGU9Ik1BUkdJTi1U
T1A6IDVwdDsgTUFSR0lOLUJPVFRPTTogNXB0Ij48UFJFIHN0eWxlPSJNQVJHSU4tTEVGVDog
NDVwdDsgbXNvLXBhcmEtbWFyZ2luLWxlZnQ6IDMuNzVnZCI+PFNQQU4gc3R5bGU9IkZPTlQt
RkFNSUxZOiAnQ291cmllciBOZXcnOyBGT05ULVNJWkU6IDEwcHQiIGxhbmc9RU4tVVM+U2Vl
IGluLWxpbmU8bzpwPjwvbzpwPjwvU1BBTj48L1BSRT48UFJFIHN0eWxlPSJNQVJHSU4tTEVG
VDogNDVwdDsgbXNvLXBhcmEtbWFyZ2luLWxlZnQ6IDMuNzVnZCI+PFNQQU4gc3R5bGU9IkZP
TlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBGT05ULVNJWkU6IDEwcHQiIGxhbmc9RU4tVVM+
RGVhciBhbGwsPG86cD48L286cD48L1NQQU4+PC9QUkU+PFBSRSBzdHlsZT0iTUFSR0lOLUxF
RlQ6IDQ1cHQ7IG1zby1wYXJhLW1hcmdpbi1sZWZ0OiAzLjc1Z2QiPjxTUEFOIHN0eWxlPSJG
T05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JzsgRk9OVC1TSVpFOiAxMHB0IiBsYW5nPUVOLVVT
PjxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwvUFJFPjxQUkUgc3R5bGU9Ik1BUkdJTi1MRUZU
OiA0NXB0OyBtc28tcGFyYS1tYXJnaW4tbGVmdDogMy43NWdkIj48U1BBTiBzdHlsZT0iRk9O
VC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IEZPTlQtU0laRTogMTBwdCIgbGFuZz1FTi1VUz5I
b3BlIHRoaXMgdmVyc2lvbiBvZiBkcmFmdCBjaGFydGVyIGFkZHJlc3MgbW9zdCBvZiB0aGUg
Y29tbWVudHMgZnJvbSB0aGUgbGlzdC48bzpwPjwvbzpwPjwvU1BBTj48L1BSRT48UFJFIHN0
eWxlPSJNQVJHSU4tTEVGVDogNDVwdDsgbXNvLXBhcmEtbWFyZ2luLWxlZnQ6IDMuNzVnZCI+
PFNQQU4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBGT05ULVNJWkU6IDEw
cHQiIGxhbmc9RU4tVVM+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9QUkU+PFBSRSBzdHls
ZT0iTUFSR0lOLUxFRlQ6IDQ1cHQ7IG1zby1wYXJhLW1hcmdpbi1sZWZ0OiAzLjc1Z2QiPjxT
UEFOIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JzsgRk9OVC1TSVpFOiAxMHB0
IiBsYW5nPUVOLVVTPi0tLS0tLTxvOnA+PC9vOnA+PC9TUEFOPjwvUFJFPjxQUkUgc3R5bGU9
Ik1BUkdJTi1MRUZUOiA0NXB0OyBtc28tcGFyYS1tYXJnaW4tbGVmdDogMy43NWdkIj48U1BB
TiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IEZPTlQtU0laRTogMTBwdCIg
bGFuZz1FTi1VUz48bzpwPiZuYnNwOzwvbzpwPjwvU1BBTj48L1BSRT48UFJFIHN0eWxlPSJN
QVJHSU4tTEVGVDogNDVwdDsgbXNvLXBhcmEtbWFyZ2luLWxlZnQ6IDMuNzVnZCI+PFNQQU4g
c3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBGT05ULVNJWkU6IDEwcHQiIGxh
bmc9RU4tVVM+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9QUkU+PFBSRSBzdHlsZT0iTUFS
R0lOLUxFRlQ6IDQ1cHQ7IG1zby1wYXJhLW1hcmdpbi1sZWZ0OiAzLjc1Z2QiPjxTUEFOIHN0
eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JzsgRk9OVC1TSVpFOiAxMHB0IiBsYW5n
PUVOLVVTPjxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwvUFJFPjxQUkUgc3R5bGU9Ik1BUkdJ
Ti1MRUZUOiA0NXB0OyBtc28tcGFyYS1tYXJnaW4tbGVmdDogMy43NWdkIj48U1BBTiBzdHls
ZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IEZPTlQtU0laRTogMTBwdCIgbGFuZz1F
Ti1VUz48bzpwPiZuYnNwOzwvbzpwPjwvU1BBTj48L1BSRT48L0JMT0NLUVVPVEU+DQo8QkxP
Q0tRVU9URSBzdHlsZT0iTUFSR0lOLVRPUDogNXB0OyBNQVJHSU4tQk9UVE9NOiA1cHQiPjxQ
UkUgc3R5bGU9Ik1BUkdJTi1MRUZUOiA0NXB0OyBtc28tcGFyYS1tYXJnaW4tbGVmdDogMy43
NWdkIj48U1BBTiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IEZPTlQtU0la
RTogMTBwdCIgbGFuZz1FTi1VUz5JbiBwYXJ0aWN1bGFyLCBhcyBzdGFydGluZyBwb2ludCwg
U1VQQSB3aWxsIG9ubHkgZm9jdXMgb24gbmV0d29yayBzZXJ2aWNlcywgd2hpY2ggYXJlIGVu
aGFuY2VkIE9wZXJhdGlvbmFsIFN1cHBvcnQgU3lzdGVtIChPU1MpIGxpa2Ugc2VydmljZXMg
dGhhdCBoZWxwIGEgY29tbXVuaWNhdGlvbiBzZXJ2aWNlIHByb3ZpZGVyIHRvIG1vbml0b3Is
IGNvbnRyb2wsIGFuYWx5emUgYW5kIG1hbmFnZSBhIGNvbW11bmljYXRpb24gbmV0d29yay4g
VGhlIHN5c3RlbXMgdGhhdCBhcmUgcnVubml1bmcgc3VjaCBuZXR3b3JrIHNlcnZpY2VzIGFy
ZSBkZW5vdGVkIGluIHRoaXMgZG9jdW1lbnQgYXMgTmV0d29yayBTZXJ2aWNlIFN5c3RlbXMu
PG86cD48L286cD48L1NQQU4+PC9QUkU+PFBSRSBzdHlsZT0iTUFSR0lOLUxFRlQ6IDQ1cHQ7
IG1zby1wYXJhLW1hcmdpbi1sZWZ0OiAzLjc1Z2QiPjxTUEFOIHN0eWxlPSJGT05ULUZBTUlM
WTogJ0NvdXJpZXIgTmV3JzsgRk9OVC1TSVpFOiAxMHB0IiBsYW5nPUVOLVVTPkVhY2ggbmV0
d29yayBzZXJ2aWNlIGNhbiBiZSByZXByZXNlbnRlZCBieSBhIGNsYXNzaWZpZWQgYXBwbGlj
YXRpb24gYmFzZWQgUE9MSUNZIG1vZGVsLCBzaW5jZSBpdCBjYW4gbW9kZWwgdGhlIGdyb3Vw
IG9mIGRlbWFuZHMgd2hpY2ggYXJlIFNIQVJFRCBhbmQgVU5JRklFRCBhbmQgYXJlIGNvbWlu
ZyBmcm9tIGEgYnVuZGxlIG9mIGFwcGxpY2F0aW9ucyB0aGF0IGltcG9zZSBzaW1pbGFyIHJl
cXVpcmVtZW50cyBvbiB0aGUgY29tbXVuaWNhdGlvbiBuZXR3b3JrLjxvOnA+PC9vOnA+PC9T
UEFOPjwvUFJFPjwvQkxPQ0tRVU9URT48UFJFIHN0eWxlPSJNQVJHSU4tTEVGVDogNDVwdDsg
bXNvLXBhcmEtbWFyZ2luLWxlZnQ6IDMuNzVnZCI+PFNQQU4gc3R5bGU9IkZPTlQtRkFNSUxZ
OiAnQ291cmllciBOZXcnOyBGT05ULVNJWkU6IDEwcHQiIGxhbmc9RU4tVVM+SSdtIGFmcmFp
ZCBJIGRvbid0IHVuZGVyc3RhbmQgKGxpa2UgSqi5cmdlbik8bzpwPjwvbzpwPjwvU1BBTj48
L1BSRT48UFJFIHN0eWxlPSJNQVJHSU4tTEVGVDogNDVwdDsgbXNvLXBhcmEtbWFyZ2luLWxl
ZnQ6IDMuNzVnZCI+PFNQQU4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ2FsaWJyaScsJ3NhbnMt
c2VyaWYnOyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMXB0IiBsYW5nPUVOLVVTPjxv
OnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwvUFJFPjxQUkUgc3R5bGU9Ik1BUkdJTi1MRUZUOiA0
NXB0OyBtc28tcGFyYS1tYXJnaW4tbGVmdDogMy43NWdkIj48U1BBTiBzdHlsZT0iRk9OVC1G
QU1JTFk6ICdDYWxpYnJpJywnc2Fucy1zZXJpZic7IENPTE9SOiAjMWY0OTdkOyBGT05ULVNJ
WkU6IDExcHQiIGxhbmc9RU4tVVM+R2Vvcmdpb3M6IFdoYXQgd2Ugd2FudCB0byBzYXkgaXMg
dGhhdCB0aGVyZSBhcmUgYXBwbGljYXRpb25zIHRoYXQgaW1wb3NlIHNpbWlsYXIgcmVxdWly
ZW1lbnRzIG9uIHRoZSBjb21tdW5pY2F0aW9uIG5ldHdvcmsuIEZvciBlYWNoIGdyb3VwIG9m
IHN1Y2ggYnVsayBvZiBhcHBsaWNhdGlvbnMgYSBuZXR3b3JrIHNlcnZpY2UgY2FuIGJlIGRl
ZmluZWQgdGhhdCBjYW4gYmUgcmVwcmVzZW50ZWQgYnkgYSBzZXJ2aWNlIHBvbGljeSBtb2Rl
bCAoaS5lLiwgaXRzIGFjdGlvbnMgYW5kIGNvbnN0cmFpbnRzKS48bzpwPjwvbzpwPjwvU1BB
Tj48L1BSRT48UFJFIHN0eWxlPSJNQVJHSU4tTEVGVDogNDVwdDsgbXNvLXBhcmEtbWFyZ2lu
LWxlZnQ6IDMuNzVnZCI+PFNQQU4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ2FsaWJyaScsJ3Nh
bnMtc2VyaWYnOyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMXB0IiBsYW5nPUVOLVVT
PjxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwvUFJFPjxQUkUgc3R5bGU9Ik1BUkdJTi1MRUZU
OiA0NXB0OyBtc28tcGFyYS1tYXJnaW4tbGVmdDogMy43NWdkIj48U1BBTiBzdHlsZT0iRk9O
VC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IEZPTlQtU0laRTogMTBwdCIgbGFuZz1FTi1VUz48
bzpwPiZuYnNwOzwvbzpwPjwvU1BBTj48L1BSRT48UFJFIHN0eWxlPSJNQVJHSU4tTEVGVDog
NDVwdDsgbXNvLXBhcmEtbWFyZ2luLWxlZnQ6IDMuNzVnZCI+PFNQQU4gc3R5bGU9IkZPTlQt
RkFNSUxZOiAnQ291cmllciBOZXcnOyBGT05ULVNJWkU6IDEwcHQiIGxhbmc9RU4tVVM+R2Vv
cmdpb3M6IFRoYW5rcyBmb3IgdGhlIHN1Z2dlc3Rpb24sIHRoZSB0ZXh0IG5lZWRzIHRvIGJl
IHJlcGhyYXNlZCwgc2VlIGJlbG93OjxvOnA+PC9vOnA+PC9TUEFOPjwvUFJFPjxQUkUgc3R5
bGU9Ik1BUkdJTi1MRUZUOiA0NXB0OyBtc28tcGFyYS1tYXJnaW4tbGVmdDogMy43NWdkIj48
U1BBTiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IEZPTlQtU0laRTogMTBw
dCIgbGFuZz1FTi1VUz5FYWNoIG5ldHdvcmsgc2VydmljZSBjYW4gYmUgcmVwcmVzZW50ZWQg
YnkgYW4gYXBwbGljYXRpb24gYmFzZWQgUE9MSUNZIG1vZGVsLCB3aGljaCBpcyBVTklGSUVE
IGFuZCBTSEFSRUQsIHNpbmNlIGl0IGNhbiBtb2RlbCB0aGUgZ3JvdXAgb2YgZGVtYW5kcyAo
aS5lLCBhY3Rpb25zIGFuZCBjb25zdHJhaW50cykgdGhhdCBhcmUgY29taW5nIGZyb20gYSBi
dW5kbGUgb2YgYXBwbGljYXRpb25zIHRoYXQgaW1wb3NlIHNpbWlsYXIgcmVxdWlyZW1lbnRz
IG9uIHRoZSBjb21tdW5pY2F0aW9uIG5ldHdvcmsuPG86cD48L286cD48L1NQQU4+PC9QUkU+
DQo8UCBzdHlsZT0iTUFSR0lOLUxFRlQ6IDQ1cHQ7IG1zby1wYXJhLW1hcmdpbi1sZWZ0OiAz
Ljc1Z2QiIGNsYXNzPU1zb05vcm1hbD48U1BBTiANCmxhbmc9RU4tVVM+SSBzdGlsbCBkb24n
dCB1bmRlcnN0YW5kPC9TUEFOPjxTUEFOIHN0eWxlPSJDT0xPUjogIzFmNDk3ZCIgDQpsYW5n
PUVOLVVTPi48L1NQQU4+PFNQQU4gbGFuZz1FTi1VUz4gd2hhdCAiVU5JRklFRCBhbmQgU0hB
UkVEIiBtZWFuLjwvU1BBTj48U1BBTiANCnN0eWxlPSJDT0xPUjogIzFmNDk3ZCIgbGFuZz1F
Ti1VUz48bzpwPjwvbzpwPjwvU1BBTj48L1A+DQo8UCBzdHlsZT0iTUFSR0lOLUxFRlQ6IDQ1
cHQ7IG1zby1wYXJhLW1hcmdpbi1sZWZ0OiAzLjc1Z2QiIGNsYXNzPU1zb05vcm1hbD48U1BB
TiANCnN0eWxlPSJGT05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5zLXNlcmlmJzsgQ09MT1I6
ICMxZjQ5N2Q7IEZPTlQtU0laRTogMTFwdCIgDQpsYW5nPUVOLVVTPjxvOnA+Jm5ic3A7PC9v
OnA+PC9TUEFOPjwvUD4NCjxQIHN0eWxlPSJNQVJHSU4tTEVGVDogNDVwdDsgbXNvLXBhcmEt
bWFyZ2luLWxlZnQ6IDMuNzVnZCIgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0Kc3R5bGU9IkZP
TlQtRkFNSUxZOiAnQ2FsaWJyaScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogIzFmNDk3ZDsgRk9O
VC1TSVpFOiAxMXB0IiANCmxhbmc9RU4tVVM+R2Vvcmdpb3M6IHRoZSB0ZXJtcyChsFVOSUZJ
RUShsSBhbmQgobBTSEFSRUShsaGxIHJlbGF0ZSB0byB0aGUgd2F5IG9mIGhvdyANCnRoZSBz
ZXJ2aWNlIHBvbGljeSBtb2RlbCBpcyBnZW5lcmF0ZWQsIHNpbmNlIGl0IGdyb3VwcyBhbmQg
aXQgdW5pZmllcyBhbmQgc2hhcmVzIA0KdGhlIHNpbWlsYXIgcmVxdWlyZW1lbnRzIGltcG9z
ZWQgYnkgYSBidWxrIG9mIA0KYXBwbGljYXRpb25zLjxvOnA+PC9vOnA+PC9TUEFOPjwvUD4N
CjxQIHN0eWxlPSJNQVJHSU4tTEVGVDogNDVwdDsgbXNvLXBhcmEtbWFyZ2luLWxlZnQ6IDMu
NzVnZCIgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0Kc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ2Fs
aWJyaScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMXB0IiAN
Cmxhbmc9RU4tVVM+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9QPg0KPFAgc3R5bGU9Ik1B
UkdJTi1MRUZUOiA0NXB0OyBtc28tcGFyYS1tYXJnaW4tbGVmdDogMy43NWdkIiBjbGFzcz1N
c29Ob3JtYWw+PFNQQU4gDQpzdHlsZT0iRk9OVC1GQU1JTFk6ICdDYWxpYnJpJywnc2Fucy1z
ZXJpZic7IENPTE9SOiAjMWY0OTdkOyBGT05ULVNJWkU6IDExcHQiIA0KbGFuZz1FTi1VUz48
bzpwPiZuYnNwOzwvbzpwPjwvU1BBTj48L1A+DQo8UCBzdHlsZT0iTUFSR0lOLUxFRlQ6IDQ1
cHQ7IG1zby1wYXJhLW1hcmdpbi1sZWZ0OiAzLjc1Z2QiIGNsYXNzPU1zb05vcm1hbD48U1BB
TiANCnN0eWxlPSJGT05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5zLXNlcmlmJzsgQ09MT1I6
ICMxZjQ5N2Q7IEZPTlQtU0laRTogMTFwdCIgDQpsYW5nPUVOLVVTPjxvOnA+Jm5ic3A7PC9v
OnA+PC9TUEFOPjwvUD4NCjxQIHN0eWxlPSJNQVJHSU4tTEVGVDogNDVwdDsgbXNvLXBhcmEt
bWFyZ2luLWxlZnQ6IDMuNzVnZCIgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0Kc3R5bGU9IkZP
TlQtRkFNSUxZOiAnQ2FsaWJyaScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogIzFmNDk3ZDsgRk9O
VC1TSVpFOiAxMXB0IiANCmxhbmc9RU4tVVM+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9Q
Pg0KPFAgc3R5bGU9Ik1BUkdJTi1MRUZUOiA0NXB0OyBtc28tcGFyYS1tYXJnaW4tbGVmdDog
My43NWdkIiBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQpzdHlsZT0iRk9OVC1GQU1JTFk6ICdD
YWxpYnJpJywnc2Fucy1zZXJpZic7IENPTE9SOiAjMWY0OTdkOyBGT05ULVNJWkU6IDExcHQi
IA0KbGFuZz1FTi1VUz48bzpwPiZuYnNwOzwvbzpwPjwvU1BBTj48L1A+DQo8UCANCnN0eWxl
PSJNQVJHSU4tQk9UVE9NOiAxMnB0OyBNQVJHSU4tTEVGVDogNDVwdDsgTUFSR0lOLVJJR0hU
OiAwY207IG1zby1wYXJhLW1hcmdpbi1sZWZ0OiAzLjc1Z2Q7IG1zby1tYXJnaW4tdG9wLWFs
dDogMGNtOyBtc28tcGFyYS1tYXJnaW4tcmlnaHQ6IDBjbTsgbXNvLXBhcmEtbWFyZ2luLWJv
dHRvbTogMTIuMHB0IiANCmNsYXNzPU1zb05vcm1hbD48U1BBTiBsYW5nPUVOLVVTPjxvOnA+
Jm5ic3A7PC9vOnA+PC9TUEFOPjwvUD48UFJFIHN0eWxlPSJNQVJHSU4tTEVGVDogNDVwdDsg
bXNvLXBhcmEtbWFyZ2luLWxlZnQ6IDMuNzVnZCI+PFNQQU4gc3R5bGU9IkZPTlQtRkFNSUxZ
OiAnQ291cmllciBOZXcnOyBGT05ULVNJWkU6IDEwcHQiIGxhbmc9RU4tVVM+PG86cD4mbmJz
cDs8L286cD48L1NQQU4+PC9QUkU+DQo8QkxPQ0tRVU9URSBzdHlsZT0iTUFSR0lOLVRPUDog
NXB0OyBNQVJHSU4tQk9UVE9NOiA1cHQiPjxQUkUgc3R5bGU9Ik1BUkdJTi1MRUZUOiA0NXB0
OyBtc28tcGFyYS1tYXJnaW4tbGVmdDogMy43NWdkIj48U1BBTiBzdHlsZT0iRk9OVC1GQU1J
TFk6ICdDb3VyaWVyIE5ldyc7IEZPTlQtU0laRTogMTBwdCIgbGFuZz1FTi1VUz4oMikgdHJh
bnNwb3J0aW5nIG1vZGVsIGluc3RhbmNlcyBlaXRoZXIgdXNpbmcgTkVUQ09ORiBvciBSRVNU
Q09ORiBhbmQgKDMpIHByb3ZpZGluZyBndWlkZWxpbmVzIG9uIEFVVE9NQVRJQ0FMTFkgbWFw
cGluZyBwb2xpY2llcyB0byBhdHRyaWJ1dGVzIG9mIHRoZSBuZXR3b3JrIGdyYXBocy48bzpw
PjwvbzpwPjwvU1BBTj48L1BSRT48UFJFIHN0eWxlPSJNQVJHSU4tTEVGVDogNDVwdDsgbXNv
LXBhcmEtbWFyZ2luLWxlZnQ6IDMuNzVnZCI+PFNQQU4gc3R5bGU9IkZPTlQtRkFNSUxZOiAn
Q291cmllciBOZXcnOyBGT05ULVNJWkU6IDEwcHQiIGxhbmc9RU4tVVM+PG86cD4mbmJzcDs8
L286cD48L1NQQU4+PC9QUkU+PFBSRSBzdHlsZT0iTUFSR0lOLUxFRlQ6IDQ1cHQ7IG1zby1w
YXJhLW1hcmdpbi1sZWZ0OiAzLjc1Z2QiPjxTUEFOIHN0eWxlPSJGT05ULUZBTUlMWTogJ0Nv
dXJpZXIgTmV3JzsgRk9OVC1TSVpFOiAxMHB0IiBsYW5nPUVOLVVTPkFsdGhvdWdoIHNvbWUg
SUVURiB3b3JraW5nIGdyb3VwcyBoYXZlIHN0YXJ0ZWQgd29yayByZWxhdGluZyB0byB0aGUg
ZGVzY3JpcHRpb24gb2YgdmFyaW91cyB0b3BvbG9naWVzIHN1Y2ggYXMgSTJSUyAoTDNhbmQg
cm91dGluZyB0b3BvbG9naWVzKSwgQUxUTyAoY29zdCBtYXBzKSwgU0ZDIChzZXJ2aWNlIGNo
YWluKSwgbm9uZSBvZiB0aGVzZSBncm91cHMgYWltIGF0IG9mZmVyaW5nIHRydWx5IGdlbmVy
aWMgdG9wb2xvZ3kgbW9kZWxzIGZvciB0aGUgc3RhbmRhcmQgbm9ydGhib3VuZCBpbnRlcmZh
Y2UuPG86cD48L286cD48L1NQQU4+PC9QUkU+PFBSRSBzdHlsZT0iTUFSR0lOLUxFRlQ6IDQ1
cHQ7IG1zby1wYXJhLW1hcmdpbi1sZWZ0OiAzLjc1Z2QiPjxTUEFOIHN0eWxlPSJGT05ULUZB
TUlMWTogJ0NvdXJpZXIgTmV3JzsgRk9OVC1TSVpFOiAxMHB0IiBsYW5nPUVOLVVTPlNVUEEg
d2lsbCB3b3JrIG9uIGRlZmluaW5nIGludGVyZmFjZXMgYmFzZWQgb24gdGhlIGNvbmNlcHQg
b2YgbmV0d29yayBncmFwaCwgYW4gZW50aXR5IGRlc2NyaWJpbmcgYW4gYXJiaXRyYXJ5IHRv
cG9sb2d5IG9mIG5vZGVzIGFuZCBsaW5rcyBhdCBhbnkgbGV2ZWwgb2YgZ3JhbnVsYXJpdHku
IFN1Y2ggYSBncmFwaCBtYXkgZGVzY3JpYmUsIGZvciBleGFtcGxlLCBhIHBoeXNpY2FsIHRv
cG9sb2d5LCBhIHNlcnZpY2UgdG9wb2xvZ3kgb3IgdGhlIHJlbGF0aW9uc2hpcHMgYmV0d2Vl
biBkYXRhY2VudGVycy4gQW55IG5ldHdvcmsgdG9wb2xvZ3kgZGF0YSBtb2RlbHMgb3IgcG9s
aWN5IG1vZGVscyB0aGF0IGhhdmUgYmVlbiBkZWZpbmVkIChvciBhcmUgYmVpbmcgZGVmaW5l
ZCkgd2l0aGluIHRoZSBJRVRGIHdpbGwgYmUgcmV1c2VkIGluIFNVUEEgYXMgbXVjaCBhcyBw
b3NzaWJsZS48bzpwPjwvbzpwPjwvU1BBTj48L1BSRT48UFJFIHN0eWxlPSJNQVJHSU4tTEVG
VDogNDVwdDsgbXNvLXBhcmEtbWFyZ2luLWxlZnQ6IDMuNzVnZCI+PFNQQU4gc3R5bGU9IkZP
TlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBGT05ULVNJWkU6IDEwcHQiIGxhbmc9RU4tVVM+
SW4gYWRkaXRpb24gdG8gdGhlIGFib3ZlLCBwb2xpY2llcyBtYXkgYmUgZGVmaW5lZCBhbmQg
YXBwbGllZCB0byBhIG5ldHdvcmsgZ3JhcGguIFRoZXNlIGFwcGxpY2F0aW9uIGJhc2VkIHBv
bGljaWVzIGFyZSBhY3Rpb25zIG9yIGNvbnN0cmFpbnRzIGdlbmVyYXRlZCBieSBOZXR3b3Jr
IFNlcnZpY2UgU3lzdGVtcy4gVGhleSBhcmUgdGhlbiBtYXBwZWQgZnJvbSB0aGUgbmV0d29y
ayBncmFwaCBpbnN0YW5jZSBpbnRvIHNwZWNpZmljIG5ldHdvcmsgbWFuYWdlbWVudCBwb2xp
Y2llcyB0b3dhcmQgbmV0d29yayBjb21wb25lbnRzLjxvOnA+PC9vOnA+PC9TUEFOPjwvUFJF
PjwvQkxPQ0tRVU9URT48UFJFIHN0eWxlPSJNQVJHSU4tTEVGVDogNDVwdDsgbXNvLXBhcmEt
bWFyZ2luLWxlZnQ6IDMuNzVnZCI+PFNQQU4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmll
ciBOZXcnOyBGT05ULVNJWkU6IDEwcHQiIGxhbmc9RU4tVVM+PG86cD4mbmJzcDs8L286cD48
L1NQQU4+PC9QUkU+PFBSRSBzdHlsZT0iTUFSR0lOLUxFRlQ6IDQ1cHQ7IG1zby1wYXJhLW1h
cmdpbi1sZWZ0OiAzLjc1Z2QiPjxTUEFOIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJpZXIg
TmV3JzsgRk9OVC1TSVpFOiAxMHB0IiBsYW5nPUVOLVVTPjxvOnA+Jm5ic3A7PC9vOnA+PC9T
UEFOPjwvUFJFPjxQUkUgc3R5bGU9Ik1BUkdJTi1MRUZUOiA0NXB0OyBtc28tcGFyYS1tYXJn
aW4tbGVmdDogMy43NWdkIj48U1BBTiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5l
dyc7IEZPTlQtU0laRTogMTBwdCIgbGFuZz1FTi1VUz5HZW9yZ2lvczogdGhlIGFib3ZlIHRl
eHQgaXMgbm90IGNsZWFyLiBUaGVyZWZvcmUsIEkgYW0gcmVwaHJhc2luZyBpdDo8bzpwPjwv
bzpwPjwvU1BBTj48L1BSRT48UFJFIHN0eWxlPSJNQVJHSU4tTEVGVDogNDVwdDsgbXNvLXBh
cmEtbWFyZ2luLWxlZnQ6IDMuNzVnZCI+PFNQQU4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291
cmllciBOZXcnOyBGT05ULVNJWkU6IDEwcHQiIGxhbmc9RU4tVVM+PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PG86cD48L286cD48L1NQQU4+PC9QUkU+
PFBSRSBzdHlsZT0iTUFSR0lOLUxFRlQ6IDQ1cHQ7IG1zby1wYXJhLW1hcmdpbi1sZWZ0OiAz
Ljc1Z2QiPjxTUEFOIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JzsgRk9OVC1T
SVpFOiAxMHB0IiBsYW5nPUVOLVVTPlRoZSBtYWluIGdvYWwgb2YgU1VQQSBpcyB0byBwcm92
aWRlIGFwcGxpY2F0aW9uIGJhc2VkIHBvbGljaWVzIGFuZCBtZWFucyB0byBtb2RlbCBhbmQg
cHJvZ3JhbSB0aGUgYWJzdHJhY3QgdmlldyBvZiBuZXR3b3JrIGluZnJhc3RydWN0dXJlIGFu
ZCBzZXJ2aWNlIGZ1bmN0aW9uIGludGVyZGVwZW5kZW5jaWVzIGluIG9yZGVyIHRvIHN1cHBv
cnQgYW5kIEFVVE9NQVRJQ0FMTFkgZmVlZCBuZXR3b3JrIG1hbmFnZW1lbnQgYW5kIGNvbnRy
b2xsaW5nIHBvbGljaWVzLiBUaGlzIGNhbiBiZSByZWFsaXplZCBieTo8bzpwPjwvbzpwPjwv
U1BBTj48L1BSRT48UFJFIHN0eWxlPSJNQVJHSU4tTEVGVDogNDVwdDsgbXNvLXBhcmEtbWFy
Z2luLWxlZnQ6IDMuNzVnZCI+PFNQQU4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBO
ZXcnOyBGT05ULVNJWkU6IDEwcHQiIGxhbmc9RU4tVVM+PG86cD4mbmJzcDs8L286cD48L1NQ
QU4+PC9QUkU+PFBSRSBzdHlsZT0iTUFSR0lOLUxFRlQ6IDQ1cHQ7IG1zby1wYXJhLW1hcmdp
bi1sZWZ0OiAzLjc1Z2QiPjxTUEFOIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3
JzsgRk9OVC1TSVpFOiAxMHB0IiBsYW5nPUVOLVVTPigxKSBtb2RlbGluZyB0aGUgbmV0d29y
ayBncmFwaCwgd2hpY2ggYW1vbmcgb3RoZXJzIGluY2x1ZGUgcG9saWN5IG1vZGVscywgZGF0
YSBtb2RlbHMgYW5kIGFwcGxpY2F0aW9uIGJhc2VkIHBvbGljaWVzLCB1c2luZyBZQU5HLCA8
bzpwPjwvbzpwPjwvU1BBTj48L1BSRT48UFJFIHN0eWxlPSJNQVJHSU4tTEVGVDogNDVwdDsg
bXNvLXBhcmEtbWFyZ2luLWxlZnQ6IDMuNzVnZCI+PFNQQU4gc3R5bGU9IkZPTlQtRkFNSUxZ
OiAnQ291cmllciBOZXcnOyBGT05ULVNJWkU6IDEwcHQiIGxhbmc9RU4tVVM+PG86cD4mbmJz
cDs8L286cD48L1NQQU4+PC9QUkU+PFBSRSBzdHlsZT0iTUFSR0lOLUxFRlQ6IDQ1cHQ7IG1z
by1wYXJhLW1hcmdpbi1sZWZ0OiAzLjc1Z2QiPjxTUEFOIHN0eWxlPSJGT05ULUZBTUlMWTog
J0NvdXJpZXIgTmV3JzsgRk9OVC1TSVpFOiAxMHB0IiBsYW5nPUVOLVVTPigyKSBhcHBseWlu
ZyBORVRDT05GIChvciBSRVNUQ09ORikgdG8gZW5hYmxlIGRpc3NlbWluYXRpb24gb2YgdXAg
dG8gZGF0ZSAoZnJlc2gpIG5ldHdvcmsgZ3JhcGhzIGluIGEgc2VjdXJlIGFuZCBlZmZpY2ll
bnQgbWFubmVyIGJldHdlZW4gbmV0d29yayBzZXJ2aWNlIHN5c3RlbXMgYW5kIG5ldHdvcmsg
bWFuYWdlbWVudCBhbmQgY29udHJvbGxpbmcgc3lzdGVtcywgPG86cD48L286cD48L1NQQU4+
PC9QUkU+DQo8UCANCnN0eWxlPSJNQVJHSU4tQk9UVE9NOiAxMnB0OyBNQVJHSU4tTEVGVDog
NDVwdDsgTUFSR0lOLVJJR0hUOiAwY207IG1zby1wYXJhLW1hcmdpbi1sZWZ0OiAzLjc1Z2Q7
IG1zby1tYXJnaW4tdG9wLWFsdDogMGNtOyBtc28tcGFyYS1tYXJnaW4tcmlnaHQ6IDBjbTsg
bXNvLXBhcmEtbWFyZ2luLWJvdHRvbTogMTIuMHB0IiANCmNsYXNzPU1zb05vcm1hbD48U1BB
TiBsYW5nPUVOLVVTPiJiZXR3ZWVuIG5ldHdvcmsgc2VydmljZSBzeXN0ZW1zIGFuZCBuZXR3
b3JrIA0KbWFuYWdlbWVudCBhbmQgY29udHJvbGxpbmcgc3lzdGVtIi4gV2hhdCBhcmUgdGhv
c2U/IEkgZG9uJ3Qgc2VlIHRoZW0gaW4geW91ciANCmZpZ3VyZS48QlI+QWxzbywgd2h5IHNo
b3VsZCBhbGwgb2YgdGhlc2UgbmVlZCB0byBrbm93IGFib3V0IHRoZSANCnRvcG9sb2d5Pzwv
U1BBTj48U1BBTiBzdHlsZT0iQ09MT1I6ICMxZjQ5N2QiIGxhbmc9RU4tVVM+PG86cD48L286
cD48L1NQQU4+PC9QPg0KPFAgDQpzdHlsZT0iTUFSR0lOLUJPVFRPTTogMTJwdDsgTUFSR0lO
LUxFRlQ6IDQ1cHQ7IE1BUkdJTi1SSUdIVDogMGNtOyBtc28tcGFyYS1tYXJnaW4tbGVmdDog
My43NWdkOyBtc28tbWFyZ2luLXRvcC1hbHQ6IDBjbTsgbXNvLXBhcmEtbWFyZ2luLXJpZ2h0
OiAwY207IG1zby1wYXJhLW1hcmdpbi1ib3R0b206IDEyLjBwdCIgDQpjbGFzcz1Nc29Ob3Jt
YWw+PFNQQU4gDQpzdHlsZT0iRk9OVC1GQU1JTFk6ICdDYWxpYnJpJywnc2Fucy1zZXJpZic7
IENPTE9SOiAjMWY0OTdkOyBGT05ULVNJWkU6IDExcHQiIA0KbGFuZz1FTi1VUz48bzpwPiZu
YnNwOzwvbzpwPjwvU1BBTj48L1A+DQo8UCANCnN0eWxlPSJNQVJHSU4tQk9UVE9NOiAxMnB0
OyBNQVJHSU4tTEVGVDogNDVwdDsgTUFSR0lOLVJJR0hUOiAwY207IG1zby1wYXJhLW1hcmdp
bi1sZWZ0OiAzLjc1Z2Q7IG1zby1tYXJnaW4tdG9wLWFsdDogMGNtOyBtc28tcGFyYS1tYXJn
aW4tcmlnaHQ6IDBjbTsgbXNvLXBhcmEtbWFyZ2luLWJvdHRvbTogMTIuMHB0IiANCmNsYXNz
PU1zb05vcm1hbD48U1BBTiANCnN0eWxlPSJGT05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5z
LXNlcmlmJzsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtU0laRTogMTFwdCIgDQpsYW5nPUVOLVVT
Pkdlb3JnaW9zOiBJbiB0aGUgZmlndXJlLCB0aGUgZW5oYW5jZWQgT1NTIHJlcHJlc2VudHMg
dGhlIG5ldHdvcmsgDQpzZXJ2aWNlIHN5c3RlbSBhbmQgdGhlIGNvbnRyb2xsZXIgcmVwcmVz
ZW50cyB0aGUgbmV0d29yayBtYW5hZ2VtZW50IGFuZCANCmNvbnRyb2xsaW5nIHN5c3RlbS48
bzpwPjwvbzpwPjwvU1BBTj48L1A+DQo8UCANCnN0eWxlPSJNQVJHSU4tQk9UVE9NOiAxMnB0
OyBNQVJHSU4tTEVGVDogNDVwdDsgTUFSR0lOLVJJR0hUOiAwY207IG1zby1wYXJhLW1hcmdp
bi1sZWZ0OiAzLjc1Z2Q7IG1zby1tYXJnaW4tdG9wLWFsdDogMGNtOyBtc28tcGFyYS1tYXJn
aW4tcmlnaHQ6IDBjbTsgbXNvLXBhcmEtbWFyZ2luLWJvdHRvbTogMTIuMHB0IiANCmNsYXNz
PU1zb05vcm1hbD48U1BBTiANCnN0eWxlPSJGT05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5z
LXNlcmlmJzsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtU0laRTogMTFwdCIgDQpsYW5nPUVOLVVT
PkluIHRoaXMgY29udGV4dCwgbmV0d29yayBzZXJ2aWNlcyBjYW4gYmUgdXNlZCB0byBwcm92
aWRlIHRoZSByZXF1aXJlZCANCiZuYnNwO2NvbmZpZ3VyYXRpb24gYW5kIGFwcGxpY2F0aW9u
IHByb2dyYW1taW5nIGludGVyZmFjZXMgdG8gc2VydmljZSANCmRldmVsb3BlcnMuIFN1YnNl
cXVlbnRseSwgYSBuZXR3b3JrIHNlcnZpY2UgY2FuIHVzZSB0aGUgYXBwbGljYXRpb24gYmFz
ZWQgDQpkZW1hbmRzIChmb3IgYWN0aW9ucyBhbmQgY29uc3RyYWludHMpIGFuZCBwb3NzaWJs
eSB1cGRhdGUgaXRzIGFzc29jaWF0ZWQgbmV0d29yayANCnNlcnZpY2UgJm5ic3A7YXR0cmli
dXRlcy4gRXhhbXBsZXMgb2YgbmV0d29yayBzZXJ2aWNlcyB0aGF0IGNhbiBtb2RpZnkgJm5i
c3A7dGhlIA0KbmV0d29yayBzZXJ2aWNlIGF0dHJpYnV0ZXMgYXJlIGZvciBleGFtcGxlLCBM
M1ZQTiBjb25maWd1cmF0aW9uIGFuZCBJUHY2IA0KdHJhbnNpdGlvbnMuIDxvOnA+PC9vOnA+
PC9TUEFOPjwvUD4NCjxQIA0Kc3R5bGU9Ik1BUkdJTi1CT1RUT006IDEycHQ7IE1BUkdJTi1M
RUZUOiA0NXB0OyBNQVJHSU4tUklHSFQ6IDBjbTsgbXNvLXBhcmEtbWFyZ2luLWxlZnQ6IDMu
NzVnZDsgbXNvLW1hcmdpbi10b3AtYWx0OiAwY207IG1zby1wYXJhLW1hcmdpbi1yaWdodDog
MGNtOyBtc28tcGFyYS1tYXJnaW4tYm90dG9tOiAxMi4wcHQiIA0KY2xhc3M9TXNvTm9ybWFs
PjxTUEFOIA0Kc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ2FsaWJyaScsJ3NhbnMtc2VyaWYnOyBD
T0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMXB0IiANCmxhbmc9RU4tVVM+Rm9yIGVhY2gg
bmV0d29yayBzZXJ2aWNlIGluc3RhbmNlIGEgbmV0d29yayBncmFwaCBuZWVkcyB0byBiZSAN
CmdlbmVyYXRlZCBhbmQgbWFpbnRhaW5lZC4gPG86cD48L286cD48L1NQQU4+PC9QPg0KPFAg
DQpzdHlsZT0iTUFSR0lOLUJPVFRPTTogMTJwdDsgTUFSR0lOLUxFRlQ6IDQ1cHQ7IE1BUkdJ
Ti1SSUdIVDogMGNtOyBtc28tcGFyYS1tYXJnaW4tbGVmdDogMy43NWdkOyBtc28tbWFyZ2lu
LXRvcC1hbHQ6IDBjbTsgbXNvLXBhcmEtbWFyZ2luLXJpZ2h0OiAwY207IG1zby1wYXJhLW1h
cmdpbi1ib3R0b206IDEyLjBwdCIgDQpjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQpzdHlsZT0i
Rk9OVC1GQU1JTFk6ICdDYWxpYnJpJywnc2Fucy1zZXJpZic7IENPTE9SOiAjMWY0OTdkOyBG
T05ULVNJWkU6IDExcHQiIA0KbGFuZz1FTi1VUz5UaGUgdXAgdG8gZGF0ZSBuZXR3b3JrIGdy
YXBoIG5lZWRzIHRvICgxKSBiZSBjb21tdW5pY2F0ZWQgYmV0d2VlbiANCnRoZSZuYnNwOyBu
ZXR3b3JrIHNlcnZpY2Ugc3lzdGVtcyBhbmQgdGhlIG5ldHdvcmsgJm5ic3A7Jm5ic3A7bWFu
YWdlbWVudCBhbmQgDQpjb250cm9sbGluZyBzeXN0ZW1zLCAoMikgbWFwIHRoZSBhdHRyaWJ1
dGVzIG9mIHRoZSBuZXR3b3JrIHNlcnZpY2UgZ3JhcGggaW50byANCnNwZWNpZmljIG5ldHdv
cmsgbWFuYWdlbWVudCBwb2xpY2llcy48bzpwPjwvbzpwPjwvU1BBTj48L1A+DQo8UCBzdHls
ZT0iTUFSR0lOLUxFRlQ6IDIxcHQ7IG1zby1wYXJhLW1hcmdpbi1sZWZ0OiAxLjc1Z2QiIA0K
Y2xhc3M9TXNvTm9ybWFsPjxCPjxJPjxTUEFOIA0Kc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ2Fs
aWJyaScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMC41cHQi
IA0KbGFuZz1FTi1VUz5bV2lsbF0gVG8gbW9kZWxpbmcgc2VydmljZSByZXF1aXJlbWVudCBh
bmQgY3JlYXRlIHNlcnZpY2UgaW5zdGFuY2VzLCANCkFQUCBuZWVkcyBhIHZpZXcgb2YgdG9w
b2xvZ3kgdG8gZm9ybSBuZXR3b3JrIGNvbmZpZ3VyYXRpb24gYWNjb3JkaW5nIHRvIHRoZSBr
ZXkgDQppbmZvcm1hdGlvbiBvZiBkZXZpY2VzIHRvcG9sb2d5LiBUaGlzIGNvbmZpZ3VyYXRp
b24gaXMgZXZlbnR1YWxseSBtYXBwZWQgdG8gdGhlIA0Kc2VsZWN0ZWQgbmV0d29yayBkZXZp
Y2VzIGFjY29yZGluZyB0byB0b3BvbG9neSBwcm92aWRlZCBieSANClNVUEEuPG86cD48L286
cD48L1NQQU4+PC9JPjwvQj48L1A+DQo8UCBzdHlsZT0iTUFSR0lOLUxFRlQ6IDIxcHQ7IG1z
by1wYXJhLW1hcmdpbi1sZWZ0OiAxLjc1Z2QiIGNsYXNzPU1zb05vcm1hbD48U1BBTiANCnN0
eWxlPSJGT05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5zLXNlcmlmJzsgQ09MT1I6ICMxZjQ5
N2Q7IEZPTlQtU0laRTogMTAuNXB0IiANCmxhbmc9RU4tVVM+PG86cD4mbmJzcDs8L286cD48
L1NQQU4+PC9QPg0KPFAgc3R5bGU9Ik1BUkdJTi1MRUZUOiA0NXB0OyBtc28tcGFyYS1tYXJn
aW4tbGVmdDogMy43NWdkIiBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQpzdHlsZT0iRk9OVC1G
QU1JTFk6ICdDb3VyaWVyIE5ldyc7IEZPTlQtU0laRTogMTBwdCIgbGFuZz1FTi1VUz5CZXN0
IA0KcmVnYXJkcyw8bzpwPjwvbzpwPjwvU1BBTj48L1A+DQo8UCBzdHlsZT0iTUFSR0lOLUxF
RlQ6IDQ1cHQ7IG1zby1wYXJhLW1hcmdpbi1sZWZ0OiAzLjc1Z2QiIGNsYXNzPU1zb05vcm1h
bD48U1BBTiANCnN0eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JzsgRk9OVC1TSVpF
OiAxMHB0IiANCmxhbmc9RU4tVVM+R2Vvcmdpb3M8L1NQQU4+PFNQQU4gDQpzdHlsZT0iRk9O
VC1GQU1JTFk6ICdDYWxpYnJpJywnc2Fucy1zZXJpZic7IENPTE9SOiAjMWY0OTdkOyBGT05U
LVNJWkU6IDExcHQiIA0KbGFuZz1FTi1VUz48bzpwPjwvbzpwPjwvU1BBTj48L1A+DQo8UCAN
CnN0eWxlPSJNQVJHSU4tQk9UVE9NOiAxMnB0OyBNQVJHSU4tTEVGVDogNDVwdDsgTUFSR0lO
LVJJR0hUOiAwY207IG1zby1wYXJhLW1hcmdpbi1sZWZ0OiAzLjc1Z2Q7IG1zby1tYXJnaW4t
dG9wLWFsdDogMGNtOyBtc28tcGFyYS1tYXJnaW4tcmlnaHQ6IDBjbTsgbXNvLXBhcmEtbWFy
Z2luLWJvdHRvbTogMTIuMHB0IiANCmNsYXNzPU1zb05vcm1hbD48U1BBTiANCnN0eWxlPSJG
T05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5zLXNlcmlmJzsgQ09MT1I6ICMxZjQ5N2Q7IEZP
TlQtU0laRTogMTFwdCIgDQpsYW5nPUVOLVVTPjxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwv
UD4NCjxQIHN0eWxlPSJNQVJHSU4tTEVGVDogNDVwdDsgbXNvLXBhcmEtbWFyZ2luLWxlZnQ6
IDMuNzVnZCIgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0Kc3R5bGU9IkZPTlQtRkFNSUxZOiAn
Q291cmllciBOZXcnOyBGT05ULVNJWkU6IDEwcHQiIA0KbGFuZz1FTi1VUz48bzpwPiZuYnNw
OzwvbzpwPjwvU1BBTj48L1A+DQo8UCANCnN0eWxlPSJNQVJHSU4tQk9UVE9NOiAxMnB0OyBN
QVJHSU4tTEVGVDogNDVwdDsgTUFSR0lOLVJJR0hUOiAwY207IG1zby1wYXJhLW1hcmdpbi1s
ZWZ0OiAzLjc1Z2Q7IG1zby1tYXJnaW4tdG9wLWFsdDogMGNtOyBtc28tcGFyYS1tYXJnaW4t
cmlnaHQ6IDBjbTsgbXNvLXBhcmEtbWFyZ2luLWJvdHRvbTogMTIuMHB0IiANCmNsYXNzPU1z
b05vcm1hbD48U1BBTiANCnN0eWxlPSJGT05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5zLXNl
cmlmJzsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtU0laRTogMTFwdCIgDQpsYW5nPUVOLVVTPjxv
OnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwvUD4NCjxQIA0Kc3R5bGU9Ik1BUkdJTi1CT1RUT006
IDEycHQ7IE1BUkdJTi1MRUZUOiA0NXB0OyBNQVJHSU4tUklHSFQ6IDBjbTsgbXNvLXBhcmEt
bWFyZ2luLWxlZnQ6IDMuNzVnZDsgbXNvLW1hcmdpbi10b3AtYWx0OiAwY207IG1zby1wYXJh
LW1hcmdpbi1yaWdodDogMGNtOyBtc28tcGFyYS1tYXJnaW4tYm90dG9tOiAxMi4wcHQiIA0K
Y2xhc3M9TXNvTm9ybWFsPjxTUEFOIGxhbmc9RU4tVVM+PEJSPjxCUj5SZWdhcmRzLCANCkJl
bm9pdDxvOnA+PC9vOnA+PC9TUEFOPjwvUD48L0RJVj48L0RJVj48L0ZPTlQ+PC9ESVY+PHA+
yOe5+8T6tO3O873TytXBy7jD08q8/qOsx+vNqLn9tefX09PKvP7Bory0zajWqs7Sw8eho8fr
u9i4tNPKvP61vWhxcy1zcG1jQGNoaW5hdW5pY29tLmNuo6y8tL/J0tTNy7aptMvTyrz+oaPO
0sPHvavBory0vavE+rXE0MXPorTTztLDx7XEt6LLzcS/wrzW0Mm+s/2how0KSWYgeW91IGhh
dmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHVzIGltbWVk
aWF0ZWx5IGJ5IGUtbWFpbC4gUGxlYXNlIHJlcGx5IHRvIGhxcy1zcG1jQGNoaW5hdW5pY29t
LmNuIGlmIHlvdSB3YW50IHRvIHVuc3Vic2NyaWJlIGZyb20gdGhpcyBtYWlsLiBXZSB3aWxs
IGltbWVkaWF0ZWx5IHJlbW92ZSB5b3VyIGluZm9ybWF0aW9uIGZyb20gb3VyIHNlbmRpbmcg
Y2F0YWxvZ3VlLjwvcD4NCjwvQk9EWT48L0hUTUw+DQo=

--=====003_Dragon126160820723_=====--


From nobody Thu Sep 25 22:02:27 2014
Return-Path: 
X-Original-To: supa@ietfa.amsl.com
Delivered-To: supa@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 933581A19E6 for ; Thu, 25 Sep 2014 22:02:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.387
X-Spam-Level: 
X-Spam-Status: No, score=-4.387 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 QDAo3-1DWETg for ; Thu, 25 Sep 2014 22:02:22 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B439D1A19E2 for ; Thu, 25 Sep 2014 22:02:21 -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 BJY14927; Fri, 26 Sep 2014 05:02:12 +0000 (GMT)
Received: from LHREML516-MBX.china.huawei.com ([169.254.1.85]) by lhreml406-hub.china.huawei.com ([10.201.5.243]) with mapi id 14.03.0158.001; Fri, 26 Sep 2014 06:02:03 +0100
From: Georgios Karagiannis 
To: "chengying10@chinaunicom.cn" 
Thread-Topic: [Supa] Draft charter v1.12//RE:  Area hand-off, and some friendlyadvice ...
Thread-Index: AQHP2USk64of2dhsUk2KgKZ6M8w5j5wS2EDwgAAAXOA=
Date: Fri, 26 Sep 2014 05:02:02 +0000
Message-ID: 
References:  <201409261244369676994@chinaunicom.cn> 
In-Reply-To: 
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.87.176]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/supa/UsLgaAiQB7iTqOzX9k8e4nPelio
Cc: Benoit Claise , supa , Tina TSOU 
Subject: Re: [Supa] Draft charter v1.12//RE:  Area hand-off, and some friendlyadvice ...
X-BeenThere: supa@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Sep 2014 05:02:26 -0000

SGkgWWluZywNCg0KVGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzIQ0KDQpQbGVhc2Ugc2VlIGluIGxp
bmUuDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBHZW9yZ2lvcyBL
YXJhZ2lhbm5pcw0KPiBTZW50OiBGcmlkYXksIFNlcHRlbWJlciAyNiwgMjAxNCA1OjUyIEFNDQo+
IFRvOiBHZW9yZ2lvcyBLYXJhZ2lhbm5pcw0KPiBTdWJqZWN0OiBSRTogW1N1cGFdIERyYWZ0IGNo
YXJ0ZXIgdjEuMTIvL1JFOiBBcmVhIGhhbmQtb2ZmLCBhbmQgc29tZQ0KPiBmcmllbmRseWFkdmlj
ZSAuLi4NCj4gDQo+IEZyb206IFN1cGEgW21haWx0bzpzdXBhLWJvdW5jZXNAaWV0Zi5vcmddIE9u
IEJlaGFsZiBPZiBZaW5nIENoZW5nDQo+IFNlbnQ6IEZyaWRheSwgU2VwdGVtYmVyIDI2LCAyMDE0
IDU6NDUgQU0NCj4gVG86IHN1cGENCj4gQ2M6IEJlbm9pdCBDbGFpc2U7IFRpbmEgVFNPVQ0KPiBT
dWJqZWN0OiBSZTogW1N1cGFdIERyYWZ0IGNoYXJ0ZXIgdjEuMTIvL1JFOiBBcmVhIGhhbmQtb2Zm
LCBhbmQgc29tZQ0KPiBmcmllbmRseWFkdmljZSAuLi4NCj4gDQo+IEhpIGFsbCwNCj4gDQo+IEkg
YXR0ZW5kZWQgdGhlIGUtbWVldGluZyBsYXN0IG5pZ2h0IGFuZCBsZWFybmVkIGEgbG90LiBUaGFu
ayB5b3UgZm9yIHlvdXINCj4gZWZmb3J0cy4gVGhlIGxhdGVzdCBjaGFydGVyIGlzIG5vdyBjbGVh
cmVyIGFuZCBmaW5lIGZyb20gbXkgc2lkZS4gTGF0ZXIgSSBwbGFuDQo+IHRvIHVwZGF0ZSB0aGUg
RERDIHVzZSBjYXNlIGFjY29yZGluZ2x5Lg0KPiANCj4gU29tZSBxdWljayBjb21tZW50czoNCj4g
DQo+IFNvbWUgSUVURiB3b3JraW5nIGdyb3VwcyBoYXZlIHN0YXJ0ZWQgd29yayByZWxhdGluZyB0
byB0aGUgZGVzY3JpcHRpb24gb2YNCj4gdmFyaW91cyB0b3BvbG9naWVzIHN1Y2ggYXMgSTJSUyAo
TDMgYW5kIHJvdXRpbmcgdG9wb2xvZ2llcyksIEFMVE8gKGNvc3QgbWFwcyksDQo+IFNGQyAoc2Vy
dmljZSBjaGFpbiksIG5vbmUgb2YgdGhlc2UgZ3JvdXBzIGFpbSAoMSkgYXQgb2ZmZXJpbmcgdHJ1
bHkgZ2VuZXJpYw0KPiB0b3BvbG9neSBtb2RlbHMgZm9yIHRoZSBzdGFuZGFyZCBub3J0aGJvdW5k
IGludGVyZmFjZSwgYW5kICgyKSB0aGF0IGFuDQo+IGFwcGxpY2F0aW9uIGNhbiBjb21tdW5pY2F0
ZSB3aXRoIG5ldHdvcmsgYm94ZXMsIHN1Y2ggYXMgbmV0d29yayBjb250cm9sbGVycywNCj4gYW5k
IE5FcywgZGV2ZWxvcGVkIGJ5IGRpZmZlcmVudCB2ZW5kb3JzLg0KPiANCj4gSGVyZSBkbyB5b3Ug
bWVhbiB0aG9zZSB3b3JraW5nIGdyb3VwIGRpZG7igJl0IGRvIHlvdXIgKDIpLiBJZiBubywgSSBn
dWVzcyB5b3UNCj4gc2hvdWxkIHVzZSDigJxuZWl0aGVy4oCdIGluc3RlYWQuDQpbPl0gDQoNCkdl
b3JnaW9zOiBXZSBtZWFuIHRoYXQgdGhvc2Ugd29ya2luZyBncm91cHMgZGlkIG5vdCBkbyAoMSkg
YW5kICgyKS4NCkRvIHdlIG5lZWQgdG8gY2hhbmdlIHRoZSB3b3JkaW5nPw0KDQo+IA0KPiBJbiBh
ZGRpdGlvbiwgZ2l2ZW4gdGhhdCB0aGVyZSB3ZXJlIHNvbWUgZGlzY3Vzc2lvbnMgcmVsYXRlZCB0
byBlbmQgdXNlciBhcHANCj4gYW5kIG1hbmFnZW1lbnQgYXBwLiBZb3UgbWlnaHQgd2FudCB0byBz
cGVjaWZ5IHRoZSBhcHAgaW4gdGhpcyBzZW50ZW5jZSB0bw0KPiBlbGltaW5hdGUgY29uZnVzaW9u
Lg0KWz5dIA0KDQoNCkdlb3JnaW9zOiAiQXBwbGljYXRpb25zIiByZXByZXNlbnQgYW4gZW50aXR5
IHRoYXQgZ2VuZXJhdGVzIGFuZCBtYWludGFpbnMgbmV0d29yayBzZXJ2aWNlcyBhbmQgaXMgYWRt
aW5pc3RyYXRlZCBieSBhIGNvbW11bmljYXRpb24gc2VydmljZSBwcm92aWRlci4NCg0KPiANCj4g
T25lIG1vcmUgY29tbWVudCwgSSBzYXcgeW91IGFkZCB0aGUgdGVybSDigJ1pbnRlcm9wZXJhYmxl
IG1hbm5lcuKAnSBpbiBzZXZlcmFsDQo+IHBsYWNlcy4gQ291bGQgeW91IHBsZWFzZSBlbGFib3Jh
dGU/DQpbPl0gDQoNCkdlb3JnaW9zOiB0aGUgaW50ZXJvcGVyYWJsZSBtYW5uZXIgcmVsYXRlcyB0
bzogcmVxdWlyZW1lbnQgdGhhdCBhcHBsaWNhdGlvbnMgc2hvdWxkIGJlIGFibGUgdG8gY29tbXVu
aWNhdGUgd2l0aCBuZXR3b3JrIGJveGVzLCBzdWNoIGFzIG5ldHdvcmsgY29udHJvbGxlcnMsIGFu
ZCBORXMsIGRldmVsb3BlZCBieSBkaWZmZXJlbnQgdmVuZG9ycy4NCg0KQmVzdCByZWdhcmRzLA0K
R2Vvcmdpb3MNCg0KPiANCj4gQlIsDQo+IFlpbmcNCj4gDQo+IDIwMTQtMDktMjYNCj4gX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBZaW5nIENIRU5HwqAg56iL6I65
DQo+IENoaW5hIFVuaWNvbSBOZXR3b3JrIFRlY2hub2xvZ3kgUmVzZWFyY2ggSW5zdGl0dXRlIOS4
reWbveiBlOmAmue9kee7nOaKgOacr+eglOeptumZog0KPiBUZWw6ICs4Ni0xMC02ODc5OTk5OS03
NzAyDQo+IE1vYmlsZTogKzg2LTE4NjAxMTAyOTcxDQo+IF9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18NCj4g5Y+R5Lu25Lq677yaIFRpbmEgVFNPVQ0KPiDlj5HpgIHml7bp
l7TvvJogMjAxNC0wOS0yNsKgIDA4OjUzOjQ3DQo+IOaUtuS7tuS6uu+8miBCZW5vaXQgQ2xhaXNl
DQo+IOaKhOmAge+8miBzdXBhQGlldGYub3JnDQo+IOS4u+mimO+8miBbU3VwYV0gRHJhZnQgY2hh
cnRlciB2MS4xMi8vUkU6IEFyZWEgaGFuZC1vZmYsIGFuZCBzb21lDQo+IGZyaWVuZGx5YWR2aWNl
IC4uLg0KPiBEZWFyIEJlbm9pdCBldCBhbCwNCj4gDQo+IEhlcmUgY29tZXMgbGF0ZXN0IHZlcnNp
b24uIFRoZSBsaXN0IGRpc2N1c3Npb24gaGVscHMgYSBsb3QgdG8gbWFrZSBpdCBjbGVhcmVyLg0K
PiANCj4gPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0K
PiBTVVBBIChTaGFyZWQgVW5pZmllZCBQb2xpY3kgQXV0b21hdGlvbikgY2hhcnRlciB2MS4xMiBU
YXJnZXQgQXJlYTogT3BlcmF0aW9ucw0KPiBhbmQgTWFuYWdlbWVudA0KPiANCj4gRGVzY3JpcHRp
b24gb2YgV29ya2luZyBHcm91cDoNCj4gDQo+IFByb2dyYW1tYXRpYyB3YXlzIHRvIGNvbmZpZ3Vy
ZSBuZXR3b3Jrcywgb2Z0ZW4gY2FsbGVkIHNvZnR3YXJlLWRlZmluZWQsIGFyZQ0KPiBjb25zaWRl
cmVkIGJ5IG1hbnkgbmV0d29yayBvcGVyYXRvcnMgaW4gb3JkZXIgdG8gc2hpZnQgdGhlIGJhbGFu
Y2UgaW4gdGhlaXINCj4gZmF2b3IuDQo+IEF1dG9tYXRpbmcgdGhlIHdheSBvZiBleHBvc2luZyBh
IHZpZXcgb2YgdGhlIG5ldHdvcmsgdG8gYXBwbGljYXRpb25zIG1heQ0KPiBwcm92aWRlIHNpZ25p
ZmljYW50IGltcHJvdmVtZW50cyBpbiBjb25maWd1cmF0aW9uIGFnaWxpdHksIGVycm9yIGRldGVj
dGlvbiBhbmQNCj4gdXB0aW1lIGZvciBvcGVyYXRvcnMuIEhvd2V2ZXIgdGhlIHJlYWwgdmFsdWUg
YmVoaW5kIGNlbnRyYWwgY29uZmlndXJhdGlvbg0KPiBzY2hlbWVzIGxpZXMgd2l0aGluIHRoZSBw
b3NzaWJsZSBzaW1wbGlmaWNhdGlvbiB0aHJvdWdoIG1vZGVscyBwcm92aWRlZCBieQ0KPiBzdWNo
IHN5c3RlbXMgdG8gYXBwbGljYXRpb25zIGFuZCBuZXR3b3JrIHNlcnZpY2VzIHJ1bm5pbmcgYWJv
dmUgdGhlbSAob24gdGhlDQo+IHNvLWNhbGxlZCBub3J0aGJvdW5kIHNpZGUpLiBXZWxsLWRlc2ln
bmVkIG1vZGVscyBhcmUgYWJsZSB0byBwcm92aWRlIGEgd2lkZQ0KPiByYW5nZSBvZiBncmFudWxh
cml0eSBmb3IgdmFyaW91cyBhcHBsaWNhdGlvbnMgYW5kIG5ldHdvcmsgc2VydmljZXMgbmVlZHMs
IGZyb20NCj4gdGhlIGxvd2VyLWxldmVsIHBoeXNpY2FsIG5ldHdvcmsgdG8gaGlnaC1sZXZlbCBh
cHBsaWNhdGlvbiBzZXJ2aWNlcy4NCj4gU2V2ZXJhbCBvcmdhbml6YXRpb25zIG91dHNpZGUgb2Yg
dGhlIElFVEYgaGF2ZSBkZWZpbmVkIHZhcmlvdXMgc2NoZW1lcyBmb3IgdGhlDQo+IGNvbmZpZ3Vy
YXRpb24gb2YgbmV0d29yayBkZXZpY2VzIGFuZCBzcGVjaWZpYyBuZXR3b3JrIGNvbnRyb2xsZXJz
LCBidXQgbm9uZSBvZg0KPiB0aGVtIG9mZmVyIGEgdmVuZG9yLW5ldXRyYWwgc3RhbmRhcmRpemVk
IHdheSBmb3IgYXBwbGljYXRpb25zIGFuZCBuZXR3b3JrDQo+IHNlcnZpY2VzIHRvIHRyYW5zbWl0
IHRoZWlyIG5lZWRzIHRvIG5ldHdvcmsgY29udHJvbGxlcnMuIFRoZSBTVVBBIChTaGFyZWQNCj4g
VW5pZmllZCBQb2xpY3kgQXV0b21hdGlvbikgd29ya2luZyBncm91cCB3aWxsIHdvcmsgb24gdGhl
IGRlZmluaXRpb24gb2Ygc3VjaA0KPiBhcyBzdGFuZGFyZGl6ZWQgaW50ZXJmYWNlIGZvciBhcHBs
aWNhdGlvbnMgYW5kIG5ldHdvcmsgc2VydmljZXMgdG8gY29tbXVuaWNhdGUNCj4gd2l0aCBuZXR3
b3JrIGNvbnRyb2xsZXJzIG9mIGFsbCB0eXBlcy4gSW4gcGFydGljdWxhciwgU1VQQSB3aWxsIGZv
Y3VzIG9uDQo+IHNlcnZpY2Ugc3BlY2lmaWMgbW9kZWxzIHRoYXQgYWxsb3cgYXBwbGljYXRpb25z
IHRvIHJlcXVlc3QgY2VydGFpbiBuZXR3b3JrDQo+IHNlcnZpY2VzIHRvIGJlIGNyZWF0ZWQvZGVs
ZXRlZC9tb2RpZmllZC4gQSBuZXR3b3JrIHNlcnZpY2UgY2FuIGZvciBleGFtcGxlIGJlDQo+IGEg
dmlydHVhbCBsaW5rIGJldHdlZW4gdHdvIGVuZHBvaW50cyB0aGF0IHVzZXMgY2VydGFpbiBwcm9w
ZXJ0aWVzLCB0cmFmZmljDQo+IGVuZ2luZWVyaW5nLCBpbXBsZW1lbnRhdGlvbiBvZiBJUHY2IHRy
YW5zaXRpb24gbWVjaGFuaXNtIGFuZCB0aGVpciBlbmZvcmNlbWVudA0KPiB0byB1c2Vycy4NCj4g
RWFjaCBuZXR3b3JrIHNlcnZpY2UgY2FuIGJlIHJlcHJlc2VudGVkIGJ5IGEgc2VydmljZSBiYXNl
ZCBQT0xJQ1kgbW9kZWwgdGhhdA0KPiBjYW4gbW9kZWwgYSBncm91cCBvZiBkZW1hbmRzIChpLmUu
LCBhY3Rpb25zIGFuZCBjb25zdHJhaW50cykgdGhhdCBhcmUgYmVpbmcNCj4gaW5pdGlhdGVkIGJ5
IGFwcGxpY2F0aW9ucyB0aGF0IGltcG9zZSBzaW1pbGFyIHJlcXVpcmVtZW50cyBvbiB0aGUNCj4g
Y29tbXVuaWNhdGlvbiBuZXR3b3JrLiBUaGUgdGVybXMgIlVOSUZJRUQiIGFuZCAiU0hBUkVEIiB1
c2VkIGluIHRoZSBTVVBBDQo+IGFiYnJldmlhdGlvbiwgcmVsYXRlIHRvIHRoZSB3YXkgb2YgaG93
IHRoZSBzZXJ2aWNlIHBvbGljeSBtb2RlbCBpcyBnZW5lcmF0ZWQsDQo+IHNpbmNlIGl0IGdyb3Vw
cywgdW5pZmllcyBhbmQgc2hhcmVzIHRoZSBzaW1pbGFyIHJlcXVpcmVtZW50cyBpbXBvc2VkIGJ5
IGEgYnVsaw0KPiBvZiBhcHBsaWNhdGlvbnMuIFNVUEEgd2lsbCBwcm92aWRlIGd1aWRlbGluZXMg
Zm9yIG1lY2hhbmlzbXMgdGhhdCBjYW4NCj4gZHluYW1pY2FsbHkgYW5kIG9uIGFuIGludGVyb3Bl
cmFibGUgbWFubmVyLCBBVVRPTUFUSUNBTExZIG1hcCBzZXJ2aWNlcyBhbmQNCj4gcG9saWNpZXMg
ZGVmaW5lZCBvbiBhbiBhYnN0cmFjdCB0b3BvbG9neSBncmFwaCBkb3duIHRvIG1vcmUgZGV0YWls
ZWQgbmV0d29yaw0KPiBncmFwaHMgYW5kIHNwZWNpZmljIG5ldHdvcmsgbWFuYWdlbWVudCBhbmQg
Y29udHJvbGxpbmcgcG9saWNpZXMuDQo+IFNvbWUgSUVURiB3b3JraW5nIGdyb3VwcyBoYXZlIHN0
YXJ0ZWQgd29yayByZWxhdGluZyB0byB0aGUgZGVzY3JpcHRpb24gb2YNCj4gdmFyaW91cyB0b3Bv
bG9naWVzIHN1Y2ggYXMgSTJSUyAoTDMgYW5kIHJvdXRpbmcgdG9wb2xvZ2llcyksIEFMVE8gKGNv
c3QgbWFwcyksDQo+IFNGQyAoc2VydmljZSBjaGFpbiksIG5vbmUgb2YgdGhlc2UgZ3JvdXBzIGFp
bSAoMSkgYXQgb2ZmZXJpbmcgdHJ1bHkgZ2VuZXJpYw0KPiB0b3BvbG9neSBtb2RlbHMgZm9yIHRo
ZSBzdGFuZGFyZCBub3J0aGJvdW5kIGludGVyZmFjZSwgYW5kICgyKSB0aGF0IGFuDQo+IGFwcGxp
Y2F0aW9uIGNhbiBjb21tdW5pY2F0ZSB3aXRoIG5ldHdvcmsgYm94ZXMsIHN1Y2ggYXMgbmV0d29y
ayBjb250cm9sbGVycywNCj4gYW5kIE5FcywgZGV2ZWxvcGVkIGJ5IGRpZmZlcmVudCB2ZW5kb3Jz
Lg0KPiBTVVBBIHdpbGwgd29yayBvbiBkZWZpbmluZyB2ZW5kb3ItbmV1dHJhbCBzdGFuZGFyZGl6
ZWQgaW50ZXJmYWNlcyBiYXNlZCBvbiB0aGUNCj4gY29uY2VwdCBvZiBuZXR3b3JrIGdyYXBoLCBh
biBlbnRpdHkgZGVzY3JpYmluZyBhbiBhcmJpdHJhcnkgdG9wb2xvZ3kgb2Ygbm9kZXMNCj4gYW5k
IGxpbmtzIGF0IGFueSBsZXZlbCBvZiBncmFudWxhcml0eS4gU3VjaCBhIG5ldHdvcmsgZ3JhcGgg
ZGVzY3JpYmVzICgxKQ0KPiB0b3BvbG9naWVzIGF0IGRpZmZlcmVudCBsZXZlbHMgb2YgYWJzdHJh
Y3Rpb24sICgyKSB0aGUgcmVsYXRpb25zaGlwcyBiZXR3ZWVuDQo+IHRoZSBhYnN0cmFjdGlvbiBs
ZXZlbHMgYW5kICgzKSBhcHBsaWVkIHNlcnZpY2UgYmFzZWQgcG9saWN5LCB3aGljaCBhcmUgYWN0
aW9ucw0KPiBhbmQgY29uc3RyYWludHMgYXBwbGllZCBvbiB0aGVzZSB0b3BvbG9naWVzLiBTVVBB
IG1heSBhbHNvIGRlZmluZSBhbnkgbWFwcGluZ3MNCj4gdG8gYW55IG90aGVyIG5ldHdvcmsgdG9w
b2xvZ3kgZGF0YSBtb2RlbHMgZGVmaW5lZCB3aXRoaW4gdGhlIElFVEYuDQo+IFRoZSBtYWluIGdv
YWwgb2YgU1VQQSBpcyB0byBwcm92aWRlIHNlcnZpY2Ugc3BlY2lmaWMgbW9kZWxzIHRoYXQgYWxs
b3cNCj4gYXBwbGljYXRpb25zIHRvIHJlcXVlc3QgbmV0d29yayBzZXJ2aWNlcyB0byBiZSBjcmVh
dGVkL2RlbGV0ZWQvbW9kaWZpZWQuIFRoaXMNCj4gY2FuIGJlIHJlYWxpemVkIGJ5Og0KPiDCoCBv
KSBtb2RlbCBtdWx0aXBsZSB0b3BvbG9naWVzIGF0IGRpZmZlcmVudCBsZXZlbHMgb2YgYWJzdHJh
Y3Rpb24gdXNpbmcgYQ0KPiBuZXR3b3JrIGdyYXBoLA0KPiDCoMKgbykgbW9kZWwgdGhlIHJlbGF0
aW9uc2hpcHMgYmV0d2VlbiB0aGUgYWJzdHJhY3Rpb24gbGV2ZWxzLg0KPiDCoCBvKSB0cmFuc3Bv
cnRpbmcgbW9kZWwgaW5zdGFuY2VzIHVzaW5nIGVpdGhlciBORVRDT05GIG9yIFJFU1RDT05GDQo+
IA0KPiBTVVBBIHdpbGwgZW5zdXJlIHRoYXQgaW4gY2FzZSBhbnkgc3BlY2lmaWMgTkVUQ09ORi9S
RVNUQ09ORiBwcm90b2NvbA0KPiByZXF1aXJlbWVudHMgYXJlIGlkZW50aWZpZWQsIHRoZXkgd2ls
bCBiZSBjb21tdW5pY2F0ZWQgaW4gYSB0aW1lbHkgbWFubmVyIHRvDQo+IHRoZSBORVRDT05GIHdv
cmtpbmcgZ3JvdXAuIFNVUEEgd2lsbCBjb25zdWx0IHdpdGggdGhlIFlBTkcgZG9jdG9ycyB0byBl
bnN1cmUNCj4gdGhhdCBkYXRhIG1vZGVscyBmb2xsb3cgY29tbW9uIHByYWN0aWNlcy4NCj4gDQo+
IFdvcmsgaXRlbXMgZm9yIFNVUEEgaW5jbHVkZToNCj4gPT09PT09PT09PT09PT09PT09PT09PT09
PT09PQ0KPiAxKSBUaGUgZGVmaW5pdGlvbiBvZiBhIHN0YW5kYXJkaXplZCBtb2RlbCBmb3IgYSBu
ZXR3b3JrIGdyYXBoLCB1c2luZyBZQU5HLg0KPiBUaGlzIG1vZGVsIG1heSBiZSB1c2VkIHRvIGRl
c2NyaWJlIHRvcG9sb2dpZXMgYXQgYW55IGZ1bmN0aW9uYWwgbGF5ZXIsIGZyb20NCj4gcGh5c2lj
YWwgbmV0d29ya3MgdG8gbmV0d29yayBzZXJ2aWNlcy4NCj4gMikgVGhlIGRlZmluaXRpb24gYW5k
IHN0YW5kYXJkaXphdGlvbiBvZiBhIG51bWJlciBvZiBiYXNpYyBwb2xpY3kgYW5kIGRhdGENCj4g
bW9kZWxzIHVzaW5nIG5ldHdvcmsgZ3JhcGhzLiBUaGVzZSBtaWdodCBpbmNsdWRlLCBidXQgYXJl
IG5vdCBsaW1pdGVkIHRvDQo+IEwzVlBOcywgdHJhZmZpYyBlbmdpbmVlcmluZywgaW1wbGVtZW50
YXRpb24gb2YgSVB2NiB0cmFuc2l0aW9uIG1lY2hhbmlzbSBhbmQNCj4gdGhlaXIgZW5mb3JjZW1l
bnQgdG8gdXNlcnMuDQo+IDMpIFByb3ZpZGUgZ3VpZGVsaW5lcyBmb3IgbWVjaGFuaXNtcyB0aGF0
IGNhbiBkeW5hbWljYWxseSBhbmQgb24gYW4NCj4gaW50ZXJvcGVyYWJsZSBtYW5uZXIsIGF1dG9t
YXRpY2FsbHkgbWFwIHNlcnZpY2VzIGFuZCBwb2xpY2llcyBkZWZpbmVkIG9uIGFuDQo+IGFic3Ry
YWN0IHRvcG9sb2d5IGdyYXBoIGRvd24gdG8gbW9yZSBkZXRhaWxlZCBuZXR3b3JrIGdyYXBocyBh
bmQgc3BlY2lmaWMNCj4gbmV0d29yayBtYW5hZ2VtZW50IGFuZCBjb250cm9sbGluZyBwb2xpY2ll
cy4NCj4gNCkgR3VpZGVsaW5lcyBvbiBob3cgdG8gdXNlIE5FVENPTkYgKG9yIFJFU1RDT05GKSBh
dXRoZW50aWNhdGlvbiBhbmQNCj4gYXV0aG9yaXphdGlvbiBtZWNoYW5pc21zIHRvIGFjaGlldmUg
cHJvdGVjdGlvbiBhbmQgaXNvbGF0aW9uDQo+IA0KPiBEZWxpdmVyYWJsZXM6DQo+ID09PT09PT09
PT09PT0NCj4gbykgUHJvZHVjZSBhbiBpbmZvcm1hdGlvbmFsIFJGQyAiUHJvYmxlbSBTdGF0ZW1l
bnQgYW5kIFVzZSBDYXNlcyIuDQo+IG8pIFByb2R1Y2UgYSBzdGFuZGFyZHMtdHJhY2sgUkZDIHRo
YXQgc3BlY2lmaWVzIFlBTkcgbW9kZWxzIGZvciBhIGdlbmVyaWMNCj4gbXVsdGktbGF5ZXIgbmV0
d29yayBncmFwaC4NCj4gbykgUHJvZHVjZSBzdGFuZGFyZHMtdHJhY2sgUkZDcyB0aGF0IHNwZWNp
ZnkgZXh0ZW5zaW9ucyBmb3IgdGhlIGdlbmVyaWMgWUFORw0KPiBtb2RlbHMgZGVmaW5lZCBhYm92
ZSBmb3IgbmV0d29yayBzZXJ2aWNlcyB0aGF0IG1hbmFnZSB2aXJ0dWFsIGxpbmtzLCB0cmFmZmlj
DQo+IGVuZ2luZWVyaW5nIGFuZCBpbXBsZW1lbnRhdGlvbiBvZiBJUHY2IHRyYW5zaXRpb24gbWVj
aGFuaXNtIGFuZCB0aGVpcg0KPiBlbmZvcmNlbWVudCB0byB1c2Vycy4NCj4gbykgUHJvZHVjZSBh
biBpbmZvcm1hdGlvbmFsIFJGQyB0aGF0IHByb3ZpZGVzIHRoZSBndWlkZWxpbmVzIGZvciBtZWNo
YW5pc21zDQo+IHRoYXQgY2FuIGR5bmFtaWNhbGx5IGFuZCBvbiBpbnRlcm9wZXJhYmxlIG1hbm5l
ciwgYXV0b21hdGljYWxseSBtYXAgc2VydmljZXMNCj4gYW5kIHBvbGljaWVzIGRlZmluZWQgb24g
YW4gYWJzdHJhY3QgdG9wb2xvZ3kgZ3JhcGggZG93biB0byBtb3JlIGRldGFpbGVkDQo+IG5ldHdv
cmsgZ3JhcGhzIGFuZCBzcGVjaWZpYyBuZXR3b3JrIG1hbmFnZW1lbnQgYW5kIGNvbnRyb2xsaW5n
IHBvbGljaWVzLg0KPiBvKSBQcm9kdWNlIGFuIGluZm9ybWF0aW9uYWwgUkZDIHRoYXQgcHJvdmlk
ZXMgdGhlIGd1aWRlbGluZXMgb24gdXNpbmcgTkVUQ09ORg0KPiAob3IgUkVTVENPTkYpIGF1dGhl
bnRpY2F0aW9uIGFuZCBhdXRob3JpemF0aW9uIG1lY2hhbmlzbXMgdG8gYWNoaWV2ZSBzZWN1cml0
eQ0KPiBwcm90ZWN0aW9uIGFuZCBpc29sYXRpb24nIGFzIGFuIEluZm9ybWF0aW9uYWwgUkZDLg0K
PiANCj4gTWlsZXN0b25lczoNCj4gPT09PT09PT09PT0NCj4gRGVjIDIwMTTCoCBJbml0aWFsICJQ
cm9ibGVtIFN0YXRlbWVudCBhbmQgVXNlIENhc2VzIiBXRyBJLUQgRmViIDIwMTXCoCBJbml0aWFs
DQo+ICJNdWx0aS1sYXllciBOZXR3b3JrIEdyYXBoIFlBTkcgTW9kZWwiIFdHIEktRCBBcHIgMjAx
NcKgIEluaXRpYWwgc2VydmljZQ0KPiBzcGVjaWZpYyBkYXRhIG1vZGVsIFdHIEktRHMgTWF5IDIw
MTXCoCBJbml0aWFsICJNYXBwaW5nIEd1aWRlbGluZXMiIFdHIEktRCBKdW4NCj4gMjAxNcKgIFN1
Ym1pdCAiUHJvYmxlbSBTdGF0ZW1lbnQgYW5kIFVzZSBDYXNlcyIgSS1EIHRvIElFU0cgSnVsIDIw
MTXCoCBJbml0aWFsDQo+ICJBdXRoZW50aWNhdGlvbiBhbmQgQXV0aG9yaXphdGlvbiIgV0cgSS1E
IFNlcCAyMDE1wqAgU3VibWl0ICJNdWx0aS1sYXllcg0KPiBOZXR3b3JrIEdyYXBoIFlBTkcgTW9k
ZWwiIEktRCB0byBJRVNHIE5vdiAyMDE1wqAgU3VibWl0IHNlcnZpY2Ugc3BlY2lmaWMgZGF0YQ0K
PiBtb2RlbCBJLURzIHRvIElFU0cgRmViIDIwMTbCoCBTdWJtaXQgIk1hcHBpbmcgR3VpZGVsaW5l
cyIgSS1EIHRvIElFU0cgQXByDQo+IDIwMTbCoCBTdWJtaXQgIkF1dGhlbnRpY2F0aW9uIGFuZCBB
dXRob3JpemF0aW9uIiBJLUQgdG8gSUVTRw0KPiANCj4gDQo+IFRoYW5rIHlvdSwNCj4gVGluYQ0K
PiANCj4gRnJvbTogU3VwYSBbbWFpbHRvOnN1cGEtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm
IE9mIExpdXNodWNoZW5nIChXaWxsKQ0KPiBTZW50OiBUaHVyc2RheSwgU2VwdGVtYmVyIDI1LCAy
MDE0IDc6MzYgUE0NCj4gVG86IEJlbm9pdCBDbGFpc2UNCj4gQ2M6IHN1cGFAaWV0Zi5vcmcNCj4g
U3ViamVjdDogUmU6IFtTdXBhXSBBcmVhIGhhbmQtb2ZmLCBhbmQgc29tZSBmcmllbmRseSBhZHZp
Y2UgLi4uDQo+IA0KPiBIaSBCZW5vaXQsDQo+IA0KPiBCZWxvdyBpbmxpbmUgcGxlYXNlIHNlZSB0
d28gcGllY2VzIG9mIGNvbXBsZW1lbnRhcnkgYW5zd2VyIGZyb20gbXkgdGVhbQ0KPiAoc3RhcnRz
IHdpdGggW1dpbGxdKS4gVGhhbmsgeW91IQ0KPiANCj4gUmVnYXJkcywNCj4gV2lsbA0KPiANCj4g
RnJvbTogU3VwYSBbbWFpbHRvOnN1cGEtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEdl
b3JnaW9zIEthcmFnaWFubmlzDQo+IFNlbnQ6IFdlZG5lc2RheSwgU2VwdGVtYmVyIDI0LCAyMDE0
IDc6MzAgUE0NCj4gVG86IEJlbm9pdCBDbGFpc2U7IFRpbmEgVFNPVTsgSnVlcmdlbiBTY2hvZW53
YWVsZGVyDQo+IENjOiBaaGVuIENhbzsgc3VwYUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW1N1
cGFdIEFyZWEgaGFuZC1vZmYsIGFuZCBzb21lIGZyaWVuZGx5IGFkdmljZSAuLi4NCj4gDQo+IEhp
IEJlbm9pdCwNCj4gDQo+IFRoYW5rIHlvdSBmb3IgeW91ciBjb21tZW50cy4NCj4gUGxlYXNlIHNl
ZSBpbiBsaW5lLA0KPiANCj4gRnJvbTogU3VwYSBbbWFpbHRvOnN1cGEtYm91bmNlc0BpZXRmLm9y
Z10gT24gQmVoYWxmIE9mIEJlbm9pdCBDbGFpc2UNCj4gU2VudDogV2VkbmVzZGF5LCBTZXB0ZW1i
ZXIgMjQsIDIwMTQgMTA6NDEgQU0NCj4gVG86IEdlb3JnaW9zIEthcmFnaWFubmlzOyBUaW5hIFRT
T1U7IEp1ZXJnZW4gU2Nob2Vud2FlbGRlcg0KPiBDYzogWmhlbiBDYW87IHN1cGFAaWV0Zi5vcmcN
Cj4gU3ViamVjdDogUmU6IFtTdXBhXSBBcmVhIGhhbmQtb2ZmLCBhbmQgc29tZSBmcmllbmRseSBh
ZHZpY2UgLi4uDQo+IA0KPiBIaSBHZW9yZ2lvcywNCj4gSGkgQmVub2l0LA0KPiANCj4gVGhhbmtz
IGZvciB5b3VyIGNvbW1lbnRzIQ0KPiBQbGVhc2Ugc2VlIGluIGxpbmUuDQo+IA0KPiANCj4gR2Vv
cmdpb3M6IFBsZWFzZSBub3RlIHRoYXQgd2UgYXJlIHJlZmVycmluZyB0byB0aGUgZm9sbG93aW5n
IGZpZ3VyZToNCj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIC0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoHwgYXBwbGlj
YXRpb25zwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8DQo+
IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0NCj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAg
fMKgIDwtLS1lbmQgdXNlLiBBcHBsLsKgwqAgfA0KPiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAg
LS0tLS0tLS0tLS0tLS0tLS0tLS0twqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHw8LS0tZW5kIHVz
ZS4gQXBwbC4NCj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqB8IGVuaGFuY2VkIE9TU8KgwqDC
oMKgwqAgfMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8DQo+IMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoCAtLS0tLS0tLS0tLS0tLS0tLS0tLS3CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfA0KPiDC
oMKgwqAgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgfMKgwqAgPC0tLSBuZXR3
b3JrIHNlcnZpY2UgfCBZQU5HIG1vZGVsc8KgIC9ORVRDT05GDQo+IGludGVyZmFjZcKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8DQo+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAtLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqAgfMKgwqAgY29udHJvbGxlcsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgIHzCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDwtLS0NCj4gwqAgbWFwcGlu
ZyBuZXR3b3JrIHNlcnZpY2VzIHRvIHRvcG9sb2d5DQo+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oCAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoCB8wqDCoMKgwqDCoMKgIHzCoMKgwqDCoMKgwqDCoCB8wqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgPC0tLSBkZXZpY2UvZmVhdHVyZQ0KPiBz
cGVjaWZpYyBZQU5HIG1vZGVscyAvIE5FVENPTkYgaW50ZXJmYWNlDQo+IMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoCBORTHCoMKgwqAgTkUywqDCoCBORW4NCj4gSXQncyBub3Qgb2J2aW91cyB3aGF0
IGFuICJlbmhhbmNlZCBPU1MiIGlzPw0KPiANCj4gR2Vvcmdpb3M6IGl0IHJlbGF0ZXMgdG8gdGhl
IHN5c3RlbSB0aGF0IHJ1bnMgbmV0d29yayBzZXJ2aWNlcy4gVGhlc2Ugc2VydmljZXMNCj4gYXJl
IGVuaGFuY2VkIE9wZXJhdGlvbmFsIFN1cHBvcnQgU3lzdGVtIChPU1MpIGxpa2Ugc2VydmljZXMg
dGhhdCBoZWxwIGENCj4gY29tbXVuaWNhdGlvbiBzZXJ2aWNlIHByb3ZpZGVyIHRvIG1vbml0b3Is
IGNvbnRyb2wsIGFuYWx5emUgYW5kIG1hbmFnZSBhDQo+IGNvbW11bmljYXRpb24gbmV0d29yay4N
Cj4gDQo+IEdlb3JnaW9zOiBBY2NvcmRpbmcgdG8gdGhlIHByb3ZpZGVkIGZpZ3VyZTogMSkgbmVl
ZCB0byB3b3JrIG9uIG5ldHdvcmsgc2VydmljZQ0KPiBZYW5nIG1vZGVscywgMiBtYXBwaW5nIG5l
dHdvcmsgc2VydmljZXMgdG8gdG9wb2xvZ3ksIDMuIERldmljZS9mZWF0dXJlDQo+IHNwZWNpZmlj
IFlhbmcgTW9kZWxzLCA0KSBlbmQgdXNlciBzcGVjaWZpYyBZYW5rIE1vZGVscyAob3V0IG9mIHNj
b3BlKS4gVGhlDQo+IGludGVyZmFjZSBiZXR3ZWVuIGVuZCB1c2VyIGFwcGxpY2F0aW9ucyBhbmQg
YSBjb250cm9sbGVyLCBhbmQgaW50ZXJmYWNlDQo+IGJldHdlZW4gZW5kIHVzZXIgYXBwbGljYXRp
b24gYW5kIGVuaGFuY2VkIE9TUywgYXJlIGFsc28gb3V0IG9mIHNjb3BlLg0KPiBDb25jZXJuaW5n
IHlvdXIgbGFzdCBzZW50ZW5jZS4gSSdtIGNvbmZ1c2VkLg0KPiBXaGF0IGRvZXMgdGhlIGZvbGxv
d2luZyBkZWxpdmVyYWJsZSBtZWFuIHRoZW4/DQo+IG8pIHNwZWNpZnkgYW5kIHN0YW5kYXJkaXpl
IGhvdyBORVRDT05GL1lBTkcgKG9yIFJFU1RDT05GL1lBTkcpIGNhbiBiZSB1c2VkIHRvDQo+IHNl
Y3VyZWx5IGFuZCBlZmZpY2llbnRseSBkaXN0cmlidXRlIHVwIHRvIGRhdGUgKGZyZXNoKSBuZXR3
b3JrIGdyYXBocyBiZXR3ZWVuDQo+IG5ldHdvcmsgc2VydmljZSBzeXN0ZW1zIGFuZCBuZXR3b3Jr
IG1hbmFnZW1lbnQgYW5kIGNvbnRyb2xsaW5nIHN5c3RlbXMNCj4gDQo+IEl0IHJlbGF0ZXMgdG8g
dGhlIGludGVyZmFjZSBiZXR3ZWVuIHRoZSBuZXR3b3JrIHNlcnZpY2Ugc3lzdGVtIChlbmhhbmNl
ZCBPU1MNCj4gaW4gdGhlIGFib3ZlIGZpZ3VyZS4NCj4gUGxlYXNlIG5vdGUgdGhhdCB3ZSBzYXkg
dGhhdCB3ZSBpbml0aWFsbHkgb25seSBmb2N1cyBvbiB0aGlzIGludGVyZmFjZSwgaW4NCj4gb3Jk
ZXIgdG8gbmFycm93IGRvd24gdGhlIHNjb3BlIG9mIHRoaXMgYWN0aXZpdHkNCj4gDQo+IEhvd2V2
ZXIsIGlmIHRoZXJlIGFyZSBzdXBwb3J0cyB0aGF0IHRoaW5rIHdlIHNob3VsZCBpbml0aWFsbHkg
Zm9jdXMgYWxzbyBvbg0KPiB0aGUgaW50ZXJmYWNlIGJldHdlZW4gZW5kIHVzZXIgYXBwbGljYXRp
b24gYW5kIGNvbnRyb2xsZXIgd2Ugd2lsbCBhbHNvIGluY2x1ZGUNCj4gdGhpcyBpbnRlcmZhY2Ug
aW4gdGhlIHNjb3BlLg0KPiANCj4gW1dpbGxdOiBGaXJzdCBvZiBhbGwsIElNT0gsIHRoZSBmaWd1
cmVzIGZyb20gQmVub2l0IGFuZCBHZW9yZ2lvcyBhcmUgbm90DQo+IGluY29tcGF0aWJsZS4gRnJv
bSB0aGUgcGVyc3BlY3RpdmUgb2YgY29udHJvbGxlciwgdGhleSBhcmUgZGlmZmVyZW50IGxhdGl0
dWRlcw0KPiBvZiBub3J0aGJhbmQuIFRoZSBhcHBsaWNhdGlvbiBhbmQgZW5oYW5jZWQgT1NTIGlu
IEdlb3JnaW9zIGZpZ3VyZSBjYW4gYmUgcHV0DQo+IHRvZ2V0aGVyIGludG8gYW4gbGFyZ2VyIGFw
cGxpY2F0aW9uKiBsYXllciBvZiBCZW5vaXTigJlzIGZpZ3VyZS4gVGhlIG5ldHdvcmsNCj4gZ3Jh
cGggaXMgcHJvcG9zZWQgdG8gcHJvdmlkZSBuZXR3b3JrLXdpZGUgY29uZmlndXJhdGlvbiBjb250
YWluaW5nIHRoZSBrZXkNCj4gaW5mb3JtYXRpb24gZm9yIHNlcnZpY2UgaW5zdGFuY2VzLiBPbmUg
ZXhhbXBsZSBpcywgZm9yIHRoZSBEREMgdXNlIGNhc2UsIHRoZQ0KPiBuZXR3b3JrIGdyYXBoIGNv
bnRhaW5zIHRoZSBrZXkgaW5mb3JtYXRpb24gc3VjaCBhcyB0aGUga2V5IG5vZGUgaW5mb3JtYXRp
b24gb2YNCj4gdGhlIHBhdGggYW5kIHRoZSBrZXkgcmVxdWlyZW1lbnQgb2YgdHJhZmZpYyBzdGVl
cmluZy4NCj4gDQo+IFJlZ2FyZGluZyB0byB0aGUgYXBwLCBtYW5hZ2VtZW50IGFwcCwgZW5kIHVz
ZXIgYXBwIGhlcmUsIEkgd2FudCB0byBhZGQNCj4gc29tZXRoaW5nIHJlbGF0ZWQgdG8gdGhlIGhp
c3Rvcnkgb2YgdGhpcyB3b3JrLiBBdCB0aGUgdmVyeSBiZWdpbm5pbmcsIHdoZW4NCj4gdGhpcyB3
b3JrIGlzIGNhbGwgQVBPTkYgYmVmb3JlIFRvcm9udG8gSUVURiBtZWV0aW5nLCB0aGUgZW5kIHVz
ZXIgYXBwIGlzIGluDQo+IHRoZSBzY29wZS4gSG93ZXZlciwgdGhlcmUgYXJlIG1haW5seSB0aHJl
ZSByZWFzb25zIHRoYXQgd2UgcmVtb3ZlIHRoaXMgcG9pbnQ6DQo+IDEuwqDCoMKgwqDCoCBUaGUg
Y29uZmxpY3Rpb24gd2l0aCBBRUNPTiwgd2UgZGlzY3Vzc2VkIHdpdGggcHJvcG9uZW50cyBvZiBB
RUNPTiBhbmQNCj4gdG8gYXZvaWQgdGhlIGNvbmZsaWN0IGFzIGF0IHRoYXQgdGltZSB0aGV5IHdl
cmUgcHJvcG9zaW5nIHRoZSBpbnRlcmZhY2UgZnJvbQ0KPiBlbmQgdXNlciBhcHAgdG8gbmV0d29y
ayBkZXZpY2VzLiBMYXRlciBpbiB0aGUgSUVTRyBtZWV0aW5nIGluIFRvcm9udG8sIHdlDQo+IHN1
Y2Nlc3NmdWxseSBjbGFyaWZpZWQgdGhlIGRpZmZlcmVuY2VzIGFuZCBnb3QgdGhlIHN1Z2dlc3Rp
b24gdG8gZm9jdXMgb24NCj4gbWFuYWdlbWVudCBhcHAuDQo+IDIuwqDCoMKgwqDCoCBMYXJzIEVn
Z2VydCBzaG93ZWQgaGlzIGNvbmNlcm5pbmcgYWJvdXQgdGhlIGludGVyZmFjZSBiZXR3ZWVuIGVu
ZCB1c2VyDQo+IGFwcCBhbmQgbmV0d29yayBkZXZpY2VzIG1heSBsZWFkIHRvIHNlY3VyaXR5IGlz
c3VlLiDCoEtvc3RhcyBQZW50aWtvdXNpcyBhbHNvDQo+IG1lbnRpb25lZCB0aGlzIHRvIG1lLg0K
PiANCj4gSG93ZXZlciwgdGhlc2UgYXJlIG9sZCBzdG9yaWVzLiBEdXJpbmcgdGhlIFRvcm9udG8g
Qm9GLCBzb21lb25lIGFsc28gc3VnZ2VzdGVkDQo+IHVzIHJlLXB1dCB0aGUgZW5kIHVzZXIgYXBw
IGludG8gY29wZS4gQSBsYXJnZSBhcHAgbGF5ZXIgY29udGFpbmluZyBib3RoIGVuZA0KPiB1c2Vy
IGFwcCBhbmQgbWFuYWdlbWVudCBhcHAgbWF5IHJlcGxhY2UgdGhlIGZpcnN0IHR3byBsYXllcnMg
aW4gdGhlIG9sZCA0DQo+IGxheWVycyBmaWd1cmUuIEhlcmUsIG15IHF1ZXN0aW9uIGlzLCBhcmUg
eW91IGluIGZhdm9yIG9mIGFkZGluZyBlbmQgdXNlciBhcHANCj4gaW50byBTVVBBIHNjb3BlIG9y
IG5vdD8NCj4gDQo+IA0KPiBSZWdhcmRpbmcgeW91ciBjb21tZW50LCAiIEknbSBub3QgY29udmlu
Y2VkIHdlIGNvdWxkIHN0YW5kYXJkaXplIHRoZW0sIGFzIHRoZXkNCj4gYXJlIG9wZXJhdG9ycyBz
cGVjaWZpYywgYW5kIHdpbGwgYmUgZXZvbHZpbmcgYWxvbmcgdGhlIHRpbWUuIFRoZXJlIGFyZSBt
YW55DQo+IGRpZmZlcmVudCB3YXlzIHRvIGNvbmZpZ3VyZSBhIFZQTiwgZm9yIGV4YW1wbGUuIiBX
ZXJlIHlvdSByZWZlcnJpbmcgdG86DQo+IDMuIERldmljZS9mZWF0dXJlIHNwZWNpZmljIFlhbmcg
TW9kZWxzPw0KPiBObywgdGhlIHNlcnZpY2UgWUFORyBtb2RlbHMNCj4gDQo+IEdlb3JnaW9zOiBJ
IHNlZSwgYnV0IHdlIGNhbiB3b3JrIG9uIFlBTkcgbW9kZWxzIHRoYXQgY2FuIGJlIHVzZWQgZm9y
IGEgbnVtYmVyDQo+IG9mIG1haW4gbmV0d29yayBzZXJ2aWNlcywgd2hpY2ggYXJlIGVzc2VudGlh
bCBmb3Igb3BlcmF0b3JzIGFuZCB0aGF0IHRoZXkNCj4gd291bGQgbGlrZSB0byBoYXZlIHRoZW0g
c3RhbmRhcmRpemVkLg0KPiANCj4gDQo+IA0KPiBTZWUgaW4tbGluZQ0KPiBEZWFyIGFsbCwNCj4g
DQo+IEhvcGUgdGhpcyB2ZXJzaW9uIG9mIGRyYWZ0IGNoYXJ0ZXIgYWRkcmVzcyBtb3N0IG9mIHRo
ZSBjb21tZW50cyBmcm9tIHRoZSBsaXN0Lg0KPiANCj4gLS0tLS0tDQo+IA0KPiANCj4gDQo+IA0K
PiBJbiBwYXJ0aWN1bGFyLCBhcyBzdGFydGluZyBwb2ludCwgU1VQQSB3aWxsIG9ubHkgZm9jdXMg
b24gbmV0d29yayBzZXJ2aWNlcywNCj4gd2hpY2ggYXJlIGVuaGFuY2VkIE9wZXJhdGlvbmFsIFN1
cHBvcnQgU3lzdGVtIChPU1MpIGxpa2Ugc2VydmljZXMgdGhhdCBoZWxwIGENCj4gY29tbXVuaWNh
dGlvbiBzZXJ2aWNlIHByb3ZpZGVyIHRvIG1vbml0b3IsIGNvbnRyb2wsIGFuYWx5emUgYW5kIG1h
bmFnZSBhDQo+IGNvbW11bmljYXRpb24gbmV0d29yay4gVGhlIHN5c3RlbXMgdGhhdCBhcmUgcnVu
bml1bmcgc3VjaCBuZXR3b3JrIHNlcnZpY2VzIGFyZQ0KPiBkZW5vdGVkIGluIHRoaXMgZG9jdW1l
bnQgYXMgTmV0d29yayBTZXJ2aWNlIFN5c3RlbXMuDQo+IEVhY2ggbmV0d29yayBzZXJ2aWNlIGNh
biBiZSByZXByZXNlbnRlZCBieSBhIGNsYXNzaWZpZWQgYXBwbGljYXRpb24gYmFzZWQNCj4gUE9M
SUNZIG1vZGVsLCBzaW5jZSBpdCBjYW4gbW9kZWwgdGhlIGdyb3VwIG9mIGRlbWFuZHMgd2hpY2gg
YXJlIFNIQVJFRCBhbmQNCj4gVU5JRklFRCBhbmQgYXJlIGNvbWluZyBmcm9tIGEgYnVuZGxlIG9m
IGFwcGxpY2F0aW9ucyB0aGF0IGltcG9zZSBzaW1pbGFyDQo+IHJlcXVpcmVtZW50cyBvbiB0aGUg
Y29tbXVuaWNhdGlvbiBuZXR3b3JrLg0KPiBJJ20gYWZyYWlkIEkgZG9uJ3QgdW5kZXJzdGFuZCAo
bGlrZSBKw7xyZ2VuKQ0KPiANCj4gR2Vvcmdpb3M6IFdoYXQgd2Ugd2FudCB0byBzYXkgaXMgdGhh
dCB0aGVyZSBhcmUgYXBwbGljYXRpb25zIHRoYXQgaW1wb3NlDQo+IHNpbWlsYXIgcmVxdWlyZW1l
bnRzIG9uIHRoZSBjb21tdW5pY2F0aW9uIG5ldHdvcmsuIEZvciBlYWNoIGdyb3VwIG9mIHN1Y2gg
YnVsaw0KPiBvZiBhcHBsaWNhdGlvbnMgYSBuZXR3b3JrIHNlcnZpY2UgY2FuIGJlIGRlZmluZWQg
dGhhdCBjYW4gYmUgcmVwcmVzZW50ZWQgYnkgYQ0KPiBzZXJ2aWNlIHBvbGljeSBtb2RlbCAoaS5l
LiwgaXRzIGFjdGlvbnMgYW5kIGNvbnN0cmFpbnRzKS4NCj4gDQo+IA0KPiBHZW9yZ2lvczogVGhh
bmtzIGZvciB0aGUgc3VnZ2VzdGlvbiwgdGhlIHRleHQgbmVlZHMgdG8gYmUgcmVwaHJhc2VkLCBz
ZWUgYmVsb3c6DQo+IEVhY2ggbmV0d29yayBzZXJ2aWNlIGNhbiBiZSByZXByZXNlbnRlZCBieSBh
biBhcHBsaWNhdGlvbiBiYXNlZCBQT0xJQ1kgbW9kZWwsDQo+IHdoaWNoIGlzIFVOSUZJRUQgYW5k
IFNIQVJFRCwgc2luY2UgaXQgY2FuIG1vZGVsIHRoZSBncm91cCBvZiBkZW1hbmRzIChpLmUsDQo+
IGFjdGlvbnMgYW5kIGNvbnN0cmFpbnRzKSB0aGF0IGFyZSBjb21pbmcgZnJvbSBhIGJ1bmRsZSBv
ZiBhcHBsaWNhdGlvbnMgdGhhdA0KPiBpbXBvc2Ugc2ltaWxhciByZXF1aXJlbWVudHMgb24gdGhl
IGNvbW11bmljYXRpb24gbmV0d29yay4NCj4gSSBzdGlsbCBkb24ndCB1bmRlcnN0YW5kLiB3aGF0
ICJVTklGSUVEIGFuZCBTSEFSRUQiIG1lYW4uDQo+IA0KPiBHZW9yZ2lvczogdGhlIHRlcm1zIOKA
nFVOSUZJRUTigJ0gYW5kIOKAnFNIQVJFROKAneKAnSByZWxhdGUgdG8gdGhlIHdheSBvZiBob3cg
dGhlDQo+IHNlcnZpY2UgcG9saWN5IG1vZGVsIGlzIGdlbmVyYXRlZCwgc2luY2UgaXQgZ3JvdXBz
IGFuZCBpdCB1bmlmaWVzIGFuZCBzaGFyZXMNCj4gdGhlIHNpbWlsYXIgcmVxdWlyZW1lbnRzIGlt
cG9zZWQgYnkgYSBidWxrIG9mIGFwcGxpY2F0aW9ucy4NCj4gDQo+IA0KPiANCj4gDQo+IA0KPiAN
Cj4gDQo+ICgyKSB0cmFuc3BvcnRpbmcgbW9kZWwgaW5zdGFuY2VzIGVpdGhlciB1c2luZyBORVRD
T05GIG9yIFJFU1RDT05GIGFuZCAoMykNCj4gcHJvdmlkaW5nIGd1aWRlbGluZXMgb24gQVVUT01B
VElDQUxMWSBtYXBwaW5nIHBvbGljaWVzIHRvIGF0dHJpYnV0ZXMgb2YgdGhlDQo+IG5ldHdvcmsg
Z3JhcGhzLg0KPiANCj4gQWx0aG91Z2ggc29tZSBJRVRGIHdvcmtpbmcgZ3JvdXBzIGhhdmUgc3Rh
cnRlZCB3b3JrIHJlbGF0aW5nIHRvIHRoZQ0KPiBkZXNjcmlwdGlvbiBvZiB2YXJpb3VzIHRvcG9s
b2dpZXMgc3VjaCBhcyBJMlJTIChMM2FuZCByb3V0aW5nIHRvcG9sb2dpZXMpLA0KPiBBTFRPIChj
b3N0IG1hcHMpLCBTRkMgKHNlcnZpY2UgY2hhaW4pLCBub25lIG9mIHRoZXNlIGdyb3VwcyBhaW0g
YXQgb2ZmZXJpbmcNCj4gdHJ1bHkgZ2VuZXJpYyB0b3BvbG9neSBtb2RlbHMgZm9yIHRoZSBzdGFu
ZGFyZCBub3J0aGJvdW5kIGludGVyZmFjZS4NCj4gU1VQQSB3aWxsIHdvcmsgb24gZGVmaW5pbmcg
aW50ZXJmYWNlcyBiYXNlZCBvbiB0aGUgY29uY2VwdCBvZiBuZXR3b3JrIGdyYXBoLA0KPiBhbiBl
bnRpdHkgZGVzY3JpYmluZyBhbiBhcmJpdHJhcnkgdG9wb2xvZ3kgb2Ygbm9kZXMgYW5kIGxpbmtz
IGF0IGFueSBsZXZlbCBvZg0KPiBncmFudWxhcml0eS4gU3VjaCBhIGdyYXBoIG1heSBkZXNjcmli
ZSwgZm9yIGV4YW1wbGUsIGEgcGh5c2ljYWwgdG9wb2xvZ3ksIGENCj4gc2VydmljZSB0b3BvbG9n
eSBvciB0aGUgcmVsYXRpb25zaGlwcyBiZXR3ZWVuIGRhdGFjZW50ZXJzLiBBbnkgbmV0d29yaw0K
PiB0b3BvbG9neSBkYXRhIG1vZGVscyBvciBwb2xpY3kgbW9kZWxzIHRoYXQgaGF2ZSBiZWVuIGRl
ZmluZWQgKG9yIGFyZSBiZWluZw0KPiBkZWZpbmVkKSB3aXRoaW4gdGhlIElFVEYgd2lsbCBiZSBy
ZXVzZWQgaW4gU1VQQSBhcyBtdWNoIGFzIHBvc3NpYmxlLg0KPiBJbiBhZGRpdGlvbiB0byB0aGUg
YWJvdmUsIHBvbGljaWVzIG1heSBiZSBkZWZpbmVkIGFuZCBhcHBsaWVkIHRvIGEgbmV0d29yaw0K
PiBncmFwaC4gVGhlc2UgYXBwbGljYXRpb24gYmFzZWQgcG9saWNpZXMgYXJlIGFjdGlvbnMgb3Ig
Y29uc3RyYWludHMgZ2VuZXJhdGVkDQo+IGJ5IE5ldHdvcmsgU2VydmljZSBTeXN0ZW1zLiBUaGV5
IGFyZSB0aGVuIG1hcHBlZCBmcm9tIHRoZSBuZXR3b3JrIGdyYXBoDQo+IGluc3RhbmNlIGludG8g
c3BlY2lmaWMgbmV0d29yayBtYW5hZ2VtZW50IHBvbGljaWVzIHRvd2FyZCBuZXR3b3JrIGNvbXBv
bmVudHMuDQo+IA0KPiANCj4gR2Vvcmdpb3M6IHRoZSBhYm92ZSB0ZXh0IGlzIG5vdCBjbGVhci4g
VGhlcmVmb3JlLCBJIGFtIHJlcGhyYXNpbmcgaXQ6DQo+ID09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PQ0KPiBUaGUgbWFpbiBnb2FsIG9mIFNVUEEgaXMgdG8gcHJv
dmlkZSBhcHBsaWNhdGlvbiBiYXNlZCBwb2xpY2llcyBhbmQgbWVhbnMgdG8NCj4gbW9kZWwgYW5k
IHByb2dyYW0gdGhlIGFic3RyYWN0IHZpZXcgb2YgbmV0d29yayBpbmZyYXN0cnVjdHVyZSBhbmQg
c2VydmljZQ0KPiBmdW5jdGlvbiBpbnRlcmRlcGVuZGVuY2llcyBpbiBvcmRlciB0byBzdXBwb3J0
IGFuZCBBVVRPTUFUSUNBTExZIGZlZWQgbmV0d29yaw0KPiBtYW5hZ2VtZW50IGFuZCBjb250cm9s
bGluZyBwb2xpY2llcy4gVGhpcyBjYW4gYmUgcmVhbGl6ZWQgYnk6DQo+IA0KPiAoMSkgbW9kZWxp
bmcgdGhlIG5ldHdvcmsgZ3JhcGgsIHdoaWNoIGFtb25nIG90aGVycyBpbmNsdWRlIHBvbGljeSBt
b2RlbHMsIGRhdGENCj4gbW9kZWxzIGFuZCBhcHBsaWNhdGlvbiBiYXNlZCBwb2xpY2llcywgdXNp
bmcgWUFORywNCj4gDQo+ICgyKSBhcHBseWluZyBORVRDT05GIChvciBSRVNUQ09ORikgdG8gZW5h
YmxlIGRpc3NlbWluYXRpb24gb2YgdXAgdG8gZGF0ZQ0KPiAoZnJlc2gpIG5ldHdvcmsgZ3JhcGhz
IGluIGEgc2VjdXJlIGFuZCBlZmZpY2llbnQgbWFubmVyIGJldHdlZW4gbmV0d29yaw0KPiBzZXJ2
aWNlIHN5c3RlbXMgYW5kIG5ldHdvcmsgbWFuYWdlbWVudCBhbmQgY29udHJvbGxpbmcgc3lzdGVt
cywgImJldHdlZW4NCj4gbmV0d29yayBzZXJ2aWNlIHN5c3RlbXMgYW5kIG5ldHdvcmsgbWFuYWdl
bWVudCBhbmQgY29udHJvbGxpbmcgc3lzdGVtIi4gV2hhdA0KPiBhcmUgdGhvc2U/IEkgZG9uJ3Qg
c2VlIHRoZW0gaW4geW91ciBmaWd1cmUuDQo+IEFsc28sIHdoeSBzaG91bGQgYWxsIG9mIHRoZXNl
IG5lZWQgdG8ga25vdyBhYm91dCB0aGUgdG9wb2xvZ3k/DQo+IA0KPiBHZW9yZ2lvczogSW4gdGhl
IGZpZ3VyZSwgdGhlIGVuaGFuY2VkIE9TUyByZXByZXNlbnRzIHRoZSBuZXR3b3JrIHNlcnZpY2UN
Cj4gc3lzdGVtIGFuZCB0aGUgY29udHJvbGxlciByZXByZXNlbnRzIHRoZSBuZXR3b3JrIG1hbmFn
ZW1lbnQgYW5kIGNvbnRyb2xsaW5nDQo+IHN5c3RlbS4NCj4gSW4gdGhpcyBjb250ZXh0LCBuZXR3
b3JrIHNlcnZpY2VzIGNhbiBiZSB1c2VkIHRvIHByb3ZpZGUgdGhlDQo+IHJlcXVpcmVkIMKgY29u
ZmlndXJhdGlvbiBhbmQgYXBwbGljYXRpb24gcHJvZ3JhbW1pbmcgaW50ZXJmYWNlcyB0byBzZXJ2
aWNlDQo+IGRldmVsb3BlcnMuIFN1YnNlcXVlbnRseSwgYSBuZXR3b3JrIHNlcnZpY2UgY2FuIHVz
ZSB0aGUgYXBwbGljYXRpb24gYmFzZWQNCj4gZGVtYW5kcyAoZm9yIGFjdGlvbnMgYW5kIGNvbnN0
cmFpbnRzKSBhbmQgcG9zc2libHkgdXBkYXRlIGl0cyBhc3NvY2lhdGVkDQo+IG5ldHdvcmsgc2Vy
dmljZSDCoGF0dHJpYnV0ZXMuIEV4YW1wbGVzIG9mIG5ldHdvcmsgc2VydmljZXMgdGhhdCBjYW4g
bW9kaWZ5IMKgdGhlDQo+IG5ldHdvcmsgc2VydmljZSBhdHRyaWJ1dGVzIGFyZSBmb3IgZXhhbXBs
ZSwgTDNWUE4gY29uZmlndXJhdGlvbiBhbmQgSVB2Ng0KPiB0cmFuc2l0aW9ucy4NCj4gRm9yIGVh
Y2ggbmV0d29yayBzZXJ2aWNlIGluc3RhbmNlIGEgbmV0d29yayBncmFwaCBuZWVkcyB0byBiZSBn
ZW5lcmF0ZWQgYW5kDQo+IG1haW50YWluZWQuDQo+IFRoZSB1cCB0byBkYXRlIG5ldHdvcmsgZ3Jh
cGggbmVlZHMgdG8gKDEpIGJlIGNvbW11bmljYXRlZCBiZXR3ZWVuIHRoZcKgIG5ldHdvcmsNCj4g
c2VydmljZSBzeXN0ZW1zIGFuZCB0aGUgbmV0d29yayDCoMKgbWFuYWdlbWVudCBhbmQgY29udHJv
bGxpbmcgc3lzdGVtcywgKDIpIG1hcA0KPiB0aGUgYXR0cmlidXRlcyBvZiB0aGUgbmV0d29yayBz
ZXJ2aWNlIGdyYXBoIGludG8gc3BlY2lmaWMgbmV0d29yayBtYW5hZ2VtZW50DQo+IHBvbGljaWVz
Lg0KPiBbV2lsbF0gVG8gbW9kZWxpbmcgc2VydmljZSByZXF1aXJlbWVudCBhbmQgY3JlYXRlIHNl
cnZpY2UgaW5zdGFuY2VzLCBBUFAgbmVlZHMNCj4gYSB2aWV3IG9mIHRvcG9sb2d5IHRvIGZvcm0g
bmV0d29yayBjb25maWd1cmF0aW9uIGFjY29yZGluZyB0byB0aGUga2V5DQo+IGluZm9ybWF0aW9u
IG9mIGRldmljZXMgdG9wb2xvZ3kuIFRoaXMgY29uZmlndXJhdGlvbiBpcyBldmVudHVhbGx5IG1h
cHBlZCB0bw0KPiB0aGUgc2VsZWN0ZWQgbmV0d29yayBkZXZpY2VzIGFjY29yZGluZyB0byB0b3Bv
bG9neSBwcm92aWRlZCBieSBTVVBBLg0KPiANCj4gQmVzdCByZWdhcmRzLA0KPiBHZW9yZ2lvcw0K
PiANCj4gDQo+IA0KPiANCj4gDQo+IFJlZ2FyZHMsIEJlbm9pdA0KPiDlpoLmnpzmgqjplJnor6/m
jqXmlLbkuobor6Xpgq7ku7bvvIzor7fpgJrov4fnlLXlrZDpgq7ku7bnq4vljbPpgJrnn6XmiJHk
u6zjgILor7flm57lpI3pgq7ku7bliLBocXMtDQo+IHNwbWNAY2hpbmF1bmljb20uY27vvIzljbPl
j6/ku6XpgIDorqLmraTpgq7ku7bjgILmiJHku6zlsIbnq4vljbPlsIbmgqjnmoTkv6Hmga/ku47m
iJHku6znmoTlj5HpgIHnm67lvZXkuK3liKDpmaTjgIINCj4gSWYgeW91IGhhdmUgcmVjZWl2ZWQg
dGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHVzIGltbWVkaWF0ZWx5IGJ5IGUtDQo+
IG1haWwuIFBsZWFzZSByZXBseSB0byBocXMtc3BtY0BjaGluYXVuaWNvbS5jbiBpZiB5b3Ugd2Fu
dCB0byB1bnN1YnNjcmliZSBmcm9tDQo+IHRoaXMgbWFpbC4gV2Ugd2lsbCBpbW1lZGlhdGVseSBy
ZW1vdmUgeW91ciBpbmZvcm1hdGlvbiBmcm9tIG91ciBzZW5kaW5nDQo+IGNhdGFsb2d1ZS4NCg==


From nobody Thu Sep 25 23:24:30 2014
Return-Path: 
X-Original-To: supa@ietfa.amsl.com
Delivered-To: supa@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6D991A1A4F for ; Thu, 25 Sep 2014 23:24:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.106
X-Spam-Level: 
X-Spam-Status: No, score=-1.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RP_MATCHES_RCVD=-0.786] 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 vlgVYhaHszhP for ; Thu, 25 Sep 2014 23:24:14 -0700 (PDT)
Received: from sendg.mailex.chinaunicom.cn (sendg.mailex.chinaunicom.cn [210.53.66.230]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D51911A1A1E for ; Thu, 25 Sep 2014 23:24:11 -0700 (PDT)
Received: from SBG8380-4.chinaunicom.cn (10.0.15.35) by M10-HQ-MLOUT01.cnc.intra (10.0.15.20) with Microsoft SMTP Server id 8.2.254.0; Fri, 26 Sep 2014 14:23:58 +0800
X-AuditID: 0a000f23-b7f696d000002d7c-c5-5425061e03dc
Received: from m10-cen-mlhub03.cnc.intra ( [10.0.192.43])	by SBG8380-4.chinaunicom.cn (Symantec Messaging Gateway) with SMTP id 21.AB.11644.E1605245; Fri, 26 Sep 2014 14:22:22 +0800 (HKT)
Received: from m10-hq-mlch01.hq.cnc.intra (10.0.15.26) by m10-cen-mlhub03.cnc.intra (10.0.192.43) with Microsoft SMTP Server (TLS) id 8.2.213.0; Fri, 26 Sep 2014 14:22:22 +0800
Received: from YingCheng-PC (114.255.193.232) by m10-hq-mlch01.hq.cnc.intra (10.0.15.26) with Microsoft SMTP Server id 8.2.213.0; Fri, 26 Sep 2014 14:22:21 +0800
Date: Fri, 26 Sep 2014 14:22:18 +0800
From: =?utf-8?B?WWluZyBDaGVuZw==?= 
To: =?utf-8?B?R2Vvcmdpb3MgS2FyYWdpYW5uaXM=?= 
References: ,  <201409261244369676994@chinaunicom.cn>, 
Message-ID: <201409261422178162817@chinaunicom.cn>
X-mailer: Foxmail 6, 15, 201, 26 [cn]
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=====003_Dragon221042328062_====="
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKKsWRmVeSWpSXmKPExsXCxXBAW7eVTTXEYFqHucXRxxIW25puMlnM 3rKK2eLo77WsDiweU35vZPVoOfKW1WPJkp9MAcxRdTaJeXn5JYklqQopqcXJtkrBmel5iSWl RakK/qUlSfmleSlKCpkptkrGSgoFOYnJqbmpeSW2SokFBalAGTsuBQxgA1SWmaeQmpecn5KZ l26rFBripmuhZPd0WdOzeXOeNa14OWXmi/Xrn/UtfTZlW8IVlowpJ26xFZx7wVoxaRdfA+Oa q6xdjJwcEgImEo/2fmWCsMUkLtxbz9bFyMUhJLCXUWLDmp9MEM4WRomFu/5CZZYyStz7PZ8F pIVFQFWi5fV2RhCbTcBeomn7LrCxIgIBEmfuPAAbyyywkFFi9oU6iOZTjBKHJs1mBXGEBVoZ Jc51toBV8QoYSSz5dx/qKFWJq219TBAbIiQuPVvIAlEjKHFy5hMWiKnBEj9efQDazAE0VV1i +S27CYyCs5BUzUJSNQuoillAU2L9Ln2IsKLElO6H7BC2hkTrnLnsyOILGNlWMUoEO7lbGFsY 6JroJWdk5iWW5mUm5+fqJedtYgQnAn7lHYwPTlgeYhTgYFTi4d23TyVEiDWxrLgy9xCjBAez kgjvZhbVECHelMTKqtSi/Pii0pzU4kOMyUAvTWSWEk3OByapvJJ4Q2MLC3NjY1MTYyNjM9KE lcR5a07IhwgJpAPTVXZqakFqEcwWJg5OqQbGDaeVZt6pEr01ZVHq17kCs2UibxmLfipacGtO nr6nJHdySrOEVNfV3CnKaYXbpkjfm1ceY3h79tnjpntyrhvKCcnbc4mn7L/R4Xz657Eybg21 k40X1b98WdandXG6I4fAlKdSMw5+e/d0d6PPP0O9HgdpoT1f1DT/cM5dfIih5tWHWI5/u8Nq lViKMxINtZiLihMBc/59JkgDAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/supa/FOYAMW_atCn8Ukr1nK_9Yb2Tm84
Cc: =?utf-8?B?QmVub2l0IENsYWlzZQ==?= , =?utf-8?B?c3VwYQ==?= , =?utf-8?B?VGluYSBUU09V?= 
Subject: Re: [Supa] =?utf-8?q?Draft_charter_v1=2E12//RE=3A__Area_hand-off=2C_a?= =?utf-8?q?nd_somefriendlyadvice_=2E=2E=2E?=
X-BeenThere: supa@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Sep 2014 06:24:26 -0000

--=====003_Dragon221042328062_=====
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgR2Vvcmdpb3MsDQoNClRoYW5rcyBmb3IgeW91ciBxdWljayBleHBsYWluYXRpb24uIEl0
IGlzIGNsZWFyIGZvciBtZS4NCg0KQlIsDQpZaW5nDQoNCg0KMjAxNC0wOS0yNiANCg0KDQoN
CllpbmcgQ0hFTkcgIOeoi+iOuQ0KQ2hpbmEgVW5pY29tIE5ldHdvcmsgVGVjaG5vbG9neSBS
ZXNlYXJjaCBJbnN0aXR1dGUg5Lit5Zu96IGU6YCa572R57uc5oqA5pyv56CU56m26ZmiDQpU
ZWw6ICs4Ni0xMC02ODc5OTk5OS03NzAyDQpNb2JpbGU6ICs4Ni0xODYwMTEwMjk3MQ0KDQoN
Cg0KDQoNCuWPkeS7tuS6uu+8miBHZW9yZ2lvcyBLYXJhZ2lhbm5pcyANCuWPkemAgeaXtumX
tO+8miAyMDE0LTA5LTI2ICAxMzowMjoxNyANCuaUtuS7tuS6uu+8miBZaW5nIENoZW5nKOiB
lOmAmumbhuWbouiBlOmAmue9kee7nOaKgOacr+eglOeptumZoikgDQrmioTpgIHvvJogQmVu
b2l0IENsYWlzZTsgVGluYSBUU09VOyBzdXBhIA0K5Li76aKY77yaIFJFOiBbU3VwYV0gRHJh
ZnQgY2hhcnRlciB2MS4xMi8vUkU6IEFyZWEgaGFuZC1vZmYsIGFuZCBzb21lZnJpZW5kbHlh
ZHZpY2UgLi4uIA0KIA0KSGkgWWluZywNClRoYW5rcyBmb3IgeW91ciBjb21tZW50cyENClBs
ZWFzZSBzZWUgaW4gbGluZS4NCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJv
bTogR2Vvcmdpb3MgS2FyYWdpYW5uaXMNCj4gU2VudDogRnJpZGF5LCBTZXB0ZW1iZXIgMjYs
IDIwMTQgNTo1MiBBTQ0KPiBUbzogR2Vvcmdpb3MgS2FyYWdpYW5uaXMNCj4gU3ViamVjdDog
UkU6IFtTdXBhXSBEcmFmdCBjaGFydGVyIHYxLjEyLy9SRTogQXJlYSBoYW5kLW9mZiwgYW5k
IHNvbWUNCj4gZnJpZW5kbHlhZHZpY2UgLi4uDQo+DQo+IEZyb206IFN1cGEgW21haWx0bzpz
dXBhLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBZaW5nIENoZW5nDQo+IFNlbnQ6
IEZyaWRheSwgU2VwdGVtYmVyIDI2LCAyMDE0IDU6NDUgQU0NCj4gVG86IHN1cGENCj4gQ2M6
IEJlbm9pdCBDbGFpc2U7IFRpbmEgVFNPVQ0KPiBTdWJqZWN0OiBSZTogW1N1cGFdIERyYWZ0
IGNoYXJ0ZXIgdjEuMTIvL1JFOiBBcmVhIGhhbmQtb2ZmLCBhbmQgc29tZQ0KPiBmcmllbmRs
eWFkdmljZSAuLi4NCj4NCj4gSGkgYWxsLA0KPg0KPiBJIGF0dGVuZGVkIHRoZSBlLW1lZXRp
bmcgbGFzdCBuaWdodCBhbmQgbGVhcm5lZCBhIGxvdC4gVGhhbmsgeW91IGZvciB5b3VyDQo+
IGVmZm9ydHMuIFRoZSBsYXRlc3QgY2hhcnRlciBpcyBub3cgY2xlYXJlciBhbmQgZmluZSBm
cm9tIG15IHNpZGUuIExhdGVyIEkgcGxhbg0KPiB0byB1cGRhdGUgdGhlIEREQyB1c2UgY2Fz
ZSBhY2NvcmRpbmdseS4NCj4NCj4gU29tZSBxdWljayBjb21tZW50czoNCj4NCj4gU29tZSBJ
RVRGIHdvcmtpbmcgZ3JvdXBzIGhhdmUgc3RhcnRlZCB3b3JrIHJlbGF0aW5nIHRvIHRoZSBk
ZXNjcmlwdGlvbiBvZg0KPiB2YXJpb3VzIHRvcG9sb2dpZXMgc3VjaCBhcyBJMlJTIChMMyBh
bmQgcm91dGluZyB0b3BvbG9naWVzKSwgQUxUTyAoY29zdCBtYXBzKSwNCj4gU0ZDIChzZXJ2
aWNlIGNoYWluKSwgbm9uZSBvZiB0aGVzZSBncm91cHMgYWltICgxKSBhdCBvZmZlcmluZyB0
cnVseSBnZW5lcmljDQo+IHRvcG9sb2d5IG1vZGVscyBmb3IgdGhlIHN0YW5kYXJkIG5vcnRo
Ym91bmQgaW50ZXJmYWNlLCBhbmQgKDIpIHRoYXQgYW4NCj4gYXBwbGljYXRpb24gY2FuIGNv
bW11bmljYXRlIHdpdGggbmV0d29yayBib3hlcywgc3VjaCBhcyBuZXR3b3JrIGNvbnRyb2xs
ZXJzLA0KPiBhbmQgTkVzLCBkZXZlbG9wZWQgYnkgZGlmZmVyZW50IHZlbmRvcnMuDQo+DQo+
IEhlcmUgZG8geW91IG1lYW4gdGhvc2Ugd29ya2luZyBncm91cCBkaWRu4oCZdCBkbyB5b3Vy
ICgyKS4gSWYgbm8sIEkgZ3Vlc3MgeW91DQo+IHNob3VsZCB1c2Ug4oCcbmVpdGhlcuKAnSBp
bnN0ZWFkLg0KWz5dDQpHZW9yZ2lvczogV2UgbWVhbiB0aGF0IHRob3NlIHdvcmtpbmcgZ3Jv
dXBzIGRpZCBub3QgZG8gKDEpIGFuZCAoMikuDQpEbyB3ZSBuZWVkIHRvIGNoYW5nZSB0aGUg
d29yZGluZz8NCj4NCj4gSW4gYWRkaXRpb24sIGdpdmVuIHRoYXQgdGhlcmUgd2VyZSBzb21l
IGRpc2N1c3Npb25zIHJlbGF0ZWQgdG8gZW5kIHVzZXIgYXBwDQo+IGFuZCBtYW5hZ2VtZW50
IGFwcC4gWW91IG1pZ2h0IHdhbnQgdG8gc3BlY2lmeSB0aGUgYXBwIGluIHRoaXMgc2VudGVu
Y2UgdG8NCj4gZWxpbWluYXRlIGNvbmZ1c2lvbi4NCls+XQ0KR2Vvcmdpb3M6ICJBcHBsaWNh
dGlvbnMiIHJlcHJlc2VudCBhbiBlbnRpdHkgdGhhdCBnZW5lcmF0ZXMgYW5kIG1haW50YWlu
cyBuZXR3b3JrIHNlcnZpY2VzIGFuZCBpcyBhZG1pbmlzdHJhdGVkIGJ5IGEgY29tbXVuaWNh
dGlvbiBzZXJ2aWNlIHByb3ZpZGVyLg0KPg0KPiBPbmUgbW9yZSBjb21tZW50LCBJIHNhdyB5
b3UgYWRkIHRoZSB0ZXJtIOKAnWludGVyb3BlcmFibGUgbWFubmVy4oCdIGluIHNldmVyYWwN
Cj4gcGxhY2VzLiBDb3VsZCB5b3UgcGxlYXNlIGVsYWJvcmF0ZT8NCls+XQ0KR2Vvcmdpb3M6
IHRoZSBpbnRlcm9wZXJhYmxlIG1hbm5lciByZWxhdGVzIHRvOiByZXF1aXJlbWVudCB0aGF0
IGFwcGxpY2F0aW9ucyBzaG91bGQgYmUgYWJsZSB0byBjb21tdW5pY2F0ZSB3aXRoIG5ldHdv
cmsgYm94ZXMsIHN1Y2ggYXMgbmV0d29yayBjb250cm9sbGVycywgYW5kIE5FcywgZGV2ZWxv
cGVkIGJ5IGRpZmZlcmVudCB2ZW5kb3JzLg0KQmVzdCByZWdhcmRzLA0KR2Vvcmdpb3MNCj4N
Cj4gQlIsDQo+IFlpbmcNCj4NCj4gMjAxNC0wOS0yNg0KPiBfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fDQo+IFlpbmcgQ0hFTkcgIOeoi+iOuQ0KPiBDaGluYSBV
bmljb20gTmV0d29yayBUZWNobm9sb2d5IFJlc2VhcmNoIEluc3RpdHV0ZSDkuK3lm73ogZTp
gJrnvZHnu5zmioDmnK/noJTnqbbpmaINCj4gVGVsOiArODYtMTAtNjg3OTk5OTktNzcwMg0K
PiBNb2JpbGU6ICs4Ni0xODYwMTEwMjk3MQ0KPiBfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fDQo+IOWPkeS7tuS6uu+8miBUaW5hIFRTT1UNCj4g5Y+R6YCB5pe2
6Ze077yaIDIwMTQtMDktMjYgIDA4OjUzOjQ3DQo+IOaUtuS7tuS6uu+8miBCZW5vaXQgQ2xh
aXNlDQo+IOaKhOmAge+8miBzdXBhQGlldGYub3JnDQo+IOS4u+mimO+8miBbU3VwYV0gRHJh
ZnQgY2hhcnRlciB2MS4xMi8vUkU6IEFyZWEgaGFuZC1vZmYsIGFuZCBzb21lDQo+IGZyaWVu
ZGx5YWR2aWNlIC4uLg0KPiBEZWFyIEJlbm9pdCBldCBhbCwNCj4NCj4gSGVyZSBjb21lcyBs
YXRlc3QgdmVyc2lvbi4gVGhlIGxpc3QgZGlzY3Vzc2lvbiBoZWxwcyBhIGxvdCB0byBtYWtl
IGl0IGNsZWFyZXIuDQo+DQo+ID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT0NCj4gU1VQQSAoU2hhcmVkIFVuaWZpZWQgUG9saWN5IEF1dG9tYXRp
b24pIGNoYXJ0ZXIgdjEuMTIgVGFyZ2V0IEFyZWE6IE9wZXJhdGlvbnMNCj4gYW5kIE1hbmFn
ZW1lbnQNCj4NCj4gRGVzY3JpcHRpb24gb2YgV29ya2luZyBHcm91cDoNCj4NCj4gUHJvZ3Jh
bW1hdGljIHdheXMgdG8gY29uZmlndXJlIG5ldHdvcmtzLCBvZnRlbiBjYWxsZWQgc29mdHdh
cmUtZGVmaW5lZCwgYXJlDQo+IGNvbnNpZGVyZWQgYnkgbWFueSBuZXR3b3JrIG9wZXJhdG9y
cyBpbiBvcmRlciB0byBzaGlmdCB0aGUgYmFsYW5jZSBpbiB0aGVpcg0KPiBmYXZvci4NCj4g
QXV0b21hdGluZyB0aGUgd2F5IG9mIGV4cG9zaW5nIGEgdmlldyBvZiB0aGUgbmV0d29yayB0
byBhcHBsaWNhdGlvbnMgbWF5DQo+IHByb3ZpZGUgc2lnbmlmaWNhbnQgaW1wcm92ZW1lbnRz
IGluIGNvbmZpZ3VyYXRpb24gYWdpbGl0eSwgZXJyb3IgZGV0ZWN0aW9uIGFuZA0KPiB1cHRp
bWUgZm9yIG9wZXJhdG9ycy4gSG93ZXZlciB0aGUgcmVhbCB2YWx1ZSBiZWhpbmQgY2VudHJh
bCBjb25maWd1cmF0aW9uDQo+IHNjaGVtZXMgbGllcyB3aXRoaW4gdGhlIHBvc3NpYmxlIHNp
bXBsaWZpY2F0aW9uIHRocm91Z2ggbW9kZWxzIHByb3ZpZGVkIGJ5DQo+IHN1Y2ggc3lzdGVt
cyB0byBhcHBsaWNhdGlvbnMgYW5kIG5ldHdvcmsgc2VydmljZXMgcnVubmluZyBhYm92ZSB0
aGVtIChvbiB0aGUNCj4gc28tY2FsbGVkIG5vcnRoYm91bmQgc2lkZSkuIFdlbGwtZGVzaWdu
ZWQgbW9kZWxzIGFyZSBhYmxlIHRvIHByb3ZpZGUgYSB3aWRlDQo+IHJhbmdlIG9mIGdyYW51
bGFyaXR5IGZvciB2YXJpb3VzIGFwcGxpY2F0aW9ucyBhbmQgbmV0d29yayBzZXJ2aWNlcyBu
ZWVkcywgZnJvbQ0KPiB0aGUgbG93ZXItbGV2ZWwgcGh5c2ljYWwgbmV0d29yayB0byBoaWdo
LWxldmVsIGFwcGxpY2F0aW9uIHNlcnZpY2VzLg0KPiBTZXZlcmFsIG9yZ2FuaXphdGlvbnMg
b3V0c2lkZSBvZiB0aGUgSUVURiBoYXZlIGRlZmluZWQgdmFyaW91cyBzY2hlbWVzIGZvciB0
aGUNCj4gY29uZmlndXJhdGlvbiBvZiBuZXR3b3JrIGRldmljZXMgYW5kIHNwZWNpZmljIG5l
dHdvcmsgY29udHJvbGxlcnMsIGJ1dCBub25lIG9mDQo+IHRoZW0gb2ZmZXIgYSB2ZW5kb3It
bmV1dHJhbCBzdGFuZGFyZGl6ZWQgd2F5IGZvciBhcHBsaWNhdGlvbnMgYW5kIG5ldHdvcmsN
Cj4gc2VydmljZXMgdG8gdHJhbnNtaXQgdGhlaXIgbmVlZHMgdG8gbmV0d29yayBjb250cm9s
bGVycy4gVGhlIFNVUEEgKFNoYXJlZA0KPiBVbmlmaWVkIFBvbGljeSBBdXRvbWF0aW9uKSB3
b3JraW5nIGdyb3VwIHdpbGwgd29yayBvbiB0aGUgZGVmaW5pdGlvbiBvZiBzdWNoDQo+IGFz
IHN0YW5kYXJkaXplZCBpbnRlcmZhY2UgZm9yIGFwcGxpY2F0aW9ucyBhbmQgbmV0d29yayBz
ZXJ2aWNlcyB0byBjb21tdW5pY2F0ZQ0KPiB3aXRoIG5ldHdvcmsgY29udHJvbGxlcnMgb2Yg
YWxsIHR5cGVzLiBJbiBwYXJ0aWN1bGFyLCBTVVBBIHdpbGwgZm9jdXMgb24NCj4gc2Vydmlj
ZSBzcGVjaWZpYyBtb2RlbHMgdGhhdCBhbGxvdyBhcHBsaWNhdGlvbnMgdG8gcmVxdWVzdCBj
ZXJ0YWluIG5ldHdvcmsNCj4gc2VydmljZXMgdG8gYmUgY3JlYXRlZC9kZWxldGVkL21vZGlm
aWVkLiBBIG5ldHdvcmsgc2VydmljZSBjYW4gZm9yIGV4YW1wbGUgYmUNCj4gYSB2aXJ0dWFs
IGxpbmsgYmV0d2VlbiB0d28gZW5kcG9pbnRzIHRoYXQgdXNlcyBjZXJ0YWluIHByb3BlcnRp
ZXMsIHRyYWZmaWMNCj4gZW5naW5lZXJpbmcsIGltcGxlbWVudGF0aW9uIG9mIElQdjYgdHJh
bnNpdGlvbiBtZWNoYW5pc20gYW5kIHRoZWlyIGVuZm9yY2VtZW50DQo+IHRvIHVzZXJzLg0K
PiBFYWNoIG5ldHdvcmsgc2VydmljZSBjYW4gYmUgcmVwcmVzZW50ZWQgYnkgYSBzZXJ2aWNl
IGJhc2VkIFBPTElDWSBtb2RlbCB0aGF0DQo+IGNhbiBtb2RlbCBhIGdyb3VwIG9mIGRlbWFu
ZHMgKGkuZS4sIGFjdGlvbnMgYW5kIGNvbnN0cmFpbnRzKSB0aGF0IGFyZSBiZWluZw0KPiBp
bml0aWF0ZWQgYnkgYXBwbGljYXRpb25zIHRoYXQgaW1wb3NlIHNpbWlsYXIgcmVxdWlyZW1l
bnRzIG9uIHRoZQ0KPiBjb21tdW5pY2F0aW9uIG5ldHdvcmsuIFRoZSB0ZXJtcyAiVU5JRklF
RCIgYW5kICJTSEFSRUQiIHVzZWQgaW4gdGhlIFNVUEENCj4gYWJicmV2aWF0aW9uLCByZWxh
dGUgdG8gdGhlIHdheSBvZiBob3cgdGhlIHNlcnZpY2UgcG9saWN5IG1vZGVsIGlzIGdlbmVy
YXRlZCwNCj4gc2luY2UgaXQgZ3JvdXBzLCB1bmlmaWVzIGFuZCBzaGFyZXMgdGhlIHNpbWls
YXIgcmVxdWlyZW1lbnRzIGltcG9zZWQgYnkgYSBidWxrDQo+IG9mIGFwcGxpY2F0aW9ucy4g
U1VQQSB3aWxsIHByb3ZpZGUgZ3VpZGVsaW5lcyBmb3IgbWVjaGFuaXNtcyB0aGF0IGNhbg0K
PiBkeW5hbWljYWxseSBhbmQgb24gYW4gaW50ZXJvcGVyYWJsZSBtYW5uZXIsIEFVVE9NQVRJ
Q0FMTFkgbWFwIHNlcnZpY2VzIGFuZA0KPiBwb2xpY2llcyBkZWZpbmVkIG9uIGFuIGFic3Ry
YWN0IHRvcG9sb2d5IGdyYXBoIGRvd24gdG8gbW9yZSBkZXRhaWxlZCBuZXR3b3JrDQo+IGdy
YXBocyBhbmQgc3BlY2lmaWMgbmV0d29yayBtYW5hZ2VtZW50IGFuZCBjb250cm9sbGluZyBw
b2xpY2llcy4NCj4gU29tZSBJRVRGIHdvcmtpbmcgZ3JvdXBzIGhhdmUgc3RhcnRlZCB3b3Jr
IHJlbGF0aW5nIHRvIHRoZSBkZXNjcmlwdGlvbiBvZg0KPiB2YXJpb3VzIHRvcG9sb2dpZXMg
c3VjaCBhcyBJMlJTIChMMyBhbmQgcm91dGluZyB0b3BvbG9naWVzKSwgQUxUTyAoY29zdCBt
YXBzKSwNCj4gU0ZDIChzZXJ2aWNlIGNoYWluKSwgbm9uZSBvZiB0aGVzZSBncm91cHMgYWlt
ICgxKSBhdCBvZmZlcmluZyB0cnVseSBnZW5lcmljDQo+IHRvcG9sb2d5IG1vZGVscyBmb3Ig
dGhlIHN0YW5kYXJkIG5vcnRoYm91bmQgaW50ZXJmYWNlLCBhbmQgKDIpIHRoYXQgYW4NCj4g
YXBwbGljYXRpb24gY2FuIGNvbW11bmljYXRlIHdpdGggbmV0d29yayBib3hlcywgc3VjaCBh
cyBuZXR3b3JrIGNvbnRyb2xsZXJzLA0KPiBhbmQgTkVzLCBkZXZlbG9wZWQgYnkgZGlmZmVy
ZW50IHZlbmRvcnMuDQo+IFNVUEEgd2lsbCB3b3JrIG9uIGRlZmluaW5nIHZlbmRvci1uZXV0
cmFsIHN0YW5kYXJkaXplZCBpbnRlcmZhY2VzIGJhc2VkIG9uIHRoZQ0KPiBjb25jZXB0IG9m
IG5ldHdvcmsgZ3JhcGgsIGFuIGVudGl0eSBkZXNjcmliaW5nIGFuIGFyYml0cmFyeSB0b3Bv
bG9neSBvZiBub2Rlcw0KPiBhbmQgbGlua3MgYXQgYW55IGxldmVsIG9mIGdyYW51bGFyaXR5
LiBTdWNoIGEgbmV0d29yayBncmFwaCBkZXNjcmliZXMgKDEpDQo+IHRvcG9sb2dpZXMgYXQg
ZGlmZmVyZW50IGxldmVscyBvZiBhYnN0cmFjdGlvbiwgKDIpIHRoZSByZWxhdGlvbnNoaXBz
IGJldHdlZW4NCj4gdGhlIGFic3RyYWN0aW9uIGxldmVscyBhbmQgKDMpIGFwcGxpZWQgc2Vy
dmljZSBiYXNlZCBwb2xpY3ksIHdoaWNoIGFyZSBhY3Rpb25zDQo+IGFuZCBjb25zdHJhaW50
cyBhcHBsaWVkIG9uIHRoZXNlIHRvcG9sb2dpZXMuIFNVUEEgbWF5IGFsc28gZGVmaW5lIGFu
eSBtYXBwaW5ncw0KPiB0byBhbnkgb3RoZXIgbmV0d29yayB0b3BvbG9neSBkYXRhIG1vZGVs
cyBkZWZpbmVkIHdpdGhpbiB0aGUgSUVURi4NCj4gVGhlIG1haW4gZ29hbCBvZiBTVVBBIGlz
IHRvIHByb3ZpZGUgc2VydmljZSBzcGVjaWZpYyBtb2RlbHMgdGhhdCBhbGxvdw0KPiBhcHBs
aWNhdGlvbnMgdG8gcmVxdWVzdCBuZXR3b3JrIHNlcnZpY2VzIHRvIGJlIGNyZWF0ZWQvZGVs
ZXRlZC9tb2RpZmllZC4gVGhpcw0KPiBjYW4gYmUgcmVhbGl6ZWQgYnk6DQo+ICAgbykgbW9k
ZWwgbXVsdGlwbGUgdG9wb2xvZ2llcyBhdCBkaWZmZXJlbnQgbGV2ZWxzIG9mIGFic3RyYWN0
aW9uIHVzaW5nIGENCj4gbmV0d29yayBncmFwaCwNCj4gICBvKSBtb2RlbCB0aGUgcmVsYXRp
b25zaGlwcyBiZXR3ZWVuIHRoZSBhYnN0cmFjdGlvbiBsZXZlbHMuDQo+ICAgbykgdHJhbnNw
b3J0aW5nIG1vZGVsIGluc3RhbmNlcyB1c2luZyBlaXRoZXIgTkVUQ09ORiBvciBSRVNUQ09O
Rg0KPg0KPiBTVVBBIHdpbGwgZW5zdXJlIHRoYXQgaW4gY2FzZSBhbnkgc3BlY2lmaWMgTkVU
Q09ORi9SRVNUQ09ORiBwcm90b2NvbA0KPiByZXF1aXJlbWVudHMgYXJlIGlkZW50aWZpZWQs
IHRoZXkgd2lsbCBiZSBjb21tdW5pY2F0ZWQgaW4gYSB0aW1lbHkgbWFubmVyIHRvDQo+IHRo
ZSBORVRDT05GIHdvcmtpbmcgZ3JvdXAuIFNVUEEgd2lsbCBjb25zdWx0IHdpdGggdGhlIFlB
TkcgZG9jdG9ycyB0byBlbnN1cmUNCj4gdGhhdCBkYXRhIG1vZGVscyBmb2xsb3cgY29tbW9u
IHByYWN0aWNlcy4NCj4NCj4gV29yayBpdGVtcyBmb3IgU1VQQSBpbmNsdWRlOg0KPiA9PT09
PT09PT09PT09PT09PT09PT09PT09PT09DQo+IDEpIFRoZSBkZWZpbml0aW9uIG9mIGEgc3Rh
bmRhcmRpemVkIG1vZGVsIGZvciBhIG5ldHdvcmsgZ3JhcGgsIHVzaW5nIFlBTkcuDQo+IFRo
aXMgbW9kZWwgbWF5IGJlIHVzZWQgdG8gZGVzY3JpYmUgdG9wb2xvZ2llcyBhdCBhbnkgZnVu
Y3Rpb25hbCBsYXllciwgZnJvbQ0KPiBwaHlzaWNhbCBuZXR3b3JrcyB0byBuZXR3b3JrIHNl
cnZpY2VzLg0KPiAyKSBUaGUgZGVmaW5pdGlvbiBhbmQgc3RhbmRhcmRpemF0aW9uIG9mIGEg
bnVtYmVyIG9mIGJhc2ljIHBvbGljeSBhbmQgZGF0YQ0KPiBtb2RlbHMgdXNpbmcgbmV0d29y
ayBncmFwaHMuIFRoZXNlIG1pZ2h0IGluY2x1ZGUsIGJ1dCBhcmUgbm90IGxpbWl0ZWQgdG8N
Cj4gTDNWUE5zLCB0cmFmZmljIGVuZ2luZWVyaW5nLCBpbXBsZW1lbnRhdGlvbiBvZiBJUHY2
IHRyYW5zaXRpb24gbWVjaGFuaXNtIGFuZA0KPiB0aGVpciBlbmZvcmNlbWVudCB0byB1c2Vy
cy4NCj4gMykgUHJvdmlkZSBndWlkZWxpbmVzIGZvciBtZWNoYW5pc21zIHRoYXQgY2FuIGR5
bmFtaWNhbGx5IGFuZCBvbiBhbg0KPiBpbnRlcm9wZXJhYmxlIG1hbm5lciwgYXV0b21hdGlj
YWxseSBtYXAgc2VydmljZXMgYW5kIHBvbGljaWVzIGRlZmluZWQgb24gYW4NCj4gYWJzdHJh
Y3QgdG9wb2xvZ3kgZ3JhcGggZG93biB0byBtb3JlIGRldGFpbGVkIG5ldHdvcmsgZ3JhcGhz
IGFuZCBzcGVjaWZpYw0KPiBuZXR3b3JrIG1hbmFnZW1lbnQgYW5kIGNvbnRyb2xsaW5nIHBv
bGljaWVzLg0KPiA0KSBHdWlkZWxpbmVzIG9uIGhvdyB0byB1c2UgTkVUQ09ORiAob3IgUkVT
VENPTkYpIGF1dGhlbnRpY2F0aW9uIGFuZA0KPiBhdXRob3JpemF0aW9uIG1lY2hhbmlzbXMg
dG8gYWNoaWV2ZSBwcm90ZWN0aW9uIGFuZCBpc29sYXRpb24NCj4NCj4gRGVsaXZlcmFibGVz
Og0KPiA9PT09PT09PT09PT09DQo+IG8pIFByb2R1Y2UgYW4gaW5mb3JtYXRpb25hbCBSRkMg
IlByb2JsZW0gU3RhdGVtZW50IGFuZCBVc2UgQ2FzZXMiLg0KPiBvKSBQcm9kdWNlIGEgc3Rh
bmRhcmRzLXRyYWNrIFJGQyB0aGF0IHNwZWNpZmllcyBZQU5HIG1vZGVscyBmb3IgYSBnZW5l
cmljDQo+IG11bHRpLWxheWVyIG5ldHdvcmsgZ3JhcGguDQo+IG8pIFByb2R1Y2Ugc3RhbmRh
cmRzLXRyYWNrIFJGQ3MgdGhhdCBzcGVjaWZ5IGV4dGVuc2lvbnMgZm9yIHRoZSBnZW5lcmlj
IFlBTkcNCj4gbW9kZWxzIGRlZmluZWQgYWJvdmUgZm9yIG5ldHdvcmsgc2VydmljZXMgdGhh
dCBtYW5hZ2UgdmlydHVhbCBsaW5rcywgdHJhZmZpYw0KPiBlbmdpbmVlcmluZyBhbmQgaW1w
bGVtZW50YXRpb24gb2YgSVB2NiB0cmFuc2l0aW9uIG1lY2hhbmlzbSBhbmQgdGhlaXINCj4g
ZW5mb3JjZW1lbnQgdG8gdXNlcnMuDQo+IG8pIFByb2R1Y2UgYW4gaW5mb3JtYXRpb25hbCBS
RkMgdGhhdCBwcm92aWRlcyB0aGUgZ3VpZGVsaW5lcyBmb3IgbWVjaGFuaXNtcw0KPiB0aGF0
IGNhbiBkeW5hbWljYWxseSBhbmQgb24gaW50ZXJvcGVyYWJsZSBtYW5uZXIsIGF1dG9tYXRp
Y2FsbHkgbWFwIHNlcnZpY2VzDQo+IGFuZCBwb2xpY2llcyBkZWZpbmVkIG9uIGFuIGFic3Ry
YWN0IHRvcG9sb2d5IGdyYXBoIGRvd24gdG8gbW9yZSBkZXRhaWxlZA0KPiBuZXR3b3JrIGdy
YXBocyBhbmQgc3BlY2lmaWMgbmV0d29yayBtYW5hZ2VtZW50IGFuZCBjb250cm9sbGluZyBw
b2xpY2llcy4NCj4gbykgUHJvZHVjZSBhbiBpbmZvcm1hdGlvbmFsIFJGQyB0aGF0IHByb3Zp
ZGVzIHRoZSBndWlkZWxpbmVzIG9uIHVzaW5nIE5FVENPTkYNCj4gKG9yIFJFU1RDT05GKSBh
dXRoZW50aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlvbiBtZWNoYW5pc21zIHRvIGFjaGlldmUg
c2VjdXJpdHkNCj4gcHJvdGVjdGlvbiBhbmQgaXNvbGF0aW9uJyBhcyBhbiBJbmZvcm1hdGlv
bmFsIFJGQy4NCj4NCj4gTWlsZXN0b25lczoNCj4gPT09PT09PT09PT0NCj4gRGVjIDIwMTQg
IEluaXRpYWwgIlByb2JsZW0gU3RhdGVtZW50IGFuZCBVc2UgQ2FzZXMiIFdHIEktRCBGZWIg
MjAxNSAgSW5pdGlhbA0KPiAiTXVsdGktbGF5ZXIgTmV0d29yayBHcmFwaCBZQU5HIE1vZGVs
IiBXRyBJLUQgQXByIDIwMTUgIEluaXRpYWwgc2VydmljZQ0KPiBzcGVjaWZpYyBkYXRhIG1v
ZGVsIFdHIEktRHMgTWF5IDIwMTUgIEluaXRpYWwgIk1hcHBpbmcgR3VpZGVsaW5lcyIgV0cg
SS1EIEp1bg0KPiAyMDE1ICBTdWJtaXQgIlByb2JsZW0gU3RhdGVtZW50IGFuZCBVc2UgQ2Fz
ZXMiIEktRCB0byBJRVNHIEp1bCAyMDE1ICBJbml0aWFsDQo+ICJBdXRoZW50aWNhdGlvbiBh
bmQgQXV0aG9yaXphdGlvbiIgV0cgSS1EIFNlcCAyMDE1ICBTdWJtaXQgIk11bHRpLWxheWVy
DQo+IE5ldHdvcmsgR3JhcGggWUFORyBNb2RlbCIgSS1EIHRvIElFU0cgTm92IDIwMTUgIFN1
Ym1pdCBzZXJ2aWNlIHNwZWNpZmljIGRhdGENCj4gbW9kZWwgSS1EcyB0byBJRVNHIEZlYiAy
MDE2ICBTdWJtaXQgIk1hcHBpbmcgR3VpZGVsaW5lcyIgSS1EIHRvIElFU0cgQXByDQo+IDIw
MTYgIFN1Ym1pdCAiQXV0aGVudGljYXRpb24gYW5kIEF1dGhvcml6YXRpb24iIEktRCB0byBJ
RVNHDQo+DQo+DQo+IFRoYW5rIHlvdSwNCj4gVGluYQ0KPg0KPiBGcm9tOiBTdXBhIFttYWls
dG86c3VwYS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTGl1c2h1Y2hlbmcgKFdp
bGwpDQo+IFNlbnQ6IFRodXJzZGF5LCBTZXB0ZW1iZXIgMjUsIDIwMTQgNzozNiBQTQ0KPiBU
bzogQmVub2l0IENsYWlzZQ0KPiBDYzogc3VwYUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTog
W1N1cGFdIEFyZWEgaGFuZC1vZmYsIGFuZCBzb21lIGZyaWVuZGx5IGFkdmljZSAuLi4NCj4N
Cj4gSGkgQmVub2l0LA0KPg0KPiBCZWxvdyBpbmxpbmUgcGxlYXNlIHNlZSB0d28gcGllY2Vz
IG9mIGNvbXBsZW1lbnRhcnkgYW5zd2VyIGZyb20gbXkgdGVhbQ0KPiAoc3RhcnRzIHdpdGgg
W1dpbGxdKS4gVGhhbmsgeW91IQ0KPg0KPiBSZWdhcmRzLA0KPiBXaWxsDQo+DQo+IEZyb206
IFN1cGEgW21haWx0bzpzdXBhLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBHZW9y
Z2lvcyBLYXJhZ2lhbm5pcw0KPiBTZW50OiBXZWRuZXNkYXksIFNlcHRlbWJlciAyNCwgMjAx
NCA3OjMwIFBNDQo+IFRvOiBCZW5vaXQgQ2xhaXNlOyBUaW5hIFRTT1U7IEp1ZXJnZW4gU2No
b2Vud2FlbGRlcg0KPiBDYzogWmhlbiBDYW87IHN1cGFAaWV0Zi5vcmcNCj4gU3ViamVjdDog
UmU6IFtTdXBhXSBBcmVhIGhhbmQtb2ZmLCBhbmQgc29tZSBmcmllbmRseSBhZHZpY2UgLi4u
DQo+DQo+IEhpIEJlbm9pdCwNCj4NCj4gVGhhbmsgeW91IGZvciB5b3VyIGNvbW1lbnRzLg0K
PiBQbGVhc2Ugc2VlIGluIGxpbmUsDQo+DQo+IEZyb206IFN1cGEgW21haWx0bzpzdXBhLWJv
dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCZW5vaXQgQ2xhaXNlDQo+IFNlbnQ6IFdl
ZG5lc2RheSwgU2VwdGVtYmVyIDI0LCAyMDE0IDEwOjQxIEFNDQo+IFRvOiBHZW9yZ2lvcyBL
YXJhZ2lhbm5pczsgVGluYSBUU09VOyBKdWVyZ2VuIFNjaG9lbndhZWxkZXINCj4gQ2M6IFpo
ZW4gQ2FvOyBzdXBhQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbU3VwYV0gQXJlYSBoYW5k
LW9mZiwgYW5kIHNvbWUgZnJpZW5kbHkgYWR2aWNlIC4uLg0KPg0KPiBIaSBHZW9yZ2lvcywN
Cj4gSGkgQmVub2l0LA0KPg0KPiBUaGFua3MgZm9yIHlvdXIgY29tbWVudHMhDQo+IFBsZWFz
ZSBzZWUgaW4gbGluZS4NCj4NCj4NCj4gR2Vvcmdpb3M6IFBsZWFzZSBub3RlIHRoYXQgd2Ug
YXJlIHJlZmVycmluZyB0byB0aGUgZm9sbG93aW5nIGZpZ3VyZToNCj4gICAgICAgICAgICAg
IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAgICAgICAgICAg
ICAgfCBhcHBsaWNhdGlvbnMgICAgICAgICAgICAgICAgICAgICAgICB8DQo+ICAgICAgICAg
ICAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gICAgICAg
ICAgICAgICAgICAgICAgICB8ICA8LS0tZW5kIHVzZS4gQXBwbC4gICB8DQo+ICAgICAgICAg
ICAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0gICAgICAgICAgICAgfDwtLS1lbmQgdXNlLiBB
cHBsLg0KPiAgICAgICAgICAgICAgfCBlbmhhbmNlZCBPU1MgICAgICB8ICAgICAgICAgICAg
IHwNCj4gICAgICAgICAgICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLSAgICAgICAgICAgICB8
DQo+ICAgICAgICAgICAgICAgICAgICAgICB8ICAgPC0tLSBuZXR3b3JrIHNlcnZpY2UgfCBZ
QU5HIG1vZGVscyAgL05FVENPTkYNCj4gaW50ZXJmYWNlICAgICAgICAgICAgICAgIHwNCj4g
ICAgICAgICAgICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+
ICAgICAgICAgICAgICB8ICAgY29udHJvbGxlciAgICAgICAgICAgICAgICAgICAgICAgfCAg
ICAgICAgICAgICAgIDwtLS0NCj4gICBtYXBwaW5nIG5ldHdvcmsgc2VydmljZXMgdG8gdG9w
b2xvZ3kNCj4gICAgICAgICAgICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tDQo+ICAgICAgICAgICAgICAgICAgfCAgICAgICB8ICAgICAgICB8ICAgICAgICAg
ICAgICAgICAgICA8LS0tIGRldmljZS9mZWF0dXJlDQo+IHNwZWNpZmljIFlBTkcgbW9kZWxz
IC8gTkVUQ09ORiBpbnRlcmZhY2UNCj4gICAgICAgICAgICAgIE5FMSAgICBORTIgICBORW4N
Cj4gSXQncyBub3Qgb2J2aW91cyB3aGF0IGFuICJlbmhhbmNlZCBPU1MiIGlzPw0KPg0KPiBH
ZW9yZ2lvczogaXQgcmVsYXRlcyB0byB0aGUgc3lzdGVtIHRoYXQgcnVucyBuZXR3b3JrIHNl
cnZpY2VzLiBUaGVzZSBzZXJ2aWNlcw0KPiBhcmUgZW5oYW5jZWQgT3BlcmF0aW9uYWwgU3Vw
cG9ydCBTeXN0ZW0gKE9TUykgbGlrZSBzZXJ2aWNlcyB0aGF0IGhlbHAgYQ0KPiBjb21tdW5p
Y2F0aW9uIHNlcnZpY2UgcHJvdmlkZXIgdG8gbW9uaXRvciwgY29udHJvbCwgYW5hbHl6ZSBh
bmQgbWFuYWdlIGENCj4gY29tbXVuaWNhdGlvbiBuZXR3b3JrLg0KPg0KPiBHZW9yZ2lvczog
QWNjb3JkaW5nIHRvIHRoZSBwcm92aWRlZCBmaWd1cmU6IDEpIG5lZWQgdG8gd29yayBvbiBu
ZXR3b3JrIHNlcnZpY2UNCj4gWWFuZyBtb2RlbHMsIDIgbWFwcGluZyBuZXR3b3JrIHNlcnZp
Y2VzIHRvIHRvcG9sb2d5LCAzLiBEZXZpY2UvZmVhdHVyZQ0KPiBzcGVjaWZpYyBZYW5nIE1v
ZGVscywgNCkgZW5kIHVzZXIgc3BlY2lmaWMgWWFuayBNb2RlbHMgKG91dCBvZiBzY29wZSku
IFRoZQ0KPiBpbnRlcmZhY2UgYmV0d2VlbiBlbmQgdXNlciBhcHBsaWNhdGlvbnMgYW5kIGEg
Y29udHJvbGxlciwgYW5kIGludGVyZmFjZQ0KPiBiZXR3ZWVuIGVuZCB1c2VyIGFwcGxpY2F0
aW9uIGFuZCBlbmhhbmNlZCBPU1MsIGFyZSBhbHNvIG91dCBvZiBzY29wZS4NCj4gQ29uY2Vy
bmluZyB5b3VyIGxhc3Qgc2VudGVuY2UuIEknbSBjb25mdXNlZC4NCj4gV2hhdCBkb2VzIHRo
ZSBmb2xsb3dpbmcgZGVsaXZlcmFibGUgbWVhbiB0aGVuPw0KPiBvKSBzcGVjaWZ5IGFuZCBz
dGFuZGFyZGl6ZSBob3cgTkVUQ09ORi9ZQU5HIChvciBSRVNUQ09ORi9ZQU5HKSBjYW4gYmUg
dXNlZCB0bw0KPiBzZWN1cmVseSBhbmQgZWZmaWNpZW50bHkgZGlzdHJpYnV0ZSB1cCB0byBk
YXRlIChmcmVzaCkgbmV0d29yayBncmFwaHMgYmV0d2Vlbg0KPiBuZXR3b3JrIHNlcnZpY2Ug
c3lzdGVtcyBhbmQgbmV0d29yayBtYW5hZ2VtZW50IGFuZCBjb250cm9sbGluZyBzeXN0ZW1z
DQo+DQo+IEl0IHJlbGF0ZXMgdG8gdGhlIGludGVyZmFjZSBiZXR3ZWVuIHRoZSBuZXR3b3Jr
IHNlcnZpY2Ugc3lzdGVtIChlbmhhbmNlZCBPU1MNCj4gaW4gdGhlIGFib3ZlIGZpZ3VyZS4N
Cj4gUGxlYXNlIG5vdGUgdGhhdCB3ZSBzYXkgdGhhdCB3ZSBpbml0aWFsbHkgb25seSBmb2N1
cyBvbiB0aGlzIGludGVyZmFjZSwgaW4NCj4gb3JkZXIgdG8gbmFycm93IGRvd24gdGhlIHNj
b3BlIG9mIHRoaXMgYWN0aXZpdHkNCj4NCj4gSG93ZXZlciwgaWYgdGhlcmUgYXJlIHN1cHBv
cnRzIHRoYXQgdGhpbmsgd2Ugc2hvdWxkIGluaXRpYWxseSBmb2N1cyBhbHNvIG9uDQo+IHRo
ZSBpbnRlcmZhY2UgYmV0d2VlbiBlbmQgdXNlciBhcHBsaWNhdGlvbiBhbmQgY29udHJvbGxl
ciB3ZSB3aWxsIGFsc28gaW5jbHVkZQ0KPiB0aGlzIGludGVyZmFjZSBpbiB0aGUgc2NvcGUu
DQo+DQo+IFtXaWxsXTogRmlyc3Qgb2YgYWxsLCBJTU9ILCB0aGUgZmlndXJlcyBmcm9tIEJl
bm9pdCBhbmQgR2Vvcmdpb3MgYXJlIG5vdA0KPiBpbmNvbXBhdGlibGUuIEZyb20gdGhlIHBl
cnNwZWN0aXZlIG9mIGNvbnRyb2xsZXIsIHRoZXkgYXJlIGRpZmZlcmVudCBsYXRpdHVkZXMN
Cj4gb2Ygbm9ydGhiYW5kLiBUaGUgYXBwbGljYXRpb24gYW5kIGVuaGFuY2VkIE9TUyBpbiBH
ZW9yZ2lvcyBmaWd1cmUgY2FuIGJlIHB1dA0KPiB0b2dldGhlciBpbnRvIGFuIGxhcmdlciBh
cHBsaWNhdGlvbiogbGF5ZXIgb2YgQmVub2l04oCZcyBmaWd1cmUuIFRoZSBuZXR3b3JrDQo+
IGdyYXBoIGlzIHByb3Bvc2VkIHRvIHByb3ZpZGUgbmV0d29yay13aWRlIGNvbmZpZ3VyYXRp
b24gY29udGFpbmluZyB0aGUga2V5DQo+IGluZm9ybWF0aW9uIGZvciBzZXJ2aWNlIGluc3Rh
bmNlcy4gT25lIGV4YW1wbGUgaXMsIGZvciB0aGUgRERDIHVzZSBjYXNlLCB0aGUNCj4gbmV0
d29yayBncmFwaCBjb250YWlucyB0aGUga2V5IGluZm9ybWF0aW9uIHN1Y2ggYXMgdGhlIGtl
eSBub2RlIGluZm9ybWF0aW9uIG9mDQo+IHRoZSBwYXRoIGFuZCB0aGUga2V5IHJlcXVpcmVt
ZW50IG9mIHRyYWZmaWMgc3RlZXJpbmcuDQo+DQo+IFJlZ2FyZGluZyB0byB0aGUgYXBwLCBt
YW5hZ2VtZW50IGFwcCwgZW5kIHVzZXIgYXBwIGhlcmUsIEkgd2FudCB0byBhZGQNCj4gc29t
ZXRoaW5nIHJlbGF0ZWQgdG8gdGhlIGhpc3Rvcnkgb2YgdGhpcyB3b3JrLiBBdCB0aGUgdmVy
eSBiZWdpbm5pbmcsIHdoZW4NCj4gdGhpcyB3b3JrIGlzIGNhbGwgQVBPTkYgYmVmb3JlIFRv
cm9udG8gSUVURiBtZWV0aW5nLCB0aGUgZW5kIHVzZXIgYXBwIGlzIGluDQo+IHRoZSBzY29w
ZS4gSG93ZXZlciwgdGhlcmUgYXJlIG1haW5seSB0aHJlZSByZWFzb25zIHRoYXQgd2UgcmVt
b3ZlIHRoaXMgcG9pbnQ6DQo+IDEuICAgICAgVGhlIGNvbmZsaWN0aW9uIHdpdGggQUVDT04s
IHdlIGRpc2N1c3NlZCB3aXRoIHByb3BvbmVudHMgb2YgQUVDT04gYW5kDQo+IHRvIGF2b2lk
IHRoZSBjb25mbGljdCBhcyBhdCB0aGF0IHRpbWUgdGhleSB3ZXJlIHByb3Bvc2luZyB0aGUg
aW50ZXJmYWNlIGZyb20NCj4gZW5kIHVzZXIgYXBwIHRvIG5ldHdvcmsgZGV2aWNlcy4gTGF0
ZXIgaW4gdGhlIElFU0cgbWVldGluZyBpbiBUb3JvbnRvLCB3ZQ0KPiBzdWNjZXNzZnVsbHkg
Y2xhcmlmaWVkIHRoZSBkaWZmZXJlbmNlcyBhbmQgZ290IHRoZSBzdWdnZXN0aW9uIHRvIGZv
Y3VzIG9uDQo+IG1hbmFnZW1lbnQgYXBwLg0KPiAyLiAgICAgIExhcnMgRWdnZXJ0IHNob3dl
ZCBoaXMgY29uY2VybmluZyBhYm91dCB0aGUgaW50ZXJmYWNlIGJldHdlZW4gZW5kIHVzZXIN
Cj4gYXBwIGFuZCBuZXR3b3JrIGRldmljZXMgbWF5IGxlYWQgdG8gc2VjdXJpdHkgaXNzdWUu
ICBLb3N0YXMgUGVudGlrb3VzaXMgYWxzbw0KPiBtZW50aW9uZWQgdGhpcyB0byBtZS4NCj4N
Cj4gSG93ZXZlciwgdGhlc2UgYXJlIG9sZCBzdG9yaWVzLiBEdXJpbmcgdGhlIFRvcm9udG8g
Qm9GLCBzb21lb25lIGFsc28gc3VnZ2VzdGVkDQo+IHVzIHJlLXB1dCB0aGUgZW5kIHVzZXIg
YXBwIGludG8gY29wZS4gQSBsYXJnZSBhcHAgbGF5ZXIgY29udGFpbmluZyBib3RoIGVuZA0K
PiB1c2VyIGFwcCBhbmQgbWFuYWdlbWVudCBhcHAgbWF5IHJlcGxhY2UgdGhlIGZpcnN0IHR3
byBsYXllcnMgaW4gdGhlIG9sZCA0DQo+IGxheWVycyBmaWd1cmUuIEhlcmUsIG15IHF1ZXN0
aW9uIGlzLCBhcmUgeW91IGluIGZhdm9yIG9mIGFkZGluZyBlbmQgdXNlciBhcHANCj4gaW50
byBTVVBBIHNjb3BlIG9yIG5vdD8NCj4NCj4NCj4gUmVnYXJkaW5nIHlvdXIgY29tbWVudCwg
IiBJJ20gbm90IGNvbnZpbmNlZCB3ZSBjb3VsZCBzdGFuZGFyZGl6ZSB0aGVtLCBhcyB0aGV5
DQo+IGFyZSBvcGVyYXRvcnMgc3BlY2lmaWMsIGFuZCB3aWxsIGJlIGV2b2x2aW5nIGFsb25n
IHRoZSB0aW1lLiBUaGVyZSBhcmUgbWFueQ0KPiBkaWZmZXJlbnQgd2F5cyB0byBjb25maWd1
cmUgYSBWUE4sIGZvciBleGFtcGxlLiIgV2VyZSB5b3UgcmVmZXJyaW5nIHRvOg0KPiAzLiBE
ZXZpY2UvZmVhdHVyZSBzcGVjaWZpYyBZYW5nIE1vZGVscz8NCj4gTm8sIHRoZSBzZXJ2aWNl
IFlBTkcgbW9kZWxzDQo+DQo+IEdlb3JnaW9zOiBJIHNlZSwgYnV0IHdlIGNhbiB3b3JrIG9u
IFlBTkcgbW9kZWxzIHRoYXQgY2FuIGJlIHVzZWQgZm9yIGEgbnVtYmVyDQo+IG9mIG1haW4g
bmV0d29yayBzZXJ2aWNlcywgd2hpY2ggYXJlIGVzc2VudGlhbCBmb3Igb3BlcmF0b3JzIGFu
ZCB0aGF0IHRoZXkNCj4gd291bGQgbGlrZSB0byBoYXZlIHRoZW0gc3RhbmRhcmRpemVkLg0K
Pg0KPg0KPg0KPiBTZWUgaW4tbGluZQ0KPiBEZWFyIGFsbCwNCj4NCj4gSG9wZSB0aGlzIHZl
cnNpb24gb2YgZHJhZnQgY2hhcnRlciBhZGRyZXNzIG1vc3Qgb2YgdGhlIGNvbW1lbnRzIGZy
b20gdGhlIGxpc3QuDQo+DQo+IC0tLS0tLQ0KPg0KPg0KPg0KPg0KPiBJbiBwYXJ0aWN1bGFy
LCBhcyBzdGFydGluZyBwb2ludCwgU1VQQSB3aWxsIG9ubHkgZm9jdXMgb24gbmV0d29yayBz
ZXJ2aWNlcywNCj4gd2hpY2ggYXJlIGVuaGFuY2VkIE9wZXJhdGlvbmFsIFN1cHBvcnQgU3lz
dGVtIChPU1MpIGxpa2Ugc2VydmljZXMgdGhhdCBoZWxwIGENCj4gY29tbXVuaWNhdGlvbiBz
ZXJ2aWNlIHByb3ZpZGVyIHRvIG1vbml0b3IsIGNvbnRyb2wsIGFuYWx5emUgYW5kIG1hbmFn
ZSBhDQo+IGNvbW11bmljYXRpb24gbmV0d29yay4gVGhlIHN5c3RlbXMgdGhhdCBhcmUgcnVu
bml1bmcgc3VjaCBuZXR3b3JrIHNlcnZpY2VzIGFyZQ0KPiBkZW5vdGVkIGluIHRoaXMgZG9j
dW1lbnQgYXMgTmV0d29yayBTZXJ2aWNlIFN5c3RlbXMuDQo+IEVhY2ggbmV0d29yayBzZXJ2
aWNlIGNhbiBiZSByZXByZXNlbnRlZCBieSBhIGNsYXNzaWZpZWQgYXBwbGljYXRpb24gYmFz
ZWQNCj4gUE9MSUNZIG1vZGVsLCBzaW5jZSBpdCBjYW4gbW9kZWwgdGhlIGdyb3VwIG9mIGRl
bWFuZHMgd2hpY2ggYXJlIFNIQVJFRCBhbmQNCj4gVU5JRklFRCBhbmQgYXJlIGNvbWluZyBm
cm9tIGEgYnVuZGxlIG9mIGFwcGxpY2F0aW9ucyB0aGF0IGltcG9zZSBzaW1pbGFyDQo+IHJl
cXVpcmVtZW50cyBvbiB0aGUgY29tbXVuaWNhdGlvbiBuZXR3b3JrLg0KPiBJJ20gYWZyYWlk
IEkgZG9uJ3QgdW5kZXJzdGFuZCAobGlrZSBKw7xyZ2VuKQ0KPg0KPiBHZW9yZ2lvczogV2hh
dCB3ZSB3YW50IHRvIHNheSBpcyB0aGF0IHRoZXJlIGFyZSBhcHBsaWNhdGlvbnMgdGhhdCBp
bXBvc2UNCj4gc2ltaWxhciByZXF1aXJlbWVudHMgb24gdGhlIGNvbW11bmljYXRpb24gbmV0
d29yay4gRm9yIGVhY2ggZ3JvdXAgb2Ygc3VjaCBidWxrDQo+IG9mIGFwcGxpY2F0aW9ucyBh
IG5ldHdvcmsgc2VydmljZSBjYW4gYmUgZGVmaW5lZCB0aGF0IGNhbiBiZSByZXByZXNlbnRl
ZCBieSBhDQo+IHNlcnZpY2UgcG9saWN5IG1vZGVsIChpLmUuLCBpdHMgYWN0aW9ucyBhbmQg
Y29uc3RyYWludHMpLg0KPg0KPg0KPiBHZW9yZ2lvczogVGhhbmtzIGZvciB0aGUgc3VnZ2Vz
dGlvbiwgdGhlIHRleHQgbmVlZHMgdG8gYmUgcmVwaHJhc2VkLCBzZWUgYmVsb3c6DQo+IEVh
Y2ggbmV0d29yayBzZXJ2aWNlIGNhbiBiZSByZXByZXNlbnRlZCBieSBhbiBhcHBsaWNhdGlv
biBiYXNlZCBQT0xJQ1kgbW9kZWwsDQo+IHdoaWNoIGlzIFVOSUZJRUQgYW5kIFNIQVJFRCwg
c2luY2UgaXQgY2FuIG1vZGVsIHRoZSBncm91cCBvZiBkZW1hbmRzIChpLmUsDQo+IGFjdGlv
bnMgYW5kIGNvbnN0cmFpbnRzKSB0aGF0IGFyZSBjb21pbmcgZnJvbSBhIGJ1bmRsZSBvZiBh
cHBsaWNhdGlvbnMgdGhhdA0KPiBpbXBvc2Ugc2ltaWxhciByZXF1aXJlbWVudHMgb24gdGhl
IGNvbW11bmljYXRpb24gbmV0d29yay4NCj4gSSBzdGlsbCBkb24ndCB1bmRlcnN0YW5kLiB3
aGF0ICJVTklGSUVEIGFuZCBTSEFSRUQiIG1lYW4uDQo+DQo+IEdlb3JnaW9zOiB0aGUgdGVy
bXMg4oCcVU5JRklFROKAnSBhbmQg4oCcU0hBUkVE4oCd4oCdIHJlbGF0ZSB0byB0aGUgd2F5
IG9mIGhvdyB0aGUNCj4gc2VydmljZSBwb2xpY3kgbW9kZWwgaXMgZ2VuZXJhdGVkLCBzaW5j
ZSBpdCBncm91cHMgYW5kIGl0IHVuaWZpZXMgYW5kIHNoYXJlcw0KPiB0aGUgc2ltaWxhciBy
ZXF1aXJlbWVudHMgaW1wb3NlZCBieSBhIGJ1bGsgb2YgYXBwbGljYXRpb25zLg0KPg0KPg0K
Pg0KPg0KPg0KPg0KPg0KPiAoMikgdHJhbnNwb3J0aW5nIG1vZGVsIGluc3RhbmNlcyBlaXRo
ZXIgdXNpbmcgTkVUQ09ORiBvciBSRVNUQ09ORiBhbmQgKDMpDQo+IHByb3ZpZGluZyBndWlk
ZWxpbmVzIG9uIEFVVE9NQVRJQ0FMTFkgbWFwcGluZyBwb2xpY2llcyB0byBhdHRyaWJ1dGVz
IG9mIHRoZQ0KPiBuZXR3b3JrIGdyYXBocy4NCj4NCj4gQWx0aG91Z2ggc29tZSBJRVRGIHdv
cmtpbmcgZ3JvdXBzIGhhdmUgc3RhcnRlZCB3b3JrIHJlbGF0aW5nIHRvIHRoZQ0KPiBkZXNj
cmlwdGlvbiBvZiB2YXJpb3VzIHRvcG9sb2dpZXMgc3VjaCBhcyBJMlJTIChMM2FuZCByb3V0
aW5nIHRvcG9sb2dpZXMpLA0KPiBBTFRPIChjb3N0IG1hcHMpLCBTRkMgKHNlcnZpY2UgY2hh
aW4pLCBub25lIG9mIHRoZXNlIGdyb3VwcyBhaW0gYXQgb2ZmZXJpbmcNCj4gdHJ1bHkgZ2Vu
ZXJpYyB0b3BvbG9neSBtb2RlbHMgZm9yIHRoZSBzdGFuZGFyZCBub3J0aGJvdW5kIGludGVy
ZmFjZS4NCj4gU1VQQSB3aWxsIHdvcmsgb24gZGVmaW5pbmcgaW50ZXJmYWNlcyBiYXNlZCBv
biB0aGUgY29uY2VwdCBvZiBuZXR3b3JrIGdyYXBoLA0KPiBhbiBlbnRpdHkgZGVzY3JpYmlu
ZyBhbiBhcmJpdHJhcnkgdG9wb2xvZ3kgb2Ygbm9kZXMgYW5kIGxpbmtzIGF0IGFueSBsZXZl
bCBvZg0KPiBncmFudWxhcml0eS4gU3VjaCBhIGdyYXBoIG1heSBkZXNjcmliZSwgZm9yIGV4
YW1wbGUsIGEgcGh5c2ljYWwgdG9wb2xvZ3ksIGENCj4gc2VydmljZSB0b3BvbG9neSBvciB0
aGUgcmVsYXRpb25zaGlwcyBiZXR3ZWVuIGRhdGFjZW50ZXJzLiBBbnkgbmV0d29yaw0KPiB0
b3BvbG9neSBkYXRhIG1vZGVscyBvciBwb2xpY3kgbW9kZWxzIHRoYXQgaGF2ZSBiZWVuIGRl
ZmluZWQgKG9yIGFyZSBiZWluZw0KPiBkZWZpbmVkKSB3aXRoaW4gdGhlIElFVEYgd2lsbCBi
ZSByZXVzZWQgaW4gU1VQQSBhcyBtdWNoIGFzIHBvc3NpYmxlLg0KPiBJbiBhZGRpdGlvbiB0
byB0aGUgYWJvdmUsIHBvbGljaWVzIG1heSBiZSBkZWZpbmVkIGFuZCBhcHBsaWVkIHRvIGEg
bmV0d29yaw0KPiBncmFwaC4gVGhlc2UgYXBwbGljYXRpb24gYmFzZWQgcG9saWNpZXMgYXJl
IGFjdGlvbnMgb3IgY29uc3RyYWludHMgZ2VuZXJhdGVkDQo+IGJ5IE5ldHdvcmsgU2Vydmlj
ZSBTeXN0ZW1zLiBUaGV5IGFyZSB0aGVuIG1hcHBlZCBmcm9tIHRoZSBuZXR3b3JrIGdyYXBo
DQo+IGluc3RhbmNlIGludG8gc3BlY2lmaWMgbmV0d29yayBtYW5hZ2VtZW50IHBvbGljaWVz
IHRvd2FyZCBuZXR3b3JrIGNvbXBvbmVudHMuDQo+DQo+DQo+IEdlb3JnaW9zOiB0aGUgYWJv
dmUgdGV4dCBpcyBub3QgY2xlYXIuIFRoZXJlZm9yZSwgSSBhbSByZXBocmFzaW5nIGl0Og0K
PiA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCj4gVGhl
IG1haW4gZ29hbCBvZiBTVVBBIGlzIHRvIHByb3ZpZGUgYXBwbGljYXRpb24gYmFzZWQgcG9s
aWNpZXMgYW5kIG1lYW5zIHRvDQo+IG1vZGVsIGFuZCBwcm9ncmFtIHRoZSBhYnN0cmFjdCB2
aWV3IG9mIG5ldHdvcmsgaW5mcmFzdHJ1Y3R1cmUgYW5kIHNlcnZpY2UNCj4gZnVuY3Rpb24g
aW50ZXJkZXBlbmRlbmNpZXMgaW4gb3JkZXIgdG8gc3VwcG9ydCBhbmQgQVVUT01BVElDQUxM
WSBmZWVkIG5ldHdvcmsNCj4gbWFuYWdlbWVudCBhbmQgY29udHJvbGxpbmcgcG9saWNpZXMu
IFRoaXMgY2FuIGJlIHJlYWxpemVkIGJ5Og0KPg0KPiAoMSkgbW9kZWxpbmcgdGhlIG5ldHdv
cmsgZ3JhcGgsIHdoaWNoIGFtb25nIG90aGVycyBpbmNsdWRlIHBvbGljeSBtb2RlbHMsIGRh
dGENCj4gbW9kZWxzIGFuZCBhcHBsaWNhdGlvbiBiYXNlZCBwb2xpY2llcywgdXNpbmcgWUFO
RywNCj4NCj4gKDIpIGFwcGx5aW5nIE5FVENPTkYgKG9yIFJFU1RDT05GKSB0byBlbmFibGUg
ZGlzc2VtaW5hdGlvbiBvZiB1cCB0byBkYXRlDQo+IChmcmVzaCkgbmV0d29yayBncmFwaHMg
aW4gYSBzZWN1cmUgYW5kIGVmZmljaWVudCBtYW5uZXIgYmV0d2VlbiBuZXR3b3JrDQo+IHNl
cnZpY2Ugc3lzdGVtcyBhbmQgbmV0d29yayBtYW5hZ2VtZW50IGFuZCBjb250cm9sbGluZyBz
eXN0ZW1zLCAiYmV0d2Vlbg0KPiBuZXR3b3JrIHNlcnZpY2Ugc3lzdGVtcyBhbmQgbmV0d29y
ayBtYW5hZ2VtZW50IGFuZCBjb250cm9sbGluZyBzeXN0ZW0iLiBXaGF0DQo+IGFyZSB0aG9z
ZT8gSSBkb24ndCBzZWUgdGhlbSBpbiB5b3VyIGZpZ3VyZS4NCj4gQWxzbywgd2h5IHNob3Vs
ZCBhbGwgb2YgdGhlc2UgbmVlZCB0byBrbm93IGFib3V0IHRoZSB0b3BvbG9neT8NCj4NCj4g
R2Vvcmdpb3M6IEluIHRoZSBmaWd1cmUsIHRoZSBlbmhhbmNlZCBPU1MgcmVwcmVzZW50cyB0
aGUgbmV0d29yayBzZXJ2aWNlDQo+IHN5c3RlbSBhbmQgdGhlIGNvbnRyb2xsZXIgcmVwcmVz
ZW50cyB0aGUgbmV0d29yayBtYW5hZ2VtZW50IGFuZCBjb250cm9sbGluZw0KPiBzeXN0ZW0u
DQo+IEluIHRoaXMgY29udGV4dCwgbmV0d29yayBzZXJ2aWNlcyBjYW4gYmUgdXNlZCB0byBw
cm92aWRlIHRoZQ0KPiByZXF1aXJlZCAgY29uZmlndXJhdGlvbiBhbmQgYXBwbGljYXRpb24g
cHJvZ3JhbW1pbmcgaW50ZXJmYWNlcyB0byBzZXJ2aWNlDQo+IGRldmVsb3BlcnMuIFN1YnNl
cXVlbnRseSwgYSBuZXR3b3JrIHNlcnZpY2UgY2FuIHVzZSB0aGUgYXBwbGljYXRpb24gYmFz
ZWQNCj4gZGVtYW5kcyAoZm9yIGFjdGlvbnMgYW5kIGNvbnN0cmFpbnRzKSBhbmQgcG9zc2li
bHkgdXBkYXRlIGl0cyBhc3NvY2lhdGVkDQo+IG5ldHdvcmsgc2VydmljZSAgYXR0cmlidXRl
cy4gRXhhbXBsZXMgb2YgbmV0d29yayBzZXJ2aWNlcyB0aGF0IGNhbiBtb2RpZnkgIHRoZQ0K
PiBuZXR3b3JrIHNlcnZpY2UgYXR0cmlidXRlcyBhcmUgZm9yIGV4YW1wbGUsIEwzVlBOIGNv
bmZpZ3VyYXRpb24gYW5kIElQdjYNCj4gdHJhbnNpdGlvbnMuDQo+IEZvciBlYWNoIG5ldHdv
cmsgc2VydmljZSBpbnN0YW5jZSBhIG5ldHdvcmsgZ3JhcGggbmVlZHMgdG8gYmUgZ2VuZXJh
dGVkIGFuZA0KPiBtYWludGFpbmVkLg0KPiBUaGUgdXAgdG8gZGF0ZSBuZXR3b3JrIGdyYXBo
IG5lZWRzIHRvICgxKSBiZSBjb21tdW5pY2F0ZWQgYmV0d2VlbiB0aGUgIG5ldHdvcmsNCj4g
c2VydmljZSBzeXN0ZW1zIGFuZCB0aGUgbmV0d29yayAgIG1hbmFnZW1lbnQgYW5kIGNvbnRy
b2xsaW5nIHN5c3RlbXMsICgyKSBtYXANCj4gdGhlIGF0dHJpYnV0ZXMgb2YgdGhlIG5ldHdv
cmsgc2VydmljZSBncmFwaCBpbnRvIHNwZWNpZmljIG5ldHdvcmsgbWFuYWdlbWVudA0KPiBw
b2xpY2llcy4NCj4gW1dpbGxdIFRvIG1vZGVsaW5nIHNlcnZpY2UgcmVxdWlyZW1lbnQgYW5k
IGNyZWF0ZSBzZXJ2aWNlIGluc3RhbmNlcywgQVBQIG5lZWRzDQo+IGEgdmlldyBvZiB0b3Bv
bG9neSB0byBmb3JtIG5ldHdvcmsgY29uZmlndXJhdGlvbiBhY2NvcmRpbmcgdG8gdGhlIGtl
eQ0KPiBpbmZvcm1hdGlvbiBvZiBkZXZpY2VzIHRvcG9sb2d5LiBUaGlzIGNvbmZpZ3VyYXRp
b24gaXMgZXZlbnR1YWxseSBtYXBwZWQgdG8NCj4gdGhlIHNlbGVjdGVkIG5ldHdvcmsgZGV2
aWNlcyBhY2NvcmRpbmcgdG8gdG9wb2xvZ3kgcHJvdmlkZWQgYnkgU1VQQS4NCj4NCj4gQmVz
dCByZWdhcmRzLA0KPiBHZW9yZ2lvcw0KPg0KPg0KPg0KPg0KPg0KPiBSZWdhcmRzLCBCZW5v
aXQNCj4g5aaC5p6c5oKo6ZSZ6K+v5o6l5pS25LqG6K+l6YKu5Lu277yM6K+36YCa6L+H55S1
5a2Q6YKu5Lu256uL5Y2z6YCa55+l5oiR5Lus44CC6K+35Zue5aSN6YKu5Lu25YiwaHFzLQ0K
PiBzcG1jQGNoaW5hdW5pY29tLmNu77yM5Y2z5Y+v5Lul6YCA6K6i5q2k6YKu5Lu244CC5oiR
5Lus5bCG56uL5Y2z5bCG5oKo55qE5L+h5oGv5LuO5oiR5Lus55qE5Y+R6YCB55uu5b2V5Lit
5Yig6Zmk44CCDQo+IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3Ig
cGxlYXNlIG5vdGlmeSB1cyBpbW1lZGlhdGVseSBieSBlLQ0KPiBtYWlsLiBQbGVhc2UgcmVw
bHkgdG8gaHFzLXNwbWNAY2hpbmF1bmljb20uY24gaWYgeW91IHdhbnQgdG8gdW5zdWJzY3Jp
YmUgZnJvbQ0KPiB0aGlzIG1haWwuIFdlIHdpbGwgaW1tZWRpYXRlbHkgcmVtb3ZlIHlvdXIg
aW5mb3JtYXRpb24gZnJvbSBvdXIgc2VuZGluZw0KPiBjYXRhbG9ndWUuDQoNCuWmguaenOaC
qOmUmeivr+aOpeaUtuS6huivpemCruS7tu+8jOivt+mAmui/h+eUteWtkOmCruS7tueri+WN
s+mAmuefpeaIkeS7rOOAguivt+WbnuWkjemCruS7tuWIsGhxcy1zcG1jQGNoaW5hdW5pY29t
LmNu77yM5Y2z5Y+v5Lul6YCA6K6i5q2k6YKu5Lu244CC5oiR5Lus5bCG56uL5Y2z5bCG5oKo
55qE5L+h5oGv5LuO5oiR5Lus55qE5Y+R6YCB55uu5b2V5Lit5Yig6Zmk44CCDQpJZiB5b3Ug
aGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdXMgaW1t
ZWRpYXRlbHkgYnkgZS1tYWlsLiBQbGVhc2UgcmVwbHkgdG8gaHFzLXNwbWNAY2hpbmF1bmlj
b20uY24gaWYgeW91IHdhbnQgdG8gdW5zdWJzY3JpYmUgZnJvbSB0aGlzIG1haWwuIFdlIHdp
bGwgaW1tZWRpYXRlbHkgcmVtb3ZlIHlvdXIgaW5mb3JtYXRpb24gZnJvbSBvdXIgc2VuZGlu
ZyBjYXRhbG9ndWUuDQo=

--=====003_Dragon221042328062_=====
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0
aW9uYWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBj
aGFyc2V0PXV0Zi04IiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxNRVRBIG5hbWU9R0VO
RVJBVE9SIGNvbnRlbnQ9Ik1TSFRNTCA4LjAwLjc2MDEuMTc1MTQiPg0KPFNUWUxFPkBmb250
LWZhY2Ugew0KCWZvbnQtZmFtaWx5OiDlrovkvZM7DQp9DQpAZm9udC1mYWNlIHsNCglmb250
LWZhbWlseTogVmVyZGFuYTsNCn0NCkBmb250LWZhY2Ugew0KCWZvbnQtZmFtaWx5OiBA5a6L
5L2TOw0KfQ0KQHBhZ2UgU2VjdGlvbjEge3NpemU6IDU5NS4zcHQgODQxLjlwdDsgbWFyZ2lu
OiA3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7IGxheW91dC1ncmlkOiAxNS42cHQ7IH0N
ClAuTXNvTm9ybWFsIHsNCglURVhULUpVU1RJRlk6IGludGVyLWlkZW9ncmFwaDsgVEVYVC1B
TElHTjoganVzdGlmeTsgTUFSR0lOOiAwY20gMGNtIDBwdDsgRk9OVC1GQU1JTFk6ICJUaW1l
cyBOZXcgUm9tYW4iOyBGT05ULVNJWkU6IDEwLjVwdA0KfQ0KTEkuTXNvTm9ybWFsIHsNCglU
RVhULUpVU1RJRlk6IGludGVyLWlkZW9ncmFwaDsgVEVYVC1BTElHTjoganVzdGlmeTsgTUFS
R0lOOiAwY20gMGNtIDBwdDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9tYW4iOyBGT05U
LVNJWkU6IDEwLjVwdA0KfQ0KRElWLk1zb05vcm1hbCB7DQoJVEVYVC1KVVNUSUZZOiBpbnRl
ci1pZGVvZ3JhcGg7IFRFWFQtQUxJR046IGp1c3RpZnk7IE1BUkdJTjogMGNtIDBjbSAwcHQ7
IEZPTlQtRkFNSUxZOiAiVGltZXMgTmV3IFJvbWFuIjsgRk9OVC1TSVpFOiAxMC41cHQNCn0N
CkE6bGluayB7DQoJQ09MT1I6IGJsdWU7IFRFWFQtREVDT1JBVElPTjogdW5kZXJsaW5lDQp9
DQpTUEFOLk1zb0h5cGVybGluayB7DQoJQ09MT1I6IGJsdWU7IFRFWFQtREVDT1JBVElPTjog
dW5kZXJsaW5lDQp9DQpBOnZpc2l0ZWQgew0KCUNPTE9SOiBwdXJwbGU7IFRFWFQtREVDT1JB
VElPTjogdW5kZXJsaW5lDQp9DQpTUEFOLk1zb0h5cGVybGlua0ZvbGxvd2VkIHsNCglDT0xP
UjogcHVycGxlOyBURVhULURFQ09SQVRJT046IHVuZGVybGluZQ0KfQ0KU1BBTi5FbWFpbFN0
eWxlMTcgew0KCUZPTlQtU1RZTEU6IG5vcm1hbDsgRk9OVC1GQU1JTFk6IFZlcmRhbmE7IENP
TE9SOiB3aW5kb3d0ZXh0OyBGT05ULVdFSUdIVDogbm9ybWFsOyBURVhULURFQ09SQVRJT046
IG5vbmU7IG1zby1zdHlsZS10eXBlOiBwZXJzb25hbC1jb21wb3NlDQp9DQpESVYuU2VjdGlv
bjEgew0KCXBhZ2U6IFNlY3Rpb24xDQp9DQpVTktOT1dOIHsNCglGT05ULVNJWkU6IDEwcHQN
Cn0NCkJMT0NLUVVPVEUgew0KCU1BUkdJTi1UT1A6IDBweDsgTUFSR0lOLUJPVFRPTTogMHB4
OyBNQVJHSU4tTEVGVDogMmVtDQp9DQpPTCB7DQoJTUFSR0lOLVRPUDogMHB4OyBNQVJHSU4t
Qk9UVE9NOiAwcHgNCn0NClVMIHsNCglNQVJHSU4tVE9QOiAwcHg7IE1BUkdJTi1CT1RUT006
IDBweA0KfQ0KPC9TVFlMRT4NCjwvSEVBRD4NCjxCT0RZIHN0eWxlPSJNQVJHSU46IDEwcHg7
IEZPTlQtRkFNSUxZOiB2ZXJkYW5hOyBGT05ULVNJWkU6IDEwcHQiPg0KPERJVj48Rk9OVCBj
b2xvcj0jMDAwMDgwIHNpemU9MiBmYWNlPVZlcmRhbmE+SGkgR2Vvcmdpb3MsPC9GT05UPjwv
RElWPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMDgwPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxE
SVY+PEZPTlQgY29sb3I9IzAwMDA4MD5UaGFua3MgZm9yIHlvdXIgcXVpY2sgZXhwbGFpbmF0
aW9uLiBJdCBpcyBjbGVhciBmb3IgDQptZS48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGNv
bG9yPSMwMDAwODA+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAw
MDgwPkJSLDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgY29sb3I9IzAwMDA4MD5ZaW5nPC9G
T05UPjwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMDgwIHNpemU9MiBmYWNlPVZlcmRh
bmE+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMDgwIHNpemU9
MiBmYWNlPVZlcmRhbmE+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0j
YzBjMGMwIHNpemU9MiBmYWNlPVZlcmRhbmE+MjAxNC0wOS0yNiA8L0ZPTlQ+PC9ESVY+PEZP
TlQgDQpjb2xvcj0jMDAwMDgwIHNpemU9MiBmYWNlPVZlcmRhbmE+DQo8SFIgc3R5bGU9IldJ
RFRIOiAxMDBweCIgYWxpZ249bGVmdCBjb2xvcj0jYjVjNGRmIFNJWkU9MT4NCjwvRk9OVD4N
CjxESVY+PEZPTlQgY29sb3I9I2MwYzBjMCBzaXplPTIgZmFjZT1WZXJkYW5hPjxTUEFOPg0K
PERJVj5ZaW5nIENIRU5HJm5ic3A7IOeoi+iOuTxCUj5DaGluYSBVbmljb20gTmV0d29yayBU
ZWNobm9sb2d5IFJlc2VhcmNoIEluc3RpdHV0ZSANCuS4reWbveiBlOmAmue9kee7nOaKgOac
r+eglOeptumZojxCUj5UZWw6ICs4Ni0xMC02ODc5OTk5OS03NzAyPEJSPk1vYmlsZTogDQor
ODYtMTg2MDExMDI5NzE8QlI+PEJSPjwvRElWPjwvU1BBTj48L0ZPTlQ+PC9ESVY+DQo8SFIg
Y29sb3I9I2I1YzRkZiBTSVpFPTE+DQoNCjxESVY+PEZPTlQgc2l6ZT0yIGZhY2U9VmVyZGFu
YT48U1RST05HPuWPkeS7tuS6uu+8mjwvU1RST05HPiBHZW9yZ2lvcyBLYXJhZ2lhbm5pcyAN
CjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yIGZhY2U9VmVyZGFuYT48U1RST05H
PuWPkemAgeaXtumXtO+8mjwvU1RST05HPiAyMDE0LTA5LTI2Jm5ic3A7IDEzOjAyOjE3IA0K
PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTIgZmFjZT1WZXJkYW5hPjxTVFJPTkc+
5pS25Lu25Lq677yaPC9TVFJPTkc+IFlpbmcgQ2hlbmco6IGU6YCa6ZuG5Zui6IGU6YCa572R
57uc5oqA5pyv56CU56m26ZmiKSANCjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0y
IGZhY2U9VmVyZGFuYT48U1RST05HPuaKhOmAge+8mjwvU1RST05HPiBCZW5vaXQgQ2xhaXNl
OyBUaW5hIFRTT1U7IA0Kc3VwYSA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9MiBm
YWNlPVZlcmRhbmE+PFNUUk9ORz7kuLvpopjvvJo8L1NUUk9ORz4gUkU6IFtTdXBhXSBEcmFm
dCBjaGFydGVyIA0KdjEuMTIvL1JFOiBBcmVhIGhhbmQtb2ZmLCBhbmQgc29tZWZyaWVuZGx5
YWR2aWNlIC4uLiA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9MiBmYWNlPVZlcmRh
bmE+PC9GT05UPiA8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yIGZhY2U9VmVyZGFuYT4NCjxE
SVY+SGkmbmJzcDtZaW5nLDwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+VGhhbmtzJm5ic3A7
Zm9yJm5ic3A7eW91ciZuYnNwO2NvbW1lbnRzITwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+
UGxlYXNlJm5ic3A7c2VlJm5ic3A7aW4mbmJzcDtsaW5lLjwvRElWPg0KPERJVj48L0RJVj4N
CjxESVY+PC9ESVY+DQo8RElWPiZndDsmbmJzcDstLS0tLU9yaWdpbmFsJm5ic3A7TWVzc2Fn
ZS0tLS0tPC9ESVY+DQo8RElWPiZndDsmbmJzcDtGcm9tOiZuYnNwO0dlb3JnaW9zJm5ic3A7
S2FyYWdpYW5uaXM8L0RJVj4NCjxESVY+Jmd0OyZuYnNwO1NlbnQ6Jm5ic3A7RnJpZGF5LCZu
YnNwO1NlcHRlbWJlciZuYnNwOzI2LCZuYnNwOzIwMTQmbmJzcDs1OjUyJm5ic3A7QU08L0RJ
Vj4NCjxESVY+Jmd0OyZuYnNwO1RvOiZuYnNwO0dlb3JnaW9zJm5ic3A7S2FyYWdpYW5uaXM8
L0RJVj4NCjxESVY+Jmd0OyZuYnNwO1N1YmplY3Q6Jm5ic3A7UkU6Jm5ic3A7W1N1cGFdJm5i
c3A7RHJhZnQmbmJzcDtjaGFydGVyJm5ic3A7djEuMTIvL1JFOiZuYnNwO0FyZWEmbmJzcDto
YW5kLW9mZiwmbmJzcDthbmQmbmJzcDtzb21lPC9ESVY+DQo8RElWPiZndDsmbmJzcDtmcmll
bmRseWFkdmljZSZuYnNwOy4uLjwvRElWPg0KPERJVj4mZ3Q7PC9ESVY+DQo8RElWPiZndDsm
bmJzcDtGcm9tOiZuYnNwO1N1cGEmbmJzcDtbbWFpbHRvOnN1cGEtYm91bmNlc0BpZXRmLm9y
Z10mbmJzcDtPbiZuYnNwO0JlaGFsZiZuYnNwO09mJm5ic3A7WWluZyZuYnNwO0NoZW5nPC9E
SVY+DQo8RElWPiZndDsmbmJzcDtTZW50OiZuYnNwO0ZyaWRheSwmbmJzcDtTZXB0ZW1iZXIm
bmJzcDsyNiwmbmJzcDsyMDE0Jm5ic3A7NTo0NSZuYnNwO0FNPC9ESVY+DQo8RElWPiZndDsm
bmJzcDtUbzombmJzcDtzdXBhPC9ESVY+DQo8RElWPiZndDsmbmJzcDtDYzombmJzcDtCZW5v
aXQmbmJzcDtDbGFpc2U7Jm5ic3A7VGluYSZuYnNwO1RTT1U8L0RJVj4NCjxESVY+Jmd0OyZu
YnNwO1N1YmplY3Q6Jm5ic3A7UmU6Jm5ic3A7W1N1cGFdJm5ic3A7RHJhZnQmbmJzcDtjaGFy
dGVyJm5ic3A7djEuMTIvL1JFOiZuYnNwO0FyZWEmbmJzcDtoYW5kLW9mZiwmbmJzcDthbmQm
bmJzcDtzb21lPC9ESVY+DQo8RElWPiZndDsmbmJzcDtmcmllbmRseWFkdmljZSZuYnNwOy4u
LjwvRElWPg0KPERJVj4mZ3Q7PC9ESVY+DQo8RElWPiZndDsmbmJzcDtIaSZuYnNwO2FsbCw8
L0RJVj4NCjxESVY+Jmd0OzwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7SSZuYnNwO2F0dGVuZGVk
Jm5ic3A7dGhlJm5ic3A7ZS1tZWV0aW5nJm5ic3A7bGFzdCZuYnNwO25pZ2h0Jm5ic3A7YW5k
Jm5ic3A7bGVhcm5lZCZuYnNwO2EmbmJzcDtsb3QuJm5ic3A7VGhhbmsmbmJzcDt5b3UmbmJz
cDtmb3ImbmJzcDt5b3VyPC9ESVY+DQo8RElWPiZndDsmbmJzcDtlZmZvcnRzLiZuYnNwO1Ro
ZSZuYnNwO2xhdGVzdCZuYnNwO2NoYXJ0ZXImbmJzcDtpcyZuYnNwO25vdyZuYnNwO2NsZWFy
ZXImbmJzcDthbmQmbmJzcDtmaW5lJm5ic3A7ZnJvbSZuYnNwO215Jm5ic3A7c2lkZS4mbmJz
cDtMYXRlciZuYnNwO0kmbmJzcDtwbGFuPC9ESVY+DQo8RElWPiZndDsmbmJzcDt0byZuYnNw
O3VwZGF0ZSZuYnNwO3RoZSZuYnNwO0REQyZuYnNwO3VzZSZuYnNwO2Nhc2UmbmJzcDthY2Nv
cmRpbmdseS48L0RJVj4NCjxESVY+Jmd0OzwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7U29tZSZu
YnNwO3F1aWNrJm5ic3A7Y29tbWVudHM6PC9ESVY+DQo8RElWPiZndDs8L0RJVj4NCjxESVY+
Jmd0OyZuYnNwO1NvbWUmbmJzcDtJRVRGJm5ic3A7d29ya2luZyZuYnNwO2dyb3VwcyZuYnNw
O2hhdmUmbmJzcDtzdGFydGVkJm5ic3A7d29yayZuYnNwO3JlbGF0aW5nJm5ic3A7dG8mbmJz
cDt0aGUmbmJzcDtkZXNjcmlwdGlvbiZuYnNwO29mPC9ESVY+DQo8RElWPiZndDsmbmJzcDt2
YXJpb3VzJm5ic3A7dG9wb2xvZ2llcyZuYnNwO3N1Y2gmbmJzcDthcyZuYnNwO0kyUlMmbmJz
cDsoTDMmbmJzcDthbmQmbmJzcDtyb3V0aW5nJm5ic3A7dG9wb2xvZ2llcyksJm5ic3A7QUxU
TyZuYnNwOyhjb3N0Jm5ic3A7bWFwcyksPC9ESVY+DQo8RElWPiZndDsmbmJzcDtTRkMmbmJz
cDsoc2VydmljZSZuYnNwO2NoYWluKSwmbmJzcDtub25lJm5ic3A7b2YmbmJzcDt0aGVzZSZu
YnNwO2dyb3VwcyZuYnNwO2FpbSZuYnNwOygxKSZuYnNwO2F0Jm5ic3A7b2ZmZXJpbmcmbmJz
cDt0cnVseSZuYnNwO2dlbmVyaWM8L0RJVj4NCjxESVY+Jmd0OyZuYnNwO3RvcG9sb2d5Jm5i
c3A7bW9kZWxzJm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7c3RhbmRhcmQmbmJzcDtub3J0aGJv
dW5kJm5ic3A7aW50ZXJmYWNlLCZuYnNwO2FuZCZuYnNwOygyKSZuYnNwO3RoYXQmbmJzcDth
bjwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7YXBwbGljYXRpb24mbmJzcDtjYW4mbmJzcDtjb21t
dW5pY2F0ZSZuYnNwO3dpdGgmbmJzcDtuZXR3b3JrJm5ic3A7Ym94ZXMsJm5ic3A7c3VjaCZu
YnNwO2FzJm5ic3A7bmV0d29yayZuYnNwO2NvbnRyb2xsZXJzLDwvRElWPg0KPERJVj4mZ3Q7
Jm5ic3A7YW5kJm5ic3A7TkVzLCZuYnNwO2RldmVsb3BlZCZuYnNwO2J5Jm5ic3A7ZGlmZmVy
ZW50Jm5ic3A7dmVuZG9ycy48L0RJVj4NCjxESVY+Jmd0OzwvRElWPg0KPERJVj4mZ3Q7Jm5i
c3A7SGVyZSZuYnNwO2RvJm5ic3A7eW91Jm5ic3A7bWVhbiZuYnNwO3Rob3NlJm5ic3A7d29y
a2luZyZuYnNwO2dyb3VwJm5ic3A7ZGlkbuKAmXQmbmJzcDtkbyZuYnNwO3lvdXImbmJzcDso
MikuJm5ic3A7SWYmbmJzcDtubywmbmJzcDtJJm5ic3A7Z3Vlc3MmbmJzcDt5b3U8L0RJVj4N
CjxESVY+Jmd0OyZuYnNwO3Nob3VsZCZuYnNwO3VzZSZuYnNwO+KAnG5laXRoZXLigJ0mbmJz
cDtpbnN0ZWFkLjwvRElWPg0KPERJVj5bJmd0O108L0RJVj4NCjxESVY+PC9ESVY+DQo8RElW
Pkdlb3JnaW9zOiZuYnNwO1dlJm5ic3A7bWVhbiZuYnNwO3RoYXQmbmJzcDt0aG9zZSZuYnNw
O3dvcmtpbmcmbmJzcDtncm91cHMmbmJzcDtkaWQmbmJzcDtub3QmbmJzcDtkbyZuYnNwOygx
KSZuYnNwO2FuZCZuYnNwOygyKS48L0RJVj4NCjxESVY+RG8mbmJzcDt3ZSZuYnNwO25lZWQm
bmJzcDt0byZuYnNwO2NoYW5nZSZuYnNwO3RoZSZuYnNwO3dvcmRpbmc/PC9ESVY+DQo8RElW
PjwvRElWPg0KPERJVj4mZ3Q7PC9ESVY+DQo8RElWPiZndDsmbmJzcDtJbiZuYnNwO2FkZGl0
aW9uLCZuYnNwO2dpdmVuJm5ic3A7dGhhdCZuYnNwO3RoZXJlJm5ic3A7d2VyZSZuYnNwO3Nv
bWUmbmJzcDtkaXNjdXNzaW9ucyZuYnNwO3JlbGF0ZWQmbmJzcDt0byZuYnNwO2VuZCZuYnNw
O3VzZXImbmJzcDthcHA8L0RJVj4NCjxESVY+Jmd0OyZuYnNwO2FuZCZuYnNwO21hbmFnZW1l
bnQmbmJzcDthcHAuJm5ic3A7WW91Jm5ic3A7bWlnaHQmbmJzcDt3YW50Jm5ic3A7dG8mbmJz
cDtzcGVjaWZ5Jm5ic3A7dGhlJm5ic3A7YXBwJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7c2Vu
dGVuY2UmbmJzcDt0bzwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7ZWxpbWluYXRlJm5ic3A7Y29u
ZnVzaW9uLjwvRElWPg0KPERJVj5bJmd0O108L0RJVj4NCjxESVY+PC9ESVY+DQo8RElWPjwv
RElWPg0KPERJVj5HZW9yZ2lvczombmJzcDsiQXBwbGljYXRpb25zIiZuYnNwO3JlcHJlc2Vu
dCZuYnNwO2FuJm5ic3A7ZW50aXR5Jm5ic3A7dGhhdCZuYnNwO2dlbmVyYXRlcyZuYnNwO2Fu
ZCZuYnNwO21haW50YWlucyZuYnNwO25ldHdvcmsmbmJzcDtzZXJ2aWNlcyZuYnNwO2FuZCZu
YnNwO2lzJm5ic3A7YWRtaW5pc3RyYXRlZCZuYnNwO2J5Jm5ic3A7YSZuYnNwO2NvbW11bmlj
YXRpb24mbmJzcDtzZXJ2aWNlJm5ic3A7cHJvdmlkZXIuPC9ESVY+DQo8RElWPjwvRElWPg0K
PERJVj4mZ3Q7PC9ESVY+DQo8RElWPiZndDsmbmJzcDtPbmUmbmJzcDttb3JlJm5ic3A7Y29t
bWVudCwmbmJzcDtJJm5ic3A7c2F3Jm5ic3A7eW91Jm5ic3A7YWRkJm5ic3A7dGhlJm5ic3A7
dGVybSZuYnNwO+KAnWludGVyb3BlcmFibGUmbmJzcDttYW5uZXLigJ0mbmJzcDtpbiZuYnNw
O3NldmVyYWw8L0RJVj4NCjxESVY+Jmd0OyZuYnNwO3BsYWNlcy4mbmJzcDtDb3VsZCZuYnNw
O3lvdSZuYnNwO3BsZWFzZSZuYnNwO2VsYWJvcmF0ZT88L0RJVj4NCjxESVY+WyZndDtdPC9E
SVY+DQo8RElWPjwvRElWPg0KPERJVj5HZW9yZ2lvczombmJzcDt0aGUmbmJzcDtpbnRlcm9w
ZXJhYmxlJm5ic3A7bWFubmVyJm5ic3A7cmVsYXRlcyZuYnNwO3RvOiZuYnNwO3JlcXVpcmVt
ZW50Jm5ic3A7dGhhdCZuYnNwO2FwcGxpY2F0aW9ucyZuYnNwO3Nob3VsZCZuYnNwO2JlJm5i
c3A7YWJsZSZuYnNwO3RvJm5ic3A7Y29tbXVuaWNhdGUmbmJzcDt3aXRoJm5ic3A7bmV0d29y
ayZuYnNwO2JveGVzLCZuYnNwO3N1Y2gmbmJzcDthcyZuYnNwO25ldHdvcmsmbmJzcDtjb250
cm9sbGVycywmbmJzcDthbmQmbmJzcDtORXMsJm5ic3A7ZGV2ZWxvcGVkJm5ic3A7YnkmbmJz
cDtkaWZmZXJlbnQmbmJzcDt2ZW5kb3JzLjwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+QmVz
dCZuYnNwO3JlZ2FyZHMsPC9ESVY+DQo8RElWPkdlb3JnaW9zPC9ESVY+DQo8RElWPjwvRElW
Pg0KPERJVj4mZ3Q7PC9ESVY+DQo8RElWPiZndDsmbmJzcDtCUiw8L0RJVj4NCjxESVY+Jmd0
OyZuYnNwO1lpbmc8L0RJVj4NCjxESVY+Jmd0OzwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7MjAx
NC0wOS0yNjwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7X19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXzwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7WWluZyZuYnNwO0NIRU5H
Jm5ic3A7Jm5ic3A756iL6I65PC9ESVY+DQo8RElWPiZndDsmbmJzcDtDaGluYSZuYnNwO1Vu
aWNvbSZuYnNwO05ldHdvcmsmbmJzcDtUZWNobm9sb2d5Jm5ic3A7UmVzZWFyY2gmbmJzcDtJ
bnN0aXR1dGUmbmJzcDvkuK3lm73ogZTpgJrnvZHnu5zmioDmnK/noJTnqbbpmaI8L0RJVj4N
CjxESVY+Jmd0OyZuYnNwO1RlbDombmJzcDsrODYtMTAtNjg3OTk5OTktNzcwMjwvRElWPg0K
PERJVj4mZ3Q7Jm5ic3A7TW9iaWxlOiZuYnNwOys4Ni0xODYwMTEwMjk3MTwvRElWPg0KPERJ
Vj4mZ3Q7Jm5ic3A7X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwv
RElWPg0KPERJVj4mZ3Q7Jm5ic3A75Y+R5Lu25Lq677yaJm5ic3A7VGluYSZuYnNwO1RTT1U8
L0RJVj4NCjxESVY+Jmd0OyZuYnNwO+WPkemAgeaXtumXtO+8miZuYnNwOzIwMTQtMDktMjYm
bmJzcDsmbmJzcDswODo1Mzo0NzwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A75pS25Lu25Lq677ya
Jm5ic3A7QmVub2l0Jm5ic3A7Q2xhaXNlPC9ESVY+DQo8RElWPiZndDsmbmJzcDvmioTpgIHv
vJombmJzcDtzdXBhQGlldGYub3JnPC9ESVY+DQo8RElWPiZndDsmbmJzcDvkuLvpopjvvJom
bmJzcDtbU3VwYV0mbmJzcDtEcmFmdCZuYnNwO2NoYXJ0ZXImbmJzcDt2MS4xMi8vUkU6Jm5i
c3A7QXJlYSZuYnNwO2hhbmQtb2ZmLCZuYnNwO2FuZCZuYnNwO3NvbWU8L0RJVj4NCjxESVY+
Jmd0OyZuYnNwO2ZyaWVuZGx5YWR2aWNlJm5ic3A7Li4uPC9ESVY+DQo8RElWPiZndDsmbmJz
cDtEZWFyJm5ic3A7QmVub2l0Jm5ic3A7ZXQmbmJzcDthbCw8L0RJVj4NCjxESVY+Jmd0Ozwv
RElWPg0KPERJVj4mZ3Q7Jm5ic3A7SGVyZSZuYnNwO2NvbWVzJm5ic3A7bGF0ZXN0Jm5ic3A7
dmVyc2lvbi4mbmJzcDtUaGUmbmJzcDtsaXN0Jm5ic3A7ZGlzY3Vzc2lvbiZuYnNwO2hlbHBz
Jm5ic3A7YSZuYnNwO2xvdCZuYnNwO3RvJm5ic3A7bWFrZSZuYnNwO2l0Jm5ic3A7Y2xlYXJl
ci48L0RJVj4NCjxESVY+Jmd0OzwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTwvRElWPg0KPERJVj4mZ3Q7
Jm5ic3A7U1VQQSZuYnNwOyhTaGFyZWQmbmJzcDtVbmlmaWVkJm5ic3A7UG9saWN5Jm5ic3A7
QXV0b21hdGlvbikmbmJzcDtjaGFydGVyJm5ic3A7djEuMTImbmJzcDtUYXJnZXQmbmJzcDtB
cmVhOiZuYnNwO09wZXJhdGlvbnM8L0RJVj4NCjxESVY+Jmd0OyZuYnNwO2FuZCZuYnNwO01h
bmFnZW1lbnQ8L0RJVj4NCjxESVY+Jmd0OzwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7RGVzY3Jp
cHRpb24mbmJzcDtvZiZuYnNwO1dvcmtpbmcmbmJzcDtHcm91cDo8L0RJVj4NCjxESVY+Jmd0
OzwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7UHJvZ3JhbW1hdGljJm5ic3A7d2F5cyZuYnNwO3Rv
Jm5ic3A7Y29uZmlndXJlJm5ic3A7bmV0d29ya3MsJm5ic3A7b2Z0ZW4mbmJzcDtjYWxsZWQm
bmJzcDtzb2Z0d2FyZS1kZWZpbmVkLCZuYnNwO2FyZTwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7
Y29uc2lkZXJlZCZuYnNwO2J5Jm5ic3A7bWFueSZuYnNwO25ldHdvcmsmbmJzcDtvcGVyYXRv
cnMmbmJzcDtpbiZuYnNwO29yZGVyJm5ic3A7dG8mbmJzcDtzaGlmdCZuYnNwO3RoZSZuYnNw
O2JhbGFuY2UmbmJzcDtpbiZuYnNwO3RoZWlyPC9ESVY+DQo8RElWPiZndDsmbmJzcDtmYXZv
ci48L0RJVj4NCjxESVY+Jmd0OyZuYnNwO0F1dG9tYXRpbmcmbmJzcDt0aGUmbmJzcDt3YXkm
bmJzcDtvZiZuYnNwO2V4cG9zaW5nJm5ic3A7YSZuYnNwO3ZpZXcmbmJzcDtvZiZuYnNwO3Ro
ZSZuYnNwO25ldHdvcmsmbmJzcDt0byZuYnNwO2FwcGxpY2F0aW9ucyZuYnNwO21heTwvRElW
Pg0KPERJVj4mZ3Q7Jm5ic3A7cHJvdmlkZSZuYnNwO3NpZ25pZmljYW50Jm5ic3A7aW1wcm92
ZW1lbnRzJm5ic3A7aW4mbmJzcDtjb25maWd1cmF0aW9uJm5ic3A7YWdpbGl0eSwmbmJzcDtl
cnJvciZuYnNwO2RldGVjdGlvbiZuYnNwO2FuZDwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7dXB0
aW1lJm5ic3A7Zm9yJm5ic3A7b3BlcmF0b3JzLiZuYnNwO0hvd2V2ZXImbmJzcDt0aGUmbmJz
cDtyZWFsJm5ic3A7dmFsdWUmbmJzcDtiZWhpbmQmbmJzcDtjZW50cmFsJm5ic3A7Y29uZmln
dXJhdGlvbjwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7c2NoZW1lcyZuYnNwO2xpZXMmbmJzcDt3
aXRoaW4mbmJzcDt0aGUmbmJzcDtwb3NzaWJsZSZuYnNwO3NpbXBsaWZpY2F0aW9uJm5ic3A7
dGhyb3VnaCZuYnNwO21vZGVscyZuYnNwO3Byb3ZpZGVkJm5ic3A7Ynk8L0RJVj4NCjxESVY+
Jmd0OyZuYnNwO3N1Y2gmbmJzcDtzeXN0ZW1zJm5ic3A7dG8mbmJzcDthcHBsaWNhdGlvbnMm
bmJzcDthbmQmbmJzcDtuZXR3b3JrJm5ic3A7c2VydmljZXMmbmJzcDtydW5uaW5nJm5ic3A7
YWJvdmUmbmJzcDt0aGVtJm5ic3A7KG9uJm5ic3A7dGhlPC9ESVY+DQo8RElWPiZndDsmbmJz
cDtzby1jYWxsZWQmbmJzcDtub3J0aGJvdW5kJm5ic3A7c2lkZSkuJm5ic3A7V2VsbC1kZXNp
Z25lZCZuYnNwO21vZGVscyZuYnNwO2FyZSZuYnNwO2FibGUmbmJzcDt0byZuYnNwO3Byb3Zp
ZGUmbmJzcDthJm5ic3A7d2lkZTwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7cmFuZ2UmbmJzcDtv
ZiZuYnNwO2dyYW51bGFyaXR5Jm5ic3A7Zm9yJm5ic3A7dmFyaW91cyZuYnNwO2FwcGxpY2F0
aW9ucyZuYnNwO2FuZCZuYnNwO25ldHdvcmsmbmJzcDtzZXJ2aWNlcyZuYnNwO25lZWRzLCZu
YnNwO2Zyb208L0RJVj4NCjxESVY+Jmd0OyZuYnNwO3RoZSZuYnNwO2xvd2VyLWxldmVsJm5i
c3A7cGh5c2ljYWwmbmJzcDtuZXR3b3JrJm5ic3A7dG8mbmJzcDtoaWdoLWxldmVsJm5ic3A7
YXBwbGljYXRpb24mbmJzcDtzZXJ2aWNlcy48L0RJVj4NCjxESVY+Jmd0OyZuYnNwO1NldmVy
YWwmbmJzcDtvcmdhbml6YXRpb25zJm5ic3A7b3V0c2lkZSZuYnNwO29mJm5ic3A7dGhlJm5i
c3A7SUVURiZuYnNwO2hhdmUmbmJzcDtkZWZpbmVkJm5ic3A7dmFyaW91cyZuYnNwO3NjaGVt
ZXMmbmJzcDtmb3ImbmJzcDt0aGU8L0RJVj4NCjxESVY+Jmd0OyZuYnNwO2NvbmZpZ3VyYXRp
b24mbmJzcDtvZiZuYnNwO25ldHdvcmsmbmJzcDtkZXZpY2VzJm5ic3A7YW5kJm5ic3A7c3Bl
Y2lmaWMmbmJzcDtuZXR3b3JrJm5ic3A7Y29udHJvbGxlcnMsJm5ic3A7YnV0Jm5ic3A7bm9u
ZSZuYnNwO29mPC9ESVY+DQo8RElWPiZndDsmbmJzcDt0aGVtJm5ic3A7b2ZmZXImbmJzcDth
Jm5ic3A7dmVuZG9yLW5ldXRyYWwmbmJzcDtzdGFuZGFyZGl6ZWQmbmJzcDt3YXkmbmJzcDtm
b3ImbmJzcDthcHBsaWNhdGlvbnMmbmJzcDthbmQmbmJzcDtuZXR3b3JrPC9ESVY+DQo8RElW
PiZndDsmbmJzcDtzZXJ2aWNlcyZuYnNwO3RvJm5ic3A7dHJhbnNtaXQmbmJzcDt0aGVpciZu
YnNwO25lZWRzJm5ic3A7dG8mbmJzcDtuZXR3b3JrJm5ic3A7Y29udHJvbGxlcnMuJm5ic3A7
VGhlJm5ic3A7U1VQQSZuYnNwOyhTaGFyZWQ8L0RJVj4NCjxESVY+Jmd0OyZuYnNwO1VuaWZp
ZWQmbmJzcDtQb2xpY3kmbmJzcDtBdXRvbWF0aW9uKSZuYnNwO3dvcmtpbmcmbmJzcDtncm91
cCZuYnNwO3dpbGwmbmJzcDt3b3JrJm5ic3A7b24mbmJzcDt0aGUmbmJzcDtkZWZpbml0aW9u
Jm5ic3A7b2YmbmJzcDtzdWNoPC9ESVY+DQo8RElWPiZndDsmbmJzcDthcyZuYnNwO3N0YW5k
YXJkaXplZCZuYnNwO2ludGVyZmFjZSZuYnNwO2ZvciZuYnNwO2FwcGxpY2F0aW9ucyZuYnNw
O2FuZCZuYnNwO25ldHdvcmsmbmJzcDtzZXJ2aWNlcyZuYnNwO3RvJm5ic3A7Y29tbXVuaWNh
dGU8L0RJVj4NCjxESVY+Jmd0OyZuYnNwO3dpdGgmbmJzcDtuZXR3b3JrJm5ic3A7Y29udHJv
bGxlcnMmbmJzcDtvZiZuYnNwO2FsbCZuYnNwO3R5cGVzLiZuYnNwO0luJm5ic3A7cGFydGlj
dWxhciwmbmJzcDtTVVBBJm5ic3A7d2lsbCZuYnNwO2ZvY3VzJm5ic3A7b248L0RJVj4NCjxE
SVY+Jmd0OyZuYnNwO3NlcnZpY2UmbmJzcDtzcGVjaWZpYyZuYnNwO21vZGVscyZuYnNwO3Ro
YXQmbmJzcDthbGxvdyZuYnNwO2FwcGxpY2F0aW9ucyZuYnNwO3RvJm5ic3A7cmVxdWVzdCZu
YnNwO2NlcnRhaW4mbmJzcDtuZXR3b3JrPC9ESVY+DQo8RElWPiZndDsmbmJzcDtzZXJ2aWNl
cyZuYnNwO3RvJm5ic3A7YmUmbmJzcDtjcmVhdGVkL2RlbGV0ZWQvbW9kaWZpZWQuJm5ic3A7
QSZuYnNwO25ldHdvcmsmbmJzcDtzZXJ2aWNlJm5ic3A7Y2FuJm5ic3A7Zm9yJm5ic3A7ZXhh
bXBsZSZuYnNwO2JlPC9ESVY+DQo8RElWPiZndDsmbmJzcDthJm5ic3A7dmlydHVhbCZuYnNw
O2xpbmsmbmJzcDtiZXR3ZWVuJm5ic3A7dHdvJm5ic3A7ZW5kcG9pbnRzJm5ic3A7dGhhdCZu
YnNwO3VzZXMmbmJzcDtjZXJ0YWluJm5ic3A7cHJvcGVydGllcywmbmJzcDt0cmFmZmljPC9E
SVY+DQo8RElWPiZndDsmbmJzcDtlbmdpbmVlcmluZywmbmJzcDtpbXBsZW1lbnRhdGlvbiZu
YnNwO29mJm5ic3A7SVB2NiZuYnNwO3RyYW5zaXRpb24mbmJzcDttZWNoYW5pc20mbmJzcDth
bmQmbmJzcDt0aGVpciZuYnNwO2VuZm9yY2VtZW50PC9ESVY+DQo8RElWPiZndDsmbmJzcDt0
byZuYnNwO3VzZXJzLjwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7RWFjaCZuYnNwO25ldHdvcmsm
bmJzcDtzZXJ2aWNlJm5ic3A7Y2FuJm5ic3A7YmUmbmJzcDtyZXByZXNlbnRlZCZuYnNwO2J5
Jm5ic3A7YSZuYnNwO3NlcnZpY2UmbmJzcDtiYXNlZCZuYnNwO1BPTElDWSZuYnNwO21vZGVs
Jm5ic3A7dGhhdDwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7Y2FuJm5ic3A7bW9kZWwmbmJzcDth
Jm5ic3A7Z3JvdXAmbmJzcDtvZiZuYnNwO2RlbWFuZHMmbmJzcDsoaS5lLiwmbmJzcDthY3Rp
b25zJm5ic3A7YW5kJm5ic3A7Y29uc3RyYWludHMpJm5ic3A7dGhhdCZuYnNwO2FyZSZuYnNw
O2JlaW5nPC9ESVY+DQo8RElWPiZndDsmbmJzcDtpbml0aWF0ZWQmbmJzcDtieSZuYnNwO2Fw
cGxpY2F0aW9ucyZuYnNwO3RoYXQmbmJzcDtpbXBvc2UmbmJzcDtzaW1pbGFyJm5ic3A7cmVx
dWlyZW1lbnRzJm5ic3A7b24mbmJzcDt0aGU8L0RJVj4NCjxESVY+Jmd0OyZuYnNwO2NvbW11
bmljYXRpb24mbmJzcDtuZXR3b3JrLiZuYnNwO1RoZSZuYnNwO3Rlcm1zJm5ic3A7IlVOSUZJ
RUQiJm5ic3A7YW5kJm5ic3A7IlNIQVJFRCImbmJzcDt1c2VkJm5ic3A7aW4mbmJzcDt0aGUm
bmJzcDtTVVBBPC9ESVY+DQo8RElWPiZndDsmbmJzcDthYmJyZXZpYXRpb24sJm5ic3A7cmVs
YXRlJm5ic3A7dG8mbmJzcDt0aGUmbmJzcDt3YXkmbmJzcDtvZiZuYnNwO2hvdyZuYnNwO3Ro
ZSZuYnNwO3NlcnZpY2UmbmJzcDtwb2xpY3kmbmJzcDttb2RlbCZuYnNwO2lzJm5ic3A7Z2Vu
ZXJhdGVkLDwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7c2luY2UmbmJzcDtpdCZuYnNwO2dyb3Vw
cywmbmJzcDt1bmlmaWVzJm5ic3A7YW5kJm5ic3A7c2hhcmVzJm5ic3A7dGhlJm5ic3A7c2lt
aWxhciZuYnNwO3JlcXVpcmVtZW50cyZuYnNwO2ltcG9zZWQmbmJzcDtieSZuYnNwO2EmbmJz
cDtidWxrPC9ESVY+DQo8RElWPiZndDsmbmJzcDtvZiZuYnNwO2FwcGxpY2F0aW9ucy4mbmJz
cDtTVVBBJm5ic3A7d2lsbCZuYnNwO3Byb3ZpZGUmbmJzcDtndWlkZWxpbmVzJm5ic3A7Zm9y
Jm5ic3A7bWVjaGFuaXNtcyZuYnNwO3RoYXQmbmJzcDtjYW48L0RJVj4NCjxESVY+Jmd0OyZu
YnNwO2R5bmFtaWNhbGx5Jm5ic3A7YW5kJm5ic3A7b24mbmJzcDthbiZuYnNwO2ludGVyb3Bl
cmFibGUmbmJzcDttYW5uZXIsJm5ic3A7QVVUT01BVElDQUxMWSZuYnNwO21hcCZuYnNwO3Nl
cnZpY2VzJm5ic3A7YW5kPC9ESVY+DQo8RElWPiZndDsmbmJzcDtwb2xpY2llcyZuYnNwO2Rl
ZmluZWQmbmJzcDtvbiZuYnNwO2FuJm5ic3A7YWJzdHJhY3QmbmJzcDt0b3BvbG9neSZuYnNw
O2dyYXBoJm5ic3A7ZG93biZuYnNwO3RvJm5ic3A7bW9yZSZuYnNwO2RldGFpbGVkJm5ic3A7
bmV0d29yazwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7Z3JhcGhzJm5ic3A7YW5kJm5ic3A7c3Bl
Y2lmaWMmbmJzcDtuZXR3b3JrJm5ic3A7bWFuYWdlbWVudCZuYnNwO2FuZCZuYnNwO2NvbnRy
b2xsaW5nJm5ic3A7cG9saWNpZXMuPC9ESVY+DQo8RElWPiZndDsmbmJzcDtTb21lJm5ic3A7
SUVURiZuYnNwO3dvcmtpbmcmbmJzcDtncm91cHMmbmJzcDtoYXZlJm5ic3A7c3RhcnRlZCZu
YnNwO3dvcmsmbmJzcDtyZWxhdGluZyZuYnNwO3RvJm5ic3A7dGhlJm5ic3A7ZGVzY3JpcHRp
b24mbmJzcDtvZjwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7dmFyaW91cyZuYnNwO3RvcG9sb2dp
ZXMmbmJzcDtzdWNoJm5ic3A7YXMmbmJzcDtJMlJTJm5ic3A7KEwzJm5ic3A7YW5kJm5ic3A7
cm91dGluZyZuYnNwO3RvcG9sb2dpZXMpLCZuYnNwO0FMVE8mbmJzcDsoY29zdCZuYnNwO21h
cHMpLDwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7U0ZDJm5ic3A7KHNlcnZpY2UmbmJzcDtjaGFp
biksJm5ic3A7bm9uZSZuYnNwO29mJm5ic3A7dGhlc2UmbmJzcDtncm91cHMmbmJzcDthaW0m
bmJzcDsoMSkmbmJzcDthdCZuYnNwO29mZmVyaW5nJm5ic3A7dHJ1bHkmbmJzcDtnZW5lcmlj
PC9ESVY+DQo8RElWPiZndDsmbmJzcDt0b3BvbG9neSZuYnNwO21vZGVscyZuYnNwO2ZvciZu
YnNwO3RoZSZuYnNwO3N0YW5kYXJkJm5ic3A7bm9ydGhib3VuZCZuYnNwO2ludGVyZmFjZSwm
bmJzcDthbmQmbmJzcDsoMikmbmJzcDt0aGF0Jm5ic3A7YW48L0RJVj4NCjxESVY+Jmd0OyZu
YnNwO2FwcGxpY2F0aW9uJm5ic3A7Y2FuJm5ic3A7Y29tbXVuaWNhdGUmbmJzcDt3aXRoJm5i
c3A7bmV0d29yayZuYnNwO2JveGVzLCZuYnNwO3N1Y2gmbmJzcDthcyZuYnNwO25ldHdvcmsm
bmJzcDtjb250cm9sbGVycyw8L0RJVj4NCjxESVY+Jmd0OyZuYnNwO2FuZCZuYnNwO05Fcywm
bmJzcDtkZXZlbG9wZWQmbmJzcDtieSZuYnNwO2RpZmZlcmVudCZuYnNwO3ZlbmRvcnMuPC9E
SVY+DQo8RElWPiZndDsmbmJzcDtTVVBBJm5ic3A7d2lsbCZuYnNwO3dvcmsmbmJzcDtvbiZu
YnNwO2RlZmluaW5nJm5ic3A7dmVuZG9yLW5ldXRyYWwmbmJzcDtzdGFuZGFyZGl6ZWQmbmJz
cDtpbnRlcmZhY2VzJm5ic3A7YmFzZWQmbmJzcDtvbiZuYnNwO3RoZTwvRElWPg0KPERJVj4m
Z3Q7Jm5ic3A7Y29uY2VwdCZuYnNwO29mJm5ic3A7bmV0d29yayZuYnNwO2dyYXBoLCZuYnNw
O2FuJm5ic3A7ZW50aXR5Jm5ic3A7ZGVzY3JpYmluZyZuYnNwO2FuJm5ic3A7YXJiaXRyYXJ5
Jm5ic3A7dG9wb2xvZ3kmbmJzcDtvZiZuYnNwO25vZGVzPC9ESVY+DQo8RElWPiZndDsmbmJz
cDthbmQmbmJzcDtsaW5rcyZuYnNwO2F0Jm5ic3A7YW55Jm5ic3A7bGV2ZWwmbmJzcDtvZiZu
YnNwO2dyYW51bGFyaXR5LiZuYnNwO1N1Y2gmbmJzcDthJm5ic3A7bmV0d29yayZuYnNwO2dy
YXBoJm5ic3A7ZGVzY3JpYmVzJm5ic3A7KDEpPC9ESVY+DQo8RElWPiZndDsmbmJzcDt0b3Bv
bG9naWVzJm5ic3A7YXQmbmJzcDtkaWZmZXJlbnQmbmJzcDtsZXZlbHMmbmJzcDtvZiZuYnNw
O2Fic3RyYWN0aW9uLCZuYnNwOygyKSZuYnNwO3RoZSZuYnNwO3JlbGF0aW9uc2hpcHMmbmJz
cDtiZXR3ZWVuPC9ESVY+DQo8RElWPiZndDsmbmJzcDt0aGUmbmJzcDthYnN0cmFjdGlvbiZu
YnNwO2xldmVscyZuYnNwO2FuZCZuYnNwOygzKSZuYnNwO2FwcGxpZWQmbmJzcDtzZXJ2aWNl
Jm5ic3A7YmFzZWQmbmJzcDtwb2xpY3ksJm5ic3A7d2hpY2gmbmJzcDthcmUmbmJzcDthY3Rp
b25zPC9ESVY+DQo8RElWPiZndDsmbmJzcDthbmQmbmJzcDtjb25zdHJhaW50cyZuYnNwO2Fw
cGxpZWQmbmJzcDtvbiZuYnNwO3RoZXNlJm5ic3A7dG9wb2xvZ2llcy4mbmJzcDtTVVBBJm5i
c3A7bWF5Jm5ic3A7YWxzbyZuYnNwO2RlZmluZSZuYnNwO2FueSZuYnNwO21hcHBpbmdzPC9E
SVY+DQo8RElWPiZndDsmbmJzcDt0byZuYnNwO2FueSZuYnNwO290aGVyJm5ic3A7bmV0d29y
ayZuYnNwO3RvcG9sb2d5Jm5ic3A7ZGF0YSZuYnNwO21vZGVscyZuYnNwO2RlZmluZWQmbmJz
cDt3aXRoaW4mbmJzcDt0aGUmbmJzcDtJRVRGLjwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7VGhl
Jm5ic3A7bWFpbiZuYnNwO2dvYWwmbmJzcDtvZiZuYnNwO1NVUEEmbmJzcDtpcyZuYnNwO3Rv
Jm5ic3A7cHJvdmlkZSZuYnNwO3NlcnZpY2UmbmJzcDtzcGVjaWZpYyZuYnNwO21vZGVscyZu
YnNwO3RoYXQmbmJzcDthbGxvdzwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7YXBwbGljYXRpb25z
Jm5ic3A7dG8mbmJzcDtyZXF1ZXN0Jm5ic3A7bmV0d29yayZuYnNwO3NlcnZpY2VzJm5ic3A7
dG8mbmJzcDtiZSZuYnNwO2NyZWF0ZWQvZGVsZXRlZC9tb2RpZmllZC4mbmJzcDtUaGlzPC9E
SVY+DQo8RElWPiZndDsmbmJzcDtjYW4mbmJzcDtiZSZuYnNwO3JlYWxpemVkJm5ic3A7Ynk6
PC9ESVY+DQo8RElWPiZndDsmbmJzcDsmbmJzcDsmbmJzcDtvKSZuYnNwO21vZGVsJm5ic3A7
bXVsdGlwbGUmbmJzcDt0b3BvbG9naWVzJm5ic3A7YXQmbmJzcDtkaWZmZXJlbnQmbmJzcDts
ZXZlbHMmbmJzcDtvZiZuYnNwO2Fic3RyYWN0aW9uJm5ic3A7dXNpbmcmbmJzcDthPC9ESVY+
DQo8RElWPiZndDsmbmJzcDtuZXR3b3JrJm5ic3A7Z3JhcGgsPC9ESVY+DQo8RElWPiZndDsm
bmJzcDsmbmJzcDsmbmJzcDtvKSZuYnNwO21vZGVsJm5ic3A7dGhlJm5ic3A7cmVsYXRpb25z
aGlwcyZuYnNwO2JldHdlZW4mbmJzcDt0aGUmbmJzcDthYnN0cmFjdGlvbiZuYnNwO2xldmVs
cy48L0RJVj4NCjxESVY+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwO28pJm5ic3A7dHJhbnNwb3J0
aW5nJm5ic3A7bW9kZWwmbmJzcDtpbnN0YW5jZXMmbmJzcDt1c2luZyZuYnNwO2VpdGhlciZu
YnNwO05FVENPTkYmbmJzcDtvciZuYnNwO1JFU1RDT05GPC9ESVY+DQo8RElWPiZndDs8L0RJ
Vj4NCjxESVY+Jmd0OyZuYnNwO1NVUEEmbmJzcDt3aWxsJm5ic3A7ZW5zdXJlJm5ic3A7dGhh
dCZuYnNwO2luJm5ic3A7Y2FzZSZuYnNwO2FueSZuYnNwO3NwZWNpZmljJm5ic3A7TkVUQ09O
Ri9SRVNUQ09ORiZuYnNwO3Byb3RvY29sPC9ESVY+DQo8RElWPiZndDsmbmJzcDtyZXF1aXJl
bWVudHMmbmJzcDthcmUmbmJzcDtpZGVudGlmaWVkLCZuYnNwO3RoZXkmbmJzcDt3aWxsJm5i
c3A7YmUmbmJzcDtjb21tdW5pY2F0ZWQmbmJzcDtpbiZuYnNwO2EmbmJzcDt0aW1lbHkmbmJz
cDttYW5uZXImbmJzcDt0bzwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7dGhlJm5ic3A7TkVUQ09O
RiZuYnNwO3dvcmtpbmcmbmJzcDtncm91cC4mbmJzcDtTVVBBJm5ic3A7d2lsbCZuYnNwO2Nv
bnN1bHQmbmJzcDt3aXRoJm5ic3A7dGhlJm5ic3A7WUFORyZuYnNwO2RvY3RvcnMmbmJzcDt0
byZuYnNwO2Vuc3VyZTwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7dGhhdCZuYnNwO2RhdGEmbmJz
cDttb2RlbHMmbmJzcDtmb2xsb3cmbmJzcDtjb21tb24mbmJzcDtwcmFjdGljZXMuPC9ESVY+
DQo8RElWPiZndDs8L0RJVj4NCjxESVY+Jmd0OyZuYnNwO1dvcmsmbmJzcDtpdGVtcyZuYnNw
O2ZvciZuYnNwO1NVUEEmbmJzcDtpbmNsdWRlOjwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7PT09
PT09PT09PT09PT09PT09PT09PT09PT09PTwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7MSkmbmJz
cDtUaGUmbmJzcDtkZWZpbml0aW9uJm5ic3A7b2YmbmJzcDthJm5ic3A7c3RhbmRhcmRpemVk
Jm5ic3A7bW9kZWwmbmJzcDtmb3ImbmJzcDthJm5ic3A7bmV0d29yayZuYnNwO2dyYXBoLCZu
YnNwO3VzaW5nJm5ic3A7WUFORy48L0RJVj4NCjxESVY+Jmd0OyZuYnNwO1RoaXMmbmJzcDtt
b2RlbCZuYnNwO21heSZuYnNwO2JlJm5ic3A7dXNlZCZuYnNwO3RvJm5ic3A7ZGVzY3JpYmUm
bmJzcDt0b3BvbG9naWVzJm5ic3A7YXQmbmJzcDthbnkmbmJzcDtmdW5jdGlvbmFsJm5ic3A7
bGF5ZXIsJm5ic3A7ZnJvbTwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7cGh5c2ljYWwmbmJzcDtu
ZXR3b3JrcyZuYnNwO3RvJm5ic3A7bmV0d29yayZuYnNwO3NlcnZpY2VzLjwvRElWPg0KPERJ
Vj4mZ3Q7Jm5ic3A7MikmbmJzcDtUaGUmbmJzcDtkZWZpbml0aW9uJm5ic3A7YW5kJm5ic3A7
c3RhbmRhcmRpemF0aW9uJm5ic3A7b2YmbmJzcDthJm5ic3A7bnVtYmVyJm5ic3A7b2YmbmJz
cDtiYXNpYyZuYnNwO3BvbGljeSZuYnNwO2FuZCZuYnNwO2RhdGE8L0RJVj4NCjxESVY+Jmd0
OyZuYnNwO21vZGVscyZuYnNwO3VzaW5nJm5ic3A7bmV0d29yayZuYnNwO2dyYXBocy4mbmJz
cDtUaGVzZSZuYnNwO21pZ2h0Jm5ic3A7aW5jbHVkZSwmbmJzcDtidXQmbmJzcDthcmUmbmJz
cDtub3QmbmJzcDtsaW1pdGVkJm5ic3A7dG88L0RJVj4NCjxESVY+Jmd0OyZuYnNwO0wzVlBO
cywmbmJzcDt0cmFmZmljJm5ic3A7ZW5naW5lZXJpbmcsJm5ic3A7aW1wbGVtZW50YXRpb24m
bmJzcDtvZiZuYnNwO0lQdjYmbmJzcDt0cmFuc2l0aW9uJm5ic3A7bWVjaGFuaXNtJm5ic3A7
YW5kPC9ESVY+DQo8RElWPiZndDsmbmJzcDt0aGVpciZuYnNwO2VuZm9yY2VtZW50Jm5ic3A7
dG8mbmJzcDt1c2Vycy48L0RJVj4NCjxESVY+Jmd0OyZuYnNwOzMpJm5ic3A7UHJvdmlkZSZu
YnNwO2d1aWRlbGluZXMmbmJzcDtmb3ImbmJzcDttZWNoYW5pc21zJm5ic3A7dGhhdCZuYnNw
O2NhbiZuYnNwO2R5bmFtaWNhbGx5Jm5ic3A7YW5kJm5ic3A7b24mbmJzcDthbjwvRElWPg0K
PERJVj4mZ3Q7Jm5ic3A7aW50ZXJvcGVyYWJsZSZuYnNwO21hbm5lciwmbmJzcDthdXRvbWF0
aWNhbGx5Jm5ic3A7bWFwJm5ic3A7c2VydmljZXMmbmJzcDthbmQmbmJzcDtwb2xpY2llcyZu
YnNwO2RlZmluZWQmbmJzcDtvbiZuYnNwO2FuPC9ESVY+DQo8RElWPiZndDsmbmJzcDthYnN0
cmFjdCZuYnNwO3RvcG9sb2d5Jm5ic3A7Z3JhcGgmbmJzcDtkb3duJm5ic3A7dG8mbmJzcDtt
b3JlJm5ic3A7ZGV0YWlsZWQmbmJzcDtuZXR3b3JrJm5ic3A7Z3JhcGhzJm5ic3A7YW5kJm5i
c3A7c3BlY2lmaWM8L0RJVj4NCjxESVY+Jmd0OyZuYnNwO25ldHdvcmsmbmJzcDttYW5hZ2Vt
ZW50Jm5ic3A7YW5kJm5ic3A7Y29udHJvbGxpbmcmbmJzcDtwb2xpY2llcy48L0RJVj4NCjxE
SVY+Jmd0OyZuYnNwOzQpJm5ic3A7R3VpZGVsaW5lcyZuYnNwO29uJm5ic3A7aG93Jm5ic3A7
dG8mbmJzcDt1c2UmbmJzcDtORVRDT05GJm5ic3A7KG9yJm5ic3A7UkVTVENPTkYpJm5ic3A7
YXV0aGVudGljYXRpb24mbmJzcDthbmQ8L0RJVj4NCjxESVY+Jmd0OyZuYnNwO2F1dGhvcml6
YXRpb24mbmJzcDttZWNoYW5pc21zJm5ic3A7dG8mbmJzcDthY2hpZXZlJm5ic3A7cHJvdGVj
dGlvbiZuYnNwO2FuZCZuYnNwO2lzb2xhdGlvbjwvRElWPg0KPERJVj4mZ3Q7PC9ESVY+DQo8
RElWPiZndDsmbmJzcDtEZWxpdmVyYWJsZXM6PC9ESVY+DQo8RElWPiZndDsmbmJzcDs9PT09
PT09PT09PT09PC9ESVY+DQo8RElWPiZndDsmbmJzcDtvKSZuYnNwO1Byb2R1Y2UmbmJzcDth
biZuYnNwO2luZm9ybWF0aW9uYWwmbmJzcDtSRkMmbmJzcDsiUHJvYmxlbSZuYnNwO1N0YXRl
bWVudCZuYnNwO2FuZCZuYnNwO1VzZSZuYnNwO0Nhc2VzIi48L0RJVj4NCjxESVY+Jmd0OyZu
YnNwO28pJm5ic3A7UHJvZHVjZSZuYnNwO2EmbmJzcDtzdGFuZGFyZHMtdHJhY2smbmJzcDtS
RkMmbmJzcDt0aGF0Jm5ic3A7c3BlY2lmaWVzJm5ic3A7WUFORyZuYnNwO21vZGVscyZuYnNw
O2ZvciZuYnNwO2EmbmJzcDtnZW5lcmljPC9ESVY+DQo8RElWPiZndDsmbmJzcDttdWx0aS1s
YXllciZuYnNwO25ldHdvcmsmbmJzcDtncmFwaC48L0RJVj4NCjxESVY+Jmd0OyZuYnNwO28p
Jm5ic3A7UHJvZHVjZSZuYnNwO3N0YW5kYXJkcy10cmFjayZuYnNwO1JGQ3MmbmJzcDt0aGF0
Jm5ic3A7c3BlY2lmeSZuYnNwO2V4dGVuc2lvbnMmbmJzcDtmb3ImbmJzcDt0aGUmbmJzcDtn
ZW5lcmljJm5ic3A7WUFORzwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7bW9kZWxzJm5ic3A7ZGVm
aW5lZCZuYnNwO2Fib3ZlJm5ic3A7Zm9yJm5ic3A7bmV0d29yayZuYnNwO3NlcnZpY2VzJm5i
c3A7dGhhdCZuYnNwO21hbmFnZSZuYnNwO3ZpcnR1YWwmbmJzcDtsaW5rcywmbmJzcDt0cmFm
ZmljPC9ESVY+DQo8RElWPiZndDsmbmJzcDtlbmdpbmVlcmluZyZuYnNwO2FuZCZuYnNwO2lt
cGxlbWVudGF0aW9uJm5ic3A7b2YmbmJzcDtJUHY2Jm5ic3A7dHJhbnNpdGlvbiZuYnNwO21l
Y2hhbmlzbSZuYnNwO2FuZCZuYnNwO3RoZWlyPC9ESVY+DQo8RElWPiZndDsmbmJzcDtlbmZv
cmNlbWVudCZuYnNwO3RvJm5ic3A7dXNlcnMuPC9ESVY+DQo8RElWPiZndDsmbmJzcDtvKSZu
YnNwO1Byb2R1Y2UmbmJzcDthbiZuYnNwO2luZm9ybWF0aW9uYWwmbmJzcDtSRkMmbmJzcDt0
aGF0Jm5ic3A7cHJvdmlkZXMmbmJzcDt0aGUmbmJzcDtndWlkZWxpbmVzJm5ic3A7Zm9yJm5i
c3A7bWVjaGFuaXNtczwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7dGhhdCZuYnNwO2NhbiZuYnNw
O2R5bmFtaWNhbGx5Jm5ic3A7YW5kJm5ic3A7b24mbmJzcDtpbnRlcm9wZXJhYmxlJm5ic3A7
bWFubmVyLCZuYnNwO2F1dG9tYXRpY2FsbHkmbmJzcDttYXAmbmJzcDtzZXJ2aWNlczwvRElW
Pg0KPERJVj4mZ3Q7Jm5ic3A7YW5kJm5ic3A7cG9saWNpZXMmbmJzcDtkZWZpbmVkJm5ic3A7
b24mbmJzcDthbiZuYnNwO2Fic3RyYWN0Jm5ic3A7dG9wb2xvZ3kmbmJzcDtncmFwaCZuYnNw
O2Rvd24mbmJzcDt0byZuYnNwO21vcmUmbmJzcDtkZXRhaWxlZDwvRElWPg0KPERJVj4mZ3Q7
Jm5ic3A7bmV0d29yayZuYnNwO2dyYXBocyZuYnNwO2FuZCZuYnNwO3NwZWNpZmljJm5ic3A7
bmV0d29yayZuYnNwO21hbmFnZW1lbnQmbmJzcDthbmQmbmJzcDtjb250cm9sbGluZyZuYnNw
O3BvbGljaWVzLjwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7bykmbmJzcDtQcm9kdWNlJm5ic3A7
YW4mbmJzcDtpbmZvcm1hdGlvbmFsJm5ic3A7UkZDJm5ic3A7dGhhdCZuYnNwO3Byb3ZpZGVz
Jm5ic3A7dGhlJm5ic3A7Z3VpZGVsaW5lcyZuYnNwO29uJm5ic3A7dXNpbmcmbmJzcDtORVRD
T05GPC9ESVY+DQo8RElWPiZndDsmbmJzcDsob3ImbmJzcDtSRVNUQ09ORikmbmJzcDthdXRo
ZW50aWNhdGlvbiZuYnNwO2FuZCZuYnNwO2F1dGhvcml6YXRpb24mbmJzcDttZWNoYW5pc21z
Jm5ic3A7dG8mbmJzcDthY2hpZXZlJm5ic3A7c2VjdXJpdHk8L0RJVj4NCjxESVY+Jmd0OyZu
YnNwO3Byb3RlY3Rpb24mbmJzcDthbmQmbmJzcDtpc29sYXRpb24nJm5ic3A7YXMmbmJzcDth
biZuYnNwO0luZm9ybWF0aW9uYWwmbmJzcDtSRkMuPC9ESVY+DQo8RElWPiZndDs8L0RJVj4N
CjxESVY+Jmd0OyZuYnNwO01pbGVzdG9uZXM6PC9ESVY+DQo8RElWPiZndDsmbmJzcDs9PT09
PT09PT09PTwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7RGVjJm5ic3A7MjAxNCZuYnNwOyZuYnNw
O0luaXRpYWwmbmJzcDsiUHJvYmxlbSZuYnNwO1N0YXRlbWVudCZuYnNwO2FuZCZuYnNwO1Vz
ZSZuYnNwO0Nhc2VzIiZuYnNwO1dHJm5ic3A7SS1EJm5ic3A7RmViJm5ic3A7MjAxNSZuYnNw
OyZuYnNwO0luaXRpYWw8L0RJVj4NCjxESVY+Jmd0OyZuYnNwOyJNdWx0aS1sYXllciZuYnNw
O05ldHdvcmsmbmJzcDtHcmFwaCZuYnNwO1lBTkcmbmJzcDtNb2RlbCImbmJzcDtXRyZuYnNw
O0ktRCZuYnNwO0FwciZuYnNwOzIwMTUmbmJzcDsmbmJzcDtJbml0aWFsJm5ic3A7c2Vydmlj
ZTwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7c3BlY2lmaWMmbmJzcDtkYXRhJm5ic3A7bW9kZWwm
bmJzcDtXRyZuYnNwO0ktRHMmbmJzcDtNYXkmbmJzcDsyMDE1Jm5ic3A7Jm5ic3A7SW5pdGlh
bCZuYnNwOyJNYXBwaW5nJm5ic3A7R3VpZGVsaW5lcyImbmJzcDtXRyZuYnNwO0ktRCZuYnNw
O0p1bjwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7MjAxNSZuYnNwOyZuYnNwO1N1Ym1pdCZuYnNw
OyJQcm9ibGVtJm5ic3A7U3RhdGVtZW50Jm5ic3A7YW5kJm5ic3A7VXNlJm5ic3A7Q2FzZXMi
Jm5ic3A7SS1EJm5ic3A7dG8mbmJzcDtJRVNHJm5ic3A7SnVsJm5ic3A7MjAxNSZuYnNwOyZu
YnNwO0luaXRpYWw8L0RJVj4NCjxESVY+Jmd0OyZuYnNwOyJBdXRoZW50aWNhdGlvbiZuYnNw
O2FuZCZuYnNwO0F1dGhvcml6YXRpb24iJm5ic3A7V0cmbmJzcDtJLUQmbmJzcDtTZXAmbmJz
cDsyMDE1Jm5ic3A7Jm5ic3A7U3VibWl0Jm5ic3A7Ik11bHRpLWxheWVyPC9ESVY+DQo8RElW
PiZndDsmbmJzcDtOZXR3b3JrJm5ic3A7R3JhcGgmbmJzcDtZQU5HJm5ic3A7TW9kZWwiJm5i
c3A7SS1EJm5ic3A7dG8mbmJzcDtJRVNHJm5ic3A7Tm92Jm5ic3A7MjAxNSZuYnNwOyZuYnNw
O1N1Ym1pdCZuYnNwO3NlcnZpY2UmbmJzcDtzcGVjaWZpYyZuYnNwO2RhdGE8L0RJVj4NCjxE
SVY+Jmd0OyZuYnNwO21vZGVsJm5ic3A7SS1EcyZuYnNwO3RvJm5ic3A7SUVTRyZuYnNwO0Zl
YiZuYnNwOzIwMTYmbmJzcDsmbmJzcDtTdWJtaXQmbmJzcDsiTWFwcGluZyZuYnNwO0d1aWRl
bGluZXMiJm5ic3A7SS1EJm5ic3A7dG8mbmJzcDtJRVNHJm5ic3A7QXByPC9ESVY+DQo8RElW
PiZndDsmbmJzcDsyMDE2Jm5ic3A7Jm5ic3A7U3VibWl0Jm5ic3A7IkF1dGhlbnRpY2F0aW9u
Jm5ic3A7YW5kJm5ic3A7QXV0aG9yaXphdGlvbiImbmJzcDtJLUQmbmJzcDt0byZuYnNwO0lF
U0c8L0RJVj4NCjxESVY+Jmd0OzwvRElWPg0KPERJVj4mZ3Q7PC9ESVY+DQo8RElWPiZndDsm
bmJzcDtUaGFuayZuYnNwO3lvdSw8L0RJVj4NCjxESVY+Jmd0OyZuYnNwO1RpbmE8L0RJVj4N
CjxESVY+Jmd0OzwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7RnJvbTombmJzcDtTdXBhJm5ic3A7
W21haWx0bzpzdXBhLWJvdW5jZXNAaWV0Zi5vcmddJm5ic3A7T24mbmJzcDtCZWhhbGYmbmJz
cDtPZiZuYnNwO0xpdXNodWNoZW5nJm5ic3A7KFdpbGwpPC9ESVY+DQo8RElWPiZndDsmbmJz
cDtTZW50OiZuYnNwO1RodXJzZGF5LCZuYnNwO1NlcHRlbWJlciZuYnNwOzI1LCZuYnNwOzIw
MTQmbmJzcDs3OjM2Jm5ic3A7UE08L0RJVj4NCjxESVY+Jmd0OyZuYnNwO1RvOiZuYnNwO0Jl
bm9pdCZuYnNwO0NsYWlzZTwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7Q2M6Jm5ic3A7c3VwYUBp
ZXRmLm9yZzwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7U3ViamVjdDombmJzcDtSZTombmJzcDtb
U3VwYV0mbmJzcDtBcmVhJm5ic3A7aGFuZC1vZmYsJm5ic3A7YW5kJm5ic3A7c29tZSZuYnNw
O2ZyaWVuZGx5Jm5ic3A7YWR2aWNlJm5ic3A7Li4uPC9ESVY+DQo8RElWPiZndDs8L0RJVj4N
CjxESVY+Jmd0OyZuYnNwO0hpJm5ic3A7QmVub2l0LDwvRElWPg0KPERJVj4mZ3Q7PC9ESVY+
DQo8RElWPiZndDsmbmJzcDtCZWxvdyZuYnNwO2lubGluZSZuYnNwO3BsZWFzZSZuYnNwO3Nl
ZSZuYnNwO3R3byZuYnNwO3BpZWNlcyZuYnNwO29mJm5ic3A7Y29tcGxlbWVudGFyeSZuYnNw
O2Fuc3dlciZuYnNwO2Zyb20mbmJzcDtteSZuYnNwO3RlYW08L0RJVj4NCjxESVY+Jmd0OyZu
YnNwOyhzdGFydHMmbmJzcDt3aXRoJm5ic3A7W1dpbGxdKS4mbmJzcDtUaGFuayZuYnNwO3lv
dSE8L0RJVj4NCjxESVY+Jmd0OzwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7UmVnYXJkcyw8L0RJ
Vj4NCjxESVY+Jmd0OyZuYnNwO1dpbGw8L0RJVj4NCjxESVY+Jmd0OzwvRElWPg0KPERJVj4m
Z3Q7Jm5ic3A7RnJvbTombmJzcDtTdXBhJm5ic3A7W21haWx0bzpzdXBhLWJvdW5jZXNAaWV0
Zi5vcmddJm5ic3A7T24mbmJzcDtCZWhhbGYmbmJzcDtPZiZuYnNwO0dlb3JnaW9zJm5ic3A7
S2FyYWdpYW5uaXM8L0RJVj4NCjxESVY+Jmd0OyZuYnNwO1NlbnQ6Jm5ic3A7V2VkbmVzZGF5
LCZuYnNwO1NlcHRlbWJlciZuYnNwOzI0LCZuYnNwOzIwMTQmbmJzcDs3OjMwJm5ic3A7UE08
L0RJVj4NCjxESVY+Jmd0OyZuYnNwO1RvOiZuYnNwO0Jlbm9pdCZuYnNwO0NsYWlzZTsmbmJz
cDtUaW5hJm5ic3A7VFNPVTsmbmJzcDtKdWVyZ2VuJm5ic3A7U2Nob2Vud2FlbGRlcjwvRElW
Pg0KPERJVj4mZ3Q7Jm5ic3A7Q2M6Jm5ic3A7WmhlbiZuYnNwO0NhbzsmbmJzcDtzdXBhQGll
dGYub3JnPC9ESVY+DQo8RElWPiZndDsmbmJzcDtTdWJqZWN0OiZuYnNwO1JlOiZuYnNwO1tT
dXBhXSZuYnNwO0FyZWEmbmJzcDtoYW5kLW9mZiwmbmJzcDthbmQmbmJzcDtzb21lJm5ic3A7
ZnJpZW5kbHkmbmJzcDthZHZpY2UmbmJzcDsuLi48L0RJVj4NCjxESVY+Jmd0OzwvRElWPg0K
PERJVj4mZ3Q7Jm5ic3A7SGkmbmJzcDtCZW5vaXQsPC9ESVY+DQo8RElWPiZndDs8L0RJVj4N
CjxESVY+Jmd0OyZuYnNwO1RoYW5rJm5ic3A7eW91Jm5ic3A7Zm9yJm5ic3A7eW91ciZuYnNw
O2NvbW1lbnRzLjwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7UGxlYXNlJm5ic3A7c2VlJm5ic3A7
aW4mbmJzcDtsaW5lLDwvRElWPg0KPERJVj4mZ3Q7PC9ESVY+DQo8RElWPiZndDsmbmJzcDtG
cm9tOiZuYnNwO1N1cGEmbmJzcDtbbWFpbHRvOnN1cGEtYm91bmNlc0BpZXRmLm9yZ10mbmJz
cDtPbiZuYnNwO0JlaGFsZiZuYnNwO09mJm5ic3A7QmVub2l0Jm5ic3A7Q2xhaXNlPC9ESVY+
DQo8RElWPiZndDsmbmJzcDtTZW50OiZuYnNwO1dlZG5lc2RheSwmbmJzcDtTZXB0ZW1iZXIm
bmJzcDsyNCwmbmJzcDsyMDE0Jm5ic3A7MTA6NDEmbmJzcDtBTTwvRElWPg0KPERJVj4mZ3Q7
Jm5ic3A7VG86Jm5ic3A7R2Vvcmdpb3MmbmJzcDtLYXJhZ2lhbm5pczsmbmJzcDtUaW5hJm5i
c3A7VFNPVTsmbmJzcDtKdWVyZ2VuJm5ic3A7U2Nob2Vud2FlbGRlcjwvRElWPg0KPERJVj4m
Z3Q7Jm5ic3A7Q2M6Jm5ic3A7WmhlbiZuYnNwO0NhbzsmbmJzcDtzdXBhQGlldGYub3JnPC9E
SVY+DQo8RElWPiZndDsmbmJzcDtTdWJqZWN0OiZuYnNwO1JlOiZuYnNwO1tTdXBhXSZuYnNw
O0FyZWEmbmJzcDtoYW5kLW9mZiwmbmJzcDthbmQmbmJzcDtzb21lJm5ic3A7ZnJpZW5kbHkm
bmJzcDthZHZpY2UmbmJzcDsuLi48L0RJVj4NCjxESVY+Jmd0OzwvRElWPg0KPERJVj4mZ3Q7
Jm5ic3A7SGkmbmJzcDtHZW9yZ2lvcyw8L0RJVj4NCjxESVY+Jmd0OyZuYnNwO0hpJm5ic3A7
QmVub2l0LDwvRElWPg0KPERJVj4mZ3Q7PC9ESVY+DQo8RElWPiZndDsmbmJzcDtUaGFua3Mm
bmJzcDtmb3ImbmJzcDt5b3VyJm5ic3A7Y29tbWVudHMhPC9ESVY+DQo8RElWPiZndDsmbmJz
cDtQbGVhc2UmbmJzcDtzZWUmbmJzcDtpbiZuYnNwO2xpbmUuPC9ESVY+DQo8RElWPiZndDs8
L0RJVj4NCjxESVY+Jmd0OzwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7R2Vvcmdpb3M6Jm5ic3A7
UGxlYXNlJm5ic3A7bm90ZSZuYnNwO3RoYXQmbmJzcDt3ZSZuYnNwO2FyZSZuYnNwO3JlZmVy
cmluZyZuYnNwO3RvJm5ic3A7dGhlJm5ic3A7Zm9sbG93aW5nJm5ic3A7ZmlndXJlOjwvRElW
Pg0KPERJVj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7LS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPC9ESVY+DQo8RElWPiZndDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDt8Jm5ic3A7YXBwbGljYXRpb25zJm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fDwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
PC9ESVY+DQo8RElWPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt8
Jm5ic3A7Jm5ic3A7Jmx0Oy0tLWVuZCZuYnNwO3VzZS4mbmJzcDtBcHBsLiZuYnNwOyZuYnNw
OyZuYnNwO3w8L0RJVj4NCjxESVY+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
Oy0tLS0tLS0tLS0tLS0tLS0tLS0tLSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3wmbHQ7LS0t
ZW5kJm5ic3A7dXNlLiZuYnNwO0FwcGwuPC9ESVY+DQo8RElWPiZndDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDt8Jm5ic3A7ZW5oYW5jZWQmbmJzcDtPU1MmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fDwvRElW
Pg0KPERJVj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7LS0tLS0tLS0tLS0t
LS0tLS0tLS0tJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fDwvRElWPg0KPERJVj4mZ3Q7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fCZuYnNwOyZuYnNwOyZuYnNwOyZsdDstLS0m
bmJzcDtuZXR3b3JrJm5ic3A7c2VydmljZSZuYnNwO3wmbmJzcDtZQU5HJm5ic3A7bW9kZWxz
Jm5ic3A7Jm5ic3A7L05FVENPTkY8L0RJVj4NCjxESVY+Jmd0OyZuYnNwO2ludGVyZmFjZSZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3w8L0RJVj4NCjxESVY+
Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tPC9ESVY+DQo8RElWPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDt8Jm5ic3A7Jm5ic3A7Jm5ic3A7Y29udHJvbGxlciZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwO3wmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bHQ7LS0tPC9ESVY+DQo8RElWPiZndDsmbmJzcDsmbmJzcDsmbmJzcDttYXBwaW5nJm5ic3A7
bmV0d29yayZuYnNwO3NlcnZpY2VzJm5ic3A7dG8mbmJzcDt0b3BvbG9neTwvRElWPg0KPERJ
Vj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7LS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS08L0RJVj4NCjxESVY+Jmd0OyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3wmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZsdDstLS0mbmJzcDtkZXZpY2Uv
ZmVhdHVyZTwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7c3BlY2lmaWMmbmJzcDtZQU5HJm5ic3A7
bW9kZWxzJm5ic3A7LyZuYnNwO05FVENPTkYmbmJzcDtpbnRlcmZhY2U8L0RJVj4NCjxESVY+
Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO05FMSZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwO05FMiZuYnNwOyZuYnNwOyZuYnNwO05FbjwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7
SXQncyZuYnNwO25vdCZuYnNwO29idmlvdXMmbmJzcDt3aGF0Jm5ic3A7YW4mbmJzcDsiZW5o
YW5jZWQmbmJzcDtPU1MiJm5ic3A7aXM/PC9ESVY+DQo8RElWPiZndDs8L0RJVj4NCjxESVY+
Jmd0OyZuYnNwO0dlb3JnaW9zOiZuYnNwO2l0Jm5ic3A7cmVsYXRlcyZuYnNwO3RvJm5ic3A7
dGhlJm5ic3A7c3lzdGVtJm5ic3A7dGhhdCZuYnNwO3J1bnMmbmJzcDtuZXR3b3JrJm5ic3A7
c2VydmljZXMuJm5ic3A7VGhlc2UmbmJzcDtzZXJ2aWNlczwvRElWPg0KPERJVj4mZ3Q7Jm5i
c3A7YXJlJm5ic3A7ZW5oYW5jZWQmbmJzcDtPcGVyYXRpb25hbCZuYnNwO1N1cHBvcnQmbmJz
cDtTeXN0ZW0mbmJzcDsoT1NTKSZuYnNwO2xpa2UmbmJzcDtzZXJ2aWNlcyZuYnNwO3RoYXQm
bmJzcDtoZWxwJm5ic3A7YTwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7Y29tbXVuaWNhdGlvbiZu
YnNwO3NlcnZpY2UmbmJzcDtwcm92aWRlciZuYnNwO3RvJm5ic3A7bW9uaXRvciwmbmJzcDtj
b250cm9sLCZuYnNwO2FuYWx5emUmbmJzcDthbmQmbmJzcDttYW5hZ2UmbmJzcDthPC9ESVY+
DQo8RElWPiZndDsmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7bmV0d29yay48L0RJVj4NCjxE
SVY+Jmd0OzwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7R2Vvcmdpb3M6Jm5ic3A7QWNjb3JkaW5n
Jm5ic3A7dG8mbmJzcDt0aGUmbmJzcDtwcm92aWRlZCZuYnNwO2ZpZ3VyZTombmJzcDsxKSZu
YnNwO25lZWQmbmJzcDt0byZuYnNwO3dvcmsmbmJzcDtvbiZuYnNwO25ldHdvcmsmbmJzcDtz
ZXJ2aWNlPC9ESVY+DQo8RElWPiZndDsmbmJzcDtZYW5nJm5ic3A7bW9kZWxzLCZuYnNwOzIm
bmJzcDttYXBwaW5nJm5ic3A7bmV0d29yayZuYnNwO3NlcnZpY2VzJm5ic3A7dG8mbmJzcDt0
b3BvbG9neSwmbmJzcDszLiZuYnNwO0RldmljZS9mZWF0dXJlPC9ESVY+DQo8RElWPiZndDsm
bmJzcDtzcGVjaWZpYyZuYnNwO1lhbmcmbmJzcDtNb2RlbHMsJm5ic3A7NCkmbmJzcDtlbmQm
bmJzcDt1c2VyJm5ic3A7c3BlY2lmaWMmbmJzcDtZYW5rJm5ic3A7TW9kZWxzJm5ic3A7KG91
dCZuYnNwO29mJm5ic3A7c2NvcGUpLiZuYnNwO1RoZTwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7
aW50ZXJmYWNlJm5ic3A7YmV0d2VlbiZuYnNwO2VuZCZuYnNwO3VzZXImbmJzcDthcHBsaWNh
dGlvbnMmbmJzcDthbmQmbmJzcDthJm5ic3A7Y29udHJvbGxlciwmbmJzcDthbmQmbmJzcDtp
bnRlcmZhY2U8L0RJVj4NCjxESVY+Jmd0OyZuYnNwO2JldHdlZW4mbmJzcDtlbmQmbmJzcDt1
c2VyJm5ic3A7YXBwbGljYXRpb24mbmJzcDthbmQmbmJzcDtlbmhhbmNlZCZuYnNwO09TUywm
bmJzcDthcmUmbmJzcDthbHNvJm5ic3A7b3V0Jm5ic3A7b2YmbmJzcDtzY29wZS48L0RJVj4N
CjxESVY+Jmd0OyZuYnNwO0NvbmNlcm5pbmcmbmJzcDt5b3VyJm5ic3A7bGFzdCZuYnNwO3Nl
bnRlbmNlLiZuYnNwO0knbSZuYnNwO2NvbmZ1c2VkLjwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7
V2hhdCZuYnNwO2RvZXMmbmJzcDt0aGUmbmJzcDtmb2xsb3dpbmcmbmJzcDtkZWxpdmVyYWJs
ZSZuYnNwO21lYW4mbmJzcDt0aGVuPzwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7bykmbmJzcDtz
cGVjaWZ5Jm5ic3A7YW5kJm5ic3A7c3RhbmRhcmRpemUmbmJzcDtob3cmbmJzcDtORVRDT05G
L1lBTkcmbmJzcDsob3ImbmJzcDtSRVNUQ09ORi9ZQU5HKSZuYnNwO2NhbiZuYnNwO2JlJm5i
c3A7dXNlZCZuYnNwO3RvPC9ESVY+DQo8RElWPiZndDsmbmJzcDtzZWN1cmVseSZuYnNwO2Fu
ZCZuYnNwO2VmZmljaWVudGx5Jm5ic3A7ZGlzdHJpYnV0ZSZuYnNwO3VwJm5ic3A7dG8mbmJz
cDtkYXRlJm5ic3A7KGZyZXNoKSZuYnNwO25ldHdvcmsmbmJzcDtncmFwaHMmbmJzcDtiZXR3
ZWVuPC9ESVY+DQo8RElWPiZndDsmbmJzcDtuZXR3b3JrJm5ic3A7c2VydmljZSZuYnNwO3N5
c3RlbXMmbmJzcDthbmQmbmJzcDtuZXR3b3JrJm5ic3A7bWFuYWdlbWVudCZuYnNwO2FuZCZu
YnNwO2NvbnRyb2xsaW5nJm5ic3A7c3lzdGVtczwvRElWPg0KPERJVj4mZ3Q7PC9ESVY+DQo8
RElWPiZndDsmbmJzcDtJdCZuYnNwO3JlbGF0ZXMmbmJzcDt0byZuYnNwO3RoZSZuYnNwO2lu
dGVyZmFjZSZuYnNwO2JldHdlZW4mbmJzcDt0aGUmbmJzcDtuZXR3b3JrJm5ic3A7c2Vydmlj
ZSZuYnNwO3N5c3RlbSZuYnNwOyhlbmhhbmNlZCZuYnNwO09TUzwvRElWPg0KPERJVj4mZ3Q7
Jm5ic3A7aW4mbmJzcDt0aGUmbmJzcDthYm92ZSZuYnNwO2ZpZ3VyZS48L0RJVj4NCjxESVY+
Jmd0OyZuYnNwO1BsZWFzZSZuYnNwO25vdGUmbmJzcDt0aGF0Jm5ic3A7d2UmbmJzcDtzYXkm
bmJzcDt0aGF0Jm5ic3A7d2UmbmJzcDtpbml0aWFsbHkmbmJzcDtvbmx5Jm5ic3A7Zm9jdXMm
bmJzcDtvbiZuYnNwO3RoaXMmbmJzcDtpbnRlcmZhY2UsJm5ic3A7aW48L0RJVj4NCjxESVY+
Jmd0OyZuYnNwO29yZGVyJm5ic3A7dG8mbmJzcDtuYXJyb3cmbmJzcDtkb3duJm5ic3A7dGhl
Jm5ic3A7c2NvcGUmbmJzcDtvZiZuYnNwO3RoaXMmbmJzcDthY3Rpdml0eTwvRElWPg0KPERJ
Vj4mZ3Q7PC9ESVY+DQo8RElWPiZndDsmbmJzcDtIb3dldmVyLCZuYnNwO2lmJm5ic3A7dGhl
cmUmbmJzcDthcmUmbmJzcDtzdXBwb3J0cyZuYnNwO3RoYXQmbmJzcDt0aGluayZuYnNwO3dl
Jm5ic3A7c2hvdWxkJm5ic3A7aW5pdGlhbGx5Jm5ic3A7Zm9jdXMmbmJzcDthbHNvJm5ic3A7
b248L0RJVj4NCjxESVY+Jmd0OyZuYnNwO3RoZSZuYnNwO2ludGVyZmFjZSZuYnNwO2JldHdl
ZW4mbmJzcDtlbmQmbmJzcDt1c2VyJm5ic3A7YXBwbGljYXRpb24mbmJzcDthbmQmbmJzcDtj
b250cm9sbGVyJm5ic3A7d2UmbmJzcDt3aWxsJm5ic3A7YWxzbyZuYnNwO2luY2x1ZGU8L0RJ
Vj4NCjxESVY+Jmd0OyZuYnNwO3RoaXMmbmJzcDtpbnRlcmZhY2UmbmJzcDtpbiZuYnNwO3Ro
ZSZuYnNwO3Njb3BlLjwvRElWPg0KPERJVj4mZ3Q7PC9ESVY+DQo8RElWPiZndDsmbmJzcDtb
V2lsbF06Jm5ic3A7Rmlyc3QmbmJzcDtvZiZuYnNwO2FsbCwmbmJzcDtJTU9ILCZuYnNwO3Ro
ZSZuYnNwO2ZpZ3VyZXMmbmJzcDtmcm9tJm5ic3A7QmVub2l0Jm5ic3A7YW5kJm5ic3A7R2Vv
cmdpb3MmbmJzcDthcmUmbmJzcDtub3Q8L0RJVj4NCjxESVY+Jmd0OyZuYnNwO2luY29tcGF0
aWJsZS4mbmJzcDtGcm9tJm5ic3A7dGhlJm5ic3A7cGVyc3BlY3RpdmUmbmJzcDtvZiZuYnNw
O2NvbnRyb2xsZXIsJm5ic3A7dGhleSZuYnNwO2FyZSZuYnNwO2RpZmZlcmVudCZuYnNwO2xh
dGl0dWRlczwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7b2YmbmJzcDtub3J0aGJhbmQuJm5ic3A7
VGhlJm5ic3A7YXBwbGljYXRpb24mbmJzcDthbmQmbmJzcDtlbmhhbmNlZCZuYnNwO09TUyZu
YnNwO2luJm5ic3A7R2Vvcmdpb3MmbmJzcDtmaWd1cmUmbmJzcDtjYW4mbmJzcDtiZSZuYnNw
O3B1dDwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7dG9nZXRoZXImbmJzcDtpbnRvJm5ic3A7YW4m
bmJzcDtsYXJnZXImbmJzcDthcHBsaWNhdGlvbiombmJzcDtsYXllciZuYnNwO29mJm5ic3A7
QmVub2l04oCZcyZuYnNwO2ZpZ3VyZS4mbmJzcDtUaGUmbmJzcDtuZXR3b3JrPC9ESVY+DQo8
RElWPiZndDsmbmJzcDtncmFwaCZuYnNwO2lzJm5ic3A7cHJvcG9zZWQmbmJzcDt0byZuYnNw
O3Byb3ZpZGUmbmJzcDtuZXR3b3JrLXdpZGUmbmJzcDtjb25maWd1cmF0aW9uJm5ic3A7Y29u
dGFpbmluZyZuYnNwO3RoZSZuYnNwO2tleTwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7aW5mb3Jt
YXRpb24mbmJzcDtmb3ImbmJzcDtzZXJ2aWNlJm5ic3A7aW5zdGFuY2VzLiZuYnNwO09uZSZu
YnNwO2V4YW1wbGUmbmJzcDtpcywmbmJzcDtmb3ImbmJzcDt0aGUmbmJzcDtEREMmbmJzcDt1
c2UmbmJzcDtjYXNlLCZuYnNwO3RoZTwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7bmV0d29yayZu
YnNwO2dyYXBoJm5ic3A7Y29udGFpbnMmbmJzcDt0aGUmbmJzcDtrZXkmbmJzcDtpbmZvcm1h
dGlvbiZuYnNwO3N1Y2gmbmJzcDthcyZuYnNwO3RoZSZuYnNwO2tleSZuYnNwO25vZGUmbmJz
cDtpbmZvcm1hdGlvbiZuYnNwO29mPC9ESVY+DQo8RElWPiZndDsmbmJzcDt0aGUmbmJzcDtw
YXRoJm5ic3A7YW5kJm5ic3A7dGhlJm5ic3A7a2V5Jm5ic3A7cmVxdWlyZW1lbnQmbmJzcDtv
ZiZuYnNwO3RyYWZmaWMmbmJzcDtzdGVlcmluZy48L0RJVj4NCjxESVY+Jmd0OzwvRElWPg0K
PERJVj4mZ3Q7Jm5ic3A7UmVnYXJkaW5nJm5ic3A7dG8mbmJzcDt0aGUmbmJzcDthcHAsJm5i
c3A7bWFuYWdlbWVudCZuYnNwO2FwcCwmbmJzcDtlbmQmbmJzcDt1c2VyJm5ic3A7YXBwJm5i
c3A7aGVyZSwmbmJzcDtJJm5ic3A7d2FudCZuYnNwO3RvJm5ic3A7YWRkPC9ESVY+DQo8RElW
PiZndDsmbmJzcDtzb21ldGhpbmcmbmJzcDtyZWxhdGVkJm5ic3A7dG8mbmJzcDt0aGUmbmJz
cDtoaXN0b3J5Jm5ic3A7b2YmbmJzcDt0aGlzJm5ic3A7d29yay4mbmJzcDtBdCZuYnNwO3Ro
ZSZuYnNwO3ZlcnkmbmJzcDtiZWdpbm5pbmcsJm5ic3A7d2hlbjwvRElWPg0KPERJVj4mZ3Q7
Jm5ic3A7dGhpcyZuYnNwO3dvcmsmbmJzcDtpcyZuYnNwO2NhbGwmbmJzcDtBUE9ORiZuYnNw
O2JlZm9yZSZuYnNwO1Rvcm9udG8mbmJzcDtJRVRGJm5ic3A7bWVldGluZywmbmJzcDt0aGUm
bmJzcDtlbmQmbmJzcDt1c2VyJm5ic3A7YXBwJm5ic3A7aXMmbmJzcDtpbjwvRElWPg0KPERJ
Vj4mZ3Q7Jm5ic3A7dGhlJm5ic3A7c2NvcGUuJm5ic3A7SG93ZXZlciwmbmJzcDt0aGVyZSZu
YnNwO2FyZSZuYnNwO21haW5seSZuYnNwO3RocmVlJm5ic3A7cmVhc29ucyZuYnNwO3RoYXQm
bmJzcDt3ZSZuYnNwO3JlbW92ZSZuYnNwO3RoaXMmbmJzcDtwb2ludDo8L0RJVj4NCjxESVY+
Jmd0OyZuYnNwOzEuJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7VGhlJm5i
c3A7Y29uZmxpY3Rpb24mbmJzcDt3aXRoJm5ic3A7QUVDT04sJm5ic3A7d2UmbmJzcDtkaXNj
dXNzZWQmbmJzcDt3aXRoJm5ic3A7cHJvcG9uZW50cyZuYnNwO29mJm5ic3A7QUVDT04mbmJz
cDthbmQ8L0RJVj4NCjxESVY+Jmd0OyZuYnNwO3RvJm5ic3A7YXZvaWQmbmJzcDt0aGUmbmJz
cDtjb25mbGljdCZuYnNwO2FzJm5ic3A7YXQmbmJzcDt0aGF0Jm5ic3A7dGltZSZuYnNwO3Ro
ZXkmbmJzcDt3ZXJlJm5ic3A7cHJvcG9zaW5nJm5ic3A7dGhlJm5ic3A7aW50ZXJmYWNlJm5i
c3A7ZnJvbTwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7ZW5kJm5ic3A7dXNlciZuYnNwO2FwcCZu
YnNwO3RvJm5ic3A7bmV0d29yayZuYnNwO2RldmljZXMuJm5ic3A7TGF0ZXImbmJzcDtpbiZu
YnNwO3RoZSZuYnNwO0lFU0cmbmJzcDttZWV0aW5nJm5ic3A7aW4mbmJzcDtUb3JvbnRvLCZu
YnNwO3dlPC9ESVY+DQo8RElWPiZndDsmbmJzcDtzdWNjZXNzZnVsbHkmbmJzcDtjbGFyaWZp
ZWQmbmJzcDt0aGUmbmJzcDtkaWZmZXJlbmNlcyZuYnNwO2FuZCZuYnNwO2dvdCZuYnNwO3Ro
ZSZuYnNwO3N1Z2dlc3Rpb24mbmJzcDt0byZuYnNwO2ZvY3VzJm5ic3A7b248L0RJVj4NCjxE
SVY+Jmd0OyZuYnNwO21hbmFnZW1lbnQmbmJzcDthcHAuPC9ESVY+DQo8RElWPiZndDsmbmJz
cDsyLiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0xhcnMmbmJzcDtFZ2dl
cnQmbmJzcDtzaG93ZWQmbmJzcDtoaXMmbmJzcDtjb25jZXJuaW5nJm5ic3A7YWJvdXQmbmJz
cDt0aGUmbmJzcDtpbnRlcmZhY2UmbmJzcDtiZXR3ZWVuJm5ic3A7ZW5kJm5ic3A7dXNlcjwv
RElWPg0KPERJVj4mZ3Q7Jm5ic3A7YXBwJm5ic3A7YW5kJm5ic3A7bmV0d29yayZuYnNwO2Rl
dmljZXMmbmJzcDttYXkmbmJzcDtsZWFkJm5ic3A7dG8mbmJzcDtzZWN1cml0eSZuYnNwO2lz
c3VlLiZuYnNwOyZuYnNwO0tvc3RhcyZuYnNwO1BlbnRpa291c2lzJm5ic3A7YWxzbzwvRElW
Pg0KPERJVj4mZ3Q7Jm5ic3A7bWVudGlvbmVkJm5ic3A7dGhpcyZuYnNwO3RvJm5ic3A7bWUu
PC9ESVY+DQo8RElWPiZndDs8L0RJVj4NCjxESVY+Jmd0OyZuYnNwO0hvd2V2ZXIsJm5ic3A7
dGhlc2UmbmJzcDthcmUmbmJzcDtvbGQmbmJzcDtzdG9yaWVzLiZuYnNwO0R1cmluZyZuYnNw
O3RoZSZuYnNwO1Rvcm9udG8mbmJzcDtCb0YsJm5ic3A7c29tZW9uZSZuYnNwO2Fsc28mbmJz
cDtzdWdnZXN0ZWQ8L0RJVj4NCjxESVY+Jmd0OyZuYnNwO3VzJm5ic3A7cmUtcHV0Jm5ic3A7
dGhlJm5ic3A7ZW5kJm5ic3A7dXNlciZuYnNwO2FwcCZuYnNwO2ludG8mbmJzcDtjb3BlLiZu
YnNwO0EmbmJzcDtsYXJnZSZuYnNwO2FwcCZuYnNwO2xheWVyJm5ic3A7Y29udGFpbmluZyZu
YnNwO2JvdGgmbmJzcDtlbmQ8L0RJVj4NCjxESVY+Jmd0OyZuYnNwO3VzZXImbmJzcDthcHAm
bmJzcDthbmQmbmJzcDttYW5hZ2VtZW50Jm5ic3A7YXBwJm5ic3A7bWF5Jm5ic3A7cmVwbGFj
ZSZuYnNwO3RoZSZuYnNwO2ZpcnN0Jm5ic3A7dHdvJm5ic3A7bGF5ZXJzJm5ic3A7aW4mbmJz
cDt0aGUmbmJzcDtvbGQmbmJzcDs0PC9ESVY+DQo8RElWPiZndDsmbmJzcDtsYXllcnMmbmJz
cDtmaWd1cmUuJm5ic3A7SGVyZSwmbmJzcDtteSZuYnNwO3F1ZXN0aW9uJm5ic3A7aXMsJm5i
c3A7YXJlJm5ic3A7eW91Jm5ic3A7aW4mbmJzcDtmYXZvciZuYnNwO29mJm5ic3A7YWRkaW5n
Jm5ic3A7ZW5kJm5ic3A7dXNlciZuYnNwO2FwcDwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7aW50
byZuYnNwO1NVUEEmbmJzcDtzY29wZSZuYnNwO29yJm5ic3A7bm90PzwvRElWPg0KPERJVj4m
Z3Q7PC9ESVY+DQo8RElWPiZndDs8L0RJVj4NCjxESVY+Jmd0OyZuYnNwO1JlZ2FyZGluZyZu
YnNwO3lvdXImbmJzcDtjb21tZW50LCZuYnNwOyImbmJzcDtJJ20mbmJzcDtub3QmbmJzcDtj
b252aW5jZWQmbmJzcDt3ZSZuYnNwO2NvdWxkJm5ic3A7c3RhbmRhcmRpemUmbmJzcDt0aGVt
LCZuYnNwO2FzJm5ic3A7dGhleTwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7YXJlJm5ic3A7b3Bl
cmF0b3JzJm5ic3A7c3BlY2lmaWMsJm5ic3A7YW5kJm5ic3A7d2lsbCZuYnNwO2JlJm5ic3A7
ZXZvbHZpbmcmbmJzcDthbG9uZyZuYnNwO3RoZSZuYnNwO3RpbWUuJm5ic3A7VGhlcmUmbmJz
cDthcmUmbmJzcDttYW55PC9ESVY+DQo8RElWPiZndDsmbmJzcDtkaWZmZXJlbnQmbmJzcDt3
YXlzJm5ic3A7dG8mbmJzcDtjb25maWd1cmUmbmJzcDthJm5ic3A7VlBOLCZuYnNwO2ZvciZu
YnNwO2V4YW1wbGUuIiZuYnNwO1dlcmUmbmJzcDt5b3UmbmJzcDtyZWZlcnJpbmcmbmJzcDt0
bzo8L0RJVj4NCjxESVY+Jmd0OyZuYnNwOzMuJm5ic3A7RGV2aWNlL2ZlYXR1cmUmbmJzcDtz
cGVjaWZpYyZuYnNwO1lhbmcmbmJzcDtNb2RlbHM/PC9ESVY+DQo8RElWPiZndDsmbmJzcDtO
bywmbmJzcDt0aGUmbmJzcDtzZXJ2aWNlJm5ic3A7WUFORyZuYnNwO21vZGVsczwvRElWPg0K
PERJVj4mZ3Q7PC9ESVY+DQo8RElWPiZndDsmbmJzcDtHZW9yZ2lvczombmJzcDtJJm5ic3A7
c2VlLCZuYnNwO2J1dCZuYnNwO3dlJm5ic3A7Y2FuJm5ic3A7d29yayZuYnNwO29uJm5ic3A7
WUFORyZuYnNwO21vZGVscyZuYnNwO3RoYXQmbmJzcDtjYW4mbmJzcDtiZSZuYnNwO3VzZWQm
bmJzcDtmb3ImbmJzcDthJm5ic3A7bnVtYmVyPC9ESVY+DQo8RElWPiZndDsmbmJzcDtvZiZu
YnNwO21haW4mbmJzcDtuZXR3b3JrJm5ic3A7c2VydmljZXMsJm5ic3A7d2hpY2gmbmJzcDth
cmUmbmJzcDtlc3NlbnRpYWwmbmJzcDtmb3ImbmJzcDtvcGVyYXRvcnMmbmJzcDthbmQmbmJz
cDt0aGF0Jm5ic3A7dGhleTwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7d291bGQmbmJzcDtsaWtl
Jm5ic3A7dG8mbmJzcDtoYXZlJm5ic3A7dGhlbSZuYnNwO3N0YW5kYXJkaXplZC48L0RJVj4N
CjxESVY+Jmd0OzwvRElWPg0KPERJVj4mZ3Q7PC9ESVY+DQo8RElWPiZndDs8L0RJVj4NCjxE
SVY+Jmd0OyZuYnNwO1NlZSZuYnNwO2luLWxpbmU8L0RJVj4NCjxESVY+Jmd0OyZuYnNwO0Rl
YXImbmJzcDthbGwsPC9ESVY+DQo8RElWPiZndDs8L0RJVj4NCjxESVY+Jmd0OyZuYnNwO0hv
cGUmbmJzcDt0aGlzJm5ic3A7dmVyc2lvbiZuYnNwO29mJm5ic3A7ZHJhZnQmbmJzcDtjaGFy
dGVyJm5ic3A7YWRkcmVzcyZuYnNwO21vc3QmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2NvbW1l
bnRzJm5ic3A7ZnJvbSZuYnNwO3RoZSZuYnNwO2xpc3QuPC9ESVY+DQo8RElWPiZndDs8L0RJ
Vj4NCjxESVY+Jmd0OyZuYnNwOy0tLS0tLTwvRElWPg0KPERJVj4mZ3Q7PC9ESVY+DQo8RElW
PiZndDs8L0RJVj4NCjxESVY+Jmd0OzwvRElWPg0KPERJVj4mZ3Q7PC9ESVY+DQo8RElWPiZn
dDsmbmJzcDtJbiZuYnNwO3BhcnRpY3VsYXIsJm5ic3A7YXMmbmJzcDtzdGFydGluZyZuYnNw
O3BvaW50LCZuYnNwO1NVUEEmbmJzcDt3aWxsJm5ic3A7b25seSZuYnNwO2ZvY3VzJm5ic3A7
b24mbmJzcDtuZXR3b3JrJm5ic3A7c2VydmljZXMsPC9ESVY+DQo8RElWPiZndDsmbmJzcDt3
aGljaCZuYnNwO2FyZSZuYnNwO2VuaGFuY2VkJm5ic3A7T3BlcmF0aW9uYWwmbmJzcDtTdXBw
b3J0Jm5ic3A7U3lzdGVtJm5ic3A7KE9TUykmbmJzcDtsaWtlJm5ic3A7c2VydmljZXMmbmJz
cDt0aGF0Jm5ic3A7aGVscCZuYnNwO2E8L0RJVj4NCjxESVY+Jmd0OyZuYnNwO2NvbW11bmlj
YXRpb24mbmJzcDtzZXJ2aWNlJm5ic3A7cHJvdmlkZXImbmJzcDt0byZuYnNwO21vbml0b3Is
Jm5ic3A7Y29udHJvbCwmbmJzcDthbmFseXplJm5ic3A7YW5kJm5ic3A7bWFuYWdlJm5ic3A7
YTwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO25ldHdvcmsuJm5i
c3A7VGhlJm5ic3A7c3lzdGVtcyZuYnNwO3RoYXQmbmJzcDthcmUmbmJzcDtydW5uaXVuZyZu
YnNwO3N1Y2gmbmJzcDtuZXR3b3JrJm5ic3A7c2VydmljZXMmbmJzcDthcmU8L0RJVj4NCjxE
SVY+Jmd0OyZuYnNwO2Rlbm90ZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDtkb2N1bWVudCZu
YnNwO2FzJm5ic3A7TmV0d29yayZuYnNwO1NlcnZpY2UmbmJzcDtTeXN0ZW1zLjwvRElWPg0K
PERJVj4mZ3Q7Jm5ic3A7RWFjaCZuYnNwO25ldHdvcmsmbmJzcDtzZXJ2aWNlJm5ic3A7Y2Fu
Jm5ic3A7YmUmbmJzcDtyZXByZXNlbnRlZCZuYnNwO2J5Jm5ic3A7YSZuYnNwO2NsYXNzaWZp
ZWQmbmJzcDthcHBsaWNhdGlvbiZuYnNwO2Jhc2VkPC9ESVY+DQo8RElWPiZndDsmbmJzcDtQ
T0xJQ1kmbmJzcDttb2RlbCwmbmJzcDtzaW5jZSZuYnNwO2l0Jm5ic3A7Y2FuJm5ic3A7bW9k
ZWwmbmJzcDt0aGUmbmJzcDtncm91cCZuYnNwO29mJm5ic3A7ZGVtYW5kcyZuYnNwO3doaWNo
Jm5ic3A7YXJlJm5ic3A7U0hBUkVEJm5ic3A7YW5kPC9ESVY+DQo8RElWPiZndDsmbmJzcDtV
TklGSUVEJm5ic3A7YW5kJm5ic3A7YXJlJm5ic3A7Y29taW5nJm5ic3A7ZnJvbSZuYnNwO2Em
bmJzcDtidW5kbGUmbmJzcDtvZiZuYnNwO2FwcGxpY2F0aW9ucyZuYnNwO3RoYXQmbmJzcDtp
bXBvc2UmbmJzcDtzaW1pbGFyPC9ESVY+DQo8RElWPiZndDsmbmJzcDtyZXF1aXJlbWVudHMm
bmJzcDtvbiZuYnNwO3RoZSZuYnNwO2NvbW11bmljYXRpb24mbmJzcDtuZXR3b3JrLjwvRElW
Pg0KPERJVj4mZ3Q7Jm5ic3A7SSdtJm5ic3A7YWZyYWlkJm5ic3A7SSZuYnNwO2Rvbid0Jm5i
c3A7dW5kZXJzdGFuZCZuYnNwOyhsaWtlJm5ic3A7SsO8cmdlbik8L0RJVj4NCjxESVY+Jmd0
OzwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7R2Vvcmdpb3M6Jm5ic3A7V2hhdCZuYnNwO3dlJm5i
c3A7d2FudCZuYnNwO3RvJm5ic3A7c2F5Jm5ic3A7aXMmbmJzcDt0aGF0Jm5ic3A7dGhlcmUm
bmJzcDthcmUmbmJzcDthcHBsaWNhdGlvbnMmbmJzcDt0aGF0Jm5ic3A7aW1wb3NlPC9ESVY+
DQo8RElWPiZndDsmbmJzcDtzaW1pbGFyJm5ic3A7cmVxdWlyZW1lbnRzJm5ic3A7b24mbmJz
cDt0aGUmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7bmV0d29yay4mbmJzcDtGb3ImbmJzcDtl
YWNoJm5ic3A7Z3JvdXAmbmJzcDtvZiZuYnNwO3N1Y2gmbmJzcDtidWxrPC9ESVY+DQo8RElW
PiZndDsmbmJzcDtvZiZuYnNwO2FwcGxpY2F0aW9ucyZuYnNwO2EmbmJzcDtuZXR3b3JrJm5i
c3A7c2VydmljZSZuYnNwO2NhbiZuYnNwO2JlJm5ic3A7ZGVmaW5lZCZuYnNwO3RoYXQmbmJz
cDtjYW4mbmJzcDtiZSZuYnNwO3JlcHJlc2VudGVkJm5ic3A7YnkmbmJzcDthPC9ESVY+DQo8
RElWPiZndDsmbmJzcDtzZXJ2aWNlJm5ic3A7cG9saWN5Jm5ic3A7bW9kZWwmbmJzcDsoaS5l
LiwmbmJzcDtpdHMmbmJzcDthY3Rpb25zJm5ic3A7YW5kJm5ic3A7Y29uc3RyYWludHMpLjwv
RElWPg0KPERJVj4mZ3Q7PC9ESVY+DQo8RElWPiZndDs8L0RJVj4NCjxESVY+Jmd0OyZuYnNw
O0dlb3JnaW9zOiZuYnNwO1RoYW5rcyZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO3N1Z2dlc3Rp
b24sJm5ic3A7dGhlJm5ic3A7dGV4dCZuYnNwO25lZWRzJm5ic3A7dG8mbmJzcDtiZSZuYnNw
O3JlcGhyYXNlZCwmbmJzcDtzZWUmbmJzcDtiZWxvdzo8L0RJVj4NCjxESVY+Jmd0OyZuYnNw
O0VhY2gmbmJzcDtuZXR3b3JrJm5ic3A7c2VydmljZSZuYnNwO2NhbiZuYnNwO2JlJm5ic3A7
cmVwcmVzZW50ZWQmbmJzcDtieSZuYnNwO2FuJm5ic3A7YXBwbGljYXRpb24mbmJzcDtiYXNl
ZCZuYnNwO1BPTElDWSZuYnNwO21vZGVsLDwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7d2hpY2gm
bmJzcDtpcyZuYnNwO1VOSUZJRUQmbmJzcDthbmQmbmJzcDtTSEFSRUQsJm5ic3A7c2luY2Um
bmJzcDtpdCZuYnNwO2NhbiZuYnNwO21vZGVsJm5ic3A7dGhlJm5ic3A7Z3JvdXAmbmJzcDtv
ZiZuYnNwO2RlbWFuZHMmbmJzcDsoaS5lLDwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7YWN0aW9u
cyZuYnNwO2FuZCZuYnNwO2NvbnN0cmFpbnRzKSZuYnNwO3RoYXQmbmJzcDthcmUmbmJzcDtj
b21pbmcmbmJzcDtmcm9tJm5ic3A7YSZuYnNwO2J1bmRsZSZuYnNwO29mJm5ic3A7YXBwbGlj
YXRpb25zJm5ic3A7dGhhdDwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7aW1wb3NlJm5ic3A7c2lt
aWxhciZuYnNwO3JlcXVpcmVtZW50cyZuYnNwO29uJm5ic3A7dGhlJm5ic3A7Y29tbXVuaWNh
dGlvbiZuYnNwO25ldHdvcmsuPC9ESVY+DQo8RElWPiZndDsmbmJzcDtJJm5ic3A7c3RpbGwm
bmJzcDtkb24ndCZuYnNwO3VuZGVyc3RhbmQuJm5ic3A7d2hhdCZuYnNwOyJVTklGSUVEJm5i
c3A7YW5kJm5ic3A7U0hBUkVEIiZuYnNwO21lYW4uPC9ESVY+DQo8RElWPiZndDs8L0RJVj4N
CjxESVY+Jmd0OyZuYnNwO0dlb3JnaW9zOiZuYnNwO3RoZSZuYnNwO3Rlcm1zJm5ic3A74oCc
VU5JRklFROKAnSZuYnNwO2FuZCZuYnNwO+KAnFNIQVJFROKAneKAnSZuYnNwO3JlbGF0ZSZu
YnNwO3RvJm5ic3A7dGhlJm5ic3A7d2F5Jm5ic3A7b2YmbmJzcDtob3cmbmJzcDt0aGU8L0RJ
Vj4NCjxESVY+Jmd0OyZuYnNwO3NlcnZpY2UmbmJzcDtwb2xpY3kmbmJzcDttb2RlbCZuYnNw
O2lzJm5ic3A7Z2VuZXJhdGVkLCZuYnNwO3NpbmNlJm5ic3A7aXQmbmJzcDtncm91cHMmbmJz
cDthbmQmbmJzcDtpdCZuYnNwO3VuaWZpZXMmbmJzcDthbmQmbmJzcDtzaGFyZXM8L0RJVj4N
CjxESVY+Jmd0OyZuYnNwO3RoZSZuYnNwO3NpbWlsYXImbmJzcDtyZXF1aXJlbWVudHMmbmJz
cDtpbXBvc2VkJm5ic3A7YnkmbmJzcDthJm5ic3A7YnVsayZuYnNwO29mJm5ic3A7YXBwbGlj
YXRpb25zLjwvRElWPg0KPERJVj4mZ3Q7PC9ESVY+DQo8RElWPiZndDs8L0RJVj4NCjxESVY+
Jmd0OzwvRElWPg0KPERJVj4mZ3Q7PC9ESVY+DQo8RElWPiZndDs8L0RJVj4NCjxESVY+Jmd0
OzwvRElWPg0KPERJVj4mZ3Q7PC9ESVY+DQo8RElWPiZndDsmbmJzcDsoMikmbmJzcDt0cmFu
c3BvcnRpbmcmbmJzcDttb2RlbCZuYnNwO2luc3RhbmNlcyZuYnNwO2VpdGhlciZuYnNwO3Vz
aW5nJm5ic3A7TkVUQ09ORiZuYnNwO29yJm5ic3A7UkVTVENPTkYmbmJzcDthbmQmbmJzcDso
Myk8L0RJVj4NCjxESVY+Jmd0OyZuYnNwO3Byb3ZpZGluZyZuYnNwO2d1aWRlbGluZXMmbmJz
cDtvbiZuYnNwO0FVVE9NQVRJQ0FMTFkmbmJzcDttYXBwaW5nJm5ic3A7cG9saWNpZXMmbmJz
cDt0byZuYnNwO2F0dHJpYnV0ZXMmbmJzcDtvZiZuYnNwO3RoZTwvRElWPg0KPERJVj4mZ3Q7
Jm5ic3A7bmV0d29yayZuYnNwO2dyYXBocy48L0RJVj4NCjxESVY+Jmd0OzwvRElWPg0KPERJ
Vj4mZ3Q7Jm5ic3A7QWx0aG91Z2gmbmJzcDtzb21lJm5ic3A7SUVURiZuYnNwO3dvcmtpbmcm
bmJzcDtncm91cHMmbmJzcDtoYXZlJm5ic3A7c3RhcnRlZCZuYnNwO3dvcmsmbmJzcDtyZWxh
dGluZyZuYnNwO3RvJm5ic3A7dGhlPC9ESVY+DQo8RElWPiZndDsmbmJzcDtkZXNjcmlwdGlv
biZuYnNwO29mJm5ic3A7dmFyaW91cyZuYnNwO3RvcG9sb2dpZXMmbmJzcDtzdWNoJm5ic3A7
YXMmbmJzcDtJMlJTJm5ic3A7KEwzYW5kJm5ic3A7cm91dGluZyZuYnNwO3RvcG9sb2dpZXMp
LDwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7QUxUTyZuYnNwOyhjb3N0Jm5ic3A7bWFwcyksJm5i
c3A7U0ZDJm5ic3A7KHNlcnZpY2UmbmJzcDtjaGFpbiksJm5ic3A7bm9uZSZuYnNwO29mJm5i
c3A7dGhlc2UmbmJzcDtncm91cHMmbmJzcDthaW0mbmJzcDthdCZuYnNwO29mZmVyaW5nPC9E
SVY+DQo8RElWPiZndDsmbmJzcDt0cnVseSZuYnNwO2dlbmVyaWMmbmJzcDt0b3BvbG9neSZu
YnNwO21vZGVscyZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO3N0YW5kYXJkJm5ic3A7bm9ydGhi
b3VuZCZuYnNwO2ludGVyZmFjZS48L0RJVj4NCjxESVY+Jmd0OyZuYnNwO1NVUEEmbmJzcDt3
aWxsJm5ic3A7d29yayZuYnNwO29uJm5ic3A7ZGVmaW5pbmcmbmJzcDtpbnRlcmZhY2VzJm5i
c3A7YmFzZWQmbmJzcDtvbiZuYnNwO3RoZSZuYnNwO2NvbmNlcHQmbmJzcDtvZiZuYnNwO25l
dHdvcmsmbmJzcDtncmFwaCw8L0RJVj4NCjxESVY+Jmd0OyZuYnNwO2FuJm5ic3A7ZW50aXR5
Jm5ic3A7ZGVzY3JpYmluZyZuYnNwO2FuJm5ic3A7YXJiaXRyYXJ5Jm5ic3A7dG9wb2xvZ3km
bmJzcDtvZiZuYnNwO25vZGVzJm5ic3A7YW5kJm5ic3A7bGlua3MmbmJzcDthdCZuYnNwO2Fu
eSZuYnNwO2xldmVsJm5ic3A7b2Y8L0RJVj4NCjxESVY+Jmd0OyZuYnNwO2dyYW51bGFyaXR5
LiZuYnNwO1N1Y2gmbmJzcDthJm5ic3A7Z3JhcGgmbmJzcDttYXkmbmJzcDtkZXNjcmliZSwm
bmJzcDtmb3ImbmJzcDtleGFtcGxlLCZuYnNwO2EmbmJzcDtwaHlzaWNhbCZuYnNwO3RvcG9s
b2d5LCZuYnNwO2E8L0RJVj4NCjxESVY+Jmd0OyZuYnNwO3NlcnZpY2UmbmJzcDt0b3BvbG9n
eSZuYnNwO29yJm5ic3A7dGhlJm5ic3A7cmVsYXRpb25zaGlwcyZuYnNwO2JldHdlZW4mbmJz
cDtkYXRhY2VudGVycy4mbmJzcDtBbnkmbmJzcDtuZXR3b3JrPC9ESVY+DQo8RElWPiZndDsm
bmJzcDt0b3BvbG9neSZuYnNwO2RhdGEmbmJzcDttb2RlbHMmbmJzcDtvciZuYnNwO3BvbGlj
eSZuYnNwO21vZGVscyZuYnNwO3RoYXQmbmJzcDtoYXZlJm5ic3A7YmVlbiZuYnNwO2RlZmlu
ZWQmbmJzcDsob3ImbmJzcDthcmUmbmJzcDtiZWluZzwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7
ZGVmaW5lZCkmbmJzcDt3aXRoaW4mbmJzcDt0aGUmbmJzcDtJRVRGJm5ic3A7d2lsbCZuYnNw
O2JlJm5ic3A7cmV1c2VkJm5ic3A7aW4mbmJzcDtTVVBBJm5ic3A7YXMmbmJzcDttdWNoJm5i
c3A7YXMmbmJzcDtwb3NzaWJsZS48L0RJVj4NCjxESVY+Jmd0OyZuYnNwO0luJm5ic3A7YWRk
aXRpb24mbmJzcDt0byZuYnNwO3RoZSZuYnNwO2Fib3ZlLCZuYnNwO3BvbGljaWVzJm5ic3A7
bWF5Jm5ic3A7YmUmbmJzcDtkZWZpbmVkJm5ic3A7YW5kJm5ic3A7YXBwbGllZCZuYnNwO3Rv
Jm5ic3A7YSZuYnNwO25ldHdvcms8L0RJVj4NCjxESVY+Jmd0OyZuYnNwO2dyYXBoLiZuYnNw
O1RoZXNlJm5ic3A7YXBwbGljYXRpb24mbmJzcDtiYXNlZCZuYnNwO3BvbGljaWVzJm5ic3A7
YXJlJm5ic3A7YWN0aW9ucyZuYnNwO29yJm5ic3A7Y29uc3RyYWludHMmbmJzcDtnZW5lcmF0
ZWQ8L0RJVj4NCjxESVY+Jmd0OyZuYnNwO2J5Jm5ic3A7TmV0d29yayZuYnNwO1NlcnZpY2Um
bmJzcDtTeXN0ZW1zLiZuYnNwO1RoZXkmbmJzcDthcmUmbmJzcDt0aGVuJm5ic3A7bWFwcGVk
Jm5ic3A7ZnJvbSZuYnNwO3RoZSZuYnNwO25ldHdvcmsmbmJzcDtncmFwaDwvRElWPg0KPERJ
Vj4mZ3Q7Jm5ic3A7aW5zdGFuY2UmbmJzcDtpbnRvJm5ic3A7c3BlY2lmaWMmbmJzcDtuZXR3
b3JrJm5ic3A7bWFuYWdlbWVudCZuYnNwO3BvbGljaWVzJm5ic3A7dG93YXJkJm5ic3A7bmV0
d29yayZuYnNwO2NvbXBvbmVudHMuPC9ESVY+DQo8RElWPiZndDs8L0RJVj4NCjxESVY+Jmd0
OzwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7R2Vvcmdpb3M6Jm5ic3A7dGhlJm5ic3A7YWJvdmUm
bmJzcDt0ZXh0Jm5ic3A7aXMmbmJzcDtub3QmbmJzcDtjbGVhci4mbmJzcDtUaGVyZWZvcmUs
Jm5ic3A7SSZuYnNwO2FtJm5ic3A7cmVwaHJhc2luZyZuYnNwO2l0OjwvRElWPg0KPERJVj4m
Z3Q7Jm5ic3A7PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PC9ESVY+DQo8RElWPiZndDsmbmJzcDtUaGUmbmJzcDttYWluJm5ic3A7Z29hbCZuYnNwO29m
Jm5ic3A7U1VQQSZuYnNwO2lzJm5ic3A7dG8mbmJzcDtwcm92aWRlJm5ic3A7YXBwbGljYXRp
b24mbmJzcDtiYXNlZCZuYnNwO3BvbGljaWVzJm5ic3A7YW5kJm5ic3A7bWVhbnMmbmJzcDt0
bzwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7bW9kZWwmbmJzcDthbmQmbmJzcDtwcm9ncmFtJm5i
c3A7dGhlJm5ic3A7YWJzdHJhY3QmbmJzcDt2aWV3Jm5ic3A7b2YmbmJzcDtuZXR3b3JrJm5i
c3A7aW5mcmFzdHJ1Y3R1cmUmbmJzcDthbmQmbmJzcDtzZXJ2aWNlPC9ESVY+DQo8RElWPiZn
dDsmbmJzcDtmdW5jdGlvbiZuYnNwO2ludGVyZGVwZW5kZW5jaWVzJm5ic3A7aW4mbmJzcDtv
cmRlciZuYnNwO3RvJm5ic3A7c3VwcG9ydCZuYnNwO2FuZCZuYnNwO0FVVE9NQVRJQ0FMTFkm
bmJzcDtmZWVkJm5ic3A7bmV0d29yazwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7bWFuYWdlbWVu
dCZuYnNwO2FuZCZuYnNwO2NvbnRyb2xsaW5nJm5ic3A7cG9saWNpZXMuJm5ic3A7VGhpcyZu
YnNwO2NhbiZuYnNwO2JlJm5ic3A7cmVhbGl6ZWQmbmJzcDtieTo8L0RJVj4NCjxESVY+Jmd0
OzwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7KDEpJm5ic3A7bW9kZWxpbmcmbmJzcDt0aGUmbmJz
cDtuZXR3b3JrJm5ic3A7Z3JhcGgsJm5ic3A7d2hpY2gmbmJzcDthbW9uZyZuYnNwO290aGVy
cyZuYnNwO2luY2x1ZGUmbmJzcDtwb2xpY3kmbmJzcDttb2RlbHMsJm5ic3A7ZGF0YTwvRElW
Pg0KPERJVj4mZ3Q7Jm5ic3A7bW9kZWxzJm5ic3A7YW5kJm5ic3A7YXBwbGljYXRpb24mbmJz
cDtiYXNlZCZuYnNwO3BvbGljaWVzLCZuYnNwO3VzaW5nJm5ic3A7WUFORyw8L0RJVj4NCjxE
SVY+Jmd0OzwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7KDIpJm5ic3A7YXBwbHlpbmcmbmJzcDtO
RVRDT05GJm5ic3A7KG9yJm5ic3A7UkVTVENPTkYpJm5ic3A7dG8mbmJzcDtlbmFibGUmbmJz
cDtkaXNzZW1pbmF0aW9uJm5ic3A7b2YmbmJzcDt1cCZuYnNwO3RvJm5ic3A7ZGF0ZTwvRElW
Pg0KPERJVj4mZ3Q7Jm5ic3A7KGZyZXNoKSZuYnNwO25ldHdvcmsmbmJzcDtncmFwaHMmbmJz
cDtpbiZuYnNwO2EmbmJzcDtzZWN1cmUmbmJzcDthbmQmbmJzcDtlZmZpY2llbnQmbmJzcDtt
YW5uZXImbmJzcDtiZXR3ZWVuJm5ic3A7bmV0d29yazwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7
c2VydmljZSZuYnNwO3N5c3RlbXMmbmJzcDthbmQmbmJzcDtuZXR3b3JrJm5ic3A7bWFuYWdl
bWVudCZuYnNwO2FuZCZuYnNwO2NvbnRyb2xsaW5nJm5ic3A7c3lzdGVtcywmbmJzcDsiYmV0
d2VlbjwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7bmV0d29yayZuYnNwO3NlcnZpY2UmbmJzcDtz
eXN0ZW1zJm5ic3A7YW5kJm5ic3A7bmV0d29yayZuYnNwO21hbmFnZW1lbnQmbmJzcDthbmQm
bmJzcDtjb250cm9sbGluZyZuYnNwO3N5c3RlbSIuJm5ic3A7V2hhdDwvRElWPg0KPERJVj4m
Z3Q7Jm5ic3A7YXJlJm5ic3A7dGhvc2U/Jm5ic3A7SSZuYnNwO2Rvbid0Jm5ic3A7c2VlJm5i
c3A7dGhlbSZuYnNwO2luJm5ic3A7eW91ciZuYnNwO2ZpZ3VyZS48L0RJVj4NCjxESVY+Jmd0
OyZuYnNwO0Fsc28sJm5ic3A7d2h5Jm5ic3A7c2hvdWxkJm5ic3A7YWxsJm5ic3A7b2YmbmJz
cDt0aGVzZSZuYnNwO25lZWQmbmJzcDt0byZuYnNwO2tub3cmbmJzcDthYm91dCZuYnNwO3Ro
ZSZuYnNwO3RvcG9sb2d5PzwvRElWPg0KPERJVj4mZ3Q7PC9ESVY+DQo8RElWPiZndDsmbmJz
cDtHZW9yZ2lvczombmJzcDtJbiZuYnNwO3RoZSZuYnNwO2ZpZ3VyZSwmbmJzcDt0aGUmbmJz
cDtlbmhhbmNlZCZuYnNwO09TUyZuYnNwO3JlcHJlc2VudHMmbmJzcDt0aGUmbmJzcDtuZXR3
b3JrJm5ic3A7c2VydmljZTwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7c3lzdGVtJm5ic3A7YW5k
Jm5ic3A7dGhlJm5ic3A7Y29udHJvbGxlciZuYnNwO3JlcHJlc2VudHMmbmJzcDt0aGUmbmJz
cDtuZXR3b3JrJm5ic3A7bWFuYWdlbWVudCZuYnNwO2FuZCZuYnNwO2NvbnRyb2xsaW5nPC9E
SVY+DQo8RElWPiZndDsmbmJzcDtzeXN0ZW0uPC9ESVY+DQo8RElWPiZndDsmbmJzcDtJbiZu
YnNwO3RoaXMmbmJzcDtjb250ZXh0LCZuYnNwO25ldHdvcmsmbmJzcDtzZXJ2aWNlcyZuYnNw
O2NhbiZuYnNwO2JlJm5ic3A7dXNlZCZuYnNwO3RvJm5ic3A7cHJvdmlkZSZuYnNwO3RoZTwv
RElWPg0KPERJVj4mZ3Q7Jm5ic3A7cmVxdWlyZWQmbmJzcDsmbmJzcDtjb25maWd1cmF0aW9u
Jm5ic3A7YW5kJm5ic3A7YXBwbGljYXRpb24mbmJzcDtwcm9ncmFtbWluZyZuYnNwO2ludGVy
ZmFjZXMmbmJzcDt0byZuYnNwO3NlcnZpY2U8L0RJVj4NCjxESVY+Jmd0OyZuYnNwO2RldmVs
b3BlcnMuJm5ic3A7U3Vic2VxdWVudGx5LCZuYnNwO2EmbmJzcDtuZXR3b3JrJm5ic3A7c2Vy
dmljZSZuYnNwO2NhbiZuYnNwO3VzZSZuYnNwO3RoZSZuYnNwO2FwcGxpY2F0aW9uJm5ic3A7
YmFzZWQ8L0RJVj4NCjxESVY+Jmd0OyZuYnNwO2RlbWFuZHMmbmJzcDsoZm9yJm5ic3A7YWN0
aW9ucyZuYnNwO2FuZCZuYnNwO2NvbnN0cmFpbnRzKSZuYnNwO2FuZCZuYnNwO3Bvc3NpYmx5
Jm5ic3A7dXBkYXRlJm5ic3A7aXRzJm5ic3A7YXNzb2NpYXRlZDwvRElWPg0KPERJVj4mZ3Q7
Jm5ic3A7bmV0d29yayZuYnNwO3NlcnZpY2UmbmJzcDsmbmJzcDthdHRyaWJ1dGVzLiZuYnNw
O0V4YW1wbGVzJm5ic3A7b2YmbmJzcDtuZXR3b3JrJm5ic3A7c2VydmljZXMmbmJzcDt0aGF0
Jm5ic3A7Y2FuJm5ic3A7bW9kaWZ5Jm5ic3A7Jm5ic3A7dGhlPC9ESVY+DQo8RElWPiZndDsm
bmJzcDtuZXR3b3JrJm5ic3A7c2VydmljZSZuYnNwO2F0dHJpYnV0ZXMmbmJzcDthcmUmbmJz
cDtmb3ImbmJzcDtleGFtcGxlLCZuYnNwO0wzVlBOJm5ic3A7Y29uZmlndXJhdGlvbiZuYnNw
O2FuZCZuYnNwO0lQdjY8L0RJVj4NCjxESVY+Jmd0OyZuYnNwO3RyYW5zaXRpb25zLjwvRElW
Pg0KPERJVj4mZ3Q7Jm5ic3A7Rm9yJm5ic3A7ZWFjaCZuYnNwO25ldHdvcmsmbmJzcDtzZXJ2
aWNlJm5ic3A7aW5zdGFuY2UmbmJzcDthJm5ic3A7bmV0d29yayZuYnNwO2dyYXBoJm5ic3A7
bmVlZHMmbmJzcDt0byZuYnNwO2JlJm5ic3A7Z2VuZXJhdGVkJm5ic3A7YW5kPC9ESVY+DQo8
RElWPiZndDsmbmJzcDttYWludGFpbmVkLjwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7VGhlJm5i
c3A7dXAmbmJzcDt0byZuYnNwO2RhdGUmbmJzcDtuZXR3b3JrJm5ic3A7Z3JhcGgmbmJzcDtu
ZWVkcyZuYnNwO3RvJm5ic3A7KDEpJm5ic3A7YmUmbmJzcDtjb21tdW5pY2F0ZWQmbmJzcDti
ZXR3ZWVuJm5ic3A7dGhlJm5ic3A7Jm5ic3A7bmV0d29yazwvRElWPg0KPERJVj4mZ3Q7Jm5i
c3A7c2VydmljZSZuYnNwO3N5c3RlbXMmbmJzcDthbmQmbmJzcDt0aGUmbmJzcDtuZXR3b3Jr
Jm5ic3A7Jm5ic3A7Jm5ic3A7bWFuYWdlbWVudCZuYnNwO2FuZCZuYnNwO2NvbnRyb2xsaW5n
Jm5ic3A7c3lzdGVtcywmbmJzcDsoMikmbmJzcDttYXA8L0RJVj4NCjxESVY+Jmd0OyZuYnNw
O3RoZSZuYnNwO2F0dHJpYnV0ZXMmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO25ldHdvcmsmbmJz
cDtzZXJ2aWNlJm5ic3A7Z3JhcGgmbmJzcDtpbnRvJm5ic3A7c3BlY2lmaWMmbmJzcDtuZXR3
b3JrJm5ic3A7bWFuYWdlbWVudDwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7cG9saWNpZXMuPC9E
SVY+DQo8RElWPiZndDsmbmJzcDtbV2lsbF0mbmJzcDtUbyZuYnNwO21vZGVsaW5nJm5ic3A7
c2VydmljZSZuYnNwO3JlcXVpcmVtZW50Jm5ic3A7YW5kJm5ic3A7Y3JlYXRlJm5ic3A7c2Vy
dmljZSZuYnNwO2luc3RhbmNlcywmbmJzcDtBUFAmbmJzcDtuZWVkczwvRElWPg0KPERJVj4m
Z3Q7Jm5ic3A7YSZuYnNwO3ZpZXcmbmJzcDtvZiZuYnNwO3RvcG9sb2d5Jm5ic3A7dG8mbmJz
cDtmb3JtJm5ic3A7bmV0d29yayZuYnNwO2NvbmZpZ3VyYXRpb24mbmJzcDthY2NvcmRpbmcm
bmJzcDt0byZuYnNwO3RoZSZuYnNwO2tleTwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7aW5mb3Jt
YXRpb24mbmJzcDtvZiZuYnNwO2RldmljZXMmbmJzcDt0b3BvbG9neS4mbmJzcDtUaGlzJm5i
c3A7Y29uZmlndXJhdGlvbiZuYnNwO2lzJm5ic3A7ZXZlbnR1YWxseSZuYnNwO21hcHBlZCZu
YnNwO3RvPC9ESVY+DQo8RElWPiZndDsmbmJzcDt0aGUmbmJzcDtzZWxlY3RlZCZuYnNwO25l
dHdvcmsmbmJzcDtkZXZpY2VzJm5ic3A7YWNjb3JkaW5nJm5ic3A7dG8mbmJzcDt0b3BvbG9n
eSZuYnNwO3Byb3ZpZGVkJm5ic3A7YnkmbmJzcDtTVVBBLjwvRElWPg0KPERJVj4mZ3Q7PC9E
SVY+DQo8RElWPiZndDsmbmJzcDtCZXN0Jm5ic3A7cmVnYXJkcyw8L0RJVj4NCjxESVY+Jmd0
OyZuYnNwO0dlb3JnaW9zPC9ESVY+DQo8RElWPiZndDs8L0RJVj4NCjxESVY+Jmd0OzwvRElW
Pg0KPERJVj4mZ3Q7PC9ESVY+DQo8RElWPiZndDs8L0RJVj4NCjxESVY+Jmd0OzwvRElWPg0K
PERJVj4mZ3Q7Jm5ic3A7UmVnYXJkcywmbmJzcDtCZW5vaXQ8L0RJVj4NCjxESVY+Jmd0OyZu
YnNwO+WmguaenOaCqOmUmeivr+aOpeaUtuS6huivpemCruS7tu+8jOivt+mAmui/h+eUteWt
kOmCruS7tueri+WNs+mAmuefpeaIkeS7rOOAguivt+WbnuWkjemCruS7tuWIsGhxcy08L0RJ
Vj4NCjxESVY+Jmd0OyZuYnNwO3NwbWNAY2hpbmF1bmljb20uY27vvIzljbPlj6/ku6XpgIDo
rqLmraTpgq7ku7bjgILmiJHku6zlsIbnq4vljbPlsIbmgqjnmoTkv6Hmga/ku47miJHku6zn
moTlj5HpgIHnm67lvZXkuK3liKDpmaTjgII8L0RJVj4NCjxESVY+Jmd0OyZuYnNwO0lmJm5i
c3A7eW91Jm5ic3A7aGF2ZSZuYnNwO3JlY2VpdmVkJm5ic3A7dGhpcyZuYnNwO2VtYWlsJm5i
c3A7aW4mbmJzcDtlcnJvciZuYnNwO3BsZWFzZSZuYnNwO25vdGlmeSZuYnNwO3VzJm5ic3A7
aW1tZWRpYXRlbHkmbmJzcDtieSZuYnNwO2UtPC9ESVY+DQo8RElWPiZndDsmbmJzcDttYWls
LiZuYnNwO1BsZWFzZSZuYnNwO3JlcGx5Jm5ic3A7dG8mbmJzcDtocXMtc3BtY0BjaGluYXVu
aWNvbS5jbiZuYnNwO2lmJm5ic3A7eW91Jm5ic3A7d2FudCZuYnNwO3RvJm5ic3A7dW5zdWJz
Y3JpYmUmbmJzcDtmcm9tPC9ESVY+DQo8RElWPiZndDsmbmJzcDt0aGlzJm5ic3A7bWFpbC4m
bmJzcDtXZSZuYnNwO3dpbGwmbmJzcDtpbW1lZGlhdGVseSZuYnNwO3JlbW92ZSZuYnNwO3lv
dXImbmJzcDtpbmZvcm1hdGlvbiZuYnNwO2Zyb20mbmJzcDtvdXImbmJzcDtzZW5kaW5nPC9E
SVY+DQo8RElWPiZndDsmbmJzcDtjYXRhbG9ndWUuPC9ESVY+PC9GT05UPjwvRElWPjxwPuWm
guaenOaCqOmUmeivr+aOpeaUtuS6huivpemCruS7tu+8jOivt+mAmui/h+eUteWtkOmCruS7
tueri+WNs+mAmuefpeaIkeS7rOOAguivt+WbnuWkjemCruS7tuWIsGhxcy1zcG1jQGNoaW5h
dW5pY29tLmNu77yM5Y2z5Y+v5Lul6YCA6K6i5q2k6YKu5Lu244CC5oiR5Lus5bCG56uL5Y2z
5bCG5oKo55qE5L+h5oGv5LuO5oiR5Lus55qE5Y+R6YCB55uu5b2V5Lit5Yig6Zmk44CCDQpJ
ZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkg
dXMgaW1tZWRpYXRlbHkgYnkgZS1tYWlsLiBQbGVhc2UgcmVwbHkgdG8gaHFzLXNwbWNAY2hp
bmF1bmljb20uY24gaWYgeW91IHdhbnQgdG8gdW5zdWJzY3JpYmUgZnJvbSB0aGlzIG1haWwu
IFdlIHdpbGwgaW1tZWRpYXRlbHkgcmVtb3ZlIHlvdXIgaW5mb3JtYXRpb24gZnJvbSBvdXIg
c2VuZGluZyBjYXRhbG9ndWUuPC9wPg0KPC9CT0RZPjwvSFRNTD4NCg==

--=====003_Dragon221042328062_=====--


From nobody Thu Sep 25 23:46:16 2014
Return-Path: 
X-Original-To: supa@ietfa.amsl.com
Delivered-To: supa@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE81F1A1A43 for ; Thu, 25 Sep 2014 23:46:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.688
X-Spam-Level: 
X-Spam-Status: No, score=-2.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-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 71XRzwoVFscK for ; Thu, 25 Sep 2014 23:46:12 -0700 (PDT)
Received: from tsinghua.edu.cn (smtp03.tsinghua.edu.cn [166.111.204.32]) by ietfa.amsl.com (Postfix) with ESMTP id ACB161A02BA for ; Thu, 25 Sep 2014 23:46:11 -0700 (PDT)
Received: from junbithinkpadx1 (unknown [59.66.24.165]) by app5 (Coremail) with SMTP id DsxvpgDnRsStCyVUM_IiAA--.3706S2; Fri, 26 Sep 2014 14:46:05 +0800 (CST)
From: "Jun Bi" 
To: 
Date: Fri, 26 Sep 2014 14:46:03 +0800
Message-ID: <036101cfd955$8a4f15c0$9eed4140$@tsinghua.edu.cn>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 15.0
Thread-Index: Ac/ZVYgSKUTofCAmQG6tEwq+JyQOYA==
Content-Language: zh-cn
X-CM-TRANSID: DsxvpgDnRsStCyVUM_IiAA--.3706S2
X-Coremail-Antispam: 1UD129KBjvJXoW7Kr13AF1UtF18KrW7Wr4DJwb_yoW8Kry5pa yagrZxKan2vw4SkrWxXw18WF1Y9397Kr4DCFnrGw1UAan0ya4xtFy5Kw4Yqa4xAry3ZrZ0 vF12vwn8Za13ZrJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUqKb7Iv0xC_Cr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Cr1j 6rxdM28EF7xvwVC2z280aVAFwI0_GcCE3s1l84ACjcxK6I8E87Iv6xkF7I0E14v26rxl6s 0DM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVACY4xI64kE6c02F40Ex7xfMcIj6xII jxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr 1lF7xvr2IYc2Ij64vIr41lc2xSY4AK67AK6r47MxAIw28IcxkI7VAKI48JMI8I3I0E5I8C rVAFwI0_Jr0_Jr4lx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWUJVWUXw CIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x02 67AKxVWUJVW8JwCI42IY6xAIw20EY4v20xvaj40_Wr1j6rW3Jr1lIxAIcVC2z280aVAFwI 0_Gr0_Cr1lIxAIcVC2z280aVCY1x0267AKxVW8JVW8JrUvcSsGvfC2KfnxnUUI43ZEXa7x UUei2UUUUUU==
X-CM-SenderInfo: xmxquxo6wvx0pjkxthxhgxhubq/
Archived-At: http://mailarchive.ietf.org/arch/msg/supa/h3_do9vFY7tWBzoymB5Akx_NSEA
Subject: [Supa] New Version Notification for draft-bi-supa-gap-analysis-00.txt
X-BeenThere: supa@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Sep 2014 06:46:15 -0000

Hi all,

The new version of Gap Analysis was updated.
Please feel free to comment.

Best Regards,
Jun Bi

-----Original Message-----
From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20
Sent: Friday, September 26, 2014 2:41 PM
To: Jun Bi; Guang Yao; Jun Bi; Guang Yao
Subject: New Version Notification for draft-bi-supa-gap-analysis-00.txt


A new version of I-D, draft-bi-supa-gap-analysis-00.txt has been =
successfully submitted by Guang Yao and posted to the IETF repository.

Name:		draft-bi-supa-gap-analysis
Revision:	00
Title:		Shared Unified Policy Automation (SUPA) Gap Analysis
Document date:	2014-09-26
Group:		Individual Submission
Pages:		12
URL:            =
http://www.ietf.org/internet-drafts/draft-bi-supa-gap-analysis-00.txt
Status:         =
https://datatracker.ietf.org/doc/draft-bi-supa-gap-analysis/
Htmlized:       http://tools.ietf.org/html/draft-bi-supa-gap-analysis-00


Abstract:
   As operators struggle to optimize their network for different
   applications while maximizing network resources usage, there's
   growing business pressure to minimize operational tasks and the
   deployment time of new services.

   New automation paradigms are meant to help reach these goals,
   including the optimization of network functions through application
   control. This control could be signaled directly by an application,
   through a proxy or orchestrated in a centralized manner.

   The current version of the Shared Unified Policy Automation (SUPA)
   group charter identifies two fields where standardization would be
   desirable for operators: the definition of a generic model for the
   description of network topologies at any layer and with any degree
   of granularity, and the definition of a standardized model for
   applications to push policies toward a central network controller.
   The first of these topics, the topology modeling, is meant to
   support the definition and application of the second. The present
   memo analyses the current state of the art of the industries
   regarding these two topics and discusses whether an IETF
   standardization is desirable and for which reasons.

                                                                         =
        =20


Please note that it may take a couple of minutes from the time of =
submission until the htmlized version and diff are available at =
tools.ietf.org.

The IETF Secretariat




From nobody Fri Sep 26 01:51:17 2014
Return-Path: 
X-Original-To: supa@ietfa.amsl.com
Delivered-To: supa@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD5C1A0389 for ; Fri, 26 Sep 2014 01:51:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.987
X-Spam-Level: 
X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 5KvU06plRbpH for ; Fri, 26 Sep 2014 01:51:15 -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 04F7F1A02E4 for ; Fri, 26 Sep 2014 01:51:14 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJY33734; Fri, 26 Sep 2014 08:51:12 +0000 (GMT)
Received: from LHREML513-MBB.china.huawei.com ([fe80::b810:863:a57e:3ff]) by lhreml404-hub.china.huawei.com ([::1]) with mapi id 14.03.0158.001; Fri, 26 Sep 2014 09:49:36 +0100
From: Hosnieh Rafiee 
To: Juergen Schoenwaelder 
Thread-Topic: [Supa] Discussion on SUPA draft chatter
Thread-Index: Ac/Egg4rnM3Ac+nuTf6RywsQVZWuJwTdD/qwAAJrT4AAArLoEAAf412AADbebqA=
Date: Fri, 26 Sep 2014 08:49:36 +0000
Message-ID: <814D0BFB77D95844A01CA29B44CBF8A7A444F9@lhreml513-mbb.china.huawei.com>
References: <008201cfc482$191b5d10$4b521730$@tsinghua.edu.cn> <814D0BFB77D95844A01CA29B44CBF8A7A43A9E@lhreml513-mbb.china.huawei.com> <20140924150105.GA24664@elstar.local> <814D0BFB77D95844A01CA29B44CBF8A7A43C83@lhreml513-mbb.china.huawei.com> <20140925073125.GB26401@elstar.local>
In-Reply-To: <20140925073125.GB26401@elstar.local>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.221.82.100]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/supa/5eec_9v1IyKJkyk1IcTfbd_50aI
Cc: "supa@ietf.org" 
Subject: Re: [Supa] Discussion on SUPA draft chatter
X-BeenThere: supa@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Sep 2014 08:51:17 -0000

Hi J=FCrgen,


> I said I do not understand that this item really refers to and hence I
> can't tell whether secauth is of any relevance. Your response does not
> change my observation. Sure, people can write anything they like in a
> charter proposal. But then they might be challenged what it means what
> they wrote. So you better be prepared to explain what exactly this
> charter item means and why secauth is of any help.

That is true. They can either remove it...The main reason that I mentioned =
secauth is that, secauth is for authentication and authorization. Netconf i=
s not for authentication or authorization. SUPA planned to have a draft for=
 explaining how to authenticate with netconf. This is something that needs =
an external protocol or external mechanism that doesn't exist in netconf si=
nce both will be two different protocols. In other word, they look for inte=
roperable mechanisms (this is based on my understanding). So, my suggestion=
 was that they can use secauth for this purpose or interoperable mechanism.=
=20

There is no need to either include secauth in netconf or SUPA but only how =
to use it as a interoperable mechanism. This was my suggestion. Some people=
 might say it is bad and some people might say it is good.

Best,
Hosnieh


From nobody Fri Sep 26 02:06:40 2014
Return-Path: 
X-Original-To: supa@ietfa.amsl.com
Delivered-To: supa@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80D971A1A89 for ; Fri, 26 Sep 2014 02:06:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.336
X-Spam-Level: 
X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.786] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-O0fozUu4-n for ; Fri, 26 Sep 2014 02:06:36 -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 35DCB1A02FF for ; Fri, 26 Sep 2014 02:06:36 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 9152D73D; Fri, 26 Sep 2014 11:06:34 +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 hBSzV8e3Cr0A; Fri, 26 Sep 2014 11:06:30 +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; Fri, 26 Sep 2014 11:06:34 +0200 (CEST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id DF2BC20036; Fri, 26 Sep 2014 11:06:33 +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 1om82R2WYZdY; Fri, 26 Sep 2014 11:06:33 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DC34D20038; Fri, 26 Sep 2014 11:06:32 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 151402EA40F8; Fri, 26 Sep 2014 11:06:30 +0200 (CEST)
Date: Fri, 26 Sep 2014 11:06:29 +0200
From: Juergen Schoenwaelder 
To: Hosnieh Rafiee 
Message-ID: <20140926090629.GA69319@elstar.local>
Mail-Followup-To: Hosnieh Rafiee , "supa@ietf.org" 
References: <008201cfc482$191b5d10$4b521730$@tsinghua.edu.cn> <814D0BFB77D95844A01CA29B44CBF8A7A43A9E@lhreml513-mbb.china.huawei.com> <20140924150105.GA24664@elstar.local> <814D0BFB77D95844A01CA29B44CBF8A7A43C83@lhreml513-mbb.china.huawei.com> <20140925073125.GB26401@elstar.local> <814D0BFB77D95844A01CA29B44CBF8A7A444F9@lhreml513-mbb.china.huawei.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <814D0BFB77D95844A01CA29B44CBF8A7A444F9@lhreml513-mbb.china.huawei.com>
User-Agent: Mutt/1.4.2.3i
Archived-At: http://mailarchive.ietf.org/arch/msg/supa/BXZYQ8Iawka3Ni-6PJQGIYqhpEw
Cc: "supa@ietf.org" 
Subject: Re: [Supa] Discussion on SUPA draft chatter
X-BeenThere: supa@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Sep 2014 09:06:38 -0000

On Fri, Sep 26, 2014 at 08:49:36AM +0000, Hosnieh Rafiee wrote:
> Hi Jürgen,
> 
> 
> > I said I do not understand that this item really refers to and hence I
> > can't tell whether secauth is of any relevance. Your response does not
> > change my observation. Sure, people can write anything they like in a
> > charter proposal. But then they might be challenged what it means what
> > they wrote. So you better be prepared to explain what exactly this
> > charter item means and why secauth is of any help.
> 
> That is true. They can either remove it...The main reason that I mentioned secauth is that, secauth is for authentication and authorization. Netconf is not for authentication or authorization. SUPA planned to have a draft for explaining how to authenticate with netconf. This is something that needs an external protocol or external mechanism that doesn't exist in netconf since both will be two different protocols. In other word, they look for interoperable mechanisms (this is based on my understanding). So, my suggestion was that they can use secauth for this purpose or interoperable mechanism. 
> 
> There is no need to either include secauth in netconf or SUPA but only how to use it as a interoperable mechanism. This was my suggestion. Some people might say it is bad and some people might say it is good.
> 

NETCONF runs over secure transports (SSH and TLS) and both secure
transports authenticate both of the server and the client (mutual
authentication) NETCONF has an access control model for data model
level authorization. If you want to authorize session using AAA, you
can of course hook SSH into say a RADIUS server. The system
configuration data model even details how to configure this. All this
is defined in RFCs and interoperable today. I remain puzzled what the
problem to be solved is.

/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 Sep 26 04:42:18 2014
Return-Path: 
X-Original-To: supa@ietfa.amsl.com
Delivered-To: supa@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 301FA1A1B3E for ; Fri, 26 Sep 2014 04:42:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.987
X-Spam-Level: 
X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 cW35cmXJpcXi for ; Fri, 26 Sep 2014 04:42:16 -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 BB1501A1B3C for ; Fri, 26 Sep 2014 04:42:15 -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 BJY50543; Fri, 26 Sep 2014 11:42:12 +0000 (GMT)
Received: from LHREML513-MBB.china.huawei.com ([fe80::b810:863:a57e:3ff]) by lhreml401-hub.china.huawei.com ([10.201.5.240]) with mapi id 14.03.0158.001; Fri, 26 Sep 2014 12:42:09 +0100
From: Hosnieh Rafiee 
To: Juergen Schoenwaelder 
Thread-Topic: [Supa] Discussion on SUPA draft chatter
Thread-Index: Ac/Egg4rnM3Ac+nuTf6RywsQVZWuJwTdD/qwAAJrT4AAArLoEAAf412AADbebqD///XxgP//w/lA
Date: Fri, 26 Sep 2014 11:42:08 +0000
Message-ID: <814D0BFB77D95844A01CA29B44CBF8A7A44555@lhreml513-mbb.china.huawei.com>
References: <008201cfc482$191b5d10$4b521730$@tsinghua.edu.cn> <814D0BFB77D95844A01CA29B44CBF8A7A43A9E@lhreml513-mbb.china.huawei.com> <20140924150105.GA24664@elstar.local> <814D0BFB77D95844A01CA29B44CBF8A7A43C83@lhreml513-mbb.china.huawei.com> <20140925073125.GB26401@elstar.local> <814D0BFB77D95844A01CA29B44CBF8A7A444F9@lhreml513-mbb.china.huawei.com> <20140926090629.GA69319@elstar.local>
In-Reply-To: <20140926090629.GA69319@elstar.local>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.221.82.100]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/supa/8jBXABXu090f1s7nAnXc_wvgB4w
Cc: "supa@ietf.org" 
Subject: Re: [Supa] Discussion on SUPA draft chatter
X-BeenThere: supa@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Sep 2014 11:42:17 -0000

>=20
> NETCONF runs over secure transports (SSH and TLS) and both secure
> transports authenticate both of the server and the client (mutual
> authentication) NETCONF has an access control model for data model
> level authorization. If you want to authorize session using AAA, you
> can of course hook SSH into say a RADIUS server. The system
> configuration data model even details how to configure this. All this
> is defined in RFCs and interoperable today. I remain puzzled what the
> problem to be solved is.

The more discussion is not related to this list.=20
I suggest you read secauth requirements and use case scenarios. I cannot ad=
d more since this is not related.

Best,
Hosnieh


From nobody Fri Sep 26 05:55:47 2014
Return-Path: 
X-Original-To: supa@ietfa.amsl.com
Delivered-To: supa@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 590141A1BED for ; Fri, 26 Sep 2014 05:55:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AoRDlFzu6TFZ for ; Fri, 26 Sep 2014 05:55:43 -0700 (PDT)
Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002:c07::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68FD61A1BAE for ; Fri, 26 Sep 2014 05:55:43 -0700 (PDT)
Received: by mail-yk0-f181.google.com with SMTP id 200so4098329ykr.12 for ; Fri, 26 Sep 2014 05:55:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:from:date:message-id:subject:to:content-type; bh=zUtG/ySvup7PFFqbhiOOnFIpvCVeM+M/Al/bvwKY/DA=; b=K60JI6gyCRVs/O/qepZAEmz9DYjFNcR+T8LCMNb3QMR44e5Pa+8kzUGQtwUJ8vdQlj t70swwRjcbMkv/zYF1FJqUfwcFpEBlxqVJm/pSnQwIXTlJV2CA+p0E6f5MKu9Fht4XUY GGVPdmF74mJKUL4fnKTYlMGCFreHdz4gehgpXSxN4svCB5i2eeBvsIF8PwQVpXP+5MYu ZYoUIkhfD+go9FX2rGeQ14ezpF24fjJmN33zSe7GW+09GGnwgQJLWiMKXIOGRbD7DHud Vh9G9YXB7Vb0NQvIRcOOQR1zXS0eGjsHAf/aYy06UpfKDR6hDYjBICiObPR8odgi8usk doHA==
X-Received: by 10.236.0.169 with SMTP id 29mr1639470yhb.150.1411736142655; Fri, 26 Sep 2014 05:55:42 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.170.133.207 with HTTP; Fri, 26 Sep 2014 05:55:02 -0700 (PDT)
From: Qiong 
Date: Fri, 26 Sep 2014 20:55:02 +0800
Message-ID: 
To: supa@ietf.org
Content-Type: multipart/alternative; boundary=089e01634e684cb5480503f76f0a
Archived-At: http://mailarchive.ietf.org/arch/msg/supa/C43-HmH2SFuNcAhzOipCvcN4dfs
Subject: [Supa] Fw: New Version Notification for draft-sun-supa-openv6-use-cases-00.txt
X-BeenThere: supa@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Sep 2014 12:55:45 -0000

--089e01634e684cb5480503f76f0a
Content-Type: text/plain; charset=UTF-8

 Hi all,

The following is the new version of openv6 use case. Please feel free to
comment.Thanks in advance!

Best Regards,
Qiong

China Telecom


 *From:* internet-drafts 
*Date:* 2014-09-25 18:48
*To:* Qiong Sun ; Qiong Sun ; JF
Tremblay ; Chongfeng Xie
; JF Tremblay
; Chongfeng
Xie 
*Subject:* New Version Notification for
draft-sun-supa-openv6-use-cases-00.txt

A new version of I-D, draft-sun-supa-openv6-use-cases-00.txt
has been successfully submitted by Qiong Sun and posted to the
IETF repository.

Name: draft-sun-supa-openv6-use-cases
Revision: 00
Title: Use case of IPv6 transition in SUPA
Document date: 2014-09-25
Group: Individual Submission
Pages: 10
URL:
http://www.ietf.org/internet-drafts/draft-sun-supa-openv6-use-cases-00.txt
Status:
https://datatracker.ietf.org/doc/draft-sun-supa-openv6-use-cases/
Htmlized:
http://tools.ietf.org/html/draft-sun-supa-openv6-use-cases-00


Abstract:
   The IPv6 transition has been an ongoing process throughout the world
   due to the exhaustion of the IPv4 address space.  However, this
   transition leads to costly end-to-end network upgrades and poses new
   challenges of managing a large number of devices with a variety of
   transitioning protocols.  While IPv6 transition tools exist, there
   are still new issues exist.  Operators may need various types of IPv6
   transition technologies depending on performance requirements,
   deployment scenarios, etc.

   To address these difficulties, a software defined unifying approach
   would provide a unified way to deploy IPv6 in a cost-effective,
   flexible manner.

   This document describes use cases of IPv6 transition (Openv6) and
   also requirements in SUPA architecture.





Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat



-- 
==============================================
Qiong Sun
China Telecom Beijing Research Institute


Open source code:
lightweight 4over6: *http://sourceforge.net/projects/laft6/
*
PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/
 *
===============================================

--089e01634e684cb5480503f76f0a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


=C2=A0Hi all,



The following is the new version of openv6 use case. Please feel free to co=
mment.Thanks in advance!



Best Regards,

Qiong

China Telecom 









Date:=C2=A02014-09-25=C2=A018:48



Subject:=C2=A0New Version Notification for=20
draft-sun-supa-openv6-use-cases-00.txt




=C2=A0


A new version of I-D, draft-sun-supa-openv6-use-cases-00.txt


has been successfully submitted by Qiong Sun and posted to the


IETF repository.


=C2=A0


Name: draft-sun-supa-openv6-use-cases


Revision: 00


Title: Use case of IPv6 transition in SUPA


Document date: 2014-09-25


Group: Individual Submission


Pages: 10


URL:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=20
http://www.ietf.org/internet-drafts/draft-sun-supa-openv6-use-c=
ases-00.txt


Status:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=20
https://datatracker.ietf.org/doc/draft-sun-supa-openv6-use-cases/

Htmlized:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=20
h=
ttp://tools.ietf.org/html/draft-sun-supa-openv6-use-cases-00


=C2=A0


=C2=A0


Abstract:


=C2=A0=C2=A0 The IPv6 transition has been an ongoing process throughou=
t the=20
world


=C2=A0=C2=A0 due to the exhaustion of the IPv4 address space.=C2=A0 Ho=
wever, this


=C2=A0=C2=A0 transition leads to costly end-to-end network upgrades an=
d poses=20
new


=C2=A0=C2=A0 challenges of managing a large number of devices with a v=
ariety of


=C2=A0=C2=A0 transitioning protocols.=C2=A0 While IPv6 transition tool=
s exist, there


=C2=A0=C2=A0 are still new issues exist.=C2=A0 Operators may need vari=
ous types of=20
IPv6


=C2=A0=C2=A0 transition technologies depending on performance requirem=
ents,


=C2=A0=C2=A0 deployment scenarios, etc.


=C2=A0


=C2=A0=C2=A0 To address these difficulties, a software defined unifyin=
g=20
approach


=C2=A0=C2=A0 would provide a unified way to deploy IPv6 in a cost-effe=
ctive,


=C2=A0=C2=A0 flexible manner.


=C2=A0


=C2=A0=C2=A0 This document describes use cases of IPv6 transition (Ope=
nv6) and


=C2=A0=C2=A0 also requirements in SUPA architecture.


=C2=A0


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=20



=C2=A0


=C2=A0


Please note that it may take a couple of minutes from the time of=20
submission


until the htmlized version and diff are available at tools.ietf.org.


=C2=A0


The IETF Secretariat


=C2=A0


-- 
=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Qiong Sun
China Telecom Be=
ijing Research Institute


Open source code:
lightweight 4over6=
: h=
ttp://sourceforge.net/projects/laft6/
PCP-natcoord: http=
://sourceforge.net/projects/pcpportsetdemo/ 
=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D





--089e01634e684cb5480503f76f0a--


From nobody Fri Sep 26 06:31:40 2014
Return-Path: 
X-Original-To: supa@ietfa.amsl.com
Delivered-To: supa@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27DE41A1BFD for ; Fri, 26 Sep 2014 06:31:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.287
X-Spam-Level: 
X-Spam-Status: No, score=-14.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_AFFORDABLE=1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, 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 ij2fPVjpWkF2 for ; Fri, 26 Sep 2014 06:31:36 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 612851A6FC0 for ; Fri, 26 Sep 2014 06:31:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9266; q=dns/txt; s=iport; t=1411738293; x=1412947893; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=PYPLCENGOMXwIjT8x6UA0y6+ISFyZJSOxP9HV3jQ1Yg=; b=WqjCx11dSyR0gevem8dN3HQbhHT4O/lh/y2JS5AgWjqLOG5iOvTnXkfJ KQhJWT4+1MHWUQXPhfj5I3H/T3lwlQE2sWy6XZW16wijhy4R65tWW83zu NRMiIEQGMkV6xAcsbC1AnxgAXEL1rYkO9X4QxZLeAxE7A4n22vkEc7wji E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgAOAOdpJVStJA2K/2dsb2JhbAAZAUaDDlNXBIJ9xz4MhnhUAhluFgFyCYQDAQEBBAEBASAROgkCDAYBBgIRBAEBAwIGAhsDAgQlCxQBBgEBBQQBBA4FCAERAYgjDY0ONJxMhU+QLwEXgSyOQQ8iDYJyNoEdBZFjhDqIa5N4g2NsAYFHgQIBAQE
X-IronPort-AV: E=Sophos;i="5.04,604,1406592000"; d="scan'208";a="358416105"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-7.cisco.com with ESMTP; 26 Sep 2014 13:31:32 +0000
Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s8QDVWKx012554 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 26 Sep 2014 13:31:32 GMT
Received: from xmb-aln-x11.cisco.com ([169.254.6.41]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0195.001; Fri, 26 Sep 2014 08:31:32 -0500
From: "Eric Voit (evoit)" 
To: "supa@ietf.org" 
Thread-Topic: [netmod] "00" Notification for draft-voit-netmod-peer-mount-requirements
Thread-Index: Ac/ZjioymKhX4n/+Q0irapwH2HUqIw==
Date: Fri, 26 Sep 2014 13:31:31 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.116.134.135]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/supa/Qfr8C-B8BOl26L1u6brXTwm-_G8
Cc: "Alexander Clemm \(alex\)" 
Subject: [Supa] FW: [netmod] "00" Notification for draft-voit-netmod-peer-mount-requirements
X-BeenThere: supa@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Sep 2014 13:31:38 -0000

SSBqdXN0IGxlYXJuZWQgYWJvdXQgU1VQQSwgYW5kIGJhc2VkIG9uIHRoZSBldm9sdmluZyBjaGFy
dGVyIGl0IHNlZW1zIHF1aXRlIHJlbGV2YW50IHRvIGFuIGluZm9ybWF0aW9uYWwgZHJhZnQgc2V2
ZXJhbCBvZiB1cyBzdWJtaXR0ZWQgdG8gTmV0bW9kIHllc3RlcmRheS4NCmh0dHA6Ly93d3cuaWV0
Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXZvaXQtbmV0bW9kLXBlZXItbW91bnQtcmVxdWly
ZW1lbnRzLTAwLnR4dA0KDQpPdXIgZHJhZnQgYWdncmVnYXRlcyByZXF1aXJlbWVudHMgd2UgaGF2
ZSB1bmNvdmVyZWQgYXMgd2UgaGF2ZSBidWlsdCBzZXZlcmFsIG5ldyBEYXRhIENlbnRlciBlZGdl
IHNlcnZpY2VzIHVwb24gYW4gT3BlbiBEYXlsaWdodCBjb250cm9sbGVyLiAgV2UgYWxyZWFkeSBo
YXZlIGEgd29ya2luZyBZQU5HIHNlcnZpY2UgbW9kZWwgZm9yIHR3byBvZiB0aGUgdHdvIHNlcnZp
Y2VzIGluIHRoZSBkcmFmdC4gIElmIHRoZXJlIGlzIGludGVyZXN0IGhlcmUsIEkgY291bGQgcHVi
bGlzaCB0aGF0IG1vZGVsIGFzIHdlbGwuDQoNClRoYW5rcywNCkVyaWMNCg0KLS0tLS1PcmlnaW5h
bCBNZXNzYWdlLS0tLS0NCkZyb206IG5ldG1vZCBbbWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYu
b3JnXSBPbiBCZWhhbGYgT2YgRXJpYyBWb2l0LCBTZXB0ZW1iZXIgMjUsIDIwMTQgNjozOCBQTQ0K
DQpXZSBoYXZlIGJlZW4gZGV2ZWxvcGluZyBTRE4gYXBwbGljYXRpb25zIHdoaWNoIHJlcXVpcmUg
cXVpY2ssIGl0ZXJhdGl2ZSBhY2Nlc3MgdG8gb2JqZWN0cyByZXByZXNlbnRpbmcgbmV0d29yayBh
bmQgZGV2aWNlIGFic3RyYWN0aW9ucy7CoCBUaGVzZSBvYmplY3RzIGluY2x1ZGUgb25lcyBhdXRo
b3JpdGF0aXZlbHkgb3duZWQgYnkgYSBsb2NhbCBzeXN0ZW0sIGFzIHdlbGwgYXMgb25lcyBwcm92
aWRlZCBmcm9tIHJlbW90ZSBkYXRhc3RvcmVzLsKgIFR3byBzdWNoIGFwcGxpY2F0aW9ucyB3ZSBo
YXZlIHByb3RvdHlwZWQgYXJlIOKAnENsb3VkIFBvbGljZXLigJ0gYW5kIOKAnEREb1MgVGhyZXNo
b2xkaW5n4oCdLiDCoChTZWUgbGlua3MgYmVsb3cgZm9yIG1vcmUgb24gdGhlc2UgYXBwcy4pDQoN
ClRoZSBnb29kIG5ld3MgaXMgdGhhdCB3ZSBmb3VuZCBZQU5HIG1vZGVscyBhbmQgc3ludGF4IHRv
IGJlIGEgbmljZSBmaXQgZm9yIHRoZXNlIGFwcGxpY2F0aW9ucy7CoMKgIEhvd2V2ZXIgd2UgaGF2
ZSBiZWVuIHRyeWluZyB0byBjb3ZlciBzZXZlcmFsIG1pc3NpbmcgZWxlbWVudHM6DQoNCk1pc3Np
bmcgRWxlbWVudCAjMTogRGV2ZWxvcGVyIFNpbXBsaWNpdHkgV2Ugd2FudGVkIGFwcGxpY2F0aW9u
cyB0byBhY2Nlc3MgcmVtb3RlIG9iamVjdHMgZnJvbSBhIHNpbmdsZSBkYXRhc3RvcmUsIHdpdGhv
dXQgaGF2aW5nIHRvIGhhdmUgdGhlIGFwcGxpY2F0aW9ucyBwZWVyIGRpcmVjdGx5IHdpdGggcmVt
b3RlIGRldmljZXMuwqAgV2UgYWxzbyB3YW50ZWQgY2xpZW50cyBhbmQgYXBwbGljYXRpb25zIHRv
IGFjY2VzcyBkYXRhc3RvcmVzIGluIHRoZSBzYW1lIHdheSBpbmRlcGVuZGVudCBvZiB3aGV0aGVy
IHRoZSBhcHBsaWNhdGlvbnMgd2VyZSBob3N0ZWQgb24gYSBOZXR3b3JrIEVsZW1lbnQgb3IgQ29u
dHJvbGxlci4NCg0KTWlzc2luZyBFbGVtZW50ICMyOiBXaG8gb3ducyBhbiBPYmplY3Q/DQpBcHBs
aWNhdGlvbnMgY2FuJ3QgdGVsbCB3aGljaCBOZXR3b3JrIEVsZW1lbnQgYWNyb3NzIGEgc2V0IG9m
IGRldmljZXMgaXMgdGhlIGF1dGhvcml0YXRpdmUgb3duZXIgb2YgYSBwYXJ0aWN1bGFyIHJlcGxp
Y2F0ZWQgb2JqZWN0LsKgIFNpbmNlIHJlcGxpY2F0ZWQgZGF0YSBnZXRzIG91dCBvZiBzeW5jaCwg
cmVzb2x1dGlvbiAvIGNvbnZlcmdlbmNlIGlzIGEgcHJvYmxlbS4NCg0KTWlzc2luZyBFbGVtZW50
ICMzOiBNYWludGFpbmluZyBjYWNoZXMgb2YgcmVtb3RlIGluZm9ybWF0aW9uIEFwcGxpY2F0aW9u
cyBuZWVkIHRpbWVseSBhY2Nlc3MgdG8gcmVtb3RlIGluZm9ybWF0aW9uLCB3aGljaCBjYW4gbmVj
ZXNzaXRhdGUgdGhlIGludHJvZHVjdGlvbiBjYWNoZSBpbmZyYXN0cnVjdHVyZS7CoCBOZXRjb25m
IHByb3ZpZGVzIGxpdHRsZSBzdXBwb3J0IHRvIGZhY2lsaXRhdGUgdGhpcy7CoCBGb3IgZXhhbXBs
ZSwgbm90aWZpY2F0aW9ucyBhcmUgbm90IGEgZ29vZCBtYXRjaCB0byBzdWJzY3JpYmUgdG8gcHVz
aC11cGRhdGVzLsKgIA0KDQpUbyBzb2x2ZSB0aGVzZSBwcm9ibGVtcywgd2UgbmVlZCB0ZWNobm9s
b2d5IHNvbHV0aW9ucyB3aGljaCB3b3JrIGVxdWFsbHkgd2VsbCBmb3IgYm90aCBDb250cm9sbGVy
cyBhbmQgTmV0d29yayBFbGVtZW50cy7CoCBUaGVzZSBzb2x1dGlvbnMgbXVzdCBleHBvc2UgbG9j
YWwgZGF0YXN0b3JlcyB3aGljaCBwcm92aWRlIGF1dGhvcml0YXRpdmUsIGNvbnNvbGlkYXRlZCB2
aWV3cyBvZiBkaXN0cmlidXRlZCBuZXR3b3JrIG9iamVjdHMuwqAgVGhpcyBtdXN0IGJlIGRvbmUg
aW4gYSB3YXkgd2hpY2ggYWxsb3dzIHRoZSBhcHBsaWNhdGlvbnMgdG8gc2l0IGFueXdoZXJlIGlu
IHRoZSBuZXR3b3JrLCBvbiB2YXJpb3VzIGFic3RyYWN0aW9ucywgd2hpbGUgbWFpbnRhaW5pbmcg
ZG9tYWluIGNvbnNpc3RlbmN5LiBBbmQgdGhpcyBtdXN0IGJlIGRvbmUgd2hpbGUgbWF4aW1pemlu
ZyBhcHBsaWNhdGlvbiBkZXZlbG9wZXIgc2ltcGxpY2l0eS7CoCANCg0KVGhpcyBkcmFmdCBpcyBp
bnRlbmRlZCB0byBzdGFydCBhZ2dyZWdhdGluZyByZXF1aXJlbWVudHMgaW4gdGhpcyBzcGFjZS7C
oCBUaGUgZHJhZnQgaXMgbm90IGNvbXBsZXRlLCBzbyBpdCB3b3VsZCBiZSBncmVhdCB0byBoZWFy
IGZyb20gb3RoZXJzIHdobyBhcmUgaW50ZXJlc3RlZCBpbiBoZWxwaW5nIHNvIHRoYXQgd2UgZW5k
IHVwIHdpdGggYSBtb3JlIGNvbXByZWhlbnNpdmUgY29udGV4dC4NCg0KU29sdXRpb25zIGRvIGV4
aXN0IHdoaWNoIGNhbiBzb2x2ZSBhIHN1YnNldCBvZiB0aGVzZSByZXF1aXJlbWVudHMuwqAgT25l
IHBhcnRpY3VsYXIgdGVjaG5vbG9neSB3ZSBoYXZlIGJ1aWx0IGlzIGtub3duIGFzIOKAnHBlZXIg
bW91bnTigJ0uwqAgUGVlciBtb3VudCBnaXZlcyB0aGUgYWJpbGl0eSB0byByZWZlcmVuY2UgWUFO
RyBpbmZvcm1hdGlvbiBpbnRvIGEgbG9jYWwgZGF0YXN0b3JlIGZyb20gcmVtb3RlIGRhdGFzdG9y
ZXMuwqAgVGhpcyBwcm92aWRlcyBjbGllbnQgYXBwbGljYXRpb25zIHdpdGggbG9jYWwgYWNjZXNz
IHRvIGluZm9ybWF0aW9uIHdoaWNoIG1pZ2h0IGJlIHRyYW5zcGFyZW50bHkgZmVkZXJhdGVkIGFj
cm9zcyBtdWx0aXBsZSBzeXN0ZW1zIGFuZCBkYXRhc3RvcmVzLsKgIEl0IGFsc28gcmV0YWlucyBj
bGVhciBvYmplY3Qgb3duZXJzaGlwIHRvIG1pbmltaXplIHN5bmNocm9uaXphdGlvbiBhbmQgaW50
ZXItc3lzdGVtIGRlcGVuZGVuY3kgaXNzdWVzLsKgwqAgVGhlcmUgYXJlIGFscmVhZHkgaW1wbGVt
ZW50YXRpb25zIG9mIHRoaXMgdGVjaG5vbG9neSwgZm9yIGV4YW1wbGUsIGluIE9wZW4gRGF5bGln
aHQuwqAgSG93ZXZlciwgd2UgYmVsaWV2ZSByZXF1aXJlbWVudHMgYW5kIHVzZSBjYXNlcyBmb3Ig
dGhpcyB0ZWNobm9sb2d5IGFwcGx5IGVxdWFsbHkgd2VsbCB0byBuZXR3b3JrIGRldmljZXMuwqAg
DQoNClBsZWFzZSBsZXQgdXMga25vdyBpZiBlaXRoZXIgdGhlIHJlcXVpcmVtZW50cyBvciB0ZWNo
bm9sb2d5IHNwZWNpZmljYXRpb25zIGFyZSBwcm9ibGVtIHlvdSBhcmUgaW50ZXJlc3RlZCBpbiBl
eHBsb3JpbmcuDQoNClRoYW5rcyENCkVyaWMsIEFsZXgsIFByYWJoYWthcmEsIEFtYmlrYSwgU2hh
c2hpDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNA
aWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddDQpTZW50OiBUaHVyc2Rh
eSwgU2VwdGVtYmVyIDI1LCAyMDE0IDg6NDEgQU0NClRvOiBQcmFiaGFrYXJhIFllbGxhaSAocHll
bGxhaSk7IFNoYXNoaSBLdW1hciBCYW5zYWwgKHNoYWJhbnNhKTsgQW1iaWthIFByYXNhZCBUcmlw
YXRoeSAoYW1idHJpcGEpOyBBbGV4YW5kZXIgQ2xlbW0gKGFsZXgpOyBFcmljIFZvaXQgKGV2b2l0
KTsgQW1iaWthIFByYXNhZCBUcmlwYXRoeSAoYW1idHJpcGEpOyBBbGV4YW5kZXIgQ2xlbW0gKGFs
ZXgpOyBQcmFiaGFrYXJhIFllbGxhaSAocHllbGxhaSk7IEVyaWMgVm9pdCAoZXZvaXQpOyBTaGFz
aGkgS3VtYXIgQmFuc2FsIChzaGFiYW5zYSkNClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNh
dGlvbiBmb3IgZHJhZnQtdm9pdC1uZXRtb2QtcGVlci1tb3VudC1yZXF1aXJlbWVudHMtMDAudHh0
DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXZvaXQtbmV0bW9kLXBlZXItbW91bnQt
cmVxdWlyZW1lbnRzLTAwLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBF
cmljIFZvaXQgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOsKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgZHJhZnQtdm9pdC1uZXRtb2QtcGVlci1tb3Vu
dC1yZXF1aXJlbWVudHMNClJldmlzaW9uOsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDAwDQpU
aXRsZTrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFJlcXVpcmVtZW50
cyBmb3IgUGVlciBNb3VudGluZyBvZiBZQU5HIHN1YnRyZWVzIGZyb20gUmVtb3RlIERhdGFzdG9y
ZXMNCkRvY3VtZW50IGRhdGU6IDIwMTQtMDktMjUNCkdyb3VwOsKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczrCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgIDIyDQpVUkw6wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBodHRw
Oi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC12b2l0LW5ldG1vZC1wZWVyLW1v
dW50LXJlcXVpcmVtZW50cy0wMC50eHQNClN0YXR1czrCoMKgwqDCoMKgwqDCoMKgIGh0dHBzOi8v
ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXZvaXQtbmV0bW9kLXBlZXItbW91bnQtcmVx
dWlyZW1lbnRzLw0KSHRtbGl6ZWQ6wqDCoMKgwqDCoMKgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9o
dG1sL2RyYWZ0LXZvaXQtbmV0bW9kLXBlZXItbW91bnQtcmVxdWlyZW1lbnRzLTAwDQoNCg0KQWJz
dHJhY3Q6DQrCoMKgIE5ldHdvcmsgaW50ZWdyYXRlZCBhcHBsaWNhdGlvbnMgd2FudCBzaW1wbGUg
d2F5cyB0byBhY2Nlc3MgWUFORw0KwqDCoCBvYmplY3RzIGFuZCBzdWJ0cmVlcyB3aGljaCBtaWdo
dCBiZSBkaXN0cmlidXRlZCBhY3Jvc3MgbmV0d29yay4NCsKgwqAgUGVyZm9ybWFuY2UgcmVxdWly
ZW1lbnRzIG1heSBkaWN0YXRlIHRoYXQgaXQgaXMgdW5hZmZvcmRhYmxlIGZvciBhDQrCoMKgIHN1
YnNldCBvZiB0aGVzZSBhcHBsaWNhdGlvbnMgdG8gZ28gdGhyb3VnaCBleGlzdGluZyBjZW50cmFs
aXplZA0KwqDCoCBtYW5hZ2VtZW50IGJyb2tlcnMuwqAgRm9yIHN1Y2ggYXBwbGljYXRpb25zLCBk
ZXZlbG9wbWVudCBjb21wbGV4aXR5DQrCoMKgIG11c3QgYmUgbWluaW1pemVkLsKgIFNwZWNpZmlj
IGFzcGVjdHMgb2YgY29tcGxleGl0eSBkZXZlbG9wZXJzIHdhbnQgdG8NCsKgwqAgaWdub3JlIGlu
Y2x1ZGU6DQoNCsKgwqAgb8KgIHdoZXRoZXIgYXV0aG9yaXRhdGl2ZSBpbmZvcm1hdGlvbiBpcyBh
Y3R1YWxseSBzb3VyY2VkIGZyb20gcmVtb3RlDQrCoMKgwqDCoMKgIGRhdGFzdG9yZXMgKGFzIHdl
bGwgYXMgaG93IHRvIGdldCB0byB0aG9zZSBkYXRhc3RvcmVzKSwNCg0KwqDCoCBvwqAgd2hldGhl
ciBzdWNoIGluZm9ybWF0aW9uIGhhcyBiZWVuIGxvY2FsbHkgY2FjaGVkIG9yIG5vdCwNCg0KwqDC
oCBvwqAgd2hldGhlciB0aGVyZSBhcmUgemVybywgb25lLCBvciBtb3JlIGNvbnRyb2xsZXJzIGFz
c2VydGluZw0KwqDCoMKgwqDCoCBvd25lcnNoaXAgb2YgaW5mb3JtYXRpb24sIGFuZA0KDQrCoMKg
IG/CoCB3aGV0aGVyIHRoZXJlIGFyZSBpbnRlcmFjdGlvbnMgd2l0aCBvdGhlciBhcHBsaWNhdGlv
bnMNCsKgwqDCoMKgwqAgY29uY3VycmVudGx5IHJ1bm5pbmcgZWxzZXdoZXJlDQoNCsKgwqAgVGhl
IHNvbHV0aW9uIHJlcXVpcmVtZW50cyBkZXNjcmliZWQgaW4gdGhpcyBkb2N1bWVudCBkZXRhaWwg
d2hhdCBpcw0KwqDCoCBuZWVkZWQgdG8gc3VwcG9ydCBhcHBsaWNhdGlvbiBhY2Nlc3MgdG8gYXV0
aG9yaXRhdGl2ZSBuZXR3b3JrIFlBTkcNCsKgwqAgb2JqZWN0cyBmcm9tIGNvbnRyb2xsZXJzIChz
dGFyKSBvciBwZWVyaW5nIG5ldHdvcmsgZGV2aWNlcyAobWVzaCkgaW4NCsKgwqAgc3VjaCBhIHdh
eSB0byBtZWV0IHRoZXNlIGdvYWxzLg0KDQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqAgDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNv
dXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRt
bGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0K
DQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXw0KbmV0bW9kIG1haWxpbmcgbGlzdA0KbmV0bW9kQGlldGYub3JnDQpo
dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0K


From nobody Fri Sep 26 06:35:07 2014
Return-Path: 
X-Original-To: supa@ietfa.amsl.com
Delivered-To: supa@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0F961A6FD0 for ; Fri, 26 Sep 2014 06:35:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.987
X-Spam-Level: 
X-Spam-Status: No, score=-3.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_AFFORDABLE=1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 6tf_lMeQvYo0 for ; Fri, 26 Sep 2014 06:35:00 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 330EA1A6FCD for ; Fri, 26 Sep 2014 06:34:59 -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 BNA76067; Fri, 26 Sep 2014 13:34:53 +0000 (GMT)
Received: from LHREML516-MBX.china.huawei.com ([169.254.1.85]) by lhreml404-hub.china.huawei.com ([::1]) with mapi id 14.03.0158.001; Fri, 26 Sep 2014 14:34:52 +0100
From: Georgios Karagiannis 
To: "Eric Voit (evoit)" , "supa@ietf.org" 
Thread-Topic: [netmod] "00" Notification for draft-voit-netmod-peer-mount-requirements
Thread-Index: Ac/ZjioymKhX4n/+Q0irapwH2HUqIwAAEm2A
Date: Fri, 26 Sep 2014 13:34:52 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.203.125.135]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/supa/1ZT1_TQUR-gO-1D7t10AnWgs7zg
Cc: "Alexander Clemm \(alex\)" 
Subject: Re: [Supa] [netmod] "00" Notification for draft-voit-netmod-peer-mount-requirements
X-BeenThere: supa@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Sep 2014 13:35:03 -0000

SGkgRXJpYywNCg0KVGhhbmtzIGZvciB0aGUgaW5mb3JtYXRpb24uDQpJIGhhdmUgbm90IHJlYWQg
eW91ciBkcmFmdCBpbiBkZXRhaWwsIGJ1dCBmcm9tIHlvdXIgZXhwbGFuYXRpb24sIGl0IG1pZ2h0
IGJlIHJlbGV2YW50IHRvIFNVUEEuDQoNCkJlc3QgcmVnYXJkcywNCkdlb3JnaW9zDQoNCg0KPiAt
LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBTdXBhIFttYWlsdG86c3VwYS1ib3Vu
Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRXJpYyBWb2l0IChldm9pdCkNCj4gU2VudDogRnJp
ZGF5LCBTZXB0ZW1iZXIgMjYsIDIwMTQgMjozMiBQTQ0KPiBUbzogc3VwYUBpZXRmLm9yZw0KPiBD
YzogQWxleGFuZGVyIENsZW1tIChhbGV4KQ0KPiBTdWJqZWN0OiBbU3VwYV0gRlc6IFtuZXRtb2Rd
ICIwMCIgTm90aWZpY2F0aW9uIGZvciBkcmFmdC12b2l0LW5ldG1vZC1wZWVyLQ0KPiBtb3VudC1y
ZXF1aXJlbWVudHMNCj4gDQo+IEkganVzdCBsZWFybmVkIGFib3V0IFNVUEEsIGFuZCBiYXNlZCBv
biB0aGUgZXZvbHZpbmcgY2hhcnRlciBpdCBzZWVtcyBxdWl0ZQ0KPiByZWxldmFudCB0byBhbiBp
bmZvcm1hdGlvbmFsIGRyYWZ0IHNldmVyYWwgb2YgdXMgc3VibWl0dGVkIHRvIE5ldG1vZCB5ZXN0
ZXJkYXkuDQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXZvaXQt
bmV0bW9kLXBlZXItbW91bnQtcmVxdWlyZW1lbnRzLQ0KPiAwMC50eHQNCj4gDQo+IE91ciBkcmFm
dCBhZ2dyZWdhdGVzIHJlcXVpcmVtZW50cyB3ZSBoYXZlIHVuY292ZXJlZCBhcyB3ZSBoYXZlIGJ1
aWx0IHNldmVyYWwNCj4gbmV3IERhdGEgQ2VudGVyIGVkZ2Ugc2VydmljZXMgdXBvbiBhbiBPcGVu
IERheWxpZ2h0IGNvbnRyb2xsZXIuICBXZSBhbHJlYWR5DQo+IGhhdmUgYSB3b3JraW5nIFlBTkcg
c2VydmljZSBtb2RlbCBmb3IgdHdvIG9mIHRoZSB0d28gc2VydmljZXMgaW4gdGhlIGRyYWZ0Lg0K
PiBJZiB0aGVyZSBpcyBpbnRlcmVzdCBoZXJlLCBJIGNvdWxkIHB1Ymxpc2ggdGhhdCBtb2RlbCBh
cyB3ZWxsLg0KPiANCj4gVGhhbmtzLA0KPiBFcmljDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3Nh
Z2UtLS0tLQ0KPiBGcm9tOiBuZXRtb2QgW21haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZ10g
T24gQmVoYWxmIE9mIEVyaWMgVm9pdCwNCj4gU2VwdGVtYmVyIDI1LCAyMDE0IDY6MzggUE0NCj4g
DQo+IFdlIGhhdmUgYmVlbiBkZXZlbG9waW5nIFNETiBhcHBsaWNhdGlvbnMgd2hpY2ggcmVxdWly
ZSBxdWljaywgaXRlcmF0aXZlIGFjY2Vzcw0KPiB0byBvYmplY3RzIHJlcHJlc2VudGluZyBuZXR3
b3JrIGFuZCBkZXZpY2UgYWJzdHJhY3Rpb25zLsKgIFRoZXNlIG9iamVjdHMNCj4gaW5jbHVkZSBv
bmVzIGF1dGhvcml0YXRpdmVseSBvd25lZCBieSBhIGxvY2FsIHN5c3RlbSwgYXMgd2VsbCBhcyBv
bmVzIHByb3ZpZGVkDQo+IGZyb20gcmVtb3RlIGRhdGFzdG9yZXMuwqAgVHdvIHN1Y2ggYXBwbGlj
YXRpb25zIHdlIGhhdmUgcHJvdG90eXBlZCBhcmUg4oCcQ2xvdWQNCj4gUG9saWNlcuKAnSBhbmQg
4oCcRERvUyBUaHJlc2hvbGRpbmfigJ0uIMKgKFNlZSBsaW5rcyBiZWxvdyBmb3IgbW9yZSBvbiB0
aGVzZSBhcHBzLikNCj4gDQo+IFRoZSBnb29kIG5ld3MgaXMgdGhhdCB3ZSBmb3VuZCBZQU5HIG1v
ZGVscyBhbmQgc3ludGF4IHRvIGJlIGEgbmljZSBmaXQgZm9yDQo+IHRoZXNlIGFwcGxpY2F0aW9u
cy7CoMKgIEhvd2V2ZXIgd2UgaGF2ZSBiZWVuIHRyeWluZyB0byBjb3ZlciBzZXZlcmFsIG1pc3Np
bmcNCj4gZWxlbWVudHM6DQo+IA0KPiBNaXNzaW5nIEVsZW1lbnQgIzE6IERldmVsb3BlciBTaW1w
bGljaXR5IFdlIHdhbnRlZCBhcHBsaWNhdGlvbnMgdG8gYWNjZXNzDQo+IHJlbW90ZSBvYmplY3Rz
IGZyb20gYSBzaW5nbGUgZGF0YXN0b3JlLCB3aXRob3V0IGhhdmluZyB0byBoYXZlIHRoZQ0KPiBh
cHBsaWNhdGlvbnMgcGVlciBkaXJlY3RseSB3aXRoIHJlbW90ZSBkZXZpY2VzLsKgIFdlIGFsc28g
d2FudGVkIGNsaWVudHMgYW5kDQo+IGFwcGxpY2F0aW9ucyB0byBhY2Nlc3MgZGF0YXN0b3JlcyBp
biB0aGUgc2FtZSB3YXkgaW5kZXBlbmRlbnQgb2Ygd2hldGhlciB0aGUNCj4gYXBwbGljYXRpb25z
IHdlcmUgaG9zdGVkIG9uIGEgTmV0d29yayBFbGVtZW50IG9yIENvbnRyb2xsZXIuDQo+IA0KPiBN
aXNzaW5nIEVsZW1lbnQgIzI6IFdobyBvd25zIGFuIE9iamVjdD8NCj4gQXBwbGljYXRpb25zIGNh
bid0IHRlbGwgd2hpY2ggTmV0d29yayBFbGVtZW50IGFjcm9zcyBhIHNldCBvZiBkZXZpY2VzIGlz
IHRoZQ0KPiBhdXRob3JpdGF0aXZlIG93bmVyIG9mIGEgcGFydGljdWxhciByZXBsaWNhdGVkIG9i
amVjdC7CoCBTaW5jZSByZXBsaWNhdGVkIGRhdGENCj4gZ2V0cyBvdXQgb2Ygc3luY2gsIHJlc29s
dXRpb24gLyBjb252ZXJnZW5jZSBpcyBhIHByb2JsZW0uDQo+IA0KPiBNaXNzaW5nIEVsZW1lbnQg
IzM6IE1haW50YWluaW5nIGNhY2hlcyBvZiByZW1vdGUgaW5mb3JtYXRpb24gQXBwbGljYXRpb25z
IG5lZWQNCj4gdGltZWx5IGFjY2VzcyB0byByZW1vdGUgaW5mb3JtYXRpb24sIHdoaWNoIGNhbiBu
ZWNlc3NpdGF0ZSB0aGUgaW50cm9kdWN0aW9uDQo+IGNhY2hlIGluZnJhc3RydWN0dXJlLsKgIE5l
dGNvbmYgcHJvdmlkZXMgbGl0dGxlIHN1cHBvcnQgdG8gZmFjaWxpdGF0ZQ0KPiB0aGlzLsKgIEZv
ciBleGFtcGxlLCBub3RpZmljYXRpb25zIGFyZSBub3QgYSBnb29kIG1hdGNoIHRvIHN1YnNjcmli
ZSB0byBwdXNoLQ0KPiB1cGRhdGVzLg0KPiANCj4gVG8gc29sdmUgdGhlc2UgcHJvYmxlbXMsIHdl
IG5lZWQgdGVjaG5vbG9neSBzb2x1dGlvbnMgd2hpY2ggd29yayBlcXVhbGx5IHdlbGwNCj4gZm9y
IGJvdGggQ29udHJvbGxlcnMgYW5kIE5ldHdvcmsgRWxlbWVudHMuwqAgVGhlc2Ugc29sdXRpb25z
IG11c3QgZXhwb3NlIGxvY2FsDQo+IGRhdGFzdG9yZXMgd2hpY2ggcHJvdmlkZSBhdXRob3JpdGF0
aXZlLCBjb25zb2xpZGF0ZWQgdmlld3Mgb2YgZGlzdHJpYnV0ZWQNCj4gbmV0d29yayBvYmplY3Rz
LsKgIFRoaXMgbXVzdCBiZSBkb25lIGluIGEgd2F5IHdoaWNoIGFsbG93cyB0aGUgYXBwbGljYXRp
b25zIHRvDQo+IHNpdCBhbnl3aGVyZSBpbiB0aGUgbmV0d29yaywgb24gdmFyaW91cyBhYnN0cmFj
dGlvbnMsIHdoaWxlIG1haW50YWluaW5nIGRvbWFpbg0KPiBjb25zaXN0ZW5jeS4gQW5kIHRoaXMg
bXVzdCBiZSBkb25lIHdoaWxlIG1heGltaXppbmcgYXBwbGljYXRpb24gZGV2ZWxvcGVyDQo+IHNp
bXBsaWNpdHkuDQo+IA0KPiBUaGlzIGRyYWZ0IGlzIGludGVuZGVkIHRvIHN0YXJ0IGFnZ3JlZ2F0
aW5nIHJlcXVpcmVtZW50cyBpbiB0aGlzIHNwYWNlLsKgIFRoZQ0KPiBkcmFmdCBpcyBub3QgY29t
cGxldGUsIHNvIGl0IHdvdWxkIGJlIGdyZWF0IHRvIGhlYXIgZnJvbSBvdGhlcnMgd2hvIGFyZQ0K
PiBpbnRlcmVzdGVkIGluIGhlbHBpbmcgc28gdGhhdCB3ZSBlbmQgdXAgd2l0aCBhIG1vcmUgY29t
cHJlaGVuc2l2ZSBjb250ZXh0Lg0KPiANCj4gU29sdXRpb25zIGRvIGV4aXN0IHdoaWNoIGNhbiBz
b2x2ZSBhIHN1YnNldCBvZiB0aGVzZSByZXF1aXJlbWVudHMuwqAgT25lDQo+IHBhcnRpY3VsYXIg
dGVjaG5vbG9neSB3ZSBoYXZlIGJ1aWx0IGlzIGtub3duIGFzIOKAnHBlZXIgbW91bnTigJ0uwqAg
UGVlciBtb3VudA0KPiBnaXZlcyB0aGUgYWJpbGl0eSB0byByZWZlcmVuY2UgWUFORyBpbmZvcm1h
dGlvbiBpbnRvIGEgbG9jYWwgZGF0YXN0b3JlIGZyb20NCj4gcmVtb3RlIGRhdGFzdG9yZXMuwqAg
VGhpcyBwcm92aWRlcyBjbGllbnQgYXBwbGljYXRpb25zIHdpdGggbG9jYWwgYWNjZXNzIHRvDQo+
IGluZm9ybWF0aW9uIHdoaWNoIG1pZ2h0IGJlIHRyYW5zcGFyZW50bHkgZmVkZXJhdGVkIGFjcm9z
cyBtdWx0aXBsZSBzeXN0ZW1zIGFuZA0KPiBkYXRhc3RvcmVzLsKgIEl0IGFsc28gcmV0YWlucyBj
bGVhciBvYmplY3Qgb3duZXJzaGlwIHRvIG1pbmltaXplDQo+IHN5bmNocm9uaXphdGlvbiBhbmQg
aW50ZXItc3lzdGVtIGRlcGVuZGVuY3kgaXNzdWVzLsKgwqAgVGhlcmUgYXJlIGFscmVhZHkNCj4g
aW1wbGVtZW50YXRpb25zIG9mIHRoaXMgdGVjaG5vbG9neSwgZm9yIGV4YW1wbGUsIGluIE9wZW4g
RGF5bGlnaHQuwqAgSG93ZXZlciwNCj4gd2UgYmVsaWV2ZSByZXF1aXJlbWVudHMgYW5kIHVzZSBj
YXNlcyBmb3IgdGhpcyB0ZWNobm9sb2d5IGFwcGx5IGVxdWFsbHkgd2VsbA0KPiB0byBuZXR3b3Jr
IGRldmljZXMuDQo+IA0KPiBQbGVhc2UgbGV0IHVzIGtub3cgaWYgZWl0aGVyIHRoZSByZXF1aXJl
bWVudHMgb3IgdGVjaG5vbG9neSBzcGVjaWZpY2F0aW9ucyBhcmUNCj4gcHJvYmxlbSB5b3UgYXJl
IGludGVyZXN0ZWQgaW4gZXhwbG9yaW5nLg0KPiANCj4gVGhhbmtzIQ0KPiBFcmljLCBBbGV4LCBQ
cmFiaGFrYXJhLCBBbWJpa2EsIFNoYXNoaQ0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t
LS0NCj4gRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJh
ZnRzQGlldGYub3JnXQ0KPiBTZW50OiBUaHVyc2RheSwgU2VwdGVtYmVyIDI1LCAyMDE0IDg6NDEg
QU0NCj4gVG86IFByYWJoYWthcmEgWWVsbGFpIChweWVsbGFpKTsgU2hhc2hpIEt1bWFyIEJhbnNh
bCAoc2hhYmFuc2EpOyBBbWJpa2EgUHJhc2FkDQo+IFRyaXBhdGh5IChhbWJ0cmlwYSk7IEFsZXhh
bmRlciBDbGVtbSAoYWxleCk7IEVyaWMgVm9pdCAoZXZvaXQpOyBBbWJpa2EgUHJhc2FkDQo+IFRy
aXBhdGh5IChhbWJ0cmlwYSk7IEFsZXhhbmRlciBDbGVtbSAoYWxleCk7IFByYWJoYWthcmEgWWVs
bGFpIChweWVsbGFpKTsgRXJpYw0KPiBWb2l0IChldm9pdCk7IFNoYXNoaSBLdW1hciBCYW5zYWwg
KHNoYWJhbnNhKQ0KPiBTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0
LXZvaXQtbmV0bW9kLXBlZXItbW91bnQtDQo+IHJlcXVpcmVtZW50cy0wMC50eHQNCj4gDQo+IA0K
PiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtdm9pdC1uZXRtb2QtcGVlci1tb3VudC1yZXF1
aXJlbWVudHMtMDAudHh0DQo+IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgRXJp
YyBWb2l0IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCj4gDQo+IE5hbWU6wqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBkcmFmdC12b2l0LW5ldG1vZC1wZWVyLW1v
dW50LXJlcXVpcmVtZW50cw0KPiBSZXZpc2lvbjrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAw
MA0KPiBUaXRsZTrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFJlcXVp
cmVtZW50cyBmb3IgUGVlciBNb3VudGluZyBvZiBZQU5HIHN1YnRyZWVzDQo+IGZyb20gUmVtb3Rl
IERhdGFzdG9yZXMgRG9jdW1lbnQgZGF0ZTogMjAxNC0wOS0yNQ0KPiBHcm91cDrCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KPiBQYWdlczrC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDIyDQo+IFVSTDrCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXZvaXQt
bmV0bW9kLXBlZXItDQo+IG1vdW50LXJlcXVpcmVtZW50cy0wMC50eHQNCj4gU3RhdHVzOsKgwqDC
oMKgwqDCoMKgwqAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtdm9pdC1u
ZXRtb2QtcGVlci1tb3VudC0NCj4gcmVxdWlyZW1lbnRzLw0KPiBIdG1saXplZDrCoMKgwqDCoMKg
wqAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdm9pdC1uZXRtb2QtcGVlci1tb3Vu
dC0NCj4gcmVxdWlyZW1lbnRzLTAwDQo+IA0KPiANCj4gQWJzdHJhY3Q6DQo+IMKgwqAgTmV0d29y
ayBpbnRlZ3JhdGVkIGFwcGxpY2F0aW9ucyB3YW50IHNpbXBsZSB3YXlzIHRvIGFjY2VzcyBZQU5H
DQo+IMKgwqAgb2JqZWN0cyBhbmQgc3VidHJlZXMgd2hpY2ggbWlnaHQgYmUgZGlzdHJpYnV0ZWQg
YWNyb3NzIG5ldHdvcmsuDQo+IMKgwqAgUGVyZm9ybWFuY2UgcmVxdWlyZW1lbnRzIG1heSBkaWN0
YXRlIHRoYXQgaXQgaXMgdW5hZmZvcmRhYmxlIGZvciBhDQo+IMKgwqAgc3Vic2V0IG9mIHRoZXNl
IGFwcGxpY2F0aW9ucyB0byBnbyB0aHJvdWdoIGV4aXN0aW5nIGNlbnRyYWxpemVkDQo+IMKgwqAg
bWFuYWdlbWVudCBicm9rZXJzLsKgIEZvciBzdWNoIGFwcGxpY2F0aW9ucywgZGV2ZWxvcG1lbnQg
Y29tcGxleGl0eQ0KPiDCoMKgIG11c3QgYmUgbWluaW1pemVkLsKgIFNwZWNpZmljIGFzcGVjdHMg
b2YgY29tcGxleGl0eSBkZXZlbG9wZXJzIHdhbnQgdG8NCj4gwqDCoCBpZ25vcmUgaW5jbHVkZToN
Cj4gDQo+IMKgwqAgb8KgIHdoZXRoZXIgYXV0aG9yaXRhdGl2ZSBpbmZvcm1hdGlvbiBpcyBhY3R1
YWxseSBzb3VyY2VkIGZyb20gcmVtb3RlDQo+IMKgwqDCoMKgwqAgZGF0YXN0b3JlcyAoYXMgd2Vs
bCBhcyBob3cgdG8gZ2V0IHRvIHRob3NlIGRhdGFzdG9yZXMpLA0KPiANCj4gwqDCoCBvwqAgd2hl
dGhlciBzdWNoIGluZm9ybWF0aW9uIGhhcyBiZWVuIGxvY2FsbHkgY2FjaGVkIG9yIG5vdCwNCj4g
DQo+IMKgwqAgb8KgIHdoZXRoZXIgdGhlcmUgYXJlIHplcm8sIG9uZSwgb3IgbW9yZSBjb250cm9s
bGVycyBhc3NlcnRpbmcNCj4gwqDCoMKgwqDCoCBvd25lcnNoaXAgb2YgaW5mb3JtYXRpb24sIGFu
ZA0KPiANCj4gwqDCoCBvwqAgd2hldGhlciB0aGVyZSBhcmUgaW50ZXJhY3Rpb25zIHdpdGggb3Ro
ZXIgYXBwbGljYXRpb25zDQo+IMKgwqDCoMKgwqAgY29uY3VycmVudGx5IHJ1bm5pbmcgZWxzZXdo
ZXJlDQo+IA0KPiDCoMKgIFRoZSBzb2x1dGlvbiByZXF1aXJlbWVudHMgZGVzY3JpYmVkIGluIHRo
aXMgZG9jdW1lbnQgZGV0YWlsIHdoYXQgaXMNCj4gwqDCoCBuZWVkZWQgdG8gc3VwcG9ydCBhcHBs
aWNhdGlvbiBhY2Nlc3MgdG8gYXV0aG9yaXRhdGl2ZSBuZXR3b3JrIFlBTkcNCj4gwqDCoCBvYmpl
Y3RzIGZyb20gY29udHJvbGxlcnMgKHN0YXIpIG9yIHBlZXJpbmcgbmV0d29yayBkZXZpY2VzICht
ZXNoKSBpbg0KPiDCoMKgIHN1Y2ggYSB3YXkgdG8gbWVldCB0aGVzZSBnb2Fscy4NCj4gDQo+IA0K
PiANCj4gDQo+IA0KPiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1p
bnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQo+IHVudGlsIHRoZSBodG1saXplZCB2
ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQo+IA0KPiBU
aGUgSUVURiBTZWNyZXRhcmlhdA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18NCj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPiBuZXRtb2RAaWV0Zi5v
cmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCj4gX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gU3VwYSBtYWls
aW5nIGxpc3QNCj4gU3VwYUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu
L2xpc3RpbmZvL3N1cGENCg==


From nobody Fri Sep 26 21:06:43 2014
Return-Path: 
X-Original-To: supa@ietfa.amsl.com
Delivered-To: supa@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E9911A01EA for ; Fri, 26 Sep 2014 21:06:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level: 
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_14=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 7tiiddMlKssM for ; Fri, 26 Sep 2014 21:06:37 -0700 (PDT)
Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F30371A011F for ; Fri, 26 Sep 2014 21:06:36 -0700 (PDT)
Received: by mail-oi0-f50.google.com with SMTP id a141so9275380oig.9 for ; Fri, 26 Sep 2014 21:06:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qaut0kfXL9R8ogoOJ2+jtbVyQ13jtpI5QIepFP8g+gE=; b=NmsMxO5pEQ4blhdT1LNbsiMX7y2CFft0eWy/5ZKYxh+IgcrV8NfdJwAItQ4UxPxafz XoEMKQNR8W4y44+3PTONAbOT1CHhqcw2S1vaMbbhqxFXBHf6Vx2Tn9F+3yDaDwdg7f86 dTuU3DBLiGpUr3aVDy6MizXtD7aUEi/ixt3rNNwy7tJCyz3R4/LIIhZ+1rOw2lKi5g7f IhvoRG+oaSqqsQ3ftcVprDDcalvu5lHqldITJcoK5L8iW/0jHgg57gOls0ZvIcpfjlex eOP2PmqgRJastVeXUmIpT7QGVuZB3grZyEN9ZTgYjPU6Amc3+u9pOgEYL2gP8MxqPEw+ 70Qg==
MIME-Version: 1.0
X-Received: by 10.60.60.131 with SMTP id h3mr25639243oer.17.1411790796389; Fri, 26 Sep 2014 21:06:36 -0700 (PDT)
Received: by 10.76.35.39 with HTTP; Fri, 26 Sep 2014 21:06:36 -0700 (PDT)
In-Reply-To: 
References: 
Date: Fri, 26 Sep 2014 21:06:36 -0700
Message-ID: 
From: Parviz Yegani 
To: Georgios Karagiannis 
Content-Type: multipart/alternative; boundary=089e0149bb24ea83a1050404287b
Archived-At: http://mailarchive.ietf.org/arch/msg/supa/L0omJjIksce-q4hgTF9rrETm3kM
Cc: "supa@ietf.org" 
Subject: Re: [Supa] New SUPA charter
X-BeenThere: supa@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 27 Sep 2014 04:06:40 -0000

--089e0149bb24ea83a1050404287b
Content-Type: text/plain; charset=UTF-8

Great job Georgios. The charter is well written and nicely structured. The
notion of "network boxes", however, is a bit confusing. I'd rather to
replace it with "network nodes" or "network components". I also have some
other minor editorial comments. I will send it in a separate email. It's
good that you mentioned the SUPA WG (once formed) will collaborate with
other relevant groups within IETF (NETCONF, Yang doctors, ..) to ensure
consistency and avoid divergence or perhaps any possible duplication of
work.

Thanks,
Parviz

On Thu, Sep 25, 2014 at 5:31 PM, Georgios Karagiannis <
georgios.karagiannis@huawei.com> wrote:

>  Hi all,
>
>
>
> We have worked out all comments that we have received on the previous
> version of the SUPA charter.
>
> The new version of the charter can be seen below:
>
>
>
> Best regards,
>
> Georgios
>
>
>
>
>
> =================================================
>
> SUPA (Shared Unified Policy Automation) charter v1.12
>
> Target Area: Operations and Management
>
>
>
> Description of Working Group:
>
>
>
> Programmatic ways to configure networks, often called software-defined,
> are considered by many network operators in order to shift the balance in
> their favor.
>
> Automating the way of exposing a view of the network to applications may
> provide significant improvements in configuration agility, error detection
> and uptime for operators. However the real value behind central
> configuration schemes lies within the possible simplification through
> models provided by such systems to applications and network services
> running above them (on the so-called northbound side). Well-designed models
> are able to provide a wide range of granularity for various applications
> and network services needs, from the lower-level physical network to
> high-level application services.
>
>
>
> Several organizations outside of the IETF have defined various schemes for
> the configuration of network devices and specific network controllers, but
> none of them offer a vendor-neutral standardized way for applications and
> network services to transmit their needs to network controllers. The SUPA
> (Shared Unified Policy Automation) working group will work on the
> definition of such as standardized interface for applications and network
> services to communicate with network controllers of all types. In
> particular, SUPA will focus on service specific models that allow
> applications to request certain network services to be
> created/deleted/modified. A network service can for example be a virtual
> link between two endpoints that uses certain properties, traffic
> engineering, implementation of IPv6 transition mechanism and their
> enforcement to users.
>
>
>
> Each network service can be represented by a service based POLICY model
> that can model a group of demands (i.e., actions and constraints) that are
> being initiated by applications that impose similar requirements on the
> communication network. The terms "UNIFIED" and "SHARED" used in the SUPA
> abbreviation, relate to the way of how the service policy model is
> generated, since it groups, unifies and shares the similar requirements
> imposed by a bulk of applications. SUPA will provide guidelines for
> mechanisms that can dynamically and on an interoperable manner,
> AUTOMATICALLY map services and policies defined on an abstract topology
> graph down to more detailed network graphs and specific network management
> and controlling policies.
>
>
>
> Some IETF working groups have started work relating to the description of
> various topologies such as I2RS (L3 and routing topologies), ALTO (cost
> maps), SFC (service chain), none of these groups aim (1) at offering truly
> generic topology models for the standard northbound interface, and (2) that
> an application can communicate with network boxes, such as network
> controllers, and NEs, developed by different vendors.
>
> SUPA will work on defining vendor-neutral standardized interfaces based on
> the concept of network graph, an entity describing an arbitrary topology of
> nodes and links at any level of granularity. Such a network graph describes
> (1) topologies at different levels of abstraction, (2) the relationships
> between the abstraction levels and (3) applied service based policy, which
> are actions and constraints applied on these topologies.
>
> SUPA may also define any mappings to any other network topology data
> models defined within the IETF.
>
>
>
> The main goal of SUPA is to provide service specific models that allow
> applications to request network services to be created/deleted/modified.
> This can be realized by:
>
>   o) model multiple topologies at different levels of abstraction using a
> network graph,
>
>   o) model the relationships between the abstraction levels.
>
>   o) transporting model instances using either NETCONF or RESTCONF
>
>
>
> SUPA will ensure that in case any specific NETCONF/RESTCONF protocol
> requirements are identified, they will be communicated in a timely manner
> to the NETCONF working group. SUPA will consult with the YANG doctors to
> ensure that data models follow common practices.
>
>
>
> Work items for SUPA include:
>
> ============================
>
> 1) The definition of a standardized model for a network graph, using YANG.
> This model may be used to describe topologies at any functional layer, from
> physical networks to network services.
>
> 2) The definition and standardization of a number of basic policy and data
> models using network graphs. These might include, but are not limited to
> L3VPNs, traffic engineering, implementation of IPv6 transition mechanism
> and their enforcement to users.
>
> 3) Provide guidelines for mechanisms that can dynamically and on an
> interoperable manner, automatically map services and policies defined on an
> abstract topology graph down to more detailed network graphs and specific
> network management and controlling policies.
>
> 4) Guidelines on how to use NETCONF (or RESTCONF) authentication and
> authorization mechanisms to achieve protection and isolation
>
>
>
> Deliverables:
>
> =============
>
> o) Produce an informational RFC "Problem Statement and Use Cases".
>
> o) Produce a standards-track RFC that specifies YANG models for a generic
> multi-layer network graph.
>
> o) Produce standards-track RFCs that specify extensions for the generic
> YANG models defined above for network services that manage virtual links,
> traffic engineering and implementation of IPv6 transition mechanism and
> their enforcement to users.
>
> o) Produce an informational RFC that provides the guidelines for
> mechanisms that can dynamically and on interoperable manner, automatically
> map services and policies defined on an abstract topology graph down to
> more detailed network graphs and specific network management and
> controlling policies.
>
> o) Produce an informational RFC that provides the guidelines on using
> NETCONF (or RESTCONF) authentication and authorization mechanisms to
> achieve security protection and isolation' as an Informational RFC.
>
>
>
> Milestones:
>
> ===========
>
> Dec 2014  Initial "Problem Statement and Use Cases" WG I-D
>
> Feb 2015  Initial "Multi-layer Network Graph YANG Model" WG I-D
>
> Apr 2015  Initial service specific data model WG I-Ds
>
> May 2015  Initial "Mapping Guidelines" WG I-D
>
> Jun 2015  Submit "Problem Statement and Use Cases" I-D to IESG
>
> Jul 2015  Initial "Authentication and Authorization" WG I-D
>
> Sep 2015  Submit "Multi-layer Network Graph YANG Model" I-D to IESG
>
> Nov 2015  Submit service specific data model I-Ds to IESG
>
> Feb 2016  Submit "Mapping Guidelines" I-D to IESG
>
> Apr 2016  Submit "Authentication and Authorization" I-D to IESG
>
>
>
>
>
>
>
> _______________________________________________
> Supa mailing list
> Supa@ietf.org
> https://www.ietf.org/mailman/listinfo/supa
>
>


-- 
Dr. Parviz Yegani
(408) 759-1973 mobile
pyegani@gmail.com

--089e0149bb24ea83a1050404287b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Great job Georgios. The charter is well written and nicely structured. Th=
e notion of "network boxes", however, is a bit confusing. I'd=
 rather to replace it with "network nodes" or "network compo=
nents". I also have some other minor editorial comments. I will send i=
t in a separate email. It's good that you mentioned the SUPA WG (once f=
ormed) will collaborate with other relevant groups within IETF (NETCONF, Ya=
ng doctors, ..) to ensure consistency and avoid divergence or perhaps any p=
ossible duplication of work.

Thanks,
Parviz

On Thu, Sep 25, 2014 at 5:31 PM, Georgios Karagiannis <georgios.karagiannis@huawei.com> wrote:











Hi all,


=C2=A0


We have worked out all comments that we have receive=
d on the previous version of the SUPA charter.


The new version of the charter can be seen below:=



=C2=A0


Best regards,


Georgios


=C2=A0


=C2=A0


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D


SUPA (Shared Unified Policy Automation) charter v1.1=
2


Target Area: Operations and Management=



=C2=A0


Description of Working Group:


=C2=A0


Programmatic ways to configure networks, often calle=
d software-defined, are considered by many network operators in order to sh=
ift the balance in their favor.


Automating the way of exposing a view of the network=
 to applications may provide significant improvements in configuration agil=
ity, error detection and uptime for operators. However the real value behin=
d central configuration schemes lies
 within the possible simplification through models provided by such systems=
 to applications and network services running above them (on the so-called =
northbound side). Well-designed models are able to provide a wide range of =
granularity for various applications
 and network services needs, from the lower-level physical network to high-=
level application services.



=C2=A0


Several organizations outside of the IETF have defin=
ed various schemes for the configuration of network devices and specific ne=
twork controllers, but none of them offer a vendor-neutral standardized way=
 for applications and network services
 to transmit their needs to network controllers. The SUPA (Shared Unified P=
olicy Automation) working group will work on the definition of such as stan=
dardized interface for applications and network services to communicate wit=
h network controllers of all types.
 In particular, SUPA will focus on service specific models that allow appli=
cations to request certain network services to be created/deleted/modified.=
 A network service can for example be a virtual link between two endpoints =
that uses certain properties, traffic
 engineering, implementation of IPv6 transition mechanism and their enforce=
ment to users.


=C2=A0


Each network service can be represented by a service=
 based POLICY model that can model a group of demands (i.e., actions and co=
nstraints) that are being initiated by applications that impose similar req=
uirements on the communication network.
 The terms "UNIFIED" and "SHARED" used in the SUPA abbr=
eviation, relate to the way of how the service policy model is generated, s=
ince it groups, unifies and shares the similar requirements imposed by a bu=
lk of applications. SUPA will provide guidelines for
 mechanisms that can dynamically and on an interoperable manner, AUTOMATICA=
LLY map services and policies defined on an abstract topology graph down to=
 more detailed network graphs and specific network management and controlli=
ng policies.


=C2=A0


Some IETF working groups have started work relating =
to the description of various topologies such as I2RS (L3 and routing topol=
ogies), ALTO (cost maps), SFC (service chain), none of these groups aim (1)=
 at offering truly generic topology
 models for the standard northbound interface, and (2) that an application =
can communicate with network boxes, such as network controllers, and NEs, d=
eveloped by different vendors.


SUPA will work on defining vendor-neutral standardiz=
ed interfaces based on the concept of network graph, an entity describing a=
n arbitrary topology of nodes and links at any level of granularity. Such a=
 network graph describes (1) topologies
 at different levels of abstraction, (2) the relationships between the abst=
raction levels and (3) applied service based policy, which are actions and =
constraints applied on these topologies.



SUPA may also define any mappings to any other netwo=
rk topology data models defined within the IETF.


=C2=A0


The main goal of SUPA is to provide service specific=
 models that allow applications to request network services to be created/d=
eleted/modified. This can be realized by:


=C2=A0 o) model multiple topologies at different lev=
els of abstraction using a network graph,



=C2=A0=C2=A0o) model the relationships between the a=
bstraction levels.


=C2=A0 o) transporting model instances using either =
NETCONF or RESTCONF



=C2=A0


SUPA will ensure that in case any specific NETCONF/R=
ESTCONF protocol requirements are identified, they will be communicated in =
a timely manner to the NETCONF working group. SUPA will consult with the YA=
NG doctors to ensure that data models
 follow common practices.


=C2=A0


Work items for SUPA include:


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


1) The definition of a standardized model for a netw=
ork graph, using YANG. This model may be used to describe topologies at any=
 functional layer, from physical networks to network services.



2) The definition and standardization of a number of=
 basic policy and data models using network graphs. These might include, bu=
t are not limited to L3VPNs, traffic engineering, implementation of IPv6 tr=
ansition mechanism and their enforcement
 to users.=C2=A0 


3) Provide guidelines for mechanisms that can dynami=
cally and on an interoperable manner, automatically map services and polici=
es defined on an abstract topology graph down to more detailed network grap=
hs and specific network management
 and controlling policies.


4) Guidelines on how to use NETCONF (or RESTCONF) au=
thentication and authorization mechanisms to achieve protection and isolati=
on


=C2=A0


Deliverables:


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


o) Produce an informational RFC "Problem Statem=
ent and Use Cases".


o) Produce a standards-track RFC that specifies YANG=
 models for a generic multi-layer network graph.


o) Produce standards-track RFCs that specify extensi=
ons for the generic YANG models defined above for network services that man=
age virtual links, traffic engineering and implementation of IPv6 transitio=
n mechanism and their enforcement
 to users.


o) Produce an informational RFC that provides the gu=
idelines for mechanisms that can dynamically and on interoperable manner, a=
utomatically map services and policies defined on an abstract topology grap=
h down to more detailed network graphs
 and specific network management and controlling policies.

o) Produce an informational RFC that provides the gu=
idelines on using NETCONF (or RESTCONF) authentication and authorization me=
chanisms to achieve security protection and isolation' as an Informatio=
nal RFC.


=C2=A0


Milestones:


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


Dec 2014=C2=A0 Initial "Problem Statement and U=
se Cases" WG I-D


Feb 2015=C2=A0 Initial "Multi-layer Network Gra=
ph YANG Model" WG I-D


Apr 2015=C2=A0 Initial service specific data model W=
G I-Ds 


May 2015=C2=A0 Initial "Mapping Guidelines"=
; WG I-D


Jun 2015=C2=A0 Submit "Problem Statement and Us=
e Cases" I-D to IESG


Jul 2015=C2=A0 Initial "Authentication and Auth=
orization" WG I-D


Sep 2015=C2=A0 Submit "Multi-layer Network Grap=
h YANG Model" I-D to IESG


Nov 2015=C2=A0 Submit service specific data model I-=
Ds to IESG


Feb 2016=C2=A0 Submit "Mapping Guidelines"=
 I-D to IESG


Apr 2016=C2=A0 Submit "Authentication and Autho=
rization" I-D to IESG


=C2=A0


=C2=A0


=C2=A0







_______________________________________________

Supa mailing list

Supa@ietf.org

ht=
tps://www.ietf.org/mailman/listinfo/supa





-- 
Dr. Parviz Yegani
(408) 759-1973 mobile
<=
a href=3D"mailto:pyegani@gmail.com" target=3D"_blank">pyegani@gmail.com=





--089e0149bb24ea83a1050404287b--


From nobody Sat Sep 27 13:48:02 2014
Return-Path: 
X-Original-To: supa@ietfa.amsl.com
Delivered-To: supa@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6FAC1A0406 for ; Sat, 27 Sep 2014 13:48:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level: 
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_14=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 At1J5kKR4baF for ; Sat, 27 Sep 2014 13:47:59 -0700 (PDT)
Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEB461A0342 for ; Sat, 27 Sep 2014 13:47:58 -0700 (PDT)
Received: by mail-oi0-f43.google.com with SMTP id x69so273837oia.2 for ; Sat, 27 Sep 2014 13:47:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=SFYgDvLKt4vbwifFGiBWE30y+JbEoC5tZseqzLpnT94=; b=LTYCKWZv2BqdSRJ+ygxAdYQpuVr9BlGqbvCtTrR0h5t1rleTF7PjMcBARwRDnp7eDD shRGbprPnBZY31yC72dmwv7FDOCV18Dhmk4nF470J9p6bHIkYC92fODRDLCKR652L3MA splPyS8kDP1oRhyV7cMoFfyw3K0O2+lRzu+ULt5jH81qySEhm6KYU+0+S9hbgOTJRLt0 8tYQRpTL+jkkDU5+7TW8pdL4hOx1Fxp/5l4zakIsJmZGXqjZxnOU5XjaxcPfx7BBFKG/ 68D1JECwnoPBHJWWI8G4bpWeSfXOgjNw0akMyTtx918xQdwqsqrT2xoiX21/ueJTVmmU ZJLg==
MIME-Version: 1.0
X-Received: by 10.60.78.233 with SMTP id e9mr7455204oex.49.1411850878164; Sat, 27 Sep 2014 13:47:58 -0700 (PDT)
Received: by 10.76.35.39 with HTTP; Sat, 27 Sep 2014 13:47:58 -0700 (PDT)
In-Reply-To: 
References: 
Date: Sat, 27 Sep 2014 13:47:58 -0700
Message-ID: 
From: Parviz Yegani 
To: "supa@ietf.org" 
Content-Type: multipart/alternative; boundary=089e0111e15411a74b05041226f3
Archived-At: http://mailarchive.ietf.org/arch/msg/supa/bvBz7yWOjyNT0pg2-XqtMeyyfFo
Subject: Re: [Supa] New SUPA charter
X-BeenThere: supa@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 27 Sep 2014 20:48:02 -0000

--089e0111e15411a74b05041226f3
Content-Type: text/plain; charset=UTF-8

Great job Georgios. The charter is well written and nicely structured. The
notion of "network boxes", however, is a bit confusing. I'd rather to
replace it with "network nodes" or "network components". I also have some
other minor editorial comments. I will send it in a separate email. It's
good that you mentioned the SUPA WG (once formed) will collaborate with
other relevant groups within IETF (NETCONF, Yang doctors, ..) to ensure
consistency and avoid divergence or perhaps any possible duplication of
work.

Thanks,
Parviz


On Thu, Sep 25, 2014 at 5:31 PM, Georgios Karagiannis <
georgios.karagiannis@huawei.com> wrote:

>  Hi all,
>
>
>
> We have worked out all comments that we have received on the previous
> version of the SUPA charter.
>
> The new version of the charter can be seen below:
>
>
>
> Best regards,
>
> Georgios
>
>
>
>
>
> =================================================
>
> SUPA (Shared Unified Policy Automation) charter v1.12
>
> Target Area: Operations and Management
>
>
>
> Description of Working Group:
>
>
>
> Programmatic ways to configure networks, often called software-defined,
> are considered by many network operators in order to shift the balance in
> their favor.
>
> Automating the way of exposing a view of the network to applications may
> provide significant improvements in configuration agility, error detection
> and uptime for operators. However the real value behind central
> configuration schemes lies within the possible simplification through
> models provided by such systems to applications and network services
> running above them (on the so-called northbound side). Well-designed models
> are able to provide a wide range of granularity for various applications
> and network services needs, from the lower-level physical network to
> high-level application services.
>
>
>
> Several organizations outside of the IETF have defined various schemes for
> the configuration of network devices and specific network controllers, but
> none of them offer a vendor-neutral standardized way for applications and
> network services to transmit their needs to network controllers. The SUPA
> (Shared Unified Policy Automation) working group will work on the
> definition of such as standardized interface for applications and network
> services to communicate with network controllers of all types. In
> particular, SUPA will focus on service specific models that allow
> applications to request certain network services to be
> created/deleted/modified. A network service can for example be a virtual
> link between two endpoints that uses certain properties, traffic
> engineering, implementation of IPv6 transition mechanism and their
> enforcement to users.
>
>
>
> Each network service can be represented by a service based POLICY model
> that can model a group of demands (i.e., actions and constraints) that are
> being initiated by applications that impose similar requirements on the
> communication network. The terms "UNIFIED" and "SHARED" used in the SUPA
> abbreviation, relate to the way of how the service policy model is
> generated, since it groups, unifies and shares the similar requirements
> imposed by a bulk of applications. SUPA will provide guidelines for
> mechanisms that can dynamically and on an interoperable manner,
> AUTOMATICALLY map services and policies defined on an abstract topology
> graph down to more detailed network graphs and specific network management
> and controlling policies.
>
>
>
> Some IETF working groups have started work relating to the description of
> various topologies such as I2RS (L3 and routing topologies), ALTO (cost
> maps), SFC (service chain), none of these groups aim (1) at offering truly
> generic topology models for the standard northbound interface, and (2) that
> an application can communicate with network boxes, such as network
> controllers, and NEs, developed by different vendors.
>
> SUPA will work on defining vendor-neutral standardized interfaces based on
> the concept of network graph, an entity describing an arbitrary topology of
> nodes and links at any level of granularity. Such a network graph describes
> (1) topologies at different levels of abstraction, (2) the relationships
> between the abstraction levels and (3) applied service based policy, which
> are actions and constraints applied on these topologies.
>
> SUPA may also define any mappings to any other network topology data
> models defined within the IETF.
>
>
>
> The main goal of SUPA is to provide service specific models that allow
> applications to request network services to be created/deleted/modified.
> This can be realized by:
>
>   o) model multiple topologies at different levels of abstraction using a
> network graph,
>
>   o) model the relationships between the abstraction levels.
>
>   o) transporting model instances using either NETCONF or RESTCONF
>
>
>
> SUPA will ensure that in case any specific NETCONF/RESTCONF protocol
> requirements are identified, they will be communicated in a timely manner
> to the NETCONF working group. SUPA will consult with the YANG doctors to
> ensure that data models follow common practices.
>
>
>
> Work items for SUPA include:
>
> ============================
>
> 1) The definition of a standardized model for a network graph, using YANG.
> This model may be used to describe topologies at any functional layer, from
> physical networks to network services.
>
> 2) The definition and standardization of a number of basic policy and data
> models using network graphs. These might include, but are not limited to
> L3VPNs, traffic engineering, implementation of IPv6 transition mechanism
> and their enforcement to users.
>
> 3) Provide guidelines for mechanisms that can dynamically and on an
> interoperable manner, automatically map services and policies defined on an
> abstract topology graph down to more detailed network graphs and specific
> network management and controlling policies.
>
> 4) Guidelines on how to use NETCONF (or RESTCONF) authentication and
> authorization mechanisms to achieve protection and isolation
>
>
>
> Deliverables:
>
> =============
>
> o) Produce an informational RFC "Problem Statement and Use Cases".
>
> o) Produce a standards-track RFC that specifies YANG models for a generic
> multi-layer network graph.
>
> o) Produce standards-track RFCs that specify extensions for the generic
> YANG models defined above for network services that manage virtual links,
> traffic engineering and implementation of IPv6 transition mechanism and
> their enforcement to users.
>
> o) Produce an informational RFC that provides the guidelines for
> mechanisms that can dynamically and on interoperable manner, automatically
> map services and policies defined on an abstract topology graph down to
> more detailed network graphs and specific network management and
> controlling policies.
>
> o) Produce an informational RFC that provides the guidelines on using
> NETCONF (or RESTCONF) authentication and authorization mechanisms to
> achieve security protection and isolation' as an Informational RFC.
>
>
>
> Milestones:
>
> ===========
>
> Dec 2014  Initial "Problem Statement and Use Cases" WG I-D
>
> Feb 2015  Initial "Multi-layer Network Graph YANG Model" WG I-D
>
> Apr 2015  Initial service specific data model WG I-Ds
>
> May 2015  Initial "Mapping Guidelines" WG I-D
>
> Jun 2015  Submit "Problem Statement and Use Cases" I-D to IESG
>
> Jul 2015  Initial "Authentication and Authorization" WG I-D
>
> Sep 2015  Submit "Multi-layer Network Graph YANG Model" I-D to IESG
>
> Nov 2015  Submit service specific data model I-Ds to IESG
>
> Feb 2016  Submit "Mapping Guidelines" I-D to IESG
>
> Apr 2016  Submit "Authentication and Authorization" I-D to IESG
>
>
>
>
>
>
>
> _______________________________________________
> Supa mailing list
> Supa@ietf.org
> https://www.ietf.org/mailman/listinfo/supa
>
>


-- 
Dr. Parviz Yegani
(408) 759-1973 mobile
pyegani@gmail.com

--089e0111e15411a74b05041226f3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Great job Georgios. The charter is well wri=
tten and nicely structured. The notion of "network boxes", howeve=
r, is a bit confusing. I'd rather to replace it with "network node=
s" or "network components". I also have some other minor edi=
torial comments. I will send it in a separate email. It's good that you=
 mentioned the SUPA WG (once formed) will collaborate with other relevant g=
roups within IETF (NETCONF, Yang doctors, ..) to ensure consistency and avo=
id divergence or perhaps any possible duplication of work.

Thanks,
Parviz


On Thu, Sep 25, 2014 at 5=
:31 PM, Georgios Karagiannis <georgios.karagiannis@huawei.co=
m> wrote:











Hi all,


=C2=A0


We have worked out all comments that we have receive=
d on the previous version of the SUPA charter.


The new version of the charter can be seen below:=



=C2=A0


Best regards,


Georgios


=C2=A0


=C2=A0


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D


SUPA (Shared Unified Policy Automation) charter v1.1=
2


Target Area: Operations and Management=



=C2=A0


Description of Working Group:


=C2=A0


Programmatic ways to configure networks, often calle=
d software-defined, are considered by many network operators in order to sh=
ift the balance in their favor.


Automating the way of exposing a view of the network=
 to applications may provide significant improvements in configuration agil=
ity, error detection and uptime for operators. However the real value behin=
d central configuration schemes lies
 within the possible simplification through models provided by such systems=
 to applications and network services running above them (on the so-called =
northbound side). Well-designed models are able to provide a wide range of =
granularity for various applications
 and network services needs, from the lower-level physical network to high-=
level application services.



=C2=A0


Several organizations outside of the IETF have defin=
ed various schemes for the configuration of network devices and specific ne=
twork controllers, but none of them offer a vendor-neutral standardized way=
 for applications and network services
 to transmit their needs to network controllers. The SUPA (Shared Unified P=
olicy Automation) working group will work on the definition of such as stan=
dardized interface for applications and network services to communicate wit=
h network controllers of all types.
 In particular, SUPA will focus on service specific models that allow appli=
cations to request certain network services to be created/deleted/modified.=
 A network service can for example be a virtual link between two endpoints =
that uses certain properties, traffic
 engineering, implementation of IPv6 transition mechanism and their enforce=
ment to users.


=C2=A0


Each network service can be represented by a service=
 based POLICY model that can model a group of demands (i.e., actions and co=
nstraints) that are being initiated by applications that impose similar req=
uirements on the communication network.
 The terms "UNIFIED" and "SHARED" used in the SUPA abbr=
eviation, relate to the way of how the service policy model is generated, s=
ince it groups, unifies and shares the similar requirements imposed by a bu=
lk of applications. SUPA will provide guidelines for
 mechanisms that can dynamically and on an interoperable manner, AUTOMATICA=
LLY map services and policies defined on an abstract topology graph down to=
 more detailed network graphs and specific network management and controlli=
ng policies.


=C2=A0


Some IETF working groups have started work relating =
to the description of various topologies such as I2RS (L3 and routing topol=
ogies), ALTO (cost maps), SFC (service chain), none of these groups aim (1)=
 at offering truly generic topology
 models for the standard northbound interface, and (2) that an application =
can communicate with network boxes, such as network controllers, and NEs, d=
eveloped by different vendors.


SUPA will work on defining vendor-neutral standardiz=
ed interfaces based on the concept of network graph, an entity describing a=
n arbitrary topology of nodes and links at any level of granularity. Such a=
 network graph describes (1) topologies
 at different levels of abstraction, (2) the relationships between the abst=
raction levels and (3) applied service based policy, which are actions and =
constraints applied on these topologies.



SUPA may also define any mappings to any other netwo=
rk topology data models defined within the IETF.


=C2=A0


The main goal of SUPA is to provide service specific=
 models that allow applications to request network services to be created/d=
eleted/modified. This can be realized by:


=C2=A0 o) model multiple topologies at different lev=
els of abstraction using a network graph,



=C2=A0=C2=A0o) model the relationships between the a=
bstraction levels.


=C2=A0 o) transporting model instances using either =
NETCONF or RESTCONF



=C2=A0


SUPA will ensure that in case any specific NETCONF/R=
ESTCONF protocol requirements are identified, they will be communicated in =
a timely manner to the NETCONF working group. SUPA will consult with the YA=
NG doctors to ensure that data models
 follow common practices.


=C2=A0


Work items for SUPA include:


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


1) The definition of a standardized model for a netw=
ork graph, using YANG. This model may be used to describe topologies at any=
 functional layer, from physical networks to network services.



2) The definition and standardization of a number of=
 basic policy and data models using network graphs. These might include, bu=
t are not limited to L3VPNs, traffic engineering, implementation of IPv6 tr=
ansition mechanism and their enforcement
 to users.=C2=A0 


3) Provide guidelines for mechanisms that can dynami=
cally and on an interoperable manner, automatically map services and polici=
es defined on an abstract topology graph down to more detailed network grap=
hs and specific network management
 and controlling policies.


4) Guidelines on how to use NETCONF (or RESTCONF) au=
thentication and authorization mechanisms to achieve protection and isolati=
on


=C2=A0


Deliverables:


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


o) Produce an informational RFC "Problem Statem=
ent and Use Cases".


o) Produce a standards-track RFC that specifies YANG=
 models for a generic multi-layer network graph.


o) Produce standards-track RFCs that specify extensi=
ons for the generic YANG models defined above for network services that man=
age virtual links, traffic engineering and implementation of IPv6 transitio=
n mechanism and their enforcement
 to users.


o) Produce an informational RFC that provides the gu=
idelines for mechanisms that can dynamically and on interoperable manner, a=
utomatically map services and policies defined on an abstract topology grap=
h down to more detailed network graphs
 and specific network management and controlling policies.

o) Produce an informational RFC that provides the gu=
idelines on using NETCONF (or RESTCONF) authentication and authorization me=
chanisms to achieve security protection and isolation' as an Informatio=
nal RFC.


=C2=A0


Milestones:


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


Dec 2014=C2=A0 Initial "Problem Statement and U=
se Cases" WG I-D


Feb 2015=C2=A0 Initial "Multi-layer Network Gra=
ph YANG Model" WG I-D


Apr 2015=C2=A0 Initial service specific data model W=
G I-Ds 


May 2015=C2=A0 Initial "Mapping Guidelines"=
; WG I-D


Jun 2015=C2=A0 Submit "Problem Statement and Us=
e Cases" I-D to IESG


Jul 2015=C2=A0 Initial "Authentication and Auth=
orization" WG I-D


Sep 2015=C2=A0 Submit "Multi-layer Network Grap=
h YANG Model" I-D to IESG


Nov 2015=C2=A0 Submit service specific data model I-=
Ds to IESG


Feb 2016=C2=A0 Submit "Mapping Guidelines"=
 I-D to IESG


Apr 2016=C2=A0 Submit "Authentication and Autho=
rization" I-D to IESG


=C2=A0


=C2=A0


=C2=A0







_______________________________________________

Supa mailing list

Supa@ietf.org

ht=
tps://www.ietf.org/mailman/listinfo/supa





-- 
Dr. Parviz Yegani
(408) 759-1973 mobile
<=
a href=3D"mailto:pyegani@gmail.com" target=3D"_blank">pyegani@gmail.com=





--089e0111e15411a74b05041226f3--


From nobody Sat Sep 27 18:38:26 2014
Return-Path: 
X-Original-To: supa@ietfa.amsl.com
Delivered-To: supa@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE6E01A00DF for ; Sat, 27 Sep 2014 18:38:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.986
X-Spam-Level: 
X-Spam-Status: No, score=-3.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_AFFORDABLE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 8JE0wDgeMxzn for ; Sat, 27 Sep 2014 18:38:19 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0C3A1A00C3 for ; Sat, 27 Sep 2014 18:38:18 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNB72747; Sun, 28 Sep 2014 01:38:17 +0000 (GMT)
Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 28 Sep 2014 02:38:16 +0100
Received: from szxeml557-mbs.china.huawei.com ([169.254.6.57]) by szxeml405-hub.china.huawei.com ([::1]) with mapi id 14.03.0158.001; Sun, 28 Sep 2014 09:38:05 +0800
From: Tina TSOU 
To: Georgios Karagiannis , "Eric Voit (evoit)" , "supa@ietf.org" 
Thread-Topic: [netmod] "00" Notification for draft-voit-netmod-peer-mount-requirements
Thread-Index: Ac/ZjioymKhX4n/+Q0irapwH2HUqIwAAEm2AAEtmX7A=
Date: Sun, 28 Sep 2014 01:38:04 +0000
Message-ID: 
References:  
In-Reply-To: 
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.66.87.91]
Content-Type: multipart/alternative; boundary="_000_C0E0A32284495243BDE0AC8A066631A8185A49A7szxeml557mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/supa/s2JMEmh_X2kT3qNlLeVj5Xzt2fg
Cc: "Alexander Clemm \(alex\)" 
Subject: Re: [Supa] [netmod] "00" Notification for draft-voit-netmod-peer-mount-requirements
X-BeenThere: supa@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 28 Sep 2014 01:38:24 -0000

--_000_C0E0A32284495243BDE0AC8A066631A8185A49A7szxeml557mbschi_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

RGVhciBFcmljIGV0IGFsLA0KDQoNCg0KRGlzdHJpYnV0ZWQgRGF0YSBDZW50ZXIgc2VydmljZXMg
YXJlIHR5cGljYWwgY2FzZSBmb3IgU1VQQS4NCg0KWW91ciBzdWJtaXNzaW9uIG9mIGRyYWZ0cyBh
cmUgdmVyeSB3ZWxjb21lLg0KDQoNCg0KWW91IG1heSBiZSBpbnRlcmVzdGVkIHRvIGxvb2sgYXQg
dGhlc2UuDQpkcmFmdC1jaGVuZy1zdXBhLWRkYy11c2UtY2FzZXMtMDA8aHR0cDovL2RhdGF0cmFj
a2VyLmlldGYub3JnL2RvYy9kcmFmdC1jaGVuZy1zdXBhLWRkYy11c2UtY2FzZXMvPg0KDQpVc2Ug
Q2FzZXMgZm9yIERpc3RyaWJ1dGVkIERhdGEgQ2VudGVyIEFwcGxpY2F0aW9ucyBpbiBTVVBBDQoN
CjIwMTQtMDktMTcNCm5ldzxodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1j
aGVuZy1zdXBhLWRkYy11c2UtY2FzZXMtMDA+DQoNCkktRCBFeGlzdHMNCg0KZHJhZnQtY29udHJl
cmFzLXN1cGEteWFuZy1uZXR3b3JrLXRvcG8tMDA8aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3Jn
L2RvYy9kcmFmdC1jb250cmVyYXMtc3VwYS15YW5nLW5ldHdvcmstdG9wby8+DQoNCkEgWUFORyBE
YXRhIE1vZGVsIGZvciBOZXR3b3JrIFRvcG9sb2dpZXMNCg0KMjAxNC0wOS0xOA0KbmV3PGh0dHA6
Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWNvbnRyZXJhcy1zdXBhLXlhbmctbmV0
d29yay10b3BvLTAwPg0KDQpJLUQgRXhpc3RzDQoNCmRyYWZ0LXphYWxvdWstc3VwYS1jb25maWd1
cmF0aW9uLW1vZGVsLTAwPGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtemFh
bG91ay1zdXBhLWNvbmZpZ3VyYXRpb24tbW9kZWwvPg0KDQpZQU5HIERhdGEgTW9kZWwgZm9yIENv
bmZpZ3VyYXRpb24gb2YgU2hhcmVkIFVuaWZpZWQgUG9saWN5IEF1dG9tYXRpb24gKFNVUEEpDQoN
CjIwMTQtMDktMjINCm5ldzxodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC16
YWFsb3VrLXN1cGEtY29uZmlndXJhdGlvbi1tb2RlbC0wMD4NCg0KSS1EIEV4aXN0cw0KDQpkcmFm
dC1wZW50aWtvdXNpcy1zdXBhLW1hcHBpbmctMDA8aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3Jn
L2RvYy9kcmFmdC1wZW50aWtvdXNpcy1zdXBhLW1hcHBpbmcvPg0KDQpTVVBBIENvbmZpZ3VyYXRp
b24gYW5kIFBvbGljeSBNYXBwaW5nDQoNCjIwMTQtMDktMjMNCm5ldzxodHRwOi8vd3d3LmlldGYu
b3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1wZW50aWtvdXNpcy1zdXBhLW1hcHBpbmctMDA+DQoNCkkt
RCBFeGlzdHMNCg0KDQoNCg0KDQoNCg0KVGhhbmsgeW91LA0KDQpUaW5hDQoNCg0KDQotLS0tLU9y
aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogU3VwYSBbbWFpbHRvOnN1cGEtYm91bmNlc0BpZXRm
Lm9yZ10gT24gQmVoYWxmIE9mIEdlb3JnaW9zIEthcmFnaWFubmlzDQpTZW50OiBGcmlkYXksIFNl
cHRlbWJlciAyNiwgMjAxNCA5OjM1IFBNDQpUbzogRXJpYyBWb2l0IChldm9pdCk7IHN1cGFAaWV0
Zi5vcmcNCkNjOiBBbGV4YW5kZXIgQ2xlbW0gKGFsZXgpDQpTdWJqZWN0OiBSZTogW1N1cGFdIFtu
ZXRtb2RdICIwMCIgTm90aWZpY2F0aW9uIGZvciBkcmFmdC12b2l0LW5ldG1vZC1wZWVyLW1vdW50
LXJlcXVpcmVtZW50cw0KDQoNCg0KSGkgRXJpYywNCg0KDQoNClRoYW5rcyBmb3IgdGhlIGluZm9y
bWF0aW9uLg0KDQpJIGhhdmUgbm90IHJlYWQgeW91ciBkcmFmdCBpbiBkZXRhaWwsIGJ1dCBmcm9t
IHlvdXIgZXhwbGFuYXRpb24sIGl0IG1pZ2h0IGJlIHJlbGV2YW50IHRvIFNVUEEuDQoNCg0KDQpC
ZXN0IHJlZ2FyZHMsDQoNCkdlb3JnaW9zDQoNCg0KDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3Nh
Z2UtLS0tLQ0KDQo+IEZyb206IFN1cGEgW21haWx0bzpzdXBhLWJvdW5jZXNAaWV0Zi5vcmddIE9u
IEJlaGFsZiBPZiBFcmljIFZvaXQNCg0KPiAoZXZvaXQpDQoNCj4gU2VudDogRnJpZGF5LCBTZXB0
ZW1iZXIgMjYsIDIwMTQgMjozMiBQTQ0KDQo+IFRvOiBzdXBhQGlldGYub3JnPG1haWx0bzpzdXBh
QGlldGYub3JnPg0KDQo+IENjOiBBbGV4YW5kZXIgQ2xlbW0gKGFsZXgpDQoNCj4gU3ViamVjdDog
W1N1cGFdIEZXOiBbbmV0bW9kXSAiMDAiIE5vdGlmaWNhdGlvbiBmb3INCg0KPiBkcmFmdC12b2l0
LW5ldG1vZC1wZWVyLSBtb3VudC1yZXF1aXJlbWVudHMNCg0KPg0KDQo+IEkganVzdCBsZWFybmVk
IGFib3V0IFNVUEEsIGFuZCBiYXNlZCBvbiB0aGUgZXZvbHZpbmcgY2hhcnRlciBpdCBzZWVtcw0K
DQo+IHF1aXRlIHJlbGV2YW50IHRvIGFuIGluZm9ybWF0aW9uYWwgZHJhZnQgc2V2ZXJhbCBvZiB1
cyBzdWJtaXR0ZWQgdG8gTmV0bW9kIHllc3RlcmRheS4NCg0KPiBodHRwOi8vd3d3LmlldGYub3Jn
L2ludGVybmV0LWRyYWZ0cy9kcmFmdC12b2l0LW5ldG1vZC1wZWVyLW1vdW50LXJlcXVpDQoNCj4g
cmVtZW50cy0NCg0KPiAwMC50eHQNCg0KPg0KDQo+IE91ciBkcmFmdCBhZ2dyZWdhdGVzIHJlcXVp
cmVtZW50cyB3ZSBoYXZlIHVuY292ZXJlZCBhcyB3ZSBoYXZlIGJ1aWx0DQoNCj4gc2V2ZXJhbCBu
ZXcgRGF0YSBDZW50ZXIgZWRnZSBzZXJ2aWNlcyB1cG9uIGFuIE9wZW4gRGF5bGlnaHQNCg0KPiBj
b250cm9sbGVyLiAgV2UgYWxyZWFkeSBoYXZlIGEgd29ya2luZyBZQU5HIHNlcnZpY2UgbW9kZWwg
Zm9yIHR3byBvZiB0aGUgdHdvIHNlcnZpY2VzIGluIHRoZSBkcmFmdC4NCg0KPiBJZiB0aGVyZSBp
cyBpbnRlcmVzdCBoZXJlLCBJIGNvdWxkIHB1Ymxpc2ggdGhhdCBtb2RlbCBhcyB3ZWxsLg0KDQo+
DQoNCj4gVGhhbmtzLA0KDQo+IEVyaWMNCg0KPg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t
LS0tDQoNCj4gRnJvbTogbmV0bW9kIFttYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmddIE9u
IEJlaGFsZiBPZiBFcmljIFZvaXQsDQoNCj4gU2VwdGVtYmVyIDI1LCAyMDE0IDY6MzggUE0NCg0K
Pg0KDQo+IFdlIGhhdmUgYmVlbiBkZXZlbG9waW5nIFNETiBhcHBsaWNhdGlvbnMgd2hpY2ggcmVx
dWlyZSBxdWljaywNCg0KPiBpdGVyYXRpdmUgYWNjZXNzIHRvIG9iamVjdHMgcmVwcmVzZW50aW5n
IG5ldHdvcmsgYW5kIGRldmljZQ0KDQo+IGFic3RyYWN0aW9ucy4gIFRoZXNlIG9iamVjdHMgaW5j
bHVkZSBvbmVzIGF1dGhvcml0YXRpdmVseSBvd25lZCBieSBhDQoNCj4gbG9jYWwgc3lzdGVtLCBh
cyB3ZWxsIGFzIG9uZXMgcHJvdmlkZWQgZnJvbSByZW1vdGUgZGF0YXN0b3Jlcy4gIFR3bw0KDQo+
IHN1Y2ggYXBwbGljYXRpb25zIHdlIGhhdmUgcHJvdG90eXBlZCBhcmUg4oCcQ2xvdWQgUG9saWNl
cuKAnSBhbmQg4oCcRERvUw0KDQo+IFRocmVzaG9sZGluZ+KAnS4gIChTZWUgbGlua3MgYmVsb3cg
Zm9yIG1vcmUgb24gdGhlc2UgYXBwcy4pDQoNCj4NCg0KPiBUaGUgZ29vZCBuZXdzIGlzIHRoYXQg
d2UgZm91bmQgWUFORyBtb2RlbHMgYW5kIHN5bnRheCB0byBiZSBhIG5pY2UgZml0DQoNCj4gZm9y
IHRoZXNlIGFwcGxpY2F0aW9ucy4gICBIb3dldmVyIHdlIGhhdmUgYmVlbiB0cnlpbmcgdG8gY292
ZXIgc2V2ZXJhbA0KDQo+IG1pc3NpbmcNCg0KPiBlbGVtZW50czoNCg0KPg0KDQo+IE1pc3Npbmcg
RWxlbWVudCAjMTogRGV2ZWxvcGVyIFNpbXBsaWNpdHkgV2Ugd2FudGVkIGFwcGxpY2F0aW9ucyB0
bw0KDQo+IGFjY2VzcyByZW1vdGUgb2JqZWN0cyBmcm9tIGEgc2luZ2xlIGRhdGFzdG9yZSwgd2l0
aG91dCBoYXZpbmcgdG8gaGF2ZQ0KDQo+IHRoZSBhcHBsaWNhdGlvbnMgcGVlciBkaXJlY3RseSB3
aXRoIHJlbW90ZSBkZXZpY2VzLiAgV2UgYWxzbyB3YW50ZWQNCg0KPiBjbGllbnRzIGFuZCBhcHBs
aWNhdGlvbnMgdG8gYWNjZXNzIGRhdGFzdG9yZXMgaW4gdGhlIHNhbWUgd2F5DQoNCj4gaW5kZXBl
bmRlbnQgb2Ygd2hldGhlciB0aGUgYXBwbGljYXRpb25zIHdlcmUgaG9zdGVkIG9uIGEgTmV0d29y
ayBFbGVtZW50IG9yIENvbnRyb2xsZXIuDQoNCj4NCg0KPiBNaXNzaW5nIEVsZW1lbnQgIzI6IFdo
byBvd25zIGFuIE9iamVjdD8NCg0KPiBBcHBsaWNhdGlvbnMgY2FuJ3QgdGVsbCB3aGljaCBOZXR3
b3JrIEVsZW1lbnQgYWNyb3NzIGEgc2V0IG9mIGRldmljZXMNCg0KPiBpcyB0aGUgYXV0aG9yaXRh
dGl2ZSBvd25lciBvZiBhIHBhcnRpY3VsYXIgcmVwbGljYXRlZCBvYmplY3QuICBTaW5jZQ0KDQo+
IHJlcGxpY2F0ZWQgZGF0YSBnZXRzIG91dCBvZiBzeW5jaCwgcmVzb2x1dGlvbiAvIGNvbnZlcmdl
bmNlIGlzIGEgcHJvYmxlbS4NCg0KPg0KDQo+IE1pc3NpbmcgRWxlbWVudCAjMzogTWFpbnRhaW5p
bmcgY2FjaGVzIG9mIHJlbW90ZSBpbmZvcm1hdGlvbg0KDQo+IEFwcGxpY2F0aW9ucyBuZWVkIHRp
bWVseSBhY2Nlc3MgdG8gcmVtb3RlIGluZm9ybWF0aW9uLCB3aGljaCBjYW4NCg0KPiBuZWNlc3Np
dGF0ZSB0aGUgaW50cm9kdWN0aW9uIGNhY2hlIGluZnJhc3RydWN0dXJlLiAgTmV0Y29uZiBwcm92
aWRlcw0KDQo+IGxpdHRsZSBzdXBwb3J0IHRvIGZhY2lsaXRhdGUgdGhpcy4gIEZvciBleGFtcGxl
LCBub3RpZmljYXRpb25zIGFyZSBub3QNCg0KPiBhIGdvb2QgbWF0Y2ggdG8gc3Vic2NyaWJlIHRv
IHB1c2gtIHVwZGF0ZXMuDQoNCj4NCg0KPiBUbyBzb2x2ZSB0aGVzZSBwcm9ibGVtcywgd2UgbmVl
ZCB0ZWNobm9sb2d5IHNvbHV0aW9ucyB3aGljaCB3b3JrDQoNCj4gZXF1YWxseSB3ZWxsIGZvciBi
b3RoIENvbnRyb2xsZXJzIGFuZCBOZXR3b3JrIEVsZW1lbnRzLiAgVGhlc2UNCg0KPiBzb2x1dGlv
bnMgbXVzdCBleHBvc2UgbG9jYWwgZGF0YXN0b3JlcyB3aGljaCBwcm92aWRlIGF1dGhvcml0YXRp
dmUsDQoNCj4gY29uc29saWRhdGVkIHZpZXdzIG9mIGRpc3RyaWJ1dGVkIG5ldHdvcmsgb2JqZWN0
cy4gIFRoaXMgbXVzdCBiZSBkb25lDQoNCj4gaW4gYSB3YXkgd2hpY2ggYWxsb3dzIHRoZSBhcHBs
aWNhdGlvbnMgdG8gc2l0IGFueXdoZXJlIGluIHRoZSBuZXR3b3JrLA0KDQo+IG9uIHZhcmlvdXMg
YWJzdHJhY3Rpb25zLCB3aGlsZSBtYWludGFpbmluZyBkb21haW4gY29uc2lzdGVuY3kuIEFuZA0K
DQo+IHRoaXMgbXVzdCBiZSBkb25lIHdoaWxlIG1heGltaXppbmcgYXBwbGljYXRpb24gZGV2ZWxv
cGVyIHNpbXBsaWNpdHkuDQoNCj4NCg0KPiBUaGlzIGRyYWZ0IGlzIGludGVuZGVkIHRvIHN0YXJ0
IGFnZ3JlZ2F0aW5nIHJlcXVpcmVtZW50cyBpbiB0aGlzDQoNCj4gc3BhY2UuICBUaGUgZHJhZnQg
aXMgbm90IGNvbXBsZXRlLCBzbyBpdCB3b3VsZCBiZSBncmVhdCB0byBoZWFyIGZyb20NCg0KPiBv
dGhlcnMgd2hvIGFyZSBpbnRlcmVzdGVkIGluIGhlbHBpbmcgc28gdGhhdCB3ZSBlbmQgdXAgd2l0
aCBhIG1vcmUgY29tcHJlaGVuc2l2ZSBjb250ZXh0Lg0KDQo+DQoNCj4gU29sdXRpb25zIGRvIGV4
aXN0IHdoaWNoIGNhbiBzb2x2ZSBhIHN1YnNldCBvZiB0aGVzZSByZXF1aXJlbWVudHMuDQoNCj4g
T25lIHBhcnRpY3VsYXIgdGVjaG5vbG9neSB3ZSBoYXZlIGJ1aWx0IGlzIGtub3duIGFzIOKAnHBl
ZXIgbW91bnTigJ0uDQoNCj4gUGVlciBtb3VudCBnaXZlcyB0aGUgYWJpbGl0eSB0byByZWZlcmVu
Y2UgWUFORyBpbmZvcm1hdGlvbiBpbnRvIGENCg0KPiBsb2NhbCBkYXRhc3RvcmUgZnJvbSByZW1v
dGUgZGF0YXN0b3Jlcy4gIFRoaXMgcHJvdmlkZXMgY2xpZW50DQoNCj4gYXBwbGljYXRpb25zIHdp
dGggbG9jYWwgYWNjZXNzIHRvIGluZm9ybWF0aW9uIHdoaWNoIG1pZ2h0IGJlDQoNCj4gdHJhbnNw
YXJlbnRseSBmZWRlcmF0ZWQgYWNyb3NzIG11bHRpcGxlIHN5c3RlbXMgYW5kIGRhdGFzdG9yZXMu
ICBJdA0KDQo+IGFsc28gcmV0YWlucyBjbGVhciBvYmplY3Qgb3duZXJzaGlwIHRvIG1pbmltaXpl
IHN5bmNocm9uaXphdGlvbiBhbmQNCg0KPiBpbnRlci1zeXN0ZW0gZGVwZW5kZW5jeSBpc3N1ZXMu
ICAgVGhlcmUgYXJlIGFscmVhZHkgaW1wbGVtZW50YXRpb25zIG9mDQoNCj4gdGhpcyB0ZWNobm9s
b2d5LCBmb3IgZXhhbXBsZSwgaW4gT3BlbiBEYXlsaWdodC4gIEhvd2V2ZXIsIHdlIGJlbGlldmUN
Cg0KPiByZXF1aXJlbWVudHMgYW5kIHVzZSBjYXNlcyBmb3IgdGhpcyB0ZWNobm9sb2d5IGFwcGx5
IGVxdWFsbHkgd2VsbCB0byBuZXR3b3JrIGRldmljZXMuDQoNCj4NCg0KPiBQbGVhc2UgbGV0IHVz
IGtub3cgaWYgZWl0aGVyIHRoZSByZXF1aXJlbWVudHMgb3IgdGVjaG5vbG9neQ0KDQo+IHNwZWNp
ZmljYXRpb25zIGFyZSBwcm9ibGVtIHlvdSBhcmUgaW50ZXJlc3RlZCBpbiBleHBsb3JpbmcuDQoN
Cj4NCg0KPiBUaGFua3MhDQoNCj4gRXJpYywgQWxleCwgUHJhYmhha2FyYSwgQW1iaWthLCBTaGFz
aGkNCg0KPg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoNCj4gRnJvbTogaW50ZXJu
ZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+IFttYWls
dG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXQ0KDQo+IFNlbnQ6IFRodXJzZGF5LCBTZXB0ZW1i
ZXIgMjUsIDIwMTQgODo0MSBBTQ0KDQo+IFRvOiBQcmFiaGFrYXJhIFllbGxhaSAocHllbGxhaSk7
IFNoYXNoaSBLdW1hciBCYW5zYWwgKHNoYWJhbnNhKTsNCg0KPiBBbWJpa2EgUHJhc2FkIFRyaXBh
dGh5IChhbWJ0cmlwYSk7IEFsZXhhbmRlciBDbGVtbSAoYWxleCk7IEVyaWMgVm9pdA0KDQo+IChl
dm9pdCk7IEFtYmlrYSBQcmFzYWQgVHJpcGF0aHkgKGFtYnRyaXBhKTsgQWxleGFuZGVyIENsZW1t
IChhbGV4KTsNCg0KPiBQcmFiaGFrYXJhIFllbGxhaSAocHllbGxhaSk7IEVyaWMgVm9pdCAoZXZv
aXQpOyBTaGFzaGkgS3VtYXIgQmFuc2FsDQoNCj4gKHNoYWJhbnNhKQ0KDQo+IFN1YmplY3Q6IE5l
dyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtdm9pdC1uZXRtb2QtcGVlci1tb3VudC0N
Cg0KPiByZXF1aXJlbWVudHMtMDAudHh0DQoNCj4NCg0KPg0KDQo+IEEgbmV3IHZlcnNpb24gb2Yg
SS1ELCBkcmFmdC12b2l0LW5ldG1vZC1wZWVyLW1vdW50LXJlcXVpcmVtZW50cy0wMC50eHQNCg0K
PiBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEVyaWMgVm9pdCBhbmQgcG9zdGVk
IHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCj4NCg0KPiBOYW1lOiAgICAgICAgICAgICAgICAg
IGRyYWZ0LXZvaXQtbmV0bW9kLXBlZXItbW91bnQtcmVxdWlyZW1lbnRzDQoNCj4gUmV2aXNpb246
ICAgICAgICAgICAgICAwMA0KDQo+IFRpdGxlOiAgICAgICAgICAgICAgICAgICAgIFJlcXVpcmVt
ZW50cyBmb3IgUGVlciBNb3VudGluZyBvZiBZQU5HDQoNCj4gc3VidHJlZXMgZnJvbSBSZW1vdGUg
RGF0YXN0b3JlcyBEb2N1bWVudCBkYXRlOiAyMDE0LTA5LTI1DQoNCj4gR3JvdXA6ICAgICAgICAg
ICAgICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQoNCj4gUGFnZXM6ICAgICAgICAgICAgICAg
ICAgMjINCg0KPiBVUkw6DQoNCj4gaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMv
ZHJhZnQtdm9pdC1uZXRtb2QtcGVlci0NCg0KPiBtb3VudC1yZXF1aXJlbWVudHMtMDAudHh0DQoN
Cj4gU3RhdHVzOg0KDQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXZv
aXQtbmV0bW9kLXBlZXItbW91bnQtDQoNCj4gcmVxdWlyZW1lbnRzLw0KDQo+IEh0bWxpemVkOg0K
DQo+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXZvaXQtbmV0bW9kLXBlZXItbW91
bnQtDQoNCj4gcmVxdWlyZW1lbnRzLTAwDQoNCj4NCg0KPg0KDQo+IEFic3RyYWN0Og0KDQo+ICAg
IE5ldHdvcmsgaW50ZWdyYXRlZCBhcHBsaWNhdGlvbnMgd2FudCBzaW1wbGUgd2F5cyB0byBhY2Nl
c3MgWUFORw0KDQo+ICAgIG9iamVjdHMgYW5kIHN1YnRyZWVzIHdoaWNoIG1pZ2h0IGJlIGRpc3Ry
aWJ1dGVkIGFjcm9zcyBuZXR3b3JrLg0KDQo+ICAgIFBlcmZvcm1hbmNlIHJlcXVpcmVtZW50cyBt
YXkgZGljdGF0ZSB0aGF0IGl0IGlzIHVuYWZmb3JkYWJsZSBmb3IgYQ0KDQo+ICAgIHN1YnNldCBv
ZiB0aGVzZSBhcHBsaWNhdGlvbnMgdG8gZ28gdGhyb3VnaCBleGlzdGluZyBjZW50cmFsaXplZA0K
DQo+ICAgIG1hbmFnZW1lbnQgYnJva2Vycy4gIEZvciBzdWNoIGFwcGxpY2F0aW9ucywgZGV2ZWxv
cG1lbnQgY29tcGxleGl0eQ0KDQo+ICAgIG11c3QgYmUgbWluaW1pemVkLiAgU3BlY2lmaWMgYXNw
ZWN0cyBvZiBjb21wbGV4aXR5IGRldmVsb3BlcnMgd2FudA0KDQo+IHRvDQoNCj4gICAgaWdub3Jl
IGluY2x1ZGU6DQoNCj4NCg0KPiAgICBvICB3aGV0aGVyIGF1dGhvcml0YXRpdmUgaW5mb3JtYXRp
b24gaXMgYWN0dWFsbHkgc291cmNlZCBmcm9tDQoNCj4gcmVtb3RlDQoNCj4gICAgICAgZGF0YXN0
b3JlcyAoYXMgd2VsbCBhcyBob3cgdG8gZ2V0IHRvIHRob3NlIGRhdGFzdG9yZXMpLA0KDQo+DQoN
Cj4gICAgbyAgd2hldGhlciBzdWNoIGluZm9ybWF0aW9uIGhhcyBiZWVuIGxvY2FsbHkgY2FjaGVk
IG9yIG5vdCwNCg0KPg0KDQo+ICAgIG8gIHdoZXRoZXIgdGhlcmUgYXJlIHplcm8sIG9uZSwgb3Ig
bW9yZSBjb250cm9sbGVycyBhc3NlcnRpbmcNCg0KPiAgICAgICBvd25lcnNoaXAgb2YgaW5mb3Jt
YXRpb24sIGFuZA0KDQo+DQoNCj4gICAgbyAgd2hldGhlciB0aGVyZSBhcmUgaW50ZXJhY3Rpb25z
IHdpdGggb3RoZXIgYXBwbGljYXRpb25zDQoNCj4gICAgICAgY29uY3VycmVudGx5IHJ1bm5pbmcg
ZWxzZXdoZXJlDQoNCj4NCg0KPiAgICBUaGUgc29sdXRpb24gcmVxdWlyZW1lbnRzIGRlc2NyaWJl
ZCBpbiB0aGlzIGRvY3VtZW50IGRldGFpbCB3aGF0IGlzDQoNCj4gICAgbmVlZGVkIHRvIHN1cHBv
cnQgYXBwbGljYXRpb24gYWNjZXNzIHRvIGF1dGhvcml0YXRpdmUgbmV0d29yayBZQU5HDQoNCj4g
ICAgb2JqZWN0cyBmcm9tIGNvbnRyb2xsZXJzIChzdGFyKSBvciBwZWVyaW5nIG5ldHdvcmsgZGV2
aWNlcyAobWVzaCkNCg0KPiBpbg0KDQo+ICAgIHN1Y2ggYSB3YXkgdG8gbWVldCB0aGVzZSBnb2Fs
cy4NCg0KPg0KDQo+DQoNCj4NCg0KPg0KDQo+DQoNCj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkg
dGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YNCg0KPiBzdWJtaXNzaW9u
IHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9v
bHMuaWV0Zi5vcmcuDQoNCj4NCg0KPiBUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo+DQoNCj4gX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KPiBuZXRtb2Qg
bWFpbGluZyBsaXN0DQoNCj4gbmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+
DQoNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg0KPiBf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQo+IFN1cGEg
bWFpbGluZyBsaXN0DQoNCj4gU3VwYUBpZXRmLm9yZzxtYWlsdG86U3VwYUBpZXRmLm9yZz4NCg0K
PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N1cGENCg0KX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KU3VwYSBtYWlsaW5nIGxp
c3QNCg0KU3VwYUBpZXRmLm9yZzxtYWlsdG86U3VwYUBpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdXBhDQo=

--_000_C0E0A32284495243BDE0AC8A066631A8185A49A7szxeml557mbschi_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm
b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0
O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkFyaWFsIFVuaWNvZGUgTVMiOw0KCXBhbm9z
ZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2Fs
aWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2Zv
bnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpA
Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQEFyaWFsIFVuaWNvZGUgTVMiOw0KCXBhbm9zZS0x
OjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05v
cm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2lu
LWJvdHRvbTouMDAwMXB0Ow0KCXRleHQtYWxpZ246anVzdGlmeTsNCgl0ZXh0LWp1c3RpZnk6aW50
ZXItaWRlb2dyYXBoOw0KCWZvbnQtc2l6ZToxMC41cHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki
LCJzYW5zLXNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w
cmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K
YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0
eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1z
b1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHls
ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJn
aW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuNXB0Ow0KCWZv
bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29B
Y2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0
eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0
b206LjAwMDFwdDsNCgl0ZXh0LWFsaWduOmp1c3RpZnk7DQoJdGV4dC1qdXN0aWZ5OmludGVyLWlk
ZW9ncmFwaDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z
LXNlcmlmIjt9DQpzcGFuLlBsYWluVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IlBsYWluIFRl
eHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFp
biBUZXh0IjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCnNwYW4uQmFs
bG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNv
LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiO30NCi5N
c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCi8qIFBhZ2UgRGVm
aW5pdGlvbnMgKi8NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsN
CgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjEN
Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht
bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht
bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6
ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl
bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iWkgtQ04iIGxp
bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiIHN0eWxlPSJ0ZXh0LWp1c3RpZnktdHJpbTpwdW5jdHVh
dGlvbiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4
dCI+PHNwYW4gbGFuZz0iRU4tVVMiPkRlYXIgRXJpYyBldCBhbCw8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0i
RU4tVVMiPkRpc3RyaWJ1dGVkIERhdGEgQ2VudGVyIHNlcnZpY2VzIGFyZSB0eXBpY2FsIGNhc2Ug
Zm9yIFNVUEEuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+
PHNwYW4gbGFuZz0iRU4tVVMiPllvdXIgc3VibWlzc2lvbiBvZiBkcmFmdHMgYXJlIHZlcnkgd2Vs
Y29tZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh
biBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPllvdSBtYXkgYmUgaW50ZXJlc3RlZCB0byBs
b29rIGF0IHRoZXNlLiAmbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8dGFibGUg
Y2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjEiIGNlbGxzcGFjaW5nPSIwIiBjZWxscGFk
ZGluZz0iMCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi0xLjE1cHQ7Ym9yZGVyLWNvbGxhcHNlOmNvbGxh
cHNlO2JvcmRlcjpub25lIj4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBzdHlsZT0iYm9yZGVyLXRvcDpz
b2xpZCAjN0Y3RjdGIDEuMHB0O2JvcmRlci1sZWZ0OnNvbGlkICM3RjdGN0YgMS4wcHQ7Ym9yZGVy
LWJvdHRvbTpub25lO2JvcmRlci1yaWdodDpub25lO3BhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQg
Ljc1cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDsiPjxhIGhyZWY9Imh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh
ZnQtY2hlbmctc3VwYS1kZGMtdXNlLWNhc2VzLyI+ZHJhZnQtY2hlbmctc3VwYS1kZGMtdXNlLWNh
c2VzLTAwPC9hPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjx0ZCBzdHlsZT0iYm9y
ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjN0Y3RjdGIDEuMHB0O3BhZGRpbmc6Ljc1cHQgLjc1
cHQgLjc1cHQgLjc1cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDsiPlVzZSBDYXNlcyBmb3IgRGlzdHJpYnV0ZWQgRGF0YSBDZW50
ZXIgQXBwbGljYXRpb25zIGluIFNVUEE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPHRk
IGNvbHNwYW49IjIiIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICM3RjdGN0Yg
MS4wcHQ7cGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+MjAxNC0wOS0xNw0K
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i
RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcv
cmZjZGlmZj91cmwyPWRyYWZ0LWNoZW5nLXN1cGEtZGRjLXVzZS1jYXNlcy0wMCI+bmV3PC9hPjxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8dGQgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl
ci10b3A6c29saWQgIzdGN0Y3RiAxLjBwdDtwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0
Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7Ij5JLUQgRXhpc3RzDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPHRkIHN0
eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICM3RjdGN0YgMS4wcHQ7cGFkZGluZzou
NzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+DQo8L3RkPg0KPHRkIHN0eWxlPSJib3JkZXI6bm9uZTti
b3JkZXItdG9wOnNvbGlkICM3RjdGN0YgMS4wcHQ7cGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAu
NzVwdCI+DQo8L3RkPg0KPHRkIHN0eWxlPSJib3JkZXItdG9wOnNvbGlkICM3RjdGN0YgMS4wcHQ7
Ym9yZGVyLWxlZnQ6bm9uZTtib3JkZXItYm90dG9tOm5vbmU7Ym9yZGVyLXJpZ2h0OnNvbGlkICM3
RjdGN0YgMS4wcHQ7cGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+DQo8L3RkPg0KPC90
cj4NCjx0cj4NCjx0ZCBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgIzdGN0Y3
RiAxLjBwdDtwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Ij4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YSBocmVmPSJo
dHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWNvbnRyZXJhcy1zdXBhLXlhbmct
bmV0d29yay10b3BvLyI+ZHJhZnQtY29udHJlcmFzLXN1cGEteWFuZy1uZXR3b3JrLXRvcG8tMDA8
L2E+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPHRkIHN0eWxlPSJib3JkZXI6bm9u
ZTtwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5BIFlBTkcgRGF0YSBNb2Rl
bCBmb3IgTmV0d29yayBUb3BvbG9naWVzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjx0
ZCBjb2xzcGFuPSIyIiBzdHlsZT0iYm9yZGVyOm5vbmU7cGFkZGluZzouNzVwdCAuNzVwdCAuNzVw
dCAuNzVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90OyI+MjAxNC0wOS0xOA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxh
IGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWNvbnRyZXJhcy1z
dXBhLXlhbmctbmV0d29yay10b3BvLTAwIj5uZXc8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0K
PC90ZD4NCjx0ZCBzdHlsZT0iYm9yZGVyOm5vbmU7cGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAu
NzVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90OyI+SS1EIEV4aXN0cw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjx0
ZCBzdHlsZT0iYm9yZGVyOm5vbmU7cGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+PC90
ZD4NCjx0ZCBzdHlsZT0iYm9yZGVyOm5vbmU7cGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVw
dCI+PC90ZD4NCjx0ZCBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXJpZ2h0OnNvbGlkICM3RjdG
N0YgMS4wcHQ7cGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+DQo8L3RkPg0KPC90cj4N
Cjx0cj4NCjx0ZCBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgIzdGN0Y3RiAx
LjBwdDtwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YSBocmVmPSJodHRw
Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXphYWxvdWstc3VwYS1jb25maWd1cmF0
aW9uLW1vZGVsLyI+ZHJhZnQtemFhbG91ay1zdXBhLWNvbmZpZ3VyYXRpb24tbW9kZWwtMDA8L2E+
DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPHRkIGNvbHNwYW49IjIiIHN0eWxlPSJi
b3JkZXI6bm9uZTtwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Ij4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5ZQU5HIERh
dGEgTW9kZWwgZm9yIENvbmZpZ3VyYXRpb24gb2YgU2hhcmVkIFVuaWZpZWQgUG9saWN5IEF1dG9t
YXRpb24gKFNVUEEpPG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjx0ZCBjb2xzcGFuPSIz
IiBzdHlsZT0iYm9yZGVyOm5vbmU7cGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
OyI+MjAxNC0wOS0yMg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxhIGhyZWY9Imh0dHA6
Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXphYWxvdWstc3VwYS1jb25maWd1cmF0
aW9uLW1vZGVsLTAwIj5uZXc8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjx0ZCBj
b2xzcGFuPSIyIiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXJpZ2h0OnNvbGlkICM3RjdGN0Yg
MS4wcHQ7cGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SS1EIEV4aXN0cw0K
PG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgc3R5bGU9ImJv
cmRlci10b3A6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjN0Y3RjdGIDEuMHB0O2JvcmRlci1ib3R0
b206c29saWQgIzdGN0Y3RiAxLjBwdDtib3JkZXItcmlnaHQ6bm9uZTtwYWRkaW5nOi43NXB0IC43
NXB0IC43NXB0IC43NXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT
IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YSBocmVmPSJodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5v
cmcvZG9jL2RyYWZ0LXBlbnRpa291c2lzLXN1cGEtbWFwcGluZy8iPmRyYWZ0LXBlbnRpa291c2lz
LXN1cGEtbWFwcGluZy0wMDwvYT4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8dGQg
Y29sc3Bhbj0iMiIgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1ib3R0b206c29saWQgIzdGN0Y3
RiAxLjBwdDtwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Ij4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5TVVBBIENvbmZp
Z3VyYXRpb24gYW5kIFBvbGljeSBNYXBwaW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4N
Cjx0ZCBjb2xzcGFuPSIzIiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWJvdHRvbTpzb2xpZCAj
N0Y3RjdGIDEuMHB0O3BhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQiPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjIwMTQt
MDktMjMNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtB
cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YSBocmVmPSJodHRwOi8vd3d3Lmll
dGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1wZW50aWtvdXNpcy1zdXBhLW1hcHBpbmctMDAiPm5l
dzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPHRkIGNvbHNwYW49IjIiIHN0eWxl
PSJib3JkZXItdG9wOm5vbmU7Ym9yZGVyLWxlZnQ6bm9uZTtib3JkZXItYm90dG9tOnNvbGlkICM3
RjdGN0YgMS4wcHQ7Ym9yZGVyLXJpZ2h0OnNvbGlkICM3RjdGN0YgMS4wcHQ7cGFkZGluZzouNzVw
dCAuNzVwdCAuNzVwdCAuNzVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF
Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SS1EIEV4aXN0cw0KPG86cD48L286cD48L3NwYW4+
PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHIgaGVpZ2h0PSIwIj4NCjx0ZCB3aWR0aD0iMjU1IiBzdHls
ZT0iYm9yZGVyOm5vbmUiPjwvdGQ+DQo8dGQgd2lkdGg9IjMxNSIgc3R5bGU9ImJvcmRlcjpub25l
Ij48L3RkPg0KPHRkIHdpZHRoPSIzOCIgc3R5bGU9ImJvcmRlcjpub25lIj48L3RkPg0KPHRkIHdp
ZHRoPSIzMyIgc3R5bGU9ImJvcmRlcjpub25lIj48L3RkPg0KPHRkIHdpZHRoPSI1MyIgc3R5bGU9
ImJvcmRlcjpub25lIj48L3RkPg0KPHRkIHdpZHRoPSIyIiBzdHlsZT0iYm9yZGVyOm5vbmUiPjwv
dGQ+DQo8dGQgd2lkdGg9IjI2IiBzdHlsZT0iYm9yZGVyOm5vbmUiPjwvdGQ+DQo8dGQgd2lkdGg9
IjI2IiBzdHlsZT0iYm9yZGVyOm5vbmUiPjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+
DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4t
VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi
PjxzcGFuIGxhbmc9IkVOLVVTIj5UaGFuayB5b3UsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRpbmE8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g
bGFuZz0iRU4tVVMiPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTogU3VwYSBb
bWFpbHRvOnN1cGEtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEdlb3JnaW9zIEthcmFn
aWFubmlzPGJyPg0KU2VudDogRnJpZGF5LCBTZXB0ZW1iZXIgMjYsIDIwMTQgOTozNSBQTTxicj4N
ClRvOiBFcmljIFZvaXQgKGV2b2l0KTsgc3VwYUBpZXRmLm9yZzxicj4NCkNjOiBBbGV4YW5kZXIg
Q2xlbW0gKGFsZXgpPGJyPg0KU3ViamVjdDogUmU6IFtTdXBhXSBbbmV0bW9kXSAmcXVvdDswMCZx
dW90OyBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXZvaXQtbmV0bW9kLXBlZXItbW91bnQtcmVxdWly
ZW1lbnRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw
YW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5IaSBFcmljLDxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5n
PSJFTi1VUyI+VGhhbmtzIGZvciB0aGUgaW5mb3JtYXRpb24uPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPkkgaGF2ZSBub3Qg
cmVhZCB5b3VyIGRyYWZ0IGluIGRldGFpbCwgYnV0IGZyb20geW91ciBleHBsYW5hdGlvbiwgaXQg
bWlnaHQgYmUgcmVsZXZhbnQgdG8gU1VQQS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPkJlc3Qg
cmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48
c3BhbiBsYW5nPSJFTi1VUyI+R2Vvcmdpb3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxh
bmc9IkVOLVVTIj4mZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsg
RnJvbTogU3VwYSBbPGEgaHJlZj0ibWFpbHRvOnN1cGEtYm91bmNlc0BpZXRmLm9yZyI+PHNwYW4g
c3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPm1haWx0bzpzdXBh
LWJvdW5jZXNAaWV0Zi5vcmc8L3NwYW4+PC9hPl0gT24gQmVoYWxmIE9mIEVyaWMgVm9pdA0KPG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0i
RU4tVVMiPiZndDsgKGV2b2l0KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q
bGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IFNlbnQ6IEZyaWRheSwgU2VwdGVtYmVy
IDI2LCAyMDE0IDI6MzIgUE08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh
aW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBUbzogPGEgaHJlZj0ibWFpbHRvOnN1cGFA
aWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpu
b25lIj5zdXBhQGlldGYub3JnPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBDYzogQWxleGFuZGVy
IENsZW1tIChhbGV4KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl
eHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IFN1YmplY3Q6IFtTdXBhXSBGVzogW25ldG1vZF0g
JnF1b3Q7MDAmcXVvdDsgTm90aWZpY2F0aW9uIGZvcg0KPG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgZHJhZnQtdm9p
dC1uZXRtb2QtcGVlci0gbW91bnQtcmVxdWlyZW1lbnRzPG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgPG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMi
PiZndDsgSSBqdXN0IGxlYXJuZWQgYWJvdXQgU1VQQSwgYW5kIGJhc2VkIG9uIHRoZSBldm9sdmlu
ZyBjaGFydGVyIGl0IHNlZW1zDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
UGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBxdWl0ZSByZWxldmFudCB0byBhbiBp
bmZvcm1hdGlvbmFsIGRyYWZ0IHNldmVyYWwgb2YgdXMgc3VibWl0dGVkIHRvIE5ldG1vZCB5ZXN0
ZXJkYXkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw
YW4gbGFuZz0iRU4tVVMiPiZndDsgPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5l
dC1kcmFmdHMvZHJhZnQtdm9pdC1uZXRtb2QtcGVlci1tb3VudC1yZXF1aSI+DQo8c3BhbiBzdHls
ZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+aHR0cDovL3d3dy5pZXRm
Lm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtdm9pdC1uZXRtb2QtcGVlci1tb3VudC1yZXF1aTwv
c3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+
PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgcmVtZW50cy08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyAwMC50eHQ8bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJF
Ti1VUyI+Jmd0OyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0
Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBPdXIgZHJhZnQgYWdncmVnYXRlcyByZXF1aXJlbWVu
dHMgd2UgaGF2ZSB1bmNvdmVyZWQgYXMgd2UgaGF2ZSBidWlsdA0KPG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgc2V2
ZXJhbCBuZXcgRGF0YSBDZW50ZXIgZWRnZSBzZXJ2aWNlcyB1cG9uIGFuIE9wZW4gRGF5bGlnaHQN
CjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxh
bmc9IkVOLVVTIj4mZ3Q7IGNvbnRyb2xsZXIuJm5ic3A7IFdlIGFscmVhZHkgaGF2ZSBhIHdvcmtp
bmcgWUFORyBzZXJ2aWNlIG1vZGVsIGZvciB0d28gb2YgdGhlIHR3byBzZXJ2aWNlcyBpbiB0aGUg
ZHJhZnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw
YW4gbGFuZz0iRU4tVVMiPiZndDsgSWYgdGhlcmUgaXMgaW50ZXJlc3QgaGVyZSwgSSBjb3VsZCBw
dWJsaXNoIHRoYXQgbW9kZWwgYXMgd2VsbC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyA8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBU
aGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw
YW4gbGFuZz0iRU4tVVMiPiZndDsgRXJpYzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IDxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IC0t
LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgRnJvbTogbmV0bW9kIFs8YSBo
cmVmPSJtYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjp3
aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5tYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0
Zi5vcmc8L3NwYW4+PC9hPl0gT24gQmVoYWxmIE9mIEVyaWMgVm9pdCwNCjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7
IFNlcHRlbWJlciAyNSwgMjAxNCA2OjM4IFBNPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsg
V2UgaGF2ZSBiZWVuIGRldmVsb3BpbmcgU0ROIGFwcGxpY2F0aW9ucyB3aGljaCByZXF1aXJlIHF1
aWNrLA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw
YW4gbGFuZz0iRU4tVVMiPiZndDsgaXRlcmF0aXZlIGFjY2VzcyB0byBvYmplY3RzIHJlcHJlc2Vu
dGluZyBuZXR3b3JrIGFuZCBkZXZpY2UNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IGFic3RyYWN0aW9ucy48L3Nw
YW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l
dyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj4gVGhlc2Ugb2JqZWN0cyBp
bmNsdWRlIG9uZXMgYXV0aG9yaXRhdGl2ZWx5IG93bmVkIGJ5IGENCjxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IGxv
Y2FsIHN5c3RlbSwgYXMgd2VsbCBhcyBvbmVzIHByb3ZpZGVkIGZyb20gcmVtb3RlIGRhdGFzdG9y
ZXMuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291
cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+IFR3bw0KPG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0i
RU4tVVMiPiZndDsgc3VjaCBhcHBsaWNhdGlvbnMgd2UgaGF2ZSBwcm90b3R5cGVkIGFyZQ0KPC9z
cGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO
ZXcmcXVvdDsiPuKAnDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+Q2xvdWQgUG9saWNlcjwvc3Bh
bj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3
JnF1b3Q7Ij7igJ08L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPiBhbmQNCjwvc3Bhbj48c3BhbiBs
YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij7i
gJw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPkREb1MNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IFRocmVzaG9s
ZGluZzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nv
dXJpZXIgTmV3JnF1b3Q7Ij7igJ08L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPi4NCjwvc3Bhbj48
c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1
b3Q7Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPihTZWUgbGlua3MgYmVsb3cgZm9y
IG1vcmUgb24gdGhlc2UgYXBwcy4pPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgVGhlIGdv
b2QgbmV3cyBpcyB0aGF0IHdlIGZvdW5kIFlBTkcgbW9kZWxzIGFuZCBzeW50YXggdG8gYmUgYSBu
aWNlIGZpdA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+
PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgZm9yIHRoZXNlIGFwcGxpY2F0aW9ucy48L3NwYW4+PHNw
YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90
OyI+Jm5ic3A7Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj4gSG93ZXZlciB3ZSBoYXZl
IGJlZW4gdHJ5aW5nIHRvIGNvdmVyIHNldmVyYWwNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IG1pc3Npbmc8bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJF
Ti1VUyI+Jmd0OyBlbGVtZW50czo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
UGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBNaXNzaW5n
IEVsZW1lbnQgIzE6IERldmVsb3BlciBTaW1wbGljaXR5IFdlIHdhbnRlZCBhcHBsaWNhdGlvbnMg
dG8NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu
IGxhbmc9IkVOLVVTIj4mZ3Q7IGFjY2VzcyByZW1vdGUgb2JqZWN0cyBmcm9tIGEgc2luZ2xlIGRh
dGFzdG9yZSwgd2l0aG91dCBoYXZpbmcgdG8gaGF2ZQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgdGhlIGFwcGxp
Y2F0aW9ucyBwZWVyIGRpcmVjdGx5IHdpdGggcmVtb3RlIGRldmljZXMuPC9zcGFuPjxzcGFuIGxh
bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZu
YnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+IFdlIGFsc28gd2FudGVkDQo8bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+
Jmd0OyBjbGllbnRzIGFuZCBhcHBsaWNhdGlvbnMgdG8gYWNjZXNzIGRhdGFzdG9yZXMgaW4gdGhl
IHNhbWUgd2F5DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0
Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBpbmRlcGVuZGVudCBvZiB3aGV0aGVyIHRoZSBhcHBs
aWNhdGlvbnMgd2VyZSBob3N0ZWQgb24gYSBOZXR3b3JrIEVsZW1lbnQgb3IgQ29udHJvbGxlci48
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5n
PSJFTi1VUyI+Jmd0OyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U
ZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBNaXNzaW5nIEVsZW1lbnQgIzI6IFdobyBvd25z
IGFuIE9iamVjdD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0
Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBBcHBsaWNhdGlvbnMgY2FuJ3QgdGVsbCB3aGljaCBO
ZXR3b3JrIEVsZW1lbnQgYWNyb3NzIGEgc2V0IG9mIGRldmljZXMNCjxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IGlz
IHRoZSBhdXRob3JpdGF0aXZlIG93bmVyIG9mIGEgcGFydGljdWxhciByZXBsaWNhdGVkIG9iamVj
dC48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3Vy
aWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj4gU2luY2UNCjxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9
IkVOLVVTIj4mZ3Q7IHJlcGxpY2F0ZWQgZGF0YSBnZXRzIG91dCBvZiBzeW5jaCwgcmVzb2x1dGlv
biAvIGNvbnZlcmdlbmNlIGlzIGEgcHJvYmxlbS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyA8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0
OyBNaXNzaW5nIEVsZW1lbnQgIzM6IE1haW50YWluaW5nIGNhY2hlcyBvZiByZW1vdGUgaW5mb3Jt
YXRpb24NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz
cGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IEFwcGxpY2F0aW9ucyBuZWVkIHRpbWVseSBhY2Nlc3MgdG8g
cmVtb3RlIGluZm9ybWF0aW9uLCB3aGljaCBjYW4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IG5lY2Vzc2l0YXRl
IHRoZSBpbnRyb2R1Y3Rpb24gY2FjaGUgaW5mcmFzdHJ1Y3R1cmUuPC9zcGFuPjxzcGFuIGxhbmc9
IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNw
Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+IE5ldGNvbmYgcHJvdmlkZXMNCjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4m
Z3Q7IGxpdHRsZSBzdXBwb3J0IHRvIGZhY2lsaXRhdGUgdGhpcy48L3NwYW4+PHNwYW4gbGFuZz0i
RU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7
PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj4gRm9yIGV4YW1wbGUsIG5vdGlmaWNhdGlvbnMgYXJl
IG5vdA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw
YW4gbGFuZz0iRU4tVVMiPiZndDsgYSBnb29kIG1hdGNoIHRvIHN1YnNjcmliZSB0byBwdXNoLSB1
cGRhdGVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz
cGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IFRvIHNvbHZlIHRoZXNlIHByb2Js
ZW1zLCB3ZSBuZWVkIHRlY2hub2xvZ3kgc29sdXRpb25zIHdoaWNoIHdvcmsNCjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4m
Z3Q7IGVxdWFsbHkgd2VsbCBmb3IgYm90aCBDb250cm9sbGVycyBhbmQgTmV0d29yayBFbGVtZW50
cy48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3Vy
aWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj4gVGhlc2UNCjxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9
IkVOLVVTIj4mZ3Q7IHNvbHV0aW9ucyBtdXN0IGV4cG9zZSBsb2NhbCBkYXRhc3RvcmVzIHdoaWNo
IHByb3ZpZGUgYXV0aG9yaXRhdGl2ZSwNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IGNvbnNvbGlkYXRlZCB2aWV3
cyBvZiBkaXN0cmlidXRlZCBuZXR3b3JrIG9iamVjdHMuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT
IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bh
bj48c3BhbiBsYW5nPSJFTi1VUyI+IFRoaXMgbXVzdCBiZSBkb25lDQo8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBp
biBhIHdheSB3aGljaCBhbGxvd3MgdGhlIGFwcGxpY2F0aW9ucyB0byBzaXQgYW55d2hlcmUgaW4g
dGhlIG5ldHdvcmssDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U
ZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBvbiB2YXJpb3VzIGFic3RyYWN0aW9ucywgd2hp
bGUgbWFpbnRhaW5pbmcgZG9tYWluIGNvbnNpc3RlbmN5LiBBbmQNCjxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IHRo
aXMgbXVzdCBiZSBkb25lIHdoaWxlIG1heGltaXppbmcgYXBwbGljYXRpb24gZGV2ZWxvcGVyIHNp
bXBsaWNpdHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+
PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgVGhpcyBkcmFmdCBpcyBpbnRl
bmRlZCB0byBzdGFydCBhZ2dyZWdhdGluZyByZXF1aXJlbWVudHMgaW4gdGhpcw0KPG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMi
PiZndDsgc3BhY2UuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6
JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+
IFRoZSBkcmFmdCBpcyBub3QgY29tcGxldGUsIHNvIGl0IHdvdWxkIGJlIGdyZWF0IHRvIGhlYXIg
ZnJvbQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw
YW4gbGFuZz0iRU4tVVMiPiZndDsgb3RoZXJzIHdobyBhcmUgaW50ZXJlc3RlZCBpbiBoZWxwaW5n
IHNvIHRoYXQgd2UgZW5kIHVwIHdpdGggYSBtb3JlIGNvbXByZWhlbnNpdmUgY29udGV4dC48bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJF
Ti1VUyI+Jmd0OyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0
Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBTb2x1dGlvbnMgZG8gZXhpc3Qgd2hpY2ggY2FuIHNv
bHZlIGEgc3Vic2V0IG9mIHRoZXNlIHJlcXVpcmVtZW50cy48L3NwYW4+PHNwYW4gbGFuZz0iRU4t
VVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9z
cGFuPjxzcGFuIGxhbmc9IkVOLVVTIj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IE9uZSBwYXJ0aWN1bGFyIHRl
Y2hub2xvZ3kgd2UgaGF2ZSBidWlsdCBpcyBrbm93biBhcw0KPC9zcGFuPjxzcGFuIGxhbmc9IkVO
LVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPuKAnDwvc3Bh
bj48c3BhbiBsYW5nPSJFTi1VUyI+cGVlciBtb3VudDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIg
c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij7igJ08L3NwYW4+PHNw
YW4gbGFuZz0iRU4tVVMiPi48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZh
bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVO
LVVTIj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz
cGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IFBlZXIgbW91bnQgZ2l2ZXMgdGhlIGFiaWxpdHkgdG8gcmVm
ZXJlbmNlIFlBTkcgaW5mb3JtYXRpb24gaW50byBhDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBsb2NhbCBkYXRh
c3RvcmUgZnJvbSByZW1vdGUgZGF0YXN0b3Jlcy48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0
eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxz
cGFuIGxhbmc9IkVOLVVTIj4gVGhpcyBwcm92aWRlcyBjbGllbnQNCjxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IGFw
cGxpY2F0aW9ucyB3aXRoIGxvY2FsIGFjY2VzcyB0byBpbmZvcm1hdGlvbiB3aGljaCBtaWdodCBi
ZQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g
bGFuZz0iRU4tVVMiPiZndDsgdHJhbnNwYXJlbnRseSBmZWRlcmF0ZWQgYWNyb3NzIG11bHRpcGxl
IHN5c3RlbXMgYW5kIGRhdGFzdG9yZXMuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i
Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48c3BhbiBs
YW5nPSJFTi1VUyI+IEl0DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh
aW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBhbHNvIHJldGFpbnMgY2xlYXIgb2JqZWN0
IG93bmVyc2hpcCB0byBtaW5pbWl6ZSBzeW5jaHJvbml6YXRpb24gYW5kDQo8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0
OyBpbnRlci1zeXN0ZW0gZGVwZW5kZW5jeSBpc3N1ZXMuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT
IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNw
Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+IFRoZXJlIGFyZSBhbHJlYWR5IGltcGxlbWVudGF0
aW9ucyBvZg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+
PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgdGhpcyB0ZWNobm9sb2d5LCBmb3IgZXhhbXBsZSwgaW4g
T3BlbiBEYXlsaWdodC48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWls
eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT
Ij4gSG93ZXZlciwgd2UgYmVsaWV2ZQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgcmVxdWlyZW1lbnRzIGFuZCB1
c2UgY2FzZXMgZm9yIHRoaXMgdGVjaG5vbG9neSBhcHBseSBlcXVhbGx5IHdlbGwgdG8gbmV0d29y
ayBkZXZpY2VzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi
PjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IFBsZWFzZSBsZXQgdXMga25v
dyBpZiBlaXRoZXIgdGhlIHJlcXVpcmVtZW50cyBvciB0ZWNobm9sb2d5DQo8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0
OyBzcGVjaWZpY2F0aW9ucyBhcmUgcHJvYmxlbSB5b3UgYXJlIGludGVyZXN0ZWQgaW4gZXhwbG9y
aW5nLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu
IGxhbmc9IkVOLVVTIj4mZ3Q7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q
bGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IFRoYW5rcyE8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBF
cmljLCBBbGV4LCBQcmFiaGFrYXJhLCBBbWJpa2EsIFNoYXNoaTxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IDxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVO
LVVTIj4mZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgRnJvbTog
PGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyI+DQo8c3BhbiBzdHlsZT0i
Y29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+aW50ZXJuZXQtZHJhZnRzQGll
dGYub3JnPC9zcGFuPjwvYT4gWzxhIGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5v
cmciPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5t
YWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9zcGFuPjwvYT5dPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsg
U2VudDogVGh1cnNkYXksIFNlcHRlbWJlciAyNSwgMjAxNCA4OjQxIEFNPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsg
VG86IFByYWJoYWthcmEgWWVsbGFpIChweWVsbGFpKTsgU2hhc2hpIEt1bWFyIEJhbnNhbCAoc2hh
YmFuc2EpOw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+
PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgQW1iaWthIFByYXNhZCBUcmlwYXRoeSAoYW1idHJpcGEp
OyBBbGV4YW5kZXIgQ2xlbW0gKGFsZXgpOyBFcmljIFZvaXQNCjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IChldm9p
dCk7IEFtYmlrYSBQcmFzYWQgVHJpcGF0aHkgKGFtYnRyaXBhKTsgQWxleGFuZGVyIENsZW1tIChh
bGV4KTsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz
cGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IFByYWJoYWthcmEgWWVsbGFpIChweWVsbGFpKTsgRXJpYyBW
b2l0IChldm9pdCk7IFNoYXNoaSBLdW1hciBCYW5zYWwNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IChzaGFiYW5z
YSk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBs
YW5nPSJFTi1VUyI+Jmd0OyBTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRy
YWZ0LXZvaXQtbmV0bW9kLXBlZXItbW91bnQtDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyByZXF1aXJlbWVudHMt
MDAudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw
YW4gbGFuZz0iRU4tVVMiPiZndDsgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgQSBuZXcg
dmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXZvaXQtbmV0bW9kLXBlZXItbW91bnQtcmVxdWlyZW1lbnRz
LTAwLnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz
cGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkg
RXJpYyBWb2l0IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS48bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0
OyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBs
YW5nPSJFTi1VUyI+Jmd0OyBOYW1lOjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv
bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPiBkcmFmdC12
b2l0LW5ldG1vZC1wZWVyLW1vdW50LXJlcXVpcmVtZW50czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IFJldmlzaW9u
Ojwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJp
ZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4t
VVMiPiAwMDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz
cGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IFRpdGxlOjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5
bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PHNw
YW4gbGFuZz0iRU4tVVMiPiBSZXF1aXJlbWVudHMgZm9yIFBlZXIgTW91bnRpbmcgb2YgWUFORw0K
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFu
Zz0iRU4tVVMiPiZndDsgc3VidHJlZXMgZnJvbSBSZW1vdGUgRGF0YXN0b3JlcyBEb2N1bWVudCBk
YXRlOiAyMDE0LTA5LTI1PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu
VGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgR3JvdXA6PC9zcGFuPjxzcGFuIGxhbmc9IkVO
LVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJF
Ti1VUyI+IEluZGl2aWR1YWwgU3VibWlzc2lvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IFBhZ2VzOjwvc3Bhbj48
c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1
b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+
PHNwYW4gbGFuZz0iRU4tVVMiPiAyMjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IFVSTDo8L3NwYW4+PHNwYW4gbGFu
Zz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IDxhIGhyZWY9
Imh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXZvaXQtbmV0bW9kLXBl
ZXItIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25l
Ij5odHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC12b2l0LW5ldG1vZC1w
ZWVyLTwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu
VGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgbW91bnQtcmVxdWlyZW1lbnRzLTAwLnR4dDxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9
IkVOLVVTIj4mZ3Q7IFN0YXR1czo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250
LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj4NCjxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVO
LVVTIj4mZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0
LXZvaXQtbmV0bW9kLXBlZXItbW91bnQtIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0
O3RleHQtZGVjb3JhdGlvbjpub25lIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k
cmFmdC12b2l0LW5ldG1vZC1wZWVyLW1vdW50LTwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgcmVx
dWlyZW1lbnRzLzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi
PjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IEh0bWxpemVkOjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V
UyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPg0KPG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0i
RU4tVVMiPiZndDsgPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdm9p
dC1uZXRtb2QtcGVlci1tb3VudC0iPg0KPHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4
dC1kZWNvcmF0aW9uOm5vbmUiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXZvaXQt
bmV0bW9kLXBlZXItbW91bnQtPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyByZXF1aXJlbWVudHMt
MDA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBs
YW5nPSJFTi1VUyI+Jmd0OyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh
aW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBBYnN0cmFjdDo8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5n
PSJFTi1VUyI+Jmd0OyA8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWls
eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9
IkVOLVVTIj4gTmV0d29yayBpbnRlZ3JhdGVkIGFwcGxpY2F0aW9ucyB3YW50IHNpbXBsZSB3YXlz
IHRvIGFjY2VzcyBZQU5HPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu
VGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBz
dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOzwv
c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+IG9iamVjdHMgYW5kIHN1YnRyZWVzIHdoaWNoIG1pZ2h0
IGJlIGRpc3RyaWJ1dGVkIGFjcm9zcyBuZXR3b3JrLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IDwvc3Bhbj48c3Bh
biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7
Ij4mbmJzcDsmbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPiBQZXJmb3JtYW5jZSByZXF1
aXJlbWVudHMgbWF5IGRpY3RhdGUgdGhhdCBpdCBpcyB1bmFmZm9yZGFibGUgZm9yIGE8bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1V
UyI+Jmd0OyA8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVv
dDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT
Ij4gc3Vic2V0IG9mIHRoZXNlIGFwcGxpY2F0aW9ucyB0byBnbyB0aHJvdWdoIGV4aXN0aW5nIGNl
bnRyYWxpemVkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+
PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i
Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOzwvc3Bhbj48
c3BhbiBsYW5nPSJFTi1VUyI+IG1hbmFnZW1lbnQgYnJva2Vycy48L3NwYW4+PHNwYW4gbGFuZz0i
RU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7
PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj4gRm9yIHN1Y2ggYXBwbGljYXRpb25zLA0KIGRldmVs
b3BtZW50IGNvbXBsZXhpdHk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh
aW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyA8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi
IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7
PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj4gbXVzdCBiZSBtaW5pbWl6ZWQuPC9zcGFuPjxzcGFu
IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi
PiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+IFNwZWNpZmljIGFzcGVjdHMNCiBvZiBj
b21wbGV4aXR5IGRldmVsb3BlcnMgd2FudCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyB0bzxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7
IDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJp
ZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPiBpZ25v
cmUgaW5jbHVkZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0
Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyA8L3NwYW4+PHNwYW4gbGFu
Zz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i
c3A7Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj4gbzwvc3Bhbj48c3BhbiBsYW5nPSJF
Ti1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8
L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPiB3aGV0aGVyIGF1dGhvcml0YXRpdmUgaW5mb3JtYXRp
b24NCiBpcyBhY3R1YWxseSBzb3VyY2VkIGZyb20gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgcmVtb3RlPG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4t
VVMiPiZndDsgPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1
b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bh
bj48c3BhbiBsYW5nPSJFTi1VUyI+IGRhdGFzdG9yZXMgKGFzIHdlbGwgYXMgaG93IHRvIGdldCB0
byB0aG9zZSBkYXRhc3RvcmVzKSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
UGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyA8L3NwYW4+
PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx
dW90OyI+Jm5ic3A7Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj4gbzwvc3Bhbj48c3Bh
biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7
Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPiB3aGV0aGVyIHN1Y2ggaW5mb3JtYXRp
b24gaGFzIGJlZW4NCiBsb2NhbGx5IGNhY2hlZCBvciBub3QsPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgPG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4t
VVMiPiZndDsgPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1
b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V
UyI+IG88L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD
b3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj4gd2hldGhl
ciB0aGVyZSBhcmUgemVybywgb25lLCBvciBtb3JlDQogY29udHJvbGxlcnMgYXNzZXJ0aW5nPG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0i
RU4tVVMiPiZndDsgPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6
JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwv
c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+IG93bmVyc2hpcCBvZiBpbmZvcm1hdGlvbiwgYW5kPG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0i
RU4tVVMiPiZndDsgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4
dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls
ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOzwvc3Bh
bj48c3BhbiBsYW5nPSJFTi1VUyI+IG88L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm
b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxh
bmc9IkVOLVVTIj4gd2hldGhlciB0aGVyZSBhcmUgaW50ZXJhY3Rpb25zIHdpdGgNCiBvdGhlciBh
cHBsaWNhdGlvbnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0
Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyA8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl
PSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj4gY29uY3VycmVudGx5IHJ1bm5p
bmcgZWxzZXdoZXJlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4
dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgPC9zcGFuPjxzcGFuIGxh
bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZu
YnNwOyZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+IFRoZSBzb2x1dGlvbiByZXF1aXJl
bWVudHMgZGVzY3JpYmVkIGluIHRoaXMgZG9jdW1lbnQgZGV0YWlsIHdoYXQgaXM8bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+
Jmd0OyA8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD
b3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj4g
bmVlZGVkIHRvIHN1cHBvcnQgYXBwbGljYXRpb24gYWNjZXNzIHRvIGF1dGhvcml0YXRpdmUgbmV0
d29yayBZQU5HPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+
PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i
Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOzwvc3Bhbj48
c3BhbiBsYW5nPSJFTi1VUyI+IG9iamVjdHMgZnJvbSBjb250cm9sbGVycyAoc3Rhcikgb3IgcGVl
cmluZyBuZXR3b3JrIGRldmljZXMgKG1lc2gpDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBpbjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4m
Z3Q7IDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nv
dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPiBz
dWNoIGEgd2F5IHRvIG1lZXQgdGhlc2UgZ29hbHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgPG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZn
dDsgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g
bGFuZz0iRU4tVVMiPiZndDsgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs
YWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgPG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgPG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMi
PiZndDsgUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZy
b20gdGhlIHRpbWUgb2YNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp
blRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxp
emVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy48bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJF
Ti1VUyI+Jmd0OyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0
Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBUaGUgSUVURiBTZWNyZXRhcmlhdDxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4m
Z3Q7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu
IGxhbmc9IkVOLVVTIj4mZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+
PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgbmV0bW9kIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7
IDxhIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5k
b3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5uZXRtb2RAaWV0Zi5vcmc8L3NwYW4+PC9hPjxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9
IkVOLVVTIj4mZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu
Zm8vbmV0bW9kIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlv
bjpub25lIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZDwvc3Bh
bj48L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw
YW4gbGFuZz0iRU4tVVMiPiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX188bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0
Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBTdXBhIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7
IDxhIGhyZWY9Im1haWx0bzpTdXBhQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93
dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+U3VwYUBpZXRmLm9yZzwvc3Bhbj48L2E+PG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4t
VVMiPiZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9z
dXBhIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25l
Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N1cGE8L3NwYW4+PC9hPjxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9
IkVOLVVTIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9
IkVOLVVTIj5TdXBhIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48YSBocmVmPSJtYWlsdG86U3VwYUBp
ZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5v
bmUiPlN1cGFAaWV0Zi5vcmc8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48YSBocmVmPSJodHRwczovL3d3
dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N1cGEiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5k
b3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu
L2xpc3RpbmZvL3N1cGE8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K
PC9ib2R5Pg0KPC9odG1sPg0K

--_000_C0E0A32284495243BDE0AC8A066631A8185A49A7szxeml557mbschi_--


From nobody Sat Sep 27 21:30:17 2014
Return-Path: 
X-Original-To: supa@ietfa.amsl.com
Delivered-To: supa@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEB491A0290 for ; Sat, 27 Sep 2014 21:30:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.986
X-Spam-Level: 
X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 0XsJcgq6TLKE for ; Sat, 27 Sep 2014 21:30: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 87D331A0276 for ; Sat, 27 Sep 2014 21:30:13 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNB80396; Sun, 28 Sep 2014 04:30:11 +0000 (GMT)
Received: from SZXEML451-HUB.china.huawei.com (10.82.67.194) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 28 Sep 2014 05:30:08 +0100
Received: from szxeml557-mbs.china.huawei.com ([169.254.6.57]) by szxeml451-hub.china.huawei.com ([10.82.67.194]) with mapi id 14.03.0158.001; Sun, 28 Sep 2014 12:30:03 +0800
From: Tina TSOU 
To: LUIS MIGUEL CONTRERAS MURILLO ,  "andrew.qu@mediatek.com" 
Thread-Topic: Comments on draft-contreras-supa-yang-network-topo-00
Thread-Index: Ac/a1N4eoZE/j94BSyOMCGqEXc72jw==
Date: Sun, 28 Sep 2014 04:30:03 +0000
Message-ID: 
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.66.87.91]
Content-Type: multipart/alternative; boundary="_000_C0E0A32284495243BDE0AC8A066631A8185A6B80szxeml557mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/supa/x6BExXruvqOLVoyp53viEiWHh5s
Cc: "supa@ietf.org" 
Subject: [Supa] Comments on draft-contreras-supa-yang-network-topo-00
X-BeenThere: supa@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 28 Sep 2014 04:30:16 -0000

--_000_C0E0A32284495243BDE0AC8A066631A8185A6B80szxeml557mbschi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Dear Luis, Andrew et al,

Thank you for writing such a concrete model.

I read draft-contreras-supa-yang-network-topo-00. It is well written. Below a=
re some comments.

The basic idea of this draft is very good, and I can understand what the au=
thor tries to say. However still, more clarification is needed especially f=
or some definitions.

1.         In section 4.2, there are "virtual node" and "container node", w=
hat is difference between these two kinds of nodes? For the virtual node, i=
t is more understandable that it is the virtualization of the physical node=
 or nodes. But for the container node, it can be a group of nodes or only o=
ne node. What is the necessity to define such a container node, is it domai=
n specific or a general idea for all the use cases?



2.         Would you elaborate one use case for the container node? In orde=
r to demonstrate the insufficiency of virtual node to cover the application=
 or use cases, show one use case that the container node idea is necessary.


3.      In section 4.2, there is also some external links or nodes definiti=
on, what is the purpose for that? Are they external for the user or the up =
level controller?


4.       In first figure of section 4
                  +-------------------------+
                  |                         |
                  |       topology          |
                  |                         |
                  +-+-+----+---------+--+-+-+
                    | |    |         |  | |
                    | |    |         |  | |
                    | |    |         |  | |
                    | |    |         |  | |
      +------------+ |    |         |  | |
       |              |    |         |  | +------------------+
       |        +-----+    |         |  +--------+           |
       |        |          |         +-+         |           |
       |        |          |           |         |           |
    +--+---+ +--+---+ +----+------++---+---+ +---+---+ +-----+-----+
    |link  | |node  | |termination||extLink| |extNode| |extTerminat|
    +------+ +------+ |Point      |+-------+ +-------+ |ionPoint   |
                      +-----------+                    +-----------+

How can the unified topology be mapped into different applications or users=
? I guess you need to map this topology, if this is the only one topology, =
to different applications in order to make it work.


Thank you,
Tina


--_000_C0E0A32284495243BDE0AC8A066631A8185A6B80szxeml557mbschi_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Dear=
 Luis, Andrew et al,


 


Than=
k you for writing such a concrete model.


 


I re=
ad draft-contreras-supa-yang-netw=
ork-topo-00.
It is well written. =
Below are some comments.


 


The =
basic idea of this draft is very good, and I can understand what the author=
 tries to say. However still, more clarification is needed especially for s=
ome definitions.



1.        
In section 4.2, there are “virtual node” and “contain=
er node”, what is difference between these two kinds of nodes? For th=
e virtual node, it is more understandable that it is the virtualization
 of the physical node or nodes. But for the container node, it can be a gro=
up of nodes or only one node. What is the necessity to define such a contai=
ner node, is it domain specific or a general idea for all the use cases?


=
 


2.        
Would you elaborate one use case for the container node? In order to de=
monstrate the insufficiency of virtual node to cover the application or use=
 cases, show one use case that the container
 node idea is necessary.


=
 

3.&n=
bsp;     In section 4.2, there is also some external li=
nks or nodes definition, what is the purpose for that? Are they external fo=
r the user or the up level controller?


 



4.      
In first figure of section 4


         &nbs=
p;        +-------------------------=
+


         &nbs=
p;        |     =
;            &n=
bsp;       |


         &nbs=
p;        |     =
;  topology          |


         &nbs=
p;        |     =
;            &n=
bsp;       |


         &nbs=
p;        +-+-+----+----=
-----+--+-+-+


         &nbs=
p;          | |  &nb=
sp; |         |  | |


         &nbs=
p;          | |  &nb=
sp; |         |  | |


         &nbs=
p;          | |  &nb=
sp; |         |  | |


         &nbs=
p;          | |  &nb=
sp; |         |  | |


      +------------+=
 |    |         |&nb=
sp; | |


       |   &n=
bsp;          |  &nb=
sp; |         |  | +------=
------------+


       |   &n=
bsp;    +-----+    |   =
;      |  +--------+   =
;        |


       |   &n=
bsp;    |        &nb=
sp; |         +-+ &nbs=
p;       |      =
;     |


       |   &n=
bsp;    |         &n=
bsp;|           | &n=
bsp;       |     &nb=
sp;     |


    +--+---+ +--+---=
3; +----+------++---+---+ +---+---+ =
3;-----+-----+


    |link  | |node  | |terminatio=
n||extLink| |extNode| |extTerminat|


    +------+ +------+ |Poin=
t      |+-------+ +-------+ |ionPo=
int   |


          &nb=
sp;           +-=
----------+          =
          +-----------+=
;


 


How =
can the unified topology be mapped into different applications or users? I =
guess you need to map this topology, if this is the only one topology, to d=
ifferent applications in order to make
 it work.  


 


 


Thank you,


Tina


 






--_000_C0E0A32284495243BDE0AC8A066631A8185A6B80szxeml557mbschi_--


From nobody Sun Sep 28 00:28:21 2014
Return-Path: 
X-Original-To: supa@ietfa.amsl.com
Delivered-To: supa@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBDDC1A038C for ; Sun, 28 Sep 2014 00:28:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.387
X-Spam-Level: 
X-Spam-Status: No, score=-6.387 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 YAhfbjgmu5t8 for ; Sun, 28 Sep 2014 00:28: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 16E011A038A for ; Sun, 28 Sep 2014 00:28:13 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJZ70506; Sun, 28 Sep 2014 07:28:12 +0000 (GMT)
Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 28 Sep 2014 08:28:11 +0100
Received: from szxeml557-mbs.china.huawei.com ([169.254.6.57]) by szxeml405-hub.china.huawei.com ([::1]) with mapi id 14.03.0158.001; Sun, 28 Sep 2014 15:28:00 +0800
From: Tina TSOU 
To: Benoit Claise 
Thread-Topic: [Supa] Area hand-off, and some friendly advice ...
Thread-Index: AQHPzqh9GTuRDclUaESQdripqpP+jZwFfqEggAAWG8mAACvmgIAG2RIAgAAUrwCAAAQVgIAAbpmAgAE7Y1CAAIOxgIAHXgDj
Date: Sun, 28 Sep 2014 07:28:00 +0000
Message-ID: <6F7F6C12-B710-4CF1-904C-EDFBCBC13EB1@huawei.com>
References:   <338BDC47F10D414AB0BC843C4D5DCFE085CE25@SJCEML701-CHM.china.huawei.com>     <20140922134145.GC18011@elstar.local>  , <5421FAE9.1070105@cisco.com>
In-Reply-To: <5421FAE9.1070105@cisco.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/supa/Te_YFUdTU33stNXJSpl33A6JDBg
Cc: Georgios Karagiannis , Juergen Schoenwaelder , Zhen Cao , "supa@ietf.org" 
Subject: Re: [Supa] Area hand-off, and some friendly advice ...
X-BeenThere: supa@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 28 Sep 2014 07:28:18 -0000

RGVhciBCZW5vaXQsDQoNClRoYW5rIHlvdSBmb3IgeW91ciBraW5kIGludml0YXRpb24uDQoNClRo
ZSBCb0YgcmVxdWVzdCBoYXMgYmVlbiB1cGxvYWRlZCB0byBodHRwOi8vdHJhYy50b29scy5pZXRm
Lm9yZy9ib2YvdHJhYy93aWtpL1dpa2lTdGFydA0KDQpMb29rIGZvcndhcmQgdG8geW91ciBmdXJ0
aGVyIGd1aWRhbmNlLg0KDQoNClRoYW5rIHlvdSwNClRpbmENCg0KPiBPbiBTZXAgMjQsIDIwMTQs
IGF0IDY6NTggQU0sICJCZW5vaXQgQ2xhaXNlIiA8YmNsYWlzZUBjaXNjby5jb20+IHdyb3RlOg0K
PiANCj4gVGluYSwgYWxsLA0KPiANCj4gVG8gbWFrZSBzdXJlIHRoaXMgY29tbWVudCBpcyBub3Qg
bG9zdCBhdCB0aGUgZW5kIG9mIHRoaXMgZW1haWwsIGxldCBtZSBtYWtlIGl0IHVwZnJvbnQuIEkg
aW52aXRlIHlvdSB0byBzdWJtaXQgYSBCb0YgcmVxdWVzdCB0byBtYWtlIHlvdXIgY2FzZS4NCj4g
Tm90ZTogdGhlIGRlYWRsaW5lIGlzIFNlcHQgMjZ0aC4NCj4gDQo+IExldCdzIHN0YXJ0IGZyb20g
dGhpcyBmaWd1cmUsIHdoZXJlIE5FPSBOZXR3b3JrIEVsZW1lbnQNCj4gICAgICAgICAgICAtLS0t
LS0tLS0tLS0tLS0tLS0tLS0NCj4gICAgICAgICAgICB8IGFwcGxpY2F0aW9ucyAgIHwNCj4gICAg
ICAgICAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gICAgICAgICAgICAgICAgICAgICAgICAg
fCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8LS0tIHNlcnZpY2UgWUFORyBtb2RlbHMg
IC9ORVRDT05GIGludGVyZmFjZQ0KPiAgICAgICAgICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K
PiAgICAgICAgICAgIHwgICBjb250cm9sbGVyICAgICB8ICAgICAgICAgICAgICAgPC0tLSAgbWFw
cGluZyBzZXJ2aWNlcyB0byB0b3BvbG9neQ0KPiAgICAgICAgICAgIC0tLS0tLS0tLS0tLS0tLS0t
LS0tLQ0KPiAgICAgICAgICAgICAgICB8ICAgICAgIHwgICAgICAgIHwgICAgICAgICAgICAgICAg
ICAgIDwtLS0gZGV2aWNlL2ZlYXR1cmUgc3BlY2lmaWMgWUFORyBtb2RlbHMgLyBORVRDT05GIGlu
dGVyZmFjZQ0KPiAgICAgICAgICAgIE5FMSAgICBORTIgICBORW4NCj4gDQo+IA0KPiBXaGF0IGNh
biB0aGUgSUVURiBwb3NzaWJseSBzdGFuZGFyZGl6ZT8NCj4gMS4gU2VydmljZSBZQU5HIG1vZGVs
cyAgL05FVENPTkY/IFllcywgZm9yIHN1cmUsIGFuZCB3ZSBzaG91bGQgZG8gdGhpcyBmdWxsIHNw
ZWVkDQo+IDIuIE1hcHBpbmcgc2VydmljZXMgdG8gdG9wb2xvZ3k/IFBvdGVudGlhbGx5LCBidXQg
dGhhdCdzIG5vdCBhbiBlYXN5IHRhc2sNCj4gMy4gc2VydmljZSBZQU5HIG1vZGVscyAgL05FVENP
TkY/IEknbSBub3QgY29udmluY2VkIHdlIGNvdWxkIHN0YW5kYXJkaXplIHRoZW0sIGFzIHRoZXkg
YXJlIG9wZXJhdG9ycyBzcGVjaWZpYywgYW5kIHdpbGwgYmUgZXZvbHZpbmcgYWxvbmcgdGhlIHRp
bWUuIFRoZXJlIGFyZSBtYW55IGRpZmZlcmVudCB3YXlzIHRvIGNvbmZpZ3VyZSBhIFZQTiwgZm9y
IGV4YW1wbGUuDQo+IA0KPiBTZWUgaW4tbGluZQ0KPj4gRGVhciBhbGwsDQo+PiANCj4+IEhvcGUg
dGhpcyB2ZXJzaW9uIG9mIGRyYWZ0IGNoYXJ0ZXIgYWRkcmVzcyBtb3N0IG9mIHRoZSBjb21tZW50
cyBmcm9tIHRoZSBsaXN0Lg0KPj4gDQo+PiAtLS0tLS0NCj4+IA0KPj4gU1VQQSAoU2hhcmVkIFVu
aWZpZWQgUG9saWN5IEF1dG9tYXRpb24pDQo+PiBUYXJnZXQgQXJlYTogT1BTDQo+PiANCj4+IA0K
Pj4gRGVzY3JpcHRpb24gb2YgV29ya2luZyBHcm91cDoNCj4+IA0KPj4gTmV0d29yayBvcGVyYXRv
cnMgYXJlIGZhY2VkIHdpdGggbmV0d29ya3Mgb2YgaW5jcmVhc2luZyBzaXplIGFuZCBjb21wbGV4
aXR5IHdoaWxlIHRyeWluZyB0byBpbXByb3ZlIHRoZWlyIHF1YWxpdHkgYW5kIGF2YWlsYWJpbGl0
eSwgYXMgbW9yZSBhbmQgbW9yZSBzZXJ2aWNlcyBkZXBlbmQgb24gdGhlbS4gUHJvZ3JhbW1hdGlj
IHdheXMgdG8gY29uZmlndXJlIG5ldHdvcmtzLCBvZnRlbiBjYWxsZWQgc29mdHdhcmUtZGVmaW5l
ZCwgYXJlIGNvbnNpZGVyZWQgYnkgbWFueSBuZXR3b3JrIG9wZXJhdG9ycyBpbiBvcmRlciB0byBz
aGlmdCB0aGUgYmFsYW5jZSBpbiB0aGVpciBmYXZvci4NCj4+IA0KPj4gQXV0b21hdGluZyB0aGUg
d2F5IG9mIGV4cG9zaW5nIGEgdmlldyBvZiB0aGUgbmV0d29yayB0byBhcHBsaWNhdGlvbnMgbWF5
IHByb3ZpZGUgc2lnbmlmaWNhbnQgaW1wcm92ZW1lbnRzIGluIGNvbmZpZ3VyYXRpb24gYWdpbGl0
eSwgZXJyb3IgZGV0ZWN0aW9uIGFuZCB1cHRpbWUgZm9yIG9wZXJhdG9ycy4gSG93ZXZlciB0aGUg
cmVhbCB2YWx1ZSBiZWhpbmQgY2VudHJhbCBjb25maWd1cmF0aW9uIHNjaGVtZXMgbGllcyB3aXRo
aW4gdGhlIHBvc3NpYmxlIHNpbXBsaWZpY2F0aW9uIHRocm91Z2ggbW9kZWxzIHByb3ZpZGVkIGJ5
IHN1Y2ggc3lzdGVtcyB0byBhcHBsaWNhdGlvbnMgYW5kIG5ldHdvcmsgc2VydmljZXMgcnVubmlu
ZyBhYm92ZSB0aGVtIChvbiB0aGUgc28tY2FsbGVkIG5vcnRoYm91bmQgc2lkZSkuIFdlbGwtZGVz
aWduZWQgbW9kZWxzIGFyZSBhYmxlIHRvIHByb3ZpZGUgYSB3aWRlIHJhbmdlIG9mIGdyYW51bGFy
aXR5IGZvciB2YXJpb3VzIGFwcGxpY2F0aW9ucyBhbmQgbmV0d29yayBzZXJ2aWNlcyBuZWVkcywg
ZnJvbSB0aGUgbG93ZXItbGV2ZWwgcGh5c2ljYWwgbmV0d29yayB0byBoaWdoLWxldmVsIGFwcGxp
Y2F0aW9uIHNlcnZpY2VzLg0KPj4gDQo+PiBBbHRob3VnaCBzZXZlcmFsIG9yZ2FuaXphdGlvbnMg
b3V0c2lkZSBvZiB0aGUgSUVURiBoYXZlIGRlZmluZWQgdmFyaW91cyBzY2hlbWVzIGZvciB0aGUg
Y29uZmlndXJhdGlvbiBvZiBuZXR3b3JrIGRldmljZXMgYW5kIHNwZWNpZmljIG5ldHdvcmsgY29u
dHJvbGxlcnMsIG5vbmUgb2YgdGhlbSBvZmZlciBhIHZlbmRvci1uZXV0cmFsIHN0YW5kYXJkaXpl
ZCB3YXkgZm9yIGFwcGxpY2F0aW9ucyBhbmQgbmV0d29yayBzZXJ2aWNlcyB0byB0cmFuc21pdCB0
aGVpciBuZWVkcyB0byBjb250cm9sbGVycy4NCj4gSXNuJ3QgaXQgc2ltcGx5IGJlY2F1c2UgdGhl
IGluZHVzdHJ5IGhhcyBub3Qgc3RhbmRhcmRpemVkIHRoZWlyIHNlcnZpY2VzPyAgU2VlIGFib3Zl
Lg0KPj4gVGhlIFNVUEEgKFNoYXJlZCBVbmlmaWVkIFBvbGljeSBBdXRvbWF0aW9uKSB3b3JraW5n
IGdyb3VwIHdpbGwgd29yayBvbiB0aGUgZGVmaW5pdGlvbiBvZiBzdWNoIGFzIHN0YW5kYXJkaXpl
ZCBpbnRlcmZhY2UgZm9yIGFwcGxpY2F0aW9ucyBhbmQgbmV0d29yayBzZXJ2aWNlcyB0byBjb21t
dW5pY2F0ZSB3aXRoIG5ldHdvcmsgY29udHJvbGxlcnMgb2YgYWxsIHR5cGVzLg0KPiBXaGF0IGlz
IGEgc3RhbmRhcmRpemVkIGludGVyZmFjZT8NCj4gSXMgInNlcnZpY2UgWUFORyBtb2RlbHMgIC9O
RVRDT05GIChvciBwb3RlbnRpYWxseSBSRVNUQ09ORikiPyBPciBpcyBpdCBzb21ldGhpbmcgZWxz
ZT8NCj4+IA0KPj4gVGhlIHNwZWNpZmljYXRpb24gb2YgdGhlIGludGVyZmFjZSB0b3dhcmRzIGVu
ZCB1c2VyIGFwbGxpY2F0aW9ucyBpcyBpbml0aWFsbHkgbm90IGluIHRoZSBzY29wZSBvZiBTVVBB
Lg0KPiBIZXJlIHlvdSBsb3N0IG1lLg0KPiBXaGljaCBpbnRlcmZhY2UgZG8geW91IG1lYW4gaW4g
ZmlndXJlIGFib3ZlPw0KPiANCj4+IEluIHBhcnRpY3VsYXIsIGFzIHN0YXJ0aW5nIHBvaW50LCBT
VVBBIHdpbGwgb25seSBmb2N1cyBvbiBuZXR3b3JrIHNlcnZpY2VzLCB3aGljaCBhcmUgZW5oYW5j
ZWQgT3BlcmF0aW9uYWwgU3VwcG9ydCBTeXN0ZW0gKE9TUykgbGlrZSBzZXJ2aWNlcyB0aGF0IGhl
bHAgYSBjb21tdW5pY2F0aW9uIHNlcnZpY2UgcHJvdmlkZXIgdG8gbW9uaXRvciwgY29udHJvbCwg
YW5hbHl6ZSBhbmQgbWFuYWdlIGEgY29tbXVuaWNhdGlvbiBuZXR3b3JrLiBUaGUgc3lzdGVtcyB0
aGF0IGFyZSBydW5uaXVuZyBzdWNoIG5ldHdvcmsgc2VydmljZXMgYXJlIGRlbm90ZWQgaW4gdGhp
cyBkb2N1bWVudCBhcyBOZXR3b3JrIFNlcnZpY2UgU3lzdGVtcy4NCj4+IEVhY2ggbmV0d29yayBz
ZXJ2aWNlIGNhbiBiZSByZXByZXNlbnRlZCBieSBhIGNsYXNzaWZpZWQgYXBwbGljYXRpb24gYmFz
ZWQgUE9MSUNZIG1vZGVsLCBzaW5jZSBpdCBjYW4gbW9kZWwgdGhlIGdyb3VwIG9mIGRlbWFuZHMg
d2hpY2ggYXJlIFNIQVJFRCBhbmQgVU5JRklFRCBhbmQgYXJlIGNvbWluZyBmcm9tIGEgYnVuZGxl
IG9mIGFwcGxpY2F0aW9ucyB0aGF0IGltcG9zZSBzaW1pbGFyIHJlcXVpcmVtZW50cyBvbiB0aGUg
Y29tbXVuaWNhdGlvbiBuZXR3b3JrLg0KPiBJJ20gYWZyYWlkIEkgZG9uJ3QgdW5kZXJzdGFuZCAo
bGlrZSBKqLlyZ2VuKQ0KPj4gDQo+PiBUaGUgbWFpbiBnb2FsIG9mIFNVUEEgaXMgdG8gcHJvdmlk
ZSBhIHdheSBmb3IgYXBwbGljYXRpb25zIGFuZCBmb3IgbmV0d29yayBzZXJ2aWNlcyB0byBzcGVj
aWZ5IFNIQVJFRCBhcHBsaWNhdGlvbiBiYXNlZCBQT0xJQ0lFUyB0byB0aGUgbmV0d29yayBpbmZy
YXN0cnVjdHVyZSB1c2luZyBhIHNpbXBsaWZpZWQgdmlldyBvZiB0aGUgbmV0d29yay4gVGhpcyBj
YW4gYmUgcmVhbGl6ZWQgYnk6DQo+PiAoMSkgbW9kZWxpbmcgdGhlIG5ldHdvcmsgaW5mcmFzdHJ1
Y3R1cmUgYXMgYW4gc2ltcGxpZmllZCBuZXR3b3JrIGdyYXBoIHVzaW5nIGEgbW9kZWxpbmcgbGFu
Z3VhZ2Ugc3VjaA0KPj4gYXMgWUFORywNCj4gDQo+PiAoMikgdHJhbnNwb3J0aW5nIG1vZGVsIGlu
c3RhbmNlcyBlaXRoZXIgdXNpbmcgTkVUQ09ORiBvciBSRVNUQ09ORiBhbmQgKDMpIHByb3ZpZGlu
ZyBndWlkZWxpbmVzIG9uIEFVVE9NQVRJQ0FMTFkgbWFwcGluZyBwb2xpY2llcyB0byBhdHRyaWJ1
dGVzIG9mIHRoZSBuZXR3b3JrIGdyYXBocy4NCj4+IA0KPj4gQWx0aG91Z2ggc29tZSBJRVRGIHdv
cmtpbmcgZ3JvdXBzIGhhdmUgc3RhcnRlZCB3b3JrIHJlbGF0aW5nIHRvIHRoZSBkZXNjcmlwdGlv
biBvZiB2YXJpb3VzIHRvcG9sb2dpZXMgc3VjaCBhcyBJMlJTIChMM2FuZCByb3V0aW5nIHRvcG9s
b2dpZXMpLCBBTFRPIChjb3N0IG1hcHMpLCBTRkMgKHNlcnZpY2UgY2hhaW4pLCBub25lIG9mIHRo
ZXNlIGdyb3VwcyBhaW0gYXQgb2ZmZXJpbmcgdHJ1bHkgZ2VuZXJpYyB0b3BvbG9neSBtb2RlbHMg
Zm9yIHRoZSBzdGFuZGFyZCBub3J0aGJvdW5kIGludGVyZmFjZS4NCj4+IFNVUEEgd2lsbCB3b3Jr
IG9uIGRlZmluaW5nIGludGVyZmFjZXMgYmFzZWQgb24gdGhlIGNvbmNlcHQgb2YgbmV0d29yayBn
cmFwaCwgYW4gZW50aXR5IGRlc2NyaWJpbmcgYW4gYXJiaXRyYXJ5IHRvcG9sb2d5IG9mIG5vZGVz
IGFuZCBsaW5rcyBhdCBhbnkgbGV2ZWwgb2YgZ3JhbnVsYXJpdHkuIFN1Y2ggYSBncmFwaCBtYXkg
ZGVzY3JpYmUsIGZvciBleGFtcGxlLCBhIHBoeXNpY2FsIHRvcG9sb2d5LCBhIHNlcnZpY2UgdG9w
b2xvZ3kgb3IgdGhlIHJlbGF0aW9uc2hpcHMgYmV0d2VlbiBkYXRhY2VudGVycy4gQW55IG5ldHdv
cmsgdG9wb2xvZ3kgZGF0YSBtb2RlbHMgb3IgcG9saWN5IG1vZGVscyB0aGF0IGhhdmUgYmVlbiBk
ZWZpbmVkIChvciBhcmUgYmVpbmcgZGVmaW5lZCkgd2l0aGluIHRoZSBJRVRGIHdpbGwgYmUgcmV1
c2VkIGluIFNVUEEgYXMgbXVjaCBhcyBwb3NzaWJsZS4NCj4+IEluIGFkZGl0aW9uIHRvIHRoZSBh
Ym92ZSwgcG9saWNpZXMgbWF5IGJlIGRlZmluZWQgYW5kIGFwcGxpZWQgdG8gYSBuZXR3b3JrIGdy
YXBoLiBUaGVzZSBhcHBsaWNhdGlvbiBiYXNlZCBwb2xpY2llcyBhcmUgYWN0aW9ucyBvciBjb25z
dHJhaW50cyBnZW5lcmF0ZWQgYnkgTmV0d29yayBTZXJ2aWNlIFN5c3RlbXMuIFRoZXkgYXJlIHRo
ZW4gbWFwcGVkIGZyb20gdGhlIG5ldHdvcmsgZ3JhcGggaW5zdGFuY2UgaW50byBzcGVjaWZpYyBu
ZXR3b3JrIG1hbmFnZW1lbnQgcG9saWNpZXMgdG93YXJkIG5ldHdvcmsgY29tcG9uZW50cy4NCj4+
ICAgIA0KPj4gV29yayBpdGVtcyBmb3IgU1VQQSBpbmNsdWRlOg0KPj4gDQo+PiAxKSBUaGUgZGVm
aW5pdGlvbiBvZiBhIHN0YW5kYXJkaXplZCBtb2RlbCBmb3IgYSBuZXR3b3JrIGdyYXBoLCB1c2lu
ZyBZQU5HLiBUaGlzIG1vZGVsIG1heSBiZSB1c2VkIHRvIGRlc2NyaWJlIHRvcG9sb2dpZXMgYXQg
YW55IGZ1bmN0aW9uYWwgbGF5ZXIsIGZyb20gcGh5c2ljYWwgbmV0d29ya3MgdG8gbmV0d29yayBz
ZXJ2aWNlcy4NCj4+IEFueSBuZXR3b3JrIHRvcG9sb2d5IGRhdGEgbW9kZWxzIG9yIHBvbGljeSBt
b2RlbHMgdGhhdCBoYXZlIGJlZW4gZGVmaW5lZCAob3IgYXJlIGJlaW5nIGRlZmluZWQpIHdpdGhp
biB0aGUgSUVURiB3aWxsIGJlIHJldXNlZCBpbiBTVVBBIGFzIG11Y2ggYXMgcG9zc2libGUuDQo+
IFNvIGJhc2ljYWxseSwgeW91ICJqdXN0IiB3YW50IGEgdG9wb2xvZ3kgZGF0YWJhc2UgLi4uDQo+
IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNsZW1tLW5ldG1vZC15YW5nLW5ldHdv
cmstdG9wby0wMQ0KPiBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWNvbnRy
ZXJhcy1zdXBhLXlhbmctbmV0d29yay10b3BvLw0KPiAuLi4gYW5kIGEgd2F5IHRvIG1hcCBzZXJ2
aWNlcyB0byBpdC4NCj4gVGhlIHRvcG9sb2d5IGlzIGtpbmQgb2YgZWFzeSwgdGhlIG1hcHBpbmcg
aXMgd2F5IGhhcmRlciENCj4+IA0KPj4gMikgVGhlIGRlZmluaXRpb24gYW5kIHN0YW5kYXJkaXph
dGlvbiBvZiBhIG51bWJlciBvZiBiYXNpYyBwb2xpY3kgYW5kIGRhdGEgbW9kZWxzIHVzaW5nIG5l
dHdvcmsgZ3JhcGhzLiBUaGVzZSBtaWdodCBpbmNsdWRlLCBidXQgYXJlIG5vdCBsaW1pdGVkIHRv
IEwzVlBOcywgZGF0YWNlbnRlcnMsIHRyYWZmaWMgZW5naW5lZXJpbmcsIGltcGxlbWVudGF0aW9u
IG9mIElQdjYgdHJhbnNpdGlvbiBtZWNoYW5pc20gYW5kIHRoZWlyIGVuZm9yY2VtZW50IHRvIHVz
ZXJzLg0KPiBBcmUgdGhlc2UgZXhhbXBsZXMgb2YgU0hBUkVEIGFuZCBVTklGSUVEIHBvbGljaWVz
Pw0KPiANCj4gUmVnYXJkcywgQmVub2l0IChPUFMgQUQpDQo+PiAgDQo+PiAzKSBHdWlkZWxpbmVz
IG9uIGhvdyB0byB1c2UgTkVUQ09ORiAob3IgUkVTVENPTkYpIGF1dGhlbnRpY2F0aW9uIGFuZCBh
dXRob3JpemF0aW9uIG1lY2hhbmlzbXMgdG8gYWNoaWV2ZSBwcm90ZWN0aW9uIGFuZCBpc29sYXRp
b24NCj4+IA0KPj4gNCkgR3VpZGVsaW5lcyBmb3IgYXV0b21hdGljIG1hcHBpbmcgcG9saWNpZXMg
dG8gYXR0cmlidXRlcyBvZiB0aGUgbmV0d29yayBncmFwaHMuDQo+PiANCj4+IA0KPj4gVGhlIGZv
bGxvd2luZyBpdGVtcyBhcmUgb3V0IG9mIHRoZSBTVVBBIHNjb3BlOg0KPj4gDQo+PiBvKSBzcGVj
aWZpY2F0aW9uIG9mIHRoZSBuZXR3b3JrIG1hbmFnZW1lbnQgYW5kIGNvbnRyb2xsaW5nIHBvbGlj
aWVzIGFuZCB0aGVpciBhc3NvY2lhdGVkIGRldmljZSBjb25maWd1cmF0aW9uIG1vZGVscw0KPj4g
DQo+PiANCj4+IE1pbGVzdG9uZXM6DQo+PiANCj4+IG8pIFByb2R1Y2UgJ1Byb2JsZW0gU3RhdGVt
ZW50IGFuZCBVc2UgQ2FzZXMnIGFzIGFuIEluZm9ybWF0aW9uYWwgUkZDLg0KPj4gDQo+PiBvKSBQ
cm9kdWNlIGEgZG9jdW1lbnQgc3BlY2lmeWluZyB0aGUgWUFORyBtb2RlbHMgZm9yIGEgZ2VuZXJp
YyBtdWx0aS1sYXllciBuZXR3b3JrIGdyYXBoLCBhcyBQcm90b2NvbCBTcGVjaWZpY2F0aW9uJyBT
dGFuZGFyZHMgVHJhY2sgUkZDLg0KPj4gDQo+PiBvKSBQcm9kdWNlIHNldmVyYWwgZG9jdW1lbnRz
IGRlc2NyaWJpbmcgZGlmZmVyZW50IHZpZXdzIG9mIGEgY29tbXVuaWNhdGlvbiBuZXR3b3JrIGJ5
IHVzaW5nIHRoZSBuZXR3b3JrIGdyYXBoIG1vZGVsIGRlZmluZWQgYWJvdmUsIHdoaWNoIGluY2x1
ZGVzIHBvbGljeSBhbmQgZGF0YSBtb2RlbHMsIGFzIFByb3RvY29sIFNwZWNpZmljYXRpb25zJyBT
dGFuZGFyZHMgVHJhY2sgUkZDcy4NCj4+IA0KPj4gbykgUHJvZHVjZSBhIGRvY3VtZW50IG9uIGRl
ZmluaW5nIHRoZSBTVVBBIE5FVENPTi9ZQU5HIG9yIFJFU1RDT05GIChvciBSRVNUQ09ORi9ZQU5H
KSBjb250YWluZXJzLCBhcyBQcm90b2NvbCBTcGVjaWZpY2F0aW9uJyBTdGFuZGFyZHMgVHJhY2sg
UkZDLg0KPj4gICAgIG8pIFByb2R1Y2UgYSBkb2N1bWVudCB0aGF0IHByb3ZpZGVzIHRoZSBndWlk
ZWxpbmVzIG9uIHVzaW5nIE5FVENPTkYgKG9yIFJFU1RDT05GKSBhdXRoZW50aWNhdGlvbiBhbmQg
YXV0aG9yaXphdGlvbiBtZWNoYW5pc21zIHRvIGFjaGlldmUgc2VjdXJpdHkgcHJvdGVjdGlvbiBh
bmQgaXNvbGF0aW9uJyBhcyBhbiBJbmZvcm1hdGlvbmFsIFJGQy4NCj4+IA0KPj4gbykgUHJvZHVj
ZSBhIGRvY3VtZW50IHRoYXQgcHJvdmlkZXMgdGhlIGd1aWRlbGluZXMgZm9yIGZvciBhdXRvbWF0
aWMgbWFwcGluZyBwb2xpY2llcyB0byBhdHRyaWJ1dGVzIG9mIHRoZSBuZXR3b3JrIGdyYXBocy4N
Cj4+IA0KPj4gLS0tLS0tLS0tLS0NCj4+IA0KPj4gDQo+PiBUaGFuayB5b3UsDQo+PiBUaW5hDQo+
PiANCj4+IA0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IEdlb3JnaW9z
IEthcmFnaWFubmlzDQo+PiBTZW50OiBUdWVzZGF5LCBTZXB0ZW1iZXIgMjMsIDIwMTQgNDoxOCBB
TQ0KPj4gVG86IEp1ZXJnZW4gU2Nob2Vud2FlbGRlcg0KPj4gQ2M6IFpoZW4gQ2FvOyBUaW5hIFRT
T1U7IHN1cGFAaWV0Zi5vcmcNCj4+IFN1YmplY3Q6IFJFOiBbU3VwYV0gQXJlYSBoYW5kLW9mZiwg
YW5kIHNvbWUgZnJpZW5kbHkgYWR2aWNlIC4uLg0KPj4gDQo+PiBIaSBKdWVyZ2VuLA0KPj4gDQo+
PiBPa2F5LCB0aGFua3MgZm9yIHlvdXIgcmVjb21tZW5kYXRpb24hDQo+PiANCj4+IEJlc3QgcmVn
YXJkcywNCj4+IEdlb3JnaW9zDQo+PiANCj4+IA0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t
LS0NCj4+IEZyb206IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciBbbWFpbHRvOmouc2Nob2Vud2FlbGRl
ckBqYWNvYnMtdW5pdmVyc2l0eS5kZV0NCj4+IFNlbnQ6IE1vbmRheSwgU2VwdGVtYmVyIDIyLCAy
MDE0IDM6NDIgUE0NCj4+IFRvOiBHZW9yZ2lvcyBLYXJhZ2lhbm5pcw0KPj4gQ2M6IFpoZW4gQ2Fv
OyBUaW5hIFRTT1U7IHN1cGFAaWV0Zi5vcmcNCj4+IFN1YmplY3Q6IFJlOiBbU3VwYV0gQXJlYSBo
YW5kLW9mZiwgYW5kIHNvbWUgZnJpZW5kbHkgYWR2aWNlIC4uLg0KPj4gDQo+Pj4gT24gTW9uLCBT
ZXAgMjIsIDIwMTQgYXQgMDE6Mjc6MDhQTSArMDAwMCwgR2Vvcmdpb3MgS2FyYWdpYW5uaXMgd3Jv
dGU6DQo+Pj4gbykgZW1waGFzaXplIHRoYXQgcmVnYXJkaW5nIHBvbGljeSwgZW5oYW5jZW1lbnRz
IG9mIHRoZSBZQU5HIHhQYXRoIGV4cHJlc3Npb24gbWlnaHQgYmUgcmVxdWlyZWQuDQo+PiBJIGFt
IHdvbmRlcmluZyB3aGF0IHRoaXMgaXMgb3Igd2h5IHRoaXMgd291bGQgYmUgbmVlZGVkLiBBdCB0
aGUgY2hhcnRlciBsZXZlbCwgeW91IG1heSBuZWVkIHRvIHRhbGsgYWJvdXQgZGVmaW5pbmcgZGF0
YSBtb2RlbHMgdG8gZXhwcmVzcyBwb2xpY3kuIEkgZG8gbm90IHNlZSB3aHkgdGhhdCB3b3VsZCBu
ZWVkIHRvIGVuaGFuY2VtZW50cyBvZiBZQU5HJ3MgdXNhZ2Ugb2YgeHBhdGguDQo+PiANCj4+IC9q
cw0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N
Cj4gU3VwYSBtYWlsaW5nIGxpc3QNCj4gU3VwYUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRm
Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N1cGENCg==


From nobody Sun Sep 28 20:39:12 2014
Return-Path: 
X-Original-To: supa@ietfa.amsl.com
Delivered-To: supa@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 477C01A6F9F for ; Sun, 28 Sep 2014 20:39:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.986
X-Spam-Level: 
X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 UXUVfA4qtwo7 for ; Sun, 28 Sep 2014 20:39:06 -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 8E18F1A6F9A for ; Sun, 28 Sep 2014 20:39:04 -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 BKA26701; Mon, 29 Sep 2014 03:39:02 +0000 (GMT)
Received: from SZXEML422-HUB.china.huawei.com (10.82.67.161) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 29 Sep 2014 04:39:00 +0100
Received: from szxeml557-mbs.china.huawei.com ([169.254.6.57]) by szxeml422-hub.china.huawei.com ([10.82.67.161]) with mapi id 14.03.0158.001; Mon, 29 Sep 2014 11:38:54 +0800
From: Tina TSOU 
To: LUIS MIGUEL CONTRERAS MURILLO ,  "andrew.qu@mediatek.com" , Martin Bjorklund 
Thread-Topic: Comments on draft-contreras-supa-yang-network-topo-00
Thread-Index: Ac/a1N4eoZE/j94BSyOMCGqEXc72jwAv1r0g
Date: Mon, 29 Sep 2014 03:38:53 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.66.87.91]
Content-Type: multipart/alternative; boundary="_000_C0E0A32284495243BDE0AC8A066631A8185A90E5szxeml557mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/supa/8CVFFmdyDK-Md1teHUuRg0LFxog
Cc: "supa@ietf.org" 
Subject: Re: [Supa] Comments on draft-contreras-supa-yang-network-topo-00
X-BeenThere: supa@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 29 Sep 2014 03:39:11 -0000

--_000_C0E0A32284495243BDE0AC8A066631A8185A90E5szxeml557mbschi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Dear Martin,

We discussed off-line how the supa topology draft is related to the i2rs to=
pology draft, I feel it is worthy to bring it to the list for broader audie=
nce.

This draft http://datatracker.ietf.org/doc/draft-hares-i2rs-info-model-serv=
ice-topo/ also focused on network topology information model which is also =
within the scope of SUPA topology model. However, besides the common intere=
sts at topology model, there are still significant differences between the =
two.

1.       The I2RS topology model is based on a service topology which is cl=
osely related to certain service. And the service topology can be dedicated=
 to one tenant or multiple tenants. For SUPA, different layers have differe=
nt views or representations of the same network topology. Multiple users ma=
y not "share" the same topology but use their own topology at their own lay=
er.



2.       The I2RS topology model use service topologies which should be ind=
ependent from network topology and therefore should not map onto other unde=
rlay topologies. The SUPA topology model is a unified topology model to sup=
port service at all levels. Each level can have its own representation of t=
he topology.


3.     There is no YANG based topology model in this I2RS draft yet. SUPA h=
as a well defined YANG data model to describe the topology.

All in all, the two drafts have something in common and the basic principal=
s are very close. IMO, service topology can be one use case for SUPA topolo=
gy model to be used in BGP, OSPF and so on.


Thank you,
Tina

From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Tina TSOU
Sent: Sunday, September 28, 2014 12:30 PM
To: LUIS MIGUEL CONTRERAS MURILLO; andrew.qu@mediatek.com
Cc: supa@ietf.org
Subject: [Supa] Comments on draft-contreras-supa-yang-network-topo-00

Dear Luis, Andrew et al,

Thank you for writing such a concrete model.

I read draft-contreras-supa-yang-network-topo-00. It is well written. Below a=
re some comments.

The basic idea of this draft is very good, and I can understand what the au=
thor tries to say. However still, more clarification is needed especially f=
or some definitions.

1.         In section 4.2, there are "virtual node" and "container node", w=
hat is difference between these two kinds of nodes? For the virtual node, i=
t is more understandable that it is the virtualization of the physical node=
 or nodes. But for the container node, it can be a group of nodes or only o=
ne node. What is the necessity to define such a container node, is it domai=
n specific or a general idea for all the use cases?



2.         Would you elaborate one use case for the container node? In orde=
r to demonstrate the insufficiency of virtual node to cover the application=
 or use cases, show one use case that the container node idea is necessary.


3.      In section 4.2, there is also some external links or nodes definiti=
on, what is the purpose for that? Are they external for the user or the up =
level controller?


4.       In first figure of section 4
                  +-------------------------+
                  |                         |
                  |       topology          |
                  |                         |
                  +-+-+----+---------+--+-+-+
                    | |    |         |  | |
                    | |    |         |  | |
                    | |    |         |  | |
                    | |    |         |  | |
      +------------+ |    |         |  | |
       |              |    |         |  | +------------------+
       |        +-----+    |         |  +--------+           |
       |        |          |         +-+         |           |
       |        |          |           |         |           |
    +--+---+ +--+---+ +----+------++---+---+ +---+---+ +-----+-----+
    |link  | |node  | |termination||extLink| |extNode| |extTerminat|
    +------+ +------+ |Point      |+-------+ +-------+ |ionPoint   |
                      +-----------+                    +-----------+

How can the unified topology be mapped into different applications or users=
? I guess you need to map this topology, if this is the only one topology, =
to different applications in order to make it work.


Thank you,
Tina


--_000_C0E0A32284495243BDE0AC8A066631A8185A90E5szxeml557mbschi_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable













Dear Martin,


 


We discussed off-line how the supa topology draft is related to t=
he i2rs topology draft, I feel it is worthy to bring it to the list for bro=
ader audience.


 


This draft http://datatracker.ietf.org/doc/draft-hares-i2rs-info-=
model-service-topo/ also focused on network topology information model whic=
h is also within the scope of SUPA topology
 model. However, besides the common interests at topology model, there are =
still significant differences between the two.





1.      
The I2RS topology model is based on a service topology wh=
ich is closely related to certain service. And the service topology can be =
dedicated to one tenant or multiple
 tenants. For SUPA, different layers have different views or representation=
s of the same network topology. Multiple users may not “share” =
the same topology but use their own topology at their own layer.=



=
 



2.      
The I2RS topology model use service topologies which shou=
ld be independent from network topology and therefore should not map onto o=
ther underlay topologies. The SUPA topology
 model is a unified topology model to support service at all levels. Each l=
evel can have its own representation of the topology.



=
 


3.     There is no YANG based topology model =
in this I2RS draft yet. SUPA has a well defined YANG data model to describe=
 the topology.


 


All in all, the two drafts have something in common and the basic=
 principals are very close. IMO, service topology can be one use case for S=
UPA topology model to be used in BGP,
 OSPF and so on. 


  


 


Thank you,


Tina



<=
o:p> 






From: Supa [mailto=
:supa-bounces@ietf.org]
On Behalf Of Tina TSOU

Sent: Sunday, September 28, 2014 12:30 PM

To: LUIS MIGUEL CONTRERAS MURILLO; andrew.qu@mediatek.com

Cc: supa@ietf.org

Subject: [Supa] Comments on draft-contreras-supa-yang-network-topo-0=
0






 


Dear=
 Luis, Andrew et al,


 


Than=
k you for writing such a concrete model.


 


I re=
ad draft-contreras-supa-yang-netw=
ork-topo-00.
It is well written. =
Below are some comments.


 


The =
basic idea of this draft is very good, and I can understand what the author=
 tries to say. However still, more clarification is needed especially for s=
ome definitions.



1.        
In section 4.2, there are “virtual node” and “contain=
er node”, what is difference between these two kinds of nodes? For th=
e virtual node, it is more understandable that it is the virtualization
 of the physical node or nodes. But for the container node, it can be a gro=
up of nodes or only one node. What is the necessity to define such a contai=
ner node, is it domain specific or a general idea for all the use cases?


=
 


2.        
Would you elaborate one use case for the container node? In order to de=
monstrate the insufficiency of virtual node to cover the application or use=
 cases, show one use case that the container
 node idea is necessary.


=
 

3.&n=
bsp;     In section 4.2, there is also some external li=
nks or nodes definition, what is the purpose for that? Are they external fo=
r the user or the up level controller?


 



4.      
In first figure of section 4


         &nbs=
p;        +-------------------------=
+


         &nbs=
p;        |     =
;            &n=
bsp;       |


         &nbs=
p;        |     =
;  topology          |


         &nbs=
p;        |     =
;            &n=
bsp;       |


         &nbs=
p;        +-+-+----+----=
-----+--+-+-+


         &nbs=
p;          | |  &nb=
sp; |         |  | |


         &nbs=
p;          | |  &nb=
sp; |         |  | |


         &nbs=
p;          | |  &nb=
sp; |         |  | |


         &nbs=
p;          | |  &nb=
sp; |         |  | |


      +------------+=
 |    |         |&nb=
sp; | |


       |   &n=
bsp;          |  &nb=
sp; |         |  | +------=
------------+


       |   &n=
bsp;    +-----+    |   =
;      |  +--------+   =
;        |


       |   &n=
bsp;    |        &nb=
sp; |         +-+ &nbs=
p;       |      =
;     |


       |   &n=
bsp;    |         &n=
bsp;|           | &n=
bsp;       |     &nb=
sp;     |


    +--+---+ +--+---=
3; +----+------++---+---+ +---+---+ =
3;-----+-----+


    |link  | |node  | |terminatio=
n||extLink| |extNode| |extTerminat|


    +------+ +------+ |Poin=
t      |+-------+ +-------+ |ionPo=
int   |


          &nb=
sp;           +-=
----------+          =
          +-----------+=
;


 


How =
can the unified topology be mapped into different applications or users? I =
guess you need to map this topology, if this is the only one topology, to d=
ifferent applications in order to make
 it work.  


 


 


Thank you,


Tina


 






--_000_C0E0A32284495243BDE0AC8A066631A8185A90E5szxeml557mbschi_--


From nobody Mon Sep 29 02:51:28 2014
Return-Path: 
X-Original-To: supa@ietfa.amsl.com
Delivered-To: supa@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51A691A8722 for ; Mon, 29 Sep 2014 02:51:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.986
X-Spam-Level: 
X-Spam-Status: No, score=-3.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_AFFORDABLE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 uSYpARhq9VHj for ; Mon, 29 Sep 2014 02:51:23 -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 0E0E71A1A28 for ; Mon, 29 Sep 2014 02:51:21 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNC85865; Mon, 29 Sep 2014 09:51:20 +0000 (GMT)
Received: from SZXEML450-HUB.china.huawei.com (10.82.67.193) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 29 Sep 2014 10:50:58 +0100
Received: from szxeml557-mbs.china.huawei.com ([169.254.6.57]) by szxeml450-hub.china.huawei.com ([10.82.67.193]) with mapi id 14.03.0158.001; Mon, 29 Sep 2014 17:49:35 +0800
From: Tina TSOU 
To: Georgios Karagiannis , "Eric Voit (evoit)" , "supa@ietf.org" 
Thread-Topic: [netmod] "00" Notification for draft-voit-netmod-peer-mount-requirements
Thread-Index: Ac/ZjioymKhX4n/+Q0irapwH2HUqIwAAEm2AAEtmX7AAQ3RaMA==
Date: Mon, 29 Sep 2014 09:49:35 +0000
Message-ID: 
References:   
In-Reply-To: 
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.66.87.91]
Content-Type: multipart/alternative; boundary="_000_C0E0A32284495243BDE0AC8A066631A8185AA587szxeml557mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/supa/Fu9Yl8NyD-Ad6r4CdMDxd8yJbf8
Cc: "Alexander Clemm \(alex\)" 
Subject: Re: [Supa] [netmod] "00" Notification for draft-voit-netmod-peer-mount-requirements
X-BeenThere: supa@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 29 Sep 2014 09:51:26 -0000

--_000_C0E0A32284495243BDE0AC8A066631A8185AA587szxeml557mbschi_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

RGVhciBFcmljIGV0IGFsLA0KDQpOb3cgSSByZWFkIGRyYWZ0LXZvaXQtbmV0bW9kLXBlZXItbW91
bnQtcmVxdWlyZW1lbnRzLCBpdCBpcyB2ZXJ5IGdvb2QgYXQgZGVzY3JpYmluZyB0aGUgcmVxdWly
ZW1lbnRzLg0KDQpJbiB0aGlzIGRyYWZ0LCB0d28gb3B0aW9uYWwgYXJjaGl0ZWN0dXJlcyB3ZXJl
IHByb3Bvc2VkOiBhIGNlbnRyYWxpemVkIG9uZSBzaW1pbGFyIHRvIFNVUEEgYW5kIGEgZGlzdHJp
YnV0ZWQgb25lIHdoaWNoIGlzIGFsc28gY29tcGF0aWJsZSB3aXRoIFNVUEEgKHdpdGggYSBsaXR0
bGUgZXh0ZW5zaW9uIG9mIFNVUEEgY2hhcnRlciBhbmQgc2NvcGUsIHdvdWxkIHlvdSBwbGVhc2Ug
cmV2aWV3IHRoZSBjaGFydGVyIG9mIFNVUEEgYW5kIHByb3ZpZGUgc29tZSB0ZXh0IGZvciBtb2Rp
ZmljYXRpb24/KS4NCg0KDQpPbmUga2V5IHJlcXVpcmVtZW50IG9mIFNVUEEgaXMgbmV0d29yay13
aWRlIG1vZGVsaW5nIGZvciBzdGFuZGFyZGl6aW5nLiBJbiB5b3VyIHdvcmssIGlzIHRoZXJlIGFs
c28gYSBzaW1pbGFyIHJlcXVpcmVtZW50PyBJIG1lYW4sIGRvIHlvdSBuZWVkIHRoZSBtb2RlbCBi
ZXR3ZWVuIGFwcCBhbmQgbmV0d29yayBlbGVtZW50IGJlIHN0YW5kYXJkaXplZD8NCg0KSGF2ZSB5
b3UgY29uc2lkZXJlZCB0aGUgbWFwcGluZyBtZWNoYW5pc20gZnJvbSBuZXR3b3JrLXdpZGUgbW9k
ZWwgdG8gZGV2aWNlIGxldmVsIGNvbmZpZ3VyYXRpb24/IFRoaXMgaXMgcGFydCBvZiB0aGUgd29y
ayBvZiBTVVBBLg0KDQpJIHdvdWxkIGFncmVlIHRoYXQgdGhlcmUgYXJlIG1hbnkgYmVuZWZpdHMg
b2YgdXNpbmcgZGlzdHJpYnV0ZWQgc29sdXRpb24sIGhvd2V2ZXIsIHRoZXJlIGlzIG9uZSBrZXkg
aXNzdWU6IGlmIHRoZSBkZWNpc2lvbnMgb3IgYWN0aW9ucyBmcm9tIGRpZmZlcmVudCBuZXR3b3Jr
IGVsZW1lbnRzIGFyZSBkaWZmZXJlbmNlIGFuZCBpbmNvbXBhdGlibGUsIGhvdyB0byBhdm9pZCB0
aGUgZmx1Y3R1YXRpb24/IElNSE8sIHRoaXMgbWF5IGJlIHNvbHZlZCBieSBzbGljaW5nIHRoZSBy
ZXNvdXJjZSBvciB1c2luZyBtdWx0aXBsZSBpbnN0YW5jZXMgZnJvbSB2aXJ0dWFsaXphdGlvbj8g
T3IgdXNpbmcgdGhlIGNvbnNpc3RlbmNlIGNoZWNrIG9mIGRpc3RyaWJ1dGVkIGRhdGFiYXNlPw0K
DQpTb21lIHdvcmRzIGZyb20gdGhpcyBkcmFmdCBtYXkgaW1wbHkgdGhlIHJlcXVpcmVtZW50IGZv
ciBleHRlbmRpbmcgdGhlIGV4aXN0aW5nIE5FVENPTkYuIEJ1dCBJ4oCZbSBub3Qgc3VyZS4gRG8g
eW91IHJlYWxseSB3YW50IHRoYXQ/DQoNCkhvcGUgaXQgaGVscHMuDQoNCg0KVGhhbmsgeW91LA0K
VGluYQ0KDQpGcm9tOiBTdXBhIFttYWlsdG86c3VwYS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh
bGYgT2YgVGluYSBUU09VDQpTZW50OiBTdW5kYXksIFNlcHRlbWJlciAyOCwgMjAxNCA5OjM4IEFN
DQpUbzogR2Vvcmdpb3MgS2FyYWdpYW5uaXM7IEVyaWMgVm9pdCAoZXZvaXQpOyBzdXBhQGlldGYu
b3JnDQpDYzogQWxleGFuZGVyIENsZW1tIChhbGV4KQ0KU3ViamVjdDogUmU6IFtTdXBhXSBbbmV0
bW9kXSAiMDAiIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtdm9pdC1uZXRtb2QtcGVlci1tb3VudC1y
ZXF1aXJlbWVudHMNCg0KDQpEZWFyIEVyaWMgZXQgYWwsDQoNCg0KDQpEaXN0cmlidXRlZCBEYXRh
IENlbnRlciBzZXJ2aWNlcyBhcmUgdHlwaWNhbCBjYXNlIGZvciBTVVBBLg0KDQpZb3VyIHN1Ym1p
c3Npb24gb2YgZHJhZnRzIGFyZSB2ZXJ5IHdlbGNvbWUuDQoNCg0KDQpZb3UgbWF5IGJlIGludGVy
ZXN0ZWQgdG8gbG9vayBhdCB0aGVzZS4NCmRyYWZ0LWNoZW5nLXN1cGEtZGRjLXVzZS1jYXNlcy0w
MDxodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWNoZW5nLXN1cGEtZGRjLXVz
ZS1jYXNlcy8+DQoNClVzZSBDYXNlcyBmb3IgRGlzdHJpYnV0ZWQgRGF0YSBDZW50ZXIgQXBwbGlj
YXRpb25zIGluIFNVUEENCg0KMjAxNC0wOS0xNw0KbmV3PGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZj
ZGlmZj91cmwyPWRyYWZ0LWNoZW5nLXN1cGEtZGRjLXVzZS1jYXNlcy0wMD4NCg0KSS1EIEV4aXN0
cw0KDQpkcmFmdC1jb250cmVyYXMtc3VwYS15YW5nLW5ldHdvcmstdG9wby0wMDxodHRwOi8vZGF0
YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWNvbnRyZXJhcy1zdXBhLXlhbmctbmV0d29yay10
b3BvLz4NCg0KQSBZQU5HIERhdGEgTW9kZWwgZm9yIE5ldHdvcmsgVG9wb2xvZ2llcw0KDQoyMDE0
LTA5LTE4DQpuZXc8aHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtY29udHJl
cmFzLXN1cGEteWFuZy1uZXR3b3JrLXRvcG8tMDA+DQoNCkktRCBFeGlzdHMNCg0KZHJhZnQtemFh
bG91ay1zdXBhLWNvbmZpZ3VyYXRpb24tbW9kZWwtMDA8aHR0cDovL2RhdGF0cmFja2VyLmlldGYu
b3JnL2RvYy9kcmFmdC16YWFsb3VrLXN1cGEtY29uZmlndXJhdGlvbi1tb2RlbC8+DQoNCllBTkcg
RGF0YSBNb2RlbCBmb3IgQ29uZmlndXJhdGlvbiBvZiBTaGFyZWQgVW5pZmllZCBQb2xpY3kgQXV0
b21hdGlvbiAoU1VQQSkNCg0KMjAxNC0wOS0yMg0KbmV3PGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZj
ZGlmZj91cmwyPWRyYWZ0LXphYWxvdWstc3VwYS1jb25maWd1cmF0aW9uLW1vZGVsLTAwPg0KDQpJ
LUQgRXhpc3RzDQoNCmRyYWZ0LXBlbnRpa291c2lzLXN1cGEtbWFwcGluZy0wMDxodHRwOi8vZGF0
YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXBlbnRpa291c2lzLXN1cGEtbWFwcGluZy8+DQoN
ClNVUEEgQ29uZmlndXJhdGlvbiBhbmQgUG9saWN5IE1hcHBpbmcNCg0KMjAxNC0wOS0yMw0KbmV3
PGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXBlbnRpa291c2lzLXN1cGEt
bWFwcGluZy0wMD4NCg0KSS1EIEV4aXN0cw0KDQoNCg0KDQoNCg0KDQpUaGFuayB5b3UsDQoNClRp
bmENCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBTdXBhIFttYWlsdG86
c3VwYS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgR2Vvcmdpb3MgS2FyYWdpYW5uaXMN
ClNlbnQ6IEZyaWRheSwgU2VwdGVtYmVyIDI2LCAyMDE0IDk6MzUgUE0NClRvOiBFcmljIFZvaXQg
KGV2b2l0KTsgc3VwYUBpZXRmLm9yZzxtYWlsdG86c3VwYUBpZXRmLm9yZz4NCkNjOiBBbGV4YW5k
ZXIgQ2xlbW0gKGFsZXgpDQpTdWJqZWN0OiBSZTogW1N1cGFdIFtuZXRtb2RdICIwMCIgTm90aWZp
Y2F0aW9uIGZvciBkcmFmdC12b2l0LW5ldG1vZC1wZWVyLW1vdW50LXJlcXVpcmVtZW50cw0KDQoN
Cg0KSGkgRXJpYywNCg0KDQoNClRoYW5rcyBmb3IgdGhlIGluZm9ybWF0aW9uLg0KDQpJIGhhdmUg
bm90IHJlYWQgeW91ciBkcmFmdCBpbiBkZXRhaWwsIGJ1dCBmcm9tIHlvdXIgZXhwbGFuYXRpb24s
IGl0IG1pZ2h0IGJlIHJlbGV2YW50IHRvIFNVUEEuDQoNCg0KDQpCZXN0IHJlZ2FyZHMsDQoNCkdl
b3JnaW9zDQoNCg0KDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KDQo+IEZyb206
IFN1cGEgW21haWx0bzpzdXBhLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBFcmljIFZv
aXQNCg0KPiAoZXZvaXQpDQoNCj4gU2VudDogRnJpZGF5LCBTZXB0ZW1iZXIgMjYsIDIwMTQgMjoz
MiBQTQ0KDQo+IFRvOiBzdXBhQGlldGYub3JnPG1haWx0bzpzdXBhQGlldGYub3JnPg0KDQo+IENj
OiBBbGV4YW5kZXIgQ2xlbW0gKGFsZXgpDQoNCj4gU3ViamVjdDogW1N1cGFdIEZXOiBbbmV0bW9k
XSAiMDAiIE5vdGlmaWNhdGlvbiBmb3INCg0KPiBkcmFmdC12b2l0LW5ldG1vZC1wZWVyLSBtb3Vu
dC1yZXF1aXJlbWVudHMNCg0KPg0KDQo+IEkganVzdCBsZWFybmVkIGFib3V0IFNVUEEsIGFuZCBi
YXNlZCBvbiB0aGUgZXZvbHZpbmcgY2hhcnRlciBpdCBzZWVtcw0KDQo+IHF1aXRlIHJlbGV2YW50
IHRvIGFuIGluZm9ybWF0aW9uYWwgZHJhZnQgc2V2ZXJhbCBvZiB1cyBzdWJtaXR0ZWQgdG8gTmV0
bW9kIHllc3RlcmRheS4NCg0KPiBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9k
cmFmdC12b2l0LW5ldG1vZC1wZWVyLW1vdW50LXJlcXVpDQoNCj4gcmVtZW50cy0NCg0KPiAwMC50
eHQNCg0KPg0KDQo+IE91ciBkcmFmdCBhZ2dyZWdhdGVzIHJlcXVpcmVtZW50cyB3ZSBoYXZlIHVu
Y292ZXJlZCBhcyB3ZSBoYXZlIGJ1aWx0DQoNCj4gc2V2ZXJhbCBuZXcgRGF0YSBDZW50ZXIgZWRn
ZSBzZXJ2aWNlcyB1cG9uIGFuIE9wZW4gRGF5bGlnaHQNCg0KPiBjb250cm9sbGVyLiAgV2UgYWxy
ZWFkeSBoYXZlIGEgd29ya2luZyBZQU5HIHNlcnZpY2UgbW9kZWwgZm9yIHR3byBvZiB0aGUgdHdv
IHNlcnZpY2VzIGluIHRoZSBkcmFmdC4NCg0KPiBJZiB0aGVyZSBpcyBpbnRlcmVzdCBoZXJlLCBJ
IGNvdWxkIHB1Ymxpc2ggdGhhdCBtb2RlbCBhcyB3ZWxsLg0KDQo+DQoNCj4gVGhhbmtzLA0KDQo+
IEVyaWMNCg0KPg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoNCj4gRnJvbTogbmV0
bW9kIFttYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBFcmljIFZv
aXQsDQoNCj4gU2VwdGVtYmVyIDI1LCAyMDE0IDY6MzggUE0NCg0KPg0KDQo+IFdlIGhhdmUgYmVl
biBkZXZlbG9waW5nIFNETiBhcHBsaWNhdGlvbnMgd2hpY2ggcmVxdWlyZSBxdWljaywNCg0KPiBp
dGVyYXRpdmUgYWNjZXNzIHRvIG9iamVjdHMgcmVwcmVzZW50aW5nIG5ldHdvcmsgYW5kIGRldmlj
ZQ0KDQo+IGFic3RyYWN0aW9ucy4gIFRoZXNlIG9iamVjdHMgaW5jbHVkZSBvbmVzIGF1dGhvcml0
YXRpdmVseSBvd25lZCBieSBhDQoNCj4gbG9jYWwgc3lzdGVtLCBhcyB3ZWxsIGFzIG9uZXMgcHJv
dmlkZWQgZnJvbSByZW1vdGUgZGF0YXN0b3Jlcy4gIFR3bw0KDQo+IHN1Y2ggYXBwbGljYXRpb25z
IHdlIGhhdmUgcHJvdG90eXBlZCBhcmUg4oCcQ2xvdWQgUG9saWNlcuKAnSBhbmQg4oCcRERvUw0K
DQo+IFRocmVzaG9sZGluZ+KAnS4gIChTZWUgbGlua3MgYmVsb3cgZm9yIG1vcmUgb24gdGhlc2Ug
YXBwcy4pDQoNCj4NCg0KPiBUaGUgZ29vZCBuZXdzIGlzIHRoYXQgd2UgZm91bmQgWUFORyBtb2Rl
bHMgYW5kIHN5bnRheCB0byBiZSBhIG5pY2UgZml0DQoNCj4gZm9yIHRoZXNlIGFwcGxpY2F0aW9u
cy4gICBIb3dldmVyIHdlIGhhdmUgYmVlbiB0cnlpbmcgdG8gY292ZXIgc2V2ZXJhbA0KDQo+IG1p
c3NpbmcNCg0KPiBlbGVtZW50czoNCg0KPg0KDQo+IE1pc3NpbmcgRWxlbWVudCAjMTogRGV2ZWxv
cGVyIFNpbXBsaWNpdHkgV2Ugd2FudGVkIGFwcGxpY2F0aW9ucyB0bw0KDQo+IGFjY2VzcyByZW1v
dGUgb2JqZWN0cyBmcm9tIGEgc2luZ2xlIGRhdGFzdG9yZSwgd2l0aG91dCBoYXZpbmcgdG8gaGF2
ZQ0KDQo+IHRoZSBhcHBsaWNhdGlvbnMgcGVlciBkaXJlY3RseSB3aXRoIHJlbW90ZSBkZXZpY2Vz
LiAgV2UgYWxzbyB3YW50ZWQNCg0KPiBjbGllbnRzIGFuZCBhcHBsaWNhdGlvbnMgdG8gYWNjZXNz
IGRhdGFzdG9yZXMgaW4gdGhlIHNhbWUgd2F5DQoNCj4gaW5kZXBlbmRlbnQgb2Ygd2hldGhlciB0
aGUgYXBwbGljYXRpb25zIHdlcmUgaG9zdGVkIG9uIGEgTmV0d29yayBFbGVtZW50IG9yIENvbnRy
b2xsZXIuDQoNCj4NCg0KPiBNaXNzaW5nIEVsZW1lbnQgIzI6IFdobyBvd25zIGFuIE9iamVjdD8N
Cg0KPiBBcHBsaWNhdGlvbnMgY2FuJ3QgdGVsbCB3aGljaCBOZXR3b3JrIEVsZW1lbnQgYWNyb3Nz
IGEgc2V0IG9mIGRldmljZXMNCg0KPiBpcyB0aGUgYXV0aG9yaXRhdGl2ZSBvd25lciBvZiBhIHBh
cnRpY3VsYXIgcmVwbGljYXRlZCBvYmplY3QuICBTaW5jZQ0KDQo+IHJlcGxpY2F0ZWQgZGF0YSBn
ZXRzIG91dCBvZiBzeW5jaCwgcmVzb2x1dGlvbiAvIGNvbnZlcmdlbmNlIGlzIGEgcHJvYmxlbS4N
Cg0KPg0KDQo+IE1pc3NpbmcgRWxlbWVudCAjMzogTWFpbnRhaW5pbmcgY2FjaGVzIG9mIHJlbW90
ZSBpbmZvcm1hdGlvbg0KDQo+IEFwcGxpY2F0aW9ucyBuZWVkIHRpbWVseSBhY2Nlc3MgdG8gcmVt
b3RlIGluZm9ybWF0aW9uLCB3aGljaCBjYW4NCg0KPiBuZWNlc3NpdGF0ZSB0aGUgaW50cm9kdWN0
aW9uIGNhY2hlIGluZnJhc3RydWN0dXJlLiAgTmV0Y29uZiBwcm92aWRlcw0KDQo+IGxpdHRsZSBz
dXBwb3J0IHRvIGZhY2lsaXRhdGUgdGhpcy4gIEZvciBleGFtcGxlLCBub3RpZmljYXRpb25zIGFy
ZSBub3QNCg0KPiBhIGdvb2QgbWF0Y2ggdG8gc3Vic2NyaWJlIHRvIHB1c2gtIHVwZGF0ZXMuDQoN
Cj4NCg0KPiBUbyBzb2x2ZSB0aGVzZSBwcm9ibGVtcywgd2UgbmVlZCB0ZWNobm9sb2d5IHNvbHV0
aW9ucyB3aGljaCB3b3JrDQoNCj4gZXF1YWxseSB3ZWxsIGZvciBib3RoIENvbnRyb2xsZXJzIGFu
ZCBOZXR3b3JrIEVsZW1lbnRzLiAgVGhlc2UNCg0KPiBzb2x1dGlvbnMgbXVzdCBleHBvc2UgbG9j
YWwgZGF0YXN0b3JlcyB3aGljaCBwcm92aWRlIGF1dGhvcml0YXRpdmUsDQoNCj4gY29uc29saWRh
dGVkIHZpZXdzIG9mIGRpc3RyaWJ1dGVkIG5ldHdvcmsgb2JqZWN0cy4gIFRoaXMgbXVzdCBiZSBk
b25lDQoNCj4gaW4gYSB3YXkgd2hpY2ggYWxsb3dzIHRoZSBhcHBsaWNhdGlvbnMgdG8gc2l0IGFu
eXdoZXJlIGluIHRoZSBuZXR3b3JrLA0KDQo+IG9uIHZhcmlvdXMgYWJzdHJhY3Rpb25zLCB3aGls
ZSBtYWludGFpbmluZyBkb21haW4gY29uc2lzdGVuY3kuIEFuZA0KDQo+IHRoaXMgbXVzdCBiZSBk
b25lIHdoaWxlIG1heGltaXppbmcgYXBwbGljYXRpb24gZGV2ZWxvcGVyIHNpbXBsaWNpdHkuDQoN
Cj4NCg0KPiBUaGlzIGRyYWZ0IGlzIGludGVuZGVkIHRvIHN0YXJ0IGFnZ3JlZ2F0aW5nIHJlcXVp
cmVtZW50cyBpbiB0aGlzDQoNCj4gc3BhY2UuICBUaGUgZHJhZnQgaXMgbm90IGNvbXBsZXRlLCBz
byBpdCB3b3VsZCBiZSBncmVhdCB0byBoZWFyIGZyb20NCg0KPiBvdGhlcnMgd2hvIGFyZSBpbnRl
cmVzdGVkIGluIGhlbHBpbmcgc28gdGhhdCB3ZSBlbmQgdXAgd2l0aCBhIG1vcmUgY29tcHJlaGVu
c2l2ZSBjb250ZXh0Lg0KDQo+DQoNCj4gU29sdXRpb25zIGRvIGV4aXN0IHdoaWNoIGNhbiBzb2x2
ZSBhIHN1YnNldCBvZiB0aGVzZSByZXF1aXJlbWVudHMuDQoNCj4gT25lIHBhcnRpY3VsYXIgdGVj
aG5vbG9neSB3ZSBoYXZlIGJ1aWx0IGlzIGtub3duIGFzIOKAnHBlZXIgbW91bnTigJ0uDQoNCj4g
UGVlciBtb3VudCBnaXZlcyB0aGUgYWJpbGl0eSB0byByZWZlcmVuY2UgWUFORyBpbmZvcm1hdGlv
biBpbnRvIGENCg0KPiBsb2NhbCBkYXRhc3RvcmUgZnJvbSByZW1vdGUgZGF0YXN0b3Jlcy4gIFRo
aXMgcHJvdmlkZXMgY2xpZW50DQoNCj4gYXBwbGljYXRpb25zIHdpdGggbG9jYWwgYWNjZXNzIHRv
IGluZm9ybWF0aW9uIHdoaWNoIG1pZ2h0IGJlDQoNCj4gdHJhbnNwYXJlbnRseSBmZWRlcmF0ZWQg
YWNyb3NzIG11bHRpcGxlIHN5c3RlbXMgYW5kIGRhdGFzdG9yZXMuICBJdA0KDQo+IGFsc28gcmV0
YWlucyBjbGVhciBvYmplY3Qgb3duZXJzaGlwIHRvIG1pbmltaXplIHN5bmNocm9uaXphdGlvbiBh
bmQNCg0KPiBpbnRlci1zeXN0ZW0gZGVwZW5kZW5jeSBpc3N1ZXMuICAgVGhlcmUgYXJlIGFscmVh
ZHkgaW1wbGVtZW50YXRpb25zIG9mDQoNCj4gdGhpcyB0ZWNobm9sb2d5LCBmb3IgZXhhbXBsZSwg
aW4gT3BlbiBEYXlsaWdodC4gIEhvd2V2ZXIsIHdlIGJlbGlldmUNCg0KPiByZXF1aXJlbWVudHMg
YW5kIHVzZSBjYXNlcyBmb3IgdGhpcyB0ZWNobm9sb2d5IGFwcGx5IGVxdWFsbHkgd2VsbCB0byBu
ZXR3b3JrIGRldmljZXMuDQoNCj4NCg0KPiBQbGVhc2UgbGV0IHVzIGtub3cgaWYgZWl0aGVyIHRo
ZSByZXF1aXJlbWVudHMgb3IgdGVjaG5vbG9neQ0KDQo+IHNwZWNpZmljYXRpb25zIGFyZSBwcm9i
bGVtIHlvdSBhcmUgaW50ZXJlc3RlZCBpbiBleHBsb3JpbmcuDQoNCj4NCg0KPiBUaGFua3MhDQoN
Cj4gRXJpYywgQWxleCwgUHJhYmhha2FyYSwgQW1iaWthLCBTaGFzaGkNCg0KPg0KDQo+IC0tLS0t
T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoNCj4gRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn
PG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+IFttYWlsdG86aW50ZXJuZXQtZHJhZnRz
QGlldGYub3JnXQ0KDQo+IFNlbnQ6IFRodXJzZGF5LCBTZXB0ZW1iZXIgMjUsIDIwMTQgODo0MSBB
TQ0KDQo+IFRvOiBQcmFiaGFrYXJhIFllbGxhaSAocHllbGxhaSk7IFNoYXNoaSBLdW1hciBCYW5z
YWwgKHNoYWJhbnNhKTsNCg0KPiBBbWJpa2EgUHJhc2FkIFRyaXBhdGh5IChhbWJ0cmlwYSk7IEFs
ZXhhbmRlciBDbGVtbSAoYWxleCk7IEVyaWMgVm9pdA0KDQo+IChldm9pdCk7IEFtYmlrYSBQcmFz
YWQgVHJpcGF0aHkgKGFtYnRyaXBhKTsgQWxleGFuZGVyIENsZW1tIChhbGV4KTsNCg0KPiBQcmFi
aGFrYXJhIFllbGxhaSAocHllbGxhaSk7IEVyaWMgVm9pdCAoZXZvaXQpOyBTaGFzaGkgS3VtYXIg
QmFuc2FsDQoNCj4gKHNoYWJhbnNhKQ0KDQo+IFN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNh
dGlvbiBmb3IgZHJhZnQtdm9pdC1uZXRtb2QtcGVlci1tb3VudC0NCg0KPiByZXF1aXJlbWVudHMt
MDAudHh0DQoNCj4NCg0KPg0KDQo+IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC12b2l0LW5l
dG1vZC1wZWVyLW1vdW50LXJlcXVpcmVtZW50cy0wMC50eHQNCg0KPiBoYXMgYmVlbiBzdWNjZXNz
ZnVsbHkgc3VibWl0dGVkIGJ5IEVyaWMgVm9pdCBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9z
aXRvcnkuDQoNCj4NCg0KPiBOYW1lOiAgICAgICAgICAgICAgICAgIGRyYWZ0LXZvaXQtbmV0bW9k
LXBlZXItbW91bnQtcmVxdWlyZW1lbnRzDQoNCj4gUmV2aXNpb246ICAgICAgICAgICAgICAwMA0K
DQo+IFRpdGxlOiAgICAgICAgICAgICAgICAgICAgIFJlcXVpcmVtZW50cyBmb3IgUGVlciBNb3Vu
dGluZyBvZiBZQU5HDQoNCj4gc3VidHJlZXMgZnJvbSBSZW1vdGUgRGF0YXN0b3JlcyBEb2N1bWVu
dCBkYXRlOiAyMDE0LTA5LTI1DQoNCj4gR3JvdXA6ICAgICAgICAgICAgICAgICAgSW5kaXZpZHVh
bCBTdWJtaXNzaW9uDQoNCj4gUGFnZXM6ICAgICAgICAgICAgICAgICAgMjINCg0KPiBVUkw6DQoN
Cj4gaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtdm9pdC1uZXRtb2Qt
cGVlci0NCg0KPiBtb3VudC1yZXF1aXJlbWVudHMtMDAudHh0DQoNCj4gU3RhdHVzOg0KDQo+IGh0
dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXZvaXQtbmV0bW9kLXBlZXItbW91
bnQtDQoNCj4gcmVxdWlyZW1lbnRzLw0KDQo+IEh0bWxpemVkOg0KDQo+IGh0dHA6Ly90b29scy5p
ZXRmLm9yZy9odG1sL2RyYWZ0LXZvaXQtbmV0bW9kLXBlZXItbW91bnQtDQoNCj4gcmVxdWlyZW1l
bnRzLTAwDQoNCj4NCg0KPg0KDQo+IEFic3RyYWN0Og0KDQo+ICAgIE5ldHdvcmsgaW50ZWdyYXRl
ZCBhcHBsaWNhdGlvbnMgd2FudCBzaW1wbGUgd2F5cyB0byBhY2Nlc3MgWUFORw0KDQo+ICAgIG9i
amVjdHMgYW5kIHN1YnRyZWVzIHdoaWNoIG1pZ2h0IGJlIGRpc3RyaWJ1dGVkIGFjcm9zcyBuZXR3
b3JrLg0KDQo+ICAgIFBlcmZvcm1hbmNlIHJlcXVpcmVtZW50cyBtYXkgZGljdGF0ZSB0aGF0IGl0
IGlzIHVuYWZmb3JkYWJsZSBmb3IgYQ0KDQo+ICAgIHN1YnNldCBvZiB0aGVzZSBhcHBsaWNhdGlv
bnMgdG8gZ28gdGhyb3VnaCBleGlzdGluZyBjZW50cmFsaXplZA0KDQo+ICAgIG1hbmFnZW1lbnQg
YnJva2Vycy4gIEZvciBzdWNoIGFwcGxpY2F0aW9ucywgZGV2ZWxvcG1lbnQgY29tcGxleGl0eQ0K
DQo+ICAgIG11c3QgYmUgbWluaW1pemVkLiAgU3BlY2lmaWMgYXNwZWN0cyBvZiBjb21wbGV4aXR5
IGRldmVsb3BlcnMgd2FudA0KDQo+IHRvDQoNCj4gICAgaWdub3JlIGluY2x1ZGU6DQoNCj4NCg0K
PiAgICBvICB3aGV0aGVyIGF1dGhvcml0YXRpdmUgaW5mb3JtYXRpb24gaXMgYWN0dWFsbHkgc291
cmNlZCBmcm9tDQoNCj4gcmVtb3RlDQoNCj4gICAgICAgZGF0YXN0b3JlcyAoYXMgd2VsbCBhcyBo
b3cgdG8gZ2V0IHRvIHRob3NlIGRhdGFzdG9yZXMpLA0KDQo+DQoNCj4gICAgbyAgd2hldGhlciBz
dWNoIGluZm9ybWF0aW9uIGhhcyBiZWVuIGxvY2FsbHkgY2FjaGVkIG9yIG5vdCwNCg0KPg0KDQo+
ICAgIG8gIHdoZXRoZXIgdGhlcmUgYXJlIHplcm8sIG9uZSwgb3IgbW9yZSBjb250cm9sbGVycyBh
c3NlcnRpbmcNCg0KPiAgICAgICBvd25lcnNoaXAgb2YgaW5mb3JtYXRpb24sIGFuZA0KDQo+DQoN
Cj4gICAgbyAgd2hldGhlciB0aGVyZSBhcmUgaW50ZXJhY3Rpb25zIHdpdGggb3RoZXIgYXBwbGlj
YXRpb25zDQoNCj4gICAgICAgY29uY3VycmVudGx5IHJ1bm5pbmcgZWxzZXdoZXJlDQoNCj4NCg0K
PiAgICBUaGUgc29sdXRpb24gcmVxdWlyZW1lbnRzIGRlc2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50
IGRldGFpbCB3aGF0IGlzDQoNCj4gICAgbmVlZGVkIHRvIHN1cHBvcnQgYXBwbGljYXRpb24gYWNj
ZXNzIHRvIGF1dGhvcml0YXRpdmUgbmV0d29yayBZQU5HDQoNCj4gICAgb2JqZWN0cyBmcm9tIGNv
bnRyb2xsZXJzIChzdGFyKSBvciBwZWVyaW5nIG5ldHdvcmsgZGV2aWNlcyAobWVzaCkNCg0KPiBp
bg0KDQo+ICAgIHN1Y2ggYSB3YXkgdG8gbWVldCB0aGVzZSBnb2Fscy4NCg0KPg0KDQo+DQoNCj4N
Cg0KPg0KDQo+DQoNCj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBt
aW51dGVzIGZyb20gdGhlIHRpbWUgb2YNCg0KPiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXpl
ZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNCj4N
Cg0KPiBUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo+DQoNCj4gX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KPiBuZXRtb2QgbWFpbGluZyBsaXN0DQoNCj4g
bmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+DQoNCj4gaHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg0KPiBfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQo+IFN1cGEgbWFpbGluZyBsaXN0DQoNCj4g
U3VwYUBpZXRmLm9yZzxtYWlsdG86U3VwYUBpZXRmLm9yZz4NCg0KPiBodHRwczovL3d3dy5pZXRm
Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N1cGENCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18NCg0KU3VwYSBtYWlsaW5nIGxpc3QNCg0KU3VwYUBpZXRmLm9y
ZzxtYWlsdG86U3VwYUBpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s
aXN0aW5mby9zdXBhDQo=

--_000_C0E0A32284495243BDE0AC8A066631A8185AA587szxeml557mbschi_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm
b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0
O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkFyaWFsIFVuaWNvZGUgTVMiOw0KCXBhbm9z
ZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2Fs
aWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2Zv
bnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9u
dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEg
MSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJGcmVlc3R5bGUgU2NyaXB0IjsN
CglwYW5vc2UtMTozIDggNCAyIDMgMiA1IDExIDQgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt
aWx5OiJcQEFyaWFsIFVuaWNvZGUgTVMiOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0
O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBk
aXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCXRl
eHQtYWxpZ246anVzdGlmeTsNCgl0ZXh0LWp1c3RpZnk6aW50ZXItaWRlb2dyYXBoOw0KCWZvbnQt
c2l6ZToxMC41cHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQphOmxp
bmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpi
bHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5
cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7
DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxh
aW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t
c3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0
b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuNXB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi
c2Fucy1zZXJpZiI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0
ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4
dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgl0ZXh0LWFs
aWduOmp1c3RpZnk7DQoJdGV4dC1qdXN0aWZ5OmludGVyLWlkZW9ncmFwaDsNCglmb250LXNpemU6
OC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpwLk1zb0xpc3RQ
YXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21z
by1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw
dDsNCgl0ZXh0LWFsaWduOmp1c3RpZnk7DQoJdGV4dC1qdXN0aWZ5OmludGVyLWlkZW9ncmFwaDsN
Cgl0ZXh0LWluZGVudDoyMS4wcHQ7DQoJZm9udC1zaXplOjEwLjVwdDsNCglmb250LWZhbWlseToi
Q2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5bGUt
bmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0
eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp
ZiI7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4
dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxv
b24gVGV4dCI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwt
cmVwbHk7DQoJZm9udC1mYW1pbHk6IkFyaWFsIFVuaWNvZGUgTVMiLCJzYW5zLXNlcmlmIjsNCglj
b2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v
bmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEy
LjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2
LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25z
ICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo3MjE1MTQyMzc7DQoJbXNvLWxpc3QtdHlwZTpo
eWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjM2NTU3NDY1NiA2NzY5ODcwMyA2NzY5ODcx
MyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2
NzY5ODcxNTt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ
bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjIxLjBwdDsNCgl0
ZXh0LWluZGVudDotMjEuMHB0O30NCm9sDQoJe21hcmdpbi1ib3R0b206MGNtO30NCnVsDQoJe21h
cmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8
bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFb
ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0i
ZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91
dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IlpILUNOIiBsaW5rPSJi
bHVlIiB2bGluaz0icHVycGxlIiBzdHlsZT0idGV4dC1qdXN0aWZ5LXRyaW06cHVuY3R1YXRpb24i
Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6IzFGNDk3
RCI+RGVhciBFcmljIGV0IGFsLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjoj
MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6IzFGNDk3
RCI+Tm93IEkgcmVhZCBkcmFmdC12b2l0LW5ldG1vZC1wZWVyLW1vdW50LXJlcXVpcmVtZW50cywg
aXQgaXMgdmVyeSBnb29kIGF0IGRlc2NyaWJpbmcgdGhlIHJlcXVpcmVtZW50cy48bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2NvbG9yOiMxRjQ5N0QiPkluIHRoaXMgZHJhZnQsIHR3byBvcHRpb25h
bCBhcmNoaXRlY3R1cmVzIHdlcmUgcHJvcG9zZWQ6IGEgY2VudHJhbGl6ZWQgb25lIHNpbWlsYXIg
dG8gU1VQQSBhbmQgYSBkaXN0cmlidXRlZCBvbmUgd2hpY2ggaXMgYWxzbyBjb21wYXRpYmxlIHdp
dGggU1VQQSAod2l0aCBhIGxpdHRsZSBleHRlbnNpb24gb2YgU1VQQQ0KIGNoYXJ0ZXIgYW5kIHNj
b3BlLCB3b3VsZCB5b3UgcGxlYXNlIHJldmlldyB0aGUgY2hhcnRlciBvZiBTVVBBIGFuZCBwcm92
aWRlIHNvbWUgdGV4dCBmb3IgbW9kaWZpY2F0aW9uPykuPG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoyMS4wcHQ7dGV4
dC1pbmRlbnQ6MGNtIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9y
OiMxRjQ5N0QiPk9uZSBrZXkgcmVxdWlyZW1lbnQgb2YgU1VQQSBpcyBuZXR3b3JrLXdpZGUgbW9k
ZWxpbmcgZm9yIHN0YW5kYXJkaXppbmcuIEluIHlvdXIgd29yaywgaXMgdGhlcmUgYWxzbyBhIHNp
bWlsYXIgcmVxdWlyZW1lbnQ/IEkgbWVhbiwgZG8geW91IG5lZWQgdGhlIG1vZGVsIGJldHdlZW4g
YXBwIGFuZCBuZXR3b3JrIGVsZW1lbnQNCiBiZSBzdGFuZGFyZGl6ZWQ/PG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtjb2xvcjojMUY0OTdEIj5IYXZlIHlvdSBjb25zaWRlcmVkIHRoZSBtYXBwaW5n
IG1lY2hhbmlzbSBmcm9tIG5ldHdvcmstd2lkZSBtb2RlbCB0byBkZXZpY2UgbGV2ZWwgY29uZmln
dXJhdGlvbj8gVGhpcyBpcyBwYXJ0IG9mIHRoZSB3b3JrIG9mIFNVUEEuPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtjb2xvcjojMUY0OTdEIj5JIHdvdWxkIGFncmVlIHRoYXQgdGhlcmUgYXJlIG1h
bnkgYmVuZWZpdHMgb2YgdXNpbmcgZGlzdHJpYnV0ZWQgc29sdXRpb24sIGhvd2V2ZXIsIHRoZXJl
IGlzIG9uZSBrZXkgaXNzdWU6IGlmIHRoZSBkZWNpc2lvbnMgb3IgYWN0aW9ucyBmcm9tIGRpZmZl
cmVudCBuZXR3b3JrIGVsZW1lbnRzIGFyZSBkaWZmZXJlbmNlDQogYW5kIGluY29tcGF0aWJsZSwg
aG93IHRvIGF2b2lkIHRoZSBmbHVjdHVhdGlvbj8gSU1ITywgdGhpcyBtYXkgYmUgc29sdmVkIGJ5
IHNsaWNpbmcgdGhlIHJlc291cmNlIG9yIHVzaW5nIG11bHRpcGxlIGluc3RhbmNlcyBmcm9tIHZp
cnR1YWxpemF0aW9uPyBPciB1c2luZyB0aGUgY29uc2lzdGVuY2UgY2hlY2sgb2YgZGlzdHJpYnV0
ZWQgZGF0YWJhc2U/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOiMxRjQ5N0Qi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjojMUY0OTdEIj5Tb21l
IHdvcmRzIGZyb20gdGhpcyBkcmFmdCBtYXkgaW1wbHkgdGhlIHJlcXVpcmVtZW50IGZvciBleHRl
bmRpbmcgdGhlIGV4aXN0aW5nIE5FVENPTkYuIEJ1dCBJ4oCZbSBub3Qgc3VyZS4gRG8geW91IHJl
YWxseSB3YW50IHRoYXQ/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOiMxRjQ5
N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjojMUY0OTdEIj5I
b3BlIGl0IGhlbHBzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjojMUY0OTdE
Ij4mbmJzcDsgPG86cD4NCjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6IzFGNDk3RCI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Zy
ZWVzdHlsZSBTY3JpcHQmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhbmsgeW91LDxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtGcmVlc3R5bGUgU2NyaXB0JnF1
b3Q7O2NvbG9yOiMxRjQ5N0QiPlRpbmE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCBVbmljb2RlIE1TJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K
PGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAx
LjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFs
aWduPSJsZWZ0IiBzdHlsZT0idGV4dC1hbGlnbjpsZWZ0Ij48Yj48c3BhbiBsYW5nPSJFTi1VUyIg
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIg
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDsiPiBTdXBhIFttYWlsdG86c3VwYS1ib3VuY2VzQGlldGYub3Jn
XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5UaW5hIFRTT1U8YnI+DQo8Yj5TZW50OjwvYj4gU3VuZGF5
LCBTZXB0ZW1iZXIgMjgsIDIwMTQgOTozOCBBTTxicj4NCjxiPlRvOjwvYj4gR2Vvcmdpb3MgS2Fy
YWdpYW5uaXM7IEVyaWMgVm9pdCAoZXZvaXQpOyBzdXBhQGlldGYub3JnPGJyPg0KPGI+Q2M6PC9i
PiBBbGV4YW5kZXIgQ2xlbW0gKGFsZXgpPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbU3VwYV0g
W25ldG1vZF0gJnF1b3Q7MDAmcXVvdDsgTm90aWZpY2F0aW9uIGZvciBkcmFmdC12b2l0LW5ldG1v
ZC1wZWVyLW1vdW50LXJlcXVpcmVtZW50czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K
PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxp
Z246bGVmdCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5EZWFyIEVyaWMgZXQg
YWwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g
bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q
bGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5EaXN0cmlidXRlZCBEYXRhIENlbnRlciBzZXJ2
aWNlcyBhcmUgdHlwaWNhbCBjYXNlIGZvciBTVVBBLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5Zb3VyIHN1Ym1pc3Npb24g
b2YgZHJhZnRzIGFyZSB2ZXJ5IHdlbGNvbWUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5Zb3Ug
bWF5IGJlIGludGVyZXN0ZWQgdG8gbG9vayBhdCB0aGVzZS4gJm5ic3A7Jm5ic3A7PG86cD48L286
cD48L3NwYW4+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBj
ZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiIHN0eWxlPSJtYXJnaW4tbGVmdDotMS4xNXB0
O2JvcmRlci1jb2xsYXBzZTpjb2xsYXBzZSI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgc3R5bGU9ImJv
cmRlci10b3A6c29saWQgIzdGN0Y3RiAxLjBwdDtib3JkZXItbGVmdDpzb2xpZCAjN0Y3RjdGIDEu
MHB0O2JvcmRlci1ib3R0b206bm9uZTtib3JkZXItcmlnaHQ6bm9uZTtwYWRkaW5nOi43NXB0IC43
NXB0IC43NXB0IC43NXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT
IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YSBocmVmPSJodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5v
cmcvZG9jL2RyYWZ0LWNoZW5nLXN1cGEtZGRjLXVzZS1jYXNlcy8iPmRyYWZ0LWNoZW5nLXN1cGEt
ZGRjLXVzZS1jYXNlcy0wMDwvYT4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8dGQg
c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgIzdGN0Y3RiAxLjBwdDtwYWRkaW5n
Oi43NXB0IC43NXB0IC43NXB0IC43NXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh
bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh
bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Vc2UgQ2FzZXMgZm9yIERpc3RyaWJ1dGVk
IERhdGEgQ2VudGVyIEFwcGxpY2F0aW9ucyBpbiBTVVBBPG86cD48L286cD48L3NwYW4+PC9wPg0K
PC90ZD4NCjx0ZCBjb2xzcGFuPSIyIiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp
ZCAjN0Y3RjdGIDEuMHB0O3BhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQiPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjIw
MTQtMDktMTcNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv
dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YSBocmVmPSJodHRwOi8vd3d3
LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1jaGVuZy1zdXBhLWRkYy11c2UtY2FzZXMtMDAi
Pm5ldzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPHRkIHN0eWxlPSJib3JkZXI6
bm9uZTtib3JkZXItdG9wOnNvbGlkICM3RjdGN0YgMS4wcHQ7cGFkZGluZzouNzVwdCAuNzVwdCAu
NzVwdCAuNzVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90OyI+SS1EIEV4aXN0cw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC90
ZD4NCjx0ZCBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjN0Y3RjdGIDEuMHB0
O3BhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQiPg0KPC90ZD4NCjx0ZCBzdHlsZT0iYm9y
ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjN0Y3RjdGIDEuMHB0O3BhZGRpbmc6Ljc1cHQgLjc1
cHQgLjc1cHQgLjc1cHQiPg0KPC90ZD4NCjx0ZCBzdHlsZT0iYm9yZGVyLXRvcDpzb2xpZCAjN0Y3
RjdGIDEuMHB0O2JvcmRlci1sZWZ0Om5vbmU7Ym9yZGVyLWJvdHRvbTpub25lO2JvcmRlci1yaWdo
dDpzb2xpZCAjN0Y3RjdGIDEuMHB0O3BhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQiPg0K
PC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv
bGlkICM3RjdGN0YgMS4wcHQ7cGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+
PGEgaHJlZj0iaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1jb250cmVyYXMt
c3VwYS15YW5nLW5ldHdvcmstdG9wby8iPmRyYWZ0LWNvbnRyZXJhcy1zdXBhLXlhbmctbmV0d29y
ay10b3BvLTAwPC9hPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjx0ZCBzdHlsZT0i
cGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+QSBZQU5HIERhdGEgTW9kZWwg
Zm9yIE5ldHdvcmsgVG9wb2xvZ2llczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8dGQg
Y29sc3Bhbj0iMiIgc3R5bGU9InBhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQiPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi
PjIwMTQtMDktMTgNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YSBocmVmPSJodHRwOi8v
d3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1jb250cmVyYXMtc3VwYS15YW5nLW5ldHdv
cmstdG9wby0wMCI+bmV3PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8dGQgc3R5
bGU9InBhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkktRCBFeGlzdHMNCjxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6Ljc1cHQgLjc1
cHQgLjc1cHQgLjc1cHQiPjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1
cHQgLjc1cHQiPjwvdGQ+DQo8dGQgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1yaWdodDpzb2xp
ZCAjN0Y3RjdGIDEuMHB0O3BhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQiPg0KPC90ZD4N
CjwvdHI+DQo8dHI+DQo8dGQgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICM3
RjdGN0YgMS4wcHQ7cGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGEgaHJl
Zj0iaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC16YWFsb3VrLXN1cGEtY29u
ZmlndXJhdGlvbi1tb2RlbC8iPmRyYWZ0LXphYWxvdWstc3VwYS1jb25maWd1cmF0aW9uLW1vZGVs
LTAwPC9hPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjx0ZCBjb2xzcGFuPSIyIiBz
dHlsZT0icGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+WUFORyBEYXRhIE1v
ZGVsIGZvciBDb25maWd1cmF0aW9uIG9mIFNoYXJlZCBVbmlmaWVkIFBvbGljeSBBdXRvbWF0aW9u
IChTVVBBKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8dGQgY29sc3Bhbj0iMyIgc3R5
bGU9InBhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjIwMTQtMDktMjINCjxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO
LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL3Jm
Y2RpZmY/dXJsMj1kcmFmdC16YWFsb3VrLXN1cGEtY29uZmlndXJhdGlvbi1tb2RlbC0wMCI+bmV3
PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8dGQgY29sc3Bhbj0iMiIgc3R5bGU9
ImJvcmRlcjpub25lO2JvcmRlci1yaWdodDpzb2xpZCAjN0Y3RjdGIDEuMHB0O3BhZGRpbmc6Ljc1
cHQgLjc1cHQgLjc1cHQgLjc1cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i
RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkktRCBFeGlzdHMNCjxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHN0eWxlPSJib3JkZXItdG9wOm5vbmU7Ym9y
ZGVyLWxlZnQ6c29saWQgIzdGN0Y3RiAxLjBwdDtib3JkZXItYm90dG9tOnNvbGlkICM3RjdGN0Yg
MS4wcHQ7Ym9yZGVyLXJpZ2h0Om5vbmU7cGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90OyI+PGEgaHJlZj0iaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1wZW50
aWtvdXNpcy1zdXBhLW1hcHBpbmcvIj5kcmFmdC1wZW50aWtvdXNpcy1zdXBhLW1hcHBpbmctMDA8
L2E+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPHRkIGNvbHNwYW49IjIiIHN0eWxl
PSJib3JkZXI6bm9uZTtib3JkZXItYm90dG9tOnNvbGlkICM3RjdGN0YgMS4wcHQ7cGFkZGluZzou
NzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n
PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+U1VQQSBDb25maWd1cmF0aW9uIGFuZCBQb2xp
Y3kgTWFwcGluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8dGQgY29sc3Bhbj0iMyIg
c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1ib3R0b206c29saWQgIzdGN0Y3RiAxLjBwdDtwYWRk
aW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtB
cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4yMDE0LTA5LTIzDQo8bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90OyI+PGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3Vy
bDI9ZHJhZnQtcGVudGlrb3VzaXMtc3VwYS1tYXBwaW5nLTAwIj5uZXc8L2E+PG86cD48L286cD48
L3NwYW4+PC9wPg0KPC90ZD4NCjx0ZCBjb2xzcGFuPSIyIiBzdHlsZT0iYm9yZGVyLXRvcDpub25l
O2JvcmRlci1sZWZ0Om5vbmU7Ym9yZGVyLWJvdHRvbTpzb2xpZCAjN0Y3RjdGIDEuMHB0O2JvcmRl
ci1yaWdodDpzb2xpZCAjN0Y3RjdGIDEuMHB0O3BhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1
cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDsiPkktRCBFeGlzdHMNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3Ry
Pg0KPHRyPg0KPHRkIHdpZHRoPSIyNTUiIHN0eWxlPSJ3aWR0aDoxOTEuMjVwdDtwYWRkaW5nOjBj
bSAwY20gMGNtIDBjbSI+PC90ZD4NCjx0ZCB3aWR0aD0iMzE1IiBzdHlsZT0id2lkdGg6MjM2LjI1
cHQ7cGFkZGluZzowY20gMGNtIDBjbSAwY20iPjwvdGQ+DQo8dGQgd2lkdGg9IjM4IiBzdHlsZT0i
d2lkdGg6MjguNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj48L3RkPg0KPHRkIHdpZHRoPSIz
MyIgc3R5bGU9IndpZHRoOjI0Ljc1cHQ7cGFkZGluZzowY20gMGNtIDBjbSAwY20iPjwvdGQ+DQo8
dGQgd2lkdGg9IjUzIiBzdHlsZT0id2lkdGg6MzkuNzVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDBj
bSI+PC90ZD4NCjx0ZCB3aWR0aD0iMiIgc3R5bGU9IndpZHRoOjEuNXB0O3BhZGRpbmc6MGNtIDBj
bSAwY20gMGNtIj48L3RkPg0KPHRkIHdpZHRoPSIyNiIgc3R5bGU9IndpZHRoOjE5LjVwdDtwYWRk
aW5nOjBjbSAwY20gMGNtIDBjbSI+PC90ZD4NCjx0ZCB3aWR0aD0iMjYiIHN0eWxlPSJ3aWR0aDox
OS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSAwY20iPjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwv
dGFibGU+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFu
Zz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp
blRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGFuayB5b3UsPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRpbmE8bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1V
UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+
PHNwYW4gbGFuZz0iRU4tVVMiPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTog
U3VwYSBbPGEgaHJlZj0ibWFpbHRvOnN1cGEtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnN1cGEt
Ym91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBHZW9yZ2lvcyBLYXJhZ2lhbm5pczxi
cj4NClNlbnQ6IEZyaWRheSwgU2VwdGVtYmVyIDI2LCAyMDE0IDk6MzUgUE08YnI+DQpUbzogRXJp
YyBWb2l0IChldm9pdCk7IDxhIGhyZWY9Im1haWx0bzpzdXBhQGlldGYub3JnIj5zdXBhQGlldGYu
b3JnPC9hPjxicj4NCkNjOiBBbGV4YW5kZXIgQ2xlbW0gKGFsZXgpPGJyPg0KU3ViamVjdDogUmU6
IFtTdXBhXSBbbmV0bW9kXSAmcXVvdDswMCZxdW90OyBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXZv
aXQtbmV0bW9kLXBlZXItbW91bnQtcmVxdWlyZW1lbnRzPG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVT
Ij5IaSBFcmljLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi
PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+VGhhbmtzIGZvciB0aGUgaW5mb3Jt
YXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw
YW4gbGFuZz0iRU4tVVMiPkkgaGF2ZSBub3QgcmVhZCB5b3VyIGRyYWZ0IGluIGRldGFpbCwgYnV0
IGZyb20geW91ciBleHBsYW5hdGlvbiwgaXQgbWlnaHQgYmUgcmVsZXZhbnQgdG8gU1VQQS48bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJF
Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4
dCI+PHNwYW4gbGFuZz0iRU4tVVMiPkJlc3QgcmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+R2Vvcmdpb3M8bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJF
Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4
dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IC0tLS0tT3JpZ2luYWwg
TWVzc2FnZS0tLS0tPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4
dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgRnJvbTogU3VwYSBbPGEgaHJlZj0ibWFpbHRvOnN1
cGEtYm91bmNlc0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1k
ZWNvcmF0aW9uOm5vbmUiPm1haWx0bzpzdXBhLWJvdW5jZXNAaWV0Zi5vcmc8L3NwYW4+PC9hPl0g
T24gQmVoYWxmIE9mIEVyaWMgVm9pdA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgKGV2b2l0KTxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4m
Z3Q7IFNlbnQ6IEZyaWRheSwgU2VwdGVtYmVyIDI2LCAyMDE0IDI6MzIgUE08bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0
OyBUbzogPGEgaHJlZj0ibWFpbHRvOnN1cGFAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjp3
aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5zdXBhQGlldGYub3JnPC9zcGFuPjwvYT48
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5n
PSJFTi1VUyI+Jmd0OyBDYzogQWxleGFuZGVyIENsZW1tIChhbGV4KTxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IFN1
YmplY3Q6IFtTdXBhXSBGVzogW25ldG1vZF0gJnF1b3Q7MDAmcXVvdDsgTm90aWZpY2F0aW9uIGZv
cg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g
bGFuZz0iRU4tVVMiPiZndDsgZHJhZnQtdm9pdC1uZXRtb2QtcGVlci0gbW91bnQtcmVxdWlyZW1l
bnRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g
bGFuZz0iRU4tVVMiPiZndDsgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs
YWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgSSBqdXN0IGxlYXJuZWQgYWJvdXQgU1VQ
QSwgYW5kIGJhc2VkIG9uIHRoZSBldm9sdmluZyBjaGFydGVyIGl0IHNlZW1zDQo8bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+
Jmd0OyBxdWl0ZSByZWxldmFudCB0byBhbiBpbmZvcm1hdGlvbmFsIGRyYWZ0IHNldmVyYWwgb2Yg
dXMgc3VibWl0dGVkIHRvIE5ldG1vZCB5ZXN0ZXJkYXkuPG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgPGEgaHJlZj0i
aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtdm9pdC1uZXRtb2QtcGVl
ci1tb3VudC1yZXF1aSI+DQo8c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29y
YXRpb246bm9uZSI+aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtdm9p
dC1uZXRtb2QtcGVlci1tb3VudC1yZXF1aTwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgcmVtZW50
cy08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBs
YW5nPSJFTi1VUyI+Jmd0OyAwMC50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyA8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBPdXIg
ZHJhZnQgYWdncmVnYXRlcyByZXF1aXJlbWVudHMgd2UgaGF2ZSB1bmNvdmVyZWQgYXMgd2UgaGF2
ZSBidWlsdA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+
PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgc2V2ZXJhbCBuZXcgRGF0YSBDZW50ZXIgZWRnZSBzZXJ2
aWNlcyB1cG9uIGFuIE9wZW4gRGF5bGlnaHQNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IGNvbnRyb2xsZXIuJm5i
c3A7IFdlIGFscmVhZHkgaGF2ZSBhIHdvcmtpbmcgWUFORyBzZXJ2aWNlIG1vZGVsIGZvciB0d28g
b2YgdGhlIHR3byBzZXJ2aWNlcyBpbiB0aGUgZHJhZnQuPG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgSWYgdGhlcmUg
aXMgaW50ZXJlc3QgaGVyZSwgSSBjb3VsZCBwdWJsaXNoIHRoYXQgbW9kZWwgYXMgd2VsbC48bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJF
Ti1VUyI+Jmd0OyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0
Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBUaGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgRXJpYzxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVO
LVVTIj4mZ3Q7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi
PjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4t
VVMiPiZndDsgRnJvbTogbmV0bW9kIFs8YSBocmVmPSJtYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0
Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25l
Ij5tYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc8L3NwYW4+PC9hPl0gT24gQmVoYWxmIE9m
IEVyaWMgVm9pdCwNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl
eHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IFNlcHRlbWJlciAyNSwgMjAxNCA2OjM4IFBNPG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0i
RU4tVVMiPiZndDsgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4
dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgV2UgaGF2ZSBiZWVuIGRldmVsb3BpbmcgU0ROIGFw
cGxpY2F0aW9ucyB3aGljaCByZXF1aXJlIHF1aWNrLA0KPG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgaXRlcmF0aXZl
IGFjY2VzcyB0byBvYmplY3RzIHJlcHJlc2VudGluZyBuZXR3b3JrIGFuZCBkZXZpY2UNCjxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVO
LVVTIj4mZ3Q7IGFic3RyYWN0aW9ucy48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm
b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxh
bmc9IkVOLVVTIj4gVGhlc2Ugb2JqZWN0cyBpbmNsdWRlIG9uZXMgYXV0aG9yaXRhdGl2ZWx5IG93
bmVkIGJ5IGENCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi
PjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IGxvY2FsIHN5c3RlbSwgYXMgd2VsbCBhcyBvbmVzIHBy
b3ZpZGVkIGZyb20gcmVtb3RlIGRhdGFzdG9yZXMuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBz
dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48
c3BhbiBsYW5nPSJFTi1VUyI+IFR3bw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgc3VjaCBhcHBsaWNhdGlvbnMg
d2UgaGF2ZSBwcm90b3R5cGVkIGFyZQ0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i
Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPuKAnDwvc3Bhbj48c3BhbiBsYW5n
PSJFTi1VUyI+Q2xvdWQgUG9saWNlcjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv
bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij7igJ08L3NwYW4+PHNwYW4gbGFuZz0i
RU4tVVMiPiBhbmQNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5
OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij7igJw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPkRE
b1MNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu
IGxhbmc9IkVOLVVTIj4mZ3Q7IFRocmVzaG9sZGluZzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIg
c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij7igJ08L3NwYW4+PHNw
YW4gbGFuZz0iRU4tVVMiPi4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt
ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0i
RU4tVVMiPihTZWUgbGlua3MgYmVsb3cgZm9yIG1vcmUgb24gdGhlc2UgYXBwcy4pPG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMi
PiZndDsgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw
YW4gbGFuZz0iRU4tVVMiPiZndDsgVGhlIGdvb2QgbmV3cyBpcyB0aGF0IHdlIGZvdW5kIFlBTkcg
bW9kZWxzIGFuZCBzeW50YXggdG8gYmUgYSBuaWNlIGZpdA0KPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgZm9yIHRo
ZXNlIGFwcGxpY2F0aW9ucy48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZh
bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7PC9zcGFuPjxzcGFuIGxh
bmc9IkVOLVVTIj4gSG93ZXZlciB3ZSBoYXZlIGJlZW4gdHJ5aW5nIHRvIGNvdmVyIHNldmVyYWwN
CjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxh
bmc9IkVOLVVTIj4mZ3Q7IG1pc3Npbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBlbGVtZW50czo8bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+
Jmd0OyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh
biBsYW5nPSJFTi1VUyI+Jmd0OyBNaXNzaW5nIEVsZW1lbnQgIzE6IERldmVsb3BlciBTaW1wbGlj
aXR5IFdlIHdhbnRlZCBhcHBsaWNhdGlvbnMgdG8NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IGFjY2VzcyByZW1v
dGUgb2JqZWN0cyBmcm9tIGEgc2luZ2xlIGRhdGFzdG9yZSwgd2l0aG91dCBoYXZpbmcgdG8gaGF2
ZQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g
bGFuZz0iRU4tVVMiPiZndDsgdGhlIGFwcGxpY2F0aW9ucyBwZWVyIGRpcmVjdGx5IHdpdGggcmVt
b3RlIGRldmljZXMuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6
JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+
IFdlIGFsc28gd2FudGVkDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh
aW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBjbGllbnRzIGFuZCBhcHBsaWNhdGlvbnMg
dG8gYWNjZXNzIGRhdGFzdG9yZXMgaW4gdGhlIHNhbWUgd2F5DQo8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBpbmRl
cGVuZGVudCBvZiB3aGV0aGVyIHRoZSBhcHBsaWNhdGlvbnMgd2VyZSBob3N0ZWQgb24gYSBOZXR3
b3JrIEVsZW1lbnQgb3IgQ29udHJvbGxlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyA8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBN
aXNzaW5nIEVsZW1lbnQgIzI6IFdobyBvd25zIGFuIE9iamVjdD88bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBBcHBs
aWNhdGlvbnMgY2FuJ3QgdGVsbCB3aGljaCBOZXR3b3JrIEVsZW1lbnQgYWNyb3NzIGEgc2V0IG9m
IGRldmljZXMNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi
PjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IGlzIHRoZSBhdXRob3JpdGF0aXZlIG93bmVyIG9mIGEg
cGFydGljdWxhciByZXBsaWNhdGVkIG9iamVjdC48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0
eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxz
cGFuIGxhbmc9IkVOLVVTIj4gU2luY2UNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IHJlcGxpY2F0ZWQgZGF0YSBn
ZXRzIG91dCBvZiBzeW5jaCwgcmVzb2x1dGlvbiAvIGNvbnZlcmdlbmNlIGlzIGEgcHJvYmxlbS48
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5n
PSJFTi1VUyI+Jmd0OyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U
ZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBNaXNzaW5nIEVsZW1lbnQgIzM6IE1haW50YWlu
aW5nIGNhY2hlcyBvZiByZW1vdGUgaW5mb3JtYXRpb24NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IEFwcGxpY2F0
aW9ucyBuZWVkIHRpbWVseSBhY2Nlc3MgdG8gcmVtb3RlIGluZm9ybWF0aW9uLCB3aGljaCBjYW4N
CjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxh
bmc9IkVOLVVTIj4mZ3Q7IG5lY2Vzc2l0YXRlIHRoZSBpbnRyb2R1Y3Rpb24gY2FjaGUgaW5mcmFz
dHJ1Y3R1cmUuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1
b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+IE5l
dGNvbmYgcHJvdmlkZXMNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp
blRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IGxpdHRsZSBzdXBwb3J0IHRvIGZhY2lsaXRh
dGUgdGhpcy48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVv
dDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj4gRm9y
IGV4YW1wbGUsIG5vdGlmaWNhdGlvbnMgYXJlIG5vdA0KPG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgYSBnb29kIG1h
dGNoIHRvIHN1YnNjcmliZSB0byBwdXNoLSB1cGRhdGVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IDxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVT
Ij4mZ3Q7IFRvIHNvbHZlIHRoZXNlIHByb2JsZW1zLCB3ZSBuZWVkIHRlY2hub2xvZ3kgc29sdXRp
b25zIHdoaWNoIHdvcmsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp
blRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IGVxdWFsbHkgd2VsbCBmb3IgYm90aCBDb250
cm9sbGVycyBhbmQgTmV0d29yayBFbGVtZW50cy48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0
eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxz
cGFuIGxhbmc9IkVOLVVTIj4gVGhlc2UNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IHNvbHV0aW9ucyBtdXN0IGV4
cG9zZSBsb2NhbCBkYXRhc3RvcmVzIHdoaWNoIHByb3ZpZGUgYXV0aG9yaXRhdGl2ZSwNCjxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVO
LVVTIj4mZ3Q7IGNvbnNvbGlkYXRlZCB2aWV3cyBvZiBkaXN0cmlidXRlZCBuZXR3b3JrIG9iamVj
dHMuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291
cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+IFRoaXMgbXVz
dCBiZSBkb25lDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0
Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBpbiBhIHdheSB3aGljaCBhbGxvd3MgdGhlIGFwcGxp
Y2F0aW9ucyB0byBzaXQgYW55d2hlcmUgaW4gdGhlIG5ldHdvcmssDQo8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBv
biB2YXJpb3VzIGFic3RyYWN0aW9ucywgd2hpbGUgbWFpbnRhaW5pbmcgZG9tYWluIGNvbnNpc3Rl
bmN5LiBBbmQNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi
PjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IHRoaXMgbXVzdCBiZSBkb25lIHdoaWxlIG1heGltaXpp
bmcgYXBwbGljYXRpb24gZGV2ZWxvcGVyIHNpbXBsaWNpdHkuPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgPG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4t
VVMiPiZndDsgVGhpcyBkcmFmdCBpcyBpbnRlbmRlZCB0byBzdGFydCBhZ2dyZWdhdGluZyByZXF1
aXJlbWVudHMgaW4gdGhpcw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs
YWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgc3BhY2UuPC9zcGFuPjxzcGFuIGxhbmc9
IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNw
Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+IFRoZSBkcmFmdCBpcyBub3QgY29tcGxldGUsIHNv
IGl0IHdvdWxkIGJlIGdyZWF0IHRvIGhlYXIgZnJvbQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgb3RoZXJzIHdo
byBhcmUgaW50ZXJlc3RlZCBpbiBoZWxwaW5nIHNvIHRoYXQgd2UgZW5kIHVwIHdpdGggYSBtb3Jl
IGNvbXByZWhlbnNpdmUgY29udGV4dC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyA8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBTb2x1
dGlvbnMgZG8gZXhpc3Qgd2hpY2ggY2FuIHNvbHZlIGEgc3Vic2V0IG9mIHRoZXNlIHJlcXVpcmVt
ZW50cy48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD
b3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj4NCjxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVO
LVVTIj4mZ3Q7IE9uZSBwYXJ0aWN1bGFyIHRlY2hub2xvZ3kgd2UgaGF2ZSBidWlsdCBpcyBrbm93
biBhcw0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7
Q291cmllciBOZXcmcXVvdDsiPuKAnDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+cGVlciBtb3Vu
dDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJp
ZXIgTmV3JnF1b3Q7Ij7igJ08L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPi48L3NwYW4+PHNwYW4g
bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+
Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IFBlZXIgbW91
bnQgZ2l2ZXMgdGhlIGFiaWxpdHkgdG8gcmVmZXJlbmNlIFlBTkcgaW5mb3JtYXRpb24gaW50byBh
DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBs
YW5nPSJFTi1VUyI+Jmd0OyBsb2NhbCBkYXRhc3RvcmUgZnJvbSByZW1vdGUgZGF0YXN0b3Jlcy48
L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVy
IE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj4gVGhpcyBwcm92aWRl
cyBjbGllbnQNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi
PjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IGFwcGxpY2F0aW9ucyB3aXRoIGxvY2FsIGFjY2VzcyB0
byBpbmZvcm1hdGlvbiB3aGljaCBtaWdodCBiZQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgdHJhbnNwYXJlbnRs
eSBmZWRlcmF0ZWQgYWNyb3NzIG11bHRpcGxlIHN5c3RlbXMgYW5kIGRhdGFzdG9yZXMuPC9zcGFu
PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm
cXVvdDsiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+IEl0DQo8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0
OyBhbHNvIHJldGFpbnMgY2xlYXIgb2JqZWN0IG93bmVyc2hpcCB0byBtaW5pbWl6ZSBzeW5jaHJv
bml6YXRpb24gYW5kDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U
ZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBpbnRlci1zeXN0ZW0gZGVwZW5kZW5jeSBpc3N1
ZXMuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291
cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+IFRo
ZXJlIGFyZSBhbHJlYWR5IGltcGxlbWVudGF0aW9ucyBvZg0KPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgdGhpcyB0
ZWNobm9sb2d5LCBmb3IgZXhhbXBsZSwgaW4gT3BlbiBEYXlsaWdodC48L3NwYW4+PHNwYW4gbGFu
Zz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i
c3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj4gSG93ZXZlciwgd2UgYmVsaWV2ZQ0KPG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4t
VVMiPiZndDsgcmVxdWlyZW1lbnRzIGFuZCB1c2UgY2FzZXMgZm9yIHRoaXMgdGVjaG5vbG9neSBh
cHBseSBlcXVhbGx5IHdlbGwgdG8gbmV0d29yayBkZXZpY2VzLjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IDxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVO
LVVTIj4mZ3Q7IFBsZWFzZSBsZXQgdXMga25vdyBpZiBlaXRoZXIgdGhlIHJlcXVpcmVtZW50cyBv
ciB0ZWNobm9sb2d5DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U
ZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBzcGVjaWZpY2F0aW9ucyBhcmUgcHJvYmxlbSB5
b3UgYXJlIGludGVyZXN0ZWQgaW4gZXhwbG9yaW5nLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IDxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4m
Z3Q7IFRoYW5rcyE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0
Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBFcmljLCBBbGV4LCBQcmFiaGFrYXJhLCBBbWJpa2Es
IFNoYXNoaTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz
cGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2Fn
ZS0tLS0tPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw
YW4gbGFuZz0iRU4tVVMiPiZndDsgRnJvbTogPGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0
c0BpZXRmLm9yZyI+DQo8c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRp
b246bm9uZSI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9zcGFuPjwvYT4gWzxhIGhyZWY9Im1h
aWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0
ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5tYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn
PC9zcGFuPjwvYT5dPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4
dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgU2VudDogVGh1cnNkYXksIFNlcHRlbWJlciAyNSwg
MjAxNCA4OjQxIEFNPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4
dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgVG86IFByYWJoYWthcmEgWWVsbGFpIChweWVsbGFp
KTsgU2hhc2hpIEt1bWFyIEJhbnNhbCAoc2hhYmFuc2EpOw0KPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgQW1iaWth
IFByYXNhZCBUcmlwYXRoeSAoYW1idHJpcGEpOyBBbGV4YW5kZXIgQ2xlbW0gKGFsZXgpOyBFcmlj
IFZvaXQNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz
cGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IChldm9pdCk7IEFtYmlrYSBQcmFzYWQgVHJpcGF0aHkgKGFt
YnRyaXBhKTsgQWxleGFuZGVyIENsZW1tIChhbGV4KTsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IFByYWJoYWth
cmEgWWVsbGFpIChweWVsbGFpKTsgRXJpYyBWb2l0IChldm9pdCk7IFNoYXNoaSBLdW1hciBCYW5z
YWwNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu
IGxhbmc9IkVOLVVTIj4mZ3Q7IChzaGFiYW5zYSk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBTdWJqZWN0OiBOZXcg
VmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXZvaXQtbmV0bW9kLXBlZXItbW91bnQtDQo8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5n
PSJFTi1VUyI+Jmd0OyByZXF1aXJlbWVudHMtMDAudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgPG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMi
PiZndDsgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw
YW4gbGFuZz0iRU4tVVMiPiZndDsgQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXZvaXQtbmV0
bW9kLXBlZXItbW91bnQtcmVxdWlyZW1lbnRzLTAwLnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IGhhcyBiZWVu
IHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgRXJpYyBWb2l0IGFuZCBwb3N0ZWQgdG8gdGhlIElF
VEYgcmVwb3NpdG9yeS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U
ZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBOYW1lOjwvc3Bhbj48
c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1
b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+
PHNwYW4gbGFuZz0iRU4tVVMiPiBkcmFmdC12b2l0LW5ldG1vZC1wZWVyLW1vdW50LXJlcXVpcmVt
ZW50czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu
IGxhbmc9IkVOLVVTIj4mZ3Q7IFJldmlzaW9uOjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5
bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPiAwMDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IFRpdGxlOjwv
c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg
TmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPiBSZXF1aXJlbWVudHMg
Zm9yIFBlZXIgTW91bnRpbmcgb2YgWUFORw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgc3VidHJlZXMgZnJvbSBS
ZW1vdGUgRGF0YXN0b3JlcyBEb2N1bWVudCBkYXRlOiAyMDE0LTA5LTI1PG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsg
R3JvdXA6PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7
Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+IEluZGl2aWR1YWwgU3VibWlzc2lvbjxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9
IkVOLVVTIj4mZ3Q7IFBhZ2VzOjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt
ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPiAyMjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVT
Ij4mZ3Q7IFVSTDo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTom
cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT
Ij4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu
IGxhbmc9IkVOLVVTIj4mZ3Q7IDxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQt
ZHJhZnRzL2RyYWZ0LXZvaXQtbmV0bW9kLXBlZXItIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5k
b3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5odHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0
LWRyYWZ0cy9kcmFmdC12b2l0LW5ldG1vZC1wZWVyLTwvc3Bhbj48L2E+PG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsg
bW91bnQtcmVxdWlyZW1lbnRzLTAwLnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IFN0YXR1czo8L3NwYW4+PHNw
YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90
OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFu
PjxzcGFuIGxhbmc9IkVOLVVTIj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vZGF0
YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXZvaXQtbmV0bW9kLXBlZXItbW91bnQtIj4NCjxz
cGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5odHRwczov
L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC12b2l0LW5ldG1vZC1wZWVyLW1vdW50LTwv
c3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+
PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgcmVxdWlyZW1lbnRzLzxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IEh0bWxp
emVkOjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nv
dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3Nw
YW4+PHNwYW4gbGFuZz0iRU4tVVMiPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgPGEgaHJlZj0iaHR0cDovL3Rv
b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdm9pdC1uZXRtb2QtcGVlci1tb3VudC0iPg0KPHNwYW4g
c3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmh0dHA6Ly90b29s
cy5pZXRmLm9yZy9odG1sL2RyYWZ0LXZvaXQtbmV0bW9kLXBlZXItbW91bnQtPC9zcGFuPjwvYT48
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5n
PSJFTi1VUyI+Jmd0OyByZXF1aXJlbWVudHMtMDA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyA8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0
OyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBs
YW5nPSJFTi1VUyI+Jmd0OyBBYnN0cmFjdDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyA8L3NwYW4+PHNwYW4gbGFu
Zz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i
c3A7Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj4gTmV0d29yayBpbnRlZ3JhdGVkIGFw
cGxpY2F0aW9ucyB3YW50IHNpbXBsZSB3YXlzIHRvIGFjY2VzcyBZQU5HPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsg
PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmll
ciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+IG9iamVj
dHMgYW5kIHN1YnRyZWVzIHdoaWNoIG1pZ2h0IGJlIGRpc3RyaWJ1dGVkIGFjcm9zcyBuZXR3b3Jr
LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxh
bmc9IkVOLVVTIj4mZ3Q7IDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt
aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDs8L3NwYW4+PHNwYW4gbGFu
Zz0iRU4tVVMiPiBQZXJmb3JtYW5jZSByZXF1aXJlbWVudHMgbWF5IGRpY3RhdGUgdGhhdCBpdCBp
cyB1bmFmZm9yZGFibGUgZm9yIGE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
UGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyA8L3NwYW4+PHNwYW4gbGFuZz0iRU4t
VVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5i
c3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj4gc3Vic2V0IG9mIHRoZXNlIGFwcGxpY2F0aW9u
cyB0byBnbyB0aHJvdWdoIGV4aXN0aW5nIGNlbnRyYWxpemVkPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgPC9zcGFu
PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm
cXVvdDsiPiZuYnNwOyZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+IG1hbmFnZW1lbnQg
YnJva2Vycy48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVv
dDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj4gRm9y
IHN1Y2ggYXBwbGljYXRpb25zLA0KIGRldmVsb3BtZW50IGNvbXBsZXhpdHk8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0
OyA8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3Vy
aWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj4gbXVz
dCBiZSBtaW5pbWl6ZWQuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1p
bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V
UyI+IFNwZWNpZmljIGFzcGVjdHMNCiBvZiBjb21wbGV4aXR5IGRldmVsb3BlcnMgd2FudCA8bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJF
Ti1VUyI+Jmd0OyB0bzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl
eHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5
bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDs8L3Nw
YW4+PHNwYW4gbGFuZz0iRU4tVVMiPiBpZ25vcmUgaW5jbHVkZTo8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyA8bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJF
Ti1VUyI+Jmd0OyA8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTom
cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVO
LVVTIj4gbzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90
O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPiB3aGV0
aGVyIGF1dGhvcml0YXRpdmUgaW5mb3JtYXRpb24NCiBpcyBhY3R1YWxseSBzb3VyY2VkIGZyb20g
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFu
Zz0iRU4tVVMiPiZndDsgcmVtb3RlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgPC9zcGFuPjxzcGFuIGxhbmc9IkVO
LVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+IGRhdGFzdG9y
ZXMgKGFzIHdlbGwgYXMgaG93IHRvIGdldCB0byB0aG9zZSBkYXRhc3RvcmVzKSw8bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+
Jmd0OyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh
biBsYW5nPSJFTi1VUyI+Jmd0OyA8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250
LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7PC9zcGFuPjxzcGFu
IGxhbmc9IkVOLVVTIj4gbzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt
aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4t
VVMiPiB3aGV0aGVyIHN1Y2ggaW5mb3JtYXRpb24gaGFzIGJlZW4NCiBsb2NhbGx5IGNhY2hlZCBv
ciBub3QsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw
YW4gbGFuZz0iRU4tVVMiPiZndDsgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgPC9zcGFuPjxzcGFuIGxhbmc9IkVO
LVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZu
YnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+IG88L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi
IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFu
PjxzcGFuIGxhbmc9IkVOLVVTIj4gd2hldGhlciB0aGVyZSBhcmUgemVybywgb25lLCBvciBtb3Jl
DQogY29udHJvbGxlcnMgYXNzZXJ0aW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgPC9zcGFuPjxzcGFuIGxhbmc9
IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+IG93bmVy
c2hpcCBvZiBpbmZvcm1hdGlvbiwgYW5kPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgPG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgPC9z
cGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO
ZXcmcXVvdDsiPiZuYnNwOyZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+IG88L3NwYW4+
PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx
dW90OyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj4gd2hldGhlciB0aGVyZSBhcmUg
aW50ZXJhY3Rpb25zIHdpdGgNCiBvdGhlciBhcHBsaWNhdGlvbnM8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyA8L3Nw
YW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l
dyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9
IkVOLVVTIj4gY29uY3VycmVudGx5IHJ1bm5pbmcgZWxzZXdoZXJlPG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgPG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0i
RU4tVVMiPiZndDsgPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6
JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJF
Ti1VUyI+IFRoZSBzb2x1dGlvbiByZXF1aXJlbWVudHMgZGVzY3JpYmVkIGluIHRoaXMgZG9jdW1l
bnQgZGV0YWlsIHdoYXQgaXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh
aW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyA8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi
IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7
PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj4gbmVlZGVkIHRvIHN1cHBvcnQgYXBwbGljYXRpb24g
YWNjZXNzIHRvIGF1dGhvcml0YXRpdmUgbmV0d29yayBZQU5HPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgPC9zcGFu
PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm
cXVvdDsiPiZuYnNwOyZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+IG9iamVjdHMgZnJv
bSBjb250cm9sbGVycyAoc3Rhcikgb3IgcGVlcmluZyBuZXR3b3JrIGRldmljZXMgKG1lc2gpDQo8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5n
PSJFTi1VUyI+Jmd0OyBpbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp
blRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIg
c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDs8
L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPiBzdWNoIGEgd2F5IHRvIG1lZXQgdGhlc2UgZ29hbHMu
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFu
Zz0iRU4tVVMiPiZndDsgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu
VGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgPG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZn
dDsgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g
bGFuZz0iRU4tVVMiPiZndDsgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs
YWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkg
dGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YNCjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7
IHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWls
YWJsZSBhdCB0b29scy5pZXRmLm9yZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyA8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBUaGUg
SUVURiBTZWNyZXRhcmlhdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp
blRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IF9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgbmV0bW9k
IG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl
eHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IDxhIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5v
cmciPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5u
ZXRtb2RAaWV0Zi5vcmc8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IDxhIGhyZWY9Imh0dHBzOi8v
d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kIj4NCjxzcGFuIHN0eWxlPSJjb2xv
cjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5odHRwczovL3d3dy5pZXRmLm9yZy9t
YWlsbWFuL2xpc3RpbmZvL25ldG1vZDwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBTdXBh
IG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl
eHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IDxhIGhyZWY9Im1haWx0bzpTdXBhQGlldGYub3Jn
Ij48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+U3Vw
YUBpZXRmLm9yZzwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdXBhIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5k
b3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu
L2xpc3RpbmZvL3N1cGE8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5TdXBhIG1haWxpbmcgbGlzdDxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVO
LVVTIj48YSBocmVmPSJtYWlsdG86U3VwYUBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOndp
bmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPlN1cGFAaWV0Zi5vcmc8L3NwYW4+PC9hPjxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9
IkVOLVVTIj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N1
cGEiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5o
dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N1cGE8L3NwYW4+PC9hPjxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_C0E0A32284495243BDE0AC8A066631A8185AA587szxeml557mbschi_--


From nobody Mon Sep 29 07:10:56 2014
Return-Path: 
X-Original-To: supa@ietfa.amsl.com
Delivered-To: supa@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D22981A1ABA for ; Mon, 29 Sep 2014 07:10:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.287
X-Spam-Level: 
X-Spam-Status: No, score=-14.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_AFFORDABLE=1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, 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 wVYEvSgT89tq for ; Mon, 29 Sep 2014 07:10:41 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9CE01A8723 for ; Mon, 29 Sep 2014 07:10:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17210; q=dns/txt; s=iport; t=1411999836; x=1413209436; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ddGodoHEPiGtTIhqXOkcBTicBSVHOJ+Xn0ikbRV2MGg=; b=l3ubQWYcQ1WpF1JfV1qXu9b6B0PD5ojQiuXyndfFLErrcnEZqjBByqDr hJ2oM7+XDSk7rm/r4ML6d3Faba10p2YIqWzyuE7OLSl6WuM5I0x9LPbro YOdZsB+zzDVt34TGSG237nSlwC9+oYO1jopoEcbkYHbz6LoKdQe7NuNw8 I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AnAJAI9nKVStJA2H/2dsb2JhbAAZAUaDDlNbgn3HDAqGelQCGXUWAXuEAwEBAQQBAQEgEToJAgwEAgEGAhEEAQEDAgYCARoDAgICJQsUAQgIAQEEAQ0FCAERAYgjDYxaMJxMhU+QEwEXgSyIfoVDMQcGgnI2gR0Fj0uCGoQ6iGuTe4NjbIFIgQIBAQE
X-IronPort-AV: E=Sophos;i="5.04,620,1406592000"; d="scan'208";a="82366969"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-7.cisco.com with ESMTP; 29 Sep 2014 14:10:34 +0000
Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s8TEAXm0013268 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 29 Sep 2014 14:10:33 GMT
Received: from xmb-aln-x11.cisco.com ([169.254.6.41]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0195.001; Mon, 29 Sep 2014 09:10:33 -0500
From: "Eric Voit (evoit)" 
To: Tina TSOU , Georgios Karagiannis , "supa@ietf.org" 
Thread-Topic: [netmod] "00" Notification for draft-voit-netmod-peer-mount-requirements
Thread-Index: Ac/ZjioymKhX4n/+Q0irapwH2HUqIwAAEm2AAEtmX7AAQ3RaMAAHV34g
Date: Mon, 29 Sep 2014 14:10:32 +0000
Message-ID: 
References:    
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.116.134.135]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/supa/wCP4cOsN_7q50knC7d94F0r5RbI
Cc: "Alexander Clemm \(alex\)" 
Subject: Re: [Supa] [netmod] "00" Notification for draft-voit-netmod-peer-mount-requirements
X-BeenThere: supa@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 29 Sep 2014 14:10:52 -0000

PkZyb206IFRpbmEgVFNPVSwgU2VwdGVtYmVyIDI5LCAyMDE0IDU6NTAgQU0NCj4NCj5EZWFyIEVy
aWMgZXQgYWwsDQo+DQo+Tm93IEkgcmVhZCBkcmFmdC12b2l0LW5ldG1vZC1wZWVyLW1vdW50LXJl
cXVpcmVtZW50cywgaXQgaXMgdmVyeSBnb29kIA0KPmF0IGRlc2NyaWJpbmcgdGhlIHJlcXVpcmVt
ZW50cy4NCj4NCj5JbiB0aGlzIGRyYWZ0LCB0d28gb3B0aW9uYWwgYXJjaGl0ZWN0dXJlcyB3ZXJl
IHByb3Bvc2VkOiBhIGNlbnRyYWxpemVkIG9uZSANCj5zaW1pbGFyIHRvIFNVUEEgYW5kIGEgZGlz
dHJpYnV0ZWQgb25lIHdoaWNoIGlzIGFsc28gY29tcGF0aWJsZSB3aXRoIFNVUEEgDQo+KHdpdGgg
YSBsaXR0bGUgZXh0ZW5zaW9uIG9mIFNVUEEgY2hhcnRlciBhbmQgc2NvcGUsIHdvdWxkIHlvdSBw
bGVhc2UgcmV2aWV3IA0KPnRoZSBjaGFydGVyIG9mIFNVUEEgYW5kIHByb3ZpZGUgc29tZSB0ZXh0
IGZvciBtb2RpZmljYXRpb24/KS4NCg0KV2lsbCBkbyBpbiBhIHNlcGFyYXRlIHJlc3BvbnNlLg0K
DQo+T25lIGtleSByZXF1aXJlbWVudCBvZiBTVVBBIGlzIG5ldHdvcmstd2lkZSBtb2RlbGluZyBm
b3Igc3RhbmRhcmRpemluZy4gDQo+SW4geW91ciB3b3JrLCBpcyB0aGVyZSBhbHNvIGEgc2ltaWxh
ciByZXF1aXJlbWVudD8NCg0KRnJvbSBhbiBhcHBsaWNhdGlvbiBzdGFuZHBvaW50LCBJIGV4cGVj
dCB0aGF0IHRoZXJlIHdpbGwgYmUgbWFueSBuZXR3b3JrIHdpZGUgDQpzZXJ2aWNlIG1vZGVscyB3
aGljaCBtYXRjaCB0byBhcHBsaWNhdGlvbnMuICBTaW5jZSBhcHBsaWNhdGlvbnMgd2lsbCBhbHdh
eXMNCndhbnQgdGhlaXIgbWluaW1hbCBtYW5hZ2VtZW50IG1vZGVsLCB0aGUgdHJpY2sgd2lsbCBi
ZSB0byBpbnN0cnVtZW50IHRoZQ0KaW50ZXJmYWNlcyBmb3IgZWFzeSBtZXNoaW5nIHdpdGggcGxh
Y2VzIGxpa2UgT3BlblN0YWNrLCBPUE5GViwgT3BlbkRheWxpZ2h0Lg0KDQpJTUhPLCBpdCBpcyBw
cmVtYXR1cmUgdG8gc3RhcnQgc3RhbmRhcmRpemluZyBtYW55IChtb3N0PykgYXBwbGljYXRpb24g
bW9kZWxzIA0KTm9ydGhib3VuZCBvZiBhIGNvbnRyb2xsZXIuICBXZSBkb24ndCBrbm93IHdoaWNo
IHNlcnZpY2VzIHdpbGwgYmUgc3VjY2Vzc2Z1bC4gIA0KV2UgZG9uJ3Qga25vdyBlbm91Z2ggYWJv
dXQga2V5IHNjYWxlIG9yIG9wZXJhdGlvbmFsIGNvbnNpZGVyYXRpb25zLg0KDQo+SSBtZWFuLCBk
byB5b3UgbmVlZCB0aGUgbW9kZWwgYmV0d2VlbiBhcHAgYW5kIG5ldHdvcmsgZWxlbWVudCBiZSAN
Cj5zdGFuZGFyZGl6ZWQ/DQoNCk5vLiAgSSB3YW50IHRvIHdvcmsgd2l0aCBleGlzdGluZyBkZXZp
Y2UgbW9kZWxzLiAgSG93ZXZlciBpZiBhIG11bHRpLW5ldHdvcmsgDQplbGVtZW50IGFwcGxpY2F0
aW9uIHNpdHMgaW4gYW4gY29udGFpbmVyIHdoaWNoIGlzIGNvLXJlc2lkZW50IG9uL25lYXIgdGhl
IA0KbmV0d29yayBlbGVtZW50LCB0aGVuIHRoaXMgY291bGQgYmUgc3RhbmRhcmRpemVkLiAgDQoN
Cj5IYXZlIHlvdSBjb25zaWRlcmVkIHRoZSBtYXBwaW5nIG1lY2hhbmlzbSBmcm9tIG5ldHdvcmst
d2lkZSBtb2RlbCANCj50byBkZXZpY2UgbGV2ZWwgY29uZmlndXJhdGlvbj8gVGhpcyBpcyBwYXJ0
IG9mIHRoZSB3b3JrIG9mIFNVUEEuDQoNClllcy4NCg0KPkkgd291bGQgYWdyZWUgdGhhdCB0aGVy
ZSBhcmUgbWFueSBiZW5lZml0cyBvZiB1c2luZyBkaXN0cmlidXRlZCBzb2x1dGlvbiwgDQo+aG93
ZXZlciwgdGhlcmUgaXMgb25lIGtleSBpc3N1ZTogaWYgdGhlIGRlY2lzaW9ucyBvciBhY3Rpb25z
IGZyb20gZGlmZmVyZW50IA0KPm5ldHdvcmsgZWxlbWVudHMgYXJlIGRpZmZlcmVuY2UgYW5kIGlu
Y29tcGF0aWJsZSwgaG93IHRvIGF2b2lkIHRoZSANCj5mbHVjdHVhdGlvbj8gDQoNClRoaXMgaXMg
dGhlIG1vc3QgaW50ZXJlc3RpbmcgcGFydCBvZiB0aGUgcHJvYmxlbS4gICBPbmUgYmVuZWZpdCBv
ZiBvdXIgIk1vdW50IiANCmFwcHJvYWNoIGlzIHRoYXQgYXV0aG9yaXRhdGl2ZSBvYmplY3RzIGFy
ZSBhY2Nlc3NpYmxlIGFueXdoZXJlIGluIGEgZG9tYWluLiAgDQotICJwZWVyIG1vdW50IiBpbmZy
YXN0cnVjdHVyZSBpcyBhZ25vc3RpYyB0byB3aGVyZSBzdWNoIGNoZWNrIG9jY3VyDQotIGNoYW5n
ZXMgaW4gc3RhdGUgY2FuIGJlIG1vbml0b3JlZCBvbiByZW1vdGUgZGV2aWNlcyB2aWEgc3Vic2Ny
aXB0aW9uDQotIGRpc3RyaWJ1dGVkIG9iamVjdHMgcHJldmlvdXMgaW5hY2Nlc3NpYmxlIGNhbiBu
b3cgYmUgY29tcGFyZWQNCi0gY29uc2lzdGVuY3kgYXBwbGV0cyAoZHJpdmVuIGJ5IHRoZXNlIHRy
aWdnZXJzKSBjYW4gYmUgcGxhY2VkIGFueXdoZXJlDQoNCkZyb20gdGhlcmUgaXQgaXMgbG9jYWwg
YnVzaW5lc3MgbG9naWMgd2hpY2ggZGV0ZXJtaW5lcyB3aGF0IHRvIGRvIGlmIA0KZGlmZmVyZW50
IGF1dGhvcml0YXRpdmUgb2JqZWN0cyBlbmQgdXAgYmVpbmcgaW5jb21wYXRpYmxlLiAgT2Z0ZW4g
aXQgaXMgDQpwb3NzaWJsZSB0byBtZWNoYW5pemUgdGhlIHJlc29sdXRpb24uICANCg0KVGhpcyBp
cyBleGFjdGx5IHdoeSB3ZSBhcmUgcHVzaGluZyAiRXZlbnR1YWwgQ29uc2lzdGVuY3kiLiAgUm91
dGluZyANClByb3RvY29scyBhbmQgQW1hem9uLmNvbSdzIHNob3BwaW5nIGNhcnQgc3lzdGVtIGhh
dmUgYWRkcmVzc2VkIHRoZXNlIA0KcHJvYmxlbXMgZXh0cmVtZWx5IHdlbGwuICBJdCBpcyB0aW1l
IHRvIGFwcGx5IHRoZXNlIHNvbHV0aW9ucyB0byBnZW5lcmFsIA0KbmV0d29ya2luZyBwb2xpY3ku
ICBFdmVuIG11bHRpcGxlIGNvbnRyb2xsZXIgZW52aXJvbm1lbnRzIGNhbiBiZSBzdXBwb3J0ZWQu
DQoNCj5JTUhPLCB0aGlzIG1heSBiZSBzb2x2ZWQgYnkgc2xpY2luZyB0aGUgcmVzb3VyY2Ugb3Ig
dXNpbmcgDQo+bXVsdGlwbGUgaW5zdGFuY2VzIGZyb20gdmlydHVhbGl6YXRpb24/IE9yIHVzaW5n
IHRoZSBjb25zaXN0ZW5jZSBjaGVjayBvZiANCj5kaXN0cmlidXRlZCBkYXRhYmFzZT8NCj4NCj5T
b21lIHdvcmRzIGZyb20gdGhpcyBkcmFmdCBtYXkgaW1wbHkgdGhlIHJlcXVpcmVtZW50IGZvciBl
eHRlbmRpbmcgdGhlIA0KPmV4aXN0aW5nIE5FVENPTkYuIEJ1dCBJ4oCZbSBub3Qgc3VyZS4gRG8g
eW91IHJlYWxseSB3YW50IHRoYXQ/DQoNCldoYXQgSSB3YW50IGlzIHRoZSBzdGFuZGFyZHMgdHJh
Y2sgZm9yIGEgbmV3IHZlcnNpb24gb2YgDQpkcmFmdC1jbGVtbS1uZXRtb2QtbW91bnQuICAgVGhl
IHZlcnNpb24gc2hvdWxkIGJlIG91dCBzb29uLg0KDQpFcmljIA0KDQo+SG9wZSBpdCBoZWxwcy4N
Cj7CoCANCj4NCj5UaGFuayB5b3UsDQo+VGluYQ0KPg0KPkZyb206IFN1cGEgW21haWx0bzpzdXBh
LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBUaW5hIFRTT1UNCj5TZW50OiBTdW5kYXks
IFNlcHRlbWJlciAyOCwgMjAxNCA5OjM4IEFNDQo+VG86IEdlb3JnaW9zIEthcmFnaWFubmlzOyBF
cmljIFZvaXQgKGV2b2l0KTsgc3VwYUBpZXRmLm9yZw0KPkNjOiBBbGV4YW5kZXIgQ2xlbW0gKGFs
ZXgpDQo+U3ViamVjdDogUmU6IFtTdXBhXSBbbmV0bW9kXSAiMDAiIE5vdGlmaWNhdGlvbiBmb3Ig
ZHJhZnQtdm9pdC1uZXRtb2QtcGVlci1tb3VudC1yZXF1aXJlbWVudHMNCj4NCj5EZWFyIEVyaWMg
ZXQgYWwsDQo+DQo+RGlzdHJpYnV0ZWQgRGF0YSBDZW50ZXIgc2VydmljZXMgYXJlIHR5cGljYWwg
Y2FzZSBmb3IgU1VQQS4NCj5Zb3VyIHN1Ym1pc3Npb24gb2YgZHJhZnRzIGFyZSB2ZXJ5IHdlbGNv
bWUuDQo+DQo+WW91IG1heSBiZSBpbnRlcmVzdGVkIHRvIGxvb2sgYXQgdGhlc2UuIMKgwqANCj5k
cmFmdC1jaGVuZy1zdXBhLWRkYy11c2UtY2FzZXMtMDAgDQpVc2UgQ2FzZXMgZm9yIERpc3RyaWJ1
dGVkIERhdGEgQ2VudGVyIEFwcGxpY2F0aW9ucyBpbiBTVVBBDQoyMDE0LTA5LTE3IA0KPm5ldw0K
SS1EIEV4aXN0cyANCg0KDQoNCmRyYWZ0LWNvbnRyZXJhcy1zdXBhLXlhbmctbmV0d29yay10b3Bv
LTAwIA0KQSBZQU5HIERhdGEgTW9kZWwgZm9yIE5ldHdvcmsgVG9wb2xvZ2llcw0KMjAxNC0wOS0x
OCANCj5uZXcNCkktRCBFeGlzdHMgDQoNCg0KDQpkcmFmdC16YWFsb3VrLXN1cGEtY29uZmlndXJh
dGlvbi1tb2RlbC0wMCANCllBTkcgRGF0YSBNb2RlbCBmb3IgQ29uZmlndXJhdGlvbiBvZiBTaGFy
ZWQgVW5pZmllZCBQb2xpY3kgQXV0b21hdGlvbiAoU1VQQSkNCjIwMTQtMDktMjIgDQo+bmV3DQpJ
LUQgRXhpc3RzIA0KZHJhZnQtcGVudGlrb3VzaXMtc3VwYS1tYXBwaW5nLTAwIA0KU1VQQSBDb25m
aWd1cmF0aW9uIGFuZCBQb2xpY3kgTWFwcGluZw0KMjAxNC0wOS0yMyANCj5uZXcNCkktRCBFeGlz
dHMgDQoNCg0KDQoNCg0KDQoNCg0KDQo+DQo+VGhhbmsgeW91LA0KPlRpbmENCj4NCj4tLS0tLU9y
aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IFN1cGEgW21haWx0bzpzdXBhLWJvdW5jZXNAaWV0
Zi5vcmddIE9uIEJlaGFsZiBPZiBHZW9yZ2lvcyBLYXJhZ2lhbm5pcw0KPlNlbnQ6IEZyaWRheSwg
U2VwdGVtYmVyIDI2LCAyMDE0IDk6MzUgUE0NCj5UbzogRXJpYyBWb2l0IChldm9pdCk7IHN1cGFA
aWV0Zi5vcmcNCj5DYzogQWxleGFuZGVyIENsZW1tIChhbGV4KQ0KPlN1YmplY3Q6IFJlOiBbU3Vw
YV0gW25ldG1vZF0gIjAwIiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXZvaXQtbmV0bW9kLXBlZXIt
bW91bnQtcmVxdWlyZW1lbnRzDQo+DQo+SGkgRXJpYywNCj4NCj5UaGFua3MgZm9yIHRoZSBpbmZv
cm1hdGlvbi4NCj5JIGhhdmUgbm90IHJlYWQgeW91ciBkcmFmdCBpbiBkZXRhaWwsIGJ1dCBmcm9t
IHlvdXIgZXhwbGFuYXRpb24sIGl0IG1pZ2h0IGJlIHJlbGV2YW50IHRvIFNVUEEuDQo+DQo+QmVz
dCByZWdhcmRzLA0KPkdlb3JnaW9zDQo+DQo+DQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t
LQ0KPj4gRnJvbTogU3VwYSBbbWFpbHRvOnN1cGEtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm
IE9mIEVyaWMgVm9pdCANCj4+IChldm9pdCkNCj4+IFNlbnQ6IEZyaWRheSwgU2VwdGVtYmVyIDI2
LCAyMDE0IDI6MzIgUE0NCj4+IFRvOiBzdXBhQGlldGYub3JnDQo+PiBDYzogQWxleGFuZGVyIENs
ZW1tIChhbGV4KQ0KPj4gU3ViamVjdDogW1N1cGFdIEZXOiBbbmV0bW9kXSAiMDAiIE5vdGlmaWNh
dGlvbiBmb3IgDQo+PiBkcmFmdC12b2l0LW5ldG1vZC1wZWVyLSBtb3VudC1yZXF1aXJlbWVudHMN
Cj4+IA0KPj4gSSBqdXN0IGxlYXJuZWQgYWJvdXQgU1VQQSwgYW5kIGJhc2VkIG9uIHRoZSBldm9s
dmluZyBjaGFydGVyIGl0IHNlZW1zIA0KPj4gcXVpdGUgcmVsZXZhbnQgdG8gYW4gaW5mb3JtYXRp
b25hbCBkcmFmdCBzZXZlcmFsIG9mIHVzIHN1Ym1pdHRlZCB0byBOZXRtb2QgeWVzdGVyZGF5Lg0K
Pj4gaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtdm9pdC1uZXRtb2Qt
cGVlci1tb3VudC1yZXF1aQ0KPj4gcmVtZW50cy0NCj4+IDAwLnR4dA0KPj4gDQo+PiBPdXIgZHJh
ZnQgYWdncmVnYXRlcyByZXF1aXJlbWVudHMgd2UgaGF2ZSB1bmNvdmVyZWQgYXMgd2UgaGF2ZSBi
dWlsdCANCj4+IHNldmVyYWwgbmV3IERhdGEgQ2VudGVyIGVkZ2Ugc2VydmljZXMgdXBvbiBhbiBP
cGVuIERheWxpZ2h0IA0KPj4gY29udHJvbGxlci7CoCBXZSBhbHJlYWR5IGhhdmUgYSB3b3JraW5n
IFlBTkcgc2VydmljZSBtb2RlbCBmb3IgdHdvIG9mIHRoZSB0d28gc2VydmljZXMgaW4gdGhlIGRy
YWZ0Lg0KPj4gSWYgdGhlcmUgaXMgaW50ZXJlc3QgaGVyZSwgSSBjb3VsZCBwdWJsaXNoIHRoYXQg
bW9kZWwgYXMgd2VsbC4NCj4+IA0KPj4gVGhhbmtzLA0KPj4gRXJpYw0KPj4gDQo+PiAtLS0tLU9y
aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogbmV0bW9kIFttYWlsdG86bmV0bW9kLWJvdW5j
ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBFcmljIFZvaXQsIA0KPj4gU2VwdGVtYmVyIDI1LCAy
MDE0IDY6MzggUE0NCj4+IA0KPj4gV2UgaGF2ZSBiZWVuIGRldmVsb3BpbmcgU0ROIGFwcGxpY2F0
aW9ucyB3aGljaCByZXF1aXJlIHF1aWNrLCANCj4+IGl0ZXJhdGl2ZSBhY2Nlc3MgdG8gb2JqZWN0
cyByZXByZXNlbnRpbmcgbmV0d29yayBhbmQgZGV2aWNlIA0KPj4gYWJzdHJhY3Rpb25zLsKgIFRo
ZXNlIG9iamVjdHMgaW5jbHVkZSBvbmVzIGF1dGhvcml0YXRpdmVseSBvd25lZCBieSBhIA0KPj4g
bG9jYWwgc3lzdGVtLCBhcyB3ZWxsIGFzIG9uZXMgcHJvdmlkZWQgZnJvbSByZW1vdGUgZGF0YXN0
b3Jlcy7CoCBUd28gDQo+PiBzdWNoIGFwcGxpY2F0aW9ucyB3ZSBoYXZlIHByb3RvdHlwZWQgYXJl
IOKAnENsb3VkIFBvbGljZXLigJ0gYW5kIOKAnEREb1MgDQo+PiBUaHJlc2hvbGRpbmfigJ0uIMKg
KFNlZSBsaW5rcyBiZWxvdyBmb3IgbW9yZSBvbiB0aGVzZSBhcHBzLikNCj4+IA0KPj4gVGhlIGdv
b2QgbmV3cyBpcyB0aGF0IHdlIGZvdW5kIFlBTkcgbW9kZWxzIGFuZCBzeW50YXggdG8gYmUgYSBu
aWNlIGZpdCANCj4+IGZvciB0aGVzZSBhcHBsaWNhdGlvbnMuwqDCoCBIb3dldmVyIHdlIGhhdmUg
YmVlbiB0cnlpbmcgdG8gY292ZXIgc2V2ZXJhbCANCj4+IG1pc3NpbmcNCj4+IGVsZW1lbnRzOg0K
Pj4gDQo+PiBNaXNzaW5nIEVsZW1lbnQgIzE6IERldmVsb3BlciBTaW1wbGljaXR5IFdlIHdhbnRl
ZCBhcHBsaWNhdGlvbnMgdG8gDQo+PiBhY2Nlc3MgcmVtb3RlIG9iamVjdHMgZnJvbSBhIHNpbmds
ZSBkYXRhc3RvcmUsIHdpdGhvdXQgaGF2aW5nIHRvIGhhdmUgDQo+PiB0aGUgYXBwbGljYXRpb25z
IHBlZXIgZGlyZWN0bHkgd2l0aCByZW1vdGUgZGV2aWNlcy7CoCBXZSBhbHNvIHdhbnRlZCANCj4+
IGNsaWVudHMgYW5kIGFwcGxpY2F0aW9ucyB0byBhY2Nlc3MgZGF0YXN0b3JlcyBpbiB0aGUgc2Ft
ZSB3YXkgDQo+PiBpbmRlcGVuZGVudCBvZiB3aGV0aGVyIHRoZSBhcHBsaWNhdGlvbnMgd2VyZSBo
b3N0ZWQgb24gYSBOZXR3b3JrIEVsZW1lbnQgb3IgQ29udHJvbGxlci4NCj4+IA0KPj4gTWlzc2lu
ZyBFbGVtZW50ICMyOiBXaG8gb3ducyBhbiBPYmplY3Q/DQo+PiBBcHBsaWNhdGlvbnMgY2FuJ3Qg
dGVsbCB3aGljaCBOZXR3b3JrIEVsZW1lbnQgYWNyb3NzIGEgc2V0IG9mIGRldmljZXMgDQo+PiBp
cyB0aGUgYXV0aG9yaXRhdGl2ZSBvd25lciBvZiBhIHBhcnRpY3VsYXIgcmVwbGljYXRlZCBvYmpl
Y3QuwqAgU2luY2UgDQo+PiByZXBsaWNhdGVkIGRhdGEgZ2V0cyBvdXQgb2Ygc3luY2gsIHJlc29s
dXRpb24gLyBjb252ZXJnZW5jZSBpcyBhIHByb2JsZW0uDQo+PiANCj4+IE1pc3NpbmcgRWxlbWVu
dCAjMzogTWFpbnRhaW5pbmcgY2FjaGVzIG9mIHJlbW90ZSBpbmZvcm1hdGlvbiANCj4+IEFwcGxp
Y2F0aW9ucyBuZWVkIHRpbWVseSBhY2Nlc3MgdG8gcmVtb3RlIGluZm9ybWF0aW9uLCB3aGljaCBj
YW4gDQo+PiBuZWNlc3NpdGF0ZSB0aGUgaW50cm9kdWN0aW9uIGNhY2hlIGluZnJhc3RydWN0dXJl
LsKgIE5ldGNvbmYgcHJvdmlkZXMgDQo+PiBsaXR0bGUgc3VwcG9ydCB0byBmYWNpbGl0YXRlIHRo
aXMuwqAgRm9yIGV4YW1wbGUsIG5vdGlmaWNhdGlvbnMgYXJlIG5vdCANCj4+IGEgZ29vZCBtYXRj
aCB0byBzdWJzY3JpYmUgdG8gcHVzaC0gdXBkYXRlcy4NCj4+IA0KPj4gVG8gc29sdmUgdGhlc2Ug
cHJvYmxlbXMsIHdlIG5lZWQgdGVjaG5vbG9neSBzb2x1dGlvbnMgd2hpY2ggd29yayANCj4+IGVx
dWFsbHkgd2VsbCBmb3IgYm90aCBDb250cm9sbGVycyBhbmQgTmV0d29yayBFbGVtZW50cy7CoCBU
aGVzZSANCj4+IHNvbHV0aW9ucyBtdXN0IGV4cG9zZSBsb2NhbCBkYXRhc3RvcmVzIHdoaWNoIHBy
b3ZpZGUgYXV0aG9yaXRhdGl2ZSwgDQo+PiBjb25zb2xpZGF0ZWQgdmlld3Mgb2YgZGlzdHJpYnV0
ZWQgbmV0d29yayBvYmplY3RzLsKgIFRoaXMgbXVzdCBiZSBkb25lIA0KPj4gaW4gYSB3YXkgd2hp
Y2ggYWxsb3dzIHRoZSBhcHBsaWNhdGlvbnMgdG8gc2l0IGFueXdoZXJlIGluIHRoZSBuZXR3b3Jr
LCANCj4+IG9uIHZhcmlvdXMgYWJzdHJhY3Rpb25zLCB3aGlsZSBtYWludGFpbmluZyBkb21haW4g
Y29uc2lzdGVuY3kuIEFuZCANCj4+IHRoaXMgbXVzdCBiZSBkb25lIHdoaWxlIG1heGltaXppbmcg
YXBwbGljYXRpb24gZGV2ZWxvcGVyIHNpbXBsaWNpdHkuDQo+PiANCj4+IFRoaXMgZHJhZnQgaXMg
aW50ZW5kZWQgdG8gc3RhcnQgYWdncmVnYXRpbmcgcmVxdWlyZW1lbnRzIGluIHRoaXMgDQo+PiBz
cGFjZS7CoCBUaGUgZHJhZnQgaXMgbm90IGNvbXBsZXRlLCBzbyBpdCB3b3VsZCBiZSBncmVhdCB0
byBoZWFyIGZyb20gDQo+PiBvdGhlcnMgd2hvIGFyZSBpbnRlcmVzdGVkIGluIGhlbHBpbmcgc28g
dGhhdCB3ZSBlbmQgdXAgd2l0aCBhIG1vcmUgY29tcHJlaGVuc2l2ZSBjb250ZXh0Lg0KPj4gDQo+
PiBTb2x1dGlvbnMgZG8gZXhpc3Qgd2hpY2ggY2FuIHNvbHZlIGEgc3Vic2V0IG9mIHRoZXNlIHJl
cXVpcmVtZW50cy7CoCANCj4+IE9uZSBwYXJ0aWN1bGFyIHRlY2hub2xvZ3kgd2UgaGF2ZSBidWls
dCBpcyBrbm93biBhcyDigJxwZWVyIG1vdW504oCdLsKgIA0KPj4gUGVlciBtb3VudCBnaXZlcyB0
aGUgYWJpbGl0eSB0byByZWZlcmVuY2UgWUFORyBpbmZvcm1hdGlvbiBpbnRvIGEgDQo+PiBsb2Nh
bCBkYXRhc3RvcmUgZnJvbSByZW1vdGUgZGF0YXN0b3Jlcy7CoCBUaGlzIHByb3ZpZGVzIGNsaWVu
dCANCj4+IGFwcGxpY2F0aW9ucyB3aXRoIGxvY2FsIGFjY2VzcyB0byBpbmZvcm1hdGlvbiB3aGlj
aCBtaWdodCBiZSANCj4+IHRyYW5zcGFyZW50bHkgZmVkZXJhdGVkIGFjcm9zcyBtdWx0aXBsZSBz
eXN0ZW1zIGFuZCBkYXRhc3RvcmVzLsKgIEl0IA0KPj4gYWxzbyByZXRhaW5zIGNsZWFyIG9iamVj
dCBvd25lcnNoaXAgdG8gbWluaW1pemUgc3luY2hyb25pemF0aW9uIGFuZCANCj4+IGludGVyLXN5
c3RlbSBkZXBlbmRlbmN5IGlzc3Vlcy7CoMKgIFRoZXJlIGFyZSBhbHJlYWR5IGltcGxlbWVudGF0
aW9ucyBvZiANCj4+IHRoaXMgdGVjaG5vbG9neSwgZm9yIGV4YW1wbGUsIGluIE9wZW4gRGF5bGln
aHQuwqAgSG93ZXZlciwgd2UgYmVsaWV2ZSANCj4+IHJlcXVpcmVtZW50cyBhbmQgdXNlIGNhc2Vz
IGZvciB0aGlzIHRlY2hub2xvZ3kgYXBwbHkgZXF1YWxseSB3ZWxsIHRvIG5ldHdvcmsgZGV2aWNl
cy4NCj4+IA0KPj4gUGxlYXNlIGxldCB1cyBrbm93IGlmIGVpdGhlciB0aGUgcmVxdWlyZW1lbnRz
IG9yIHRlY2hub2xvZ3kgDQo+PiBzcGVjaWZpY2F0aW9ucyBhcmUgcHJvYmxlbSB5b3UgYXJlIGlu
dGVyZXN0ZWQgaW4gZXhwbG9yaW5nLg0KPj4gDQo+PiBUaGFua3MhDQo+PiBFcmljLCBBbGV4LCBQ
cmFiaGFrYXJhLCBBbWJpa2EsIFNoYXNoaQ0KPj4gDQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut
LS0tLQ0KPj4gRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQt
ZHJhZnRzQGlldGYub3JnXQ0KPj4gU2VudDogVGh1cnNkYXksIFNlcHRlbWJlciAyNSwgMjAxNCA4
OjQxIEFNDQo+PiBUbzogUHJhYmhha2FyYSBZZWxsYWkgKHB5ZWxsYWkpOyBTaGFzaGkgS3VtYXIg
QmFuc2FsIChzaGFiYW5zYSk7IA0KPj4gQW1iaWthIFByYXNhZCBUcmlwYXRoeSAoYW1idHJpcGEp
OyBBbGV4YW5kZXIgQ2xlbW0gKGFsZXgpOyBFcmljIFZvaXQgDQo+PiAoZXZvaXQpOyBBbWJpa2Eg
UHJhc2FkIFRyaXBhdGh5IChhbWJ0cmlwYSk7IEFsZXhhbmRlciBDbGVtbSAoYWxleCk7IA0KPj4g
UHJhYmhha2FyYSBZZWxsYWkgKHB5ZWxsYWkpOyBFcmljIFZvaXQgKGV2b2l0KTsgU2hhc2hpIEt1
bWFyIEJhbnNhbCANCj4+IChzaGFiYW5zYSkNCj4+IFN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlm
aWNhdGlvbiBmb3IgZHJhZnQtdm9pdC1uZXRtb2QtcGVlci1tb3VudC0gDQo+PiByZXF1aXJlbWVu
dHMtMDAudHh0DQo+PiANCj4+IA0KPj4gQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXZvaXQt
bmV0bW9kLXBlZXItbW91bnQtcmVxdWlyZW1lbnRzLTAwLnR4dA0KPj4gaGFzIGJlZW4gc3VjY2Vz
c2Z1bGx5IHN1Ym1pdHRlZCBieSBFcmljIFZvaXQgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBv
c2l0b3J5Lg0KPj4gDQo+PiBOYW1lOsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAg
ZHJhZnQtdm9pdC1uZXRtb2QtcGVlci1tb3VudC1yZXF1aXJlbWVudHMNCj4+IFJldmlzaW9uOsKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDAwDQo+PiBUaXRsZTrCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgIFJlcXVpcmVtZW50cyBmb3IgUGVlciBNb3VudGluZyBvZiBZ
QU5HIA0KPj4gc3VidHJlZXMgZnJvbSBSZW1vdGUgRGF0YXN0b3JlcyBEb2N1bWVudCBkYXRlOiAy
MDE0LTA5LTI1DQo+PiBHcm91cDrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIElu
ZGl2aWR1YWwgU3VibWlzc2lvbg0KPj4gUGFnZXM6wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoCAyMg0KPj4gVVJMOsKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgDQo+PiBodHRwOi8vd3d3
LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC12b2l0LW5ldG1vZC1wZWVyLQ0KPj4gbW91
bnQtcmVxdWlyZW1lbnRzLTAwLnR4dA0KPj4gU3RhdHVzOsKgwqDCoMKgwqDCoMKgwqAgDQo+PiBo
dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC12b2l0LW5ldG1vZC1wZWVyLW1v
dW50LQ0KPj4gcmVxdWlyZW1lbnRzLw0KPj4gSHRtbGl6ZWQ6wqDCoMKgwqDCoMKgIA0KPj4gaHR0
cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdm9pdC1uZXRtb2QtcGVlci1tb3VudC0NCj4+
IHJlcXVpcmVtZW50cy0wMA0KPj4gDQo+PiANCj4+IEFic3RyYWN0Og0KPj4gwqDCoCBOZXR3b3Jr
IGludGVncmF0ZWQgYXBwbGljYXRpb25zIHdhbnQgc2ltcGxlIHdheXMgdG8gYWNjZXNzIFlBTkcN
Cj4+IMKgwqAgb2JqZWN0cyBhbmQgc3VidHJlZXMgd2hpY2ggbWlnaHQgYmUgZGlzdHJpYnV0ZWQg
YWNyb3NzIG5ldHdvcmsuDQo+PiDCoMKgIFBlcmZvcm1hbmNlIHJlcXVpcmVtZW50cyBtYXkgZGlj
dGF0ZSB0aGF0IGl0IGlzIHVuYWZmb3JkYWJsZSBmb3IgYQ0KPj4gwqDCoCBzdWJzZXQgb2YgdGhl
c2UgYXBwbGljYXRpb25zIHRvIGdvIHRocm91Z2ggZXhpc3RpbmcgY2VudHJhbGl6ZWQNCj4+IMKg
wqAgbWFuYWdlbWVudCBicm9rZXJzLsKgIEZvciBzdWNoIGFwcGxpY2F0aW9ucywgZGV2ZWxvcG1l
bnQgY29tcGxleGl0eQ0KPj4gwqDCoCBtdXN0IGJlIG1pbmltaXplZC7CoCBTcGVjaWZpYyBhc3Bl
Y3RzIG9mIGNvbXBsZXhpdHkgZGV2ZWxvcGVycyB3YW50IA0KPj4gdG8NCj4+IMKgwqAgaWdub3Jl
IGluY2x1ZGU6DQo+PiANCj4+IMKgwqAgb8KgIHdoZXRoZXIgYXV0aG9yaXRhdGl2ZSBpbmZvcm1h
dGlvbiBpcyBhY3R1YWxseSBzb3VyY2VkIGZyb20gDQo+PiByZW1vdGUNCj4+IMKgwqDCoMKgwqAg
ZGF0YXN0b3JlcyAoYXMgd2VsbCBhcyBob3cgdG8gZ2V0IHRvIHRob3NlIGRhdGFzdG9yZXMpLA0K
Pj4gDQo+PiDCoMKgIG/CoCB3aGV0aGVyIHN1Y2ggaW5mb3JtYXRpb24gaGFzIGJlZW4gbG9jYWxs
eSBjYWNoZWQgb3Igbm90LA0KPj4gDQo+PiDCoMKgIG/CoCB3aGV0aGVyIHRoZXJlIGFyZSB6ZXJv
LCBvbmUsIG9yIG1vcmUgY29udHJvbGxlcnMgYXNzZXJ0aW5nDQo+PiDCoMKgwqDCoMKgIG93bmVy
c2hpcCBvZiBpbmZvcm1hdGlvbiwgYW5kDQo+PiANCj4+IMKgwqAgb8KgIHdoZXRoZXIgdGhlcmUg
YXJlIGludGVyYWN0aW9ucyB3aXRoIG90aGVyIGFwcGxpY2F0aW9ucw0KPj4gwqDCoMKgwqDCoCBj
b25jdXJyZW50bHkgcnVubmluZyBlbHNld2hlcmUNCj4+IA0KPj4gwqDCoCBUaGUgc29sdXRpb24g
cmVxdWlyZW1lbnRzIGRlc2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50IGRldGFpbCB3aGF0IGlzDQo+
PiDCoMKgIG5lZWRlZCB0byBzdXBwb3J0IGFwcGxpY2F0aW9uIGFjY2VzcyB0byBhdXRob3JpdGF0
aXZlIG5ldHdvcmsgWUFORw0KPj4gwqDCoCBvYmplY3RzIGZyb20gY29udHJvbGxlcnMgKHN0YXIp
IG9yIHBlZXJpbmcgbmV0d29yayBkZXZpY2VzIChtZXNoKSANCj4+IGluDQo+PiDCoMKgIHN1Y2gg
YSB3YXkgdG8gbWVldCB0aGVzZSBnb2Fscy4NCj4+IA0KPj4gDQo+PiANCj4+IA0KPj4gDQo+PiBQ
bGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUg
dGltZSBvZiANCj4+IHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRp
ZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4+IA0KPj4gVGhlIElFVEYgU2Vj
cmV0YXJpYXQNCj4+IA0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18NCj4+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4+IG5ldG1vZEBpZXRmLm9yZw0KPj4g
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCj4+IF9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBTdXBhIG1haWxpbmcg
bGlzdA0KPj4gU3VwYUBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s
aXN0aW5mby9zdXBhDQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18NCj5TdXBhIG1haWxpbmcgbGlzdA0KPlN1cGFAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5p
ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N1cGENCj4NCg==


From nobody Mon Sep 29 08:02:18 2014
Return-Path: 
X-Original-To: supa@ietfa.amsl.com
Delivered-To: supa@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C99921A876D for ; Mon, 29 Sep 2014 08:02:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.036
X-Spam-Level: 
X-Spam-Status: No, score=-3.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.786] autolearn=unavailable
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 E8UB_xWpVIMV for ; Mon, 29 Sep 2014 08:02:13 -0700 (PDT)
Received: from mx2.eict.de (mx2.eict.de [212.91.241.168]) by ietfa.amsl.com (Postfix) with ESMTP id A4B7A1A8760 for ; Mon, 29 Sep 2014 08:02:12 -0700 (PDT)
Received: by mx2.eict.de (Postfix, from userid 481) id 8F2131FF58; Mon, 29 Sep 2014 17:02:11 +0200 (CEST)
Received: from mail.eict.de (mx1 [172.16.6.1]) by mx2.eict.de (Postfix) with ESMTP id 01F861FF55; Mon, 29 Sep 2014 17:02:11 +0200 (CEST)
Received: from sbs2008.eict.local (sbs2008.intern.eict.de [192.168.2.11]) by mail.eict.de (Postfix) with ESMTP id A09B23782F8; Mon, 29 Sep 2014 17:02:10 +0200 (CEST)
Received: from SBS2008.eict.local ([fe80::2051:ef24:c7c9:f298]) by SBS2008.eict.local ([fe80::2051:ef24:c7c9:f298%13]) with mapi; Mon, 29 Sep 2014 17:02:10 +0200
From: Kostas Pentikousis 
To: Parviz Yegani , Georgios Karagiannis 
Date: Mon, 29 Sep 2014 17:02:09 +0200
Thread-Topic: [Supa] New SUPA charter
Thread-Index: Ac/ahWvRdCpLkwMuTtyyGHVJ39XOQQBbfr/g
Message-ID: <0C7EDCF89AB9E2478B5D010026CFF4AEA10C72ADDE@SBS2008.eict.local>
References:  
In-Reply-To: 
Accept-Language: en-US, de-DE
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, de-DE
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/supa/BX_rXL20UNvcVLyRzZVRk12jz0Q
Cc: "nmrg@irtf.org" , "supa@ietf.org" 
Subject: Re: [Supa] New SUPA charter
X-BeenThere: supa@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 29 Sep 2014 15:02:17 -0000

SGkgR2Vvcmdpb3MsDQoNCkkgc2Vjb25kIFBhcnZpeiwgaXTigJlzIG11Y2ggYmV0dGVyIGFmdGVy
IHRoZSByZWNlbnQgcmV2aXNpb25zLiBBIGZldyBjb21tZW50cyB3cnQgdG8gdGhlIHZlcnNpb24g
YXQgaHR0cHM6Ly9naXRodWIuY29tL2xpdXNodWNoZW5nL1NVUEEvd2lraS9TVVBBLUNoYXJ0ZXIN
Cg0KRG8gd2UgbmVlZCB0aGlzIHBocmFzZTogInRvIHNoaWZ0IHRoZSBiYWxhbmNlIFtvZiBjb3N0
cz9dIGluIHRoZWlyIGZhdm9yIj8gU1VQQSBzaG91bGQgbm90IGJlIGEgemVyby1zdW0gZ2FtZS4g
RXZlcnlvbmUgc2hvdWxkIGJlbmVmaXQgKHZlbmRvcnMsIG9wZXJhdG9ycywgYWRtaW5zLCB1c2Vy
cywgbmV3IHNlcnZpY2UgcHJvdmlkZXJzKS4NCg0KRG8gd2UgUkVBTExZIGhhdmUgdG8gY2FwaXRh
bGl6ZSBQT0xJQ1ksIFVOSUZJRUQsIFNIQVJFRCwgYW5kIEFVVE9NQVRJQ0FMTFk/IDopDQoNClRo
ZSBwYXJhZ3JhcGggc3RhcnRpbmcgd2l0aCAiU29tZSBJRVRGIHdvcmtpbmcgZ3JvdXBzLi4uIiBt
YXkgYmUgdXNlZnVsIHRvIG1vdGl2YXRlIGNoYXJ0ZXJpbmcgdGhlIFdHLCBidXQgSSdtIG5vdCBz
dXJlIGl0IHNob3VsZCBiZSBwYXJ0IG9mIHRoZSBmaW5hbCBjaGFydGVyLg0KDQpGaW5hbGx5LCB0
aGUgbGFzdCBwYXJhZ3JhcGhzIHN0YXJ0aW5nIHdpdGggIlNVUEEgd2lsbCB3b3JrIG9uIGRlZmlu
aW5nLi4uICIgYW5kIGVuZGluZyB3aXRoIHRoZSBzZWN0aW9uIG9uIFdvcmsgSXRlbXMgaGFzIGEg
Yml0IG9mIG92ZXJsYXAgd2l0aCB0aGUgcmVtYWluaW5nIHRleHQgKFdvcmsgSXRlbXMsIERlbGl2
ZXJhYmxlcykuIEkgaGF2ZSBhIGZldyBtb3JlIGVkaXRvcmlhbCBjb21tZW50cyAoZS5nLiBzL3N0
YXJ0ZWQgd29yayByZWxhdGluZy9zdGFydGVkIHdvcmsgcmVsYXRlZCksIGJ1dCB3ZSBjYW4gaGFu
ZGxlIHRoYXQgb2ZmbGluZS4NCg0KQmVzdCByZWdhcmRzLA0KDQpLb3N0YXMNCg0KUFM6IEkgdG9v
ayB0aGUgbGliZXJ0eSB0byBDQyBOTVJHIGFzIHNvbWUgZm9sa3MgaW4gdGhhdCBncm91cCBtYXkg
aGF2ZSBhbiBpbnRlcmVzdCBpbiB0aGlzIGxpbmUgb2Ygd29yay4NCg0KfCBWb246IFBhcnZpeiBZ
ZWdhbmkgW21haWx0bzpweWVnYW5pQGdtYWlsLmNvbV0gDQp8IEdlc2VuZGV0OiBTYW1zdGFnLCAy
Ny4gU2VwdGVtYmVyIDIwMTQgMDY6MDcNCnwgQW46IEdlb3JnaW9zIEthcmFnaWFubmlzDQp8IENj
OiBzdXBhQGlldGYub3JnDQp8IEJldHJlZmY6IFJlOiBbU3VwYV0gTmV3IFNVUEEgY2hhcnRlcg0K
fA0KfCBHcmVhdCBqb2IgR2Vvcmdpb3MuIFRoZSBjaGFydGVyIGlzIHdlbGwgd3JpdHRlbiBhbmQg
bmljZWx5IHN0cnVjdHVyZWQuIFRoZSBub3Rpb24gb2YgIm5ldHdvcmsgYm94ZXMiLCBob3dldmVy
LCANCnwgaXMgYSBiaXQgY29uZnVzaW5nLiBJJ2QgcmF0aGVyIHRvIHJlcGxhY2UgaXQgd2l0aCAi
bmV0d29yayBub2RlcyIgb3IgIm5ldHdvcmsgY29tcG9uZW50cyIuIEkgYWxzbyBoYXZlDQp8IHNv
bWUgb3RoZXIgbWlub3IgZWRpdG9yaWFsIGNvbW1lbnRzLiBJIHdpbGwgc2VuZCBpdCBpbiBhIHNl
cGFyYXRlIGVtYWlsLiBJdCdzIGdvb2QgdGhhdCB5b3UgbWVudGlvbmVkIHRoZQ0KfCBTVVBBIFdH
IChvbmNlIGZvcm1lZCkgd2lsbCBjb2xsYWJvcmF0ZSB3aXRoIG90aGVyIHJlbGV2YW50IGdyb3Vw
cyB3aXRoaW4gSUVURiAoTkVUQ09ORiwgWWFuZyBkb2N0b3JzLCAuLikNCnwgdG8gZW5zdXJlIGNv
bnNpc3RlbmN5IGFuZCBhdm9pZCBkaXZlcmdlbmNlIG9yIHBlcmhhcHMgYW55IHBvc3NpYmxlIGR1
cGxpY2F0aW9uIG9mIHdvcmsuDQoNCnwgVGhhbmtzLA0KfCBQYXJ2aXoNCg==


From nobody Mon Sep 29 11:03:38 2014
Return-Path: 
X-Original-To: supa@ietfa.amsl.com
Delivered-To: supa@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 319481A8A15 for ; Mon, 29 Sep 2014 11:03:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.686
X-Spam-Level: 
X-Spam-Status: No, score=-14.686 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, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, 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 fVxmxcLVOYjY for ; Mon, 29 Sep 2014 11:03:29 -0700 (PDT)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 900311A9104 for ; Mon, 29 Sep 2014 11:03:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=35909; q=dns/txt; s=iport; t=1412013809; x=1413223409; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=UtD4U9EJL3ij4EcuM1EXZHgm9BdQfh1jeS63mNt73uc=; b=JHow9GA8vmyQ+5y2GMlOz8p3ClkujmyfYv5WQmrDJczT0pQeBL2JACsP iSlKVD88BaXTe+KlLnEs89dGpxLRkaGTBWHK6BHX+WUQy+qT/9+SqQM6M erridSAyle3H2thDPXNEkgAYoKYC5OBbD654cg+akkypZBcZqo45LyV02 I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ah0FAGieKVStJA2J/2dsb2JhbABggkhGU1vRYwKBFBYBe4QEAQEEDgwTOAcGBAMQAgEIFQ0WAQ0yJQEBBA4NiDa/UQEXj0YnDSQHgy6BHQWEYY0EhniBepgug2OBciIggQIBAQE
X-IronPort-AV: E=Sophos; i="5.04,621,1406592000"; d="scan'208,217"; a="82431529"
Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-3.cisco.com with ESMTP; 29 Sep 2014 18:03:27 +0000
Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s8TI3Rio017199 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 29 Sep 2014 18:03:27 GMT
Received: from xmb-aln-x11.cisco.com ([169.254.6.41]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0195.001; Mon, 29 Sep 2014 13:03:26 -0500
From: "Eric Voit (evoit)" 
To: Georgios Karagiannis 
Thread-Topic: New SUPA charter
Thread-Index: Ac/ZIUcaEK+SU+lYTNqeRV6T6bQAHwC5BFlg
Date: Mon, 29 Sep 2014 18:03:25 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.116.134.135]
Content-Type: multipart/alternative; boundary="_000_EF64FF31F4C4384DBCE5D513A791C2B120A3C22Axmbalnx11ciscoc_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/supa/PuLGn-ZvM8JGxDwGQxC1lnoOrZc
Cc: "supa@ietf.org" 
Subject: Re: [Supa] New SUPA charter
X-BeenThere: supa@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 29 Sep 2014 18:03:37 -0000

--_000_EF64FF31F4C4384DBCE5D513A791C2B120A3C22Axmbalnx11ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi George,

I like the intent of SUPA.  And that means I am going to make a lot of comm=
ents below :-).   Beyond that, I have two general comments on new items whi=
ch could be considered for scope.

Comment #1: Focus on standardizing where the network element APIs might als=
o change...
For me the highest value items to standardize are domain abstractions/model=
s which:
  (a) can be acted upon as a whole externally, and
  (b) have supporting implications requiring incremental work on the networ=
k elements.

There are such example mini-domain-abstractions in the IP control plane tod=
ay.   Consider VRRP, Anycast RP, ICCP: these are *very* close to domain pol=
icy abstractions.  To build on the lessons of these protocol types, how do =
we provide Policy abstractions which might be interesting *and* might need =
to support a dynamic convergence substrate?

The reason I am aiming here is that IETF standardization will be of most va=
lue where there is a distributed state machine linking activity across cont=
roller and network element. My suspicion is that many new service offerings=
 which are purely "controller models" (i.e., requiring only existing networ=
k element interfaces) will likely be fleshed out in Open Source venues firs=
t.   If we don't pay attention to where we are different from Open Source, =
we could end up forced to rubber stamp Open Source work in SUPA.

Comment #2: What about networks with Multiple Controllers?
Eventually there will be many interacting controllers in the network.  A hi=
storical proof-point is the old phone network which had 800/freephone, Mobi=
lity, Local number portability, and other controllers tied to the SS7 netwo=
rk.  This pattern will repeat with IP network controllers.  Huge monolithic=
 controllers will never dominate.   So in cases where there are multiple co=
ntrollers touching a single device, how to you resolve domain and device co=
nsistency issues?

IMHO, the SUPA network Policy group could be chartered to handle these reco=
nciliations.  In the end, these really are Policy reconciliation questions =
at the domain level.  The charter as written below is close to hitting that=
.

Anyway, my comments below do not focus on the two comments above, and are i=
ntended to hit just the text below...

From: Supa, September 25, 2014 8:32 PM

Hi all,

We have worked out all comments that we have received on the previous versi=
on of the SUPA charter.
The new version of the charter can be seen below:

Best regards,
Georgios


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
SUPA (Shared Unified Policy Automation) charter v1.12
Target Area: Operations and Management

Description of Working Group:

Programmatic ways to configure networks, often called software-defined, are=
 considered by many network operators in order to shift the balance in thei=
r favor.

 Versus equipment vendors? Versus end-user customers?  There is plent=
y of new value for all.

Automating the way of exposing a view of the network to applications may pr=
ovide significant improvements in configuration agility, error detection an=
d uptime for operators. However the real value behind central configuration=
 schemes lies within the possible simplification through models provided by=
 such systems to applications and network services running above them (on t=
he so-called northbound side). Well-designed models are able to provide a w=
ide range of granularity for various applications and network services need=
s, from the lower-level physical network to high-level application services=
.

 From below in SUPA goals, it looks like SUPA might be considering mo=
dels and enforcement between layers.  An L3VPN service might feel the same =
to an end user.   But an operator's underlying technology choices make expo=
sure of technology and operational knobs very different. Especially across =
different classes of operators.  There are dozens of ways of fulfilling the=
 L3VPN abstraction.  Describing the bindings digestibly to those who will c=
onsume which models in a way which also provides reuse will be non-trivial.

Several organizations outside of the IETF have defined various schemes for =
the configuration of network devices and specific network controllers, but =
none of them offer a vendor-neutral standardized way for applications and n=
etwork services to transmit their needs to network controllers. The SUPA (S=
hared Unified Policy Automation) working group will work on the definition =
of such as standardized interface for applications and network services to =
communicate with network controllers of all types. In particular, SUPA will=
 focus on service specific models that allow applications to request certai=
n network services to be created/deleted/modified.

 This will mean that the device servicing the SUPA abstraction will b=
e able to commit create/delete/modify across a set of authoritative datasto=
res within its domain.  This could even mean info authoritatively owned in =
different controllers. This can be done, but requires negotiation protocols=
 under the covers to describe which transactions can be committed.  Doing t=
his well means knowing how to revoke commitments as network conditions chan=
ge.

A network service can for example be a virtual link between two endpoints t=
hat uses certain properties, traffic engineering, implementation of IPv6 tr=
ansition mechanism and their enforcement to users.

Each network service can be represented by a service based POLICY model tha=
t can model a group of demands (i.e., actions and constraints) that are bei=
ng initiated by applications that impose similar requirements on the commun=
ication network. The terms "UNIFIED" and "SHARED" used in the SUPA abbrevia=
tion, relate to the way of how the service policy model is generated, since=
 it groups, unifies and shares the similar requirements imposed by a bulk o=
f applications. SUPA will provide guidelines for mechanisms that can dynami=
cally and on an interoperable manner, AUTOMATICALLY map services and polici=
es defined on an abstract topology graph down to more detailed network grap=
hs and specific network management and controlling policies.

 I like this paragraph.  It highlights that various subsets of networ=
k elements have abstractions which can be controlled from the outside for a=
 set purpose.

Some IETF working groups have started work relating to the description of v=
arious topologies such as I2RS (L3 and routing topologies), ALTO (cost maps=
), SFC (service chain), none of these groups aim (1) at offering truly gene=
ric topology models for the standard northbound interface, and (2) that an =
application can communicate with network boxes, such as network controllers=
, and NEs, developed by different vendors.

 Do you have examples of such models?   Especially ones where there a=
re not WG drafts somewhere else?   The very hard part will be describing a =
higher level of abstraction which is really usable by the IETF WGs listed a=
bove.  This value statement should soon be matched with an example model wh=
ich serves the set of technologies above.

SUPA will work on defining vendor-neutral standardized interfaces based on =
the concept of network graph, an entity describing an arbitrary topology of=
 nodes and links at any level of granularity. Such a network graph describe=
s (1) topologies at different levels of abstraction, (2) the relationships =
between the abstraction levels and (3) applied service based policy, which =
are actions and constraints applied on these topologies.
SUPA may also define any mappings to any other network topology data models=
 defined within the IETF.

 This need not just be about graphs.  Also see notes below about main=
taining flexibility when trying at the same time to maintain relationships =
between abstraction levels.

The main goal of SUPA is to provide service specific models that allow appl=
ications to request network services to be created/deleted/modified.


This can be realized by:
  o) model multiple topologies at different levels of abstraction using a n=
etwork graph,

 Just topologies?   There is a whole set of Policies which are not to=
pology which are (simpler?) unsolved problems.   Based on work item 2 below=
, at minimum you should be able to add the word Policy here.

  o) model the relationships between the abstraction levels.

 This means you are binding the different abstraction models via logi=
c / state machines.  What happens when one abstraction widely disconnects f=
rom existing lower level abstractions?  Is this dis-allowed?  This will be =
common for L3VPN, there are a huge number of ways to deliver the abstractio=
n.

  o) transporting model instances using either NETCONF or RESTCONF

SUPA will ensure that in case any specific NETCONF/RESTCONF protocol requir=
ements are identified, they will be communicated in a timely manner to the =
NETCONF working group. SUPA will consult with the YANG doctors to ensure th=
at data models follow common practices.

Work items for SUPA include:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D
1) The definition of a standardized model for a network graph, using YANG. =
This model may be used to describe topologies at any functional layer, from=
 physical networks to network services.

 "Any functional layer" might be hard.  To do this, the model will ha=
ve to be very "meta".  Meta is fine, but this means you will have to descri=
be relationships between layers in terms of values for specific objects.

2) The definition and standardization of a number of basic policy and data =
models using network graphs. These might include, but are not limited to L3=
VPNs, traffic engineering, implementation of IPv6 transition mechanism and =
their enforcement to users.
3) Provide guidelines for mechanisms that can dynamically and on an interop=
erable manner, automatically map services and policies defined on an abstra=
ct topology graph down to more detailed network graphs and specific network=
 management and controlling policies.

 As I note above, L3PVN is one which particular worries me.  Especial=
ly as it relates to "model the relationships between the abstraction levels=
" above.  There is such a volume of implementation methods and users, I don=
't know what we gain here by formalizing the layered dependencies.   AFAIK,=
 there will be an explosion of variants below the 1st level of abstraction.

Eric


4) Guidelines on how to use NETCONF (or RESTCONF) authentication and author=
ization mechanisms to achieve protection and isolation

Deliverables:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
o) Produce an informational RFC "Problem Statement and Use Cases".
o) Produce a standards-track RFC that specifies YANG models for a generic m=
ulti-layer network graph.
o) Produce standards-track RFCs that specify extensions for the generic YAN=
G models defined above for network services that manage virtual links, traf=
fic engineering and implementation of IPv6 transition mechanism and their e=
nforcement to users.
o) Produce an informational RFC that provides the guidelines for mechanisms=
 that can dynamically and on interoperable manner, automatically map servic=
es and policies defined on an abstract topology graph down to more detailed=
 network graphs and specific network management and controlling policies.
o) Produce an informational RFC that provides the guidelines on using NETCO=
NF (or RESTCONF) authentication and authorization mechanisms to achieve sec=
urity protection and isolation' as an Informational RFC.

Milestones:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Dec 2014  Initial "Problem Statement and Use Cases" WG I-D
Feb 2015  Initial "Multi-layer Network Graph YANG Model" WG I-D
Apr 2015  Initial service specific data model WG I-Ds
May 2015  Initial "Mapping Guidelines" WG I-D
Jun 2015  Submit "Problem Statement and Use Cases" I-D to IESG
Jul 2015  Initial "Authentication and Authorization" WG I-D
Sep 2015  Submit "Multi-layer Network Graph YANG Model" I-D to IESG
Nov 2015  Submit service specific data model I-Ds to IESG
Feb 2016  Submit "Mapping Guidelines" I-D to IESG
Apr 2016  Submit "Authentication and Authorization" I-D to IESG




--_000_EF64FF31F4C4384DBCE5D513A791C2B120A3C22Axmbalnx11ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi George,<=
/span>


 


I like the intent of S=
UPA.  And that means I am going to make a lot of comments below :-).&n=
bsp;  Beyond that, I have two general comments on new items which coul=
d be considered for scope. 



 


Comment #1: Focus o=
n standardizing where the network element APIs might also change…


For me the highest val=
ue items to standardize are domain abstractions/models which:


  (a) can be acte=
d upon as a whole externally, and



  (b) have s=
upporting implications requiring incremental work on the network elements.&=
nbsp;



 


There are such example=
 mini-domain-abstractions in the IP control plane today.   Consid=
er VRRP, Anycast RP, ICCP: these are *very* close to domain policy abstract=
ions.  To build on the lessons of these protocol
 types, how do we provide Policy abstractions which might be interesting *a=
nd* might need to support a dynamic convergence substrate? 



 


The reason I am aiming=
 here is that IETF standardization will be of most value where there is a d=
istributed state machine linking activity across controller and network ele=
ment. My suspicion is that many new
 service offerings which are purely “controller models” (i.e., =
requiring only existing network element interfaces) will likely be fleshed =
out in Open Source venues first.   If we don’t pay attentio=
n to where we are different from Open Source, we could end up
 forced to rubber stamp Open Source work in SUPA.


 


Comment #2: What ab=
out networks with Multiple Controllers?


Eventually there will =
be many interacting controllers in the network.  A historical proof-po=
int is the old phone network which had 800/freephone, Mobility, Local numbe=
r portability, and other controllers tied
 to the SS7 network.  This pattern will repeat with IP network control=
lers.  Huge monolithic controllers will never dominate.   So=
 in cases where there are multiple controllers touching a single device, ho=
w to you resolve domain and device consistency issues?  



 


IMHO, the SUPA network=
 Policy group could be chartered to handle these reconciliations.  In =
the end, these really are Policy reconciliation questions at the domain lev=
el.  The charter as written below is close
 to hitting that.


 


Anyway, my comments be=
low do not focus on the two comments above, and are intended to hit just th=
e text below…


 








From: Supa, Se=
ptember 25, 2014 8:32 PM










Hi all,


 


We have worked out all comments that we have receive=
d on the previous version of the SUPA charter.


The new version of the charter can be seen below:


 


Best regards,


Georgios


 


 


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D


SUPA (Shared Unified Policy Automation) charter v1.1=
2


Target Area: Operations and Management

 


Description of Working Group:


 


Programmatic ways to configure networks, often calle=
d software-defined, are considered by many network operators in order to sh=
ift the balance in their favor.


 


<Eric> Versus equipment vendors? Versus end-user custo=
mers?  There is plenty of new value for all.


 


Automating the way of exposing a view of the network=
 to applications may provide significant improvements in configuration agil=
ity, error detection and uptime for operators. However the real value behin=
d central configuration schemes lies
 within the possible simplification through models provided by such systems=
 to applications and network services running above them (on the so-called =
northbound side). Well-designed models are able to provide a wide range of =
granularity for various applications
 and network services needs, from the lower-level physical network to high-=
level application services.



 


<Eric> From belo=
w in SUPA goals, it looks like SUPA might be considering models and enforce=
ment between layers.  An L3VPN service might feel the same to an end u=
ser.   But an operator’s underlying technology
 choices make exposure of technology and operational knobs very different. =
Especially across different classes of operators.  There are dozens of=
 ways of fulfilling the L3VPN abstraction.  Describing the bindings di=
gestibly to those who will consume which models
 in a way which also provides reuse will be non-trivial.<=
/p>

 


Several organizations outside of the IETF have defin=
ed various schemes for the configuration of network devices and specific ne=
twork controllers, but none of them offer a vendor-neutral standardized way=
 for applications and network services
 to transmit their needs to network controllers. The SUPA (Shared Unified P=
olicy Automation) working group will work on the definition of such as stan=
dardized interface for applications and network services to communicate wit=
h network controllers of all types.
 In particular, SUPA will focus on service specific models that allow appli=
cations to request certain network services to be created/deleted/modified.



 


<Eric> This will=
 mean that the device servicing the SUPA abstraction will be able to commit=
 create/delete/modify across a set of authoritative datastores within its d=
omain.  This could even mean info authoritatively
 owned in different controllers. This can be done, but requires negotiation=
 protocols under the covers to describe which transactions can be committed=
.  Doing this well means knowing how to revoke commitments as network =
conditions change.


 


A network service can for example be a virtual link =
between two endpoints that uses certain properties, traffic engineering, im=
plementation of IPv6 transition mechanism and their enforcement to users.


 


Each network service can be represented by a service=
 based POLICY model that can model a group of demands (i.e., actions and co=
nstraints) that are being initiated by applications that impose similar req=
uirements on the communication network.
 The terms "UNIFIED" and "SHARED" used in the SUPA abbr=
eviation, relate to the way of how the service policy model is generated, s=
ince it groups, unifies and shares the similar requirements imposed by a bu=
lk of applications. SUPA will provide guidelines for
 mechanisms that can dynamically and on an interoperable manner, AUTOMATICA=
LLY map services and policies defined on an abstract topology graph down to=
 more detailed network graphs and specific network management and controlli=
ng policies.


 


<Eric> I like th=
is paragraph.  It highlights that various subsets of network elements =
have abstractions which can be controlled from the outside for a set purpos=
e. 



 


Some IETF working groups have started work relating =
to the description of various topologies such as I2RS (L3 and routing topol=
ogies), ALTO (cost maps), SFC (service chain), none of these groups aim (1)=
 at offering truly generic topology
 models for the standard northbound interface, and (2) that an application =
can communicate with network boxes, such as network controllers, and NEs, d=
eveloped by different vendors.


 


<Eric> Do you ha=
ve examples of such models?   Especially ones where there are not=
 WG drafts somewhere else?   The very hard part will be describin=
g a higher level of abstraction which is really usable by the
 IETF WGs listed above.  This value statement should soon be matched w=
ith an example model which serves the set of technologies above.=



 


SUPA will work on defining vendor-neutral standardiz=
ed interfaces based on the concept of network graph, an entity describing a=
n arbitrary topology of nodes and links at any level of granularity. Such a=
 network graph describes (1) topologies
 at different levels of abstraction, (2) the relationships between the abst=
raction levels and (3) applied service based policy, which are actions and =
constraints applied on these topologies.



SUPA may also define any mappings to any other netwo=
rk topology data models defined within the IETF.


 


<Eric> This need=
 not just be about graphs.  Also see notes below about maintaining fle=
xibility when trying at the same time to maintain relationships between abs=
traction levels.


 


The main goal of SUPA is to provide service specific=
 models that allow applications to request network services to be created/d=
eleted/modified.



 


 


This can be realized by:


  o) model multiple topologies at different lev=
els of abstraction using a network graph,



 


<Eric> Just topo=
logies?   There is a whole set of Policies which are not topology=
 which are (simpler?) unsolved problems.   Based on work item 2 b=
elow, at minimum you should be able to add the word Policy here.=



 


  o) model the relationships between the a=
bstraction levels.


 


<Eric> This mean=
s you are binding the different abstraction models via logic / state machin=
es.  What happens when one abstraction widely disconnects from existin=
g lower level abstractions?  Is this dis-allowed? 
 This will be common for L3VPN, there are a huge number of ways to deliver =
the abstraction.



 


  o) transporting model instances using either =
NETCONF or RESTCONF



 


SUPA will ensure that in case any specific NETCONF/R=
ESTCONF protocol requirements are identified, they will be communicated in =
a timely manner to the NETCONF working group. SUPA will consult with the YA=
NG doctors to ensure that data models
 follow common practices.


 


Work items for SUPA include:


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


1) The definition of a standardized model for a netw=
ork graph, using YANG. This model may be used to describe topologies at any=
 functional layer, from physical networks to network services.



 


<Eric> “An=
y functional layer” might be hard.  To do this, the model will h=
ave to be very “meta”.  Meta is fine, but this means you w=
ill have to describe relationships between layers in terms of values for sp=
ecific
 objects.


 


2) The definition and standardization of a number of=
 basic policy and data models using network graphs. These might include, bu=
t are not limited to L3VPNs, traffic engineering, implementation of IPv6 tr=
ansition mechanism and their enforcement
 to users.  


3) Provide guidelines for mechanisms that can dynami=
cally and on an interoperable manner, automatically map services and polici=
es defined on an abstract topology graph down to more detailed network grap=
hs and specific network management
 and controlling policies.


 


<Eric> As I note=
 above, L3PVN is one which particular worries me.  Especially as it re=
lates to “model the relationships between the abstraction levels̶=
1; above.  There is such a volume of implementation methods
 and users, I don’t know what we gain here by formalizing the layered=
 dependencies.   AFAIK, there will be an explosion of variants be=
low the 1st level of abstraction.


 


Eric=



 


 


4) Guidelines on how to use NETCONF (or RESTCONF) au=
thentication and authorization mechanisms to achieve protection and isolati=
on


 


Deliverables:


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

o) Produce an informational RFC "Problem Statem=
ent and Use Cases".


o) Produce a standards-track RFC that specifies YANG=
 models for a generic multi-layer network graph.


o) Produce standards-track RFCs that specify extensi=
ons for the generic YANG models defined above for network services that man=
age virtual links, traffic engineering and implementation of IPv6 transitio=
n mechanism and their enforcement
 to users.


o) Produce an informational RFC that provides the gu=
idelines for mechanisms that can dynamically and on interoperable manner, a=
utomatically map services and policies defined on an abstract topology grap=
h down to more detailed network graphs
 and specific network management and controlling policies.


o) Produce an informational RFC that provides the gu=
idelines on using NETCONF (or RESTCONF) authentication and authorization me=
chanisms to achieve security protection and isolation' as an Informational =
RFC.


 


Milestones:


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


Dec 2014  Initial "Problem Statement and U=
se Cases" WG I-D


Feb 2015  Initial "Multi-layer Network Gra=
ph YANG Model" WG I-D


Apr 2015  Initial service specific data model W=
G I-Ds 


May 2015  Initial "Mapping Guidelines"=
; WG I-D


Jun 2015  Submit "Problem Statement and Us=
e Cases" I-D to IESG


Jul 2015  Initial "Authentication and Auth=
orization" WG I-D


Sep 2015  Submit "Multi-layer Network Grap=
h YANG Model" I-D to IESG


Nov 2015  Submit service specific data model I-=
Ds to IESG


Feb 2016  Submit "Mapping Guidelines"=
 I-D to IESG


Apr 2016  Submit "Authentication and Autho=
rization" I-D to IESG


 


 


 








--_000_EF64FF31F4C4384DBCE5D513A791C2B120A3C22Axmbalnx11ciscoc_--


From nobody Mon Sep 29 12:01:43 2014
Return-Path: 
X-Original-To: supa@ietfa.amsl.com
Delivered-To: supa@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A4481A923C for ; Mon, 29 Sep 2014 12:01:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.687
X-Spam-Level: 
X-Spam-Status: No, score=-2.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, 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 m_9k9QlfHQen for ; Mon, 29 Sep 2014 12:01:39 -0700 (PDT)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id E20CE1A9250 for ; Mon, 29 Sep 2014 12:01:15 -0700 (PDT)
Received: from h200.viagenie.ca (h200.viagenie.ca [206.123.31.200]) by jazz.viagenie.ca (Postfix) with ESMTPSA id D7F4240411 for ; Mon, 29 Sep 2014 15:01:13 -0400 (EDT)
From: JF Tremblay 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Message-Id: <20692108-1D70-41AC-964F-52591C9DD993@viagenie.ca>
Date: Mon, 29 Sep 2014 15:01:13 -0400
To: supa@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/supa/zvdfHrUgJKdIqgj-QDLLZW7wiwo
Subject: [Supa] Review of draft-zaalouk-supa-configuration-model-00
X-BeenThere: supa@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 29 Sep 2014 19:01:41 -0000

I read draft-zaalouk-supa-configuration-model-00.=20

It provides an interesting starting set for the models to be defined in =
supa. Whether these should be tackled as a single draft or one for each =
model is debatable. Both approaches have advantages, but having them =
together would be desirable if some of the modelling is re-used between =
models. Having them separated would allow for the work to be more =
modular and to advance them separately if some have a consensus and not =
others.=20

That said, each model seems to be fairly independent at this moment, =
there=92s no re-use of common topology modelling between each of them, =
even if some of the elements seem to be fairly similar. For example, in =
the TE model, a pathNode and nodeID are used for configuration, but =
PathResult and PathResultNode are used for reporting. Why not define a =
common model that works both ways? There=92s also a nodeID and type =
defined in the flow model. There would be significant advantages in =
having these different models using the topology language, for example =
the one defined in draft-contreras-supa-yang-network-topo.=20

Some more specific comments about the draft below:=20
Introduction:=20
- First paragraph. Not sure why RFC2473 is mentioned there, since it=92s =
about IPv6 tunnelling.=20
- Second paragraph. This is a single sentence of 9 lines. Breaking it =
down in smaller pieces would certainly make it more readable. Also, it =
refers to APONF-architecture.=20
- Third paragraph. This text seems to hint heavily at RESTCONF. As =
Juerguen mentioned in a previous post, NETCONF is more complex but has =
some advantages compared to RESTCONF, such as being able to manage =
multiple versions of the configuration (for example a current one before =
=93committing=94).=20

L3VPN
- The models could use a bit more descriptions. For example, in a =
hub-and-spoke topology, how is the hub defined? Is it the role leaf? =
What type of identifier is phyAcIfId?
- Why is there a username and password at the interface level?=20
- The interface seems to be focused on PE-CE edge side. What happens if =
the application would like the details of the VPN configuration =
reported? (RD, RT, RR used, RT filter, etc) Would that be handled in =
another interface?
- I don=92t see any way to perform route filtering. This would be =
important in a PE-CE context.=20

Flows
- Missing a =91e=92 in module SUPA-servicflow ?
- Are sourcePrefix and destinationPrefix actually masks?=20
- What is the prefix leaf? It=92s only specified as an IP address, so it =
wouldn=92t reflect an actual prefix.=20
- How are policies mapped to flows? By the flow name only?=20
- The definition and usage for the =93Terminal Point Key=94 and =
=93Terminal Key ID=94 is a bit unclear, some description would be =
useful.=20

IP TE
- First sentence: "The network connection between data centers is =
usually leased=85=94. This is quite a strong statement. You might want =
to soften the language here (s/usually/often/) or put a reference, as =
I=92m not sure this is true for all operators.=20
- Why not use a common definition of flows in this model and the =
preceding one?
- What is iptePathResultNodes exactly? An ordered list of nodes =
describing the traffic path?=20
- Each iptePathResult seems to carry a single iptePrefixName and path, =
while an ipteFlow seems to carry multiple prefixes and and paths. What =
would be the logic behind this way of organizing data?

Tunnels:=20
- The combinaisons of ip tunnels (ip-in-ip, ip-in-ipv6, etc) seem to be =
missing from tunnelType. Also, what are bgp and ldp tunnels?


Again, this is a nice starting point for the discussion about models, =
but I=92m sure there would ways to re-use common parts of the models =
instead of repeating a lot of what seems to be the same structures in =
each one. Also, the description of each model could be fleshed out a =
bit, as the role of each element is not always obvious from the =
description.=20

JF






=20


From nobody Mon Sep 29 12:35:37 2014
Return-Path: 
X-Original-To: supa@ietfa.amsl.com
Delivered-To: supa@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 965D11A930A for ; Mon, 29 Sep 2014 12:35:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.687
X-Spam-Level: 
X-Spam-Status: No, score=-2.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, 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 syLuqPMVzOGB for ; Mon, 29 Sep 2014 12:35:35 -0700 (PDT)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 566F91A8885 for ; Mon, 29 Sep 2014 12:35:30 -0700 (PDT)
Received: from h200.viagenie.ca (h200.viagenie.ca [206.123.31.200]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 0B1B6415A9 for ; Mon, 29 Sep 2014 15:35:28 -0400 (EDT)
From: JF Tremblay 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Message-Id: <69CD2340-92AA-4095-8E27-B6EBA069206D@viagenie.ca>
Date: Mon, 29 Sep 2014 15:35:28 -0400
To: supa@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/supa/Y8v5gHr6EiuO3UumLhJKEI63v9g
Subject: [Supa] Review of draft-pentikousis-supa-mapping-00
X-BeenThere: supa@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 29 Sep 2014 19:35:36 -0000

After reading draft-pentikousis-supa-mapping-00, some concepts of supa =
remain unclear to me. It=92s not easy to put a finger on exactly what, =
but I=92ll try to describe it below.=20

=46rom reading the other supa drafts, it seems a supa-compliant entity =
(controller?) expose a number of abstract models in an interfaces to =
=93higher=94 applications (management or others). This is what the work =
in draft-contreras and draft-zaalouk seem to refer to. In that sense, I =
would expect a =93mapping=94 to happen internally between these abstract =
models and a physical topology. This way, the supa entity would maintain =
consistency between different abstract topologies and the physical =
topology.=20

However, according to this draft, there=92s only one topology being =
maintained and it seemed to be the physical one (=93...a topology module =
maintains the topology of the network infrastructure=85=94). This is =
reinforced in section 3.2: " ... the network service system acquires the =
topology information [...] if it needs some knowledge of the underlying =
network=85=94. And then in section 3.3: "...the NSS can decide=85=94. It =
seems the =93network management and control system=94 is purely a =
physical controller and the NSS is actually making decisions. So, in the =
end, if the NSS accesses the underlying network topology only, where are =
the supa abstractions used?=20

A few minor edits/comments:=20
- Introduction: draft-zhou-supa-architecture-00 is referenced but does =
not seem to exist at that url.
- Introduction: in the last paragraph, an ABPD module is discussed, but =
does not appear in figure 1.=20
- Page 8 and 9: s/quite/quit/ I guess=85=20

JF

=20




From nobody Mon Sep 29 18:57:10 2014
Return-Path: 
X-Original-To: supa@ietfa.amsl.com
Delivered-To: supa@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBA671A00C0 for ; Mon, 29 Sep 2014 18:57:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.999
X-Spam-Level: 
X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L6FywcxmP4kF for ; Mon, 29 Sep 2014 18:57:07 -0700 (PDT)
Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE3F21A00BF for ; Mon, 29 Sep 2014 18:57:07 -0700 (PDT)
Received: by mail-yk0-f182.google.com with SMTP id 131so926060ykp.27 for ; Mon, 29 Sep 2014 18:57:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:from:date:message-id:subject:to:cc:content-type;  bh=vCFNgunLcZ1MMq8aIMhkuctG2JhD4rKedOZv/bJuG6k=; b=U8ix2TEpnits27cKdY0Fzkr8Na96cF2+iT8D8CiHvl7AyhzbimqebqRz1RxII6lL3b CAHm9W9Hnv9PIxwJsBquHe5W0HzcSowH9kiS19dbtiV0h82jOXAdP4Bcv0/+t4Dty/OG dDxBtUeejFUgEFHr8gbhyvL+xW1mpHViZPM1OOFqvG8NfGz9hP5w2vwr95sc4w/yM5mg cEjLmuW3M0sWoGJco4P4TKUBTm8nz1cscU4kmwP7zGJ6MEJfFnpqkyUOHauKHqkPcfe1 7RprmQF+DM/9dH8mxNKqU/EH9rdSkma0qIE49pEwMQz4SLriUX2LXGihmPGWTD0Mo4h4 mn5w==
X-Received: by 10.236.54.101 with SMTP id h65mr8674836yhc.47.1412042226897; Mon, 29 Sep 2014 18:57:06 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.170.111.209 with HTTP; Mon, 29 Sep 2014 18:56:26 -0700 (PDT)
From: Qiong 
Date: Tue, 30 Sep 2014 09:56:26 +0800
Message-ID: 
To: adel.ietf@gmail.com
Content-Type: multipart/alternative; boundary=bcaec508f59857999705043eb378
Archived-At: http://mailarchive.ietf.org/arch/msg/supa/mRSex5-7EdZuDAcB5u3LX1DQPjc
Cc: supa@ietf.org
Subject: [Supa]  Comments on draft-zaalouk-supa-configuration-model
X-BeenThere: supa@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Sep 2014 01:57:09 -0000

--bcaec508f59857999705043eb378
Content-Type: text/plain; charset=UTF-8

   Dear authors:

I took a look at this draft and have some comments:

There are 4 different models , IMHO irrelevant, in this draft. This may
make it harder if you want to update the model and add sub-models.
Therefore, I suggest to divide it into separate drafts to make each simple
and easy to update.

In section 4.1: According to the YANG model, the YANG tree may need to be
double checked. E.g., the type of "+--rw protocol*" may be enumeration? The
type of "+--rw acIfAddr?" may be "string"?

In section 4.2: You may consider to add the flow actions to the "+--rw
flowPolicys" part. As IMHO how to deal with a specific flow is a very
important part of the flow policy.

=================================
Qiong
China Telecom Beijing Research Institute
=================================


From: Adel Zaalouk [mailto:adel.ietf@gmail.com]
Sent: Monday, September 22, 2014 9:36 PM
To: supa@ietf.org
Cc: Liushucheng (Will); Kostas Pentikousis
Subject: SUPA Draft

Dear All,


The draft with the title of "YANG Data Model for Configuration of Shared
Unified Policy Automation (SUPA)" was submitted and posted to the IETF
repository [1].


[1] http://datatracker.ietf.org/doc/draft-zaalouk-supa-configuration-model/

Best regards,
Adel Zaalouk.

--bcaec508f59857999705043eb378
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable














Dear authors:

I took=
 a look at this draft and have some comments: 


=C2=A0


There are 4 different models , IMHO irrelevant, in this draft. This ma=
y=20
make it harder if you want to update the model and add sub-models. Therefor=
e, I=20
suggest to divide it into separate drafts to make each simple and easy to=
=20
update.


=C2=A0


In section 4.1: According to the YANG model, the YANG tree may need to=
 be=20
double checked. E.g., the type of "+--rw protocol*" may be enumer=
ation? The type=20
of "+--rw acIfAddr?" may be "string"?


=C2=A0


In section 4.2: You may consider to add the flow actions to the "=
+--rw=20
flowPolicys" part. As IMHO how to deal with a specific flow is a very =
important=20
part of the flow policy.


=C2=A0


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 


Qiong
China Telecom Beijing Research Institute 
=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D



=C2=A0


From: Adel Zaalouk [mailto:adel=
.ietf@gmail.com] 


Sent: Monday, September 22, 2014 9:36 PM



Cc: Liushucheng (Will); Kostas Pentikousis


Subject: SUPA Draft


=C2=A0


Dear All,=C2=A0


=C2=A0


=C2=A0


The draft with the title of "YANG Data Model for Configuration of=
=C2=A0Shared=20
Unified Policy Automation (SUPA)" was submitted and posted to the IETF=
=20
repository [1].=C2=A0


=C2=A0


=C2=A0



=C2=A0


Best regards,=C2=A0


Adel Zaalouk. 







--bcaec508f59857999705043eb378--


From nobody Mon Sep 29 20:17:56 2014
Return-Path: 
X-Original-To: supa@ietfa.amsl.com
Delivered-To: supa@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DF3A1A00F4 for ; Mon, 29 Sep 2014 20:17:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.131
X-Spam-Level: ***
X-Spam-Status: No, score=3.131 tagged_above=-999 required=5 tests=[BAYES_50=0.8, CN_BODY_103=0.327, CN_BODY_35=0.339, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RP_MATCHES_RCVD=-0.786] 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 hhDC_YAroFQG for ; Mon, 29 Sep 2014 20:17:48 -0700 (PDT)
Received: from sendg.mailex.chinaunicom.cn (sendg.mailex.chinaunicom.cn [210.53.66.230]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B86A51A00F3 for ; Mon, 29 Sep 2014 20:17:47 -0700 (PDT)
Received: from SBG8380-4.chinaunicom.cn (10.0.15.35) by M10-HQ-MLOUT01.cnc.intra (10.0.15.20) with Microsoft SMTP Server id 8.2.254.0; Tue, 30 Sep 2014 11:17:40 +0800
X-AuditID: 0a000f23-b7f086d000007809-2e-542a20d812f0
Received: from m10-cen-mlhub04.cnc.intra ( [10.0.192.44])	by SBG8380-4.chinaunicom.cn (Symantec Messaging Gateway) with SMTP id 78.91.30729.8D02A245; Tue, 30 Sep 2014 11:17:45 +0800 (HKT)
Received: from m10-hq-mlch01.hq.cnc.intra (10.0.15.26) by m10-cen-mlhub04.cnc.intra (10.0.192.44) with Microsoft SMTP Server (TLS) id 8.2.213.0; Tue, 30 Sep 2014 11:17:44 +0800
Received: from YingCheng-PC (114.255.193.232) by m10-hq-mlch01.hq.cnc.intra (10.0.15.26) with Microsoft SMTP Server id 8.2.213.0; Tue, 30 Sep 2014 11:17:44 +0800
Date: Tue, 30 Sep 2014 11:17:42 +0800
From: Ying Cheng 
To: Kostas Pentikousis 
Message-ID: <201409301117425344166@chinaunicom.cn>
X-mailer: Foxmail 6, 15, 201, 26 [cn]
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=====003_Dragon300070204577_====="
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBKsWRmVeSWpSXmKPExsXCxXBAR/emglaIwYxvXBZ7DuxntZi9ZRWz A5PHl/9NTB5LlvxkCmCKqrNJzMvLL0ksSVVISS1OtlUKzkzPSywpLUpV8C8tScovzUtRUshM sVUyVlIoyElMTs1NzSuxVUosKEgFythxKWAAG6CyzDyF1Lzk/JTMvHRbpdAQN10LJbuny5qe zZvzrGnFyykzX6xf/6xv6bMp2xKusGRs75rNWLAoouLkpsnMDYyvQrsYOTkkBEwk/jXOYYSw xSQu3FvP1sXIxSEksJdR4v72BlYIZwujxL6lh6EySxklLr8/zgzSwiKgKrHmzUKmLkYODjYB XYne9UYgYREBA4nu/TvBpjILKEv0rLnODmILC6hJNMzrZgWxeQWMJC5duMUKsVlV4mpbHxPE SDeJ//damCBqBCVOznzCAjEnWOLsgR0sIKuEBNQllt+ym8AoMAtJ1SwkVRC2lsS8ht9MELai xJTuh+wQtqbElcmH2JHFFzCyrWKUCHZytzC2MNA10UvOyMxLLM3LTM7P1UvO28QIjmd+5R2M D05YHmIU4GBU4uF9mKoZIsSaWFZcmXuIUYKDWUmEV24HUIg3JbGyKrUoP76oNCe1+BBjMtBP E5mlRJPzgakmryTe0NjCwtzY2NTE2MjYjDRhJXHemhPyIUIC6cCElJ2aWpBaBLOFiYNTqoFx tmvhDZ0vZyvYE1Ict4iGPXm/g0t452mfEPfLM0Ndf76WXJtUsCCUx+HQxHfqPB0K3uInUy+F 6fGKbVx34o9c9P3KJyGyc89kCEZUzd7Nwnit3vhojXrMmc0tffYszbcepe3gPX088OyyvhSB k3ymEp1aCpfebdD/zJct+4/D9ekVtnt6jv5KLMUZiYZazEXFiQC+5Q7+KwMAAA==
Archived-At: http://mailarchive.ietf.org/arch/msg/supa/OXAaOtKu4bHc7biLbmXf4OGNpRE
Cc: "supa@ietf.org" 
Subject: Re: [Supa] SUPA configuration
X-BeenThere: supa@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Sep 2014 03:17:53 -0000

--=====003_Dragon300070204577_=====
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64

SGkgS29zdGFzIGV0IGFsLA0KDQpJJ3ZlIHJlYWQgdGhlIGRyYWZ0IChTVVBBIENvbmZpZ3Vy
YXRpb24gYW5kIFBvbGljeSBNYXBwaW5nLCBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv
ZG9jL2RyYWZ0LXBlbnRpa291c2lzLXN1cGEtbWFwcGluZy8pIGFuZCBjb25zaWRlciB0aGF0
IGl0IHRhY2tsZXMgYSByZWFsIHByb2JsZW0gb2YgU1VQQS4gVGhlIGV4YW1wbGUgdGhlcmVp
biBhbGlnbnMgd2l0aCB3aGF0IHdlIHByb3Bvc2VkIGluIGRkYyB1c2UgY2FzZS4gQmVsb3cg
cGxlYXNlIGtpbmRseSBmaW5kIG15IGNvbW1lbnMuDQoNCkluIHNlY3Rpb24gMy4zIFNVUEEg
bWFwcGluZyBleGFtcGxlLCBpdCBpbGx1c3RyYXRlcyBob3cgdG8gbWFwIGNvbmZpZ3VyYXRp
b24gWUFORyBtb2RlbCBpbnRvIGRldmljZS1iYXNlZCBDTEkgd2l0aCB0aGUgYXNzaXN0YW5j
ZSBvZiB0b3BvbG9neSBZQU5HIG1vZGVsLiBIb3dldmVyLCBhcyBDTEkgaXMgdXN1YWxseSB2
ZW5kb3ItZGVwZW5kZW50LCBpdCdzIGEgbGl0dGxlIGNvbXBsaWNhdGVkIHRvIG1hcCBpbnRv
IENMSXMgZGlyZWN0bHkgKEFsdGhvdWdoIHRoZSBjb21wbGV4aXR5IGlzIG5vdCBzaG93ZWQg
dXAgaW4gdGhpcyBleGFtcGxlIC0tLSBBbGwgdGhlIENMSXMgc2VlbSB0byBmb2xsb3cgdGhl
IHNwZWNpZmljYXRpb24gb2YgdGhlIHNhbWUgdmVuZG9yKS4gSU1ITywgbWFwcGluZyBjb25m
aWd1cmF0aW9uIFlBTkcgbW9kZWwgaW50byBhIHZlbmRvci1uZXV0cmFsIGRldmljZS1sZXZl
bCBjb25maWd1cmF0aW9uIFlBTkcgbW9kZWwgZmlyc3RseSBpcyBtb3JlIGFwcHJvcHJpYXRl
LiBBZnRlciB0aGF0IHdlIGNhbiBtYXAgdGhlIHZlbmRvci1uZXV0cmFsIGRldmljZS1sZXZl
bCBjb25maWd1YXRpb24gWUFORyBtb2RlbCBpbnRvIGRpZmZlcmVudCB2ZW5kb3IncyBjb25m
aWd1cmF0aW9uIGludGVyZmFjZXMvbWV0aG9kcywgd2hpY2ggaXMgdmVuZG9yLWRlcGVuZGVu
dCBhbmQgaXMgbm90IHJlcXVpcmVkIHRvIGJlIHN0YW5kYXJkaXplZC4NCg0KUFMuIEl0IGlz
IGFsc28gc3VnZ2VzdGVkIHRvIGNvbnNpZGVyIHRvIHByb3ZpZGUgYSBtb3JlIGdlbmVyYWwg
ZGVzY3JpcHRpb24gb2YgbWFwcGluZyBtZWNoYW5pc20sIGluc3RlYWQgb2Ygb25seSBwcmVz
ZW50aW5nIGEgZGV0YWlsZWQgZXhhbXBsZSwgd2hpY2ggbWFrZXMgdGhpcyBkcmFmdCBsaW1p
dGVkIHRvIGEgc3BlY2lmaWMgc2NlbmFyaW8uDQoNCg0KQlIsDQpZaW5nDQoNCg0KDQoNCjIw
MTQtMDktMzAgDQoNCg0KDQpZaW5nIENIRU5HICCzzNOoDQpDaGluYSBVbmljb20gTmV0d29y
ayBUZWNobm9sb2d5IFJlc2VhcmNoIEluc3RpdHV0ZSDW0Ln6warNqM34wue8vMr10dC+v9S6
DQpUZWw6ICs4Ni0xMC02ODc5OTk5OS03NzAyDQpNb2JpbGU6ICs4Ni0xODYwMTEwMjk3MQ0K
DQoNCg0KDQoNCreivP7Iy6O6IEtvc3RhcyBQZW50aWtvdXNpcyANCreiy83Ksbzko7ogMjAx
NC0wOS0yMyAgMTc6MDQ6MTIgDQrK1bz+yMujuiBzdXBhQGlldGYub3JnIA0Ks63LzaO6IA0K
1vfM4qO6IFtTdXBhXSBTVVBBIGNvbmZpZ3VyYXRpb24gDQogDQpEZWFyIEFsbCwNCldlIGhh
dmUgYmVlbiB3b3JraW5nIG9uIHR3byBkcmFmdHMgb24gU1VQQSBjb25maWd1cmF0aW9uLiBU
aGUgZmlyc3Qgb25lIChTVVBBIENvbmZpZ3VyYXRpb24gYW5kIFBvbGljeSBNYXBwaW5nLCBo
dHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXBlbnRpa291c2lzLXN1cGEt
bWFwcGluZy8pIGRpc2N1c3NlcyBtYXBwaW5nIG9mIGFuIGFic3RyYWN0IHZpZXcgdG8gZGV2
aWNlLWxldmVsIGNvbmZpZ3VyYXRpb24uIFRoZSBzZWNvbmQgb25lIChZQU5HIERhdGEgTW9k
ZWwgZm9yIENvbmZpZ3VyYXRpb24gb2YgU2hhcmVkIFVuaWZpZWQgUG9saWN5IEF1dG9tYXRp
b24gKFNVUEEpLCBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC16YWFs
b3VrLXN1cGEtY29uZmlndXJhdGlvbi1tb2RlbC8pIGludHJvZHVjZXMgb3VyIGVhcmx5IHN0
YWdlIHdvcmsgb24gYSBmZXcgWUFORyBtb2RlbHMgZm9yIEwzVlBOLCBJUCBURSBldGMuDQpX
ZSdyZSBsb29raW5nIGZvcndhcmQgdG8geW91ciBjb21tZW50cyBhbmQgc3VnZ2VzdGlvbnMu
IA0KQmVzdCByZWdhcmRzLA0KS29zdGFzDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXw0KU3VwYSBtYWlsaW5nIGxpc3QNClN1cGFAaWV0Zi5vcmcN
Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3VwYQ0KLg0KDQrI57n7
xPq07c7zvdPK1cHLuMPTyrz+o6zH682ouf2159fT08q8/sGivLTNqNaqztLDx6Gjx+u72Li0
08q8/rW9aHFzLXNwbWNAY2hpbmF1bmljb20uY26jrLy0v8nS1M3Ltqm0y9PKvP6ho87Sw8e9
q8GivLS9q8T6tcTQxc+itNPO0sPHtcS3osvNxL/CvNbQyb6z/aGjDQpJZiB5b3UgaGF2ZSBy
ZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdXMgaW1tZWRpYXRl
bHkgYnkgZS1tYWlsLiBQbGVhc2UgcmVwbHkgdG8gaHFzLXNwbWNAY2hpbmF1bmljb20uY24g
aWYgeW91IHdhbnQgdG8gdW5zdWJzY3JpYmUgZnJvbSB0aGlzIG1haWwuIFdlIHdpbGwgaW1t
ZWRpYXRlbHkgcmVtb3ZlIHlvdXIgaW5mb3JtYXRpb24gZnJvbSBvdXIgc2VuZGluZyBjYXRh
bG9ndWUuDQo=

--=====003_Dragon300070204577_=====
Content-Type: text/html; charset="gb2312"
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u
YWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFy
c2V0PWdiMjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBuYW1lPUdFTkVS
QVRPUiBjb250ZW50PSJNU0hUTUwgOC4wMC43NjAxLjE3NTE0Ij4NCjxTVFlMRT5AZm9udC1m
YWNlIHsNCglmb250LWZhbWlseTogy87M5TsNCn0NCkBmb250LWZhY2Ugew0KCWZvbnQtZmFt
aWx5OiBWZXJkYW5hOw0KfQ0KQGZvbnQtZmFjZSB7DQoJZm9udC1mYW1pbHk6IEDLzszlOw0K
fQ0KQHBhZ2UgU2VjdGlvbjEge3NpemU6IDU5NS4zcHQgODQxLjlwdDsgbWFyZ2luOiA3Mi4w
cHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7IGxheW91dC1ncmlkOiAxNS42cHQ7IH0NClAuTXNv
Tm9ybWFsIHsNCglURVhULUpVU1RJRlk6IGludGVyLWlkZW9ncmFwaDsgVEVYVC1BTElHTjog
anVzdGlmeTsgTUFSR0lOOiAwY20gMGNtIDBwdDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcg
Um9tYW4iOyBGT05ULVNJWkU6IDEwLjVwdA0KfQ0KTEkuTXNvTm9ybWFsIHsNCglURVhULUpV
U1RJRlk6IGludGVyLWlkZW9ncmFwaDsgVEVYVC1BTElHTjoganVzdGlmeTsgTUFSR0lOOiAw
Y20gMGNtIDBwdDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9tYW4iOyBGT05ULVNJWkU6
IDEwLjVwdA0KfQ0KRElWLk1zb05vcm1hbCB7DQoJVEVYVC1KVVNUSUZZOiBpbnRlci1pZGVv
Z3JhcGg7IFRFWFQtQUxJR046IGp1c3RpZnk7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IEZPTlQt
RkFNSUxZOiAiVGltZXMgTmV3IFJvbWFuIjsgRk9OVC1TSVpFOiAxMC41cHQNCn0NCkE6bGlu
ayB7DQoJQ09MT1I6IGJsdWU7IFRFWFQtREVDT1JBVElPTjogdW5kZXJsaW5lDQp9DQpTUEFO
Lk1zb0h5cGVybGluayB7DQoJQ09MT1I6IGJsdWU7IFRFWFQtREVDT1JBVElPTjogdW5kZXJs
aW5lDQp9DQpBOnZpc2l0ZWQgew0KCUNPTE9SOiBwdXJwbGU7IFRFWFQtREVDT1JBVElPTjog
dW5kZXJsaW5lDQp9DQpTUEFOLk1zb0h5cGVybGlua0ZvbGxvd2VkIHsNCglDT0xPUjogcHVy
cGxlOyBURVhULURFQ09SQVRJT046IHVuZGVybGluZQ0KfQ0KU1BBTi5FbWFpbFN0eWxlMTcg
ew0KCUZPTlQtU1RZTEU6IG5vcm1hbDsgRk9OVC1GQU1JTFk6IFZlcmRhbmE7IENPTE9SOiB3
aW5kb3d0ZXh0OyBGT05ULVdFSUdIVDogbm9ybWFsOyBURVhULURFQ09SQVRJT046IG5vbmU7
IG1zby1zdHlsZS10eXBlOiBwZXJzb25hbC1jb21wb3NlDQp9DQpESVYuU2VjdGlvbjEgew0K
CXBhZ2U6IFNlY3Rpb24xDQp9DQpVTktOT1dOIHsNCglGT05ULVNJWkU6IDEwcHQNCn0NCkJM
T0NLUVVPVEUgew0KCU1BUkdJTi1UT1A6IDBweDsgTUFSR0lOLUJPVFRPTTogMHB4OyBNQVJH
SU4tTEVGVDogMmVtDQp9DQpPTCB7DQoJTUFSR0lOLVRPUDogMHB4OyBNQVJHSU4tQk9UVE9N
OiAwcHgNCn0NClVMIHsNCglNQVJHSU4tVE9QOiAwcHg7IE1BUkdJTi1CT1RUT006IDBweA0K
fQ0KPC9TVFlMRT4NCjwvSEVBRD4NCjxCT0RZIHN0eWxlPSJNQVJHSU46IDEwcHg7IEZPTlQt
RkFNSUxZOiB2ZXJkYW5hOyBGT05ULVNJWkU6IDEwcHQiPg0KPERJVj48Rk9OVCBjb2xvcj0j
MDAwMDgwIHNpemU9Mj5IaSBLb3N0YXMgZXQgYWwsPC9GT05UPjwvRElWPg0KPERJVj48Rk9O
VCBjb2xvcj0jMDAwMDgwPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgY29sb3I9
IzAwMDA4MD5JJ3ZlIHJlYWQgdGhlIGRyYWZ0ICg8Rk9OVCBjb2xvcj0jMDAwMDAwPjxGT05U
IA0KY29sb3I9IzAwMDA4MD5TVVBBJm5ic3A7Q29uZmlndXJhdGlvbiZuYnNwO2FuZCZuYnNw
O1BvbGljeSZuYnNwO01hcHBpbmc8L0ZPTlQ+LCZuYnNwOzxBIA0KaHJlZj0iaHR0cDovL2Rh
dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1wZW50aWtvdXNpcy1zdXBhLW1hcHBpbmcv
Ij5odHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXBlbnRpa291c2lzLXN1
cGEtbWFwcGluZy88L0E+PC9GT05UPikgDQphbmQgY29uc2lkZXIgdGhhdCBpdCB0YWNrbGVz
IGEgcmVhbCBwcm9ibGVtIG9mIFNVUEEuIFRoZSBleGFtcGxlIHRoZXJlaW4gYWxpZ25zIA0K
d2l0aCB3aGF0IHdlIHByb3Bvc2VkIGluIGRkYyB1c2UgY2FzZS4gQmVsb3cgcGxlYXNlIGtp
bmRseSBmaW5kIG15IA0KY29tbWVucy48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGNvbG9y
PSMwMDAwODA+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMDgw
PkluIHNlY3Rpb24gMy4zIFNVUEEgbWFwcGluZyBleGFtcGxlLCBpdCBpbGx1c3RyYXRlcyBo
b3cgDQp0byBtYXAgY29uZmlndXJhdGlvbiBZQU5HIG1vZGVsIGludG8gZGV2aWNlLWJhc2Vk
IENMSSB3aXRoIHRoZSBhc3Npc3RhbmNlIG9mIA0KdG9wb2xvZ3kgWUFORyBtb2RlbC4gSG93
ZXZlciwgYXMgQ0xJIGlzIHVzdWFsbHkgdmVuZG9yLWRlcGVuZGVudCwgaXQncyBhIGxpdHRs
ZSANCmNvbXBsaWNhdGVkIHRvIG1hcCBpbnRvIENMSXMgZGlyZWN0bHkgKEFsdGhvdWdoIHRo
ZSBjb21wbGV4aXR5IGlzIG5vdCBzaG93ZWQgdXAgDQppbiB0aGlzIGV4YW1wbGUgLS0tIEFs
bCB0aGUgQ0xJcyBzZWVtIHRvIGZvbGxvdyB0aGUgc3BlY2lmaWNhdGlvbiBvZiB0aGUgc2Ft
ZSANCnZlbmRvcikuIElNSE8sIG1hcHBpbmcgY29uZmlndXJhdGlvbiBZQU5HIG1vZGVsIGlu
dG8gYSB2ZW5kb3ItbmV1dHJhbCANCmRldmljZS1sZXZlbCBjb25maWd1cmF0aW9uIFlBTkcg
bW9kZWwgZmlyc3RseSBpcyBtb3JlIGFwcHJvcHJpYXRlLiBBZnRlciB0aGF0IHdlIA0KY2Fu
IG1hcCB0aGUgdmVuZG9yLW5ldXRyYWwgZGV2aWNlLWxldmVsIGNvbmZpZ3VhdGlvbiBZQU5H
IG1vZGVsIGludG8gZGlmZmVyZW50IA0KdmVuZG9yJ3MgY29uZmlndXJhdGlvbiBpbnRlcmZh
Y2VzL21ldGhvZHMsIHdoaWNoIGlzIHZlbmRvci1kZXBlbmRlbnQgYW5kIGlzIG5vdCANCnJl
cXVpcmVkIHRvIGJlIHN0YW5kYXJkaXplZC48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGNv
bG9yPSMwMDAwODA+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAw
MDgwPlBTLiBJdCBpcyBhbHNvIHN1Z2dlc3RlZCB0byBjb25zaWRlciB0byBwcm92aWRlIGEg
bW9yZSANCmdlbmVyYWwgZGVzY3JpcHRpb24gb2YgbWFwcGluZyBtZWNoYW5pc20sIGluc3Rl
YWQgb2Ygb25seSBwcmVzZW50aW5nIGEgZGV0YWlsZWQgDQpleGFtcGxlLCB3aGljaCBtYWtl
cyB0aGlzIGRyYWZ0IGxpbWl0ZWQgdG8gYSBzcGVjaWZpYyBzY2VuYXJpby48L0ZPTlQ+PC9E
SVY+DQo8RElWPjxGT05UIGNvbG9yPSMwMDAwODA+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJ
Vj48Rk9OVCBjb2xvcj0jMDAwMDgwPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQg
Y29sb3I9IzAwMDA4MD5CUiw8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGNvbG9yPSMwMDAw
ODA+WWluZzwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgY29sb3I9IzAwMDA4MD48L0ZPTlQ+
Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGNvbG9yPSMwMDAwODA+PC9GT05UPiZuYnNwOzwv
RElWPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMDAwIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9E
SVY+DQo8RElWPjxGT05UIGNvbG9yPSMwMDAwODAgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJ
Vj4NCjxESVY+PEZPTlQgY29sb3I9I2MwYzBjMCBzaXplPTI+MjAxNC0wOS0zMCA8L0ZPTlQ+
PC9ESVY+PEZPTlQgY29sb3I9IzAwMDA4MCANCnNpemU9Mj4NCjxIUiBzdHlsZT0iV0lEVEg6
IDEwMHB4IiBhbGlnbj1sZWZ0IGNvbG9yPSNiNWM0ZGYgU0laRT0xPg0KPC9GT05UPg0KPERJ
Vj48Rk9OVCBjb2xvcj0jYzBjMGMwIHNpemU9Mj48U1BBTj4NCjxESVY+WWluZyBDSEVORyZu
YnNwOyCzzNOoPEJSPkNoaW5hIFVuaWNvbSBOZXR3b3JrIFRlY2hub2xvZ3kgUmVzZWFyY2gg
SW5zdGl0dXRlIA0K1tC5+sGqzajN+MLnvLzK9dHQvr/UujxCUj5UZWw6ICs4Ni0xMC02ODc5
OTk5OS03NzAyPEJSPk1vYmlsZTogDQorODYtMTg2MDExMDI5NzE8QlI+PEJSPjwvRElWPjwv
U1BBTj48L0ZPTlQ+PC9ESVY+DQo8SFIgY29sb3I9I2I1YzRkZiBTSVpFPTE+DQoNCjxESVY+
PEZPTlQgc2l6ZT0yPjxTVFJPTkc+t6K8/sjLo7o8L1NUUk9ORz4gS29zdGFzIFBlbnRpa291
c2lzIDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjxTVFJPTkc+t6LLzcqxvOSj
ujwvU1RST05HPiAyMDE0LTA5LTIzJm5ic3A7IDE3OjA0OjEyIDwvRk9OVD48L0RJVj4NCjxE
SVY+PEZPTlQgc2l6ZT0yPjxTVFJPTkc+ytW8/sjLo7o8L1NUUk9ORz4gc3VwYUBpZXRmLm9y
ZyA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48U1RST05HPrOty82jujwvU1RS
T05HPiA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48U1RST05HPtb3zOKjujwv
U1RST05HPiBbU3VwYV0gU1VQQSBjb25maWd1cmF0aW9uIDwvRk9OVD48L0RJVj4NCjxESVY+
PEZPTlQgc2l6ZT0yPjwvRk9OVD4gPC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj4NCjxESVY+
RGVhciZuYnNwO0FsbCw8L0RJVj4NCjxESVY+PC9ESVY+DQo8RElWPldlJm5ic3A7aGF2ZSZu
YnNwO2JlZW4mbmJzcDt3b3JraW5nJm5ic3A7b24mbmJzcDt0d28mbmJzcDtkcmFmdHMmbmJz
cDtvbiZuYnNwO1NVUEEmbmJzcDtjb25maWd1cmF0aW9uLiZuYnNwO1RoZSZuYnNwO2ZpcnN0
Jm5ic3A7b25lJm5ic3A7KFNVUEEmbmJzcDtDb25maWd1cmF0aW9uJm5ic3A7YW5kJm5ic3A7
UG9saWN5Jm5ic3A7TWFwcGluZywmbmJzcDtodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv
ZG9jL2RyYWZ0LXBlbnRpa291c2lzLXN1cGEtbWFwcGluZy8pJm5ic3A7ZGlzY3Vzc2VzJm5i
c3A7bWFwcGluZyZuYnNwO29mJm5ic3A7YW4mbmJzcDthYnN0cmFjdCZuYnNwO3ZpZXcmbmJz
cDt0byZuYnNwO2RldmljZS1sZXZlbCZuYnNwO2NvbmZpZ3VyYXRpb24uJm5ic3A7VGhlJm5i
c3A7c2Vjb25kJm5ic3A7b25lJm5ic3A7KFlBTkcmbmJzcDtEYXRhJm5ic3A7TW9kZWwmbmJz
cDtmb3ImbmJzcDtDb25maWd1cmF0aW9uJm5ic3A7b2YmbmJzcDtTaGFyZWQmbmJzcDtVbmlm
aWVkJm5ic3A7UG9saWN5Jm5ic3A7QXV0b21hdGlvbiZuYnNwOyhTVVBBKSwmbmJzcDtodHRw
czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC16YWFsb3VrLXN1cGEtY29uZmln
dXJhdGlvbi1tb2RlbC8pJm5ic3A7aW50cm9kdWNlcyZuYnNwO291ciZuYnNwO2Vhcmx5Jm5i
c3A7c3RhZ2UmbmJzcDt3b3JrJm5ic3A7b24mbmJzcDthJm5ic3A7ZmV3Jm5ic3A7WUFORyZu
YnNwO21vZGVscyZuYnNwO2ZvciZuYnNwO0wzVlBOLCZuYnNwO0lQJm5ic3A7VEUmbmJzcDtl
dGMuPC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj5XZSdyZSZuYnNwO2xvb2tpbmcmbmJzcDtm
b3J3YXJkJm5ic3A7dG8mbmJzcDt5b3VyJm5ic3A7Y29tbWVudHMmbmJzcDthbmQmbmJzcDtz
dWdnZXN0aW9ucy4mbmJzcDs8L0RJVj4NCjxESVY+PC9ESVY+DQo8RElWPkJlc3QmbmJzcDty
ZWdhcmRzLDwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+S29zdGFzPC9ESVY+DQo8RElWPjwv
RElWPg0KPERJVj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXzwvRElWPg0KPERJVj5TdXBhJm5ic3A7bWFpbGluZyZuYnNwO2xpc3Q8L0RJVj4NCjxE
SVY+U3VwYUBpZXRmLm9yZzwvRElWPg0KPERJVj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls
bWFuL2xpc3RpbmZvL3N1cGE8L0RJVj4NCjxESVY+LjwvRElWPjwvRk9OVD48L0RJVj48cD7I
57n7xPq07c7zvdPK1cHLuMPTyrz+o6zH682ouf2159fT08q8/sGivLTNqNaqztLDx6Gjx+u7
2Li008q8/rW9aHFzLXNwbWNAY2hpbmF1bmljb20uY26jrLy0v8nS1M3Ltqm0y9PKvP6ho87S
w8e9q8GivLS9q8T6tcTQxc+itNPO0sPHtcS3osvNxL/CvNbQyb6z/aGjDQpJZiB5b3UgaGF2
ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdXMgaW1tZWRp
YXRlbHkgYnkgZS1tYWlsLiBQbGVhc2UgcmVwbHkgdG8gaHFzLXNwbWNAY2hpbmF1bmljb20u
Y24gaWYgeW91IHdhbnQgdG8gdW5zdWJzY3JpYmUgZnJvbSB0aGlzIG1haWwuIFdlIHdpbGwg
aW1tZWRpYXRlbHkgcmVtb3ZlIHlvdXIgaW5mb3JtYXRpb24gZnJvbSBvdXIgc2VuZGluZyBj
YXRhbG9ndWUuPC9wPg0KPC9CT0RZPjwvSFRNTD4NCg==

--=====003_Dragon300070204577_=====--


From nobody Tue Sep 30 00:54:59 2014
Return-Path: 
X-Original-To: supa@ietfa.amsl.com
Delivered-To: supa@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78FE91A026C for ; Tue, 30 Sep 2014 00:54:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.387
X-Spam-Level: 
X-Spam-Status: No, score=-4.387 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 AsLZvq-cFz-N for ; Tue, 30 Sep 2014 00:54:55 -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 BE8B41A0277 for ; Tue, 30 Sep 2014 00:54:54 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BND80904; Tue, 30 Sep 2014 07:54:49 +0000 (GMT)
Received: from LHREML516-MBX.china.huawei.com ([169.254.1.85]) by lhreml405-hub.china.huawei.com ([10.201.5.242]) with mapi id 14.03.0158.001; Tue, 30 Sep 2014 08:54:45 +0100
From: Georgios Karagiannis 
To: "Eric Voit (evoit)" 
Thread-Topic: New SUPA charter
Thread-Index: Ac/ZIUcaEK+SU+lYTNqeRV6T6bQAHwC5BFlgAB6l7WAAAAVkkA==
Date: Tue, 30 Sep 2014 07:54:45 +0000
Message-ID: 
References:   
In-Reply-To: 
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.221.64.47]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/supa/zufhGfJ6m3IiFguw98fB_5BNg84
Cc: "supa@ietf.org" 
Subject: Re: [Supa] New SUPA charter
X-BeenThere: supa@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Sep 2014 07:54:57 -0000

Hi Eric,

Thank you very much for your constructive comments. Please see in line.



> -----Original Message-----
> From: Georgios Karagiannis
> Sent: Tuesday, September 30, 2014 9:28 AM
> To: Georgios Karagiannis
> Subject: RE: New SUPA charter
>=20
>=20
>=20
> From: Eric Voit (evoit) [mailto:evoit@cisco.com]
> Sent: Monday, September 29, 2014 8:03 PM
> To: Georgios Karagiannis
> Cc: supa@ietf.org
> Subject: RE: New SUPA charter
>=20
> Hi George,
>=20
> I like the intent of SUPA.=A0 And that means I am going to make a lot of
> comments below :-).=A0 =A0Beyond that, I have two general comments on new=
 items
> which could be considered for scope.
[>]=20

Georgios: Thank you very much.

>=20
> Comment #1: Focus on standardizing where the network element APIs might a=
lso
> change. For me the highest value items to standardize are domain
> abstractions/models which:
> =A0 (a) can be acted upon as a whole externally, and
> =A0=A0(b) have supporting implications requiring incremental work on the =
network
> elements.
>=20
> There are such example mini-domain-abstractions in the IP control plane
> today.=A0=A0 Consider VRRP, Anycast RP, ICCP: these are *very* close to d=
omain
> policy abstractions.=A0 To build on the lessons of these protocol types, =
how do
> we provide Policy abstractions which might be interesting *and* might nee=
d to
> support a dynamic convergence substrate?
[>]=20

Georgios: Agree with this comment. Please note that the intention of SUPA i=
s to include both (a) and (b).
You can help to clarify this in the text.

>=20
> The reason I am aiming here is that IETF standardization will be of most =
value
> where there is a distributed state machine linking activity across contro=
ller
> and network element. My suspicion is that many new service offerings whic=
h are
> purely "controller models" (i.e., requiring only existing network element
> interfaces) will likely be fleshed out in Open Source venues first.=A0 =
=A0If we
> don't pay attention to where we are different from Open Source, we could =
end
> up forced to rubber stamp Open Source work in SUPA.
>=20
> Comment #2: What about networks with Multiple Controllers?
> Eventually there will be many interacting controllers in the network.=A0 =
A
> historical proof-point is the old phone network which had 800/freephone,
> Mobility, Local number portability, and other controllers tied to the SS7
> network.=A0 This pattern will repeat with IP network controllers.=A0 Huge
> monolithic controllers will never dominate.=A0=A0 So in cases where there=
 are
> multiple controllers touching a single device, how to you resolve domain =
and
> device consistency issues?
[>]=20

Georgios: This comment refers to a scenario where distributed controllers a=
re used.=20
Some text that we have in the charter used to describe interoperability, as=
sumes that multi-controllers might be used,=20
see the reply on one of your comments, below.



>=20
> IMHO, the SUPA network Policy group could be chartered to handle these
> reconciliations.=A0 In the end, these really are Policy reconciliation qu=
estions
> at the domain level.=A0 The charter as written below is close to hitting =
that.
>=20
> Anyway, my comments below do not focus on the two comments above, and are
> intended to hit just the text below.
>=20
> From: Supa, September 25, 2014 8:32 PM
> Hi all,
>=20
> We have worked out all comments that we have received on the previous ver=
sion
> of the SUPA charter.
> The new version of the charter can be seen below:
>=20
> Best regards,
> Georgios
>=20
>=20
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> SUPA (Shared Unified Policy Automation) charter v1.12 Target Area: Operat=
ions
> and Management
>=20
> Description of Working Group:
>=20
> Programmatic ways to configure networks, often called software-defined, a=
re
> considered by many network operators in order to shift the balance in the=
ir
> favor.
>=20
>  Versus equipment vendors? Versus end-user customers?=A0 There is p=
lenty
> of new value for all.
[>]=20

[>]=20
Georgios: Agree that there is plenty of new value for all.
>=20
> Automating the way of exposing a view of the network to applications may
> provide significant improvements in configuration agility, error detectio=
n and
> uptime for operators. However the real value behind central configuration
> schemes lies within the possible simplification through models provided b=
y
> such systems to applications and network services running above them (on =
the
> so-called northbound side). Well-designed models are able to provide a wi=
de
> range of granularity for various applications and network services needs,=
 from
> the lower-level physical network to high-level application services.
>=20
>  From below in SUPA goals, it looks like SUPA might be considering
> models and enforcement between layers.=A0 An L3VPN service might feel the=
 same
> to an end user.=A0=A0 But an operator's underlying technology choices mak=
e
> exposure of technology and operational knobs very different. Especially a=
cross
> different classes of operators.=A0 There are dozens of ways of fulfilling=
 the
> L3VPN abstraction.=A0 Describing the bindings digestibly to those who wil=
l
> consume which models in a way which also provides reuse will be non-trivi=
al.
[>]=20

Georgios: Agree, but this will be one of the values of SUPA, i.e., to addre=
ss this non-triviality.
>=20
> Several organizations outside of the IETF have defined various schemes fo=
r the
> configuration of network devices and specific network controllers, but no=
ne of
> them offer a vendor-neutral standardized way for applications and network
> services to transmit their needs to network controllers. The SUPA (Shared
> Unified Policy Automation) working group will work on the definition of s=
uch
> as standardized interface for applications and network services to commun=
icate
> with network controllers of all types. In particular, SUPA will focus on
> service specific models that allow applications to request certain networ=
k
> services to be created/deleted/modified.
>=20
>  This will mean that the device servicing the SUPA abstraction will=
 be
> able to commit create/delete/modify across a set of authoritative datasto=
res
> within its domain.=A0 This could even mean info authoritatively owned in
> different controllers. This can be done, but requires negotiation protoco=
ls
> under the covers to describe which transactions can be committed.=A0 Doin=
g this
> well means knowing how to revoke commitments as network conditions change=
.
[>]=20

Georgios: yes, I agree with you. Netconf (or restconf) is intended to be us=
ed for this purpose.

>=20
> A network service can for example be a virtual link between two endpoints=
 that
> uses certain properties, traffic engineering, implementation of IPv6
> transition mechanism and their enforcement to users.
>=20
> Each network service can be represented by a service based POLICY model t=
hat
> can model a group of demands (i.e., actions and constraints) that are bei=
ng
> initiated by applications that impose similar requirements on the
> communication network. The terms "UNIFIED" and "SHARED" used in the SUPA
> abbreviation, relate to the way of how the service policy model is genera=
ted,
> since it groups, unifies and shares the similar requirements imposed by a=
 bulk
> of applications. SUPA will provide guidelines for mechanisms that can
> dynamically and on an interoperable manner, AUTOMATICALLY map services an=
d
> policies defined on an abstract topology graph down to more detailed netw=
ork
> graphs and specific network management and controlling policies.
>=20
>  I like this paragraph.=A0 It highlights that various subsets of ne=
twork
> elements have abstractions which can be controlled from the outside for a=
 set
> purpose.
[>]=20

Georgios: Great.

>=20
> Some IETF working groups have started work relating to the description of
> various topologies such as I2RS (L3 and routing topologies), ALTO (cost m=
aps),
> SFC (service chain), none of these groups aim (1) at offering truly gener=
ic
> topology models for the standard northbound interface, and (2) that an
> application can communicate with network boxes, such as network controlle=
rs,
> and NEs, developed by different vendors.
>=20
>  Do you have examples of such models?=A0=A0 Especially ones where t=
here are
> not WG drafts somewhere else?=A0=A0 The very hard part will be describing=
 a higher
> level of abstraction which is really usable by the IETF WGs listed
> above.=A0 This value statement should soon be matched with an example mod=
el
> which serves the set of technologies above.
[>]=20

Georgios: Actually, this example comes very close to your comment #2, where=
 the network boxes are multi-controllers.

>=20
> SUPA will work on defining vendor-neutral standardized interfaces based o=
n the
> concept of network graph, an entity describing an arbitrary topology of n=
odes
> and links at any level of granularity. Such a network graph describes (1)
> topologies at different levels of abstraction, (2) the relationships betw=
een
> the abstraction levels and (3) applied service based policy, which are ac=
tions
> and constraints applied on these topologies.
> SUPA may also define any mappings to any other network topology data mode=
ls
> defined within the IETF.
>=20
>  This need not just be about graphs.=A0 Also see notes below about
> maintaining flexibility when trying at the same time to maintain relation=
ships
> between abstraction levels.
[>]=20

Georgios: No, it is not only about graphs. Please note that in our provided=
 definition a network graph, includes policies and relationships between ab=
straction levels.


>=20
> The main goal of SUPA is to provide service specific models that allow
> applications to request network services to be created/deleted/modified.
>=20
>=20
> This can be realized by:
> =A0 o) model multiple topologies at different levels of abstraction using=
 a
> network graph,
>=20
>  Just topologies?=A0=A0 There is a whole set of Policies which are =
not
> topology which are (simpler?) unsolved problems.=A0 =A0Based on work item=
 2 below,
> at minimum you should be able to add the word Policy here.
[>]=20

Georgios: Agree. . Please note that in our provided definition a network gr=
aph, includes policies and relationships between abstraction levels.

>=20
> =A0=A0o) model the relationships between the abstraction levels.
>=20
>  This means you are binding the different abstraction models via lo=
gic /
> state machines.=A0 What happens when one abstraction widely disconnects f=
rom
> existing lower level abstractions?=A0 Is this dis-allowed?=A0 This will b=
e common
> for L3VPN, there are a huge number of ways to deliver the abstraction.
[>]=20

Georgios: Thanks for providing hints on the solution space. I agree with yo=
u that such details need to be incorporated in the solution space.

>=20
> =A0 o) transporting model instances using either NETCONF or RESTCONF
>=20
> SUPA will ensure that in case any specific NETCONF/RESTCONF protocol
> requirements are identified, they will be communicated in a timely manner=
 to
> the NETCONF working group. SUPA will consult with the YANG doctors to ens=
ure
> that data models follow common practices.
>=20
> Work items for SUPA include:
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D
> 1) The definition of a standardized model for a network graph, using YANG=
.
> This model may be used to describe topologies at any functional layer, fr=
om
> physical networks to network services.
>=20
>  "Any functional layer" might be hard.=A0 To do this, the model wil=
l have
> to be very "meta".=A0 Meta is fine, but this means you will have to descr=
ibe
> relationships between layers in terms of values for specific objects.
[>]=20

Georgios: maybe values and characteristics.
>=20
> 2) The definition and standardization of a number of basic policy and dat=
a
> models using network graphs. These might include, but are not limited to
> L3VPNs, traffic engineering, implementation of IPv6 transition mechanism =
and
> their enforcement to users.
> 3) Provide guidelines for mechanisms that can dynamically and on an
> interoperable manner, automatically map services and policies defined on =
an
> abstract topology graph down to more detailed network graphs and specific
> network management and controlling policies.
>=20
>  As I note above, L3PVN is one which particular worries me.=A0 Espe=
cially
> as it relates to "model the relationships between the abstraction levels"
> above.=A0 There is such a volume of implementation methods and users, I d=
on't
> know what we gain here by formalizing the layered dependencies.=A0=A0 AFA=
IK, there
> will be an explosion of variants below the 1st level of abstraction.
[>]=20

Georgios: By formalizing the layered dependencies we can stimulate interope=
rability.

>=20
> Eric
>=20
>=20
> 4) Guidelines on how to use NETCONF (or RESTCONF) authentication and
> authorization mechanisms to achieve protection and isolation
>=20
> Deliverables:
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> o) Produce an informational RFC "Problem Statement and Use Cases".
> o) Produce a standards-track RFC that specifies YANG models for a generic
> multi-layer network graph.
> o) Produce standards-track RFCs that specify extensions for the generic Y=
ANG
> models defined above for network services that manage virtual links, traf=
fic
> engineering and implementation of IPv6 transition mechanism and their
> enforcement to users.
> o) Produce an informational RFC that provides the guidelines for mechanis=
ms
> that can dynamically and on interoperable manner, automatically map servi=
ces
> and policies defined on an abstract topology graph down to more detailed
> network graphs and specific network management and controlling policies.
> o) Produce an informational RFC that provides the guidelines on using NET=
CONF
> (or RESTCONF) authentication and authorization mechanisms to achieve secu=
rity
> protection and isolation' as an Informational RFC.
>=20
> Milestones:
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> Dec 2014=A0 Initial "Problem Statement and Use Cases" WG I-D Feb 2015=A0 =
Initial
> "Multi-layer Network Graph YANG Model" WG I-D Apr 2015=A0 Initial service
> specific data model WG I-Ds May 2015=A0 Initial "Mapping Guidelines" WG I=
-D Jun
> 2015=A0 Submit "Problem Statement and Use Cases" I-D to IESG Jul 2015=A0 =
Initial
> "Authentication and Authorization" WG I-D Sep 2015=A0 Submit "Multi-layer
> Network Graph YANG Model" I-D to IESG Nov 2015=A0 Submit service specific=
 data
> model I-Ds to IESG Feb 2016=A0 Submit "Mapping Guidelines" I-D to IESG Ap=
r
> 2016=A0 Submit "Authentication and Authorization" I-D to IESG
>=20
>=20

Best regards,
Georgios


From nobody Tue Sep 30 02:20:20 2014
Return-Path: 
X-Original-To: supa@ietfa.amsl.com
Delivered-To: supa@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA0B51A02EA for ; Tue, 30 Sep 2014 02:20:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.963
X-Spam-Level: 
X-Spam-Status: No, score=0.963 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 TWL-vzAJ-XYo for ; Tue, 30 Sep 2014 02:20:15 -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 620EA1A02E9 for ; Tue, 30 Sep 2014 02:20:14 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKB65234; Tue, 30 Sep 2014 09:20:11 +0000 (GMT)
Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 30 Sep 2014 10:19:32 +0100
Received: from szxeml555-mbs.china.huawei.com ([169.254.2.65]) by szxeml403-hub.china.huawei.com ([::1]) with mapi id 14.03.0158.001; Tue, 30 Sep 2014 17:19:24 +0800
From: linjunru 
To: JF Tremblay , "supa@ietf.org" 
Thread-Topic: [Supa] Review of draft-pentikousis-supa-mapping-00
Thread-Index: AQHP3ByPx87+V0u/gEeb/A0YWLZDypwZZVpA
Date: Tue, 30 Sep 2014 09:19:23 +0000
Message-ID: <92F95A318014D342B5C277097274F2E505E46A@szxeml555-mbs.china.huawei.com>
References: <69CD2340-92AA-4095-8E27-B6EBA069206D@viagenie.ca>
In-Reply-To: <69CD2340-92AA-4095-8E27-B6EBA069206D@viagenie.ca>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.66.88.198]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/supa/oxZys2hX0prPyMC3y4iyK6wq7y4
Subject: [Supa] =?gb2312?b?tPC4tDogIFJldmlldyBvZiBkcmFmdC1wZW50aWtvdXNp?= =?gb2312?b?cy1zdXBhLW1hcHBpbmctMDA=?=
X-BeenThere: supa@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Sep 2014 09:20:17 -0000

SGksIEpGOg0KCVRoYW5rIHlvdSBmb3IgeW91ciBjb25zdHJ1Y3RpdmUgY29tbWVudHMuIFBsZWFz
ZSBzZWUgaW4gbGluZQ0KDQo+IA0KPiBBZnRlciByZWFkaW5nIGRyYWZ0LXBlbnRpa291c2lzLXN1
cGEtbWFwcGluZy0wMCwgc29tZSBjb25jZXB0cyBvZiBzdXBhDQo+IHJlbWFpbiB1bmNsZWFyIHRv
IG1lLiBJdKGvcyBub3QgZWFzeSB0byBwdXQgYSBmaW5nZXIgb24gZXhhY3RseSB3aGF0LCBidXQg
SaGvbGwgdHJ5DQo+IHRvIGRlc2NyaWJlIGl0IGJlbG93Lg0KPiANCj4gRnJvbSByZWFkaW5nIHRo
ZSBvdGhlciBzdXBhIGRyYWZ0cywgaXQgc2VlbXMgYSBzdXBhLWNvbXBsaWFudCBlbnRpdHkNCj4g
KGNvbnRyb2xsZXI/KSBleHBvc2UgYSBudW1iZXIgb2YgYWJzdHJhY3QgbW9kZWxzIGluIGFuIGlu
dGVyZmFjZXMgdG8gobBoaWdoZXKhsQ0KPiBhcHBsaWNhdGlvbnMgKG1hbmFnZW1lbnQgb3Igb3Ro
ZXJzKS4gVGhpcyBpcyB3aGF0IHRoZSB3b3JrIGluIGRyYWZ0LWNvbnRyZXJhcw0KPiBhbmQgZHJh
ZnQtemFhbG91ayBzZWVtIHRvIHJlZmVyIHRvLiBJbiB0aGF0IHNlbnNlLCBJIHdvdWxkIGV4cGVj
dCBhIKGwbWFwcGluZ6GxDQo+IHRvIGhhcHBlbiBpbnRlcm5hbGx5IGJldHdlZW4gdGhlc2UgYWJz
dHJhY3QgbW9kZWxzIGFuZCBhIHBoeXNpY2FsIHRvcG9sb2d5Lg0KPiBUaGlzIHdheSwgdGhlIHN1
cGEgZW50aXR5IHdvdWxkIG1haW50YWluIGNvbnNpc3RlbmN5IGJldHdlZW4gZGlmZmVyZW50DQo+
IGFic3RyYWN0IHRvcG9sb2dpZXMgYW5kIHRoZSBwaHlzaWNhbCB0b3BvbG9neS4NCj4gDQo+IEhv
d2V2ZXIsIGFjY29yZGluZyB0byB0aGlzIGRyYWZ0LCB0aGVyZaGvcyBvbmx5IG9uZSB0b3BvbG9n
eSBiZWluZyBtYWludGFpbmVkDQo+IGFuZCBpdCBzZWVtZWQgdG8gYmUgdGhlIHBoeXNpY2FsIG9u
ZSAoobAuLi5hIHRvcG9sb2d5IG1vZHVsZSBtYWludGFpbnMgdGhlDQo+IHRvcG9sb2d5IG9mIHRo
ZSBuZXR3b3JrIGluZnJhc3RydWN0dXJloa2hsSkuIFRoaXMgaXMgcmVpbmZvcmNlZCBpbiBzZWN0
aW9uIDMuMjogIiAuLi4NCj4gdGhlIG5ldHdvcmsgc2VydmljZSBzeXN0ZW0gYWNxdWlyZXMgdGhl
IHRvcG9sb2d5IGluZm9ybWF0aW9uIFsuLi5dIGlmIGl0IG5lZWRzDQo+IHNvbWUga25vd2xlZGdl
IG9mIHRoZSB1bmRlcmx5aW5nIG5ldHdvcmuhraGxLiBBbmQgdGhlbiBpbiBzZWN0aW9uIDMuMzog
Ii4uLnRoZQ0KPiBOU1MgY2FuIGRlY2lkZaGtobEuIEl0IHNlZW1zIHRoZSChsG5ldHdvcmsgbWFu
YWdlbWVudCBhbmQgY29udHJvbCBzeXN0ZW2hsSBpcw0KPiBwdXJlbHkgYSBwaHlzaWNhbCBjb250
cm9sbGVyIGFuZCB0aGUgTlNTIGlzIGFjdHVhbGx5IG1ha2luZyBkZWNpc2lvbnMuIFNvLCBpbiB0
aGUNCj4gZW5kLCBpZiB0aGUgTlNTIGFjY2Vzc2VzIHRoZSB1bmRlcmx5aW5nIG5ldHdvcmsgdG9w
b2xvZ3kgb25seSwgd2hlcmUgYXJlIHRoZQ0KPiBzdXBhIGFic3RyYWN0aW9ucyB1c2VkPw0KPiAN
CiBbSnVucnVdIA0KLS0tInRoZXJloa9zIG9ubHkgb25lIHRvcG9sb2d5IGJlaW5nIG1haW50YWlu
ZWQgYW5kIGl0IHNlZW1lZCB0byBiZSB0aGUgcGh5c2ljYWwgb25lIiBpcyBleGFjdGx5IHdoYXQg
d2UgYXJlIHRhbGtpbmcgYWJvdXQuIE5TUyBtYXkgaGF2ZSBpdHMgb3duICJhYnN0cmFjdCB2aWV3
IiBvZiB0aGUgcGh5c2ljYWwgdG9wb2xvZ3ksIHdoaWNoIGlzIGJ1aWx0IGJhc2VkIG9uIHRoZSBw
aHlzaWNhbCB0b3BvbG9neSBpbmZvcm1hdGlvbiBtYWludGFpbmVkIGluIHRoZSBuZXR3b3JrIG1h
bmFnZW1lbnQgJiBjb250cm9sIHN5c3RlbSwgaG93ZXZlciB0aGlzICJhYnN0cmFjdCB2aWV3IiBp
cyBuZXR3b3JrIHNlcnZpY2UvYXBwbGljYXRpb24tZGVwZW5kZW50IGFuZCBpcyBub3QgZm9jdXNl
ZCBvbiBieSB0aGlzIGRyYWZ0Lg0KLS0tImlmIHRoZSBOU1MgYWNjZXNzZXMgdGhlIHVuZGVybHlp
bmcgbmV0d29yayB0b3BvbG9neSBvbmx5IiBpcyBub3QgZXhhY3RseSByaWdodC4gVGhlIG5ldHdv
cmsgbWFuYWdlbWVudCAmIGNvbnRyb2wgc3lzdGVtIGFsc28gbmVlZHMgdG8gYWNjZXNzIHRoZSB1
bmRlcmx5aW5nIG5ldHdvcmsgdG9wb2xvZ3ksIGVzcGVjaWFsbHkgd2hlbiBtYXBwaW5nIHRoZSBO
U1MncyBjb25maWd1cmF0aW9uIGludG8gZGV2aWNlLWxldmVsIGNvbmZpZ3VyYXRpb24sIGl0IG5l
ZWRzIHRoZSB1bmRlcmx5aW5nIG5ldHdvcmsgdG9wb2xvZ3kgdG8gZGVjaWRlIHdoZXJlIGFuZCBo
b3cgaXMgdGhlIGNvbmZpZ3VyYXRpb24gZGVwbG95ZWQuDQotLS0iIHdoZXJlIGFyZSB0aGUgc3Vw
YSBhYnN0cmFjdGlvbnMgdXNlZD8gIiwgdGhleSBhcmUgdXNlZCB0byBjb25maWd1cmUgdGhlIG5l
dHdvcmsgc2VydmljZXMgbmV0d29yay13aWRlbHkgc3VjaCBhcyBpbiBMM3ZwbiwgSVBURS4uLg0K
LS0taW4gc2VjdGlvbiAzLjM6ICIuLi50aGUgTlNTIGNhbiBkZWNpZGWhraGxIGhlcmUgdGhlIE5T
UydzIGRlY2lzaW9uIGlzIG1vcmUgYSBjb25maWd1cmF0aW9uIGZyb20gaGlnaCBsZXZlbCwgc3Vj
aCBhcyBzdGVlcmluZyB0cmFmZmljIGF3YXkgZnJvbSBhIHNwZWNpZmljIG5ldHdvcmsgZWxlbWVu
dCBhbmQgc3RlZXJpbmcgdHJhZmZpYyB0b3dhcmQgYSBwYXRoIHBhc3NlcyB0aHJvdWdoIGEgc3Bl
Y2lmaWMgbmV0d29yayBlbGVtZW50IC4gSW4gdGhlIGV4YW1wbGUgc2NlbmFyaW8sIHRoZXJlIG1h
eSBiZSBzZXZlcmFsIHBhdGhzIGZyb20gQSB0byBCIHdoaWNoIGFsc28gdHJhdmVsIHRocm91Z2gg
Qy4gQnV0IHRoZSBOU1MgaGFzIG5vIGlkZWEgYWJvdXQgdGhlc2UgcGF0aHMgYW5kIGl0IGlzIG5v
dCBhYmxlIHRvIGRlY2lkZSB3aGljaCBwYXRoIGlzIGJldHRlciBuZWl0aGVyLiBTbyBpdCBzZW5k
cyB0aGUgcGF0aCBjb25zdHJhaW5zIChiYW5kd2lkdGggPiAxME1iL3MsIHRocm91Z2ggQywgaW5n
cmVzcyBub2RlIGlzIEEgYW5kIGVncmVzcyBub2RlIGlzIEIpIHRvIHRoZSBuZXR3b3JrIG1hbmFn
ZW1lbnQgJiBjb250cm9sIHN5c3RlbSwgYW5kIHRoZSBuZXR3b3JrIG1hbmFnZW1lbnQgJiBjb250
cm9sIHN5c3RlbSBtYWtlIHRoZSBhY3R1YWwgImRlY2lzaW9ucyI6IHRoZSBzcGVjaWZpYyBwYXRo
IChBLEQsQyxFLEIpIGlzIHRoZSBvbmUuIFRoZSBleHByZXNzaW9uIGhlcmUgbWF5IGNhdXNlIGNv
bmZ1c2lvbiBhbmQgIi4uLnRoZSBwb2xpY3kgb2YgdGhlIE5TUycgbmV0d29yayBzZXJ2aWNlIGlu
ZGljYXRlcyB0aGF0IKGtobFtYXkgYmUgbW9yZSBhcHByb3ByaWF0ZSB0aGFuICIuLi50aGUgTlNT
IGNhbiBkZWNpZGWhraGxLg0KDQoNCj4gQSBmZXcgbWlub3IgZWRpdHMvY29tbWVudHM6DQo+IC0g
SW50cm9kdWN0aW9uOiBkcmFmdC16aG91LXN1cGEtYXJjaGl0ZWN0dXJlLTAwIGlzIHJlZmVyZW5j
ZWQgYnV0IGRvZXMgbm90DQo+IHNlZW0gdG8gZXhpc3QgYXQgdGhhdCB1cmwuDQo+IC0gSW50cm9k
dWN0aW9uOiBpbiB0aGUgbGFzdCBwYXJhZ3JhcGgsIGFuIEFCUEQgbW9kdWxlIGlzIGRpc2N1c3Nl
ZCwgYnV0IGRvZXMNCj4gbm90IGFwcGVhciBpbiBmaWd1cmUgMS4NCj4gLSBQYWdlIDggYW5kIDk6
IHMvcXVpdGUvcXVpdC8gSSBndWVzc6GtDQoNCltKdW5ydV0gVGhhbmtzLCB3ZSB3aWxsIGNvcnJl
Y3QgaXQgaW4gdGhlIG5ldyB2aXNpb24uDQoNCj4gDQo+IEpGDQo+IA0KPiANCj4gDQo+IA0KPiAN
Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gU3Vw
YSBtYWlsaW5nIGxpc3QNCj4gU3VwYUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9t
YWlsbWFuL2xpc3RpbmZvL3N1cGENCg0KQmVzdCBSZWdhcmRzLA0KSlINCi0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tDQpKdW5ydSBMaW4NCkludGVncmF0aW9uIFRlY2hub2xvZ3kgUmVzZWFyY2ggRGVwdA0KSHVh
d2VpIFRlY2hub2xvZ2llcyBDby4sTHRkDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoNCg==


From nobody Tue Sep 30 03:21:51 2014
Return-Path: 
X-Original-To: supa@ietfa.amsl.com
Delivered-To: supa@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 785C61A0331; Tue, 30 Sep 2014 03:21:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.987
X-Spam-Level: 
X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 dn21brwtNA2N; Tue, 30 Sep 2014 03:21:44 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 624501A031F; Tue, 30 Sep 2014 03:21:43 -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 BKB72285; Tue, 30 Sep 2014 10:21:30 +0000 (GMT)
Received: from LHREML516-MBX.china.huawei.com ([169.254.1.85]) by lhreml402-hub.china.huawei.com ([10.201.5.241]) with mapi id 14.03.0158.001; Tue, 30 Sep 2014 11:21:23 +0100
From: Georgios Karagiannis 
To: Kostas Pentikousis 
Thread-Topic: [Supa] New SUPA charter
Thread-Index: Ac/ZIUcaEK+SU+lYTNqeRV6T6bQAHwA3sVMAAHt6SIAAKi/zMA==
Date: Tue, 30 Sep 2014 10:21:23 +0000
Message-ID: 
References:   <0C7EDCF89AB9E2478B5D010026CFF4AEA10C72ADDE@SBS2008.eict.local>
In-Reply-To: <0C7EDCF89AB9E2478B5D010026CFF4AEA10C72ADDE@SBS2008.eict.local>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.221.64.47]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/supa/kpfX7NyvIE3I4Wp3xmENkn5jytM
Cc: "nmrg@irtf.org" , "supa@ietf.org" , Parviz Yegani 
Subject: Re: [Supa] New SUPA charter
X-BeenThere: supa@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Sep 2014 10:21:45 -0000

RGVhciBLb3N0YXMsDQoNClRoYW5rIHlvdSB2ZXJ5IG11Y2ggZm9yIHRoZSBwcm92aWRlZCBjb21t
ZW50cyBvbiB0aGUgU1VQQSBjaGFydGVyIQ0KDQpQbGVhc2Ugc2VlIGluIGxpbmUhDQoNCj4gLS0t
LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogS29zdGFzIFBlbnRpa291c2lzIFttYWls
dG86ay5wZW50aWtvdXNpc0BlaWN0LmRlXQ0KPiBTZW50OiBNb25kYXksIFNlcHRlbWJlciAyOSwg
MjAxNCA1OjAyIFBNDQo+IFRvOiBQYXJ2aXogWWVnYW5pOyBHZW9yZ2lvcyBLYXJhZ2lhbm5pcw0K
PiBDYzogc3VwYUBpZXRmLm9yZzsgbm1yZ0BpcnRmLm9yZw0KPiBTdWJqZWN0OiBBVzogW1N1cGFd
IE5ldyBTVVBBIGNoYXJ0ZXINCj4gDQo+IEhpIEdlb3JnaW9zLA0KPiANCj4gSSBzZWNvbmQgUGFy
dml6LCBpdOKAmXMgbXVjaCBiZXR0ZXIgYWZ0ZXIgdGhlIHJlY2VudCByZXZpc2lvbnMuIEEgZmV3
IGNvbW1lbnRzDQo+IHdydCB0byB0aGUgdmVyc2lvbiBhdCBodHRwczovL2dpdGh1Yi5jb20vbGl1
c2h1Y2hlbmcvU1VQQS93aWtpL1NVUEEtQ2hhcnRlcg0KPiANCj4gRG8gd2UgbmVlZCB0aGlzIHBo
cmFzZTogInRvIHNoaWZ0IHRoZSBiYWxhbmNlIFtvZiBjb3N0cz9dIGluIHRoZWlyIGZhdm9yIj8N
Cj4gU1VQQSBzaG91bGQgbm90IGJlIGEgemVyby1zdW0gZ2FtZS4gRXZlcnlvbmUgc2hvdWxkIGJl
bmVmaXQgKHZlbmRvcnMsDQo+IG9wZXJhdG9ycywgYWRtaW5zLCB1c2VycywgbmV3IHNlcnZpY2Ug
cHJvdmlkZXJzKS4NCls+XSANCkdlb3JnaW9zOiBBZ3JlZSB3aXRoIHlvdSwgdGhhdCBldmVyeW9u
ZSBzaG91bGQgYmVuZWZpdCAodmVuZG9ycywNCm9wZXJhdG9ycywgYWRtaW5zLCB1c2VycywgbmV3
IHNlcnZpY2UgcHJvdmlkZXJzKS4NCldlIG5lZWQgdG8gcmVwaHJhc2UgdGhpcyB0ZXh0LiANCg0K
PiANCj4gRG8gd2UgUkVBTExZIGhhdmUgdG8gY2FwaXRhbGl6ZSBQT0xJQ1ksIFVOSUZJRUQsIFNI
QVJFRCwgYW5kIEFVVE9NQVRJQ0FMTFk/IDopDQpbPl0gDQpHZW9yZ2lvczogbm90IHJlYWxseSwg
d2UganVzdCB1c2VkIHRoZW0gdG8gbWFrZSB0aGUgZW1waGFzaXplIGhvdyB0aGUgU1VQQSBhYmJy
ZXZpYXRpb24gcmVsYXRlcyB0byB0aGUgY2hhcnRlciBkZXNjcmlwdGlvbi4gSSBhc3N1bWUgdGhh
dCB3ZSBjYW4gbWFyayB0aGVzZSB3b3JkcyB1c2luZyBhbm90aGVyIG1ldGhvZCwgZS5nLiwgIiIN
Cg0KPiANCj4gVGhlIHBhcmFncmFwaCBzdGFydGluZyB3aXRoICJTb21lIElFVEYgd29ya2luZyBn
cm91cHMuLi4iIG1heSBiZSB1c2VmdWwgdG8NCj4gbW90aXZhdGUgY2hhcnRlcmluZyB0aGUgV0cs
IGJ1dCBJJ20gbm90IHN1cmUgaXQgc2hvdWxkIGJlIHBhcnQgb2YgdGhlIGZpbmFsDQo+IGNoYXJ0
ZXIuDQpbPl0gDQoNCkdlb3JnaW9zOiBOb3Qgc3VyZSwgaG93IHdlIHNob3VsZCBoYW5kbGUgdGhp
cyBpc3N1ZS4gV2UgdXNlZCB0aGUgcGFyYWdyYXBoIHRvIHNob3cgdGhlIHJlbGF0aW9uIHdpdGgg
b3RoZXIgSUVURiBXR3MuDQoNCj4gDQo+IEZpbmFsbHksIHRoZSBsYXN0IHBhcmFncmFwaHMgc3Rh
cnRpbmcgd2l0aCAiU1VQQSB3aWxsIHdvcmsgb24gZGVmaW5pbmcuLi4gIg0KPiBhbmQgZW5kaW5n
IHdpdGggdGhlIHNlY3Rpb24gb24gV29yayBJdGVtcyBoYXMgYSBiaXQgb2Ygb3ZlcmxhcCB3aXRo
IHRoZQ0KPiByZW1haW5pbmcgdGV4dCAoV29yayBJdGVtcywgRGVsaXZlcmFibGVzKS4gDQpbPl0g
DQoNCkdlb3JnaW9zOiBUaGFua3MsICB3ZSB3aWxsIHRyeSB0byByZW1vdmUgdGhlIG92ZXJsYXAg
YXMgbXVjaCBhcyBwb3NzaWJsZS4NCg0KSSBoYXZlIGEgZmV3IG1vcmUgZWRpdG9yaWFsDQo+IGNv
bW1lbnRzIChlLmcuIHMvc3RhcnRlZCB3b3JrIHJlbGF0aW5nL3N0YXJ0ZWQgd29yayByZWxhdGVk
KSwgYnV0IHdlIGNhbg0KPiBoYW5kbGUgdGhhdCBvZmZsaW5lLg0KWz5dIA0KDQpHZW9yZ2lvczog
dGhhbmsgeW91IHZlcnkgbXVjaCENCg0KQmVzdCByZWdhcmRzLA0KR2Vvcmdpb3MNCg0KPiANCj4g
QmVzdCByZWdhcmRzLA0KPiANCj4gS29zdGFzDQo+IA0KPiBQUzogSSB0b29rIHRoZSBsaWJlcnR5
IHRvIENDIE5NUkcgYXMgc29tZSBmb2xrcyBpbiB0aGF0IGdyb3VwIG1heSBoYXZlIGFuDQo+IGlu
dGVyZXN0IGluIHRoaXMgbGluZSBvZiB3b3JrLg0KPiANCj4gfCBWb246IFBhcnZpeiBZZWdhbmkg
W21haWx0bzpweWVnYW5pQGdtYWlsLmNvbV0NCj4gfCBHZXNlbmRldDogU2Ftc3RhZywgMjcuIFNl
cHRlbWJlciAyMDE0IDA2OjA3DQo+IHwgQW46IEdlb3JnaW9zIEthcmFnaWFubmlzDQo+IHwgQ2M6
IHN1cGFAaWV0Zi5vcmcNCj4gfCBCZXRyZWZmOiBSZTogW1N1cGFdIE5ldyBTVVBBIGNoYXJ0ZXIN
Cj4gfA0KPiB8IEdyZWF0IGpvYiBHZW9yZ2lvcy4gVGhlIGNoYXJ0ZXIgaXMgd2VsbCB3cml0dGVu
IGFuZCBuaWNlbHkgc3RydWN0dXJlZC4NCj4gfCBUaGUgbm90aW9uIG9mICJuZXR3b3JrIGJveGVz
IiwgaG93ZXZlciwgaXMgYSBiaXQgY29uZnVzaW5nLiBJJ2QgcmF0aGVyDQo+IHwgdG8gcmVwbGFj
ZSBpdCB3aXRoICJuZXR3b3JrIG5vZGVzIiBvciAibmV0d29yayBjb21wb25lbnRzIi4gSSBhbHNv
DQo+IHwgaGF2ZSBzb21lIG90aGVyIG1pbm9yIGVkaXRvcmlhbCBjb21tZW50cy4gSSB3aWxsIHNl
bmQgaXQgaW4gYSBzZXBhcmF0ZQ0KPiB8IGVtYWlsLiBJdCdzIGdvb2QgdGhhdCB5b3UgbWVudGlv
bmVkIHRoZSBTVVBBIFdHIChvbmNlIGZvcm1lZCkgd2lsbA0KPiBjb2xsYWJvcmF0ZSB3aXRoIG90
aGVyIHJlbGV2YW50IGdyb3VwcyB3aXRoaW4gSUVURiAoTkVUQ09ORiwgWWFuZyBkb2N0b3JzLCAu
LikNCj4gdG8gZW5zdXJlIGNvbnNpc3RlbmN5IGFuZCBhdm9pZCBkaXZlcmdlbmNlIG9yIHBlcmhh
cHMgYW55IHBvc3NpYmxlIGR1cGxpY2F0aW9uDQo+IG9mIHdvcmsuDQo+IA0KPiB8IFRoYW5rcywN
Cj4gfCBQYXJ2aXoNCg==


From nobody Tue Sep 30 04:14:14 2014
Return-Path: 
X-Original-To: supa@ietfa.amsl.com
Delivered-To: supa@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 552C91A037D for ; Tue, 30 Sep 2014 04:14:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.986
X-Spam-Level: 
X-Spam-Status: No, score=-3.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_AFFORDABLE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 9h0sa3W0vxS8 for ; Tue, 30 Sep 2014 04:14:06 -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 6DE3D1A037F for ; Tue, 30 Sep 2014 04:14:05 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNE04260; Tue, 30 Sep 2014 11:14:03 +0000 (GMT)
Received: from SZXEML453-HUB.china.huawei.com (10.82.67.196) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 30 Sep 2014 12:13:58 +0100
Received: from szxeml557-mbs.china.huawei.com ([169.254.6.57]) by SZXEML453-HUB.china.huawei.com ([10.82.67.196]) with mapi id 14.03.0158.001; Tue, 30 Sep 2014 19:13:17 +0800
From: Tina TSOU 
To: "Eric Voit (evoit)" 
Thread-Topic: [netmod] "00" Notification for draft-voit-netmod-peer-mount-requirements
Thread-Index: Ac/ZjioymKhX4n/+Q0irapwH2HUqIwAAEm2AAEtmX7AAQ3RaMAAHV34gAC4S59E=
Date: Tue, 30 Sep 2014 11:13:16 +0000
Message-ID: <8F55D6F3-14C8-4F45-8F7C-A4CDA8DCA1FE@huawei.com>
References:    , 
In-Reply-To: 
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_8F55D6F314C84F458F7CA4CDA8DCA1FEhuaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/supa/HiBUcf6tafQ9azpdbiDySmVHGzw
Cc: Georgios Karagiannis , "Alexander Clemm \(alex\)" , "supa@ietf.org" 
Subject: Re: [Supa] [netmod] "00" Notification for draft-voit-netmod-peer-mount-requirements
X-BeenThere: supa@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Sep 2014 11:14:11 -0000

--_000_8F55D6F314C84F458F7CA4CDA8DCA1FEhuaweicom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Dear Eric,

In line...


Thank you,
Tina

On Sep 29, 2014, at 10:10 PM, "Eric Voit (evoit)" > wrote:

From: Tina TSOU, September 29, 2014 5:50 AM

Dear Eric et al,

Now I read draft-voit-netmod-peer-mount-requirements, it is very good
at describing the requirements.

In this draft, two optional architectures were proposed: a centralized one
similar to SUPA and a distributed one which is also compatible with SUPA
(with a little extension of SUPA charter and scope, would you please review
the charter of SUPA and provide some text for modification?).

Will do in a separate response.
Got it.

That was very useful as a booster for a converged version of charter.


One key requirement of SUPA is network-wide modeling for standardizing.
In your work, is there also a similar requirement?

>From an application standpoint, I expect that there will be many network wi=
de
service models which match to applications.  Since applications will always
want their minimal management model, the trick will be to instrument the
interfaces for easy meshing with places like OpenStack, OPNFV, OpenDaylight=
.

IMHO, it is premature to start standardizing many (most?) application model=
s
Northbound of a controller.  We don't know which services will be successfu=
l.
We don't know enough about key scale or operational considerations.
Agree. Not everything, just a little piece of all the puzzles.

The IESG suggested network management services, especially distributed data=
 center services, before Toronto.

There are a few solid use cases, and you also brought "mount" use case.
https://datatracker.ietf.org/doc/draft-cheng-supa-ddc-use-cases/
https://datatracker.ietf.org/doc/draft-sun-supa-openv6-use-cases/

Openstack Neutron is mostly interested at the L3VPN service NBIs.
https://datatracker.ietf.org/doc/draft-zaalouk-supa-configuration-model/
is a starting point for virtual links.

Look forward to the models you mentioned earlier.

It can be stand alone side by side, or converge with others.


I mean, do you need the model between app and network element be
standardized?

No.  I want to work with existing device models.  However if a multi-networ=
k
element application sits in an container which is co-resident on/near the
network element, then this could be standardized.
Thank you for considering the popular scenarios.


Have you considered the mapping mechanism from network-wide model
to device level configuration? This is part of the work of SUPA.

Yes.
IMHO, https://datatracker.ietf.org/doc/draft-pentikousis-supa-mapping/ need=
s to consider "mount" case in later version.

I would agree that there are many benefits of using distributed solution,
however, there is one key issue: if the decisions or actions from different
network elements are difference and incompatible, how to avoid the
fluctuation?

This is the most interesting part of the problem.   One benefit of our "Mou=
nt"
approach is that authoritative objects are accessible anywhere in a domain.
- "peer mount" infrastructure is agnostic to where such check occur
- changes in state can be monitored on remote devices via subscription
- distributed objects previous inaccessible can now be compared
- consistency applets (driven by these triggers) can be placed anywhere

>From there it is local business logic which determines what to do if
different authoritative objects end up being incompatible.  Often it is
possible to mechanize the resolution.

This is exactly why we are pushing "Eventual Consistency".  Routing
Protocols and Amazon.com's shopping cart system have add=
ressed these
problems extremely well.  It is time to apply these solutions to general
networking policy.  Even multiple controller environments can be supported.
Exactly, I lean more to the Amazon and Tencent like approaches.

That's what I mean below.


IMHO, this may be solved by slicing the resource or using
multiple instances from virtualization? Or using the consistence check of
distributed database?

Some words from this draft may imply the requirement for extending the
existing NETCONF. But I=92m not sure. Do you really want that?

What I want is the standards track for a new version of
draft-clemm-netmod-mount.   The version should be out soon.
Look forward to the new version.

If there is potential change to Netconf, should that part be sent to the Ne=
tconf WG?


Eric

Hope it helps.


Thank you,
Tina

From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Tina TSOU
Sent: Sunday, September 28, 2014 9:38 AM
To: Georgios Karagiannis; Eric Voit (evoit); supa@ietf.org
Cc: Alexander Clemm (alex)
Subject: Re: [Supa] [netmod] "00" Notification for draft-voit-netmod-peer-m=
ount-requirements

Dear Eric et al,

Distributed Data Center services are typical case for SUPA.
Your submission of drafts are very welcome.

You may be interested to look at these.
draft-cheng-supa-ddc-use-cases-00
Use Cases for Distributed Data Center Applications in SUPA
2014-09-17
new
I-D Exists



draft-contreras-supa-yang-network-topo-00
A YANG Data Model for Network Topologies
2014-09-18
new
I-D Exists



draft-zaalouk-supa-configuration-model-00
YANG Data Model for Configuration of Shared Unified Policy Automation (SUPA=
)
2014-09-22
new
I-D Exists
draft-pentikousis-supa-mapping-00
SUPA Configuration and Policy Mapping
2014-09-23
new
I-D Exists










Thank you,
Tina

-----Original Message-----
From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Georgios Karagiannis
Sent: Friday, September 26, 2014 9:35 PM
To: Eric Voit (evoit); supa@ietf.org
Cc: Alexander Clemm (alex)
Subject: Re: [Supa] [netmod] "00" Notification for draft-voit-netmod-peer-m=
ount-requirements

Hi Eric,

Thanks for the information.
I have not read your draft in detail, but from your explanation, it might b=
e relevant to SUPA.

Best regards,
Georgios


-----Original Message-----
From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Eric Voit
(evoit)
Sent: Friday, September 26, 2014 2:32 PM
To: supa@ietf.org
Cc: Alexander Clemm (alex)
Subject: [Supa] FW: [netmod] "00" Notification for
draft-voit-netmod-peer- mount-requirements

I just learned about SUPA, and based on the evolving charter it seems
quite relevant to an informational draft several of us submitted to Netmod =
yesterday.
http://www.ietf.org/internet-drafts/draft-voit-netmod-peer-mount-requi
rements-
00.txt

Our draft aggregates requirements we have uncovered as we have built
several new Data Center edge services upon an Open Daylight
controller.  We already have a working YANG service model for two of the tw=
o services in the draft.
If there is interest here, I could publish that model as well.

Thanks,
Eric

-----Original Message-----
From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Eric Voit,
September 25, 2014 6:38 PM

We have been developing SDN applications which require quick,
iterative access to objects representing network and device
abstractions.  These objects include ones authoritatively owned by a
local system, as well as ones provided from remote datastores.  Two
such applications we have prototyped are =93Cloud Policer=94 and =93DDoS
Thresholding=94.  (See links below for more on these apps.)

The good news is that we found YANG models and syntax to be a nice fit
for these applications.   However we have been trying to cover several
missing
elements:

Missing Element #1: Developer Simplicity We wanted applications to
access remote objects from a single datastore, without having to have
the applications peer directly with remote devices.  We also wanted
clients and applications to access datastores in the same way
independent of whether the applications were hosted on a Network Element or=
 Controller.

Missing Element #2: Who owns an Object?
Applications can't tell which Network Element across a set of devices
is the authoritative owner of a particular replicated object.  Since
replicated data gets out of synch, resolution / convergence is a problem.

Missing Element #3: Maintaining caches of remote information
Applications need timely access to remote information, which can
necessitate the introduction cache infrastructure.  Netconf provides
little support to facilitate this.  For example, notifications are not
a good match to subscribe to push- updates.

To solve these problems, we need technology solutions which work
equally well for both Controllers and Network Elements.  These
solutions must expose local datastores which provide authoritative,
consolidated views of distributed network objects.  This must be done
in a way which allows the applications to sit anywhere in the network,
on various abstractions, while maintaining domain consistency. And
this must be done while maximizing application developer simplicity.

This draft is intended to start aggregating requirements in this
space.  The draft is not complete, so it would be great to hear from
others who are interested in helping so that we end up with a more comprehe=
nsive context.

Solutions do exist which can solve a subset of these requirements.
One particular technology we have built is known as =93peer mount=94.
Peer mount gives the ability to reference YANG information into a
local datastore from remote datastores.  This provides client
applications with local access to information which might be
transparently federated across multiple systems and datastores.  It
also retains clear object ownership to minimize synchronization and
inter-system dependency issues.   There are already implementations of
this technology, for example, in Open Daylight.  However, we believe
requirements and use cases for this technology apply equally well to networ=
k devices.

Please let us know if either the requirements or technology
specifications are problem you are interested in exploring.

Thanks!
Eric, Alex, Prabhakara, Ambika, Shashi

-----Original Message-----
From: internet-drafts@ietf.org [mailto:int=
ernet-drafts@ietf.org]
Sent: Thursday, September 25, 2014 8:41 AM
To: Prabhakara Yellai (pyellai); Shashi Kumar Bansal (shabansa);
Ambika Prasad Tripathy (ambtripa); Alexander Clemm (alex); Eric Voit
(evoit); Ambika Prasad Tripathy (ambtripa); Alexander Clemm (alex);
Prabhakara Yellai (pyellai); Eric Voit (evoit); Shashi Kumar Bansal
(shabansa)
Subject: New Version Notification for draft-voit-netmod-peer-mount-
requirements-00.txt


A new version of I-D, draft-voit-netmod-peer-mount-requirements-00.txt
has been successfully submitted by Eric Voit and posted to the IETF reposit=
ory.

Name:                  draft-voit-netmod-peer-mount-requirements
Revision:              00
Title:                     Requirements for Peer Mounting of YANG
subtrees from Remote Datastores Document date: 2014-09-25
Group:                  Individual Submission
Pages:                  22
URL:
http://www.ietf.org/internet-drafts/draft-voit-netmod-peer-
mount-requirements-00.txt
Status:
https://datatracker.ietf.org/doc/draft-voit-netmod-peer-mount-
requirements/
Htmlized:
http://tools.ietf.org/html/draft-voit-netmod-peer-mount-
requirements-00


Abstract:
   Network integrated applications want simple ways to access YANG
   objects and subtrees which might be distributed across network.
   Performance requirements may dictate that it is unaffordable for a
   subset of these applications to go through existing centralized
   management brokers.  For such applications, development complexity
   must be minimized.  Specific aspects of complexity developers want
to
   ignore include:

   o  whether authoritative information is actually sourced from
remote
      datastores (as well as how to get to those datastores),

   o  whether such information has been locally cached or not,

   o  whether there are zero, one, or more controllers asserting
      ownership of information, and

   o  whether there are interactions with other applications
      concurrently running elsewhere

   The solution requirements described in this document detail what is
   needed to support application access to authoritative network YANG
   objects from controllers (star) or peering network devices (mesh)
in
   such a way to meet these goals.





Please note that it may take a couple of minutes from the time of
submission until the htmlized version and diff are available at tools.ietf.=
org.

The IETF Secretariat

_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
Supa mailing list
Supa@ietf.org
https://www.ietf.org/mailman/listinfo/supa
_______________________________________________
Supa mailing list
Supa@ietf.org
https://www.ietf.org/mailman/listinfo/supa


--_000_8F55D6F314C84F458F7CA4CDA8DCA1FEhuaweicom_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable







Dear Eric,







In line...










Thank you,


Tina






On Sep 29, 2014, at 10:10 PM, "Eric Voit (evoit)" <evoit@cisco.com> wrote:










From: Tina TSOU, September 29, 2014 5:50 AM=










Dear Eric et al,









Now I read draft-voit-netmod-peer-mount-req=
uirements, it is very good





at describing the requirements.









In this draft, two optional architectures w=
ere proposed: a centralized one





similar to SUPA and a distributed one which=
 is also compatible with SUPA





(with a little extension of SUPA charter an=
d scope, would you please review





the charter of SUPA and provide some text f=
or modification?).





Will do in a separate response.





Got it.






That was very useful as a booster for a converged version of charter.<=
/div>









One key requirement of SUPA is network-wide=
 modeling for standardizing.





In your work, is there also a similar requi=
rement?





From an application standpoint, I expect that there will be many netw=
ork wide


service models which match to applications.  Since applications =
will always

want their minimal management model, the trick will be to instrument =
the

interfaces for easy meshing with places like OpenStack, OPNFV, OpenDa=
ylight.



IMHO, it is premature to start standardizing many (most?) application=
 models


Northbound of a controller.  We don't know which services will b=
e successful.  

We don't know enough about key scale or operational considerations.





Agree. Not everything, just a little piece of all the puzzles.







The IESG suggested network management services, especially distributed=
 data center services, before Toronto.







There are a few solid use cases, and you also brought "mount"=
; use case.









Openstack Neutron is mostly interested at the L3VPN service NBIs.


is a starting point for virtual links.







Look forward to the models you mentioned earlier.







It can be stand alone side by side, or converge with others.










I mean, do you need the model between app a=
nd network element be





standardized?





No.  I want to work with existing device models.  However i=
f a multi-network


element application sits in an container which is co-resident on/near=
 the 


network element, then this could be standardized.  





Thank you for considering the popular scenarios.










Have you considered the mapping mechanism f=
rom network-wide model





to device level configuration? This is part=
 of the work of SUPA.





Yes.





IMHO, https://datatracker.ietf.org/doc/draft-pentikousis-supa-mappin=
g/ needs to consider "mount" case in later version.








I would agree that there are many benefits =
of using distributed solution,





however, there is one key issue: if the dec=
isions or actions from different





network elements are difference and incompa=
tible, how to avoid the





fluctuation? 





This is the most interesting part of the problem.   One ben=
efit of our "Mount"


approach is that authoritative objects are accessible anywhere in a d=
omain.  

- "peer mount" infrastructure is agnostic to where such che=
ck occur

- changes in state can be monitored on remote devices via subscriptio=
n

- distributed objects previous inaccessible can now be compared

- consistency applets (driven by these triggers) can be placed anywhe=
re



From there it is local business logic which determines what to do if =



different authoritative objects end up being incompatible.  Ofte=
n it is 


possible to mechanize the resolution.  



This is exactly why we are pushing "Eventual Consistency". =
 Routing 


Protocols and Amazon.com's shopping=
 cart system have addressed these


problems extremely well.  It is time to apply these solutions to=
 general 


networking policy.  Even multiple controller environments can be=
 supported.





Exactly, I lean more to the Amazon and Tencent like approaches.







That's what I mean below.


 







IMHO, this may be solved by slicing the res=
ource or using





multiple instances from virtualization? Or =
using the consistence check of





distributed database?









Some words from this draft may imply the re=
quirement for extending the





existing NETCONF. But I=92m not sure. Do yo=
u really want that?





What I want is the standards track for a new version of 

draft-clemm-netmod-mount.   The version should be out soon.=






Look forward to the new version.







If there is potential change to Netconf, should that part be sent to t=
he Netconf WG?









Eric 




Hope it helps.




  









Thank you,




Tina









From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Tina TSOU



Sent: Sunday, September 28, 2014 9:38 AM




To: Georgios Karagiannis; Eric Voit (evoit)=
; 
supa@ietf.org




Cc: Alexander Clemm (alex)




Subject: Re: [Supa] [netmod] "00"=
 Notification for draft-voit-netmod-peer-mount-requirements









Dear Eric et al,









Distributed Data Center services are typica=
l case for SUPA.




Your submission of drafts are very welcome.=










You may be interested to look at these. &nb=
sp; 




draft-cheng-supa-ddc-use-cases-00 


Use Cases for Distributed Data Center Applications in SUPA

2014-09-17 


new



I-D Exists 







draft-contreras-supa-yang-network-topo-00 

A YANG Data Model for Network Topologies

2014-09-18 


new



I-D Exists 







draft-zaalouk-supa-configuration-model-00 

YANG Data Model for Configuration of Shared Unified Policy Automation=
 (SUPA)

2014-09-22 


new



I-D Exists 

draft-pentikousis-supa-mapping-00 

SUPA Configuration and Policy Mapping

2014-09-23 


new



I-D Exists 

























Thank you,




Tina









-----Original Message-----




From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Georgios Karagiann=
is




Sent: Friday, September 26, 2014 9:35 PM




To: Eric Voit (evoit); 
supa@ietf.org




Cc: Alexander Clemm (alex)




Subject: Re: [Supa] [netmod] "00"=
 Notification for draft-voit-netmod-peer-mount-requirements









Hi Eric,









Thanks for the information.




I have not read your draft in detail, but f=
rom your explanation, it might be relevant to SUPA.









Best regards,




Georgios
















-----Original Message-----








From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Eric Voit









(evoit)








Sent: Friday, September 26, 2014 2:32 PM








To: supa@i=
etf.org








Cc: Alexander Clemm (alex)








Subject: [Supa] FW: [netmod] "00"=
 Notification for 









draft-voit-netmod-peer- mount-requirements<=
/span>

















I just learned about SUPA, and based on the=
 evolving charter it seems









quite relevant to an informational draft se=
veral of us submitted to Netmod yesterday.








http://www.ietf.org/internet-drafts=
/draft-voit-netmod-peer-mount-requi








rements-








00.txt

















Our draft aggregates requirements we have u=
ncovered as we have built









several new Data Center edge services upon =
an Open Daylight









controller.  We already have a working=
 YANG service model for two of the two services in the draft.








If there is interest here, I could publish =
that model as well.

















Thanks,








Eric

















-----Original Message-----








From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Eric Voit,









September 25, 2014 6:38 PM

















We have been developing SDN applications wh=
ich require quick,









iterative access to objects representing ne=
twork and device









abstractions.  These objects include o=
nes authoritatively owned by a









local system, as well as ones provided from=
 remote datastores.  Two









such applications we have prototyped are =
=93Cloud Policer=94 and =93DDoS









Thresholding=94.  (See links below for=
 more on these apps.)

















The good news is that we found YANG models =
and syntax to be a nice fit









for these applications.   However=
 we have been trying to cover several









missing








elements:

















Missing Element #1: Developer Simplicity We=
 wanted applications to









access remote objects from a single datasto=
re, without having to have









the applications peer directly with remote =
devices.  We also wanted









clients and applications to access datastor=
es in the same way









independent of whether the applications wer=
e hosted on a Network Element or Controller.

















Missing Element #2: Who owns an Object?








Applications can't tell which Network Eleme=
nt across a set of devices









is the authoritative owner of a particular =
replicated object.  Since









replicated data gets out of synch, resoluti=
on / convergence is a problem.

















Missing Element #3: Maintaining caches of r=
emote information









Applications need timely access to remote i=
nformation, which can









necessitate the introduction cache infrastr=
ucture.  Netconf provides









little support to facilitate this.  Fo=
r example, notifications are not









a good match to subscribe to push- updates.=


















To solve these problems, we need technology=
 solutions which work









equally well for both Controllers and Netwo=
rk Elements.  These









solutions must expose local datastores whic=
h provide authoritative,









consolidated views of distributed network o=
bjects.  This must be done









in a way which allows the applications to s=
it anywhere in the network,









on various abstractions, while maintaining =
domain consistency. And









this must be done while maximizing applicat=
ion developer simplicity.

















This draft is intended to start aggregating=
 requirements in this









space.  The draft is not complete, so =
it would be great to hear from









others who are interested in helping so tha=
t we end up with a more comprehensive context.

















Solutions do exist which can solve a subset=
 of these requirements. 









One particular technology we have built is =
known as =93peer mount=94. 









Peer mount gives the ability to reference Y=
ANG information into a









local datastore from remote datastores.&nbs=
p; This provides client









applications with local access to informati=
on which might be









transparently federated across multiple sys=
tems and datastores.  It









also retains clear object ownership to mini=
mize synchronization and









inter-system dependency issues.  =
 There are already implementations of









this technology, for example, in Open Dayli=
ght.  However, we believe









requirements and use cases for this technol=
ogy apply equally well to network devices.

















Please let us know if either the requiremen=
ts or technology









specifications are problem you are interest=
ed in exploring.

















Thanks!








Eric, Alex, Prabhakara, Ambika, Shashi

















-----Original Message-----








From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]








Sent: Thursday, September 25, 2014 8:41 AM<=
/span>








To: Prabhakara Yellai (pyellai); Shashi Kum=
ar Bansal (shabansa);









Ambika Prasad Tripathy (ambtripa); Alexande=
r Clemm (alex); Eric Voit









(evoit); Ambika Prasad Tripathy (ambtripa);=
 Alexander Clemm (alex);









Prabhakara Yellai (pyellai); Eric Voit (evo=
it); Shashi Kumar Bansal









(shabansa)








Subject: New Version Notification for draft=
-voit-netmod-peer-mount-









requirements-00.txt


























A new version of I-D, draft-voit-netmod-pee=
r-mount-requirements-00.txt








has been successfully submitted by Eric Voi=
t and posted to the IETF repository.

















Name:      &n=
bsp;           draft-voit=
-netmod-peer-mount-requirements








Revision:     &nbs=
p;        00








Title:      &=
nbsp;           &nbs=
p;  Requirements for Peer Mounting of YANG









subtrees from Remote Datastores Document da=
te: 2014-09-25








Group:      &=
nbsp;           Individua=
l Submission








Pages:      &=
nbsp;           22=









URL:      &nb=
sp;     








http://www.ietf.org/internet-drafts/draft-voit=
-netmod-peer-








mount-requirements-00.txt








Status:      =
   








https://datatracker.ietf.org/doc/draft-voit=
-netmod-peer-mount-








requirements/








Htmlized:     &nbs=
p; 








http://tools.ietf.org/html/draft-voit-netmod-peer=
-mount-








requirements-00


























Abstract:








   Network integrated application=
s want simple ways to access YANG








   objects and subtrees which mig=
ht be distributed across network.








   Performance requirements may d=
ictate that it is unaffordable for a








   subset of these applications t=
o go through existing centralized








   management brokers.  For =
such applications, development complexity








   must be minimized.  Speci=
fic aspects of complexity developers want









to








   ignore include:

















   o  whether authoritative =
information is actually sourced from









remote








      datastores (=
as well as how to get to those datastores),

















   o  whether such informati=
on has been locally cached or not,

















   o  whether there are zero=
, one, or more controllers asserting








      ownership of=
 information, and

















   o  whether there are inte=
ractions with other applications








      concurrently=
 running elsewhere

















   The solution requirements desc=
ribed in this document detail what is








   needed to support application =
access to authoritative network YANG








   objects from controllers (star=
) or peering network devices (mesh)









in








   such a way to meet these goals=
.





















































Please note that it may take a couple of mi=
nutes from the time of









submission until the htmlized version and d=
iff are available at
tools.ietf.org.

















The IETF Secretariat

















___________________________________________=
____








netmod mailing list








netmod@i=
etf.org








https://www.ietf.org/mailman/listinfo/netmod








___________________________________________=
____








Supa mailing list








Supa@ietf.=
org








https://www.ietf.org/mailman/listinfo/supa






___________________________________________=
____




Supa mailing list




Supa@ietf.=
org




https://www.ietf.org/mailman/listinfo/supa

















--_000_8F55D6F314C84F458F7CA4CDA8DCA1FEhuaweicom_--


From nobody Tue Sep 30 15:16:55 2014
Return-Path: 
X-Original-To: supa@ietfa.amsl.com
Delivered-To: supa@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56BCB1ACC85 for ; Tue, 30 Sep 2014 15:16:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.787
X-Spam-Level: 
X-Spam-Status: No, score=-0.787 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.786, 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 BYIoR5BZRuVC for ; Tue, 30 Sep 2014 15:16:47 -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 3DC271ACC81 for ; Tue, 30 Sep 2014 15:16:45 -0700 (PDT)
Received: from smtptc.telefonica.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id E3C0D3700EF; Wed,  1 Oct 2014 00:16:42 +0200 (CEST)
Received: from ESTGVMSP105.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 C75F93700E7; Wed,  1 Oct 2014 00:16:42 +0200 (CEST)
Received: from emea01-am1-obe.outbound.protection.outlook.com (10.92.5.139) by tls.telefonica.com (10.92.6.51) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 1 Oct 2014 00:16:42 +0200
Received: from DB4PR06MB576.eurprd06.prod.outlook.com (10.242.192.23) by DB4PR06MB576.eurprd06.prod.outlook.com (10.242.192.23) with Microsoft SMTP Server (TLS) id 15.0.1039.15; Tue, 30 Sep 2014 22:16:41 +0000
Received: from DB4PR06MB576.eurprd06.prod.outlook.com ([10.242.192.23]) by DB4PR06MB576.eurprd06.prod.outlook.com ([10.242.192.23]) with mapi id 15.00.1039.011; Tue, 30 Sep 2014 22:16:41 +0000
From: LUIS MIGUEL CONTRERAS MURILLO 
To: JF Tremblay 
Thread-Topic: [Supa] New Version Notification for draft-contreras-supa-yang-network-topo-00.txt
Thread-Index: AQHP0xTtYNoV/hmyG0eLnhFczRTp4pwGg71AgADS8YCAEvbtcA==
Date: Tue, 30 Sep 2014 22:16:41 +0000
Message-ID: <847df8c42e344ba389f43e6e86743921@DB4PR06MB576.eurprd06.prod.outlook.com>
References: <20140918074811.15859.74757.idtracker@ietfa.amsl.com> <716e56912f124e2d8c13148c5b83f1f5@DB4PR06MB576.eurprd06.prod.outlook.com> 
In-Reply-To: 
Accept-Language: es-ES, en-US
Content-Language: es-ES
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [79.144.77.90]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DB4PR06MB576;
x-forefront-prvs: 0350D7A55D
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(51914003)(189002)(24454002)(377424004)(59124003)(199003)(377454003)(19580405001)(10300001)(106356001)(105586002)(110136001)(87936001)(95666004)(50986999)(92566001)(21056001)(19609705001)(33646002)(120916001)(19580395003)(230783001)(108616004)(76176999)(4396001)(15975445006)(64706001)(54356999)(19617315012)(85852003)(85306004)(106116001)(19625215002)(101416001)(80022003)(46102003)(66066001)(74316001)(76482002)(107046002)(2656002)(97736003)(31966008)(14971765001)(99396003)(15202345003)(19300405004)(16236675004)(16601075003)(20776003)(76576001)(86362001)(24736002)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR06MB576; H:DB4PR06MB576.eurprd06.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
Content-Type: multipart/alternative; boundary="_000_847df8c42e344ba389f43e6e86743921DB4PR06MB576eurprd06pro_"
MIME-Version: 1.0
X-OriginatorOrg: telefonica.com
X-TM-AS-MML: No
Archived-At: http://mailarchive.ietf.org/arch/msg/supa/nB3dnjH1OVk4f5n2CyQ-YjttTM0
Cc: "andrew.qu@mediatek.com" , "supa@ietf.org" 
Subject: Re: [Supa] New Version Notification for draft-contreras-supa-yang-network-topo-00.txt
X-BeenThere: supa@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Sep 2014 22:16:53 -0000

--_000_847df8c42e344ba389f43e6e86743921DB4PR06MB576eurprd06pro_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi JF

Sorry for jumping so late on this. These are very busy weeks for me. Please=
, see my comments in line.

De: JF Tremblay [mailto:jean-francois.tremblay@viagenie.ca]
Enviado el: jueves, 18 de septiembre de 2014 22:24
Para: LUIS MIGUEL CONTRERAS MURILLO
CC: supa@ietf.org; andrew.qu@mediatek.com
Asunto: Re: [Supa] New Version Notification for draft-contreras-supa-yang-n=
etwork-topo-00.txt

Luis,
Thanks to you and Andrew for writing this. Very interesting and quite in li=
ne with the conception of a multi-layer topology model I was myself trying =
to express.

A few questions:
You limited the scope of the topology information to layer-3 and beneath. W=
as it because you don't believe such a topology could be applicable at high=
er levels?
In my mind, such a generic topology model could apply to higher layers. For=
 example, a host-server relationship could be a very basic topology with a =
link between two nodes. It would allow later on to define policies or param=
eters on such a session/link.
[Luis>>] Agree, This hierarchy can be extended to higher layers than L3, wi=
th the appropriate dependencies with respect to the underlying topologies d=
escribing lower layers.

Another point: I do like the idea of hierarchizing the topologies, but I'm =
not sure I understand it the way you described it. Reading the document, it=
 seemed at first that a parent topology would be a lower-abstraction (lower=
-level) topology object. Topologies of different levels would be linked thr=
ough a parent-children relationship. But then the text mentions "The parent=
 topology has a container node that maps a sub topology.", it sounds like y=
ou're defining a topology embedded in a topology of the same layer. Do I ge=
t this right? Both concepts are interesting, maybe a way could be found to =
differentiate them in the text. The second one sounds more like a container=
-contained relationship rather than parent-children.
[Luis>>] In my opinion it can be used for both approaches. From my point of=
 view a clear parent-child relationship could be the one e.g. observed betw=
een an IP topology and a transmission (let say a photonic mesh) topology. O=
n the other hand, it can be used as well for a "Russian doll" approach. An =
example of that could be for instance the case in which an operator offers =
transport capabilities to other service provider in one are, like in some m=
obile backhaul scenarios. The infrastructure operator will clearly observed=
 the physical topology while offering a condensed (or contained) topology t=
o the service provider which is renting that capacity. Let me know if it ma=
kes sense to you.

Also, could a topology be a parent to more than one higher-level topology? =
I guess it does, but I haven't seen it clearly mentioned in the text. An ex=
ample would be a single physical topology with several different logical to=
pologies on top of it.
[Luis>>] I think so. The example mentioned above for the rented capacity in=
 the mobile backhaul could be a case, assuming more than one operator rents=
 capacity to the same infrastructure provider. Other cases could be for ins=
tance the deployment of different VPNs on the same transport infrastructure=
..

Btw, you might want to take a look at http://tools.ietf.org/html/draft-edpr=
op-opsawg-multi-layer-oam-ps-00. It describes a multi-layer OAM model. Not =
exactly the same concepts, but it describes interesting ideas too.
[Luis>>] Thanks for the pointer. I didn't have an opportunity yetto read th=
is work, but I commit to do and come back to this thread if any comment rai=
se to me.

JF Tremblay
Viagenie

[Luis>>] Thank you, and sorry for the delay in answering. Best regards. Lui=
s.


On Sep 18, 2014, at 3:54 AM, LUIS MIGUEL CONTRERAS MURILLO > wrote:


Dear colleagues,

Please note a new draft document addressing YANG modelling of network topol=
ogy has been just uploaded. Any comment is more than welcome.

Thanks

Best regards

Luis

-----Mensaje original-----
De: internet-drafts@ietf.org [mailto:inter=
net-drafts@ietf.org]
Enviado el: jueves, 18 de septiembre de 2014 9:48
Para: LUIS MIGUEL CONTRERAS MURILLO; Andrew Qu; LUIS MIGUEL CONTRERAS MURIL=
LO; Andrew Qu
Asunto: New Version Notification for draft-contreras-supa-yang-network-topo=
-00.txt


A new version of I-D, draft-contreras-supa-yang-network-topo-00.txt
has been successfully submitted by Luis M. Contreras and posted to the IETF=
 repository.

Name:           draft-contreras-supa-yang-network-topo
Revision:       00
Title:          A YANG Data Model for Network Topologies
Document date:  2014-09-18
Group:          Individual Submission
Pages:          23
URL:            http://www.ietf.org/internet-drafts/draft-contreras-supa-ya=
ng-network-topo-00.txt
Status:         https://datatracker.ietf.org/doc/draft-contreras-supa-yang-=
network-topo/
Htmlized:       http://tools.ietf.org/html/draft-contreras-supa-yang-networ=
k-topo-00


Abstract:
  This document defines a YANG data model for network topologies.




Please note that it may take a couple of minutes from the time of submissio=
n until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


________________________________

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
_______________________________________________
Supa mailing list
Supa@ietf.org
https://www.ietf.org/mailman/listinfo/supa


________________________________

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_847df8c42e344ba389f43e6e86743921DB4PR06MB576eurprd06pro_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hi JF

 <=
/p>

Sorry for jumping so late=
 on this. These are very busy weeks for me. Please, see my comments in line=
.


 <=
/p>





De: JF Tremblay [mailto:jean-francois.tremblay@viagenie.ca]


Enviado el: jueves, 18 de septiembre de 2014 22:24

Para: LUIS MIGUEL CONTRERAS MURILLO

CC: supa@ietf.org; andrew.qu@mediatek.com

Asunto: Re: [Supa] New Version Notification for draft-contreras-supa=
-yang-network-topo-00.txt






 




Luis, 






Thanks to you and Andrew for writing this. Very inte=
resting and quite in line with the conception of a multi-layer topology mod=
el I was myself trying to express.






 






A few questions: 






You limited the scope of the topology information to=
 layer-3 and beneath. Was it because you don’t believe such a topolog=
y could be applicable at higher levels? 






In my mind, such a generic topology model could appl=
y to higher layers. For example, a host-server relationship could be a very=
 basic topology with a link between two nodes. It would allow later on to d=
efine policies or parameters on such
 a session/link.  


[Luis>>] Agre=
e, This hierarchy can be extended to higher layers than L3, with the approp=
riate dependencies with respect to the underlying topologies describing
 lower layers.<=
/p>





  






Another point: I do like the idea of hierarchizing t=
he topologies, but I’m not sure I understand it the way you described=
 it. Reading the document, it seemed at first that a parent topology would =
be a lower-abstraction (lower-level) topology
 object. Topologies of different levels would be linked through a parent-ch=
ildren relationship. But then the text mentions “The parent topology =
has a container node that maps a sub topology.”, it sounds like you&#=
8217;re defining a topology embedded in a topology
 of the same layer. Do I get this right? Both concepts are interesting, may=
be a way could be found to differentiate them in the text. The second one s=
ounds more like a container-contained relationship rather than parent-child=
ren. 


[Luis>>] In m=
y opinion it can be used for both approaches. From my point of view a clear=
 parent-child relationship could be the one e.g. observed between
 an IP topology and a transmission (let say a photonic mesh) topology. On t=
he other hand, it can be used as well for a “Russian doll” appr=
oach. An example of that could be for instance the case in which an operato=
r offers transport capabilities to other service
 provider in one are, like in some mobile backhaul scenarios. The infrastru=
cture operator will clearly observed the physical topology while offering a=
 condensed (or contained) topology to the service provider which is renting=
 that capacity. Let me know if it
 makes sense to you.






 






Also, could a topology be a parent to more than one =
higher-level topology? I guess it does, but I haven’t seen it clearly=
 mentioned in the text. An example would be a single physical topology with=
 several different logical topologies on
 top of it. 


[Luis>>] I th=
ink so. The example mentioned above for the rented capacity in the mobile b=
ackhaul could be a case, assuming more than one operator rents
 capacity to the same infrastructure provider. Other cases could be for ins=
tance the deployment of different VPNs on the same transport infrastructure=
..






 






Btw, you might want to take a look at h=
ttp://tools.ietf.org/html/draft-edprop-opsawg-multi-layer-oam-ps-00. It=
 describes a multi-layer OAM model. Not exactly
 the same concepts, but it describes interesting ideas too. 


[Luis>>] Than=
ks for the pointer. I didn’t have an opportunity yetto read this work=
, but I commit to do and come back to this thread if any comment raise
 to me.




 








JF Tremblay 






Viagenie






 


[Luis>>] Than=
k you, and sorry for the delay in answering. Best regards. Luis.=







 




 






On Sep 18, 2014, at 3:54 AM, LUIS MIGUEL CONTRERAS M=
URILLO <lu=
ismiguel.contrerasmurillo@telefonica.com> wrote:











Dear colleagues,



Please note a new draft document addressing YANG modelling of network topol=
ogy has been just uploaded. Any comment is more than welcome.



Thanks



Best regards



Luis



-----Mensaje original-----

De: internet-drafts@ietf.org [mailto:internet-drafts@ietf.=
org]

Enviado el: jueves, 18 de septiembre de 2014 9:48

Para: LUIS MIGUEL CONTRERAS MURILLO; Andrew Qu; LUIS MIGUEL CONTRERAS MURIL=
LO; Andrew Qu

Asunto: New Version Notification for draft-contreras-supa-yang-network-topo=
-00.txt





A new version of I-D, draft-contreras-supa-yang-network-topo-00.txt

has been successfully submitted by Luis M. Contreras and posted to the IETF=
 repository.



Name:           draft-con=
treras-supa-yang-network-topo

Revision:       00

Title:          A YANG Data Mo=
del for Network Topologies

Document date:  2014-09-18

Group:          Individual Sub=
mission

Pages:          23

URL:            http://www.ietf.org/internet-drafts/draft-contreras-supa-yan=
g-network-topo-00.txt

Status:         https://d=
atatracker.ietf.org/doc/draft-contreras-supa-yang-network-topo/

Htmlized:       http://tools.ietf.org/h=
tml/draft-contreras-supa-yang-network-topo-00





Abstract:

  This document defines a YANG data model for network topologies.=










Please note that it may take a couple of minutes from the time of submissio=
n until the htmlized version and diff are available at
tools.ietf.org.



The IETF Secretariat





________________________________



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 mensagem por erro, rogamos-lhe que nos o =
comunique imediatamente por esta mesma via e proceda a sua destrui=E7=E3o
_______________________________________________

Supa mailing list

Supa@ietf.org

https://www.ietf.org/mailman/listinfo/supa




 









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_847df8c42e344ba389f43e6e86743921DB4PR06MB576eurprd06pro_--


From nobody Tue Sep 30 15:17:50 2014
Return-Path: 
X-Original-To: supa@ietfa.amsl.com
Delivered-To: supa@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC5721ACCF8 for ; Tue, 30 Sep 2014 15:17:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.086
X-Spam-Level: 
X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.786, 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 EAw_MZlgWMg0 for ; Tue, 30 Sep 2014 15:17:44 -0700 (PDT)
Received: from smtptc.telefonica.com (smtptc.telefonica.com [195.76.34.108]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CB341ACCED for ; Tue, 30 Sep 2014 15:17:42 -0700 (PDT)
Received: from smtptc.telefonica.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 899918813E; Wed,  1 Oct 2014 00:17:40 +0200 (CEST)
Received: from ESTGVMSP107.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 6AC608813D; Wed,  1 Oct 2014 00:17:40 +0200 (CEST)
Received: from emea01-am1-obe.outbound.protection.outlook.com (10.92.5.139) by tls.telefonica.com (10.92.6.52) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 1 Oct 2014 00:17:40 +0200
Received: from DB4PR06MB576.eurprd06.prod.outlook.com (10.242.192.23) by DB4PR06MB576.eurprd06.prod.outlook.com (10.242.192.23) with Microsoft SMTP Server (TLS) id 15.0.1039.15; Tue, 30 Sep 2014 22:17:38 +0000
Received: from DB4PR06MB576.eurprd06.prod.outlook.com ([10.242.192.23]) by DB4PR06MB576.eurprd06.prod.outlook.com ([10.242.192.23]) with mapi id 15.00.1039.011; Tue, 30 Sep 2014 22:17:38 +0000
From: LUIS MIGUEL CONTRERAS MURILLO 
To: "Liushucheng (Will)" , JF Tremblay 
Thread-Topic: [Supa] New Version Notification for draft-contreras-supa-yang-network-topo-00.txt
Thread-Index: AQHP0xTtYNoV/hmyG0eLnhFczRTp4pwGg71AgADS8YCAAomDgIAQchpw
Date: Tue, 30 Sep 2014 22:17:38 +0000
Message-ID: <06e97d10dbf74d0e8f69a9771ae01cf7@DB4PR06MB576.eurprd06.prod.outlook.com>
References: <20140918074811.15859.74757.idtracker@ietfa.amsl.com> <716e56912f124e2d8c13148c5b83f1f5@DB4PR06MB576.eurprd06.prod.outlook.com>  
In-Reply-To: 
Accept-Language: es-ES, en-US
Content-Language: es-ES
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [79.144.77.90]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DB4PR06MB576;
x-forefront-prvs: 0350D7A55D
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(189002)(24454002)(377424004)(59124003)(199003)(377454003)(19580405001)(10300001)(106356001)(105586002)(87936001)(95666004)(50986999)(92566001)(21056001)(19609705001)(33646002)(120916001)(19580395003)(230783001)(108616004)(76176999)(4396001)(15975445006)(64706001)(54356999)(19617315012)(93886004)(85852003)(85306004)(106116001)(19625215002)(101416001)(80022003)(46102003)(66066001)(74316001)(76482002)(107046002)(2656002)(97736003)(31966008)(14971765001)(99396003)(15202345003)(19300405004)(16236675004)(16601075003)(20776003)(76576001)(86362001)(24736002)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR06MB576; H:DB4PR06MB576.eurprd06.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
Content-Type: multipart/alternative; boundary="_000_06e97d10dbf74d0e8f69a9771ae01cf7DB4PR06MB576eurprd06pro_"
MIME-Version: 1.0
X-OriginatorOrg: telefonica.com
X-TM-AS-MML: No
Archived-At: http://mailarchive.ietf.org/arch/msg/supa/0IRKNjQy7mCqp_4oTxeMzIc4_Fs
Cc: "andrew.qu@mediatek.com" , "supa@ietf.org" 
Subject: Re: [Supa] New Version Notification for draft-contreras-supa-yang-network-topo-00.txt
X-BeenThere: supa@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Sep 2014 22:17:48 -0000

--_000_06e97d10dbf74d0e8f69a9771ae01cf7DB4PR06MB576eurprd06pro_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Will,

Thanks for your comment. I basically agree. Noted for the next version of t=
he draft.

Regards,

Luis

De: Liushucheng (Will) [mailto:liushucheng@huawei.com]
Enviado el: s=E1bado, 20 de septiembre de 2014 13:08
Para: JF Tremblay; LUIS MIGUEL CONTRERAS MURILLO
CC: andrew.qu@mediatek.com; supa@ietf.org
Asunto: RE: [Supa] New Version Notification for draft-contreras-supa-yang-n=
etwork-topo-00.txt

Hi JF,

I read this draft and have some comments to yours. Please see below in-line=
.

Regards,
Will

From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of JF Tremblay
Sent: Friday, September 19, 2014 4:24 AM
To: LUIS MIGUEL CONTRERAS MURILLO
Cc: andrew.qu@mediatek.com; supa@ietf.org
Subject: Re: [Supa] New Version Notification for draft-contreras-supa-yang-=
network-topo-00.txt

Luis,
Thanks to you and Andrew for writing this. Very interesting and quite in li=
ne with the conception of a multi-layer topology model I was myself trying =
to express.

A few questions:
You limited the scope of the topology information to layer-3 and beneath. W=
as it because you don't believe such a topology could be applicable at high=
er levels?
In my mind, such a generic topology model could apply to higher layers. For=
 example, a host-server relationship could be a very basic topology with a =
link between two nodes. It would allow later on to define policies or param=
eters on such a session/link.

[Will] I agree with JF that we should not limit the scope of topology. Actu=
ally, I think in the draft they did not limit the scope as I see words like=
, "physical, data link and IP and can be extended to   layer 4,5 and 7", "T=
he model is also capable of depicting the  topology at different layers", "=
A network at any layer can contain multiple topologies. Each  topology is c=
aptured in its own list elements, distinguished via a  topology ID." Howeve=
r, I guess you have such an impression because in section 4, when they give=
 the detailed examples, they only write about l0-l3.

IMHO, the advanced network functions (besides the basic routing and forward=
ing functions) for added value services are mostly Layer4 to Layer7 based. =
The Layer 4-7 network service function may include (not limited) firewalls,=
 WAN and application acceleration, Deep Packet Inspection (DPI), server loa=
d balancers, NAT,TCP optimizer, etc. Some of them are designed and deployed=
 to enhance user experience, such as TCP or video optimization, content cat=
ching and compression, while others apply actions to data packets, such as =
Firewall, Policing (e.g. PCEF/PCRF), Mirroring, statistics collection based=
 on Layer 4-7 headers, etc. If an application need to control multiple serv=
ice functions in network, it may need a topology for Layer 4-7 service func=
tion nodes and connections (For example, a traffic steering application may=
 need to know the L4-L7 topology first. So it can tell network (including n=
etwork service function nodes) how to steer a traffic).

So, I propose to add following words in the end of page 4, below the senten=
ce "ip means layer 3 topology ...":
"TCP/UDP or other Layer 4-7 information" means layer 4-7 topology that swit=
ch packets by Layer 4-7 information in packet or packet header."

I also  propose to add description like below(please note that they are jus=
t examples and may need to be modified) into "module SUPA-topology":
enum ip {
               value 4;
               description "L4";
             }
             enum ip {
               value 5;
               description "L5";
             }
             enum ip {
               value 6;
               description "L6";
             }
             enum ip {
               value 7;
               description "L7";
             }


Another point: I do like the idea of hierarchizing the topologies, but I'm =
not sure I understand it the way you described it. Reading the document, it=
 seemed at first that a parent topology would be a lower-abstraction (lower=
-level) topology object. Topologies of different levels would be linked thr=
ough a parent-children relationship. But then the text mentions "The parent=
 topology has a container node that maps a sub topology.", it sounds like y=
ou're defining a topology embedded in a topology of the same layer. Do I ge=
t this right? Both concepts are interesting, maybe a way could be found to =
differentiate them in the text. The second one sounds more like a container=
-contained relationship rather than parent-children.

Also, could a topology be a parent to more than one higher-level topology? =
I guess it does, but I haven't seen it clearly mentioned in the text. An ex=
ample would be a single physical topology with several different logical to=
pologies on top of it.

Btw, you might want to take a look at http://tools.ietf.org/html/draft-edpr=
op-opsawg-multi-layer-oam-ps-00. It describes a multi-layer OAM model. Not =
exactly the same concepts, but it describes interesting ideas too.

JF Tremblay
Viagenie



On Sep 18, 2014, at 3:54 AM, LUIS MIGUEL CONTRERAS MURILLO > wrote:

Dear colleagues,

Please note a new draft document addressing YANG modelling of network topol=
ogy has been just uploaded. Any comment is more than welcome.

Thanks

Best regards

Luis

-----Mensaje original-----
De: internet-drafts@ietf.org [mailto:inter=
net-drafts@ietf.org]
Enviado el: jueves, 18 de septiembre de 2014 9:48
Para: LUIS MIGUEL CONTRERAS MURILLO; Andrew Qu; LUIS MIGUEL CONTRERAS MURIL=
LO; Andrew Qu
Asunto: New Version Notification for draft-contreras-supa-yang-network-topo=
-00.txt


A new version of I-D, draft-contreras-supa-yang-network-topo-00.txt
has been successfully submitted by Luis M. Contreras and posted to the IETF=
 repository.

Name:           draft-contreras-supa-yang-network-topo
Revision:       00
Title:          A YANG Data Model for Network Topologies
Document date:  2014-09-18
Group:          Individual Submission
Pages:          23
URL:            http://www.ietf.org/internet-drafts/draft-contreras-supa-ya=
ng-network-topo-00.txt
Status:         https://datatracker.ietf.org/doc/draft-contreras-supa-yang-=
network-topo/
Htmlized:       http://tools.ietf.org/html/draft-contreras-supa-yang-networ=
k-topo-00


Abstract:
  This document defines a YANG data model for network topologies.




Please note that it may take a couple of minutes from the time of submissio=
n until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


________________________________

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
_______________________________________________
Supa mailing list
Supa@ietf.org
https://www.ietf.org/mailman/listinfo/supa


________________________________

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_06e97d10dbf74d0e8f69a9771ae01cf7DB4PR06MB576eurprd06pro_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hi Will,


 <=
/p>

Thanks for your comment. =
I basically agree. Noted for the next version of the draft.


 <=
/p>

Regards,


 <=
/p>

Luis

 <=
/p>





De: Liushucheng (Will) [mailto:liushucheng@huawei.com]


Enviado el: s=E1bado, 20 de septiembre de 2014 13:08

Para: JF Tremblay; LUIS MIGUEL CONTRERAS MURILLO

CC: andrew.qu@mediatek.com; supa@ietf.org

Asunto: RE: [Supa] New Version Notification for draft-contreras-supa=
-yang-network-topo-00.txt






 








From:
 Supa [mailto:supa-bounces@ietf.or=
g] 
On Behalf Of JF Tremblay

Sent: Friday, September 19, 2014 4:24 AM

To: LUIS MIGUEL CONTRERAS MURILLO

Cc: andrew.qu@mediatek.com=
; 
supa@ietf.org

Subject: Re: [Supa] New Version Notification for draft-contreras-sup=
a-yang-network-topo-00.txt






 




Luis, 






Thanks to you and Andrew for=
 writing this. Very interesting and quite in line with the conception of a =
multi-layer topology model I was myself
 trying to express.






 






A few questions: <=
/o:p>






You limited the scope of the=
 topology information to layer-3 and beneath. Was it because you don’=
t believe such a topology could be applicable
 at higher levels? 






In my mind, such a generic t=
opology model could apply to higher layers. For example, a host-server rela=
tionship could be a very basic topology
 with a link between two nodes. It would allow later on to define policies =
or parameters on such a session/link.  


 


[Will] I agree with JF that we should not limit the scope of topology.=
 Actually, I think in the draft they did not limit the scope
 as I see words like, “physical, data link and IP and can be extended=
 to   layer 4,5 and 7”, “The model is also capable of=
 depicting the  topology at different layers”, “A network =
at any layer can contain multiple topologies. Each  topology is captur=
ed in its
 own list elements, distinguished via a  topology ID.” However, =
I guess you have such an impression because in section 4, when they give th=
e detailed examples, they only write about l0-l3.



 


IMHO, the advanced network functions (besides the basic routing and fo=
rwarding functions) for added value services are mostly
 Layer4 to Layer7 based. The Layer 4-7 network service function may include=
 (not limited) firewalls, WAN and application acceleration, Deep Packet Ins=
pection (DPI), server load balancers, NAT,TCP optimizer, etc. Some of them =
are designed and deployed to enhance
 user experience, such as TCP or video optimization, content catching and c=
ompression, while others apply actions to data packets, such as Firewall, P=
olicing (e.g. PCEF/PCRF), Mirroring, statistics collection based on Layer 4=
-7 headers, etc. If an application
 need to control multiple service functions in network, it may need a topol=
ogy for Layer 4-7 service function nodes and connections (For example, a tr=
affic steering application may need to know the L4-L7 topology first. So it=
 can tell network (including network
 service function nodes) how to steer a traffic).


 


So, I propose to add following words in the end of page 4, below the s=
entence
“ip means layer 3 topology=
 …”:
=



"TCP/UDP or other Layer 4-7 information" means layer 4-7 top=
ology that switch packets by Layer 4-7 information in packet or packet
 header.”


 


I also  propose to add description like below(please note that th=
ey are just examples and may need to be modified) into “module
 SUPA-topology”:


enum ip {


       =
        value 4;

       =
        description "L4";=



       =
      }


       =
      enum ip {


       =
        value 5;

       =
        description "L5";=



       =
      }


       =
      enum ip {


       =
        value 6;

       =
        description "L6";=



       =
      }


       =
      enum ip {


       =
        value 7;

       =
        description "L7";=



           &nbs=
p; }


  






Another point: I do like the=
 idea of hierarchizing the topologies, but I’m not sure I understand =
it the way you described it. Reading the document,
 it seemed at first that a parent topology would be a lower-abstraction (lo=
wer-level) topology object. Topologies of different levels would be linked =
through a parent-children relationship. But then the text mentions “T=
he parent topology has a container node
 that maps a sub topology.”, it sounds like you’re defining a t=
opology embedded in a topology of the same layer. Do I get this right? Both=
 concepts are interesting, maybe a way could be found to differentiate them=
 in the text. The second one sounds more like
 a container-contained relationship rather than parent-children. =







 






Also, could a topology be a =
parent to more than one higher-level topology? I guess it does, but I haven=
’t seen it clearly mentioned in the text.
 An example would be a single physical topology with several different logi=
cal topologies on top of it. 






 






Btw, you might want to take =
a look at http://tools.ietf.org/html/draft-edprop-opsawg-multi-l=
ayer-oam-ps-00.
 It describes a multi-layer OAM model. Not exactly the same concepts, but i=
t describes interesting ideas too. 




 








JF Tremblay =
;






Viagenie






 






 




&nbs=
p;






On Sep 18=
, 2014, at 3:54 AM, LUIS MIGUEL CONTRERAS MURILLO <luismiguel.contrerasmurillo@telefo=
nica.com> wrote:




 




Dear coll=
eagues,



Please note a new draft document addressing YANG modelling of network topol=
ogy has been just uploaded. Any comment is more than welcome.



Thanks



Best regards



Luis



-----Mensaje original-----

De: internet-drafts@ietf.org [mailto:internet-drafts@ietf.=
org]

Enviado el: jueves, 18 de septiembre de 2014 9:48

Para: LUIS MIGUEL CONTRERAS MURILLO; Andrew Qu; LUIS MIGUEL CONTRERAS MURIL=
LO; Andrew Qu

Asunto: New Version Notification for draft-contreras-supa-yang-network-topo=
-00.txt





A new version of I-D, draft-contreras-supa-yang-network-topo-00.txt

has been successfully submitted by Luis M. Contreras and posted to the IETF=
 repository.



Name:           draft-con=
treras-supa-yang-network-topo

Revision:       00

Title:          A YANG Data Mo=
del for Network Topologies

Document date:  2014-09-18

Group:          Individual Sub=
mission

Pages:          23

URL:            http://www.ietf.org/internet-drafts/draft-contreras-supa-yan=
g-network-topo-00.txt

Status:         https://d=
atatracker.ietf.org/doc/draft-contreras-supa-yang-network-topo/

Htmlized:       http://tools.ietf.org/h=
tml/draft-contreras-supa-yang-network-topo-00





Abstract:

  This document defines a YANG data model for network topologies.=










Please note that it may take a couple of minutes from the time of submissio=
n until the htmlized version and diff are available at
tools.ietf.org.



The IETF Secretariat





________________________________



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

_______________________________________________

Supa mailing list

Supa@ietf.org

https://www.ietf.org=
/mailman/listinfo/supa






&nbs=
p;











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_06e97d10dbf74d0e8f69a9771ae01cf7DB4PR06MB576eurprd06pro_--



From nobody Tue Sep 30 15:21:19 2014
Return-Path: 
X-Original-To: supa@ietfa.amsl.com
Delivered-To: supa@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 349F01A1BE8 for ; Tue, 30 Sep 2014 15:21:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.686
X-Spam-Level: 
X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.786, 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 zISg8P79VCis for ; Tue, 30 Sep 2014 15:21:11 -0700 (PDT)
Received: from smtpjc.telefonica.com (smtpjc.telefonica.com [81.47.204.76]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B08E11A9245 for ; Tue, 30 Sep 2014 15:21:10 -0700 (PDT)
Received: from smtpjc.telefonica.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id D64032D020C; Wed,  1 Oct 2014 00:21:07 +0200 (CEST)
Received: from ESTGVMSP105.EUROPE.telefonica.corp (unknown [10.92.4.9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtpjc.telefonica.com (Postfix) with ESMTPS id B75222D0123; Wed,  1 Oct 2014 00:21:07 +0200 (CEST)
Received: from emea01-am1-obe.outbound.protection.outlook.com (10.92.5.139) by tls.telefonica.com (10.92.6.51) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 1 Oct 2014 00:21:06 +0200
Received: from DB4PR06MB576.eurprd06.prod.outlook.com (10.242.192.23) by DB4PR06MB576.eurprd06.prod.outlook.com (10.242.192.23) with Microsoft SMTP Server (TLS) id 15.0.1039.15; Tue, 30 Sep 2014 22:21:06 +0000
Received: from DB4PR06MB576.eurprd06.prod.outlook.com ([10.242.192.23]) by DB4PR06MB576.eurprd06.prod.outlook.com ([10.242.192.23]) with mapi id 15.00.1039.011; Tue, 30 Sep 2014 22:21:06 +0000
From: LUIS MIGUEL CONTRERAS MURILLO 
To: Kostas Pentikousis , "Liushucheng (Will)" , "supa@ietf.org" 
Thread-Topic: [Supa] bof request text
Thread-Index: Ac/YAy09696cAFlgTtaF9cU29rHdGAAAPVqAAT4rTTA=
Date: Tue, 30 Sep 2014 22:21:06 +0000
Message-ID: 
References:  <0C7EDCF89AB9E2478B5D010026CFF4AEA10C72ABF0@SBS2008.eict.local>
In-Reply-To: <0C7EDCF89AB9E2478B5D010026CFF4AEA10C72ABF0@SBS2008.eict.local>
Accept-Language: es-ES, en-US
Content-Language: es-ES
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [79.144.77.90]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DB4PR06MB576;
x-forefront-prvs: 0350D7A55D
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(189002)(50944004)(53754006)(199003)(497574002)(19580405001)(10300001)(106356001)(105586002)(87936001)(95666004)(50986999)(92566001)(561944003)(21056001)(33646002)(120916001)(19580395003)(108616004)(76176999)(4396001)(15975445006)(64706001)(54356999)(19617315012)(107886001)(2501002)(85852003)(85306004)(19625215002)(101416001)(80022003)(46102003)(66066001)(74316001)(76482002)(107046002)(2656002)(97736003)(31966008)(99396003)(15202345003)(19300405004)(16236675004)(20776003)(76576001)(86362001)(24736002)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR06MB576; H:DB4PR06MB576.eurprd06.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
Content-Type: multipart/alternative; boundary="_000_a2ba892522654b5f8be41113ffee2bccDB4PR06MB576eurprd06pro_"
MIME-Version: 1.0
X-OriginatorOrg: telefonica.com
X-TM-AS-MML: No
Archived-At: http://mailarchive.ietf.org/arch/msg/supa/zja3pNDgGkG_X2ijz5LMuL1t5tc
Subject: Re: [Supa] bof request text
X-BeenThere: supa@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Sep 2014 22:21:15 -0000

--_000_a2ba892522654b5f8be41113ffee2bccDB4PR06MB576eurprd06pro_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

KzENCg0KRGU6IFN1cGEgW21haWx0bzpzdXBhLWJvdW5jZXNAaWV0Zi5vcmddIEVuIG5vbWJyZSBk
ZSBLb3N0YXMgUGVudGlrb3VzaXMNCkVudmlhZG8gZWw6IG1pw6lyY29sZXMsIDI0IGRlIHNlcHRp
ZW1icmUgZGUgMjAxNCAxNjozMQ0KUGFyYTogTGl1c2h1Y2hlbmcgKFdpbGwpOyBzdXBhQGlldGYu
b3JnDQpBc3VudG86IFJlOiBbU3VwYV0gYm9mIHJlcXVlc3QgdGV4dA0KDQpIaSBXaWxsLCBhbGws
DQoNCkdpdmVuIHRoYXQgdGhlIG1lZXRpbmcgaXMgaW4gSGF3YWlpLCByZW1vdGUgcGFydGljaXBh
dGlvbiB3b3VsZCBiZSBoaWdobHkgZGVzaXJhYmxlIGltby4gU28gSSB3b3VsZCBzYXkg4oCceWVz
4oCdIGZvciB3ZWJleC9tZWV0ZWNoby4NCg0KQmVzdCByZWdhcmRzLA0KDQpLb3N0YXMNCg0KVm9u
OiBMaXVzaHVjaGVuZyAoV2lsbCkgW21haWx0bzpsaXVzaHVjaGVuZ0BodWF3ZWkuY29tXQ0KR2Vz
ZW5kZXQ6IE1pdHR3b2NoLCAyNC4gU2VwdGVtYmVyIDIwMTQgMTY6MjUNCkFuOiBzdXBhQGlldGYu
b3JnPG1haWx0bzpzdXBhQGlldGYub3JnPg0KQmV0cmVmZjogW1N1cGFdIGJvZiByZXF1ZXN0IHRl
eHQNCg0KSGkgYWxsLA0KDQpJ4oCZbSBzZW5kaW5nIHlvdSB0aGUgdXBkYXRlZCB2ZXJzaW9uIG9m
IGJvZiByZXF1ZXN0LiBQbGVhc2UgcmV2aWV3IGl0IGFuZCBsZXQgbWUga25vdyB5b3VyIHRob3Vn
aHQuDQoNCg0KVGhlIG1haW4gY2hhbmdlcyBhcmU6DQoNCkkgY3V0IHRoZSByZXF1ZXN0IHNob3J0
IGJ5IHJlbW92aW5nIHRoZSAnJ1dvcmsgaXRlbXMgcmVsYXRlZCB0byBTVVBBIGluY2x1ZGU6Jycg
YW5kICcnTWlsZXN0b25lczonJywgd2hpY2ggYXJlIHVzdWFsbHkgbm90IHB1dCBpbiB0aGUgcmVx
dWVzdC4gKFF1ZXN0aW9uOiBzaG91bGQgSSByZW1vdmUgdGhlbT8pDQoNCkkgdXBkYXRlZCB0aGUg
bGlua3MgYW5kIHRoZSByZXNwb25zaWJsZSBBRCwgYW5kIG1ha2UgdGhlIGZvcm1hdCBuZWF0Lg0K
DQoNCg0KU1VQQQ0KDQogICogICBMb25nIG5hbWUgYW5kIGFiYnJldmlhdGlvbjogU1VQQSAoU2hh
cmVkIFVuaWZpZWQgUG9saWN5IEF1dG9tYXRpb24pDQogICogICBEZXNjcmlwdGlvbjogTmV0d29y
ayBvcGVyYXRvcnMgYXJlIGZhY2VkIHdpdGggbmV0d29ya3Mgb2YgaW5jcmVhc2luZyBzaXplIGFu
ZCBjb21wbGV4aXR5IHdoaWxlIHRyeWluZyB0byBpbXByb3ZlIHRoZWlyIHF1YWxpdHkgYW5kIGF2
YWlsYWJpbGl0eSwgYXMgbW9yZSBhbmQgbW9yZSBzZXJ2aWNlcyBkZXBlbmQgb24gdGhlbS4gQXV0
b21hdGluZyB0aGUgd2F5IG9mIGV4cG9zaW5nIGEgdmlldyBvZiB0aGUgbmV0d29yayB0byBhcHBs
aWNhdGlvbnMgbWF5IHByb3ZpZGUgc2lnbmlmaWNhbnQgaW1wcm92ZW1lbnRzIGluIGNvbmZpZ3Vy
YXRpb24gYWdpbGl0eSwgZXJyb3IgZGV0ZWN0aW9uIGFuZCB1cHRpbWUgZm9yIG9wZXJhdG9ycy4g
SG93ZXZlciB0aGUgcmVhbCB2YWx1ZSBiZWhpbmQgY2VudHJhbCBjb25maWd1cmF0aW9uIHNjaGVt
ZXMgbGllcyB3aXRoaW4gdGhlIHBvc3NpYmxlIHNpbXBsaWZpY2F0aW9uIHRocm91Z2ggbW9kZWxz
IHByb3ZpZGVkIGJ5IHN1Y2ggc3lzdGVtcyB0byBhcHBsaWNhdGlvbnMgYW5kIG5ldHdvcmsgc2Vy
dmljZXMgcnVubmluZyBhYm92ZSB0aGVtIChvbiB0aGUgc28tY2FsbGVkIG5vcnRoYm91bmQgc2lk
ZSkuIFdlbGwtZGVzaWduZWQgbW9kZWxzIGFyZSBhYmxlIHRvIHByb3ZpZGUgYSB3aWRlIHJhbmdl
IG9mIGdyYW51bGFyaXR5IGZvciB2YXJpb3VzIGFwcGxpY2F0aW9ucyBhbmQgbmV0d29yayBzZXJ2
aWNlcyBuZWVkcywgZnJvbSB0aGUgbG93ZXItbGV2ZWwgcGh5c2ljYWwgbmV0d29yayB0byBoaWdo
LWxldmVsIGFwcGxpY2F0aW9uIHNlcnZpY2VzLg0KDQpQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgaXMg
YSBuZXcgdmVyc2lvbiBvZiBhcG9uZiBib2YgcHJvcG9zYWwgYmFzZWQgb24gY29tbWVudHMgcmVj
ZWl2ZWQuDQoNClRoZSBtYWluIGdvYWwgb2YgU1VQQSBpcyB0byBwcm92aWRlIGEgd2F5IGZvciBh
cHBsaWNhdGlvbnMgYW5kIGZvciBuZXR3b3JrIHNlcnZpY2VzIHRvIHNwZWNpZnkgU0hBUkVEIGFw
cGxpY2F0aW9uIGJhc2VkIFBPTElDSUVTIHRvIHRoZSBuZXR3b3JrIGluZnJhc3RydWN0dXJlIHVz
aW5nIGEgc2ltcGxpZmllZCB2aWV3IG9mIHRoZSBuZXR3b3JrLiBUaGlzIGNhbiBiZSByZWFsaXpl
ZCBieTogKDEpIG1vZGVsaW5nIHRoZSBuZXR3b3JrIGluZnJhc3RydWN0dXJlIGFzIGFuIHNpbXBs
aWZpZWQgbmV0d29yayBncmFwaCB1c2luZyBhIG1vZGVsaW5nIGxhbmd1YWdlIHN1Y2ggYXMgWUFO
RywgKDIpIHRyYW5zcG9ydGluZyBtb2RlbCBpbnN0YW5jZXMgZWl0aGVyIHVzaW5nIE5FVENPTkYg
b3IgUkVTVENPTkYgYW5kICgzKSBwcm92aWRpbmcgZ3VpZGVsaW5lcyBvbiBBVVRPTUFUSUNBTExZ
IG1hcHBpbmcgcG9saWNpZXMgdG8gYXR0cmlidXRlcyBvZiB0aGUgbmV0d29yayBncmFwaHMuDQoN
CiAgKiAgIEFnZW5kYTogVEJEDQogICogICBTdGF0dXM6IFdHIEZvcm1pbmcNCiAgKiAgIFJlc3Bv
bnNpYmxlIEFEOiBCZW5vaXQgQ2xhaXNlDQogICogICBCb0YgcHJvcG9uZW50czogVEJEDQogICog
ICBCb0YgQ2hhaXJzOiBUQkQNCiAgKiAgIE51bWJlciBvZiBwZW9wbGUgZXhwZWN0ZWQgdG8gYXR0
ZW5kOiAxMDANCiAgKiAgIExlbmd0aCBvZiBzZXNzaW9uICgxLCAxLjUsIDIsIG9yIDIuNSBob3Vy
cyk6IDEuNSBob3Vycw0KICAqICAgQ29uZmxpY3RzIHRvIGF2b2lkICh3aG9sZSBBcmVhcyBhbmQv
b3IgV0dzKToNCiAgKiAgIERvZXMgaXQgcmVxdWlyZSBXZWJFWD8gSWYgc28sIHdoeT86IG5vDQog
ICogICBEb2VzIGl0IHJlcXVpcmUgTWVldGVjaG8/IElmIHNvLCB3aHk/OiBubw0KICAqICAgTGlu
a3MgdG8gdGhlIG1haWxpbmcgbGlzdCwgZHJhZnQgY2hhcnRlciBpZiBhbnksIHJlbGV2YW50IElu
dGVybmV0LURyYWZ0cywgZXRjLg0KDQogICAgICogICBCb0YgSW5mbyBQYWdlOiDigItodHRwOi8v
bGl1c2h1Y2hlbmcuZ2l0aHViLmlvL1NVUEEvPGh0dHA6Ly9saXVzaHVjaGVuZy5naXRodWIuaW8v
U1VQQS8+DQogICAgICogICBNYWlsaW5nIGxpc3QgYW5kIGluZm8gcGFnZTog4oCLc3VwYUBpZXRm
Lm9yZzxtYWlsdG86c3VwYUBpZXRmLm9yZz47IOKAi2h0dHBzOi8vd3d3LmlldGYub3JnL21haWxt
YW4vbGlzdGluZm8vc3VwYTxodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N1
cGE+Ow0KICAgICAqICAgRHJhZnQgY2hhcnRlcjog4oCLaHR0cHM6Ly9naXRodWIuY29tL2xpdXNo
dWNoZW5nL1NVUEEvd2lraS9TVVBBLUNoYXJ0ZXI8aHR0cHM6Ly9naXRodWIuY29tL2xpdXNodWNo
ZW5nL1NVUEEvd2lraS9TVVBBLUNoYXJ0ZXI+IDvigItodHRwOi8vd3d3LmlldGYub3JnL21haWwt
YXJjaGl2ZS93ZWIvc3VwYS9jdXJyZW50L21zZzAwMDUxLmh0bWw8aHR0cDovL3d3dy5pZXRmLm9y
Zy9tYWlsLWFyY2hpdmUvd2ViL3N1cGEvY3VycmVudC9tc2cwMDA1MS5odG1sPg0KICAgICAqICAg
UmVsZXZhbnQgZHJhZnRzOg0KDQogICAgICAgICogICBkcmFmdC1rYXJhZ2lhbm5pcy1zdXBhLXBy
b2JsZW0tc3RhdGVtZW50PGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWthcmFnaWFu
bmlzLXN1cGEtcHJvYmxlbS1zdGF0ZW1lbnQ+DQogICAgICAgICogICBkcmFmdC1jaGVuZy1zdXBh
LWRkYy11c2UtY2FzZXM8aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2hlbmctc3Vw
YS1kZGMtdXNlLWNhc2VzPg0KICAgICAgICAqICAgZHJhZnQtcGVudGlrb3VzaXMtc3VwYS1tYXBw
aW5nPGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXBlbnRpa291c2lzLXN1cGEtbWFw
cGluZz4NCiAgICAgICAgKiAgIGRyYWZ0LWNvbnRyZXJhcy1zdXBhLXlhbmctbmV0d29yay10b3Bv
PGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNvbnRyZXJhcy1zdXBhLXlhbmctbmV0
d29yay10b3BvPg0KICAgICAgICAqICAgZHJhZnQtemFhbG91ay1zdXBhLWNvbmZpZ3VyYXRpb24t
bW9kZWw8aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtemFhbG91ay1zdXBhLWNvbmZp
Z3VyYXRpb24tbW9kZWw+DQoNCg0KUmVnYXJkcywNClNodWNoZW5nIExJVSAoV2lsbCkNCi0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpTaHVjaGVuZyBMSVUgKFdpbGwpLCBQaC5ELg0KUmVzZWFy
Y2hlciAmIFN0YW5kYXJkIFJlcHJlc2VudGF0aXZlDQpIdWF3ZWkgVGVjaG5vbG9naWVzIENvLixM
dGQNCmxpdXNodWNoZW5nQGh1YXdlaS5jb208bWFpbHRvOmxpdXNodWNoZW5nQGh1YXdlaS5jb20+
DQpodHRwOi8vd3d3LmxpbmtlZGluLmNvbS9pbi9zaHVjaGVuZw0KLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpFc3RlIG1l
bnNhamUgeSBzdXMgYWRqdW50b3Mgc2UgZGlyaWdlbiBleGNsdXNpdmFtZW50ZSBhIHN1IGRlc3Rp
bmF0YXJpbywgcHVlZGUgY29udGVuZXIgaW5mb3JtYWNpw7NuIHByaXZpbGVnaWFkYSBvIGNvbmZp
ZGVuY2lhbCB5IGVzIHBhcmEgdXNvIGV4Y2x1c2l2byBkZSBsYSBwZXJzb25hIG8gZW50aWRhZCBk
ZSBkZXN0aW5vLiBTaSBubyBlcyB1c3RlZC4gZWwgZGVzdGluYXRhcmlvIGluZGljYWRvLCBxdWVk
YSBub3RpZmljYWRvIGRlIHF1ZSBsYSBsZWN0dXJhLCB1dGlsaXphY2nDs24sIGRpdnVsZ2FjacOz
biB5L28gY29waWEgc2luIGF1dG9yaXphY2nDs24gcHVlZGUgZXN0YXIgcHJvaGliaWRhIGVuIHZp
cnR1ZCBkZSBsYSBsZWdpc2xhY2nDs24gdmlnZW50ZS4gU2kgaGEgcmVjaWJpZG8gZXN0ZSBtZW5z
YWplIHBvciBlcnJvciwgbGUgcm9nYW1vcyBxdWUgbm9zIGxvIGNvbXVuaXF1ZSBpbm1lZGlhdGFt
ZW50ZSBwb3IgZXN0YSBtaXNtYSB2w61hIHkgcHJvY2VkYSBhIHN1IGRlc3RydWNjacOzbi4NCg0K
VGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIHRyYW5zbWlzc2lvbiBpcyBwcml2aWxl
Z2VkIGFuZCBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gaW50ZW5kZWQgb25seSBmb3IgdGhlIHVz
ZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgbmFtZWQgYWJvdmUuIElmIHRoZSByZWFkZXIg
b2YgdGhpcyBtZXNzYWdlIGlzIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3UgYXJlIGhl
cmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24gb3IgY29w
eWluZyBvZiB0aGlzIGNvbW11bmljYXRpb24gaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gSWYgeW91
IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4gZXJyb3IsIGRvIG5vdCByZWFkIGl0
LiBQbGVhc2UgaW1tZWRpYXRlbHkgcmVwbHkgdG8gdGhlIHNlbmRlciB0aGF0IHlvdSBoYXZlIHJl
Y2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciBhbmQgdGhlbiBkZWxldGUgaXQuDQoN
CkVzdGEgbWVuc2FnZW0gZSBzZXVzIGFuZXhvcyBzZSBkaXJpZ2VtIGV4Y2x1c2l2YW1lbnRlIGFv
IHNldSBkZXN0aW5hdMOhcmlvLCBwb2RlIGNvbnRlciBpbmZvcm1hw6fDo28gcHJpdmlsZWdpYWRh
IG91IGNvbmZpZGVuY2lhbCBlIMOpIHBhcmEgdXNvIGV4Y2x1c2l2byBkYSBwZXNzb2Egb3UgZW50
aWRhZGUgZGUgZGVzdGluby4gU2UgbsOjbyDDqSB2b3NzYSBzZW5ob3JpYSBvIGRlc3RpbmF0w6Fy
aW8gaW5kaWNhZG8sIGZpY2Egbm90aWZpY2FkbyBkZSBxdWUgYSBsZWl0dXJhLCB1dGlsaXphw6fD
o28sIGRpdnVsZ2HDp8OjbyBlL291IGPDs3BpYSBzZW0gYXV0b3JpemHDp8OjbyBwb2RlIGVzdGFy
IHByb2liaWRhIGVtIHZpcnR1ZGUgZGEgbGVnaXNsYcOnw6NvIHZpZ2VudGUuIFNlIHJlY2ViZXUg
ZXN0YSBtZW5zYWdlbSBwb3IgZXJybywgcm9nYW1vcy1saGUgcXVlIG5vcyBvIGNvbXVuaXF1ZSBp
bWVkaWF0YW1lbnRlIHBvciBlc3RhIG1lc21hIHZpYSBlIHByb2NlZGEgYSBzdWEgZGVzdHJ1acOn
w6NvDQo=

--_000_a2ba892522654b5f8be41113ffee2bccDB4PR06MB576eurprd06pro_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K
CXtmb250LWZhbWlseTpTaW1TdW47DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpA
Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlNpbVN1bjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAx
IDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FtYnJpYTsNCglwYW5vc2UtMToy
IDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN
CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt
aWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNl
DQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0
O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxAU2ltU3VuIjsNCglwYW5vc2UtMToyIDEg
NiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk66buY6K6k5a2X5L2T
O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBk
aXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCXRl
eHQtYWxpZ246anVzdGlmeTsNCglmb250LXNpemU6MTAuNXB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxp
YnJpIiwic2Fucy1zZXJpZiI7fQ0KaDQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk7DQoJbXNvLXN0
eWxlLWxpbms6IlTDrXR1bG8gNCBDYXIiOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1h
cmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxl
ZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6U2ltU3VuOw0KCWZvbnQt
d2VpZ2h0OmJvbGQ7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJp
b3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N
CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp
dHk6OTk7DQoJY29sb3I6Izk1NEY3MjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAu
TXNvUGxhaW5UZXh0LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRleHQNCgl7bXNvLXN0
eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJUZXh0byBzaW4gZm9ybWF0byBDYXIi
Ow0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC41
cHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpwDQoJe21zby1zdHls
ZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6
MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglm
b250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OlNpbVN1bjt9DQpwLk1zb0FjZXRhdGUsIGxp
Lk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt
c28tc3R5bGUtbGluazoiVGV4dG8gZGUgZ2xvYm8gQ2FyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdp
bi1ib3R0b206LjAwMDFwdDsNCgl0ZXh0LWFsaWduOmp1c3RpZnk7DQoJZm9udC1zaXplOjguMHB0
Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLlR0dWxvNENhcg0K
CXttc28tc3R5bGUtbmFtZToiVMOtdHVsbyA0IENhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk7
DQoJbXNvLXN0eWxlLWxpbms6IlTDrXR1bG8gNCI7DQoJZm9udC1mYW1pbHk6IkNhbWJyaWEiLCJz
ZXJpZiI7DQoJY29sb3I6IzRGODFCRDsNCglmb250LXdlaWdodDpib2xkOw0KCWZvbnQtc3R5bGU6
aXRhbGljO30NCnNwYW4uVGV4dG9zaW5mb3JtYXRvQ2FyDQoJe21zby1zdHlsZS1uYW1lOiJUZXh0
byBzaW4gZm9ybWF0byBDYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt
bGluazoiVGV4dG8gc2luIGZvcm1hdG8iOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4u
NENoYXINCgl7bXNvLXN0eWxlLW5hbWU6Iuagh+mimCA0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlv
cml0eTo5Ow0KCW1zby1zdHlsZS1saW5rOiLmoIfpopggNCI7DQoJZm9udC1mYW1pbHk6U2ltU3Vu
Ow0KCWZvbnQtd2VpZ2h0OmJvbGQ7fQ0KcC40LCBsaS40LCBkaXYuNA0KCXttc28tc3R5bGUtbmFt
ZToi5qCH6aKYIDQiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi
5qCH6aKYIDQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
dGV4dC1hbGlnbjpqdXN0aWZ5Ow0KCWZvbnQtc2l6ZToxMC41cHQ7DQoJZm9udC1mYW1pbHk6IkNh
bGlicmkiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkNoYXINCgl7bXNvLXN0eWxlLW5hbWU6Iue6r+aW
h+acrCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms657qv
5paH5pysOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KcC5hLCBsaS5h
LCBkaXYuYQ0KCXttc28tc3R5bGUtbmFtZTrnuq/mlofmnKw7DQoJbXNvLXN0eWxlLXByaW9yaXR5
Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiLnuq/mlofmnKwgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCglt
YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJdGV4dC1hbGlnbjpqdXN0aWZ5Ow0KCWZvbnQtc2l6ZTox
MC41cHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpwLmJlcnNjaHJp
ZnQ0LCBsaS5iZXJzY2hyaWZ0NCwgZGl2LmJlcnNjaHJpZnQ0DQoJe21zby1zdHlsZS1uYW1lOiLD
nGJlcnNjaHJpZnQgNCI7DQoJbXNvLXN0eWxlLWxpbms6IsOcYmVyc2NocmlmdCA0IFpjaG4iOw0K
CW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCXRleHQtYWxpZ246anVzdGlm
eTsNCglmb250LXNpemU6MTAuNXB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp
ZiI7fQ0Kc3Bhbi5iZXJzY2hyaWZ0NFpjaG4NCgl7bXNvLXN0eWxlLW5hbWU6IsOcYmVyc2Nocmlm
dCA0IFpjaG4iOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5Ow0KCW1zby1zdHlsZS1saW5rOiLDnGJl
cnNjaHJpZnQgNCI7DQoJZm9udC1mYW1pbHk6IkNhbWJyaWEiLCJzZXJpZiI7DQoJY29sb3I6IzRG
ODFCRDsNCglmb250LXdlaWdodDpib2xkOw0KCWZvbnQtc3R5bGU6aXRhbGljO30NCnAuTnVyVGV4
dCwgbGkuTnVyVGV4dCwgZGl2Lk51clRleHQNCgl7bXNvLXN0eWxlLW5hbWU6Ik51ciBUZXh0IjsN
Cgltc28tc3R5bGUtbGluazoiTnVyIFRleHQgWmNobiI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4t
Ym90dG9tOi4wMDAxcHQ7DQoJdGV4dC1hbGlnbjpqdXN0aWZ5Ow0KCWZvbnQtc2l6ZToxMC41cHQ7
DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLk51clRleHRaY2hu
DQoJe21zby1zdHlsZS1uYW1lOiJOdXIgVGV4dCBaY2huIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6
OTk7DQoJbXNvLXN0eWxlLWxpbms6Ik51ciBUZXh0IjsNCglmb250LWZhbWlseTpDb25zb2xhczt9
DQpzcGFuLkVzdGlsb0NvcnJlbzI5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQt
ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFu
LmFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1jb252ZXJ0ZWQt
c3BhY2U7fQ0Kc3Bhbi5pY29uDQoJe21zby1zdHlsZS1uYW1lOmljb247fQ0Kc3Bhbi5Fc3RpbG9D
b3JyZW8zMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJy
aSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5Fc3RpbG9Db3JyZW8zMw0K
CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs
InNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5UZXh0b2RlZ2xvYm9DYXINCgl7
bXNvLXN0eWxlLW5hbWU6IlRleHRvIGRlIGdsb2JvIENhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5
Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJUZXh0byBkZSBnbG9ibyI7DQoJZm9udC1mYW1pbHk6IlRh
aG9tYSIsInNhbnMtc2VyaWYiO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4
cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np
emU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7
fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmlu
aXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo3NTkxMDg5OTE7DQoJbXNvLWxpc3Qt
dGVtcGxhdGUtaWRzOi0xMTY0ODI2OTc0O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwt
bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10
YWItc3RvcDozNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt
aW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls
eTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC10YWItc3RvcDo3Mi4wcHQ7
DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7
fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC10YWItc3RvcDoxMDguMHB0Ow0KCW1zby1s
ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0
IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MTQ0LjBwdDsNCgltc28tbGV2ZWwtbnVt
YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZl
bDUNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjE4MC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np
dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21z
by1sZXZlbC10YWItc3RvcDoyMTYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm
dDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwt
dGFiLXN0b3A6MjUyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4
dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLXRhYi1zdG9w
OjI4OC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50
Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC10YWItc3RvcDozMjQuMHB0
Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0
O30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjEwMjM2MzMyNTI7DQoJbXNvLWxpc3QtdGVtcGxh
dGUtaWRzOjIxMTAxNjk4NDg7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXIt
Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w
OjM2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6
LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJv
bDt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K
CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NzIuMHB0Ow0KCW1zby1s
ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1h
bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxl
dmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6
74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxMDguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9z
aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZTox
MC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2
ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl
bC10YWItc3RvcDoxNDQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0
ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m
YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h
dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxODAu
MHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu
MHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N
CkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv
LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyMTYuMHB0Ow0KCW1zby1sZXZl
bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNp
LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVs
Nw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3
Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyNTIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp
b246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w
cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwt
bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10
YWItc3RvcDoyODguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0
LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p
bHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi
dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozMjQuMHB0
Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0
Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs
aXN0IGwyDQoJe21zby1saXN0LWlkOjEwNzkxMzI4MzA7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRz
Oi05MTU5MTAxMTg7fQ0KQGxpc3QgbDI6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0
OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjM2LjBw
dDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw
dDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA
bGlzdCBsMjpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s
ZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOjcyLjBwdDsNCgltc28tbGV2ZWwtbnVt
YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250
LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJpZGktZm9u
dC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDI6bGV2ZWwzDQoJe21zby1sZXZl
bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs
LXRhYi1zdG9wOjEwOC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl
eHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh
bWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDI6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9y
bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjE0
NC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0x
OC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7
fQ0KQGxpc3QgbDI6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt
c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjE4MC4wcHQ7DQoJbXNvLWxl
dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFu
c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2
ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv
grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIxNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np
dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw
LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw3DQoJe21zby1sZXZl
bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs
LXRhYi1zdG9wOjI1Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl
eHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh
bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0
OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjI4OC4w
cHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4w
cHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K
QGxpc3QgbDI6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t
bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMyNC4wcHQ7DQoJbXNvLWxldmVs
LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2kt
Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDMNCgl7bXNv
LWxpc3QtaWQ6MTEzNzc5MzMxOTsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE1Njg5NTI7fQ0K
QGxpc3QgbDM6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t
bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjM2LjBwdDsNCgltc28tbGV2ZWwt
bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1m
b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDIN
Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJ
bXNvLWxldmVsLXRhYi1zdG9wOjcyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl
ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K
CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVz
IE5ldyBSb21hbiI7fQ0KQGxpc3QgbDM6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0
OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEwOC4w
cHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4w
cHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K
QGxpc3QgbDM6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t
bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjE0NC4wcHQ7DQoJbXNvLWxldmVs
LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2kt
Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw1
DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7
DQoJbXNvLWxldmVsLXRhYi1zdG9wOjE4MC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv
bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw
dDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw2DQoJe21zby1sZXZlbC1u
dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh
Yi1zdG9wOjIxNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt
aW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls
eTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1
bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjI1Mi4wcHQ7
DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7
DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp
c3QgbDM6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2
ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjI4OC4wcHQ7DQoJbXNvLWxldmVsLW51
bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9u
dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw5DQoJ
e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ
bXNvLWxldmVsLXRhYi1zdG9wOjMyNC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps
ZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN
Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQNCgl7bXNvLWxpc3QtaWQ6MTIwNDYzNjM3
OTsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTc5MTg4MjM5ODt9DQpAbGlzdCBsNDpsZXZlbDEN
Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN
Cgltc28tbGV2ZWwtdGFiLXN0b3A6MzYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246
bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7
DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw0OmxldmVsMg0KCXttc28tbGV2ZWwtbnVt
YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0
b3A6NzIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu
dDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNv
dXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpA
bGlzdCBsNDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s
ZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTA4LjBwdDsNCgltc28tbGV2ZWwt
bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1m
b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNDpsZXZl
bDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjE0NC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np
dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDQ6bGV2ZWw1DQoJe21z
by1sZXZlbC10YWItc3RvcDoxODAuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm
dDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGw0OmxldmVsNg0KCXttc28tbGV2ZWwt
dGFiLXN0b3A6MjE2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4
dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsNDpsZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9w
OjI1Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50
Oi0xOC4wcHQ7fQ0KQGxpc3QgbDQ6bGV2ZWw4DQoJe21zby1sZXZlbC10YWItc3RvcDoyODguMHB0
Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0
O30NCkBsaXN0IGw0OmxldmVsOQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MzI0LjBwdDsNCgltc28t
bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlz
dCBsNQ0KCXttc28tbGlzdC1pZDoxNDI4ODkwMTY5Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczo3
ODg0MDE2NjY7fQ0KQGxpc3QgbDU6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1
bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjM2LjBwdDsN
Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsN
Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz
dCBsNTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl
bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NzIuMHB0Ow0KCW1zby1sZXZlbC1udW1i
ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQt
c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw1OmxldmVsMw0KCXtt
c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z
by1sZXZlbC10YWItc3RvcDoxMDguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm
dDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ
Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw1OmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVy
LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv
cDoxNDQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu
dDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3lt
Ym9sO30NCkBsaXN0IGw1OmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7
DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxODAuMHB0Ow0KCW1z
by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1z
by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw1
OmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl
eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyMTYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXIt
cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6
ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw1OmxldmVsNw0KCXttc28t
bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s
ZXZlbC10YWItc3RvcDoyNTIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN
Cgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u
dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw1OmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZv
cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoy
ODguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot
MTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9s
O30NCkBsaXN0IGw1OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ
bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozMjQuMHB0Ow0KCW1zby1s
ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1h
bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCm9sDQoJe21hcmdp
bi1ib3R0b206MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+PCEt
LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk
bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+
DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0
YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi
b2R5IGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiIgc3R5bGU9InRl
eHQtanVzdGlmeS10cmltOnB1bmN0dWF0aW9uIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xv
cjojMUY0OTdEIj4mIzQzOzE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y
ZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQi
PjxiPjxzcGFuIGxhbmc9IkVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RGU6PC9zcGFuPjwvYj48
c3BhbiBsYW5nPSJFUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBTdXBhIFttYWlsdG86c3VwYS1i
b3VuY2VzQGlldGYub3JnXQ0KPGI+RW4gbm9tYnJlIGRlIDwvYj5Lb3N0YXMgUGVudGlrb3VzaXM8
YnI+DQo8Yj5FbnZpYWRvIGVsOjwvYj4gbWnDqXJjb2xlcywgMjQgZGUgc2VwdGllbWJyZSBkZSAy
MDE0IDE2OjMxPGJyPg0KPGI+UGFyYTo8L2I+IExpdXNodWNoZW5nIChXaWxsKTsgc3VwYUBpZXRm
Lm9yZzxicj4NCjxiPkFzdW50bzo8L2I+IFJlOiBbU3VwYV0gYm9mIHJlcXVlc3QgdGV4dDxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBh
bGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdCI+PG86cD4mbmJzcDs8L286cD48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xv
cjojMUY0OTdEIj5IaSBXaWxsLCBhbGwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+R2l2ZW4gdGhhdCB0aGUgbWVl
dGluZyBpcyBpbiBIYXdhaWksIHJlbW90ZSBwYXJ0aWNpcGF0aW9uIHdvdWxkIGJlIGhpZ2hseSBk
ZXNpcmFibGUgaW1vLiBTbyBJIHdvdWxkIHNheSDigJx5ZXPigJ0gZm9yIHdlYmV4L21lZXRlY2hv
LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9InRl
eHQtYWxpZ246bGVmdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3
RCI+QmVzdCByZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIGFsaWduPSJsZWZ0IiBzdHlsZT0idGV4dC1hbGlnbjpsZWZ0Ij48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVm
dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+S29zdGFzPG86
cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVl
IDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJv
cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBj
bSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0IiBzdHlsZT0idGV4
dC1hbGlnbjpsZWZ0Ij48Yj48c3BhbiBsYW5nPSJERSIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlZv
bjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkRFIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IExpdXNo
dWNoZW5nIChXaWxsKSBbPGEgaHJlZj0ibWFpbHRvOmxpdXNodWNoZW5nQGh1YXdlaS5jb20iPm1h
aWx0bzpsaXVzaHVjaGVuZ0BodWF3ZWkuY29tPC9hPl0NCjxicj4NCjxiPkdlc2VuZGV0OjwvYj4g
TWl0dHdvY2gsIDI0LiBTZXB0ZW1iZXIgMjAxNCAxNjoyNTxicj4NCjxiPkFuOjwvYj4gPGEgaHJl
Zj0ibWFpbHRvOnN1cGFAaWV0Zi5vcmciPnN1cGFAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+QmV0cmVm
Zjo8L2I+IFtTdXBhXSBib2YgcmVxdWVzdCB0ZXh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k
aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0IiBzdHlsZT0idGV4
dC1hbGlnbjpsZWZ0Ij48c3BhbiBsYW5nPSJERSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgYWxsLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J
4oCZbSBzZW5kaW5nIHlvdSB0aGUgdXBkYXRlZCB2ZXJzaW9uIG9mIGJvZiByZXF1ZXN0LiBQbGVh
c2UgcmV2aWV3IGl0IGFuZCBsZXQgbWUga25vdyB5b3VyIHRob3VnaHQuPG86cD48L286cD48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29QbGFpblRleHQiPlRoZSBtYWluIGNoYW5nZXMgYXJlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb1BsYWluVGV4dCI+SSBjdXQgdGhlIHJlcXVlc3Qgc2hvcnQgYnkgcmVtb3ZpbmcgdGhl
ICcnV29yayBpdGVtcyByZWxhdGVkIHRvIFNVUEEgaW5jbHVkZTonJyBhbmQgJydNaWxlc3RvbmVz
OicnLCB3aGljaCBhcmUgdXN1YWxseSBub3QgcHV0IGluIHRoZSByZXF1ZXN0LiAoUXVlc3Rpb246
IHNob3VsZCBJIHJlbW92ZSB0aGVtPyk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp
blRleHQiPkkgdXBkYXRlZCB0aGUgbGlua3MgYW5kIHRoZSByZXNwb25zaWJsZSBBRCwgYW5kIG1h
a2UgdGhlIGZvcm1hdCBuZWF0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4
dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8aDQgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDo1
LjRwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206MGNtO21hcmdpbi1sZWZ0OjBjbTtt
YXJnaW4tYm90dG9tOi4wMDAxcHQ7cGFnZS1icmVhay1hZnRlcjphdm9pZDtiYWNrZ3JvdW5kOndo
aXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5Oum7mOiupOWt
l+S9kztjb2xvcjpibGFjayI+U1VQQTxvOnA+PC9vOnA+PC9zcGFuPjwvaDQ+DQo8dWwgdHlwZT0i
ZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOmJsYWNrO21zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQtYWxpZ246bGVm
dDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5Oum7mOiupOWtl+S9kyI+TG9uZyBuYW1lIGFu
ZCBhYmJyZXZpYXRpb246IFNVUEEgKFNoYXJlZCBVbmlmaWVkIFBvbGljeSBBdXRvbWF0aW9uKTxv
OnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjpi
bGFjazttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0
ZXh0LWFsaWduOmxlZnQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzM7YmFja2dyb3VuZDp3aGl0ZSI+
DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTrpu5jorqTlrZfkvZMi
PkRlc2NyaXB0aW9uOiBOZXR3b3JrIG9wZXJhdG9ycyBhcmUgZmFjZWQgd2l0aCBuZXR3b3JrcyBv
ZiBpbmNyZWFzaW5nIHNpemUgYW5kIGNvbXBsZXhpdHkgd2hpbGUgdHJ5aW5nIHRvIGltcHJvdmUg
dGhlaXIgcXVhbGl0eSBhbmQgYXZhaWxhYmlsaXR5LCBhcyBtb3JlIGFuZCBtb3JlIHNlcnZpY2Vz
IGRlcGVuZCBvbiB0aGVtLiBBdXRvbWF0aW5nIHRoZSB3YXkgb2YNCiBleHBvc2luZyBhIHZpZXcg
b2YgdGhlIG5ldHdvcmsgdG8gYXBwbGljYXRpb25zIG1heSBwcm92aWRlIHNpZ25pZmljYW50IGlt
cHJvdmVtZW50cyBpbiBjb25maWd1cmF0aW9uIGFnaWxpdHksIGVycm9yIGRldGVjdGlvbiBhbmQg
dXB0aW1lIGZvciBvcGVyYXRvcnMuIEhvd2V2ZXIgdGhlIHJlYWwgdmFsdWUgYmVoaW5kIGNlbnRy
YWwgY29uZmlndXJhdGlvbiBzY2hlbWVzIGxpZXMgd2l0aGluIHRoZSBwb3NzaWJsZSBzaW1wbGlm
aWNhdGlvbiB0aHJvdWdoDQogbW9kZWxzIHByb3ZpZGVkIGJ5IHN1Y2ggc3lzdGVtcyB0byBhcHBs
aWNhdGlvbnMgYW5kIG5ldHdvcmsgc2VydmljZXMgcnVubmluZyBhYm92ZSB0aGVtIChvbiB0aGUg
c28tY2FsbGVkIG5vcnRoYm91bmQgc2lkZSkuIFdlbGwtZGVzaWduZWQgbW9kZWxzIGFyZSBhYmxl
IHRvIHByb3ZpZGUgYSB3aWRlIHJhbmdlIG9mIGdyYW51bGFyaXR5IGZvciB2YXJpb3VzIGFwcGxp
Y2F0aW9ucyBhbmQgbmV0d29yayBzZXJ2aWNlcyBuZWVkcywgZnJvbSB0aGUgbG93ZXItbGV2ZWwN
CiBwaHlzaWNhbCBuZXR3b3JrIHRvIGhpZ2gtbGV2ZWwgYXBwbGljYXRpb24gc2VydmljZXMuPG86
cD48L286cD48L3NwYW4+PC9saT48L3VsPg0KPHAgc3R5bGU9Im1hcmdpbi1sZWZ0OjIxLjBwdDtt
c28tcGFyYS1tYXJnaW4tbGVmdDoyLjBnZDtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTrpu5jorqTlrZfkvZM7Y29sb3I6YmxhY2siPlBs
ZWFzZSBub3RlIHRoYXQgdGhpcyBpcyBhIG5ldyB2ZXJzaW9uIG9mIGFwb25mIGJvZiBwcm9wb3Nh
bCBiYXNlZCBvbiBjb21tZW50cyByZWNlaXZlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBz
dHlsZT0ibWFyZ2luLWxlZnQ6MjEuMHB0O21zby1wYXJhLW1hcmdpbi1sZWZ0OjIuMGdkO2JhY2tn
cm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5Oum7
mOiupOWtl+S9kztjb2xvcjpibGFjayI+VGhlIG1haW4gZ29hbCBvZiBTVVBBIGlzIHRvIHByb3Zp
ZGUgYSB3YXkgZm9yIGFwcGxpY2F0aW9ucyBhbmQgZm9yIG5ldHdvcmsgc2VydmljZXMgdG8gc3Bl
Y2lmeSBTSEFSRUQgYXBwbGljYXRpb24gYmFzZWQgUE9MSUNJRVMNCiB0byB0aGUgbmV0d29yayBp
bmZyYXN0cnVjdHVyZSB1c2luZyBhIHNpbXBsaWZpZWQgdmlldyBvZiB0aGUgbmV0d29yay4gVGhp
cyBjYW4gYmUgcmVhbGl6ZWQgYnk6ICgxKSBtb2RlbGluZyB0aGUgbmV0d29yayBpbmZyYXN0cnVj
dHVyZSBhcyBhbiBzaW1wbGlmaWVkIG5ldHdvcmsgZ3JhcGggdXNpbmcgYSBtb2RlbGluZyBsYW5n
dWFnZSBzdWNoIGFzIFlBTkcsICgyKSB0cmFuc3BvcnRpbmcgbW9kZWwgaW5zdGFuY2VzIGVpdGhl
ciB1c2luZyBORVRDT05GDQogb3IgUkVTVENPTkYgYW5kICgzKSBwcm92aWRpbmcgZ3VpZGVsaW5l
cyBvbiBBVVRPTUFUSUNBTExZIG1hcHBpbmcgcG9saWNpZXMgdG8gYXR0cmlidXRlcyBvZiB0aGUg
bmV0d29yayBncmFwaHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHVsIHR5cGU9ImRpc2MiPg0K
PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjpibGFjazttc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOmxlZnQ7bXNvLWxp
c3Q6bDQgbGV2ZWwxIGxmbzY7YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTrpu5jorqTlrZfkvZMiPkFnZW5kYTogVEJEPG86cD48L286
cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOmJsYWNrO21z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQtYWxp
Z246bGVmdDttc28tbGlzdDpsNCBsZXZlbDEgbGZvNjtiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5Oum7mOiupOWtl+S9kyI+U3RhdHVz
OiBXRyBGb3JtaW5nPG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9ImNvbG9yOmJsYWNrO21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvO3RleHQtYWxpZ246bGVmdDttc28tbGlzdDpsNCBsZXZlbDEgbGZvNjtiYWNr
Z3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
Oum7mOiupOWtl+S9kyI+UmVzcG9uc2libGUgQUQ6IEJlbm9pdCBDbGFpc2U8bzpwPjwvbzpwPjwv
c3Bhbj48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6YmxhY2s7bXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1hbGlnbjps
ZWZ0O21zby1saXN0Omw0IGxldmVsMSBsZm82O2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk66buY6K6k5a2X5L2TIj5Cb0YgcHJvcG9u
ZW50czogVEJEPG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9ImNvbG9yOmJsYWNrO21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvO3RleHQtYWxpZ246bGVmdDttc28tbGlzdDpsNCBsZXZlbDEgbGZvNjtiYWNrZ3Jv
dW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5Oum7
mOiupOWtl+S9kyI+Qm9GIENoYWlyczogVEJEPG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOmJsYWNrO21zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQtYWxpZ246bGVmdDttc28tbGlzdDpsNCBs
ZXZlbDEgbGZvNjtiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5Oum7mOiupOWtl+S9kyI+TnVtYmVyIG9mIHBlb3BsZSBleHBlY3RlZCB0
byBhdHRlbmQ6IDEwMDxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJjb2xvcjpibGFjazttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOmxlZnQ7bXNvLWxpc3Q6bDQgbGV2ZWwxIGxmbzY7YmFj
a2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTrpu5jorqTlrZfkvZMiPkxlbmd0aCBvZiBzZXNzaW9uICgxLCAxLjUsIDIsIG9yIDIuNSBob3Vy
cyk6IDEuNSBob3VyczxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJjb2xvcjpibGFjazttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOmxlZnQ7bXNvLWxpc3Q6bDQgbGV2ZWwxIGxmbzY7YmFj
a2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTrpu5jorqTlrZfkvZMiPkNvbmZsaWN0cyB0byBhdm9pZCAod2hvbGUgQXJlYXMgYW5kL29yIFdH
cyk6PG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNv
bG9yOmJsYWNrO21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvO3RleHQtYWxpZ246bGVmdDttc28tbGlzdDpsNCBsZXZlbDEgbGZvNjtiYWNrZ3JvdW5kOndo
aXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5Oum7mOiupOWt
l+S9kyI+RG9lcyBpdCByZXF1aXJlIFdlYkVYPyBJZiBzbywgd2h5Pzogbm88bzpwPjwvbzpwPjwv
c3Bhbj48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6YmxhY2s7bXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1hbGlnbjps
ZWZ0O21zby1saXN0Omw0IGxldmVsMSBsZm82O2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk66buY6K6k5a2X5L2TIj5Eb2VzIGl0IHJl
cXVpcmUgTWVldGVjaG8/IElmIHNvLCB3aHk/OiBubzxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxp
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjpibGFjazttc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOmxlZnQ7bXNvLWxpc3Q6
bDQgbGV2ZWwxIGxmbzY7YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTrpu5jorqTlrZfkvZMiPkxpbmtzIHRvIHRoZSBtYWlsaW5nIGxp
c3QsIGRyYWZ0IGNoYXJ0ZXIgaWYgYW55LCByZWxldmFudCBJbnRlcm5ldC1EcmFmdHMsIGV0Yy48
L3NwYW4+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTrpu5jorqTl
rZfkvZMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PC91bD4NCjx1bCB0eXBlPSJkaXNjIj4NCjx1
bCB0eXBlPSJjaXJjbGUiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjpibGFj
azttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0
LWFsaWduOmxlZnQ7bXNvLWxpc3Q6bDQgbGV2ZWwyIGxmbzY7YmFja2dyb3VuZDp3aGl0ZSI+DQo8
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTrpu5jorqTlrZfkvZMiPkJv
RiBJbmZvIFBhZ2U6PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z
cGFuPjxhIGhyZWY9Imh0dHA6Ly9saXVzaHVjaGVuZy5naXRodWIuaW8vU1VQQS8iPjxzcGFuIGNs
YXNzPSJpY29uIj48c3BhbiBzdHlsZT0iY29sb3I6IzQ0MDA4OCI+4oCLPC9zcGFuPjwvc3Bhbj48
c3BhbiBzdHlsZT0iY29sb3I6IzQ0MDA4OCI+aHR0cDovL2xpdXNodWNoZW5nLmdpdGh1Yi5pby9T
VVBBLzwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9ImNvbG9yOmJsYWNrO21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvO3RleHQtYWxpZ246bGVmdDttc28tbGlzdDpsNCBsZXZlbDIgbGZvNjti
YWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5Oum7mOiupOWtl+S9kyI+TWFpbGluZyBsaXN0IGFuZCBpbmZvIHBhZ2U6PHNwYW4gY2xhc3M9
ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpzdXBh
QGlldGYub3JnIj48c3BhbiBjbGFzcz0iaWNvbiI+PHNwYW4gc3R5bGU9ImNvbG9yOiM0NDAwODgi
PuKAizwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiM0NDAwODgiPnN1cGFAaWV0Zi5v
cmc8L3NwYW4+PC9hPjs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8
L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdXBh
Ij48c3BhbiBjbGFzcz0iaWNvbiI+PHNwYW4gc3R5bGU9ImNvbG9yOiM0NDAwODgiPuKAizwvc3Bh
bj48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiM0NDAwODgiPmh0dHBzOi8vd3d3LmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vc3VwYTwvc3Bhbj48L2E+OzxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+
PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjpibGFjazttc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOmxlZnQ7bXNvLWxp
c3Q6bDQgbGV2ZWwyIGxmbzY7YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBsYW5nPSJERSIgc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk66buY6K6k5a2X5L2TIj5EcmFmdCBjaGFy
dGVyOjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3Nw
YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk66buY6K6k5a2X5L2T
Ij48YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vbGl1c2h1Y2hlbmcvU1VQQS93aWtpL1NVUEEt
Q2hhcnRlciI+PHNwYW4gY2xhc3M9Imljb24iPjxzcGFuIGxhbmc9IkRFIiBzdHlsZT0iY29sb3I6
IzQ0MDA4OCI+4oCLPC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJERSIgc3R5bGU9ImNvbG9yOiM0
NDAwODgiPmh0dHBzOi8vZ2l0aHViLmNvbS9saXVzaHVjaGVuZy9TVVBBL3dpa2kvU1VQQS1DaGFy
dGVyPC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+
PHNwYW4gbGFuZz0iREUiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5Oum7mOiu
pOWtl+S9kyI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJERSIgc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk66buY6K6k5a2X5L2TIj47PC9zcGFuPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5Oum7mOiupOWtl+S9kyI+PGEgaHJlZj0iaHR0
cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3N1cGEvY3VycmVudC9tc2cwMDA1MS5o
dG1sIj48c3BhbiBjbGFzcz0iaWNvbiI+PHNwYW4gbGFuZz0iREUiIHN0eWxlPSJjb2xvcjojNDQw
MDg4Ij7igIs8L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkRFIiBzdHlsZT0iY29sb3I6IzQ0MDA4
OCI+aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3N1cGEvY3VycmVudC9tc2cw
MDA1MS5odG1sPC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gbGFuZz0iREUiIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5Oum7mOiupOWtl+S9kyI+PG86cD48L286cD48L3NwYW4+PC9s
aT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOmJsYWNrO21zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQtYWxpZ246bGVmdDttc28t
bGlzdDpsNCBsZXZlbDIgbGZvNjtiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5Oum7mOiupOWtl+S9kyI+UmVsZXZhbnQgZHJhZnRzOjwv
c3Bhbj4gPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk66buY6K6k5a2X
5L2TIj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PC91bD4NCjwvdWw+DQo8dWwgdHlwZT0iZGlz
YyI+DQo8dWwgdHlwZT0iY2lyY2xlIj4NCjx1bCB0eXBlPSJzcXVhcmUiPg0KPGxpIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJjb2xvcjpibGFjazttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOmxlZnQ7bXNvLWxpc3Q6bDQgbGV2ZWwz
IGxmbzY7YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTrpu5jorqTlrZfkvZMiPjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9o
dG1sL2RyYWZ0LWthcmFnaWFubmlzLXN1cGEtcHJvYmxlbS1zdGF0ZW1lbnQiPjxzcGFuIHN0eWxl
PSJjb2xvcjojNDQwMDg4Ij5kcmFmdC1rYXJhZ2lhbm5pcy1zdXBhLXByb2JsZW0tc3RhdGVtZW50
PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0iY29sb3I6YmxhY2s7bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG87dGV4dC1hbGlnbjpsZWZ0O21zby1saXN0Omw0IGxldmVsMyBsZm82O2JhY2tn
cm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
6buY6K6k5a2X5L2TIj48YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1j
aGVuZy1zdXBhLWRkYy11c2UtY2FzZXMiPjxzcGFuIHN0eWxlPSJjb2xvcjojNDQwMDg4Ij5kcmFm
dC1jaGVuZy1zdXBhLWRkYy11c2UtY2FzZXM8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwv
bGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjpibGFjazttc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOmxlZnQ7bXNv
LWxpc3Q6bDQgbGV2ZWwzIGxmbzY7YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTrpu5jorqTlrZfkvZMiPjxhIGhyZWY9Imh0dHA6Ly90
b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXBlbnRpa291c2lzLXN1cGEtbWFwcGluZyI+PHNwYW4g
c3R5bGU9ImNvbG9yOiM0NDAwODgiPmRyYWZ0LXBlbnRpa291c2lzLXN1cGEtbWFwcGluZzwvc3Bh
bj48L2E+PG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
ImNvbG9yOmJsYWNrO21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvO3RleHQtYWxpZ246bGVmdDttc28tbGlzdDpsNCBsZXZlbDMgbGZvNjtiYWNrZ3JvdW5k
OndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5Oum7mOiu
pOWtl+S9kyI+PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY29udHJl
cmFzLXN1cGEteWFuZy1uZXR3b3JrLXRvcG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojNDQwMDg4Ij5k
cmFmdC1jb250cmVyYXMtc3VwYS15YW5nLW5ldHdvcmstdG9wbzwvc3Bhbj48L2E+PG86cD48L286
cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOmJsYWNrO21z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQtYWxp
Z246bGVmdDttc28tbGlzdDpsNCBsZXZlbDMgbGZvNjtiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5Oum7mOiupOWtl+S9kyI+PGEgaHJl
Zj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtemFhbG91ay1zdXBhLWNvbmZpZ3Vy
YXRpb24tbW9kZWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojNDQwMDg4Ij5kcmFmdC16YWFsb3VrLXN1
cGEtY29uZmlndXJhdGlvbi1tb2RlbDwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9saT48
L3VsPg0KPC91bD4NCjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+UmVnYXJkcyw8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2h1Y2hlbmcgTElVIChX
aWxsKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxpPlNodWNo
ZW5nIExJVSAoV2lsbCksIFBoLkQuPG86cD48L286cD48L2k+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PGk+UmVzZWFyY2hlciAmYW1wOyBTdGFuZGFyZCBSZXByZXNlbnRhdGl2ZSA8bzpwPjwv
bzpwPjwvaT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48aT48c3BhbiBsYW5nPSJERSI+SHVh
d2VpIFRlY2hub2xvZ2llcyBDby4sTHRkPG86cD48L286cD48L3NwYW4+PC9pPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxpPjxhIGhyZWY9Im1haWx0bzpsaXVzaHVjaGVuZ0BodWF3ZWkuY29t
Ij48c3BhbiBsYW5nPSJERSIgc3R5bGU9ImNvbG9yOmJsdWUiPmxpdXNodWNoZW5nQGh1YXdlaS5j
b208L3NwYW4+PC9hPjwvaT48aT48c3BhbiBsYW5nPSJERSI+PG86cD48L286cD48L3NwYW4+PC9p
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxpPjxhIGhyZWY9Imh0dHA6Ly93d3cubGlua2Vk
aW4uY29tL2luL3NodWNoZW5nIj48c3BhbiBsYW5nPSJERSIgc3R5bGU9ImNvbG9yOmJsdWUiPmh0
dHA6Ly93d3cubGlua2VkaW4uY29tL2luL3NodWNoZW5nPC9zcGFuPjwvYT48L2k+PGk+PHNwYW4g
bGFuZz0iREUiPjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJyPg0KPGhy
Pg0KPGZvbnQgZmFjZT0iQXJpYWwiIGNvbG9yPSJHcmF5IiBzaXplPSIxIj48YnI+DQpFc3RlIG1l
bnNhamUgeSBzdXMgYWRqdW50b3Mgc2UgZGlyaWdlbiBleGNsdXNpdmFtZW50ZSBhIHN1IGRlc3Rp
bmF0YXJpbywgcHVlZGUgY29udGVuZXIgaW5mb3JtYWNpw7NuIHByaXZpbGVnaWFkYSBvIGNvbmZp
ZGVuY2lhbCB5IGVzIHBhcmEgdXNvIGV4Y2x1c2l2byBkZSBsYSBwZXJzb25hIG8gZW50aWRhZCBk
ZSBkZXN0aW5vLiBTaSBubyBlcyB1c3RlZC4gZWwgZGVzdGluYXRhcmlvIGluZGljYWRvLCBxdWVk
YSBub3RpZmljYWRvIGRlIHF1ZSBsYQ0KIGxlY3R1cmEsIHV0aWxpemFjacOzbiwgZGl2dWxnYWNp
w7NuIHkvbyBjb3BpYSBzaW4gYXV0b3JpemFjacOzbiBwdWVkZSBlc3RhciBwcm9oaWJpZGEgZW4g
dmlydHVkIGRlIGxhIGxlZ2lzbGFjacOzbiB2aWdlbnRlLiBTaSBoYSByZWNpYmlkbyBlc3RlIG1l
bnNhamUgcG9yIGVycm9yLCBsZSByb2dhbW9zIHF1ZSBub3MgbG8gY29tdW5pcXVlIGlubWVkaWF0
YW1lbnRlIHBvciBlc3RhIG1pc21hIHbDrWEgeSBwcm9jZWRhIGEgc3UgZGVzdHJ1Y2Npw7NuLjxi
cj4NCjxicj4NClRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyB0cmFuc21pc3Npb24g
aXMgcHJpdmlsZWdlZCBhbmQgY29uZmlkZW50aWFsIGluZm9ybWF0aW9uIGludGVuZGVkIG9ubHkg
Zm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IG5hbWVkIGFib3ZlLiBJZiB0
aGUgcmVhZGVyIG9mIHRoaXMgbWVzc2FnZSBpcyBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwg
eW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwNCiBkaXN0cmli
dXRpb24gb3IgY29weWluZyBvZiB0aGlzIGNvbW11bmljYXRpb24gaXMgc3RyaWN0bHkgcHJvaGli
aXRlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4gZXJyb3IsIGRv
IG5vdCByZWFkIGl0LiBQbGVhc2UgaW1tZWRpYXRlbHkgcmVwbHkgdG8gdGhlIHNlbmRlciB0aGF0
IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciBhbmQgdGhlbiBk
ZWxldGUgaXQuPGJyPg0KPGJyPg0KRXN0YSBtZW5zYWdlbSBlIHNldXMgYW5leG9zIHNlIGRpcmln
ZW0gZXhjbHVzaXZhbWVudGUgYW8gc2V1IGRlc3RpbmF0w6FyaW8sIHBvZGUgY29udGVyIGluZm9y
bWHDp8OjbyBwcml2aWxlZ2lhZGEgb3UgY29uZmlkZW5jaWFsIGUgw6kgcGFyYSB1c28gZXhjbHVz
aXZvIGRhIHBlc3NvYSBvdSBlbnRpZGFkZSBkZSBkZXN0aW5vLiBTZSBuw6NvIMOpIHZvc3NhIHNl
bmhvcmlhIG8gZGVzdGluYXTDoXJpbyBpbmRpY2FkbywgZmljYSBub3RpZmljYWRvIGRlIHF1ZSBh
DQogbGVpdHVyYSwgdXRpbGl6YcOnw6NvLCBkaXZ1bGdhw6fDo28gZS9vdSBjw7NwaWEgc2VtIGF1
dG9yaXphw6fDo28gcG9kZSBlc3RhciBwcm9pYmlkYSBlbSB2aXJ0dWRlIGRhIGxlZ2lzbGHDp8Oj
byB2aWdlbnRlLiBTZSByZWNlYmV1IGVzdGEgbWVuc2FnZW0gcG9yIGVycm8sIHJvZ2Ftb3MtbGhl
IHF1ZSBub3MgbyBjb211bmlxdWUgaW1lZGlhdGFtZW50ZSBwb3IgZXN0YSBtZXNtYSB2aWEgZSBw
cm9jZWRhIGEgc3VhIGRlc3RydWnDp8Ojbzxicj4NCjwvZm9udD4NCjwvYm9keT4NCjwvaHRtbD4N
Cg==

--_000_a2ba892522654b5f8be41113ffee2bccDB4PR06MB576eurprd06pro_--


From nobody Tue Sep 30 16:03:28 2014
Return-Path: 
X-Original-To: supa@ietfa.amsl.com
Delivered-To: supa@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF9591ACD3F for ; Tue, 30 Sep 2014 16:02:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.686
X-Spam-Level: 
X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.786, 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 w4v-sGlMN6ow for ; Tue, 30 Sep 2014 16:02:31 -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 075E41ACC83 for ; Tue, 30 Sep 2014 16:01:33 -0700 (PDT)
Received: from smtptc.telefonica.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 4DAC8600E5; Wed,  1 Oct 2014 01:01:31 +0200 (CEST)
Received: from ESTGVMSP103.EUROPE.telefonica.corp (unknown [10.92.4.9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtptc.telefonica.com (Postfix) with ESMTPS id 313E9600E1; Wed,  1 Oct 2014 01:01:31 +0200 (CEST)
Received: from emea01-am1-obe.outbound.protection.outlook.com (10.92.5.139) by tls.telefonica.com (10.92.6.50) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 1 Oct 2014 01:01:30 +0200
Received: from DB4PR06MB576.eurprd06.prod.outlook.com (10.242.192.23) by DB4PR06MB573.eurprd06.prod.outlook.com (10.242.159.28) with Microsoft SMTP Server (TLS) id 15.0.1039.15; Tue, 30 Sep 2014 23:01:29 +0000
Received: from DB4PR06MB576.eurprd06.prod.outlook.com ([10.242.192.23]) by DB4PR06MB576.eurprd06.prod.outlook.com ([10.242.192.23]) with mapi id 15.00.1039.011; Tue, 30 Sep 2014 23:01:29 +0000
From: LUIS MIGUEL CONTRERAS MURILLO 
To: Tina TSOU , "andrew.qu@mediatek.com" 
Thread-Topic: Comments on draft-contreras-supa-yang-network-topo-00
Thread-Index: Ac/a1N4eoZE/j94BSyOMCGqEXc72jwCKwvTA
Date: Tue, 30 Sep 2014 23:01:29 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: es-ES, en-US
Content-Language: es-ES
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [79.144.77.90]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DB4PR06MB573;
x-forefront-prvs: 0350D7A55D
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(199003)(189002)(108616004)(4396001)(107046002)(97736003)(95666004)(19580405001)(230783001)(31966008)(76576001)(33646002)(19580395003)(86362001)(105586002)(20776003)(85852003)(101416001)(19617315012)(76482002)(66066001)(92566001)(16236675004)(76176999)(120916001)(15202345003)(50986999)(46102003)(54356999)(19625215002)(106356001)(80022003)(10300001)(15975445006)(85306004)(2501002)(99396003)(87936001)(2656002)(19300405004)(74316001)(21056001)(64706001)(24736002)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR06MB573; H:DB4PR06MB576.eurprd06.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
Content-Type: multipart/alternative; boundary="_000_a4d34e9cc6e84a5881915ff9a4f93eb1DB4PR06MB576eurprd06pro_"
MIME-Version: 1.0
X-OriginatorOrg: telefonica.com
X-TM-AS-MML: No
Archived-At: http://mailarchive.ietf.org/arch/msg/supa/yImg3-MW-buS7epYOJZzXQ-Rx-4
Cc: "supa@ietf.org" 
Subject: Re: [Supa] Comments on draft-contreras-supa-yang-network-topo-00
X-BeenThere: supa@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Sep 2014 23:02:45 -0000
X-List-Received-Date: Tue, 30 Sep 2014 23:02:45 -0000

--_000_a4d34e9cc6e84a5881915ff9a4f93eb1DB4PR06MB576eurprd06pro_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Hi Tina,

Thanks for your comments. Please, see my answers in-line.

De: Supa [mailto:supa-bounces@ietf.org] En nombre de Tina TSOU
Enviado el: domingo, 28 de septiembre de 2014 6:30
Para: LUIS MIGUEL CONTRERAS MURILLO; andrew.qu@mediatek.com
CC: supa@ietf.org
Asunto: [Supa] Comments on draft-contreras-supa-yang-network-topo-00

Dear Luis, Andrew et al,

Thank you for writing such a concrete model.

I read draft-contreras-supa-yang-network-topo-00. It is well written. Below a=
re some comments.

The basic idea of this draft is very good, and I can understand what the au=
thor tries to say. However still, more clarification is needed especially f=
or some definitions.

1.         In section 4.2, there are =E2=80=9Cvirtual node=E2=80=9D and =E2=
=80=9Ccontainer node=E2=80=9D, what is difference between these two kinds o=
f nodes? For the virtual node, it is more understandable that it is the vir=
tualization of the physical node or nodes. But for the container node, it c=
an be a group of nodes or only one node. What is the necessity to define su=
ch a container node, is it domain specific or a general idea for all the us=
e cases?
[Luis>>] As you point out a virtual node can represent an slice of a physic=
al node. On the other hand, the container node represents a grouping of sev=
eral other nodes that can be observed as a one consolidated node from a top=
ology perspective. I would say that it is a general idea that can be applic=
able to some use case.



2.         Would you elaborate one use case for the container node? In orde=
r to demonstrate the insufficiency of virtual node to cover the application=
 or use cases, show one use case that the container node idea is necessary.
[Luis>>] From my understanding the idea of a container node can be useful f=
or representing some scenarios. I have mentioned in some previous mail an e=
xample of a rented infrastructure let=E2=80=99s say for mobile backhaul. Th=
e service provider which rents the infrastructure will handle a detailed to=
pology of the physical infrastructure but it could expose a simplified topo=
logy to the service provider which is renting such capacity. Other example =
could be for instance the internals of a data center. You could consider fo=
r example all the DC environment as a container node connecting a virtual m=
achine to a border router, hiding the complexity of the internal topology o=
f the DC, that could not be required to be known from the service perspecti=
ve for that VM. Let me know if these examples make sense to you.


3.      In section 4.2, there is also some external links or nodes definiti=
on, what is the purpose for that? Are they external for the user or the up =
level controller?

[Luis>>] The external links or nodes represent objects connected to the top=
ology but not controlled by the controller. They are required to provide co=
nsistent definition to some topologies (I=E2=80=99m thinking for instance i=
n VPNs). Probably the text has to be refined for a better explanation of th=
at.


4.       In first figure of section 4
                  +-------------------------+
                  |                         |
                  |       topology          |
                  |                         |
                  +-+-+----+---------+--+-+-+
                    | |    |         |  | |
                    | |    |         |  | |
                    | |    |         |  | |
                    | |    |         |  | |
      +------------+ |    |         |  | |
       |              |    |         |  | +------------------+
       |        +-----+    |         |  +--------+           |
       |        |          |         +-+         |           |
       |        |          |           |         |           |
    +--+---+ +--+---+ +----+------++---+---+ +---+---+ +-----+-----+
    |link  | |node  | |termination||extLink| |extNode| |extTerminat|
    +------+ +------+ |Point      |+-------+ +-------+ |ionPoint   |
                      +-----------+                    +-----------+

How can the unified topology be mapped into different applications or users=
? I guess you need to map this topology, if this is the only one topology, =
to different applications in order to make it work.


[Luis>>] Not sure if I understand correctly the question. The topology will=
 have different views according to the users or applications. Each view sho=
uld provide the elements needed for comprehensively representing the servic=
e for each user or application. Nor sure if this answers the question. Plea=
se, let me know if not.
Thank you,
Tina


________________________________

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

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

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=C3=A1=
rio, pode conter informa=C3=A7=C3=A3o privilegiada ou confidencial e =C3=A9=
 para uso exclusivo da pessoa ou entidade de destino. Se n=C3=A3o =C3=A9 vo=
ssa senhoria o destinat=C3=A1rio indicado, fica notificado de que a leitura=
, utiliza=C3=A7=C3=A3o, divulga=C3=A7=C3=A3o e/ou c=C3=B3pia sem autoriza=
=C3=A7=C3=A3o pode estar proibida em virtude da legisla=C3=A7=C3=A3o vigent=
e. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imedi=
atamente por esta mesma via e proceda a sua destrui=C3=A7=C3=A3o

--_000_a4d34e9cc6e84a5881915ff9a4f93eb1DB4PR06MB576eurprd06pro_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable











Hi Tina,


 


Thanks for your comments.
Please, see my answer=
s in-line.


=
 






De: Supa [mailto:supa-bo=
unces@ietf.org]
En nombre de Tina TSOU

Enviado el: domingo, 28 de septiembre de 2014 6:30

Para: LUIS MIGUEL CONTRERAS MURILLO; andrew.qu@mediatek.com

CC: supa@ietf.org

Asunto: [Supa] Comments on draft-contreras-supa-yang-network-topo-00=







 =



Dear Luis, Andrew et al,


 


Thank you for writing such a concrete model.


 


I read
draft-contreras-supa-=
yang-network-topo-00.
It is we=
ll written. Below are some comments.


 


The basic idea of this draft is very good, and I can understand wha=
t the author tries to say. However still, more clarification is needed espe=
cially for some definitions.



1.        
In section 4.2, there are =E2=80=9Cvirtual node=E2=80=9D an=
d =E2=80=9Ccontainer node=E2=80=9D, what is difference between these two ki=
nds of nodes? For the virtual node, it is more understandable that
 it is the virtualization of the physical node or nodes. But for the contai=
ner node, it can be a group of nodes or only one node. What is the necessit=
y to define such a container node, is it domain specific or a general idea =
for all the use cases?


[Luis>>] As you point out a virtual node =
can represent an slice of a physical node. On the other hand, the container=
 node represents a grouping of several other
 nodes that can be observed as a one consolidated node from a topology pers=
pective. I would say that it is a general idea that can be applicable to so=
me use case.



=
 



2.        
Would you elaborate one use case for the container node? In=
 order to demonstrate the insufficiency of virtual node to cover the applic=
ation or use cases, show one use case
 that the container node idea is necessary.


[Luis>>] From my understanding the idea o=
f a container node can be useful for representing some scenarios. I have me=
ntioned in some previous mail an example of
 a rented infrastructure let=E2=80=99s say for mobile backhaul. The service=
 provider which rents the infrastructure will handle a detailed topology of=
 the physical infrastructure but it could expose a simplified topology to t=
he service provider which is renting such
 capacity. Other example could be for instance the internals of a data cent=
er. You could consider for example all the DC environment as a container no=
de connecting a virtual machine to a border router, hiding the complexity o=
f the internal topology of the DC,
 that could not be required to be known from the service perspective for th=
at VM. Let me know if these examples make sense to you.<=
/o:p>


=
 


3.      In section 4.2, there is also some=
 external links or nodes definition, what is the purpose for that? Are they=
 external for the user or the up level controller?


 


[Luis>>] The external links or nodes repr=
esent objects connected to the topology but not controlled by the controlle=
r. They are required to provide consistent
 definition to some topologies (I=E2=80=99m thinking for instance in VPNs).=
 Probably the text has to be refined for a better explanation of that.


 



4.      
In first figure of section 4


       &nbs=
p;          +-------------=
------------+


       &nbs=
p;          |   =
;            &n=
bsp;         |

       &nbs=
p;          |   =
;    topology        =
;  |


       &nbs=
p;          |   =
;            &n=
bsp;         |

       &nbs=
p;          +-+-+-=
---+---------+--+-+-+


       &nbs=
p;            | |&nb=
sp;   |         |  |=
 |


       &nbs=
p;            | |&nb=
sp;   |         |  |=
 |


       &nbs=
p;            | |&nb=
sp;   |         |  |=
 |


       &nbs=
p;            | |&nb=
sp;   |         |  |=
 |


      +-----=
-------+ |    |       =
;  |  | |


       | &n=
bsp;            |&nb=
sp;   |         |  |=
 +------------------+


       | &n=
bsp;      +-----+    | =
;        |  +--------+ =
;          |=



       | &n=
bsp;      |      &nb=
sp;   |         +-=
3;         |    =
;       |


       | &n=
bsp;      |       &n=
bsp;  |         &nbs=
p; |         |   &nb=
sp;       |


    +--+---+ +-=
-+---+ +----+------++---+---+ +---+=
---+ +-----+-----+


    |link  | |node  |=
 |termination||extLink| |extNode| |extTerminat|


    +------+ +-----=
-+ |Point      |+-------+ +-------=
+ |ionPoint   |


       &nbs=
p;             =
 +-----------+        =
            +---=
--------+


 


How can the unified topology be mapped into different applications =
or users? I guess you need to map this topology, if this is the only one to=
pology, to different applications in
 order to make it work.  


 


 


[Luis>>] Not sure if I understand correct=
ly the question. The topology will have different views according to the us=
ers or applications. Each view should provide
 the elements needed for comprehensively representing the service for each =
user or application. Nor sure if this answers the question. Please, let me =
know if not.


Thank you,


Tina


 









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



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



Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=C3=A1=
rio, pode conter informa=C3=A7=C3=A3o privilegiada ou confidencial e =C3=A9=
 para uso exclusivo da pessoa ou entidade de destino. Se n=C3=A3o =C3=A9 vo=
ssa senhoria o destinat=C3=A1rio indicado, fica notificado de que a
 leitura, utiliza=C3=A7=C3=A3o, divulga=C3=A7=C3=A3o e/ou c=C3=B3pia sem au=
toriza=C3=A7=C3=A3o pode estar proibida em virtude da legisla=C3=A7=C3=A3o =
vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique=
 imediatamente por esta mesma via e proceda a sua destrui=C3=A7=C3=A3o





--_000_a4d34e9cc6e84a5881915ff9a4f93eb1DB4PR06MB576eurprd06pro_--


From nobody Tue Sep 30 23:05:21 2014
Return-Path: 
X-Original-To: supa@ietfa.amsl.com
Delivered-To: supa@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D0571A015F for ; Tue, 30 Sep 2014 23:05:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.336
X-Spam-Level: 
X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.786] 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 9cfFDtD2u5H9 for ; Tue, 30 Sep 2014 23:05:18 -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 040531A006A for ; Tue, 30 Sep 2014 23:05:18 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 0D570F99; Wed,  1 Oct 2014 08:05:16 +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 vm7UgeZTRvOV; Wed,  1 Oct 2014 08:05:15 +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,  1 Oct 2014 08:05:15 +0200 (CEST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id A434120036; Wed,  1 Oct 2014 08:05:15 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id H9ljmborg1pS; Wed,  1 Oct 2014 08:05:14 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3854720035; Wed,  1 Oct 2014 08:05:13 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 6CA542EBD2A3; Wed,  1 Oct 2014 08:05:12 +0200 (CEST)
Date: Wed, 1 Oct 2014 08:05:11 +0200
From: Juergen Schoenwaelder 
To: LUIS MIGUEL CONTRERAS MURILLO 
Message-ID: <20141001060510.GA36781@elstar.local>
Mail-Followup-To: LUIS MIGUEL CONTRERAS MURILLO ,  Tina TSOU , "andrew.qu@mediatek.com" , "supa@ietf.org" 
References:  
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
User-Agent: Mutt/1.4.2.3i
Archived-At: http://mailarchive.ietf.org/arch/msg/supa/aKUhqoOkzrbmUUiS85fZhHue5bg
Cc: "andrew.qu@mediatek.com" , "supa@ietf.org" , Tina TSOU 
Subject: Re: [Supa] Comments on draft-contreras-supa-yang-network-topo-00
X-BeenThere: supa@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 01 Oct 2014 06:05:20 -0000

On Tue, Sep 30, 2014 at 11:01:29PM +0000, LUIS MIGUEL CONTRERAS MURILLO wrote:
> 
> 3.      In section 4.2, there is also some external links or nodes definition, what is the purpose for that? Are they external for the user or the up level controller?
> 
> [Luis>>] The external links or nodes represent objects connected to the topology but not controlled by the controller. They are required to provide consistent definition to some topologies (I’m thinking for instance in VPNs). Probably the text has to be refined for a better explanation of that.
> 

This approach may not be very suitable if there are multiple
controller since then you have to maintain N different topology
models. It may be more scalable to have one topology and instead tag
nodes and links as needed (if exposure of controller domains is needed
at all).

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103