The goal is to achieve interoperation between different hardware and software implementations on the different aspects addressed by 6lo, 6TiSCH and ROLL WGs. This include 6TiSCH minimal draft implementation, demonstrating TSCH synchronization and OF0 for RPL on a minimal network. 6lowpan to demostrate cross link layer inter-operability by means of bridges or backbones routers. Storing and non-storing RPL implementation including its coexistance in different sub-networks. The focus during this event is open to demonstrating 6lo, ROLL or 6TiSCH drafts implementations, including but not limited to: e.g. - 6TiSCH minimal draft: http://tools.ietf.org/html/draft-ietf-6tisch-minimal-00. - TBD Participants are encouraged to bring devices which implement parts or all of the listed drafts. Levels of interoperation are proposed: - *Level 1*, star topology. A single BBR devices acts as the time source neighbor for all other nodes. Nodes need to demonstrate frame-based and acknowledgement-based synchronization. The static TSCH schedule, as well as all slot timings are taken from draft-ietf-6tisch-minimal-00. - *Level 2*, multi-hop topology. This level builds upon level 1. The goal of this level is full compliance to draft-ietf-6tisch-minimal-00, including multi-hop routing (RPL). - *Level 3*, on-the-fly scheduling. [optional] Preliminary implementations of http://tools.ietf.org/html/draft-dujovne-6tisch-on-the-fly can be shown. - *Level 4*, drafts from ROLL, such as: draft-ietf-roll-mpl-parameter-configuration, draft-ko-roll-mix-network-pathology, Opportunistic routing, selective DIS, and others that participants want to show - *Level 5*, drafts from 6lo, such as: draft-ietf-6lo-btle, draft-ietf-6lo-ghc,draft-ietf-6lo-lowpanz, and others that participants want to show. - *Level 6* Other drafts, such as draft-thubert-6man-flow-label-for-rpl, etc. Focus 2: Demonstration Participants are encouraged to bring devices and technology based on 6TiSCH, 6lo and ROLL which they believe can be of interest for the other participants. These devices may or may not participate in the interoperation event. Demonstration of more complete systems are encouraged, for example systems which show the interconnection of a 6TiSCH based mesh to traditional networks. Focus 3: Tools Participants are encouraged to bring and present different tools developed around 6TiSCH/6lo/ROLL networks. Possible tools include, but are not limited to: - acquisition devices (i.e. "sniffers") - packet analysis tools (e.g. Wireshark) - simulation/emulation platforms Important Dates The preparation of this event will be held during a portion of the bi-weekly 6TiSCH call (*To Be Decided how and when!!!*). In particular: - *06/02/2014* Announcement of the plugfest event to the WG/ML related with constrained devices, such as: 6tisch, 6lo, roll, core, lwig, dtls-iot, coman, ace, etc. - *06/06/2014* Adoption of the plugfest call by the WGs, and call for participants at each group. - *06/02/2014-06/13/2014* Participants have contacted the plugfest chairs (Xavier or Ines) with a tentative description of what they wish to participate in. - *06/20/2014* Synchronization point 1. Participants can share the state of advancement of the implementation and raise blocking points. - *07/11/2014* Synchronization point 2. Participants can share the state of advancement of the implementation and raise blocking points. - *07/20/2014*. Plugfest at IETF90. Tentative Agenda from 9:00 to 13:00 - *[09.00]* Welcome and Initial Instructions - *[09.05]* Participants Pitch (5 min per Participant) - *[09.45]* Participants Pitch Tools (5 min per Participant) - *[10.15]* Interoperation (Islands) - *[11.50]* Feedback and open discussion. - *[12.40]* Acknowledgements and Plugfest End For More Information - *Contact*: Xavi Vilajosana xvilajosana@eecs.berkeley.edu - Ines Robles mariainesrobles@gmail.com Note Well This event is organized as part of the IETF90 standardization meeting. You need to register to the IETF90 conference to be able to participate. Daily passes are available. The IETF Note Well applies to this plugfest, see http://www.ietf.org/about/note-well.html. About The IETF 6TiSCH working group standardizes mechanisms focusing on enabling IPv6 over the TSCH mode of the IEEE802.15.4e standard. You can access the charter at http://datatracker.ietf.org/wg/6tisch/charter/, which also contains links to the mailing list and the Internet-Drafts published by the group. 6TiSCH holds weekly phone calls on Friday 8am PST. Participation is open, and is subject to the IETF Note Well. The IETF 6lo working group focuses on the work that facilitates IPv6 connectivity over constrained node networks with the characteristics of: limited power, memory and processing resources;. You can access the charter at https://datatracker.ietf.org/wg/6lo/charter/, which also contains links to the mailing list and the I-D published by the group. The IETF ROLL working group is focused on routing issues for LLN (Low Power and Lossy Networks), in IPv6 routing architectural framework for the industrial, connected home, building and urban sensor networks application scenarios. You can access the charter at https://datatracker.ietf.org/wg/roll/charter/, which also contains links to the mailing list and the I-D published by the group. --047d7b3a9b742ce9d904facd703b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Dear all,

We would like to announce the plugfest event at the 90th IETF Meeti= ng in Toronto.

We call for participants. The deadli= ne to receive topics to present or demonstrate in the event is 06/13/2014. = Interested audience is also welcome and we encourage audience to participat= e in the feedback session.

<= font face=3D"arial, helvetica, sans-serif">Please find next the plugfest in= formation.=C2=A0

We hope= to see you there!

Xavier and Ines.

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

Low Power and Lossy Networks plugfest at IETF90

The=C2=A0IETF 6TiSCH,=C2=A0IETF 6lo=C2=A0and=C2=A0IETF ROLL=C2=A0working g= roups are hosting an informal "plugfest" event at the IETF90 meet= ing, in Toronto, CA, during the week of July 20-25 2014.

Goals=

When and where ?

Date: Sunday July 20 20= 14, 0900-1300 EDT.
Location<= /strong>: Meeting Room TBD, Fairmont Royal York Hotel 100 Front Street W, T= oronto, CA.

Topol= ogy proposed - TBD

Star topology
IPv6

Complementary angles

This event will feature the following complementary a= ngles:

= Interoperation
Demonstration
Tools
Focus 1: Interoperation

Dow= nload the interoperation guidelines:

- TBD for Toronto - interoperation guidelines, version 1 (Lon= don)

The= focus during this event is open to demonstrating 6lo, ROLL or 6TiSCH draft= s implementations, including but not limited to: e.g. - 6TiSCH minimal draf= t:=C2=A0http://tools.ietf.org/html/draft-ietf-6tisch-minimal-00. = - TBD

Par= ticipants are encouraged to bring devices which implement parts or all of t= he listed drafts.

Lev= els of interoperation are proposed:

Level 1, star topology.= A single BBR devices acts as the time source neighbor for all other nodes.= Nodes need to demonstrate frame-based and acknowledgement-based synchroniz= ation. The static TSCH schedule, as well as all slot timings are taken from= draft-ietf-6tisch-minimal-00.

Level 2, multi-hop topo= logy. This level builds upon level 1. The goal of this level is full compli= ance to draft-ietf-6tisch-minimal-00, including multi-hop routing (RPL).
Level 3, on-the-fly sch= eduling. [optional] Preliminary implementations of=C2=A0http://to= ols.ietf.org/html/draft-dujovne-6tisch-on-the-fly=C2=A0can be shown.
Level 4, drafts from RO= LL, such as: draft-ietf-roll-mpl-parameter-configuration, draft-ko-roll-mix= -network-pathology, Opportunistic routing, selective DIS, and others that p= articipants want to show

Level 5, drafts from 6l= o, such as: draft-ietf-6lo-btle, draft-ietf-6lo-ghc,draft-ietf-6lo-lowpanz,= and others that participants want to show.
Level 6=C2=A0Other drafts, such as draft-thubert-6man-flow= -label-for-rpl, etc.
Focus 2: Demonstration
Participants are encouraged to bring devices and te= chnology based on 6TiSCH, 6lo and ROLL which they believe can be of interes= t for the other participants. These devices may or may not participate in t= he interoperation event. Demonstration of more complete systems are encoura= ged, for example systems which show the interconnection of a 6TiSCH based m= esh to traditional networks.

Focus= 3: Tools
Participants are encouraged to bring and present different tools developed = around 6TiSCH/6lo/ROLL networks. Possible tools include, but are not limite= d to:

acquisition devices (i.e. "sniffers= ")
packet analysis tools (e.g. = Wireshark)
simulation/emulation plat= forms

= Important Dates
The preparation of this event will be held during a portion of the bi-weekl= y 6TiSCH call (To Be Decided how and when!!!). In particul= ar:

06/02/2014=C2=A0Announc= ement of the plugfest event to the WG/ML related with constrained devices, = such as: 6tisch, 6lo, roll, core, lwig, dtls-iot, coman, ace, etc.
06/06/2014=C2=A0Adoption of the plugfest call by the WGs, = and call for participants at each group.
06/02/2014-06/13/2014=C2=A0Participants have contacte= d the plugfest chairs (Xavier or Ines) with a tentative description of what= they wish to participate in.

06/20/2014=C2=A0Synchro= nization point 1. Participants can share the state of advancement of the im= plementation and raise blocking points.
07/11/2014=C2=A0Synchronization point 2. Participants can = share the state of advancement of the implementation and raise blocking poi= nts.

07/20/2014. Plugfest at= IETF90.
Tentative Agenda from 9:00 to 13:00
[09.00]=C2=A0Welcome and I= nitial Instructions

[09.05]=C2=A0Participants Pitch= (5 min per Participant)
[09.45]= =C2=A0Participants Pitch Tools (5 min per Participant)
[10.15]=C2=A0Interoperation (Islands)
[11.50]=C2=A0Feedback and open discussion.
[12.40]=C2=A0Acknowledgements and Plugf= est End

For M= ore Information

Contact: Xavi Vilajosan= a=C2=A0xvilajosana@eecs.berkel= ey.edu=C2=A0- Ines Robles=C2=A0mariainesrobles@gmail.com

= Note Well
This event is organized as part of the IETF90 standardization meeting. You = need to register to the IETF90 conference to be able to participate. Daily = passes are available. The IETF Note Well applies to this plugfest, see=C2= =A0http:/= /www.ietf.org/about/note-well.html.

About=
http://datatracker.ietf.org/wg/6tisch/charter/, which also = contains links to the mailing list and the Internet-Drafts published by the= group. 6TiSCH holds weekly phone calls on Friday 8am PST. Participation is= open, and is subject to the IETF Note Well.

The= IETF 6lo working group focuses on the work that facilitates IPv6 connectiv= ity over constrained node networks with the characteristics of: limited pow= er, memory and processing resources;. You can access the charter at=C2=A0https:/= /datatracker.ietf.org/wg/6lo/charter/, which also contains links to the= mailing list and the I-D published by the group.

The= IETF ROLL working group is focused on routing issues for LLN (Low Power an= d Lossy Networks), in IPv6 routing architectural framework for the industri= al, connected home, building and urban sensor networks application scenario= s. You can access the charter at=C2=A0https://datatracker.ietf.org/wg/roll/char= ter/, which also contains links to the mailing list and the I-D publish= ed by the group.

--047d7b3a9b742ce9d904facd703b-- From nobody Tue Jun 3 02:57:46 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E9B41A00D7; Tue, 3 Jun 2014 02:57:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.363 X-Spam-Level: X-Spam-Status: No, score=-7.363 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_CHARSET_FARAWAY=2.45, RP_MATCHES_RCVD=-0.651, 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 ErBaK7-iO0I6; Tue, 3 Jun 2014 02:57:35 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3C091A00C0; Tue, 3 Jun 2014 02:57:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3938; q=dns/txt; s=iport; t=1401789449; x=1402999049; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=81DHEIPP3/o6Fd2zUAn1D5xckOWoAtueGbjc283e8xE=; b=hFOTs9gtjPo9TB2Fd2b2JCp2m0cyM6jI5VkzwMs/vTV79qMjJB7RGdGS xIR8bctH1Y0LF6lab0LfmOteKBfeFQScqev/H7oUZjYtt7321E6cR+MIY k3PAbaXGrxY3A2QCN6AXJNnYXxJMgR/KfsvVGnHbkn1RXaE0t4B6K20o5 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqUEAAqbjVOtJssW/2dsb2JhbABZg1mDRLg4hzkBgSJ0giUBAQEEAQEBLwE7CgEQCQIYBAUWCAUCCQMCAQIBFR8RBgEMAQUCAQEXiCcNkHKcGgikPxeBJoxKCgcBAk4HgnGBTwEDiXKQEYE+hS+MRIM6O4EwCRc X-IronPort-AV: E=Sophos;i="4.98,964,1392163200"; d="scan'208";a="68225005" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 03 Jun 2014 09:57:27 +0000 Received: from [10.60.67.91] (ams-bclaise-89110.cisco.com [10.60.67.91]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s539vRGV026340; Tue, 3 Jun 2014 09:57:27 GMT Message-ID: <538D9C07.8060808@cisco.com> Date: Tue, 03 Jun 2014 11:57:27 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Likepeng , The IESG References: <20140514221215.8150.56543.idtracker@ietfa.amsl.com> <34966E97BE8AD64EAE9D3D6E4DEE36F252B2A345@SZXEMA501-MBS.china.huawei.com> In-Reply-To: <34966E97BE8AD64EAE9D3D6E4DEE36F252B2A345@SZXEMA501-MBS.china.huawei.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/ace/3eBVtq4aLbNh_BtpHSp7raKAPrs Cc: "aaa-doctors@ietf.org" , "ace@ietf.org" Subject: Re: [Ace] Benoit Claise's Block on charter-ietf-ace-00-01: (with BLOCK) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments $ace$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 09:57:37 -0000 On 15/05/2014 23:13, Likepeng wrote: >> What are "resources? It seems they are applications, but the charter doesn't make that clear. > I think I have explained in another thread. Resources are not applications, and the resource concept is taken from HTTP protocol. > > About the "resource", we can take the definition from RFC2616: > > resource > A network data object or service that can be identified by a URI, > as defined in section 3.2. Resources may be available in multiple > representations (e.g. multiple languages, data formats, size, and > resolutions) or vary in other ways. > > For example, resources can be temperature sensors on a data collection node, or a list of alarms on a home security controller. [RFC6690] > > Maybe we can add two explanations: one is that resources can be identified by a URI, two is that resources are hosted on the resource server. > > "Access to a resource" means Get, Put, Post and Delete to a resource. > >> ... >> This working group therefore aims to produce a standardized solution for authentication and authorization to enable authorized access to resources in constrained environments. >> ... > This sentence has been revised to: > > NEW > This working group therefore aims to produce a standardized solution for authentication and authorization to enable authorized access (Get, Put, Post, Delete) to resources identified by a URI and hosted on a resource server in constrained environments. > END That solves the first part of my DISCUSS. Thanks, Benoit > > Hope it clarifies. > > Thanks, > Kind Regards > Kepeng > > -----�ʼ�ԭ��----- > ��: Ace [mailto:ace-bounces@ietf.org] �� Benoit Claise > ��ʱ��: 2014��5��15�� 6:12 > �ռ��: The IESG > ��: aaa-doctors@ietf.org; ace@ietf.org > ��: [Ace] Benoit Claise's Block on charter-ietf-ace-00-01: (with BLOCK) > > Benoit Claise has entered the following ballot position for > charter-ietf-ace-00-01: Block > > When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) > > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/charter-ietf-ace/ > > > > ---------------------------------------------------------------------- > BLOCK: > ---------------------------------------------------------------------- > > Reaction from the AAA-doctors. > > 1. > I haven't been following it in detail, but it does seem rather vague. > > ... > This working group therefore aims to produce a standardized solution for authentication and authorization to enable authorized access to resources in constrained environments. > ... > > What are "resources? It seems they are applications, but the charter doesn't make that clear. Also, if the "constrained environments" are using DTLS, they don't seem that constrained to me. > > It looks to be a slight variation on existing technologies. e.g. we want X, Y and Z, but in situation B instead of A. So... we're going to design something completely new. > > On the other hand, I'm happy to see people paying attention to authentication and authorization. Too many protocols are designed to solve a problem first, and second to add security. > > 2. > The Charter makes a number of assertions that are provably false, such as that AAA protocols are inappropriate for constrained environments. AAA protocols were deployed in the 1990s to support extremely limited NAS devices and Internet hosts with tiny fractions of the power of today's systems. Any device that can run IP can authenticate against a AAA server. > > Let me include the AAA-doctors in the discussion > > > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace From nobody Tue Jun 3 03:16:05 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AF3B1A0190; Tue, 3 Jun 2014 03:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.151 X-Spam-Level: X-Spam-Status: No, score=-10.151 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, RP_MATCHES_RCVD=-0.651, 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 B_cjF9zwhcPt; Tue, 3 Jun 2014 03:15:49 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E41B51A018A; Tue, 3 Jun 2014 03:15:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22757; q=dns/txt; s=iport; t=1401790543; x=1403000143; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=EvoJGFAQI4cwAJbsdekSCjx2AqbC0UzYXj8juk/WoIo=; b=Nwzfx0ASDQqkQN9DggVCp4STrgCLMfLwueMnPMw+DZs3nqbyYcY55KVZ lQojR/Djjb45/BE5j2PkgWj9Yrd6SHoZ/EtnNrdwpwAUGsspc1ZI9J3/x zE9HOEbC2cmwwM6Qf9ueSDocksyijRn9BELAMUhRkh8+1MKmum6V8h9iS U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtQEAHafjVOtJssW/2dsb2JhbABPCoJCgReDRL9xAYEjdIIlAQEBAwEjRA0EAQULCxIPDAoLAgIJAwIBAgE3DgYBDAEHAQEXiB8IrSGkQReNcAYEBwECTgcKgmuBSwEDmgOGbYxEgzo7gTAJFwIC X-IronPort-AV: E=Sophos; i="4.98,964,1392163200"; d="scan'208,217"; a="72347055" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 03 Jun 2014 10:15:39 +0000 Received: from [10.60.67.91] (ams-bclaise-89110.cisco.com [10.60.67.91]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s53AFd7p013940; Tue, 3 Jun 2014 10:15:39 GMT Message-ID: <538DA047.7080902@cisco.com> Date: Tue, 03 Jun 2014 12:15:35 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Likepeng , Kathleen Moriarty , "adrian@olddog.co.uk" References: <20140514221215.8150.56543.idtracker@ietfa.amsl.com> <34966E97BE8AD64EAE9D3D6E4DEE36F252B2A345@SZXEMA501-MBS.china.huawei.com> <34966E97BE8AD64EAE9D3D6E4DEE36F252B38978@SZXEMA501-MBS.china.huawei.com> <34966E97BE8AD64EAE9D3D6E4DEE36F258140E59@SZXEMA501-MBX.china.huawei.com> In-Reply-To: <34966E97BE8AD64EAE9D3D6E4DEE36F258140E59@SZXEMA501-MBX.china.huawei.com> Content-Type: multipart/alternative; boundary="------------050604020100090501070105" Archived-At: http://mailarchive.ietf.org/arch/msg/ace/1Icgxj8kBAPZ0yXpfmcP9G9tjso Cc: "aaa-doctors@ietf.org" , The IESG , "ace@ietf.org" Subject: Re: [Ace] Revised charter proposal: charter-ietf-ace-00-02 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments $ace$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 10:15:52 -0000 This is a multi-part message in MIME format. --------------050604020100090501070105 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi, > Hello all, > > Based on recent discussions, I made a revised charter proposal, as included in this email, not on the webpage yet. > > Please take a look and let us know if you have any further comments. > > @Adrian and @Benoit, please check if the proposed texts can resolve your comments. > > Thanks, > Kind Regards > Kepeng > > ------------------------------------------------------------------------------------------------------------------------------------------------------------- > Compared with charter-ietf-ace-00-01 on the webpage, the changes are: > > (1) Add one clarification sentence about REST architecture: > OLD > The IETF has recently developed protocols for use in constrained > environments, where network nodes are limited in CPU, memory and power. > REST architecture is widely used for such constrained environments. > > NEW > The IETF has recently developed protocols for use in constrained > environments, where network nodes are limited in CPU, memory and power. > REST architecture is widely used for such constrained environments. > END Considering that OLD is OLD The IETF has recently developed protocols for use in constrained environments, where network nodes are limited in CPU, memory and power. ... fine with me > > (2) Remove “AAA protocol” from the charter: > OLD > The IETF has a long history in developing three-party authentication and > authorization protocols for distributed environments. Examples include > Kerberos, the Public Key Infrastructure (PKI), the Authentication, > Authorization and Accounting (AAA) infrastructure, and the Web > Authorization Protocol (OAuth). > > NEW > The IETF has a long history in developing three-party authentication and > authorization protocols for distributed environments. Examples include > Kerberos, the Public Key Infrastructure (PKI), and the Web Authorization Protocol (OAuth). > END We have AAA-doctors telling: maybe RADIUS is applicable? Personally, I don't know and it doesn't matter at this point. We received feedback such as: Let's be clear here: It was never said (in the charter or anywhere else in the group to my knowledge) that RADIUS (or indeed any other AAA protocol) would not run on constrained devices (RFC 7228). The charter simply said the protocols were not optimised for constrained devices. That does not preclude considering any protocol for suitability for constrained devices either a) as is, b) in a restricted way or c) in an adapted way. So, at this stage, I don't think any protocols should be excluded from consideration and should certainly not be eliminated on a hunch that they might be "too big". Let's do the assessment properly at the appropriate time. As a reminder - the focus now is to complete the charter. Or >>The Charter makes a number of assertions that are provably false, such as that AAA protocols are inappropriate for constrained environments. In fact, the charter does not say that. But to avoid confusion, let's remove AAA protocol from the charter. In the charter, we mentioned that we want to reuse existing authentication and authorization protocols where applicable to build the constrained-environment solution. ... which I read as: let's consider the AAA protocols, and evaluate if they would work in constrained devices. I don't understand the logic: why do you want to remove AAA from the charter? Not only would I keep "AAA", but I would propose OLD: Existing authentication and authorization protocols will be used where applicable to build the constrained-environment solution NEW: Existing authentication and authorization protocols will be evaluated and re-used where applicable to build the constrained-environment solution Regards, Benoit > > (3) Clarify the scope: > OLD: > Note that the initial focus is on CoAP and HTTP with DTLS and TLS. > Other security protocols may be considered as long as the primary focus is maintained. > Other application protocols and protocols at other layers in the stack are out of scope. > > NEW > Note that the initial focus is on CoAP and HTTP with DTLS and TLS. > Other security protocols may be considered as long as the primary focus is maintained. > The group is scoped to work only on the web protocols and data carried within them. > END > > (4) Update milestones for the use case & requirements document: > OLD: > Jul 2015 Submit “Use cases and Requirements” document to IESG for publication as informational RFC. > > NEW > Dec 2014 Optionally, submit "Use cases and Requirements" document to the IESG for publication as an Informational RFC. > END > > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > Charter charter-ietf-ace-00-02 > Authentication and Authorization for Constrained > Environment (ACE) > > The IETF has recently developed protocols for use in constrained > environments, where network nodes are limited in CPU, memory and power. > REST architecture is widely used for such constrained environments. > It has been observed that Internet protocols can be applied to these > constrained environments, often only requiring minor tweaking and > profiling. In other cases, new protocols have been defined to address > the specific requirements of constrained environments. An example of > such a protocol is the Constrained Application Protocol (CoAP). > > As in other environments, authentication and authorization questions > also arise in constrained environments. For example, a door lock has to > authorize the person seeking access using a "digital key". Where is the > authorization policy stored? How does the digital key communicate with > the lock? Does the lock interact with an authorization server to obtain > authorization information? How can access be temporarily granted to > other persons? How can access be revoked? These types of questions have > been answered by existing protocols for use cases outside constrained > environments, however in constrained environments, additional and > different requirements pose challenges for the use of various security > protocols. In particular, the need arises for a dynamic and fine grained > access control mechanism, where clients and/or resource servers are > constrained. > > The IETF has a long history in developing three-party authentication and > authorization protocols for distributed environments. Examples include > Kerberos, the Public Key Infrastructure (PKI), and the Web > Authorization Protocol (OAuth). All these protocols enjoy widespread > deployment on the Internet. Although they all aim to solve a similar > goal, at an abstract level, they offer quite different functions and > utilize different message exchanges. These differences result from the > main deployment use cases they were designed for respectively. > > Requirements derived from use cases indicate the suitability of existing > work as a solution for constrained environments. These protocols, > however, were not optimized for constrained environments. Additional > requirements that need to be taken into account are the lack of a > suitable user-interface and the inability of embedded devices to contact > an authorization server in real-time with every resource access request > due to intermittent connectivity, etc. > > This working group therefore aims to produce a standardized solution for > authentication and authorization to enable authorized access (GET, PUT, POST, > DELETE) to resources identified by a URI and hosted on a resource > server in constrained environments. As a starting point, the working > group will assume that access to resources at a resource server by a > client device takes place using CoAP and is protected by DTLS. Both > resource server and client may be constrained. This access will be > mediated by an authorization server, which is not considered to be > constrained. > > Existing authentication and authorization protocols will be used where > applicable to build the constrained-environment solution. This requires > relevant specifications to be reviewed for suitability, selecting a > subset of them and restricting the options within each of the > specifications. Some functionality, however, may not be available in > existing protocols, in which case the solution may also involve new > protocol work. Leveraging existing work means the working group benefits > from available security analysis, implementation, and deployment > experience. Moreover, a standardized solution for federated > authentication and authorization will help to stimulate the deployment > of constrained devices that provide increased security. > > Once progress in identifying suitable candidate solutions has been made, > the working group will verify whether the same mechanisms are also > applicable beyond the use of CoAP and DTLS, which are the two main > protocols the group will focus on for access to resources. In > particular, the ability to use the developed solution over HTTP and TLS > will be investigated. Note that the initial focus is on CoAP and HTTP with DTLS and TLS. > Other security protocols may be considered as long as the primary focus is maintained. > The group is scoped to work only on the web protocols and data carried within them. > Furthermore, to guarantee smooth transition, the > integration with existing deployments will be studied, particularly > concerning the use of protocol translation proxies. > > This work does not make the assumption that the party offering > application layer services is always the same party offering network > access services. > > The working group has the following tasks: > > 1) Produce use cases and requirements > > 2) Identify authentication and authorization mechanisms suitable for > resource access in constrained environments. > > Milestones: > > Jul 2014 Submit "Use cases and Requirements" as a WG item. > Dec 2014 Submit "Authentication and Authorization Solution" as a WG item. > Dec 2014 Optionally, submit "Use cases and Requirements" document > to the IESG for publication as an Informational RFC. > Jul 2016 Submit "Authentication and Authorization Solution" > specification to the IESG for publication as a Proposed Standard. > > Proposed Milestones > No milestones for charter found. --------------050604020100090501070105 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Hi,

Hello all, Based on recent discussions, I made a revised charter proposal, as included in this email, not on the webpage yet. Please take a look and let us know if you have any further comments. @Adrian and @Benoit, please check if the proposed texts can resolve your comments. Thanks, Kind Regards Kepeng ------------------------------------------------------------------------------------------------------------------------------------------------------------- Compared with charter-ietf-ace-00-01 on the webpage, the changes are: (1) Add one clarification sentence about REST architecture: OLD The IETF has recently developed protocols for use in constrained environments, where network nodes are limited in CPU, memory and power. REST architecture is widely used for such constrained environments. NEW The IETF has recently developed protocols for use in constrained environments, where network nodes are limited in CPU, memory and power. REST architecture is widely used for such constrained environments. END

Considering that OLD is

OLD

The IETF has recently developed protocols for use in constrained

environments, where network nodes are limited in CPU, memory and power.

... fine with me

(2) Remove “AAA protocol” from the charter: OLD The IETF has a long history in developing three-party authentication and authorization protocols for distributed environments. Examples include Kerberos, the Public Key Infrastructure (PKI), the Authentication, Authorization and Accounting (AAA) infrastructure, and the Web Authorization Protocol (OAuth). NEW The IETF has a long history in developing three-party authentication and authorization protocols for distributed environments. Examples include Kerberos, the Public Key Infrastructure (PKI), and the Web Authorization Protocol (OAuth). END

We have AAA-doctors telling: maybe RADIUS is applicable?
Personally, I don't know and it doesn't matter at this point.
We received feedback such as:

Let's be clear here: It was never said (in the charter or anywhere else in the group to my knowledge) that RADIUS (or indeed any other AAA protocol) would not run on constrained devices (RFC 7228). The charter simply said the protocols were not optimised for constrained devices. That does not preclude considering any protocol for suitability for constrained devices either a) as is, b) in a restricted way or c) in an adapted way.

So, at this stage, I don't think any protocols should be excluded from consideration and should certainly not be eliminated on a hunch that they might be "too big". Let's do the assessment properly at the appropriate time. As a reminder - the focus now is to complete the charter.
Or

>>The Charter makes a number of assertions that are provably false, such as that AAA protocols are inappropriate for constrained environments.

In fact, the charter does not say that. But to avoid confusion, let's remove AAA protocol from the charter. In the charter, we mentioned that we want to reuse existing authentication and authorization protocols where applicable to build the constrained-environment solution.

... which I read as: let's consider the AAA protocols, and evaluate if they would work in constrained devices.
I don't understand the logic: why do you want to remove AAA from the charter?
Not only would I keep "AAA", but I would propose

OLD:
Existing authentication and authorization protocols will be used where
applicable to build the constrained-environment solution

NEW:
Existing authentication and authorization protocols will be evaluated and re-used where
applicable to build the constrained-environment solution

Regards, Benoit

(3) Clarify the scope: OLD: Note that the initial focus is on CoAP and HTTP with DTLS and TLS. Other security protocols may be considered as long as the primary focus is maintained. Other application protocols and protocols at other layers in the stack are out of scope. NEW Note that the initial focus is on CoAP and HTTP with DTLS and TLS. Other security protocols may be considered as long as the primary focus is maintained. The group is scoped to work only on the web protocols and data carried within them. END (4) Update milestones for the use case & requirements document: OLD: Jul 2015 Submit “Use cases and Requirements” document to IESG for publication as informational RFC. NEW Dec 2014 Optionally, submit "Use cases and Requirements" document to the IESG for publication as an Informational RFC. END ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Charter charter-ietf-ace-00-02 Authentication and Authorization for Constrained Environment (ACE) The IETF has recently developed protocols for use in constrained environments, where network nodes are limited in CPU, memory and power. REST architecture is widely used for such constrained environments. It has been observed that Internet protocols can be applied to these constrained environments, often only requiring minor tweaking and profiling. In other cases, new protocols have been defined to address the specific requirements of constrained environments. An example of such a protocol is the Constrained Application Protocol (CoAP). As in other environments, authentication and authorization questions also arise in constrained environments. For example, a door lock has to authorize the person seeking access using a "digital key". Where is the authorization policy stored? How does the digital key communicate with the lock? Does the lock interact with an authorization server to obtain authorization information? How can access be temporarily granted to other persons? How can access be revoked? These types of questions have been answered by existing protocols for use cases outside constrained environments, however in constrained environments, additional and different requirements pose challenges for the use of various security protocols. In particular, the need arises for a dynamic and fine grained access control mechanism, where clients and/or resource servers are constrained. The IETF has a long history in developing three-party authentication and authorization protocols for distributed environments. Examples include Kerberos, the Public Key Infrastructure (PKI), and the Web Authorization Protocol (OAuth). All these protocols enjoy widespread deployment on the Internet. Although they all aim to solve a similar goal, at an abstract level, they offer quite different functions and utilize different message exchanges. These differences result from the main deployment use cases they were designed for respectively. Requirements derived from use cases indicate the suitability of existing work as a solution for constrained environments. These protocols, however, were not optimized for constrained environments. Additional requirements that need to be taken into account are the lack of a suitable user-interface and the inability of embedded devices to contact an authorization server in real-time with every resource access request due to intermittent connectivity, etc. This working group therefore aims to produce a standardized solution for authentication and authorization to enable authorized access (GET, PUT, POST, DELETE) to resources identified by a URI and hosted on a resource server in constrained environments. As a starting point, the working group will assume that access to resources at a resource server by a client device takes place using CoAP and is protected by DTLS. Both resource server and client may be constrained. This access will be mediated by an authorization server, which is not considered to be constrained. Existing authentication and authorization protocols will be used where applicable to build the constrained-environment solution. This requires relevant specifications to be reviewed for suitability, selecting a subset of them and restricting the options within each of the specifications. Some functionality, however, may not be available in existing protocols, in which case the solution may also involve new protocol work. Leveraging existing work means the working group benefits from available security analysis, implementation, and deployment experience. Moreover, a standardized solution for federated authentication and authorization will help to stimulate the deployment of constrained devices that provide increased security. Once progress in identifying suitable candidate solutions has been made, the working group will verify whether the same mechanisms are also applicable beyond the use of CoAP and DTLS, which are the two main protocols the group will focus on for access to resources. In particular, the ability to use the developed solution over HTTP and TLS will be investigated. Note that the initial focus is on CoAP and HTTP with DTLS and TLS. Other security protocols may be considered as long as the primary focus is maintained. The group is scoped to work only on the web protocols and data carried within them. Furthermore, to guarantee smooth transition, the integration with existing deployments will be studied, particularly concerning the use of protocol translation proxies. This work does not make the assumption that the party offering application layer services is always the same party offering network access services. The working group has the following tasks: 1) Produce use cases and requirements 2) Identify authentication and authorization mechanisms suitable for resource access in constrained environments. Milestones: Jul 2014 Submit "Use cases and Requirements" as a WG item. Dec 2014 Submit "Authentication and Authorization Solution" as a WG item. Dec 2014 Optionally, submit "Use cases and Requirements" document to the IESG for publication as an Informational RFC. Jul 2016 Submit "Authentication and Authorization Solution" specification to the IESG for publication as a Proposed Standard. Proposed Milestones No milestones for charter found.

--------------050604020100090501070105-- From nobody Tue Jun 3 03:32:32 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94DB11A01A7; Tue, 3 Jun 2014 03:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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-aYR8CPQWYk; Tue, 3 Jun 2014 03:32: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 183141A01B1; Tue, 3 Jun 2014 03:32:12 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHU15873; Tue, 03 Jun 2014 10:32:06 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 3 Jun 2014 11:31:16 +0100 Received: from SZXEMA405-HUB.china.huawei.com (10.82.72.37) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 3 Jun 2014 11:32:04 +0100 Received: from SZXEMA501-MBS.china.huawei.com ([169.254.2.214]) by SZXEMA405-HUB.china.huawei.com ([10.82.72.37]) with mapi id 14.03.0158.001; Tue, 3 Jun 2014 18:31:57 +0800 From: Likepeng To: Benoit Claise , Kathleen Moriarty , "adrian@olddog.co.uk" Thread-Topic: Revised charter proposal: charter-ietf-ace-00-02 Thread-Index: AQHPeLrW9teE9ryEO0GmvALEdUzf8JtesfKAgACKjwA= Date: Tue, 3 Jun 2014 10:31:56 +0000 Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F258153F43@SZXEMA501-MBS.china.huawei.com> References: <20140514221215.8150.56543.idtracker@ietfa.amsl.com> <34966E97BE8AD64EAE9D3D6E4DEE36F252B2A345@SZXEMA501-MBS.china.huawei.com> <34966E97BE8AD64EAE9D3D6E4DEE36F252B38978@SZXEMA501-MBS.china.huawei.com> <34966E97BE8AD64EAE9D3D6E4DEE36F258140E59@SZXEMA501-MBX.china.huawei.com> <538DA047.7080902@cisco.com> In-Reply-To: <538DA047.7080902@cisco.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.89.186] Content-Type: multipart/alternative; boundary="_000_34966E97BE8AD64EAE9D3D6E4DEE36F258153F43SZXEMA501MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/ace/A7tzG4eFXM4sqURNp1AM7qfbink Cc: "aaa-doctors@ietf.org" , The IESG , "ace@ietf.org" Subject: Re: [Ace] Revised charter proposal: charter-ietf-ace-00-02 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments $ace$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 10:32:22 -0000 --_000_34966E97BE8AD64EAE9D3D6E4DEE36F258153F43SZXEMA501MBSchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQmVub2l0LA0KDQo+Tm90IG9ubHkgd291bGQgSSBrZWVwICJBQUEiLA0KDQpPSy4NCg0KPmJ1 dCBJIHdvdWxkIHByb3Bvc2UNCg0KPk9MRDoNCj5FeGlzdGluZyBhdXRoZW50aWNhdGlvbiBhbmQg YXV0aG9yaXphdGlvbiBwcm90b2NvbHMgd2lsbCBiZSB1c2VkIHdoZXJlDQphcHBsaWNhYmxlIHRv IGJ1aWxkIHRoZSBjb25zdHJhaW5lZC1lbnZpcm9ubWVudCBzb2x1dGlvbi4NCg0KPk5FVzoNCkV4 aXN0aW5nIGF1dGhlbnRpY2F0aW9uIGFuZCBhdXRob3JpemF0aW9uIHByb3RvY29scyB3aWxsIGJl IGV2YWx1YXRlZCBhbmQgcmUtdXNlZCB3aGVyZQ0KYXBwbGljYWJsZSB0byBidWlsZCB0aGUgY29u c3RyYWluZWQtZW52aXJvbm1lbnQgc29sdXRpb24uDQoNCk9LLCBmaW5lIHdpdGggbWUuDQoNClRo YW5rcyBmb3IgdGhlIGZlZWRiYWNrLg0KDQpLaW5kIFJlZ2FyZHMNCktlcGVuZw0KDQrlj5Hku7bk uro6IEJlbm9pdCBDbGFpc2UgW21haWx0bzpiY2xhaXNlQGNpc2NvLmNvbV0NCuWPkemAgeaXtumX tDogMjAxNOW5tDbmnIgz5pelIDEyOjE2DQrmlLbku7bkuro6IExpa2VwZW5nOyBLYXRobGVlbiBN b3JpYXJ0eTsgYWRyaWFuQG9sZGRvZy5jby51aw0K5oqE6YCBOiBhYWEtZG9jdG9yc0BpZXRmLm9y ZzsgVGhlIElFU0c7IGFjZUBpZXRmLm9yZw0K5Li76aKYOiBSZTogUmV2aXNlZCBjaGFydGVyIHBy b3Bvc2FsOiBjaGFydGVyLWlldGYtYWNlLTAwLTAyDQoNCkhpLA0KDQpIZWxsbyBhbGwsDQoNCg0K DQpCYXNlZCBvbiByZWNlbnQgZGlzY3Vzc2lvbnMsIEkgbWFkZSBhIHJldmlzZWQgY2hhcnRlciBw cm9wb3NhbCwgYXMgaW5jbHVkZWQgaW4gdGhpcyBlbWFpbCwgbm90IG9uIHRoZSB3ZWJwYWdlIHll dC4NCg0KDQoNClBsZWFzZSB0YWtlIGEgbG9vayBhbmQgbGV0IHVzIGtub3cgaWYgeW91IGhhdmUg YW55IGZ1cnRoZXIgY29tbWVudHMuDQoNCg0KDQpAQWRyaWFuIGFuZCBAQmVub2l0LCBwbGVhc2Ug Y2hlY2sgaWYgdGhlIHByb3Bvc2VkIHRleHRzIGNhbiByZXNvbHZlIHlvdXIgY29tbWVudHMuDQoN Cg0KDQpUaGFua3MsDQoNCktpbmQgUmVnYXJkcw0KDQpLZXBlbmcNCg0KDQoNCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KQ29tcGFyZWQgd2l0aCBjaGFydGVy LWlldGYtYWNlLTAwLTAxIG9uIHRoZSB3ZWJwYWdlLCB0aGUgY2hhbmdlcyBhcmU6DQoNCg0KDQoo MSkgICAgICBBZGQgb25lIGNsYXJpZmljYXRpb24gc2VudGVuY2UgYWJvdXQgUkVTVCBhcmNoaXRl Y3R1cmU6DQoNCk9MRA0KDQpUaGUgSUVURiBoYXMgcmVjZW50bHkgZGV2ZWxvcGVkIHByb3RvY29s cyBmb3IgdXNlIGluIGNvbnN0cmFpbmVkDQoNCmVudmlyb25tZW50cywgd2hlcmUgbmV0d29yayBu b2RlcyBhcmUgbGltaXRlZCBpbiBDUFUsIG1lbW9yeSBhbmQgcG93ZXIuDQoNClJFU1QgYXJjaGl0 ZWN0dXJlIGlzIHdpZGVseSB1c2VkIGZvciBzdWNoIGNvbnN0cmFpbmVkIGVudmlyb25tZW50cy4N Cg0KDQoNCk5FVw0KDQpUaGUgSUVURiBoYXMgcmVjZW50bHkgZGV2ZWxvcGVkIHByb3RvY29scyBm b3IgdXNlIGluIGNvbnN0cmFpbmVkDQoNCmVudmlyb25tZW50cywgd2hlcmUgbmV0d29yayBub2Rl cyBhcmUgbGltaXRlZCBpbiBDUFUsIG1lbW9yeSBhbmQgcG93ZXIuDQoNClJFU1QgYXJjaGl0ZWN0 dXJlIGlzIHdpZGVseSB1c2VkIGZvciBzdWNoIGNvbnN0cmFpbmVkIGVudmlyb25tZW50cy4NCg0K RU5EDQpDb25zaWRlcmluZyB0aGF0IE9MRCBpcw0KDQpPTEQNCg0KVGhlIElFVEYgaGFzIHJlY2Vu dGx5IGRldmVsb3BlZCBwcm90b2NvbHMgZm9yIHVzZSBpbiBjb25zdHJhaW5lZA0KDQplbnZpcm9u bWVudHMsIHdoZXJlIG5ldHdvcmsgbm9kZXMgYXJlIGxpbWl0ZWQgaW4gQ1BVLCBtZW1vcnkgYW5k IHBvd2VyLg0KLi4uIGZpbmUgd2l0aCBtZQ0KDQoNCg0KDQoNCg0KKDIpICAgICBSZW1vdmUg4oCc QUFBIHByb3RvY29s4oCdIGZyb20gdGhlIGNoYXJ0ZXI6DQoNCk9MRA0KDQpUaGUgSUVURiBoYXMg YSBsb25nIGhpc3RvcnkgaW4gZGV2ZWxvcGluZyB0aHJlZS1wYXJ0eSBhdXRoZW50aWNhdGlvbiBh bmQNCg0KYXV0aG9yaXphdGlvbiBwcm90b2NvbHMgZm9yIGRpc3RyaWJ1dGVkIGVudmlyb25tZW50 cy4gRXhhbXBsZXMgaW5jbHVkZQ0KDQpLZXJiZXJvcywgdGhlIFB1YmxpYyBLZXkgSW5mcmFzdHJ1 Y3R1cmUgKFBLSSksIHRoZSBBdXRoZW50aWNhdGlvbiwNCg0KQXV0aG9yaXphdGlvbiBhbmQgQWNj b3VudGluZyAoQUFBKSBpbmZyYXN0cnVjdHVyZSwgYW5kIHRoZSBXZWINCg0KQXV0aG9yaXphdGlv biBQcm90b2NvbCAoT0F1dGgpLg0KDQoNCg0KTkVXDQoNClRoZSBJRVRGIGhhcyBhIGxvbmcgaGlz dG9yeSBpbiBkZXZlbG9waW5nIHRocmVlLXBhcnR5IGF1dGhlbnRpY2F0aW9uIGFuZA0KDQphdXRo b3JpemF0aW9uIHByb3RvY29scyBmb3IgZGlzdHJpYnV0ZWQgZW52aXJvbm1lbnRzLiBFeGFtcGxl cyBpbmNsdWRlDQoNCktlcmJlcm9zLCB0aGUgUHVibGljIEtleSBJbmZyYXN0cnVjdHVyZSAoUEtJ KSwgYW5kIHRoZSBXZWIgQXV0aG9yaXphdGlvbiBQcm90b2NvbCAoT0F1dGgpLg0KDQpFTkQNCldl IGhhdmUgQUFBLWRvY3RvcnMgdGVsbGluZzogbWF5YmUgUkFESVVTIGlzIGFwcGxpY2FibGU/DQpQ ZXJzb25hbGx5LCBJIGRvbid0IGtub3cgYW5kIGl0IGRvZXNuJ3QgbWF0dGVyIGF0IHRoaXMgcG9p bnQuDQpXZSByZWNlaXZlZCBmZWVkYmFjayBzdWNoIGFzOg0KTGV0J3MgYmUgY2xlYXIgaGVyZTog SXQgd2FzIG5ldmVyIHNhaWQgKGluIHRoZSBjaGFydGVyIG9yIGFueXdoZXJlIGVsc2UgaW4gdGhl IGdyb3VwIHRvIG15IGtub3dsZWRnZSkgdGhhdCBSQURJVVMgKG9yIGluZGVlZCBhbnkgb3RoZXIg QUFBIHByb3RvY29sKSB3b3VsZCBub3QgcnVuIG9uIGNvbnN0cmFpbmVkIGRldmljZXMgKFJGQyA3 MjI4KS4gVGhlIGNoYXJ0ZXIgc2ltcGx5IHNhaWQgdGhlIHByb3RvY29scyB3ZXJlIG5vdCBvcHRp bWlzZWQgZm9yIGNvbnN0cmFpbmVkIGRldmljZXMuIFRoYXQgZG9lcyBub3QgcHJlY2x1ZGUgY29u c2lkZXJpbmcgYW55IHByb3RvY29sIGZvciBzdWl0YWJpbGl0eSBmb3IgY29uc3RyYWluZWQgZGV2 aWNlcyBlaXRoZXIgYSkgYXMgaXMsIGIpIGluIGEgcmVzdHJpY3RlZCB3YXkgb3IgYykgaW4gYW4g YWRhcHRlZCB3YXkuDQoNClNvLCBhdCB0aGlzIHN0YWdlLCBJIGRvbid0IHRoaW5rIGFueSBwcm90 b2NvbHMgc2hvdWxkIGJlIGV4Y2x1ZGVkIGZyb20gY29uc2lkZXJhdGlvbiBhbmQgc2hvdWxkIGNl cnRhaW5seSBub3QgYmUgZWxpbWluYXRlZCBvbiBhIGh1bmNoIHRoYXQgdGhleSBtaWdodCBiZSAi dG9vIGJpZyIuIExldCdzIGRvIHRoZSBhc3Nlc3NtZW50IHByb3Blcmx5IGF0IHRoZSBhcHByb3By aWF0ZSB0aW1lLiBBcyBhIHJlbWluZGVyIC0gdGhlIGZvY3VzIG5vdyBpcyB0byBjb21wbGV0ZSB0 aGUgY2hhcnRlci4NCk9yDQoNCj4+VGhlIENoYXJ0ZXIgbWFrZXMgYSBudW1iZXIgb2YgYXNzZXJ0 aW9ucyB0aGF0IGFyZSBwcm92YWJseSBmYWxzZSwgc3VjaCBhcyB0aGF0IEFBQSBwcm90b2NvbHMg YXJlIGluYXBwcm9wcmlhdGUgZm9yIGNvbnN0cmFpbmVkIGVudmlyb25tZW50cy4NCg0KSW4gZmFj dCwgdGhlIGNoYXJ0ZXIgZG9lcyBub3Qgc2F5IHRoYXQuIEJ1dCB0byBhdm9pZCBjb25mdXNpb24s IGxldCdzIHJlbW92ZSBBQUEgcHJvdG9jb2wgZnJvbSB0aGUgY2hhcnRlci4NCg0KDQoNCkluIHRo ZSBjaGFydGVyLCB3ZSBtZW50aW9uZWQgdGhhdCB3ZSB3YW50IHRvIHJldXNlIGV4aXN0aW5nIGF1 dGhlbnRpY2F0aW9uIGFuZCBhdXRob3JpemF0aW9uIHByb3RvY29scyB3aGVyZSBhcHBsaWNhYmxl IHRvIGJ1aWxkIHRoZSBjb25zdHJhaW5lZC1lbnZpcm9ubWVudCBzb2x1dGlvbi4NCi4uLiB3aGlj aCBJIHJlYWQgYXM6IGxldCdzIGNvbnNpZGVyIHRoZSBBQUEgcHJvdG9jb2xzLCBhbmQgZXZhbHVh dGUgaWYgdGhleSB3b3VsZCB3b3JrIGluIGNvbnN0cmFpbmVkIGRldmljZXMuDQpJIGRvbid0IHVu ZGVyc3RhbmQgdGhlIGxvZ2ljOiB3aHkgZG8geW91IHdhbnQgdG8gcmVtb3ZlIEFBQSBmcm9tIHRo ZSBjaGFydGVyPw0KTm90IG9ubHkgd291bGQgSSBrZWVwICJBQUEiLCBidXQgSSB3b3VsZCBwcm9w b3NlDQoNCk9MRDoNCkV4aXN0aW5nIGF1dGhlbnRpY2F0aW9uIGFuZCBhdXRob3JpemF0aW9uIHBy b3RvY29scyB3aWxsIGJlIHVzZWQgd2hlcmUNCmFwcGxpY2FibGUgdG8gYnVpbGQgdGhlIGNvbnN0 cmFpbmVkLWVudmlyb25tZW50IHNvbHV0aW9uDQoNCk5FVzoNCkV4aXN0aW5nIGF1dGhlbnRpY2F0 aW9uIGFuZCBhdXRob3JpemF0aW9uIHByb3RvY29scyB3aWxsIGJlIGV2YWx1YXRlZCBhbmQgcmUt dXNlZCB3aGVyZQ0KYXBwbGljYWJsZSB0byBidWlsZCB0aGUgY29uc3RyYWluZWQtZW52aXJvbm1l bnQgc29sdXRpb24NCg0KUmVnYXJkcywgQmVub2l0DQoNCg0KDQoNCg0KDQooMykgQ2xhcmlmeSB0 aGUgc2NvcGU6DQoNCk9MRDoNCg0KTm90ZSB0aGF0IHRoZSBpbml0aWFsIGZvY3VzIGlzIG9uIENv QVAgYW5kIEhUVFAgd2l0aCBEVExTIGFuZCBUTFMuDQoNCk90aGVyIHNlY3VyaXR5IHByb3RvY29s cyBtYXkgYmUgY29uc2lkZXJlZCBhcyBsb25nIGFzIHRoZSBwcmltYXJ5IGZvY3VzIGlzIG1haW50 YWluZWQuDQoNCk90aGVyIGFwcGxpY2F0aW9uIHByb3RvY29scyBhbmQgcHJvdG9jb2xzIGF0IG90 aGVyIGxheWVycyBpbiB0aGUgc3RhY2sgYXJlIG91dCBvZiBzY29wZS4NCg0KDQoNCk5FVw0KDQpO b3RlIHRoYXQgdGhlIGluaXRpYWwgZm9jdXMgaXMgb24gQ29BUCBhbmQgSFRUUCB3aXRoIERUTFMg YW5kIFRMUy4NCg0KT3RoZXIgc2VjdXJpdHkgcHJvdG9jb2xzIG1heSBiZSBjb25zaWRlcmVkIGFz IGxvbmcgYXMgdGhlIHByaW1hcnkgZm9jdXMgaXMgbWFpbnRhaW5lZC4NCg0KVGhlIGdyb3VwIGlz IHNjb3BlZCB0byB3b3JrIG9ubHkgb24gdGhlIHdlYiBwcm90b2NvbHMgYW5kIGRhdGEgY2Fycmll ZCB3aXRoaW4gdGhlbS4NCg0KRU5EDQoNCg0KDQooNCkgICAgIFVwZGF0ZSBtaWxlc3RvbmVzIGZv ciB0aGUgdXNlIGNhc2UgJiByZXF1aXJlbWVudHMgZG9jdW1lbnQ6DQoNCk9MRDoNCg0KSnVsIDIw MTUgU3VibWl0IOKAnFVzZSBjYXNlcyBhbmQgUmVxdWlyZW1lbnRz4oCdIGRvY3VtZW50IHRvIElF U0cgZm9yIHB1YmxpY2F0aW9uIGFzIGluZm9ybWF0aW9uYWwgUkZDLg0KDQoNCg0KTkVXDQoNCkRl YyAyMDE0IE9wdGlvbmFsbHksIHN1Ym1pdCAiVXNlIGNhc2VzIGFuZCBSZXF1aXJlbWVudHMiIGRv Y3VtZW50IHRvIHRoZSBJRVNHIGZvciBwdWJsaWNhdGlvbiBhcyBhbiBJbmZvcm1hdGlvbmFsIFJG Qy4NCg0KRU5EDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQoNCkNoYXJ0ZXIgY2hhcnRlci1pZXRmLWFjZS0wMC0wMg0KDQpB dXRoZW50aWNhdGlvbiBhbmQgQXV0aG9yaXphdGlvbiBmb3IgQ29uc3RyYWluZWQNCg0KRW52aXJv bm1lbnQgKEFDRSkNCg0KDQoNClRoZSBJRVRGIGhhcyByZWNlbnRseSBkZXZlbG9wZWQgcHJvdG9j b2xzIGZvciB1c2UgaW4gY29uc3RyYWluZWQNCg0KZW52aXJvbm1lbnRzLCB3aGVyZSBuZXR3b3Jr IG5vZGVzIGFyZSBsaW1pdGVkIGluIENQVSwgbWVtb3J5IGFuZCBwb3dlci4NCg0KUkVTVCBhcmNo aXRlY3R1cmUgaXMgd2lkZWx5IHVzZWQgZm9yIHN1Y2ggY29uc3RyYWluZWQgZW52aXJvbm1lbnRz Lg0KDQpJdCBoYXMgYmVlbiBvYnNlcnZlZCB0aGF0IEludGVybmV0IHByb3RvY29scyBjYW4gYmUg YXBwbGllZCB0byB0aGVzZQ0KDQpjb25zdHJhaW5lZCBlbnZpcm9ubWVudHMsIG9mdGVuIG9ubHkg cmVxdWlyaW5nIG1pbm9yIHR3ZWFraW5nIGFuZA0KDQpwcm9maWxpbmcuIEluIG90aGVyIGNhc2Vz LCBuZXcgcHJvdG9jb2xzIGhhdmUgYmVlbiBkZWZpbmVkIHRvIGFkZHJlc3MNCg0KdGhlIHNwZWNp ZmljIHJlcXVpcmVtZW50cyBvZiBjb25zdHJhaW5lZCBlbnZpcm9ubWVudHMuIEFuIGV4YW1wbGUg b2YNCg0Kc3VjaCBhIHByb3RvY29sIGlzIHRoZSBDb25zdHJhaW5lZCBBcHBsaWNhdGlvbiBQcm90 b2NvbCAoQ29BUCkuDQoNCg0KDQpBcyBpbiBvdGhlciBlbnZpcm9ubWVudHMsIGF1dGhlbnRpY2F0 aW9uIGFuZCBhdXRob3JpemF0aW9uIHF1ZXN0aW9ucw0KDQphbHNvIGFyaXNlIGluIGNvbnN0cmFp bmVkIGVudmlyb25tZW50cy4gRm9yIGV4YW1wbGUsIGEgZG9vciBsb2NrIGhhcyB0bw0KDQphdXRo b3JpemUgdGhlIHBlcnNvbiBzZWVraW5nIGFjY2VzcyB1c2luZyBhICJkaWdpdGFsIGtleSIuIFdo ZXJlIGlzIHRoZQ0KDQphdXRob3JpemF0aW9uIHBvbGljeSBzdG9yZWQ/IEhvdyBkb2VzIHRoZSBk aWdpdGFsIGtleSBjb21tdW5pY2F0ZSB3aXRoDQoNCnRoZSBsb2NrPyBEb2VzIHRoZSBsb2NrIGlu dGVyYWN0IHdpdGggYW4gYXV0aG9yaXphdGlvbiBzZXJ2ZXIgdG8gb2J0YWluDQoNCmF1dGhvcml6 YXRpb24gaW5mb3JtYXRpb24/IEhvdyBjYW4gYWNjZXNzIGJlIHRlbXBvcmFyaWx5IGdyYW50ZWQg dG8NCg0Kb3RoZXIgcGVyc29ucz8gSG93IGNhbiBhY2Nlc3MgYmUgcmV2b2tlZD8gVGhlc2UgdHlw ZXMgb2YgcXVlc3Rpb25zIGhhdmUNCg0KYmVlbiBhbnN3ZXJlZCBieSBleGlzdGluZyBwcm90b2Nv bHMgZm9yIHVzZSBjYXNlcyBvdXRzaWRlIGNvbnN0cmFpbmVkDQoNCmVudmlyb25tZW50cywgaG93 ZXZlciBpbiBjb25zdHJhaW5lZCBlbnZpcm9ubWVudHMsIGFkZGl0aW9uYWwgYW5kDQoNCmRpZmZl cmVudCByZXF1aXJlbWVudHMgcG9zZSBjaGFsbGVuZ2VzIGZvciB0aGUgdXNlIG9mIHZhcmlvdXMg c2VjdXJpdHkNCg0KcHJvdG9jb2xzLiBJbiBwYXJ0aWN1bGFyLCB0aGUgbmVlZCBhcmlzZXMgZm9y IGEgZHluYW1pYyBhbmQgZmluZSBncmFpbmVkDQoNCmFjY2VzcyBjb250cm9sIG1lY2hhbmlzbSwg d2hlcmUgY2xpZW50cyBhbmQvb3IgcmVzb3VyY2Ugc2VydmVycyBhcmUNCg0KY29uc3RyYWluZWQu DQoNCg0KDQpUaGUgSUVURiBoYXMgYSBsb25nIGhpc3RvcnkgaW4gZGV2ZWxvcGluZyB0aHJlZS1w YXJ0eSBhdXRoZW50aWNhdGlvbiBhbmQNCg0KYXV0aG9yaXphdGlvbiBwcm90b2NvbHMgZm9yIGRp c3RyaWJ1dGVkIGVudmlyb25tZW50cy4gRXhhbXBsZXMgaW5jbHVkZQ0KDQpLZXJiZXJvcywgdGhl IFB1YmxpYyBLZXkgSW5mcmFzdHJ1Y3R1cmUgKFBLSSksIGFuZCB0aGUgV2ViDQoNCkF1dGhvcml6 YXRpb24gUHJvdG9jb2wgKE9BdXRoKS4gQWxsIHRoZXNlIHByb3RvY29scyBlbmpveSB3aWRlc3By ZWFkDQoNCmRlcGxveW1lbnQgb24gdGhlIEludGVybmV0LiBBbHRob3VnaCB0aGV5IGFsbCBhaW0g dG8gc29sdmUgYSBzaW1pbGFyDQoNCmdvYWwsIGF0IGFuIGFic3RyYWN0IGxldmVsLCB0aGV5IG9m ZmVyIHF1aXRlIGRpZmZlcmVudCBmdW5jdGlvbnMgYW5kDQoNCnV0aWxpemUgZGlmZmVyZW50IG1l c3NhZ2UgZXhjaGFuZ2VzLiBUaGVzZSBkaWZmZXJlbmNlcyByZXN1bHQgZnJvbSB0aGUNCg0KbWFp biBkZXBsb3ltZW50IHVzZSBjYXNlcyB0aGV5IHdlcmUgZGVzaWduZWQgZm9yIHJlc3BlY3RpdmVs eS4NCg0KDQoNClJlcXVpcmVtZW50cyBkZXJpdmVkIGZyb20gdXNlIGNhc2VzIGluZGljYXRlIHRo ZSBzdWl0YWJpbGl0eSBvZiBleGlzdGluZw0KDQp3b3JrIGFzIGEgc29sdXRpb24gZm9yIGNvbnN0 cmFpbmVkIGVudmlyb25tZW50cy4gVGhlc2UgcHJvdG9jb2xzLA0KDQpob3dldmVyLCB3ZXJlIG5v dCBvcHRpbWl6ZWQgZm9yIGNvbnN0cmFpbmVkIGVudmlyb25tZW50cy4gQWRkaXRpb25hbA0KDQpy ZXF1aXJlbWVudHMgdGhhdCBuZWVkIHRvIGJlIHRha2VuIGludG8gYWNjb3VudCBhcmUgdGhlIGxh Y2sgb2YgYQ0KDQpzdWl0YWJsZSB1c2VyLWludGVyZmFjZSBhbmQgdGhlIGluYWJpbGl0eSBvZiBl bWJlZGRlZCBkZXZpY2VzIHRvIGNvbnRhY3QNCg0KYW4gYXV0aG9yaXphdGlvbiBzZXJ2ZXIgaW4g cmVhbC10aW1lIHdpdGggZXZlcnkgcmVzb3VyY2UgYWNjZXNzIHJlcXVlc3QNCg0KZHVlIHRvIGlu dGVybWl0dGVudCBjb25uZWN0aXZpdHksIGV0Yy4NCg0KDQoNClRoaXMgd29ya2luZyBncm91cCB0 aGVyZWZvcmUgYWltcyB0byBwcm9kdWNlIGEgc3RhbmRhcmRpemVkIHNvbHV0aW9uIGZvcg0KDQph dXRoZW50aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlvbiB0byBlbmFibGUgYXV0aG9yaXplZCBhY2Nl c3MgKEdFVCwgUFVULCBQT1NULA0KDQpERUxFVEUpIHRvIHJlc291cmNlcyBpZGVudGlmaWVkIGJ5 IGEgVVJJIGFuZCBob3N0ZWQgb24gYSByZXNvdXJjZQ0KDQpzZXJ2ZXIgaW4gY29uc3RyYWluZWQg ZW52aXJvbm1lbnRzLiBBcyBhIHN0YXJ0aW5nIHBvaW50LCB0aGUgd29ya2luZw0KDQpncm91cCB3 aWxsIGFzc3VtZSB0aGF0IGFjY2VzcyB0byByZXNvdXJjZXMgYXQgYSByZXNvdXJjZSBzZXJ2ZXIg YnkgYQ0KDQpjbGllbnQgZGV2aWNlIHRha2VzIHBsYWNlIHVzaW5nIENvQVAgYW5kIGlzIHByb3Rl Y3RlZCBieSBEVExTLiBCb3RoDQoNCnJlc291cmNlIHNlcnZlciBhbmQgY2xpZW50IG1heSBiZSBj b25zdHJhaW5lZC4gVGhpcyBhY2Nlc3Mgd2lsbCBiZQ0KDQptZWRpYXRlZCBieSBhbiBhdXRob3Jp emF0aW9uIHNlcnZlciwgd2hpY2ggaXMgbm90IGNvbnNpZGVyZWQgdG8gYmUNCg0KY29uc3RyYWlu ZWQuDQoNCg0KDQpFeGlzdGluZyBhdXRoZW50aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlvbiBwcm90 b2NvbHMgd2lsbCBiZSB1c2VkIHdoZXJlDQoNCmFwcGxpY2FibGUgdG8gYnVpbGQgdGhlIGNvbnN0 cmFpbmVkLWVudmlyb25tZW50IHNvbHV0aW9uLiBUaGlzIHJlcXVpcmVzDQoNCnJlbGV2YW50IHNw ZWNpZmljYXRpb25zIHRvIGJlIHJldmlld2VkIGZvciBzdWl0YWJpbGl0eSwgc2VsZWN0aW5nIGEN Cg0Kc3Vic2V0IG9mIHRoZW0gYW5kIHJlc3RyaWN0aW5nIHRoZSBvcHRpb25zIHdpdGhpbiBlYWNo IG9mIHRoZQ0KDQpzcGVjaWZpY2F0aW9ucy4gU29tZSBmdW5jdGlvbmFsaXR5LCBob3dldmVyLCBt YXkgbm90IGJlIGF2YWlsYWJsZSBpbg0KDQpleGlzdGluZyBwcm90b2NvbHMsIGluIHdoaWNoIGNh c2UgdGhlIHNvbHV0aW9uIG1heSBhbHNvIGludm9sdmUgbmV3DQoNCnByb3RvY29sIHdvcmsuIExl dmVyYWdpbmcgZXhpc3Rpbmcgd29yayBtZWFucyB0aGUgd29ya2luZyBncm91cCBiZW5lZml0cw0K DQpmcm9tIGF2YWlsYWJsZSBzZWN1cml0eSBhbmFseXNpcywgaW1wbGVtZW50YXRpb24sIGFuZCBk ZXBsb3ltZW50DQoNCmV4cGVyaWVuY2UuIE1vcmVvdmVyLCBhIHN0YW5kYXJkaXplZCBzb2x1dGlv biBmb3IgZmVkZXJhdGVkDQoNCmF1dGhlbnRpY2F0aW9uIGFuZCBhdXRob3JpemF0aW9uIHdpbGwg aGVscCB0byBzdGltdWxhdGUgdGhlIGRlcGxveW1lbnQNCg0Kb2YgY29uc3RyYWluZWQgZGV2aWNl cyB0aGF0IHByb3ZpZGUgaW5jcmVhc2VkIHNlY3VyaXR5Lg0KDQoNCg0KT25jZSBwcm9ncmVzcyBp biBpZGVudGlmeWluZyBzdWl0YWJsZSBjYW5kaWRhdGUgc29sdXRpb25zIGhhcyBiZWVuIG1hZGUs DQoNCnRoZSB3b3JraW5nIGdyb3VwIHdpbGwgdmVyaWZ5IHdoZXRoZXIgdGhlIHNhbWUgbWVjaGFu aXNtcyBhcmUgYWxzbw0KDQphcHBsaWNhYmxlIGJleW9uZCB0aGUgdXNlIG9mIENvQVAgYW5kIERU TFMsIHdoaWNoIGFyZSB0aGUgdHdvIG1haW4NCg0KcHJvdG9jb2xzIHRoZSBncm91cCB3aWxsIGZv Y3VzIG9uIGZvciBhY2Nlc3MgdG8gcmVzb3VyY2VzLiBJbg0KDQpwYXJ0aWN1bGFyLCB0aGUgYWJp bGl0eSB0byB1c2UgdGhlIGRldmVsb3BlZCBzb2x1dGlvbiBvdmVyIEhUVFAgYW5kIFRMUw0KDQp3 aWxsIGJlIGludmVzdGlnYXRlZC4gTm90ZSB0aGF0IHRoZSBpbml0aWFsIGZvY3VzIGlzIG9uIENv QVAgYW5kIEhUVFAgd2l0aCBEVExTIGFuZCBUTFMuDQoNCk90aGVyIHNlY3VyaXR5IHByb3RvY29s cyBtYXkgYmUgY29uc2lkZXJlZCBhcyBsb25nIGFzIHRoZSBwcmltYXJ5IGZvY3VzIGlzIG1haW50 YWluZWQuDQoNClRoZSBncm91cCBpcyBzY29wZWQgdG8gd29yayBvbmx5IG9uIHRoZSB3ZWIgcHJv dG9jb2xzIGFuZCBkYXRhIGNhcnJpZWQgd2l0aGluIHRoZW0uDQoNCkZ1cnRoZXJtb3JlLCB0byBn dWFyYW50ZWUgc21vb3RoIHRyYW5zaXRpb24sIHRoZQ0KDQppbnRlZ3JhdGlvbiB3aXRoIGV4aXN0 aW5nIGRlcGxveW1lbnRzIHdpbGwgYmUgc3R1ZGllZCwgcGFydGljdWxhcmx5DQoNCmNvbmNlcm5p bmcgdGhlIHVzZSBvZiBwcm90b2NvbCB0cmFuc2xhdGlvbiBwcm94aWVzLg0KDQoNCg0KVGhpcyB3 b3JrIGRvZXMgbm90IG1ha2UgdGhlIGFzc3VtcHRpb24gdGhhdCB0aGUgcGFydHkgb2ZmZXJpbmcN Cg0KYXBwbGljYXRpb24gbGF5ZXIgc2VydmljZXMgaXMgYWx3YXlzIHRoZSBzYW1lIHBhcnR5IG9m ZmVyaW5nIG5ldHdvcmsNCg0KYWNjZXNzIHNlcnZpY2VzLg0KDQoNCg0KVGhlIHdvcmtpbmcgZ3Jv dXAgaGFzIHRoZSBmb2xsb3dpbmcgdGFza3M6DQoNCg0KDQoxKSBQcm9kdWNlIHVzZSBjYXNlcyBh bmQgcmVxdWlyZW1lbnRzDQoNCg0KDQoyKSBJZGVudGlmeSBhdXRoZW50aWNhdGlvbiBhbmQgYXV0 aG9yaXphdGlvbiBtZWNoYW5pc21zIHN1aXRhYmxlIGZvcg0KDQpyZXNvdXJjZSBhY2Nlc3MgaW4g Y29uc3RyYWluZWQgZW52aXJvbm1lbnRzLg0KDQoNCg0KTWlsZXN0b25lczoNCg0KDQoNCkp1bCAy MDE0IFN1Ym1pdCAiVXNlIGNhc2VzIGFuZCBSZXF1aXJlbWVudHMiIGFzIGEgV0cgaXRlbS4NCg0K RGVjIDIwMTQgU3VibWl0ICJBdXRoZW50aWNhdGlvbiBhbmQgQXV0aG9yaXphdGlvbiBTb2x1dGlv biIgYXMgYSBXRyBpdGVtLg0KDQpEZWMgMjAxNCBPcHRpb25hbGx5LCBzdWJtaXQgIlVzZSBjYXNl cyBhbmQgUmVxdWlyZW1lbnRzIiBkb2N1bWVudA0KDQp0byB0aGUgSUVTRyBmb3IgcHVibGljYXRp b24gYXMgYW4gSW5mb3JtYXRpb25hbCBSRkMuDQoNCkp1bCAyMDE2IFN1Ym1pdCAiQXV0aGVudGlj YXRpb24gYW5kIEF1dGhvcml6YXRpb24gU29sdXRpb24iDQoNCnNwZWNpZmljYXRpb24gdG8gdGhl IElFU0cgZm9yIHB1YmxpY2F0aW9uIGFzIGEgUHJvcG9zZWQgU3RhbmRhcmQuDQoNCg0KDQpQcm9w b3NlZCBNaWxlc3RvbmVzDQoNCk5vIG1pbGVzdG9uZXMgZm9yIGNoYXJ0ZXIgZm91bmQuDQoNCg== --_000_34966E97BE8AD64EAE9D3D6E4DEE36F258153F43SZXEMA501MBSchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OuWui+S9kzsNCgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1M IOmihOiuvuagvOW8jyBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzsNCgljb2xvcjpibGFj azt9DQpzcGFuLkhUTUxDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIOmihOiuvuagvOW8jyBD aGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwg6aKE 6K6+5qC85byPIjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrO30N CnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAu MHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJn aW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9 IlpILUNOIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIEJlbm9pdCw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+Jmd0O05vdCBvbmx5IHdvdWxkIEkga2VlcCAmcXVvdDtBQUEmcXVv dDssDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+T0suPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZndDtidXQgSSB3b3VsZCBwcm9wb3NlPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZndDtPTEQ6PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mZ3Q7RXhpc3RpbmcgYXV0aGVudGljYXRpb24gYW5kIGF1 dGhvcml6YXRpb24gcHJvdG9jb2xzIHdpbGwgYmUgdXNlZCB3aGVyZTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+YXBwbGljYWJsZSB0byBidWlsZCB0aGUgY29uc3Ry YWluZWQtZW52aXJvbm1lbnQgc29sdXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPiZndDtORVc6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5FeGlzdGluZyBhdXRoZW50aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlvbiBwcm90b2NvbHMgd2ls bCBiZSBldmFsdWF0ZWQgYW5kIHJlLXVzZWQgd2hlcmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPmFwcGxpY2FibGUgdG8gYnVpbGQgdGhlIGNvbnN0cmFpbmVkLWVu dmlyb25tZW50IHNvbHV0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5P SywgZmluZSB3aXRoIG1lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFu a3MgZm9yIHRoZSBmZWVkYmFjay4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5LaW5kIFJlZ2FyZHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PktlcGVuZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Nv bG9yOndpbmRvd3RleHQiPuWPkeS7tuS6ujxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvc3Bh bj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOndp bmRvd3RleHQiPiBCZW5vaXQgQ2xhaXNlIFttYWlsdG86YmNsYWlzZUBjaXNjby5jb21dDQo8YnI+ DQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6d2luZG93dGV4 dCI+5Y+R6YCB5pe26Ze0PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9zcGFuPjwvYj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6d2luZG93dGV4dCI+ IDIwMTQ8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6d2luZG93dGV4 dCI+5bm0PHNwYW4gbGFuZz0iRU4tVVMiPjY8L3NwYW4+5pyIPHNwYW4gbGFuZz0iRU4tVVMiPjM8 L3NwYW4+5pelPHNwYW4gbGFuZz0iRU4tVVMiPg0KIDEyOjE2PGJyPg0KPC9zcGFuPjxiPuaUtuS7 tuS6ujxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IExp a2VwZW5nOyBLYXRobGVlbiBNb3JpYXJ0eTsgYWRyaWFuQG9sZGRvZy5jby51azxicj4NCjwvc3Bh bj48Yj7mioTpgIE8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4t VVMiPiBhYWEtZG9jdG9yc0BpZXRmLm9yZzsgVGhlIElFU0c7IGFjZUBpZXRmLm9yZzxicj4NCjwv c3Bhbj48Yj7kuLvpopg8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0i RU4tVVMiPiBSZTogUmV2aXNlZCBjaGFydGVyIHByb3Bvc2FsOiBjaGFydGVyLWlldGYtYWNlLTAw LTAyPG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPkhpLCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+SGVsbG8gYWxsLDxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5CYXNlZCBvbiByZWNlbnQgZGlzY3Vzc2lv bnMsIEkgbWFkZSBhIHJldmlzZWQgY2hhcnRlciBwcm9wb3NhbCwgYXMgaW5jbHVkZWQgaW4gdGhp cyBlbWFpbCwgbm90IG9uIHRoZSB3ZWJwYWdlIHlldC4gPG86cD48L286cD48L3NwYW4+PC9wcmU+ DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4N CjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPlBsZWFzZSB0YWtlIGEgbG9vayBhbmQgbGV0IHVzIGtu b3cgaWYgeW91IGhhdmUgYW55IGZ1cnRoZXIgY29tbWVudHMuPG86cD48L286cD48L3NwYW4+PC9w cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPkBBZHJpYW4gYW5kIEBCZW5vaXQsIHBsZWFzZSBj aGVjayBpZiB0aGUgcHJvcG9zZWQgdGV4dHMgY2FuIHJlc29sdmUgeW91ciBjb21tZW50cy48bzpw PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+VGhhbmtzLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+S2luZCBSZWdhcmRz PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5LZXBlbmc8 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+LS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Q29tcGFyZWQgd2l0aCBjaGFydGVyLWlldGYtYWNl LTAwLTAxIG9uIHRoZSB3ZWJwYWdlLCB0aGUgY2hhbmdlcyBhcmU6PG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPigxKSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBBZGQgb25lIGNsYXJpZmljYXRpb24gc2VudGVuY2UgYWJvdXQgUkVTVCBhcmNoaXRl Y3R1cmU6PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5P TEQ8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPlRoZSBJ RVRGIGhhcyByZWNlbnRseSBkZXZlbG9wZWQgcHJvdG9jb2xzIGZvciB1c2UgaW4gY29uc3RyYWlu ZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPmVudmly b25tZW50cywgd2hlcmUgbmV0d29yayBub2RlcyBhcmUgbGltaXRlZCBpbiBDUFUsIG1lbW9yeSBh bmQgcG93ZXIuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1V UyI+UkVTVCBhcmNoaXRlY3R1cmUgaXMgd2lkZWx5IHVzZWQgZm9yIHN1Y2ggY29uc3RyYWluZWQg ZW52aXJvbm1lbnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVO LVVTIj5ORVc8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMi PlRoZSBJRVRGIGhhcyByZWNlbnRseSBkZXZlbG9wZWQgcHJvdG9jb2xzIGZvciB1c2UgaW4gY29u c3RyYWluZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMi PmVudmlyb25tZW50cywgd2hlcmUgbmV0d29yayBub2RlcyBhcmUgbGltaXRlZCBpbiBDUFUsIG1l bW9yeSBhbmQgcG93ZXIuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9 IkVOLVVTIj5SRVNUIGFyY2hpdGVjdHVyZSBpcyB3aWRlbHkgdXNlZCBmb3Igc3VjaCBjb25zdHJh aW5lZCBlbnZpcm9ubWVudHMuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh bmc9IkVOLVVTIj5FTkQ8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5Db25zaWRlcmluZyB0aGF0IE9M RCBpczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5PTEQ8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSBJRVRGIGhhcyByZWNlbnRseSBk ZXZlbG9wZWQgcHJvdG9jb2xzIGZvciB1c2UgaW4gY29uc3RyYWluZWQ8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPmVudmlyb25tZW50cywgd2hl cmUgbmV0d29yayBub2RlcyBhcmUgbGltaXRlZCBpbiBDUFUsIG1lbW9yeSBhbmQgcG93ZXIuIDwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Li4uIGZpbmUgd2l0aCBtZTxicj4NCjxi cj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4oMikmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgUmVtb3ZlIOKAnEFBQSBwcm90b2NvbOKAnSBmcm9tIHRoZSBj aGFydGVyOjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+ T0xEPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUg SUVURiBoYXMgYSBsb25nIGhpc3RvcnkgaW4gZGV2ZWxvcGluZyB0aHJlZS1wYXJ0eSBhdXRoZW50 aWNhdGlvbiBhbmQ8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4t VVMiPmF1dGhvcml6YXRpb24gcHJvdG9jb2xzIGZvciBkaXN0cmlidXRlZCBlbnZpcm9ubWVudHMu IEV4YW1wbGVzIGluY2x1ZGU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFu Zz0iRU4tVVMiPktlcmJlcm9zLCB0aGUgUHVibGljIEtleSBJbmZyYXN0cnVjdHVyZSAoUEtJKSwg dGhlIEF1dGhlbnRpY2F0aW9uLDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs YW5nPSJFTi1VUyI+QXV0aG9yaXphdGlvbiBhbmQgQWNjb3VudGluZyAoQUFBKSBpbmZyYXN0cnVj dHVyZSwgYW5kIHRoZSBXZWI8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFu Zz0iRU4tVVMiPkF1dGhvcml6YXRpb24gUHJvdG9jb2wgKE9BdXRoKS48bzpwPjwvbzpwPjwvc3Bh bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+TkVXPG86cD48L286cD48L3NwYW4+PC9w cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUgSUVURiBoYXMgYSBsb25nIGhpc3Rvcnkg aW4gZGV2ZWxvcGluZyB0aHJlZS1wYXJ0eSBhdXRoZW50aWNhdGlvbiBhbmQ8bzpwPjwvbzpwPjwv c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPmF1dGhvcml6YXRpb24gcHJvdG9j b2xzIGZvciBkaXN0cmlidXRlZCBlbnZpcm9ubWVudHMuIEV4YW1wbGVzIGluY2x1ZGU8bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPktlcmJlcm9zLCB0aGUg UHVibGljIEtleSBJbmZyYXN0cnVjdHVyZSAoUEtJKSwgYW5kIHRoZSBXZWIgQXV0aG9yaXphdGlv biBQcm90b2NvbCAoT0F1dGgpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs YW5nPSJFTi1VUyI+RU5EPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+V2UgaGF2ZSBBQUEtZG9jdG9ycyB0ZWxsaW5nOiBtYXli ZSBSQURJVVMgaXMgYXBwbGljYWJsZT88YnI+DQpQZXJzb25hbGx5LCBJIGRvbid0IGtub3cgYW5k IGl0IGRvZXNuJ3QgbWF0dGVyIGF0IHRoaXMgcG9pbnQuPGJyPg0KV2UgcmVjZWl2ZWQgZmVlZGJh Y2sgc3VjaCBhczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+TGV0J3MgYmUgY2xlYXIgaGVyZTogSXQgd2FzIG5ldmVyIHNhaWQg KGluIHRoZSBjaGFydGVyIG9yIGFueXdoZXJlIGVsc2UgaW4gdGhlIGdyb3VwIHRvIG15IGtub3ds ZWRnZSkgdGhhdCBSQURJVVMgKG9yIGluZGVlZCBhbnkgb3RoZXIgQUFBIHByb3RvY29sKSB3b3Vs ZCBub3QgcnVuIG9uIGNvbnN0cmFpbmVkIGRldmljZXMgKFJGQyA3MjI4KS4gVGhlIGNoYXJ0ZXIg c2ltcGx5DQogc2FpZCB0aGUgcHJvdG9jb2xzIHdlcmUgbm90IG9wdGltaXNlZCBmb3IgY29uc3Ry YWluZWQgZGV2aWNlcy4gVGhhdCBkb2VzIG5vdCBwcmVjbHVkZSBjb25zaWRlcmluZyBhbnkgcHJv dG9jb2wgZm9yIHN1aXRhYmlsaXR5IGZvciBjb25zdHJhaW5lZCBkZXZpY2VzIGVpdGhlciBhKSBh cyBpcywgYikgaW4gYSByZXN0cmljdGVkIHdheSBvciBjKSBpbiBhbiBhZGFwdGVkIHdheS48YnI+ DQo8YnI+DQpTbywgYXQgdGhpcyBzdGFnZSwgSSBkb24ndCB0aGluayBhbnkgcHJvdG9jb2xzIHNo b3VsZCBiZSBleGNsdWRlZCBmcm9tIGNvbnNpZGVyYXRpb24gYW5kIHNob3VsZCBjZXJ0YWlubHkg bm90IGJlIGVsaW1pbmF0ZWQgb24gYSBodW5jaCB0aGF0IHRoZXkgbWlnaHQgYmUgJnF1b3Q7dG9v IGJpZyZxdW90Oy4gTGV0J3MgZG8gdGhlIGFzc2Vzc21lbnQgcHJvcGVybHkgYXQgdGhlIGFwcHJv cHJpYXRlIHRpbWUuIEFzIGEgcmVtaW5kZXIgLSB0aGUgZm9jdXMgbm93IGlzIHRvDQogY29tcGxl dGUgdGhlIGNoYXJ0ZXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9yPG86cD48L286cD48L3NwYW4+PC9wPg0KPHByZT48c3Bh biBsYW5nPSJFTi1VUyI+Jmd0OyZndDtUaGUgQ2hhcnRlciBtYWtlcyBhIG51bWJlciBvZiBhc3Nl cnRpb25zIHRoYXQgYXJlIHByb3ZhYmx5IGZhbHNlLCBzdWNoIGFzIHRoYXQgQUFBIHByb3RvY29s cyBhcmUgaW5hcHByb3ByaWF0ZSBmb3IgY29uc3RyYWluZWQgZW52aXJvbm1lbnRzLjxvOnA+PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+SW4gZmFjdCwgdGhlIGNo YXJ0ZXIgZG9lcyBub3Qgc2F5IHRoYXQuIEJ1dCB0byBhdm9pZCBjb25mdXNpb24sIGxldCdzIHJl bW92ZSBBQUEgcHJvdG9jb2wgZnJvbSB0aGUgY2hhcnRlci48bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+SW4gdGhlIGNoYXJ0ZXIsIHdlIG1lbnRpb25lZCB0 aGF0IHdlIHdhbnQgdG8gcmV1c2UgZXhpc3RpbmcgYXV0aGVudGljYXRpb24gYW5kIGF1dGhvcml6 YXRpb24gcHJvdG9jb2xzIHdoZXJlIGFwcGxpY2FibGUgdG8gYnVpbGQgdGhlIGNvbnN0cmFpbmVk LWVudmlyb25tZW50IHNvbHV0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPi4uLiB3aGljaCBJIHJlYWQgYXM6IGxldCdz IGNvbnNpZGVyIHRoZSBBQUEgcHJvdG9jb2xzLCBhbmQgZXZhbHVhdGUgaWYgdGhleSB3b3VsZCB3 b3JrIGluIGNvbnN0cmFpbmVkIGRldmljZXMuPGJyPg0KSSBkb24ndCB1bmRlcnN0YW5kIHRoZSBs b2dpYzogd2h5IGRvIHlvdSB3YW50IHRvIHJlbW92ZSBBQUEgZnJvbSB0aGUgY2hhcnRlcj88YnI+ DQpOb3Qgb25seSB3b3VsZCBJIGtlZXAgJnF1b3Q7QUFBJnF1b3Q7LCBidXQgSSB3b3VsZCBwcm9w b3NlPGJyPg0KPGJyPg0KT0xEOjxicj4NCkV4aXN0aW5nIGF1dGhlbnRpY2F0aW9uIGFuZCBhdXRo b3JpemF0aW9uIHByb3RvY29scyB3aWxsIGJlIHVzZWQgd2hlcmU8YnI+DQphcHBsaWNhYmxlIHRv IGJ1aWxkIHRoZSBjb25zdHJhaW5lZC1lbnZpcm9ubWVudCBzb2x1dGlvbjxicj4NCjxicj4NCk5F Vzo8YnI+DQpFeGlzdGluZyBhdXRoZW50aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlvbiBwcm90b2Nv bHMgd2lsbCBiZSBldmFsdWF0ZWQgYW5kIHJlLXVzZWQgd2hlcmU8YnI+DQphcHBsaWNhYmxlIHRv IGJ1aWxkIHRoZSBjb25zdHJhaW5lZC1lbnZpcm9ubWVudCBzb2x1dGlvbjxicj4NCjxicj4NClJl Z2FyZHMsIEJlbm9pdDxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwcmU+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu IGxhbmc9IkVOLVVTIj4oMykgQ2xhcmlmeSB0aGUgc2NvcGU6PG86cD48L286cD48L3NwYW4+PC9w cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5PTEQ6PG86cD48L286cD48L3NwYW4+PC9wcmU+ DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5Ob3RlIHRoYXQgdGhlIGluaXRpYWwgZm9jdXMgaXMg b24gQ29BUCBhbmQgSFRUUCB3aXRoIERUTFMgYW5kIFRMUy48bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPk90aGVyIHNlY3VyaXR5IHByb3RvY29scyBtYXkg YmUgY29uc2lkZXJlZCBhcyBsb25nIGFzIHRoZSBwcmltYXJ5IGZvY3VzIGlzIG1haW50YWluZWQu Jm5ic3A7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+ T3RoZXIgYXBwbGljYXRpb24gcHJvdG9jb2xzIGFuZCBwcm90b2NvbHMgYXQgb3RoZXIgbGF5ZXJz IGluIHRoZSBzdGFjayBhcmUgb3V0IG9mIHNjb3BlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZT48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8 cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5ORVc8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+ PHNwYW4gbGFuZz0iRU4tVVMiPk5vdGUgdGhhdCB0aGUgaW5pdGlhbCBmb2N1cyBpcyBvbiBDb0FQ IGFuZCBIVFRQIHdpdGggRFRMUyBhbmQgVExTLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy ZT48c3BhbiBsYW5nPSJFTi1VUyI+T3RoZXIgc2VjdXJpdHkgcHJvdG9jb2xzIG1heSBiZSBjb25z aWRlcmVkIGFzIGxvbmcgYXMgdGhlIHByaW1hcnkgZm9jdXMgaXMgbWFpbnRhaW5lZC4mbmJzcDsg PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUgZ3Jv dXAgaXMgc2NvcGVkIHRvIHdvcmsgb25seSBvbiB0aGUgd2ViIHByb3RvY29scyBhbmQgZGF0YSBj YXJyaWVkIHdpdGhpbiB0aGVtLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs YW5nPSJFTi1VUyI+RU5EPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i RU4tVVMiPig0KSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBVcGRhdGUgbWlsZXN0b25lcyBmb3Ig dGhlIHVzZSBjYXNlICZhbXA7IHJlcXVpcmVtZW50cyBkb2N1bWVudDo8bzpwPjwvbzpwPjwvc3Bh bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPk9MRDo8bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPkp1bCAyMDE1IFN1Ym1pdCDigJxVc2UgY2Fz ZXMgYW5kIFJlcXVpcmVtZW50c+KAnSBkb2N1bWVudCB0byBJRVNHIGZvciBwdWJsaWNhdGlvbiBh cyBpbmZvcm1hdGlvbmFsIFJGQy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs YW5nPSJFTi1VUyI+TkVXPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9 IkVOLVVTIj5EZWMgMjAxNCBPcHRpb25hbGx5LCBzdWJtaXQgJnF1b3Q7VXNlIGNhc2VzIGFuZCBS ZXF1aXJlbWVudHMmcXVvdDsgZG9jdW1lbnQgdG8gdGhlIElFU0cgZm9yIHB1YmxpY2F0aW9uIGFz IGFuIEluZm9ybWF0aW9uYWwgUkZDLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh biBsYW5nPSJFTi1VUyI+RU5EPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFu Zz0iRU4tVVMiPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4t VVMiPkNoYXJ0ZXIgY2hhcnRlci1pZXRmLWFjZS0wMC0wMjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+QXV0aGVudGljYXRpb24gYW5kIEF1dGhvcml6YXRp b24gZm9yIENvbnN0cmFpbmVkPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh bmc9IkVOLVVTIj5FbnZpcm9ubWVudCAoQUNFKTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy ZT48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJl PjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUgSUVURiBoYXMgcmVjZW50bHkgZGV2ZWxvcGVkIHByb3Rv Y29scyBmb3IgdXNlIGluIGNvbnN0cmFpbmVkPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl PjxzcGFuIGxhbmc9IkVOLVVTIj5lbnZpcm9ubWVudHMsIHdoZXJlIG5ldHdvcmsgbm9kZXMgYXJl IGxpbWl0ZWQgaW4gQ1BVLCBtZW1vcnkgYW5kIHBvd2VyLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPlJFU1QgYXJjaGl0ZWN0dXJlIGlzIHdpZGVseSB1 c2VkIGZvciBzdWNoIGNvbnN0cmFpbmVkIGVudmlyb25tZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPkl0IGhhcyBiZWVuIG9ic2VydmVkIHRoYXQg SW50ZXJuZXQgcHJvdG9jb2xzIGNhbiBiZSBhcHBsaWVkIHRvIHRoZXNlPG86cD48L286cD48L3Nw YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5jb25zdHJhaW5lZCBlbnZpcm9ubWVu dHMsIG9mdGVuIG9ubHkgcmVxdWlyaW5nIG1pbm9yIHR3ZWFraW5nIGFuZDxvOnA+PC9vOnA+PC9z cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+cHJvZmlsaW5nLiBJbiBvdGhlciBj YXNlcywgbmV3IHByb3RvY29scyBoYXZlIGJlZW4gZGVmaW5lZCB0byBhZGRyZXNzPG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj50aGUgc3BlY2lmaWMgcmVx dWlyZW1lbnRzIG9mIGNvbnN0cmFpbmVkIGVudmlyb25tZW50cy4gQW4gZXhhbXBsZSBvZjxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+c3VjaCBhIHByb3Rv Y29sIGlzIHRoZSBDb25zdHJhaW5lZCBBcHBsaWNhdGlvbiBQcm90b2NvbCAoQ29BUCkuPG86cD48 L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPkFzIGluIG90aGVyIGVu dmlyb25tZW50cywgYXV0aGVudGljYXRpb24gYW5kIGF1dGhvcml6YXRpb24gcXVlc3Rpb25zPG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5hbHNvIGFyaXNl IGluIGNvbnN0cmFpbmVkIGVudmlyb25tZW50cy4gRm9yIGV4YW1wbGUsIGEgZG9vciBsb2NrIGhh cyB0bzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+YXV0 aG9yaXplIHRoZSBwZXJzb24gc2Vla2luZyBhY2Nlc3MgdXNpbmcgYSAmcXVvdDtkaWdpdGFsIGtl eSZxdW90Oy4gV2hlcmUgaXMgdGhlPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu IGxhbmc9IkVOLVVTIj5hdXRob3JpemF0aW9uIHBvbGljeSBzdG9yZWQ/IEhvdyBkb2VzIHRoZSBk aWdpdGFsIGtleSBjb21tdW5pY2F0ZSB3aXRoPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl PjxzcGFuIGxhbmc9IkVOLVVTIj50aGUgbG9jaz8gRG9lcyB0aGUgbG9jayBpbnRlcmFjdCB3aXRo IGFuIGF1dGhvcml6YXRpb24gc2VydmVyIHRvIG9idGFpbjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+YXV0aG9yaXphdGlvbiBpbmZvcm1hdGlvbj8gSG93 IGNhbiBhY2Nlc3MgYmUgdGVtcG9yYXJpbHkgZ3JhbnRlZCB0bzxvOnA+PC9vOnA+PC9zcGFuPjwv cHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+b3RoZXIgcGVyc29ucz8gSG93IGNhbiBhY2Nl c3MgYmUgcmV2b2tlZD8gVGhlc2UgdHlwZXMgb2YgcXVlc3Rpb25zIGhhdmU8bzpwPjwvbzpwPjwv c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPmJlZW4gYW5zd2VyZWQgYnkgZXhp c3RpbmcgcHJvdG9jb2xzIGZvciB1c2UgY2FzZXMgb3V0c2lkZSBjb25zdHJhaW5lZDxvOnA+PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+ZW52aXJvbm1lbnRzLCBo b3dldmVyIGluIGNvbnN0cmFpbmVkIGVudmlyb25tZW50cywgYWRkaXRpb25hbCBhbmQ8bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPmRpZmZlcmVudCByZXF1 aXJlbWVudHMgcG9zZSBjaGFsbGVuZ2VzIGZvciB0aGUgdXNlIG9mIHZhcmlvdXMgc2VjdXJpdHk8 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPnByb3RvY29s cy4gSW4gcGFydGljdWxhciwgdGhlIG5lZWQgYXJpc2VzIGZvciBhIGR5bmFtaWMgYW5kIGZpbmUg Z3JhaW5lZDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+ YWNjZXNzIGNvbnRyb2wgbWVjaGFuaXNtLCB3aGVyZSBjbGllbnRzIGFuZC9vciByZXNvdXJjZSBz ZXJ2ZXJzIGFyZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1V UyI+Y29uc3RyYWluZWQuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i RU4tVVMiPlRoZSBJRVRGIGhhcyBhIGxvbmcgaGlzdG9yeSBpbiBkZXZlbG9waW5nIHRocmVlLXBh cnR5IGF1dGhlbnRpY2F0aW9uIGFuZDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh biBsYW5nPSJFTi1VUyI+YXV0aG9yaXphdGlvbiBwcm90b2NvbHMgZm9yIGRpc3RyaWJ1dGVkIGVu dmlyb25tZW50cy4gRXhhbXBsZXMgaW5jbHVkZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy ZT48c3BhbiBsYW5nPSJFTi1VUyI+S2VyYmVyb3MsIHRoZSBQdWJsaWMgS2V5IEluZnJhc3RydWN0 dXJlIChQS0kpLCBhbmQgdGhlIFdlYjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh biBsYW5nPSJFTi1VUyI+QXV0aG9yaXphdGlvbiBQcm90b2NvbCAoT0F1dGgpLiBBbGwgdGhlc2Ug cHJvdG9jb2xzIGVuam95IHdpZGVzcHJlYWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+ PHNwYW4gbGFuZz0iRU4tVVMiPmRlcGxveW1lbnQgb24gdGhlIEludGVybmV0LiBBbHRob3VnaCB0 aGV5IGFsbCBhaW0gdG8gc29sdmUgYSBzaW1pbGFyPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5nb2FsLCBhdCBhbiBhYnN0cmFjdCBsZXZlbCwgdGhleSBv ZmZlciBxdWl0ZSBkaWZmZXJlbnQgZnVuY3Rpb25zIGFuZDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+dXRpbGl6ZSBkaWZmZXJlbnQgbWVzc2FnZSBleGNo YW5nZXMuIFRoZXNlIGRpZmZlcmVuY2VzIHJlc3VsdCBmcm9tIHRoZTxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+bWFpbiBkZXBsb3ltZW50IHVzZSBjYXNl cyB0aGV5IHdlcmUgZGVzaWduZWQgZm9yIHJlc3BlY3RpdmVseS48bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+UmVxdWlyZW1lbnRzIGRlcml2ZWQgZnJvbSB1 c2UgY2FzZXMgaW5kaWNhdGUgdGhlIHN1aXRhYmlsaXR5IG9mIGV4aXN0aW5nPG86cD48L286cD48 L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj53b3JrIGFzIGEgc29sdXRpb24g Zm9yIGNvbnN0cmFpbmVkIGVudmlyb25tZW50cy4gVGhlc2UgcHJvdG9jb2xzLDxvOnA+PC9vOnA+ PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+aG93ZXZlciwgd2VyZSBub3Qg b3B0aW1pemVkIGZvciBjb25zdHJhaW5lZCBlbnZpcm9ubWVudHMuIEFkZGl0aW9uYWw8bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPnJlcXVpcmVtZW50cyB0 aGF0IG5lZWQgdG8gYmUgdGFrZW4gaW50byBhY2NvdW50IGFyZSB0aGUgbGFjayBvZiBhPG86cD48 L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5zdWl0YWJsZSB1c2Vy LWludGVyZmFjZSBhbmQgdGhlIGluYWJpbGl0eSBvZiBlbWJlZGRlZCBkZXZpY2VzIHRvIGNvbnRh Y3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPmFuIGF1 dGhvcml6YXRpb24gc2VydmVyIGluIHJlYWwtdGltZSB3aXRoIGV2ZXJ5IHJlc291cmNlIGFjY2Vz cyByZXF1ZXN0PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVT Ij5kdWUgdG8gaW50ZXJtaXR0ZW50IGNvbm5lY3Rpdml0eSwgZXRjLjxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGlzIHdvcmtpbmcgZ3JvdXAgdGhlcmVm b3JlIGFpbXMgdG8gcHJvZHVjZSBhIHN0YW5kYXJkaXplZCBzb2x1dGlvbiBmb3I8bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPmF1dGhlbnRpY2F0aW9uIGFu ZCBhdXRob3JpemF0aW9uIHRvIGVuYWJsZSBhdXRob3JpemVkIGFjY2VzcyAoR0VULCBQVVQsIFBP U1QsIDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+REVM RVRFKSB0byByZXNvdXJjZXMgaWRlbnRpZmllZCBieSBhIFVSSSBhbmQgaG9zdGVkIG9uIGEgcmVz b3VyY2U8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPnNl cnZlciBpbiBjb25zdHJhaW5lZCBlbnZpcm9ubWVudHMuIEFzIGEgc3RhcnRpbmcgcG9pbnQsIHRo ZSB3b3JraW5nPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVT Ij5ncm91cCB3aWxsIGFzc3VtZSB0aGF0IGFjY2VzcyB0byByZXNvdXJjZXMgYXQgYSByZXNvdXJj ZSBzZXJ2ZXIgYnkgYTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJF Ti1VUyI+Y2xpZW50IGRldmljZSB0YWtlcyBwbGFjZSB1c2luZyBDb0FQIGFuZCBpcyBwcm90ZWN0 ZWQgYnkgRFRMUy4gQm90aDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5n PSJFTi1VUyI+cmVzb3VyY2Ugc2VydmVyIGFuZCBjbGllbnQgbWF5IGJlIGNvbnN0cmFpbmVkLiBU aGlzIGFjY2VzcyB3aWxsIGJlPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh bmc9IkVOLVVTIj5tZWRpYXRlZCBieSBhbiBhdXRob3JpemF0aW9uIHNlcnZlciwgd2hpY2ggaXMg bm90IGNvbnNpZGVyZWQgdG8gYmU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g bGFuZz0iRU4tVVMiPmNvbnN0cmFpbmVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz cGFuIGxhbmc9IkVOLVVTIj5FeGlzdGluZyBhdXRoZW50aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlv biBwcm90b2NvbHMgd2lsbCBiZSB1c2VkIHdoZXJlPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5hcHBsaWNhYmxlIHRvIGJ1aWxkIHRoZSBjb25zdHJhaW5l ZC1lbnZpcm9ubWVudCBzb2x1dGlvbi4gVGhpcyByZXF1aXJlczxvOnA+PC9vOnA+PC9zcGFuPjwv cHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+cmVsZXZhbnQgc3BlY2lmaWNhdGlvbnMgdG8g YmUgcmV2aWV3ZWQgZm9yIHN1aXRhYmlsaXR5LCBzZWxlY3RpbmcgYTxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+c3Vic2V0IG9mIHRoZW0gYW5kIHJlc3Ry aWN0aW5nIHRoZSBvcHRpb25zIHdpdGhpbiBlYWNoIG9mIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwv cHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+c3BlY2lmaWNhdGlvbnMuIFNvbWUgZnVuY3Rp b25hbGl0eSwgaG93ZXZlciwgbWF5IG5vdCBiZSBhdmFpbGFibGUgaW48bzpwPjwvbzpwPjwvc3Bh bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPmV4aXN0aW5nIHByb3RvY29scywgaW4g d2hpY2ggY2FzZSB0aGUgc29sdXRpb24gbWF5IGFsc28gaW52b2x2ZSBuZXc8bzpwPjwvbzpwPjwv c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPnByb3RvY29sIHdvcmsuIExldmVy YWdpbmcgZXhpc3Rpbmcgd29yayBtZWFucyB0aGUgd29ya2luZyBncm91cCBiZW5lZml0czxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+ZnJvbSBhdmFpbGFi bGUgc2VjdXJpdHkgYW5hbHlzaXMsIGltcGxlbWVudGF0aW9uLCBhbmQgZGVwbG95bWVudDxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+ZXhwZXJpZW5jZS4g TW9yZW92ZXIsIGEgc3RhbmRhcmRpemVkIHNvbHV0aW9uIGZvciBmZWRlcmF0ZWQ8bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPmF1dGhlbnRpY2F0aW9uIGFu ZCBhdXRob3JpemF0aW9uIHdpbGwgaGVscCB0byBzdGltdWxhdGUgdGhlIGRlcGxveW1lbnQ8bzpw PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPm9mIGNvbnN0cmFp bmVkIGRldmljZXMgdGhhdCBwcm92aWRlIGluY3JlYXNlZCBzZWN1cml0eS48bzpwPjwvbzpwPjwv c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+T25jZSBwcm9ncmVzcyBpbiBpZGVu dGlmeWluZyBzdWl0YWJsZSBjYW5kaWRhdGUgc29sdXRpb25zIGhhcyBiZWVuIG1hZGUsPG86cD48 L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj50aGUgd29ya2luZyBn cm91cCB3aWxsIHZlcmlmeSB3aGV0aGVyIHRoZSBzYW1lIG1lY2hhbmlzbXMgYXJlIGFsc288bzpw PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPmFwcGxpY2FibGUg YmV5b25kIHRoZSB1c2Ugb2YgQ29BUCBhbmQgRFRMUywgd2hpY2ggYXJlIHRoZSB0d28gbWFpbjxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+cHJvdG9jb2xz IHRoZSBncm91cCB3aWxsIGZvY3VzIG9uIGZvciBhY2Nlc3MgdG8gcmVzb3VyY2VzLiBJbjxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+cGFydGljdWxhciwg dGhlIGFiaWxpdHkgdG8gdXNlIHRoZSBkZXZlbG9wZWQgc29sdXRpb24gb3ZlciBIVFRQIGFuZCBU TFM8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPndpbGwg YmUgaW52ZXN0aWdhdGVkLiBOb3RlIHRoYXQgdGhlIGluaXRpYWwgZm9jdXMgaXMgb24gQ29BUCBh bmQgSFRUUCB3aXRoIERUTFMgYW5kIFRMUy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+ PHNwYW4gbGFuZz0iRU4tVVMiPk90aGVyIHNlY3VyaXR5IHByb3RvY29scyBtYXkgYmUgY29uc2lk ZXJlZCBhcyBsb25nIGFzIHRoZSBwcmltYXJ5IGZvY3VzIGlzIG1haW50YWluZWQuJm5ic3A7IDxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+VGhlIGdyb3Vw IGlzIHNjb3BlZCB0byB3b3JrIG9ubHkgb24gdGhlIHdlYiBwcm90b2NvbHMgYW5kIGRhdGEgY2Fy cmllZCB3aXRoaW4gdGhlbS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFu Zz0iRU4tVVMiPkZ1cnRoZXJtb3JlLCB0byBndWFyYW50ZWUgc21vb3RoIHRyYW5zaXRpb24sIHRo ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+aW50ZWdy YXRpb24gd2l0aCBleGlzdGluZyBkZXBsb3ltZW50cyB3aWxsIGJlIHN0dWRpZWQsIHBhcnRpY3Vs YXJseTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Y29u Y2VybmluZyB0aGUgdXNlIG9mIHByb3RvY29sIHRyYW5zbGF0aW9uIHByb3hpZXMuPG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPlRoaXMgd29yayBkb2VzIG5v dCBtYWtlIHRoZSBhc3N1bXB0aW9uIHRoYXQgdGhlIHBhcnR5IG9mZmVyaW5nPG86cD48L286cD48 L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5hcHBsaWNhdGlvbiBsYXllciBz ZXJ2aWNlcyBpcyBhbHdheXMgdGhlIHNhbWUgcGFydHkgb2ZmZXJpbmcgbmV0d29yazxvOnA+PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+YWNjZXNzIHNlcnZpY2Vz LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUgd29y a2luZyBncm91cCBoYXMgdGhlIGZvbGxvd2luZyB0YXNrczo8bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+MSkgUHJvZHVjZSB1c2UgY2FzZXMgYW5kIHJlcXVp cmVtZW50czxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4y KSBJZGVudGlmeSBhdXRoZW50aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlvbiBtZWNoYW5pc21zIHN1 aXRhYmxlIGZvcjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1V UyI+cmVzb3VyY2UgYWNjZXNzIGluIGNvbnN0cmFpbmVkIGVudmlyb25tZW50cy48bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+TWlsZXN0b25lczo8bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+SnVsIDIwMTQgU3VibWl0 ICZxdW90O1VzZSBjYXNlcyBhbmQgUmVxdWlyZW1lbnRzJnF1b3Q7IGFzIGEgV0cgaXRlbS48bzpw PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPkRlYyAyMDE0IFN1 Ym1pdCAmcXVvdDtBdXRoZW50aWNhdGlvbiBhbmQgQXV0aG9yaXphdGlvbiBTb2x1dGlvbiZxdW90 OyBhcyBhIFdHIGl0ZW0uPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9 IkVOLVVTIj5EZWMgMjAxNCBPcHRpb25hbGx5LCBzdWJtaXQgJnF1b3Q7VXNlIGNhc2VzIGFuZCBS ZXF1aXJlbWVudHMmcXVvdDsgZG9jdW1lbnQgPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl PjxzcGFuIGxhbmc9IkVOLVVTIj50byB0aGUgSUVTRyBmb3IgcHVibGljYXRpb24gYXMgYW4gSW5m b3JtYXRpb25hbCBSRkMuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9 IkVOLVVTIj5KdWwgMjAxNiBTdWJtaXQgJnF1b3Q7QXV0aGVudGljYXRpb24gYW5kIEF1dGhvcml6 YXRpb24gU29sdXRpb24mcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g bGFuZz0iRU4tVVMiPnNwZWNpZmljYXRpb24gdG8gdGhlIElFU0cgZm9yIHB1YmxpY2F0aW9uIGFz IGEgUHJvcG9zZWQgU3RhbmRhcmQuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g bGFuZz0iRU4tVVMiPlByb3Bvc2VkIE1pbGVzdG9uZXMgPG86cD48L286cD48L3NwYW4+PC9wcmU+ DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5ObyBtaWxlc3RvbmVzIGZvciBjaGFydGVyIGZvdW5k LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_34966E97BE8AD64EAE9D3D6E4DEE36F258153F43SZXEMA501MBSchi_-- From nobody Tue Jun 3 03:38:12 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5528F1A01AA for ; Tue, 3 Jun 2014 03:38:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.149 X-Spam-Level: * X-Spam-Status: No, score=1.149 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, SPF_HELO_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 h2bl4ymIHkFL for ; Tue, 3 Jun 2014 03:38:08 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66EF91A01A0 for ; Tue, 3 Jun 2014 03:38:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s53Ac0lr017223 for ; Tue, 3 Jun 2014 12:38:00 +0200 (CEST) Received: from [134.102.218.214] (dynamic-218-o.informatik.uni-bremen.de [134.102.218.214]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 1E29D1761 for ; Tue, 3 Jun 2014 12:38:00 +0200 (CEST) Message-ID: <538DA583.4070200@tzi.de> Date: Tue, 03 Jun 2014 12:37:55 +0200 From: Stefanie Gerdes User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "ace@ietf.org" X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ace/PKrrLKCEJ9NurVdehYkLmYjjsVk Subject: [Ace] Security Domains X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments $ace$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 10:38:10 -0000 Hi, In my draft about actors in the ACE architecture [1] I explained that the client (the one that wants to access a resource) and the resource server (the one that hosts the resource) might belong to different security domains. There is some discussion going on if this really is the case. I did not really get yet what the disagreement is about, so maybe someone can help me with that. I might be wrong, but I guess the fact that devices of different owners might need to interact with each other is not really the question, is it? The scenarios described in the use cases draft [2] indicate that this is often the case. In the container scenario, the device of the transport company will not belong to the supermarket chain. In the home scenario, Jeffreys device for getting access to Janes house will belong to Jeffrey and not to Jane. The device of the doctor which wants to access data on Johns heart rate monitor will not belong to John. If it is an emergency physician she might not even have seen John ever before. So maybe there is some misunderstanding about security domains. My intent for using this term was to emphasize the fact that C and RS do not know each other at the time when C sends its first resource request. This means, RS does not have any keys or other information about C and C does not have any keys or other information about RS. Do we disagree about this? Thanks, Steffi [1] http://tools.ietf.org/pdf/draft-gerdes-ace-actors-00.pdf [2] http://tools.ietf.org/id/draft-seitz-ace-usecases-00.txt From nobody Tue Jun 3 05:30:04 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B5AF1A0240; Tue, 3 Jun 2014 05:29:49 -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 8POsC-DfkXUu; Tue, 3 Jun 2014 05:29:44 -0700 (PDT) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 810E51A0261; Tue, 3 Jun 2014 05:29:43 -0700 (PDT) Received: by mail-la0-f54.google.com with SMTP id pv20so3367986lab.41 for ; Tue, 03 Jun 2014 05:29: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=hSis/5GFmBLfyq5yrpyzCuqruxIGvsH3ioJjzkD/Qyo=; b=WZoCTgjalekerhgNJSpF7KxD/Ip3755mJy/oP1njnFPw7MdP1pKfSr8SY2zRUhIQg4 e0e4h7Q5tdscK5EQrCdzXATkDUnBKOl/2o6jeQmtF9N82M75OSQDwUKn+yLaVaa7/Pct RETvfHHPQJmmfsqK0ULn8mdBw6LQoao9Ng/HUVfZssN0tV2GksDTcAxYpi2wMInKiWmh UrFNewSYd3Iv2zet28kP3U24dPzvGxtuUNMfXnVlDD9HS07Wk/iNsIu+6gdARNd6pD23 mJcRpHDZrFtpYeFBzRLPt7w14RnqS7F+arSWHBIO6C8wmeeekHtRJalOzXElSZ7Dvoos 8inQ== MIME-Version: 1.0 X-Received: by 10.112.149.71 with SMTP id ty7mr33119626lbb.34.1401798576196; Tue, 03 Jun 2014 05:29:36 -0700 (PDT) Received: by 10.112.33.36 with HTTP; Tue, 3 Jun 2014 05:29:36 -0700 (PDT) In-Reply-To: <34966E97BE8AD64EAE9D3D6E4DEE36F258153F43@SZXEMA501-MBS.china.huawei.com> References: <20140514221215.8150.56543.idtracker@ietfa.amsl.com> <34966E97BE8AD64EAE9D3D6E4DEE36F252B2A345@SZXEMA501-MBS.china.huawei.com> <34966E97BE8AD64EAE9D3D6E4DEE36F252B38978@SZXEMA501-MBS.china.huawei.com> <34966E97BE8AD64EAE9D3D6E4DEE36F258140E59@SZXEMA501-MBX.china.huawei.com> <538DA047.7080902@cisco.com> <34966E97BE8AD64EAE9D3D6E4DEE36F258153F43@SZXEMA501-MBS.china.huawei.com> Date: Tue, 3 Jun 2014 08:29:36 -0400 Message-ID: From: Kathleen Moriarty To: Likepeng Content-Type: multipart/alternative; boundary=047d7b3a8ada2e514104faedaa7f Archived-At: http://mailarchive.ietf.org/arch/msg/ace/V-s5c9QLzf7pJiBUrC2W6eUOUVo Cc: Benoit Claise , "adrian@olddog.co.uk" , "ace@ietf.org" , The IESG , "aaa-doctors@ietf.org" Subject: Re: [Ace] Revised charter proposal: charter-ietf-ace-00-02 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments $ace$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 12:29:49 -0000 --047d7b3a8ada2e514104faedaa7f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Kepeng, If we are at a point where I can update the charter, seems that way, please send the latest version that has been agreed upon and I'll take care of the update. Thanks. On Tue, Jun 3, 2014 at 6:31 AM, Likepeng wrote: > Hi Benoit, > > > > >Not only would I keep "AAA", > > > > OK. > > > > >but I would propose > > > > >OLD: > > >Existing authentication and authorization protocols will be used where > > applicable to build the constrained-environment solution. > > > > >NEW: > > Existing authentication and authorization protocols will be evaluated and > re-used where > > applicable to build the constrained-environment solution. > > > > OK, fine with me. > > > > Thanks for the feedback. > > > > Kind Regards > > Kepeng > > > > *=E5=8F=91=E4=BB=B6=E4=BA=BA:* Benoit Claise [mailto:bclaise@cisco.com] > *=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4:* 2014=E5=B9=B46=E6=9C=883=E6=97=A5= 12:16 > *=E6=94=B6=E4=BB=B6=E4=BA=BA:* Likepeng; Kathleen Moriarty; adrian@olddog= .co.uk > *=E6=8A=84=E9=80=81:* aaa-doctors@ietf.org; The IESG; ace@ietf.org > *=E4=B8=BB=E9=A2=98:* Re: Revised charter proposal: charter-ietf-ace-00-0= 2 > > > > Hi, > > Hello all, > > > > Based on recent discussions, I made a revised charter proposal, as includ= ed in this email, not on the webpage yet. > > > > Please take a look and let us know if you have any further comments. > > > > @Adrian and @Benoit, please check if the proposed texts can resolve your = comments. > > > > Thanks, > > Kind Regards > > Kepeng > > > > -------------------------------------------------------------------------= ---------------------------------------------------------------------------= --------- > > Compared with charter-ietf-ace-00-01 on the webpage, the changes are: > > > > (1) Add one clarification sentence about REST architecture: > > OLD > > The IETF has recently developed protocols for use in constrained > > environments, where network nodes are limited in CPU, memory and power. > > REST architecture is widely used for such constrained environments. > > > > NEW > > The IETF has recently developed protocols for use in constrained > > environments, where network nodes are limited in CPU, memory and power. > > REST architecture is widely used for such constrained environments. > > END > > Considering that OLD is > > OLD > > The IETF has recently developed protocols for use in constrained > > environments, where network nodes are limited in CPU, memory and power. > > ... fine with me > > > > > > (2) Remove =E2=80=9CAAA protocol=E2=80=9D from the charter: > > OLD > > The IETF has a long history in developing three-party authentication and > > authorization protocols for distributed environments. Examples include > > Kerberos, the Public Key Infrastructure (PKI), the Authentication, > > Authorization and Accounting (AAA) infrastructure, and the Web > > Authorization Protocol (OAuth). > > > > NEW > > The IETF has a long history in developing three-party authentication and > > authorization protocols for distributed environments. Examples include > > Kerberos, the Public Key Infrastructure (PKI), and the Web Authorization = Protocol (OAuth). > > END > > We have AAA-doctors telling: maybe RADIUS is applicable? > Personally, I don't know and it doesn't matter at this point. > We received feedback such as: > > Let's be clear here: It was never said (in the charter or anywhere else i= n > the group to my knowledge) that RADIUS (or indeed any other AAA protocol) > would not run on constrained devices (RFC 7228). The charter simply said > the protocols were not optimised for constrained devices. That does not > preclude considering any protocol for suitability for constrained devices > either a) as is, b) in a restricted way or c) in an adapted way. > > So, at this stage, I don't think any protocols should be excluded from > consideration and should certainly not be eliminated on a hunch that they > might be "too big". Let's do the assessment properly at the appropriate > time. As a reminder - the focus now is to complete the charter. > > Or > > >>The Charter makes a number of assertions that are provably false, such = as that AAA protocols are inappropriate for constrained environments. > > In fact, the charter does not say that. But to avoid confusion, let's rem= ove AAA protocol from the charter. > > > > In the charter, we mentioned that we want to reuse existing authenticatio= n and authorization protocols where applicable to build the constrained-env= ironment solution. > > ... which I read as: let's consider the AAA protocols, and evaluate if > they would work in constrained devices. > I don't understand the logic: why do you want to remove AAA from the > charter? > Not only would I keep "AAA", but I would propose > > OLD: > Existing authentication and authorization protocols will be used where > applicable to build the constrained-environment solution > > NEW: > Existing authentication and authorization protocols will be evaluated and > re-used where > applicable to build the constrained-environment solution > > Regards, Benoit > > > > > > (3) Clarify the scope: > > OLD: > > Note that the initial focus is on CoAP and HTTP with DTLS and TLS. > > Other security protocols may be considered as long as the primary focus i= s maintained. > > Other application protocols and protocols at other layers in the stack ar= e out of scope. > > > > NEW > > Note that the initial focus is on CoAP and HTTP with DTLS and TLS. > > Other security protocols may be considered as long as the primary focus i= s maintained. > > The group is scoped to work only on the web protocols and data carried wi= thin them. > > END > > > > (4) Update milestones for the use case & requirements document: > > OLD: > > Jul 2015 Submit =E2=80=9CUse cases and Requirements=E2=80=9D document to = IESG for publication as informational RFC. > > > > NEW > > Dec 2014 Optionally, submit "Use cases and Requirements" document to the = IESG for publication as an Informational RFC. > > END > > > > -------------------------------------------------------------------------= ---------------------------------------------------------------------------= ------------------------ > > Charter charter-ietf-ace-00-02 > > Authentication and Authorization for Constrained > > Environment (ACE) > > > > The IETF has recently developed protocols for use in constrained > > environments, where network nodes are limited in CPU, memory and power. > > REST architecture is widely used for such constrained environments. > > It has been observed that Internet protocols can be applied to these > > constrained environments, often only requiring minor tweaking and > > profiling. In other cases, new protocols have been defined to address > > the specific requirements of constrained environments. An example of > > such a protocol is the Constrained Application Protocol (CoAP). > > > > As in other environments, authentication and authorization questions > > also arise in constrained environments. For example, a door lock has to > > authorize the person seeking access using a "digital key". Where is the > > authorization policy stored? How does the digital key communicate with > > the lock? Does the lock interact with an authorization server to obtain > > authorization information? How can access be temporarily granted to > > other persons? How can access be revoked? These types of questions have > > been answered by existing protocols for use cases outside constrained > > environments, however in constrained environments, additional and > > different requirements pose challenges for the use of various security > > protocols. In particular, the need arises for a dynamic and fine grained > > access control mechanism, where clients and/or resource servers are > > constrained. > > > > The IETF has a long history in developing three-party authentication and > > authorization protocols for distributed environments. Examples include > > Kerberos, the Public Key Infrastructure (PKI), and the Web > > Authorization Protocol (OAuth). All these protocols enjoy widespread > > deployment on the Internet. Although they all aim to solve a similar > > goal, at an abstract level, they offer quite different functions and > > utilize different message exchanges. These differences result from the > > main deployment use cases they were designed for respectively. > > > > Requirements derived from use cases indicate the suitability of existing > > work as a solution for constrained environments. These protocols, > > however, were not optimized for constrained environments. Additional > > requirements that need to be taken into account are the lack of a > > suitable user-interface and the inability of embedded devices to contact > > an authorization server in real-time with every resource access request > > due to intermittent connectivity, etc. > > > > This working group therefore aims to produce a standardized solution for > > authentication and authorization to enable authorized access (GET, PUT, P= OST, > > DELETE) to resources identified by a URI and hosted on a resource > > server in constrained environments. As a starting point, the working > > group will assume that access to resources at a resource server by a > > client device takes place using CoAP and is protected by DTLS. Both > > resource server and client may be constrained. This access will be > > mediated by an authorization server, which is not considered to be > > constrained. > > > > Existing authentication and authorization protocols will be used where > > applicable to build the constrained-environment solution. This requires > > relevant specifications to be reviewed for suitability, selecting a > > subset of them and restricting the options within each of the > > specifications. Some functionality, however, may not be available in > > existing protocols, in which case the solution may also involve new > > protocol work. Leveraging existing work means the working group benefits > > from available security analysis, implementation, and deployment > > experience. Moreover, a standardized solution for federated > > authentication and authorization will help to stimulate the deployment > > of constrained devices that provide increased security. > > > > Once progress in identifying suitable candidate solutions has been made, > > the working group will verify whether the same mechanisms are also > > applicable beyond the use of CoAP and DTLS, which are the two main > > protocols the group will focus on for access to resources. In > > particular, the ability to use the developed solution over HTTP and TLS > > will be investigated. Note that the initial focus is on CoAP and HTTP wit= h DTLS and TLS. > > Other security protocols may be considered as long as the primary focus i= s maintained. > > The group is scoped to work only on the web protocols and data carried wi= thin them. > > Furthermore, to guarantee smooth transition, the > > integration with existing deployments will be studied, particularly > > concerning the use of protocol translation proxies. > > > > This work does not make the assumption that the party offering > > application layer services is always the same party offering network > > access services. > > > > The working group has the following tasks: > > > > 1) Produce use cases and requirements > > > > 2) Identify authentication and authorization mechanisms suitable for > > resource access in constrained environments. > > > > Milestones: > > > > Jul 2014 Submit "Use cases and Requirements" as a WG item. > > Dec 2014 Submit "Authentication and Authorization Solution" as a WG item. > > Dec 2014 Optionally, submit "Use cases and Requirements" document > > to the IESG for publication as an Informational RFC. > > Jul 2016 Submit "Authentication and Authorization Solution" > > specification to the IESG for publication as a Proposed Standard. > > > > Proposed Milestones > > No milestones for charter found. > > > --=20 Best regards, Kathleen --047d7b3a8ada2e514104faedaa7f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Kepeng,

If we are at a point where I= can update the charter, seems that way, please send the latest version tha= t has been agreed upon and I'll take care of the update.

Thanks.

On Tue, Jun 3, 2014 at 6:31 AM, Likepeng <likepeng@huaw= ei.com> wrote:

Hi Benoit,=

=C2= =A0

>Not on= ly would I keep "AAA",

=C2= =A0

OK.<= u>

=C2= =A0

>but I = would propose

=C2= =A0

>OLD:

>Existi= ng authentication and authorization protocols will be used where<= /u>

appl= icable to build the constrained-environment solution.<= /p>

=C2= =A0

>NEW:

Existing a= uthentication and authorization protocols will be evaluated and re-used whe= re

appl= icable to build the constrained-environment solution.<= /p>
=C2= =A0

OK, fine w= ith me.

=C2= =A0

Thanks for= the feedback.

=C2= =A0

Kind Regar= ds

Kepeng<= /u>

=C2= =A0

=E5=8F=91=E4=BB=B6=E4=BA=BA: Benoit Claise [m= ailto:bclaise@cisco.= com]
=E5=8F=91=E9=80= =81=E6=97=B6=E9=97=B4: 2014=E5=B9=B46=E6=9C=883=E6=97=A5 12:16

=E6=94=B6=E4=BB=B6=E4=BA=BA: Likepeng; Kathleen Moriarty; <= a href=3D"mailto:adrian@olddog.co.uk" target=3D"_blank">adrian@olddog.co.uk=

=E6=8A=84=E9=80=81: aaa= -doctors@ietf.org; The IESG; ace@ietf.org

=E4=B8=BB=E9=A2=98: Re: Revised charter proposal: charter-ietf-ace-00-0= 2

=C2=A0

= Hi,

Hello all,

=C2=A0

Based on recent discussions, I made a revised cha= rter proposal, as included in this email, not on the webpage yet.

=C2=A0

Please take a look and let us know if you have an= y further comments.

=C2=A0

@Adrian and @Benoit, please check if the proposed= texts can resolve your comments.

=C2=A0

Thanks,

Kind Regards

Kepeng

=C2=A0

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

Compared with charter-ietf-ace-00-01 on the webpa= ge, the changes are:

=C2=A0

(1)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Add one clarifi= cation sentence about REST architecture:

OLD

The IETF has recently developed protocols for use= in constrained

environments, where network nodes are limited in = CPU, memory and power.

REST architecture is widely used for such constra= ined environments.

=C2=A0

NEW

The IETF has recently developed protocols for use= in constrained

environments, where network nodes are limited in = CPU, memory and power.

REST architecture is widely used for such constra= ined environments.

END

Considering that OLD is<= u>

OLD

The IETF has recently develo= ped protocols for use in constrained<= /u>

environments, where network = nodes are limited in CPU, memory and power. =

... fine with me

=C2=A0

=C2=A0

(2)=C2=A0=C2=A0=C2=A0=C2=A0 Remove =E2=80=9CAAA p= rotocol=E2=80=9D from the charter:

OLD

The IETF has a long history in developing three-p= arty authentication and

authorization protocols for distributed environme= nts. Examples include

Kerberos, the Public Key Infrastructure (PKI), th= e Authentication,

Authorization and Accounting (AAA) infrastructure= , and the Web

Authorization Protocol (OAuth).

=C2=A0

NEW

The IETF has a long history in developing three-p= arty authentication and

authorization protocols for distributed environme= nts. Examples include

Kerberos, the Public Key Infrastructure (PKI), an= d the Web Authorization Protocol (OAuth).

END

We have AAA-doctors telling: ma= ybe RADIUS is applicable?
Personally, I don't know and it doesn't matter at this point.
We received feedback such as:

Let's be clear here: It was= never said (in the charter or anywhere else in the group to my knowledge) = that RADIUS (or indeed any other AAA protocol) would not run on constrained= devices (RFC 7228). The charter simply said the protocols were not optimised for constrained devices. That does n= ot preclude considering any protocol for suitability for constrained device= s either a) as is, b) in a restricted way or c) in an adapted way.

So, at this stage, I don't think any protocols should be excluded from = consideration and should certainly not be eliminated on a hunch that they m= ight be "too big". Let's do the assessment properly at the ap= propriate time. As a reminder - the focus now is to complete the charter.

Or

>>The Charter makes a number of assertions = that are provably false, such as that AAA protocols are inappropriate for c= onstrained environments.

In fact, the charter does not say that. But to av= oid confusion, let's remove AAA protocol from the charter.

=C2=A0

In the charter, we mentioned that we want to reus= e existing authentication and authorization protocols where applicable to b= uild the constrained-environment solution.

... which I read as: let's = consider the AAA protocols, and evaluate if they would work in constrained = devices.
I don't understand the logic: why do you want to remove AAA from the ch= arter?
Not only would I keep "AAA", but I would propose

OLD:
Existing authentication and authorization protocols will be used where
applicable to build the constrained-environment solution

NEW:
Existing authentication and authorization protocols will be evaluated and r= e-used where
applicable to build the constrained-environment solution

Regards, Benoit

=C2=A0

=C2=A0

(3) Clarify the scope:

OLD:

Note that the initial focus is on CoAP and HTTP w= ith DTLS and TLS.

Other security protocols may be considered as lon= g as the primary focus is maintained.=C2=A0

Other application protocols and protocols at othe= r layers in the stack are out of scope.

=C2=A0

NEW

Note that the initial focus is on CoAP and HTTP w= ith DTLS and TLS.

Other security protocols may be considered as lon= g as the primary focus is maintained.=C2=A0

The group is scoped to work only on the web proto= cols and data carried within them.

END

=C2=A0

(4)=C2=A0=C2=A0=C2=A0=C2=A0 Update milestones for= the use case & requirements document:

OLD:

Jul 2015 Submit =E2=80=9CUse cases and Requiremen= ts=E2=80=9D document to IESG for publication as informational RFC.

=C2=A0

NEW

Dec 2014 Optionally, submit "Use cases and R= equirements" document to the IESG for publication as an Informational = RFC.

END

=C2=A0

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

Charter charter-ietf-ace-00-02

Authentication and Authorization for Constrained<= u>

Environment (ACE)

=C2=A0

The IETF has recently developed protocols for use= in constrained

environments, where network nodes are limited in = CPU, memory and power.

REST architecture is widely used for such constra= ined environments.

It has been observed that Internet protocols can = be applied to these

constrained environments, often only requiring mi= nor tweaking and

profiling. In other cases, new protocols have bee= n defined to address

the specific requirements of constrained environm= ents. An example of

such a protocol is the Constrained Application Pr= otocol (CoAP).

=C2=A0

As in other environments, authentication and auth= orization questions

also arise in constrained environments. For examp= le, a door lock has to

authorize the person seeking access using a "= ;digital key". Where is the

authorization policy stored? How does the digital= key communicate with

the lock? Does the lock interact with an authoriz= ation server to obtain

authorization information? How can access be temp= orarily granted to

other persons? How can access be revoked? These t= ypes of questions have

been answered by existing protocols for use cases= outside constrained

environments, however in constrained environments= , additional and

different requirements pose challenges for the us= e of various security

protocols. In particular, the need arises for a d= ynamic and fine grained

access control mechanism, where clients and/or re= source servers are

constrained.

=C2=A0

The IETF has a long history in developing three-p= arty authentication and

authorization protocols for distributed environme= nts. Examples include

Kerberos, the Public Key Infrastructure (PKI), an= d the Web

Authorization Protocol (OAuth). All these protoco= ls enjoy widespread

deployment on the Internet. Although they all aim= to solve a similar

goal, at an abstract level, they offer quite diff= erent functions and

utilize different message exchanges. These differ= ences result from the

main deployment use cases they were designed for = respectively.

=C2=A0

Requirements derived from use cases indicate the = suitability of existing

work as a solution for constrained environments. = These protocols,

however, were not optimized for constrained envir= onments. Additional

requirements that need to be taken into account a= re the lack of a

suitable user-interface and the inability of embe= dded devices to contact

an authorization server in real-time with every r= esource access request

due to intermittent connectivity, etc.<= /u>

=C2=A0

This working group therefore aims to produce a st= andardized solution for

authentication and authorization to enable author= ized access (GET, PUT, POST,

DELETE) to resources identified by a URI and host= ed on a resource

server in constrained environments. As a starting= point, the working

group will assume that access to resources at a r= esource server by a

client device takes place using CoAP and is prote= cted by DTLS. Both

resource server and client may be constrained. Th= is access will be

mediated by an authorization server, which is not= considered to be

constrained.

=C2=A0

Existing authentication and authorization protoco= ls will be used where

applicable to build the constrained-environment s= olution. This requires

relevant specifications to be reviewed for suitab= ility, selecting a

subset of them and restricting the options within= each of the

specifications. Some functionality, however, may = not be available in

existing protocols, in which case the solution ma= y also involve new

protocol work. Leveraging existing work means the= working group benefits

from available security analysis, implementation,= and deployment

experience. Moreover, a standardized solution for= federated

authentication and authorization will help to sti= mulate the deployment

of constrained devices that provide increased sec= urity.

=C2=A0

Once progress in identifying suitable candidate s= olutions has been made,

the working group will verify whether the same me= chanisms are also

applicable beyond the use of CoAP and DTLS, which= are the two main

protocols the group will focus on for access to r= esources. In

particular, the ability to use the developed solu= tion over HTTP and TLS

will be investigated. Note that the initial focus= is on CoAP and HTTP with DTLS and TLS.

Other security protocols may be considered as lon= g as the primary focus is maintained.=C2=A0

The group is scoped to work only on the web proto= cols and data carried within them.

Furthermore, to guarantee smooth transition, the<= u>

integration with existing deployments will be stu= died, particularly

concerning the use of protocol translation proxie= s.

=C2=A0

This work does not make the assumption that the p= arty offering

application layer services is always the same par= ty offering network

access services.

=C2=A0

The working group has the following tasks:=

=C2=A0

1) Produce use cases and requirements

=C2=A0

2) Identify authentication and authorization mech= anisms suitable for

resource access in constrained environments.

=C2=A0

Milestones:

=C2=A0

Jul 2014 Submit "Use cases and Requirements&= quot; as a WG item.

Dec 2014 Submit "Authentication and Authoriz= ation Solution" as a WG item.

Dec 2014 Optionally, submit "Use cases and R= equirements" document

to the IESG for publication as an Informational R= FC.

Jul 2016 Submit "Authentication and Authoriz= ation Solution"

specification to the IESG for publication as a Pr= oposed Standard.

=C2=A0

Proposed Milestones

No milestones for charter found.

=C2=A0

--

Best regards,
Kathleen

--047d7b3a8ada2e514104faedaa7f-- From nobody Tue Jun 3 06:52:12 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCFCD1A029A for ; Tue, 3 Jun 2014 06:52:10 -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 ZfCBFkYDsDOL for ; Tue, 3 Jun 2014 06:52:07 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6924E1A0295 for ; Tue, 3 Jun 2014 06:52:07 -0700 (PDT) Received: by mail-ie0-f170.google.com with SMTP id to1so4805840ieb.1 for ; Tue, 03 Jun 2014 06:52:01 -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:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=tr3Blqemp83+f5hp6nc+aGFjgvc7MrE6x+3Hj1uxovQ=; b=jNFSs1XyMPMqT7nvPhJec1LPhB0O+nX422Z+l34s6E793zdZp1iRsKAezu5r3BYvD0 664+erQY6eqkvXgSDGlWcdUYZEksNbGCX2WwKnSZnDem0HdUIEpitTDCaK/qcQ1Lg8+6 dxIxJSdn05EJ9QFIlQZ7XJ86ao7y/nYZJ9MDgx4ZW6W8E8e9GL9eZ+fRjEfLTfhlNj81 49sOSufv+N9ymGup7TH1DkEonaeXa5+yJdGAcBomqofIz6nhQnQvPzQgNxn2bGCvotuT LvekuQ2NSdC2R3WAoa5aO3U6/vU2li4athNAx6vfoZFJ/BiYZEf9aGzdzhfhNgWlXfX7 rIPQ== X-Received: by 10.50.25.3 with SMTP id y3mr7668496igf.47.1401803521306; Tue, 03 Jun 2014 06:52:01 -0700 (PDT) Received: from [192.168.1.103] (CPE0013100e2c51-CM001cea35caa6.cpe.net.cable.rogers.com. [99.231.3.110]) by mx.google.com with ESMTPSA id b3sm2489845igl.3.2014.06.03.06.52.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Jun 2014 06:52:00 -0700 (PDT) Message-ID: <538DD2FD.2020400@gmail.com> Date: Tue, 03 Jun 2014 09:51:57 -0400 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Stefanie Gerdes , "ace@ietf.org" References: <538DA583.4070200@tzi.de> In-Reply-To: <538DA583.4070200@tzi.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ace/fvnlryxieia0fC1lNmqPDvVVDs4 Subject: Re: [Ace] Security Domains X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments $ace$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 13:52:10 -0000 Hi Steffi: I think authorization mechanisms should indeed facilitate deployment in heterogeneous trust domain settings, where the term "heterogeneous" applies across the entire device and system's life cycle. BTW - I have not seen the "discussion going on" and "disagreement" regarding this topic on the ACE mailing list. Rene == There is some discussion going on if this really is the case. I did not really get yet what the disagreement is about, so maybe someone can help me with that. On 6/3/2014 6:37 AM, Stefanie Gerdes wrote: > Hi, > > In my draft about actors in the ACE architecture [1] I explained that > the client (the one that wants to access a resource) and the resource > server (the one that hosts the resource) might belong to different > security domains. There is some discussion going on if this really is > the case. > > I did not really get yet what the disagreement is about, so maybe > someone can help me with that. > > I might be wrong, but I guess the fact that devices of different owners > might need to interact with each other is not really the question, is > it? The scenarios described in the use cases draft [2] indicate that > this is often the case. In the container scenario, the device of the > transport company will not belong to the supermarket chain. In the home > scenario, Jeffreys device for getting access to Janes house will belong > to Jeffrey and not to Jane. The device of the doctor which wants to > access data on Johns heart rate monitor will not belong to John. If it > is an emergency physician she might not even have seen John ever before. > > So maybe there is some misunderstanding about security domains. My > intent for using this term was to emphasize the fact that C and RS do > not know each other at the time when C sends its first resource request. > This means, RS does not have any keys or other information about C and C > does not have any keys or other information about RS. Do we disagree > about this? > > Thanks, > Steffi > > > [1] http://tools.ietf.org/pdf/draft-gerdes-ace-actors-00.pdf > [2] http://tools.ietf.org/id/draft-seitz-ace-usecases-00.txt > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 From nobody Tue Jun 3 07:16:28 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A899D1A02B3 for ; Tue, 3 Jun 2014 07:16:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_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 2MibSdYZsEXm for ; Tue, 3 Jun 2014 07:16:26 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A757E1A0080 for ; Tue, 3 Jun 2014 07:16:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s53EFuP5001091; Tue, 3 Jun 2014 16:15:56 +0200 (CEST) Received: from pptp-218-1.informatik.uni-bremen.de (pptp-218-1.informatik.uni-bremen.de [134.102.218.240]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id EAA921991; Tue, 3 Jun 2014 16:15:55 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 7.3 $1878.2$) Content-Type: text/plain; charset=windows-1252 From: Carsten Bormann In-Reply-To: <538DD2FD.2020400@gmail.com> Date: Tue, 3 Jun 2014 16:15:55 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <521AAE69-A9C5-4EF9-BD11-86A6AE06A0DA@tzi.org> References: <538DA583.4070200@tzi.de> <538DD2FD.2020400@gmail.com> To: Rene Struik X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/ace/4QOSrpyDlWAHSfZEtjm4wLjQlFY Cc: Stefanie Gerdes , "ace@ietf.org" Subject: Re: [Ace] Security Domains X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments $ace$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 14:16:27 -0000 On 03 Jun 2014, at 15:51, Rene Struik wrote: > I did not really get yet what the disagreement is about, so maybe > someone can help me with that. Here in Stockholm there was a relatively extended discussion whether it = is worth to separate the client owner and the resource owner function in = the architecture and analogously separate out the Authorization Manager = (less-constrained counterpart of the client) from the Authorization = Server (less-constrained counterpart of the resource server). =20 http://tools.ietf.org/html/draft-gerdes-ace-actors takes the view that = this exercise is worthwhile. Obviously, this is an architectural model and does not say anything how = these functions are mapped to specific devices in a specific deployment. = If you don=92t separate out the functions in the architecture, I = believe the result will be single-owner thinking and it will be very = hard to later address the multiple-owner aspect that is so central to = the Internet of Things idea. Others believe that initial deployments = will all be single-owner and it will be hard to drum up input to an = architecture enabled for multiple owners, but it will be relatively easy = to extend the single-owner architecture later. Gr=FC=DFe, Carsten From nobody Tue Jun 3 07:27:02 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC04F1A021E; Tue, 3 Jun 2014 07:26:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 IxAOmAA4wIVf; Tue, 3 Jun 2014 07:26:52 -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 399651A0170; Tue, 3 Jun 2014 07:26:51 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHU38680; Tue, 03 Jun 2014 14:26:43 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 3 Jun 2014 15:25:44 +0100 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; Tue, 3 Jun 2014 15:26:28 +0100 Received: from SZXEMA501-MBS.china.huawei.com ([169.254.2.214]) by SZXEMA402-HUB.china.huawei.com ([10.82.72.34]) with mapi id 14.03.0158.001; Tue, 3 Jun 2014 22:26:24 +0800 From: Likepeng To: Kathleen Moriarty Thread-Topic: Revised charter proposal: charter-ietf-ace-00-02 Thread-Index: AQHPeLrW9teE9ryEO0GmvALEdUzf8JtesfKAgACKjwD//5riAIAAjBcw Date: Tue, 3 Jun 2014 14:26:23 +0000 Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F25815405D@SZXEMA501-MBS.china.huawei.com> References: <20140514221215.8150.56543.idtracker@ietfa.amsl.com> <34966E97BE8AD64EAE9D3D6E4DEE36F252B2A345@SZXEMA501-MBS.china.huawei.com> <34966E97BE8AD64EAE9D3D6E4DEE36F252B38978@SZXEMA501-MBS.china.huawei.com> <34966E97BE8AD64EAE9D3D6E4DEE36F258140E59@SZXEMA501-MBX.china.huawei.com> <538DA047.7080902@cisco.com> <34966E97BE8AD64EAE9D3D6E4DEE36F258153F43@SZXEMA501-MBS.china.huawei.com> 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.200.66.129] Content-Type: multipart/alternative; boundary="_000_34966E97BE8AD64EAE9D3D6E4DEE36F25815405DSZXEMA501MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/ace/NnIews515j2eHJl3WjNlaNdjPEM Cc: Benoit Claise , "adrian@olddog.co.uk" , "ace@ietf.org" , The IESG , "aaa-doctors@ietf.org" Subject: Re: [Ace] Revised charter proposal: charter-ietf-ace-00-02 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments $ace$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 14:26:57 -0000 --_000_34966E97BE8AD64EAE9D3D6E4DEE36F25815405DSZXEMA501MBSchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgS2F0aGxlZW4gYW5kIGFsbCwNCg0KVGhpcyBpcyB3aGF0IEkgaGF2ZSBub3c6DQoNCkNoYW5n ZSAjMTogKFByb3Bvc2VkIGJ5IEtlcGVuZywgY29uZmlybWVkIGJ5IEJlbm9pdCkNCg0KT0xEDQoN ClRoZSBJRVRGIGhhcyByZWNlbnRseSBkZXZlbG9wZWQgcHJvdG9jb2xzIGZvciB1c2UgaW4gY29u c3RyYWluZWQNCg0KZW52aXJvbm1lbnRzLCB3aGVyZSBuZXR3b3JrIG5vZGVzIGFyZSBsaW1pdGVk IGluIENQVSwgbWVtb3J5IGFuZCBwb3dlci4NCg0KDQoNCk5FVw0KDQpUaGUgSUVURiBoYXMgcmVj ZW50bHkgZGV2ZWxvcGVkIHByb3RvY29scyBmb3IgdXNlIGluIGNvbnN0cmFpbmVkDQoNCmVudmly b25tZW50cywgd2hlcmUgbmV0d29yayBub2RlcyBhcmUgbGltaXRlZCBpbiBDUFUsIG1lbW9yeSBh bmQgcG93ZXIuDQoNClJFU1QgYXJjaGl0ZWN0dXJlIGlzIHdpZGVseSB1c2VkIGZvciBzdWNoIGNv bnN0cmFpbmVkIGVudmlyb25tZW50cy4NCg0KRU5EDQoNCg0KDQpDaGFuZ2UgIzI6IChQcm9wb3Nh bCBmcm9tIFJlbmUsIHN1cHBvcnRlZCBieSBTdGVmYW5pZSkNCg0KT0xEOg0KDQpSZXF1aXJlbWVu dHMgZGVyaXZlZCBmcm9tIHVzZSBjYXNlcyBpbmRpY2F0ZSB0aGUgc3VpdGFiaWxpdHkgb2YgZXhp c3RpbmcNCg0Kd29yayBhcyBhIHNvbHV0aW9uIGZvciBjb25zdHJhaW5lZCBlbnZpcm9ubWVudHMN Cg0KDQoNCk5FVzoNCg0KUmVxdWlyZW1lbnRzIGRlcml2ZWQgZnJvbSB1c2UgY2FzZXMgbWF5IGlu ZGljYXRlIHRoYXQgZXhpc3Rpbmcgd29yayBpcw0KDQogdXNlZnVsIGFzIGJhc2lzIGZvciBhcyBh IHNvbHV0aW9uIGZvciBjb25zdHJhaW5lZCBlbnZpcm9ubWVudHMNCg0KDQoNCkNoYW5nZSAjMzog KFByb3Bvc2FsIGZyb20gSmFyaSwgc3VwcG9ydGVkIGJ5IEJhcnJ5LCBSb2JlcnQgYW5kIEJlaGNl dCkNCg0KT0xEOg0KDQpOb3RlIHRoYXQgdGhlIGluaXRpYWwgZm9jdXMgaXMgb24gQ29BUCBhbmQg SFRUUCB3aXRoIERUTFMgYW5kIFRMUy4NCg0KT3RoZXIgc2VjdXJpdHkgcHJvdG9jb2xzIG1heSBi ZSBjb25zaWRlcmVkIGFzIGxvbmcgYXMgdGhlIHByaW1hcnkgZm9jdXMgaXMgbWFpbnRhaW5lZC4N Cg0KT3RoZXIgYXBwbGljYXRpb24gcHJvdG9jb2xzIGFuZCBwcm90b2NvbHMgYXQgb3RoZXIgbGF5 ZXJzIGluIHRoZSBzdGFjayBhcmUgb3V0IG9mIHNjb3BlLg0KDQoNCg0KTkVXDQoNCk5vdGUgdGhh dCB0aGUgaW5pdGlhbCBmb2N1cyBpcyBvbiBDb0FQIGFuZCBIVFRQIHdpdGggRFRMUyBhbmQgVExT Lg0KDQpPdGhlciBzZWN1cml0eSBwcm90b2NvbHMgbWF5IGJlIGNvbnNpZGVyZWQgYXMgbG9uZyBh cyB0aGUgcHJpbWFyeSBmb2N1cyBpcyBtYWludGFpbmVkLg0KDQpUaGUgZ3JvdXAgaXMgc2NvcGVk IHRvIHdvcmsgb25seSBvbiB0aGUgd2ViIHByb3RvY29scyBhbmQgZGF0YSBjYXJyaWVkIHdpdGhp biB0aGVtLg0KDQpFTkQNCg0KDQoNCkNoYW5nZSA0OiAoUHJvcG9zYWwgZnJvbSBKYXJpLCByZXZp c2VkIGJ5IFJlbmUsIHN1cHBvcnRlZCBieSBTdGVmYW5pZSkNCg0KT0xEOg0KDQpKdWwgMjAxNCBT dWJtaXQgIlVzZSBjYXNlcyBhbmQgUmVxdWlyZW1lbnRzIsKdIGFzIGEgV0cgaXRlbS4NCg0KSnVs IDIwMTUgU3VibWl0IOKAnFVzZSBjYXNlcyBhbmQgUmVxdWlyZW1lbnRz4oCdIGRvY3VtZW50IHRv IElFU0cgZm9yIHB1YmxpY2F0aW9uIGFzIGluZm9ybWF0aW9uYWwgUkZDLg0KDQoNCg0KTkVXDQoN CkRlYyAyMDE0IFN1Ym1pdCAiVXNlIGNhc2VzIGFuZCBSZXF1aXJlbWVudHMiwp0gYXMgYSBXRyBp dGVtLg0KDQpBcHIgMjAxNSBPcHRpb25hbGx5LCBzdWJtaXQgIlVzZSBjYXNlcyBhbmQgUmVxdWly ZW1lbnRzIiBkb2N1bWVudCB0byB0aGUgSUVTRyBmb3INCg0KcHVibGljYXRpb24gYXMgYW4gSW5m b3JtYXRpb25hbCBSRkMuDQoNCkVORA0KDQpJIHRoaW5rIHdlIGNvdmVyZWQgYWxsIG9mIHRoZSBJ RVNHIHJldmlldyBjb21tZW50cy4NCg0KSWYgdGhlcmUgaXMgYW55IG9wZW4gaXNzdWUsIHBsZWFz ZSBsZXQgdXMga25vdy4NCg0KVGhhbmtzLA0KDQpLaW5kIFJlZ2FyZHMNCktlcGVuZw0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KQ2hhcnRlciBjaGFydGVyLWlldGYt YWNlLTAwLTAyDQpBdXRoZW50aWNhdGlvbiBhbmQgQXV0aG9yaXphdGlvbiBmb3IgQ29uc3RyYWlu ZWQNCkVudmlyb25tZW50IChBQ0UpDQoNClRoZSBJRVRGIGhhcyByZWNlbnRseSBkZXZlbG9wZWQg cHJvdG9jb2xzIGZvciB1c2UgaW4gY29uc3RyYWluZWQNCmVudmlyb25tZW50cywgd2hlcmUgbmV0 d29yayBub2RlcyBhcmUgbGltaXRlZCBpbiBDUFUsIG1lbW9yeSBhbmQgcG93ZXIuDQpSRVNUIGFy Y2hpdGVjdHVyZSBpcyB3aWRlbHkgdXNlZCBmb3Igc3VjaCBjb25zdHJhaW5lZCBlbnZpcm9ubWVu dHMuDQpJdCBoYXMgYmVlbiBvYnNlcnZlZCB0aGF0IEludGVybmV0IHByb3RvY29scyBjYW4gYmUg YXBwbGllZCB0byB0aGVzZQ0KY29uc3RyYWluZWQgZW52aXJvbm1lbnRzLCBvZnRlbiBvbmx5IHJl cXVpcmluZyBtaW5vciB0d2Vha2luZyBhbmQNCnByb2ZpbGluZy4gSW4gb3RoZXIgY2FzZXMsIG5l dyBwcm90b2NvbHMgaGF2ZSBiZWVuIGRlZmluZWQgdG8gYWRkcmVzcw0KdGhlIHNwZWNpZmljIHJl cXVpcmVtZW50cyBvZiBjb25zdHJhaW5lZCBlbnZpcm9ubWVudHMuIEFuIGV4YW1wbGUgb2YNCnN1 Y2ggYSBwcm90b2NvbCBpcyB0aGUgQ29uc3RyYWluZWQgQXBwbGljYXRpb24gUHJvdG9jb2wgKENv QVApLg0KDQpBcyBpbiBvdGhlciBlbnZpcm9ubWVudHMsIGF1dGhlbnRpY2F0aW9uIGFuZCBhdXRo b3JpemF0aW9uIHF1ZXN0aW9ucw0KYWxzbyBhcmlzZSBpbiBjb25zdHJhaW5lZCBlbnZpcm9ubWVu dHMuIEZvciBleGFtcGxlLCBhIGRvb3IgbG9jayBoYXMgdG8NCmF1dGhvcml6ZSB0aGUgcGVyc29u IHNlZWtpbmcgYWNjZXNzIHVzaW5nIGEgImRpZ2l0YWwga2V5Ii4gV2hlcmUgaXMgdGhlDQphdXRo b3JpemF0aW9uIHBvbGljeSBzdG9yZWQ/IEhvdyBkb2VzIHRoZSBkaWdpdGFsIGtleSBjb21tdW5p Y2F0ZSB3aXRoDQp0aGUgbG9jaz8gRG9lcyB0aGUgbG9jayBpbnRlcmFjdCB3aXRoIGFuIGF1dGhv cml6YXRpb24gc2VydmVyIHRvIG9idGFpbg0KYXV0aG9yaXphdGlvbiBpbmZvcm1hdGlvbj8gSG93 IGNhbiBhY2Nlc3MgYmUgdGVtcG9yYXJpbHkgZ3JhbnRlZCB0bw0Kb3RoZXIgcGVyc29ucz8gSG93 IGNhbiBhY2Nlc3MgYmUgcmV2b2tlZD8gVGhlc2UgdHlwZXMgb2YgcXVlc3Rpb25zIGhhdmUNCmJl ZW4gYW5zd2VyZWQgYnkgZXhpc3RpbmcgcHJvdG9jb2xzIGZvciB1c2UgY2FzZXMgb3V0c2lkZSBj b25zdHJhaW5lZA0KZW52aXJvbm1lbnRzLCBob3dldmVyIGluIGNvbnN0cmFpbmVkIGVudmlyb25t ZW50cywgYWRkaXRpb25hbCBhbmQNCmRpZmZlcmVudCByZXF1aXJlbWVudHMgcG9zZSBjaGFsbGVu Z2VzIGZvciB0aGUgdXNlIG9mIHZhcmlvdXMgc2VjdXJpdHkNCnByb3RvY29scy4gSW4gcGFydGlj dWxhciwgdGhlIG5lZWQgYXJpc2VzIGZvciBhIGR5bmFtaWMgYW5kIGZpbmUgZ3JhaW5lZA0KYWNj ZXNzIGNvbnRyb2wgbWVjaGFuaXNtLCB3aGVyZSBjbGllbnRzIGFuZC9vciByZXNvdXJjZSBzZXJ2 ZXJzIGFyZQ0KY29uc3RyYWluZWQuDQoNClRoZSBJRVRGIGhhcyBhIGxvbmcgaGlzdG9yeSBpbiBk ZXZlbG9waW5nIHRocmVlLXBhcnR5IGF1dGhlbnRpY2F0aW9uIGFuZA0KYXV0aG9yaXphdGlvbiBw cm90b2NvbHMgZm9yIGRpc3RyaWJ1dGVkIGVudmlyb25tZW50cy4gRXhhbXBsZXMgaW5jbHVkZQ0K S2VyYmVyb3MsIHRoZSBQdWJsaWMgS2V5IEluZnJhc3RydWN0dXJlIChQS0kpLCB0aGUgQXV0aGVu dGljYXRpb24sDQpBdXRob3JpemF0aW9uIGFuZCBBY2NvdW50aW5nIChBQUEpIGluZnJhc3RydWN0 dXJlLGFuZCB0aGUgV2ViDQpBdXRob3JpemF0aW9uIFByb3RvY29sIChPQXV0aCkuIEFsbCB0aGVz ZSBwcm90b2NvbHMgZW5qb3kgd2lkZXNwcmVhZA0KZGVwbG95bWVudCBvbiB0aGUgSW50ZXJuZXQu IEFsdGhvdWdoIHRoZXkgYWxsIGFpbSB0byBzb2x2ZSBhIHNpbWlsYXINCmdvYWwsIGF0IGFuIGFi c3RyYWN0IGxldmVsLCB0aGV5IG9mZmVyIHF1aXRlIGRpZmZlcmVudCBmdW5jdGlvbnMgYW5kDQp1 dGlsaXplIGRpZmZlcmVudCBtZXNzYWdlIGV4Y2hhbmdlcy4gVGhlc2UgZGlmZmVyZW5jZXMgcmVz dWx0IGZyb20gdGhlDQptYWluIGRlcGxveW1lbnQgdXNlIGNhc2VzIHRoZXkgd2VyZSBkZXNpZ25l ZCBmb3IgcmVzcGVjdGl2ZWx5Lg0KDQpSZXF1aXJlbWVudHMgZGVyaXZlZCBmcm9tIHVzZSBjYXNl cyBtYXkgaW5kaWNhdGUgdGhhdCBleGlzdGluZyB3b3JrIGlzDQp1c2VmdWwgYXMgYmFzaXMgZm9y IGFzIGEgc29sdXRpb24gZm9yIGNvbnN0cmFpbmVkIGVudmlyb25tZW50cy4NClRoZXNlIHByb3Rv Y29scywNCmhvd2V2ZXIsIHdlcmUgbm90IG9wdGltaXplZCBmb3IgY29uc3RyYWluZWQgZW52aXJv bm1lbnRzLiBBZGRpdGlvbmFsDQpyZXF1aXJlbWVudHMgdGhhdCBuZWVkIHRvIGJlIHRha2VuIGlu dG8gYWNjb3VudCBhcmUgdGhlIGxhY2sgb2YgYQ0Kc3VpdGFibGUgdXNlci1pbnRlcmZhY2UgYW5k IHRoZSBpbmFiaWxpdHkgb2YgZW1iZWRkZWQgZGV2aWNlcyB0byBjb250YWN0DQphbiBhdXRob3Jp emF0aW9uIHNlcnZlciBpbiByZWFsLXRpbWUgd2l0aCBldmVyeSByZXNvdXJjZSBhY2Nlc3MgcmVx dWVzdA0KZHVlIHRvIGludGVybWl0dGVudCBjb25uZWN0aXZpdHksIGV0Yy4NCg0KVGhpcyB3b3Jr aW5nIGdyb3VwIHRoZXJlZm9yZSBhaW1zIHRvIHByb2R1Y2UgYSBzdGFuZGFyZGl6ZWQgc29sdXRp b24gZm9yDQphdXRoZW50aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlvbiB0byBlbmFibGUgYXV0aG9y aXplZCBhY2Nlc3MgKEdFVCwgUFVULCBQT1NULA0KREVMRVRFKSB0byByZXNvdXJjZXMgaWRlbnRp ZmllZCBieSBhIFVSSSBhbmQgaG9zdGVkIG9uIGEgcmVzb3VyY2UNCnNlcnZlciBpbiBjb25zdHJh aW5lZCBlbnZpcm9ubWVudHMuIEFzIGEgc3RhcnRpbmcgcG9pbnQsIHRoZSB3b3JraW5nDQpncm91 cCB3aWxsIGFzc3VtZSB0aGF0IGFjY2VzcyB0byByZXNvdXJjZXMgYXQgYSByZXNvdXJjZSBzZXJ2 ZXIgYnkgYQ0KY2xpZW50IGRldmljZSB0YWtlcyBwbGFjZSB1c2luZyBDb0FQIGFuZCBpcyBwcm90 ZWN0ZWQgYnkgRFRMUy4gQm90aA0KcmVzb3VyY2Ugc2VydmVyIGFuZCBjbGllbnQgbWF5IGJlIGNv bnN0cmFpbmVkLiBUaGlzIGFjY2VzcyB3aWxsIGJlDQptZWRpYXRlZCBieSBhbiBhdXRob3JpemF0 aW9uIHNlcnZlciwgd2hpY2ggaXMgbm90IGNvbnNpZGVyZWQgdG8gYmUNCmNvbnN0cmFpbmVkLg0K DQpFeGlzdGluZyBhdXRoZW50aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlvbiBwcm90b2NvbHMgd2ls bCBiZSBldmFsdWF0ZWQNCmFuZCByZS11c2VkIHdoZXJlIGFwcGxpY2FibGUgdG8gYnVpbGQgdGhl IGNvbnN0cmFpbmVkLWVudmlyb25tZW50IHNvbHV0aW9uLg0KVGhpcyByZXF1aXJlcw0KcmVsZXZh bnQgc3BlY2lmaWNhdGlvbnMgdG8gYmUgcmV2aWV3ZWQgZm9yIHN1aXRhYmlsaXR5LCBzZWxlY3Rp bmcgYQ0Kc3Vic2V0IG9mIHRoZW0gYW5kIHJlc3RyaWN0aW5nIHRoZSBvcHRpb25zIHdpdGhpbiBl YWNoIG9mIHRoZQ0Kc3BlY2lmaWNhdGlvbnMuIFNvbWUgZnVuY3Rpb25hbGl0eSwgaG93ZXZlciwg bWF5IG5vdCBiZSBhdmFpbGFibGUgaW4NCmV4aXN0aW5nIHByb3RvY29scywgaW4gd2hpY2ggY2Fz ZSB0aGUgc29sdXRpb24gbWF5IGFsc28gaW52b2x2ZSBuZXcNCnByb3RvY29sIHdvcmsuIExldmVy YWdpbmcgZXhpc3Rpbmcgd29yayBtZWFucyB0aGUgd29ya2luZyBncm91cCBiZW5lZml0cw0KZnJv bSBhdmFpbGFibGUgc2VjdXJpdHkgYW5hbHlzaXMsIGltcGxlbWVudGF0aW9uLCBhbmQgZGVwbG95 bWVudA0KZXhwZXJpZW5jZS4gTW9yZW92ZXIsIGEgc3RhbmRhcmRpemVkIHNvbHV0aW9uIGZvciBm ZWRlcmF0ZWQNCmF1dGhlbnRpY2F0aW9uIGFuZCBhdXRob3JpemF0aW9uIHdpbGwgaGVscCB0byBz dGltdWxhdGUgdGhlIGRlcGxveW1lbnQNCm9mIGNvbnN0cmFpbmVkIGRldmljZXMgdGhhdCBwcm92 aWRlIGluY3JlYXNlZCBzZWN1cml0eS4NCg0KT25jZSBwcm9ncmVzcyBpbiBpZGVudGlmeWluZyBz dWl0YWJsZSBjYW5kaWRhdGUgc29sdXRpb25zIGhhcyBiZWVuIG1hZGUsDQp0aGUgd29ya2luZyBn cm91cCB3aWxsIHZlcmlmeSB3aGV0aGVyIHRoZSBzYW1lIG1lY2hhbmlzbXMgYXJlIGFsc28NCmFw cGxpY2FibGUgYmV5b25kIHRoZSB1c2Ugb2YgQ29BUCBhbmQgRFRMUywgd2hpY2ggYXJlIHRoZSB0 d28gbWFpbg0KcHJvdG9jb2xzIHRoZSBncm91cCB3aWxsIGZvY3VzIG9uIGZvciBhY2Nlc3MgdG8g cmVzb3VyY2VzLiBJbg0KcGFydGljdWxhciwgdGhlIGFiaWxpdHkgdG8gdXNlIHRoZSBkZXZlbG9w ZWQgc29sdXRpb24gb3ZlciBIVFRQIGFuZCBUTFMNCndpbGwgYmUgaW52ZXN0aWdhdGVkLiBOb3Rl IHRoYXQgdGhlIGluaXRpYWwgZm9jdXMgaXMgb24gQ29BUCBhbmQgSFRUUCB3aXRoIERUTFMgYW5k IFRMUy4NCk90aGVyIHNlY3VyaXR5IHByb3RvY29scyBtYXkgYmUgY29uc2lkZXJlZCBhcyBsb25n IGFzIHRoZSBwcmltYXJ5IGZvY3VzIGlzIG1haW50YWluZWQuDQpUaGUgZ3JvdXAgaXMgc2NvcGVk IHRvIHdvcmsgb25seSBvbiB0aGUgd2ViIHByb3RvY29scyBhbmQgZGF0YSBjYXJyaWVkIHdpdGhp biB0aGVtLg0KRnVydGhlcm1vcmUsIHRvIGd1YXJhbnRlZSBzbW9vdGggdHJhbnNpdGlvbiwgdGhl DQppbnRlZ3JhdGlvbiB3aXRoIGV4aXN0aW5nIGRlcGxveW1lbnRzIHdpbGwgYmUgc3R1ZGllZCwg cGFydGljdWxhcmx5DQpjb25jZXJuaW5nIHRoZSB1c2Ugb2YgcHJvdG9jb2wgdHJhbnNsYXRpb24g cHJveGllcy4NCg0KVGhpcyB3b3JrIGRvZXMgbm90IG1ha2UgdGhlIGFzc3VtcHRpb24gdGhhdCB0 aGUgcGFydHkgb2ZmZXJpbmcNCmFwcGxpY2F0aW9uIGxheWVyIHNlcnZpY2VzIGlzIGFsd2F5cyB0 aGUgc2FtZSBwYXJ0eSBvZmZlcmluZyBuZXR3b3JrDQphY2Nlc3Mgc2VydmljZXMuDQoNClRoZSB3 b3JraW5nIGdyb3VwIGhhcyB0aGUgZm9sbG93aW5nIHRhc2tzOg0KDQoxKSBQcm9kdWNlIHVzZSBj YXNlcyBhbmQgcmVxdWlyZW1lbnRzDQoNCjIpIElkZW50aWZ5IGF1dGhlbnRpY2F0aW9uIGFuZCBh dXRob3JpemF0aW9uIG1lY2hhbmlzbXMgc3VpdGFibGUgZm9yDQpyZXNvdXJjZSBhY2Nlc3MgaW4g Y29uc3RyYWluZWQgZW52aXJvbm1lbnRzLg0KDQpNaWxlc3RvbmVzOg0KDQpEZWMgMjAxNCBTdWJt aXQgIlVzZSBjYXNlcyBhbmQgUmVxdWlyZW1lbnRzIiBhcyBhIFdHIGl0ZW0uDQpEZWMgMjAxNCBT dWJtaXQgIkF1dGhlbnRpY2F0aW9uIGFuZCBBdXRob3JpemF0aW9uIFNvbHV0aW9uIiBhcyBhIFdH IGl0ZW0uDQpBcHIgMjAxNSBPcHRpb25hbGx5LCBzdWJtaXQgIlVzZSBjYXNlcyBhbmQgUmVxdWly ZW1lbnRzIiBkb2N1bWVudA0KdG8gdGhlIElFU0cgZm9yIHB1YmxpY2F0aW9uIGFzIGFuIEluZm9y bWF0aW9uYWwgUkZDLg0KSnVsIDIwMTYgU3VibWl0ICJBdXRoZW50aWNhdGlvbiBhbmQgQXV0aG9y aXphdGlvbiBTb2x1dGlvbiINCnNwZWNpZmljYXRpb24gdG8gdGhlIElFU0cgZm9yIHB1YmxpY2F0 aW9uIGFzIGEgUHJvcG9zZWQgU3RhbmRhcmQuDQoNClByb3Bvc2VkIE1pbGVzdG9uZXMNCk5vIG1p bGVzdG9uZXMgZm9yIGNoYXJ0ZXIgZm91bmQuDQoNCg0KDQrlj5Hku7bkuro6IEthdGhsZWVuIE1v cmlhcnR5IFttYWlsdG86a2F0aGxlZW4ubW9yaWFydHkuaWV0ZkBnbWFpbC5jb21dDQrlj5HpgIHm l7bpl7Q6IDIwMTTlubQ25pyIM+aXpSAxNDozMA0K5pS25Lu25Lq6OiBMaWtlcGVuZw0K5oqE6YCB OiBCZW5vaXQgQ2xhaXNlOyBhZHJpYW5Ab2xkZG9nLmNvLnVrOyBhYWEtZG9jdG9yc0BpZXRmLm9y ZzsgVGhlIElFU0c7IGFjZUBpZXRmLm9yZw0K5Li76aKYOiBSZTogUmV2aXNlZCBjaGFydGVyIHBy b3Bvc2FsOiBjaGFydGVyLWlldGYtYWNlLTAwLTAyDQoNCkhpIEtlcGVuZywNCg0KSWYgd2UgYXJl IGF0IGEgcG9pbnQgd2hlcmUgSSBjYW4gdXBkYXRlIHRoZSBjaGFydGVyLCBzZWVtcyB0aGF0IHdh eSwgcGxlYXNlIHNlbmQgdGhlIGxhdGVzdCB2ZXJzaW9uIHRoYXQgaGFzIGJlZW4gYWdyZWVkIHVw b24gYW5kIEknbGwgdGFrZSBjYXJlIG9mIHRoZSB1cGRhdGUuDQoNClRoYW5rcy4NCg0KT24gVHVl LCBKdW4gMywgMjAxNCBhdCA2OjMxIEFNLCBMaWtlcGVuZyA8bGlrZXBlbmdAaHVhd2VpLmNvbTxt YWlsdG86bGlrZXBlbmdAaHVhd2VpLmNvbT4+IHdyb3RlOg0KSGkgQmVub2l0LA0KDQo+Tm90IG9u bHkgd291bGQgSSBrZWVwICJBQUEiLA0KDQpPSy4NCg0KPmJ1dCBJIHdvdWxkIHByb3Bvc2UNCg0K Pk9MRDoNCj5FeGlzdGluZyBhdXRoZW50aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlvbiBwcm90b2Nv bHMgd2lsbCBiZSB1c2VkIHdoZXJlDQphcHBsaWNhYmxlIHRvIGJ1aWxkIHRoZSBjb25zdHJhaW5l ZC1lbnZpcm9ubWVudCBzb2x1dGlvbi4NCg0KPk5FVzoNCkV4aXN0aW5nIGF1dGhlbnRpY2F0aW9u IGFuZCBhdXRob3JpemF0aW9uIHByb3RvY29scyB3aWxsIGJlIGV2YWx1YXRlZCBhbmQgcmUtdXNl ZCB3aGVyZQ0KYXBwbGljYWJsZSB0byBidWlsZCB0aGUgY29uc3RyYWluZWQtZW52aXJvbm1lbnQg c29sdXRpb24uDQoNCk9LLCBmaW5lIHdpdGggbWUuDQoNClRoYW5rcyBmb3IgdGhlIGZlZWRiYWNr Lg0KDQpLaW5kIFJlZ2FyZHMNCktlcGVuZw0KDQrlj5Hku7bkuro6IEJlbm9pdCBDbGFpc2UgW21h aWx0bzpiY2xhaXNlQGNpc2NvLmNvbTxtYWlsdG86YmNsYWlzZUBjaXNjby5jb20+XQ0K5Y+R6YCB 5pe26Ze0OiAyMDE05bm0NuaciDPml6UgMTI6MTYNCuaUtuS7tuS6ujogTGlrZXBlbmc7IEthdGhs ZWVuIE1vcmlhcnR5OyBhZHJpYW5Ab2xkZG9nLmNvLnVrPG1haWx0bzphZHJpYW5Ab2xkZG9nLmNv LnVrPg0K5oqE6YCBOiBhYWEtZG9jdG9yc0BpZXRmLm9yZzxtYWlsdG86YWFhLWRvY3RvcnNAaWV0 Zi5vcmc+OyBUaGUgSUVTRzsgYWNlQGlldGYub3JnPG1haWx0bzphY2VAaWV0Zi5vcmc+DQrkuLvp opg6IFJlOiBSZXZpc2VkIGNoYXJ0ZXIgcHJvcG9zYWw6IGNoYXJ0ZXItaWV0Zi1hY2UtMDAtMDIN Cg0KSGksDQoNCkhlbGxvIGFsbCwNCg0KDQoNCkJhc2VkIG9uIHJlY2VudCBkaXNjdXNzaW9ucywg SSBtYWRlIGEgcmV2aXNlZCBjaGFydGVyIHByb3Bvc2FsLCBhcyBpbmNsdWRlZCBpbiB0aGlzIGVt YWlsLCBub3Qgb24gdGhlIHdlYnBhZ2UgeWV0Lg0KDQoNCg0KUGxlYXNlIHRha2UgYSBsb29rIGFu ZCBsZXQgdXMga25vdyBpZiB5b3UgaGF2ZSBhbnkgZnVydGhlciBjb21tZW50cy4NCg0KDQoNCkBB ZHJpYW4gYW5kIEBCZW5vaXQsIHBsZWFzZSBjaGVjayBpZiB0aGUgcHJvcG9zZWQgdGV4dHMgY2Fu IHJlc29sdmUgeW91ciBjb21tZW50cy4NCg0KDQoNClRoYW5rcywNCg0KS2luZCBSZWdhcmRzDQoN CktlcGVuZw0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KDQpDb21wYXJlZCB3aXRoIGNoYXJ0ZXItaWV0Zi1hY2UtMDAtMDEgb24gdGhlIHdlYnBhZ2Us IHRoZSBjaGFuZ2VzIGFyZToNCg0KDQoNCigxKSAgICAgIEFkZCBvbmUgY2xhcmlmaWNhdGlvbiBz ZW50ZW5jZSBhYm91dCBSRVNUIGFyY2hpdGVjdHVyZToNCg0KT0xEDQoNClRoZSBJRVRGIGhhcyBy ZWNlbnRseSBkZXZlbG9wZWQgcHJvdG9jb2xzIGZvciB1c2UgaW4gY29uc3RyYWluZWQNCg0KZW52 aXJvbm1lbnRzLCB3aGVyZSBuZXR3b3JrIG5vZGVzIGFyZSBsaW1pdGVkIGluIENQVSwgbWVtb3J5 IGFuZCBwb3dlci4NCg0KUkVTVCBhcmNoaXRlY3R1cmUgaXMgd2lkZWx5IHVzZWQgZm9yIHN1Y2gg Y29uc3RyYWluZWQgZW52aXJvbm1lbnRzLg0KDQoNCg0KTkVXDQoNClRoZSBJRVRGIGhhcyByZWNl bnRseSBkZXZlbG9wZWQgcHJvdG9jb2xzIGZvciB1c2UgaW4gY29uc3RyYWluZWQNCg0KZW52aXJv bm1lbnRzLCB3aGVyZSBuZXR3b3JrIG5vZGVzIGFyZSBsaW1pdGVkIGluIENQVSwgbWVtb3J5IGFu ZCBwb3dlci4NCg0KUkVTVCBhcmNoaXRlY3R1cmUgaXMgd2lkZWx5IHVzZWQgZm9yIHN1Y2ggY29u c3RyYWluZWQgZW52aXJvbm1lbnRzLg0KDQpFTkQNCkNvbnNpZGVyaW5nIHRoYXQgT0xEIGlzDQoN Ck9MRA0KDQpUaGUgSUVURiBoYXMgcmVjZW50bHkgZGV2ZWxvcGVkIHByb3RvY29scyBmb3IgdXNl IGluIGNvbnN0cmFpbmVkDQoNCmVudmlyb25tZW50cywgd2hlcmUgbmV0d29yayBub2RlcyBhcmUg bGltaXRlZCBpbiBDUFUsIG1lbW9yeSBhbmQgcG93ZXIuDQouLi4gZmluZSB3aXRoIG1lDQoNCg0K DQoNCg0KKDIpICAgICBSZW1vdmUg4oCcQUFBIHByb3RvY29s4oCdIGZyb20gdGhlIGNoYXJ0ZXI6 DQoNCk9MRA0KDQpUaGUgSUVURiBoYXMgYSBsb25nIGhpc3RvcnkgaW4gZGV2ZWxvcGluZyB0aHJl ZS1wYXJ0eSBhdXRoZW50aWNhdGlvbiBhbmQNCg0KYXV0aG9yaXphdGlvbiBwcm90b2NvbHMgZm9y IGRpc3RyaWJ1dGVkIGVudmlyb25tZW50cy4gRXhhbXBsZXMgaW5jbHVkZQ0KDQpLZXJiZXJvcywg dGhlIFB1YmxpYyBLZXkgSW5mcmFzdHJ1Y3R1cmUgKFBLSSksIHRoZSBBdXRoZW50aWNhdGlvbiwN Cg0KQXV0aG9yaXphdGlvbiBhbmQgQWNjb3VudGluZyAoQUFBKSBpbmZyYXN0cnVjdHVyZSwgYW5k IHRoZSBXZWINCg0KQXV0aG9yaXphdGlvbiBQcm90b2NvbCAoT0F1dGgpLg0KDQoNCg0KTkVXDQoN ClRoZSBJRVRGIGhhcyBhIGxvbmcgaGlzdG9yeSBpbiBkZXZlbG9waW5nIHRocmVlLXBhcnR5IGF1 dGhlbnRpY2F0aW9uIGFuZA0KDQphdXRob3JpemF0aW9uIHByb3RvY29scyBmb3IgZGlzdHJpYnV0 ZWQgZW52aXJvbm1lbnRzLiBFeGFtcGxlcyBpbmNsdWRlDQoNCktlcmJlcm9zLCB0aGUgUHVibGlj IEtleSBJbmZyYXN0cnVjdHVyZSAoUEtJKSwgYW5kIHRoZSBXZWIgQXV0aG9yaXphdGlvbiBQcm90 b2NvbCAoT0F1dGgpLg0KDQpFTkQNCldlIGhhdmUgQUFBLWRvY3RvcnMgdGVsbGluZzogbWF5YmUg UkFESVVTIGlzIGFwcGxpY2FibGU/DQpQZXJzb25hbGx5LCBJIGRvbid0IGtub3cgYW5kIGl0IGRv ZXNuJ3QgbWF0dGVyIGF0IHRoaXMgcG9pbnQuDQpXZSByZWNlaXZlZCBmZWVkYmFjayBzdWNoIGFz Og0KTGV0J3MgYmUgY2xlYXIgaGVyZTogSXQgd2FzIG5ldmVyIHNhaWQgKGluIHRoZSBjaGFydGVy IG9yIGFueXdoZXJlIGVsc2UgaW4gdGhlIGdyb3VwIHRvIG15IGtub3dsZWRnZSkgdGhhdCBSQURJ VVMgKG9yIGluZGVlZCBhbnkgb3RoZXIgQUFBIHByb3RvY29sKSB3b3VsZCBub3QgcnVuIG9uIGNv bnN0cmFpbmVkIGRldmljZXMgKFJGQyA3MjI4KS4gVGhlIGNoYXJ0ZXIgc2ltcGx5IHNhaWQgdGhl IHByb3RvY29scyB3ZXJlIG5vdCBvcHRpbWlzZWQgZm9yIGNvbnN0cmFpbmVkIGRldmljZXMuIFRo YXQgZG9lcyBub3QgcHJlY2x1ZGUgY29uc2lkZXJpbmcgYW55IHByb3RvY29sIGZvciBzdWl0YWJp bGl0eSBmb3IgY29uc3RyYWluZWQgZGV2aWNlcyBlaXRoZXIgYSkgYXMgaXMsIGIpIGluIGEgcmVz dHJpY3RlZCB3YXkgb3IgYykgaW4gYW4gYWRhcHRlZCB3YXkuDQoNClNvLCBhdCB0aGlzIHN0YWdl LCBJIGRvbid0IHRoaW5rIGFueSBwcm90b2NvbHMgc2hvdWxkIGJlIGV4Y2x1ZGVkIGZyb20gY29u c2lkZXJhdGlvbiBhbmQgc2hvdWxkIGNlcnRhaW5seSBub3QgYmUgZWxpbWluYXRlZCBvbiBhIGh1 bmNoIHRoYXQgdGhleSBtaWdodCBiZSAidG9vIGJpZyIuIExldCdzIGRvIHRoZSBhc3Nlc3NtZW50 IHByb3Blcmx5IGF0IHRoZSBhcHByb3ByaWF0ZSB0aW1lLiBBcyBhIHJlbWluZGVyIC0gdGhlIGZv Y3VzIG5vdyBpcyB0byBjb21wbGV0ZSB0aGUgY2hhcnRlci4NCk9yDQoNCj4+VGhlIENoYXJ0ZXIg bWFrZXMgYSBudW1iZXIgb2YgYXNzZXJ0aW9ucyB0aGF0IGFyZSBwcm92YWJseSBmYWxzZSwgc3Vj aCBhcyB0aGF0IEFBQSBwcm90b2NvbHMgYXJlIGluYXBwcm9wcmlhdGUgZm9yIGNvbnN0cmFpbmVk IGVudmlyb25tZW50cy4NCg0KSW4gZmFjdCwgdGhlIGNoYXJ0ZXIgZG9lcyBub3Qgc2F5IHRoYXQu IEJ1dCB0byBhdm9pZCBjb25mdXNpb24sIGxldCdzIHJlbW92ZSBBQUEgcHJvdG9jb2wgZnJvbSB0 aGUgY2hhcnRlci4NCg0KDQoNCkluIHRoZSBjaGFydGVyLCB3ZSBtZW50aW9uZWQgdGhhdCB3ZSB3 YW50IHRvIHJldXNlIGV4aXN0aW5nIGF1dGhlbnRpY2F0aW9uIGFuZCBhdXRob3JpemF0aW9uIHBy b3RvY29scyB3aGVyZSBhcHBsaWNhYmxlIHRvIGJ1aWxkIHRoZSBjb25zdHJhaW5lZC1lbnZpcm9u bWVudCBzb2x1dGlvbi4NCi4uLiB3aGljaCBJIHJlYWQgYXM6IGxldCdzIGNvbnNpZGVyIHRoZSBB QUEgcHJvdG9jb2xzLCBhbmQgZXZhbHVhdGUgaWYgdGhleSB3b3VsZCB3b3JrIGluIGNvbnN0cmFp bmVkIGRldmljZXMuDQpJIGRvbid0IHVuZGVyc3RhbmQgdGhlIGxvZ2ljOiB3aHkgZG8geW91IHdh bnQgdG8gcmVtb3ZlIEFBQSBmcm9tIHRoZSBjaGFydGVyPw0KTm90IG9ubHkgd291bGQgSSBrZWVw ICJBQUEiLCBidXQgSSB3b3VsZCBwcm9wb3NlDQoNCk9MRDoNCkV4aXN0aW5nIGF1dGhlbnRpY2F0 aW9uIGFuZCBhdXRob3JpemF0aW9uIHByb3RvY29scyB3aWxsIGJlIHVzZWQgd2hlcmUNCmFwcGxp Y2FibGUgdG8gYnVpbGQgdGhlIGNvbnN0cmFpbmVkLWVudmlyb25tZW50IHNvbHV0aW9uDQoNCk5F VzoNCkV4aXN0aW5nIGF1dGhlbnRpY2F0aW9uIGFuZCBhdXRob3JpemF0aW9uIHByb3RvY29scyB3 aWxsIGJlIGV2YWx1YXRlZCBhbmQgcmUtdXNlZCB3aGVyZQ0KYXBwbGljYWJsZSB0byBidWlsZCB0 aGUgY29uc3RyYWluZWQtZW52aXJvbm1lbnQgc29sdXRpb24NCg0KUmVnYXJkcywgQmVub2l0DQoN Cg0KDQoNCg0KKDMpIENsYXJpZnkgdGhlIHNjb3BlOg0KDQpPTEQ6DQoNCk5vdGUgdGhhdCB0aGUg aW5pdGlhbCBmb2N1cyBpcyBvbiBDb0FQIGFuZCBIVFRQIHdpdGggRFRMUyBhbmQgVExTLg0KDQpP dGhlciBzZWN1cml0eSBwcm90b2NvbHMgbWF5IGJlIGNvbnNpZGVyZWQgYXMgbG9uZyBhcyB0aGUg cHJpbWFyeSBmb2N1cyBpcyBtYWludGFpbmVkLg0KDQpPdGhlciBhcHBsaWNhdGlvbiBwcm90b2Nv bHMgYW5kIHByb3RvY29scyBhdCBvdGhlciBsYXllcnMgaW4gdGhlIHN0YWNrIGFyZSBvdXQgb2Yg c2NvcGUuDQoNCg0KDQpORVcNCg0KTm90ZSB0aGF0IHRoZSBpbml0aWFsIGZvY3VzIGlzIG9uIENv QVAgYW5kIEhUVFAgd2l0aCBEVExTIGFuZCBUTFMuDQoNCk90aGVyIHNlY3VyaXR5IHByb3RvY29s cyBtYXkgYmUgY29uc2lkZXJlZCBhcyBsb25nIGFzIHRoZSBwcmltYXJ5IGZvY3VzIGlzIG1haW50 YWluZWQuDQoNClRoZSBncm91cCBpcyBzY29wZWQgdG8gd29yayBvbmx5IG9uIHRoZSB3ZWIgcHJv dG9jb2xzIGFuZCBkYXRhIGNhcnJpZWQgd2l0aGluIHRoZW0uDQoNCkVORA0KDQoNCg0KKDQpICAg ICBVcGRhdGUgbWlsZXN0b25lcyBmb3IgdGhlIHVzZSBjYXNlICYgcmVxdWlyZW1lbnRzIGRvY3Vt ZW50Og0KDQpPTEQ6DQoNCkp1bCAyMDE1IFN1Ym1pdCDigJxVc2UgY2FzZXMgYW5kIFJlcXVpcmVt ZW50c+KAnSBkb2N1bWVudCB0byBJRVNHIGZvciBwdWJsaWNhdGlvbiBhcyBpbmZvcm1hdGlvbmFs IFJGQy4NCg0KDQoNCk5FVw0KDQpEZWMgMjAxNCBPcHRpb25hbGx5LCBzdWJtaXQgIlVzZSBjYXNl cyBhbmQgUmVxdWlyZW1lbnRzIiBkb2N1bWVudCB0byB0aGUgSUVTRyBmb3IgcHVibGljYXRpb24g YXMgYW4gSW5mb3JtYXRpb25hbCBSRkMuDQoNCkVORA0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpDaGFydGVyIGNoYXJ0 ZXItaWV0Zi1hY2UtMDAtMDINCg0KQXV0aGVudGljYXRpb24gYW5kIEF1dGhvcml6YXRpb24gZm9y IENvbnN0cmFpbmVkDQoNCkVudmlyb25tZW50IChBQ0UpDQoNCg0KDQpUaGUgSUVURiBoYXMgcmVj ZW50bHkgZGV2ZWxvcGVkIHByb3RvY29scyBmb3IgdXNlIGluIGNvbnN0cmFpbmVkDQoNCmVudmly b25tZW50cywgd2hlcmUgbmV0d29yayBub2RlcyBhcmUgbGltaXRlZCBpbiBDUFUsIG1lbW9yeSBh bmQgcG93ZXIuDQoNClJFU1QgYXJjaGl0ZWN0dXJlIGlzIHdpZGVseSB1c2VkIGZvciBzdWNoIGNv bnN0cmFpbmVkIGVudmlyb25tZW50cy4NCg0KSXQgaGFzIGJlZW4gb2JzZXJ2ZWQgdGhhdCBJbnRl cm5ldCBwcm90b2NvbHMgY2FuIGJlIGFwcGxpZWQgdG8gdGhlc2UNCg0KY29uc3RyYWluZWQgZW52 aXJvbm1lbnRzLCBvZnRlbiBvbmx5IHJlcXVpcmluZyBtaW5vciB0d2Vha2luZyBhbmQNCg0KcHJv ZmlsaW5nLiBJbiBvdGhlciBjYXNlcywgbmV3IHByb3RvY29scyBoYXZlIGJlZW4gZGVmaW5lZCB0 byBhZGRyZXNzDQoNCnRoZSBzcGVjaWZpYyByZXF1aXJlbWVudHMgb2YgY29uc3RyYWluZWQgZW52 aXJvbm1lbnRzLiBBbiBleGFtcGxlIG9mDQoNCnN1Y2ggYSBwcm90b2NvbCBpcyB0aGUgQ29uc3Ry YWluZWQgQXBwbGljYXRpb24gUHJvdG9jb2wgKENvQVApLg0KDQoNCg0KQXMgaW4gb3RoZXIgZW52 aXJvbm1lbnRzLCBhdXRoZW50aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlvbiBxdWVzdGlvbnMNCg0K YWxzbyBhcmlzZSBpbiBjb25zdHJhaW5lZCBlbnZpcm9ubWVudHMuIEZvciBleGFtcGxlLCBhIGRv b3IgbG9jayBoYXMgdG8NCg0KYXV0aG9yaXplIHRoZSBwZXJzb24gc2Vla2luZyBhY2Nlc3MgdXNp bmcgYSAiZGlnaXRhbCBrZXkiLiBXaGVyZSBpcyB0aGUNCg0KYXV0aG9yaXphdGlvbiBwb2xpY3kg c3RvcmVkPyBIb3cgZG9lcyB0aGUgZGlnaXRhbCBrZXkgY29tbXVuaWNhdGUgd2l0aA0KDQp0aGUg bG9jaz8gRG9lcyB0aGUgbG9jayBpbnRlcmFjdCB3aXRoIGFuIGF1dGhvcml6YXRpb24gc2VydmVy IHRvIG9idGFpbg0KDQphdXRob3JpemF0aW9uIGluZm9ybWF0aW9uPyBIb3cgY2FuIGFjY2VzcyBi ZSB0ZW1wb3JhcmlseSBncmFudGVkIHRvDQoNCm90aGVyIHBlcnNvbnM/IEhvdyBjYW4gYWNjZXNz IGJlIHJldm9rZWQ/IFRoZXNlIHR5cGVzIG9mIHF1ZXN0aW9ucyBoYXZlDQoNCmJlZW4gYW5zd2Vy ZWQgYnkgZXhpc3RpbmcgcHJvdG9jb2xzIGZvciB1c2UgY2FzZXMgb3V0c2lkZSBjb25zdHJhaW5l ZA0KDQplbnZpcm9ubWVudHMsIGhvd2V2ZXIgaW4gY29uc3RyYWluZWQgZW52aXJvbm1lbnRzLCBh ZGRpdGlvbmFsIGFuZA0KDQpkaWZmZXJlbnQgcmVxdWlyZW1lbnRzIHBvc2UgY2hhbGxlbmdlcyBm b3IgdGhlIHVzZSBvZiB2YXJpb3VzIHNlY3VyaXR5DQoNCnByb3RvY29scy4gSW4gcGFydGljdWxh ciwgdGhlIG5lZWQgYXJpc2VzIGZvciBhIGR5bmFtaWMgYW5kIGZpbmUgZ3JhaW5lZA0KDQphY2Nl c3MgY29udHJvbCBtZWNoYW5pc20sIHdoZXJlIGNsaWVudHMgYW5kL29yIHJlc291cmNlIHNlcnZl cnMgYXJlDQoNCmNvbnN0cmFpbmVkLg0KDQoNCg0KVGhlIElFVEYgaGFzIGEgbG9uZyBoaXN0b3J5 IGluIGRldmVsb3BpbmcgdGhyZWUtcGFydHkgYXV0aGVudGljYXRpb24gYW5kDQoNCmF1dGhvcml6 YXRpb24gcHJvdG9jb2xzIGZvciBkaXN0cmlidXRlZCBlbnZpcm9ubWVudHMuIEV4YW1wbGVzIGlu Y2x1ZGUNCg0KS2VyYmVyb3MsIHRoZSBQdWJsaWMgS2V5IEluZnJhc3RydWN0dXJlIChQS0kpLCBh bmQgdGhlIFdlYg0KDQpBdXRob3JpemF0aW9uIFByb3RvY29sIChPQXV0aCkuIEFsbCB0aGVzZSBw cm90b2NvbHMgZW5qb3kgd2lkZXNwcmVhZA0KDQpkZXBsb3ltZW50IG9uIHRoZSBJbnRlcm5ldC4g QWx0aG91Z2ggdGhleSBhbGwgYWltIHRvIHNvbHZlIGEgc2ltaWxhcg0KDQpnb2FsLCBhdCBhbiBh YnN0cmFjdCBsZXZlbCwgdGhleSBvZmZlciBxdWl0ZSBkaWZmZXJlbnQgZnVuY3Rpb25zIGFuZA0K DQp1dGlsaXplIGRpZmZlcmVudCBtZXNzYWdlIGV4Y2hhbmdlcy4gVGhlc2UgZGlmZmVyZW5jZXMg cmVzdWx0IGZyb20gdGhlDQoNCm1haW4gZGVwbG95bWVudCB1c2UgY2FzZXMgdGhleSB3ZXJlIGRl c2lnbmVkIGZvciByZXNwZWN0aXZlbHkuDQoNCg0KDQpSZXF1aXJlbWVudHMgZGVyaXZlZCBmcm9t IHVzZSBjYXNlcyBpbmRpY2F0ZSB0aGUgc3VpdGFiaWxpdHkgb2YgZXhpc3RpbmcNCg0Kd29yayBh cyBhIHNvbHV0aW9uIGZvciBjb25zdHJhaW5lZCBlbnZpcm9ubWVudHMuIFRoZXNlIHByb3RvY29s cywNCg0KaG93ZXZlciwgd2VyZSBub3Qgb3B0aW1pemVkIGZvciBjb25zdHJhaW5lZCBlbnZpcm9u bWVudHMuIEFkZGl0aW9uYWwNCg0KcmVxdWlyZW1lbnRzIHRoYXQgbmVlZCB0byBiZSB0YWtlbiBp bnRvIGFjY291bnQgYXJlIHRoZSBsYWNrIG9mIGENCg0Kc3VpdGFibGUgdXNlci1pbnRlcmZhY2Ug YW5kIHRoZSBpbmFiaWxpdHkgb2YgZW1iZWRkZWQgZGV2aWNlcyB0byBjb250YWN0DQoNCmFuIGF1 dGhvcml6YXRpb24gc2VydmVyIGluIHJlYWwtdGltZSB3aXRoIGV2ZXJ5IHJlc291cmNlIGFjY2Vz cyByZXF1ZXN0DQoNCmR1ZSB0byBpbnRlcm1pdHRlbnQgY29ubmVjdGl2aXR5LCBldGMuDQoNCg0K DQpUaGlzIHdvcmtpbmcgZ3JvdXAgdGhlcmVmb3JlIGFpbXMgdG8gcHJvZHVjZSBhIHN0YW5kYXJk aXplZCBzb2x1dGlvbiBmb3INCg0KYXV0aGVudGljYXRpb24gYW5kIGF1dGhvcml6YXRpb24gdG8g ZW5hYmxlIGF1dGhvcml6ZWQgYWNjZXNzIChHRVQsIFBVVCwgUE9TVCwNCg0KREVMRVRFKSB0byBy ZXNvdXJjZXMgaWRlbnRpZmllZCBieSBhIFVSSSBhbmQgaG9zdGVkIG9uIGEgcmVzb3VyY2UNCg0K c2VydmVyIGluIGNvbnN0cmFpbmVkIGVudmlyb25tZW50cy4gQXMgYSBzdGFydGluZyBwb2ludCwg dGhlIHdvcmtpbmcNCg0KZ3JvdXAgd2lsbCBhc3N1bWUgdGhhdCBhY2Nlc3MgdG8gcmVzb3VyY2Vz IGF0IGEgcmVzb3VyY2Ugc2VydmVyIGJ5IGENCg0KY2xpZW50IGRldmljZSB0YWtlcyBwbGFjZSB1 c2luZyBDb0FQIGFuZCBpcyBwcm90ZWN0ZWQgYnkgRFRMUy4gQm90aA0KDQpyZXNvdXJjZSBzZXJ2 ZXIgYW5kIGNsaWVudCBtYXkgYmUgY29uc3RyYWluZWQuIFRoaXMgYWNjZXNzIHdpbGwgYmUNCg0K bWVkaWF0ZWQgYnkgYW4gYXV0aG9yaXphdGlvbiBzZXJ2ZXIsIHdoaWNoIGlzIG5vdCBjb25zaWRl cmVkIHRvIGJlDQoNCmNvbnN0cmFpbmVkLg0KDQoNCg0KRXhpc3RpbmcgYXV0aGVudGljYXRpb24g YW5kIGF1dGhvcml6YXRpb24gcHJvdG9jb2xzIHdpbGwgYmUgdXNlZCB3aGVyZQ0KDQphcHBsaWNh YmxlIHRvIGJ1aWxkIHRoZSBjb25zdHJhaW5lZC1lbnZpcm9ubWVudCBzb2x1dGlvbi4gVGhpcyBy ZXF1aXJlcw0KDQpyZWxldmFudCBzcGVjaWZpY2F0aW9ucyB0byBiZSByZXZpZXdlZCBmb3Igc3Vp dGFiaWxpdHksIHNlbGVjdGluZyBhDQoNCnN1YnNldCBvZiB0aGVtIGFuZCByZXN0cmljdGluZyB0 aGUgb3B0aW9ucyB3aXRoaW4gZWFjaCBvZiB0aGUNCg0Kc3BlY2lmaWNhdGlvbnMuIFNvbWUgZnVu Y3Rpb25hbGl0eSwgaG93ZXZlciwgbWF5IG5vdCBiZSBhdmFpbGFibGUgaW4NCg0KZXhpc3Rpbmcg cHJvdG9jb2xzLCBpbiB3aGljaCBjYXNlIHRoZSBzb2x1dGlvbiBtYXkgYWxzbyBpbnZvbHZlIG5l dw0KDQpwcm90b2NvbCB3b3JrLiBMZXZlcmFnaW5nIGV4aXN0aW5nIHdvcmsgbWVhbnMgdGhlIHdv cmtpbmcgZ3JvdXAgYmVuZWZpdHMNCg0KZnJvbSBhdmFpbGFibGUgc2VjdXJpdHkgYW5hbHlzaXMs IGltcGxlbWVudGF0aW9uLCBhbmQgZGVwbG95bWVudA0KDQpleHBlcmllbmNlLiBNb3Jlb3Zlciwg YSBzdGFuZGFyZGl6ZWQgc29sdXRpb24gZm9yIGZlZGVyYXRlZA0KDQphdXRoZW50aWNhdGlvbiBh bmQgYXV0aG9yaXphdGlvbiB3aWxsIGhlbHAgdG8gc3RpbXVsYXRlIHRoZSBkZXBsb3ltZW50DQoN Cm9mIGNvbnN0cmFpbmVkIGRldmljZXMgdGhhdCBwcm92aWRlIGluY3JlYXNlZCBzZWN1cml0eS4N Cg0KDQoNCk9uY2UgcHJvZ3Jlc3MgaW4gaWRlbnRpZnlpbmcgc3VpdGFibGUgY2FuZGlkYXRlIHNv bHV0aW9ucyBoYXMgYmVlbiBtYWRlLA0KDQp0aGUgd29ya2luZyBncm91cCB3aWxsIHZlcmlmeSB3 aGV0aGVyIHRoZSBzYW1lIG1lY2hhbmlzbXMgYXJlIGFsc28NCg0KYXBwbGljYWJsZSBiZXlvbmQg dGhlIHVzZSBvZiBDb0FQIGFuZCBEVExTLCB3aGljaCBhcmUgdGhlIHR3byBtYWluDQoNCnByb3Rv Y29scyB0aGUgZ3JvdXAgd2lsbCBmb2N1cyBvbiBmb3IgYWNjZXNzIHRvIHJlc291cmNlcy4gSW4N Cg0KcGFydGljdWxhciwgdGhlIGFiaWxpdHkgdG8gdXNlIHRoZSBkZXZlbG9wZWQgc29sdXRpb24g b3ZlciBIVFRQIGFuZCBUTFMNCg0Kd2lsbCBiZSBpbnZlc3RpZ2F0ZWQuIE5vdGUgdGhhdCB0aGUg aW5pdGlhbCBmb2N1cyBpcyBvbiBDb0FQIGFuZCBIVFRQIHdpdGggRFRMUyBhbmQgVExTLg0KDQpP dGhlciBzZWN1cml0eSBwcm90b2NvbHMgbWF5IGJlIGNvbnNpZGVyZWQgYXMgbG9uZyBhcyB0aGUg cHJpbWFyeSBmb2N1cyBpcyBtYWludGFpbmVkLg0KDQpUaGUgZ3JvdXAgaXMgc2NvcGVkIHRvIHdv cmsgb25seSBvbiB0aGUgd2ViIHByb3RvY29scyBhbmQgZGF0YSBjYXJyaWVkIHdpdGhpbiB0aGVt Lg0KDQpGdXJ0aGVybW9yZSwgdG8gZ3VhcmFudGVlIHNtb290aCB0cmFuc2l0aW9uLCB0aGUNCg0K aW50ZWdyYXRpb24gd2l0aCBleGlzdGluZyBkZXBsb3ltZW50cyB3aWxsIGJlIHN0dWRpZWQsIHBh cnRpY3VsYXJseQ0KDQpjb25jZXJuaW5nIHRoZSB1c2Ugb2YgcHJvdG9jb2wgdHJhbnNsYXRpb24g cHJveGllcy4NCg0KDQoNClRoaXMgd29yayBkb2VzIG5vdCBtYWtlIHRoZSBhc3N1bXB0aW9uIHRo YXQgdGhlIHBhcnR5IG9mZmVyaW5nDQoNCmFwcGxpY2F0aW9uIGxheWVyIHNlcnZpY2VzIGlzIGFs d2F5cyB0aGUgc2FtZSBwYXJ0eSBvZmZlcmluZyBuZXR3b3JrDQoNCmFjY2VzcyBzZXJ2aWNlcy4N Cg0KDQoNClRoZSB3b3JraW5nIGdyb3VwIGhhcyB0aGUgZm9sbG93aW5nIHRhc2tzOg0KDQoNCg0K MSkgUHJvZHVjZSB1c2UgY2FzZXMgYW5kIHJlcXVpcmVtZW50cw0KDQoNCg0KMikgSWRlbnRpZnkg YXV0aGVudGljYXRpb24gYW5kIGF1dGhvcml6YXRpb24gbWVjaGFuaXNtcyBzdWl0YWJsZSBmb3IN Cg0KcmVzb3VyY2UgYWNjZXNzIGluIGNvbnN0cmFpbmVkIGVudmlyb25tZW50cy4NCg0KDQoNCk1p bGVzdG9uZXM6DQoNCg0KDQpKdWwgMjAxNCBTdWJtaXQgIlVzZSBjYXNlcyBhbmQgUmVxdWlyZW1l bnRzIiBhcyBhIFdHIGl0ZW0uDQoNCkRlYyAyMDE0IFN1Ym1pdCAiQXV0aGVudGljYXRpb24gYW5k IEF1dGhvcml6YXRpb24gU29sdXRpb24iIGFzIGEgV0cgaXRlbS4NCg0KRGVjIDIwMTQgT3B0aW9u YWxseSwgc3VibWl0ICJVc2UgY2FzZXMgYW5kIFJlcXVpcmVtZW50cyIgZG9jdW1lbnQNCg0KdG8g dGhlIElFU0cgZm9yIHB1YmxpY2F0aW9uIGFzIGFuIEluZm9ybWF0aW9uYWwgUkZDLg0KDQpKdWwg MjAxNiBTdWJtaXQgIkF1dGhlbnRpY2F0aW9uIGFuZCBBdXRob3JpemF0aW9uIFNvbHV0aW9uIg0K DQpzcGVjaWZpY2F0aW9uIHRvIHRoZSBJRVNHIGZvciBwdWJsaWNhdGlvbiBhcyBhIFByb3Bvc2Vk IFN0YW5kYXJkLg0KDQoNCg0KUHJvcG9zZWQgTWlsZXN0b25lcw0KDQpObyBtaWxlc3RvbmVzIGZv ciBjaGFydGVyIGZvdW5kLg0KDQoNCg0KDQotLQ0KDQpCZXN0IHJlZ2FyZHMsDQpLYXRobGVlbg0K --_000_34966E97BE8AD64EAE9D3D6E4DEE36F25815405DSZXEMA501MBSchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmln aHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQpwcmUNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIOmihOiuvuagvOW8jyBDaGFy IjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIu MHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUs IGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoi5om55rOo5qGG5paH5pysIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZTo5LjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0Kc3Bhbi5I VE1MQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCDpooTorr7moLzlvI8gQ2hhciI7DQoJbXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIOmihOiuvuagvOW8jyI7 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5DaGFyDQoJe21zby1zdHlsZS1uYW1lOiLm ibnms6jmoYbmlofmnKwgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls ZS1saW5rOuaJueazqOahhuaWh+acrDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5 MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBLYXRobGVlbiBh bmQgYWxsLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGlzIGlzIHdoYXQg SSBoYXZlIG5vdzo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q2hhbmdlICMx OiAoUHJvcG9zZWQgYnkgS2VwZW5nLCBjb25maXJtZWQgYnkgQmVub2l0KTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5PTEQ8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGUgSUVURiBo YXMgcmVjZW50bHkgZGV2ZWxvcGVkIHByb3RvY29scyBmb3IgdXNlIGluIGNvbnN0cmFpbmVkPG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ZW52aXJvbm1lbnRzLCB3aGVyZSBuZXR3b3JrIG5v ZGVzIGFyZSBsaW1pdGVkIGluIENQVSwgbWVtb3J5IGFuZCBwb3dlci4gPG86cD48L286cD48L3Nw YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TkVXPG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlIElFVEYgaGFzIHJlY2VudGx5IGRldmVsb3Bl ZCBwcm90b2NvbHMgZm9yIHVzZSBpbiBjb25zdHJhaW5lZDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPmVudmlyb25tZW50cywgd2hlcmUgbmV0d29yayBub2RlcyBhcmUgbGltaXRlZCBpbiBD UFUsIG1lbW9yeSBhbmQgcG93ZXIuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UkVTVCBh cmNoaXRlY3R1cmUgaXMgd2lkZWx5IHVzZWQgZm9yIHN1Y2ggY29uc3RyYWluZWQgZW52aXJvbm1l bnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkVORDxvOnA+PC9vOnA+PC9zcGFuPjwv cHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkNoYW5nZSAjMjog KFByb3Bvc2FsIGZyb20gUmVuZSwgc3VwcG9ydGVkIGJ5IFN0ZWZhbmllKTxvOnA+PC9vOnA+PC9z cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPk9MRDo8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SZXF1aXJl bWVudHMgZGVyaXZlZCBmcm9tIHVzZSBjYXNlcyBpbmRpY2F0ZSB0aGUgc3VpdGFiaWxpdHkgb2Yg ZXhpc3Rpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj53b3JrIGFzIGEgc29sdXRpb24g Zm9yIGNvbnN0cmFpbmVkIGVudmlyb25tZW50cyA8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw cmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5ORVc6PG86cD48L286cD48L3Nw YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+UmVxdWlyZW1lbnRzIGRlcml2ZWQgZnJvbSB1c2UgY2FzZXMgbWF5IGlu ZGljYXRlIHRoYXQgZXhpc3Rpbmcgd29yayBpczxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy ZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PiB1c2VmdWwgYXMgYmFzaXMgZm9yIGFzIGEgc29sdXRpb24gZm9yIGNvbnN0cmFpbmVkIGVudmly b25tZW50czxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkNoYW5nZSAjMzogKFByb3Bvc2FsIGZyb20gSmFyaSwgc3VwcG9ydGVk IGJ5IEJhcnJ5LCBSb2JlcnQgYW5kIEJlaGNldCk8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw cmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5PTEQ6PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Tm90ZSB0aGF0IHRoZSBpbml0aWFs IGZvY3VzIGlzIG9uIENvQVAgYW5kIEhUVFAgd2l0aCBEVExTIGFuZCBUTFMuPG86cD48L286cD48 L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+T3RoZXIgc2VjdXJpdHkgcHJvdG9jb2xzIG1heSBiZSBjb25zaWRl cmVkIGFzIGxvbmcgYXMgdGhlIHByaW1hcnkgZm9jdXMgaXMgbWFpbnRhaW5lZC4mbmJzcDsgPG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+T3RoZXIgYXBwbGljYXRpb24gcHJvdG9jb2xzIGFu ZCBwcm90b2NvbHMgYXQgb3RoZXIgbGF5ZXJzIGluIHRoZSBzdGFjayBhcmUgb3V0IG9mIHNjb3Bl LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPk5FVzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk5vdGUgdGhhdCB0aGUg aW5pdGlhbCBmb2N1cyBpcyBvbiBDb0FQIGFuZCBIVFRQIHdpdGggRFRMUyBhbmQgVExTLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk90aGVyIHNlY3VyaXR5IHByb3RvY29scyBtYXkgYmUg Y29uc2lkZXJlZCBhcyBsb25nIGFzIHRoZSBwcmltYXJ5IGZvY3VzIGlzIG1haW50YWluZWQuJm5i c3A7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSBncm91cCBpcyBzY29wZWQgdG8g d29yayBvbmx5IG9uIHRoZSB3ZWIgcHJvdG9jb2xzIGFuZCBkYXRhIGNhcnJpZWQgd2l0aGluIHRo ZW0uPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RU5EPG86cD48L286cD48L3NwYW4+PC9w cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q2hhbmdlIDQ6IChQ cm9wb3NhbCBmcm9tIEphcmksIHJldmlzZWQgYnkgUmVuZSwgc3VwcG9ydGVkIGJ5IFN0ZWZhbmll KTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk9MRDo8bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5KdWwgMjAxNCBTdWJtaXQgJnF1b3Q7VXNlIGNhc2VzIGFuZCBSZXF1aXJlbWVudHMm cXVvdDsmIzE1NzsgYXMgYSBXRyBpdGVtLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkp1 bCAyMDE1IFN1Ym1pdCDigJxVc2UgY2FzZXMgYW5kIFJlcXVpcmVtZW50c+KAnSBkb2N1bWVudCB0 byBJRVNHIGZvciBwdWJsaWNhdGlvbiBhcyBpbmZvcm1hdGlvbmFsIFJGQy48bzpwPjwvbzpwPjwv c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5ORVc8 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5EZWMgMjAxNCBTdWJtaXQgJnF1b3Q7VXNlIGNh c2VzIGFuZCBSZXF1aXJlbWVudHMmcXVvdDsmIzE1NzsgYXMgYSBXRyBpdGVtLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPkFwciAyMDE1IE9wdGlvbmFsbHksIHN1Ym1pdCAmcXVvdDtVc2Ug Y2FzZXMgYW5kIFJlcXVpcmVtZW50cyZxdW90OyBkb2N1bWVudCB0byB0aGUgSUVTRyBmb3I8bzpw PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5wdWJsaWNhdGlvbiBhcyBhbiBJbmZvcm1hdGlvbmFs IFJGQy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5FTkQ8bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5JIHRoaW5rIHdlIGNvdmVyZWQgYWxsIG9mIHRoZSBJRVNHIHJl dmlldyBjb21tZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SWYgdGhl cmUgaXMgYW55IG9wZW4gaXNzdWUsIHBsZWFzZSBsZXQgdXMga25vdy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5LaW5kIFJlZ2FyZHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPktlcGVuZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+Q2hhcnRlciBjaGFydGVyLWlldGYtYWNlLTAwLTAyPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BdXRoZW50aWNhdGlvbiBhbmQgQXV0 aG9yaXphdGlvbiBmb3IgQ29uc3RyYWluZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkVudmlyb25tZW50IChBQ0UpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPlRoZSBJRVRGIGhhcyByZWNlbnRseSBkZXZlbG9wZWQgcHJvdG9jb2xzIGZvciB1 c2UgaW4gY29uc3RyYWluZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPmVudmlyb25tZW50cywgd2hlcmUgbmV0d29yayBub2RlcyBhcmUgbGltaXRlZCBpbiBDUFUs IG1lbW9yeSBhbmQgcG93ZXIuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPlJFU1QgYXJjaGl0ZWN0dXJlIGlzIHdpZGVseSB1c2VkIGZvciBzdWNoIGNvbnN0cmFp bmVkIGVudmlyb25tZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPkl0IGhhcyBiZWVuIG9ic2VydmVkIHRoYXQgSW50ZXJuZXQgcHJvdG9jb2xzIGNhbiBiZSBh cHBsaWVkIHRvIHRoZXNlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5jb25zdHJhaW5lZCBlbnZpcm9ubWVudHMsIG9mdGVuIG9ubHkgcmVxdWlyaW5nIG1pbm9yIHR3 ZWFraW5nIGFuZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+cHJv ZmlsaW5nLiBJbiBvdGhlciBjYXNlcywgbmV3IHByb3RvY29scyBoYXZlIGJlZW4gZGVmaW5lZCB0 byBhZGRyZXNzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj50aGUg c3BlY2lmaWMgcmVxdWlyZW1lbnRzIG9mIGNvbnN0cmFpbmVkIGVudmlyb25tZW50cy4gQW4gZXhh bXBsZSBvZjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+c3VjaCBh IHByb3RvY29sIGlzIHRoZSBDb25zdHJhaW5lZCBBcHBsaWNhdGlvbiBQcm90b2NvbCAoQ29BUCku PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFzIGluIG90aGVyIGVudmlyb25t ZW50cywgYXV0aGVudGljYXRpb24gYW5kIGF1dGhvcml6YXRpb24gcXVlc3Rpb25zPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5hbHNvIGFyaXNlIGluIGNvbnN0cmFp bmVkIGVudmlyb25tZW50cy4gRm9yIGV4YW1wbGUsIGEgZG9vciBsb2NrIGhhcyB0bzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+YXV0aG9yaXplIHRoZSBwZXJzb24g c2Vla2luZyBhY2Nlc3MgdXNpbmcgYSAmcXVvdDtkaWdpdGFsIGtleSZxdW90Oy4gV2hlcmUgaXMg dGhlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5hdXRob3JpemF0 aW9uIHBvbGljeSBzdG9yZWQ/IEhvdyBkb2VzIHRoZSBkaWdpdGFsIGtleSBjb21tdW5pY2F0ZSB3 aXRoPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj50aGUgbG9jaz8g RG9lcyB0aGUgbG9jayBpbnRlcmFjdCB3aXRoIGFuIGF1dGhvcml6YXRpb24gc2VydmVyIHRvIG9i dGFpbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+YXV0aG9yaXph dGlvbiBpbmZvcm1hdGlvbj8gSG93IGNhbiBhY2Nlc3MgYmUgdGVtcG9yYXJpbHkgZ3JhbnRlZCB0 bzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+b3RoZXIgcGVyc29u cz8gSG93IGNhbiBhY2Nlc3MgYmUgcmV2b2tlZD8gVGhlc2UgdHlwZXMgb2YgcXVlc3Rpb25zIGhh dmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPmJlZW4gYW5zd2Vy ZWQgYnkgZXhpc3RpbmcgcHJvdG9jb2xzIGZvciB1c2UgY2FzZXMgb3V0c2lkZSBjb25zdHJhaW5l ZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ZW52aXJvbm1lbnRz LCBob3dldmVyIGluIGNvbnN0cmFpbmVkIGVudmlyb25tZW50cywgYWRkaXRpb25hbCBhbmQ8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPmRpZmZlcmVudCByZXF1aXJl bWVudHMgcG9zZSBjaGFsbGVuZ2VzIGZvciB0aGUgdXNlIG9mIHZhcmlvdXMgc2VjdXJpdHk8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPnByb3RvY29scy4gSW4gcGFy dGljdWxhciwgdGhlIG5lZWQgYXJpc2VzIGZvciBhIGR5bmFtaWMgYW5kIGZpbmUgZ3JhaW5lZDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+YWNjZXNzIGNvbnRyb2wg bWVjaGFuaXNtLCB3aGVyZSBjbGllbnRzIGFuZC9vciByZXNvdXJjZSBzZXJ2ZXJzIGFyZTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Y29uc3RyYWluZWQuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSBJRVRGIGhhcyBhIGxvbmcgaGlzdG9y eSBpbiBkZXZlbG9waW5nIHRocmVlLXBhcnR5IGF1dGhlbnRpY2F0aW9uIGFuZDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+YXV0aG9yaXphdGlvbiBwcm90b2NvbHMg Zm9yIGRpc3RyaWJ1dGVkIGVudmlyb25tZW50cy4gRXhhbXBsZXMgaW5jbHVkZTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+S2VyYmVyb3MsIHRoZSBQdWJsaWMgS2V5 IEluZnJhc3RydWN0dXJlIChQS0kpLCB0aGUgQXV0aGVudGljYXRpb24sPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BdXRob3JpemF0aW9uIGFuZCBBY2NvdW50aW5n IChBQUEpIGluZnJhc3RydWN0dXJlLGFuZCB0aGUgV2ViPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5BdXRob3JpemF0aW9uIFByb3RvY29sIChPQXV0aCkuIEFsbCB0 aGVzZSBwcm90b2NvbHMgZW5qb3kgd2lkZXNwcmVhZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+ZGVwbG95bWVudCBvbiB0aGUgSW50ZXJuZXQuIEFsdGhvdWdoIHRo ZXkgYWxsIGFpbSB0byBzb2x2ZSBhIHNpbWlsYXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPmdvYWwsIGF0IGFuIGFic3RyYWN0IGxldmVsLCB0aGV5IG9mZmVyIHF1 aXRlIGRpZmZlcmVudCBmdW5jdGlvbnMgYW5kPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj51dGlsaXplIGRpZmZlcmVudCBtZXNzYWdlIGV4Y2hhbmdlcy4gVGhlc2Ug ZGlmZmVyZW5jZXMgcmVzdWx0IGZyb20gdGhlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5tYWluIGRlcGxveW1lbnQgdXNlIGNhc2VzIHRoZXkgd2VyZSBkZXNpZ25l ZCBmb3IgcmVzcGVjdGl2ZWx5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5S ZXF1aXJlbWVudHMgZGVyaXZlZCBmcm9tIHVzZSBjYXNlcyBtYXkgaW5kaWNhdGUgdGhhdCBleGlz dGluZyB3b3JrIGlzDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PnVzZWZ1bCBhcyBiYXNpcyBmb3IgYXMgYSBzb2x1dGlvbiBmb3IgY29uc3RyYWluZWQgZW52aXJv bm1lbnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlc2Ug cHJvdG9jb2xzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+aG93 ZXZlciwgd2VyZSBub3Qgb3B0aW1pemVkIGZvciBjb25zdHJhaW5lZCBlbnZpcm9ubWVudHMuIEFk ZGl0aW9uYWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPnJlcXVp cmVtZW50cyB0aGF0IG5lZWQgdG8gYmUgdGFrZW4gaW50byBhY2NvdW50IGFyZSB0aGUgbGFjayBv ZiBhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5zdWl0YWJsZSB1 c2VyLWludGVyZmFjZSBhbmQgdGhlIGluYWJpbGl0eSBvZiBlbWJlZGRlZCBkZXZpY2VzIHRvIGNv bnRhY3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPmFuIGF1dGhv cml6YXRpb24gc2VydmVyIGluIHJlYWwtdGltZSB3aXRoIGV2ZXJ5IHJlc291cmNlIGFjY2VzcyBy ZXF1ZXN0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5kdWUgdG8g aW50ZXJtaXR0ZW50IGNvbm5lY3Rpdml0eSwgZXRjLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5UaGlzIHdvcmtpbmcgZ3JvdXAgdGhlcmVmb3JlIGFpbXMgdG8gcHJvZHVjZSBh IHN0YW5kYXJkaXplZCBzb2x1dGlvbiBmb3I8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPmF1dGhlbnRpY2F0aW9uIGFuZCBhdXRob3JpemF0aW9uIHRvIGVuYWJsZSBh dXRob3JpemVkIGFjY2VzcyAoR0VULCBQVVQsIFBPU1QsDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkRFTEVURSkgdG8gcmVzb3VyY2VzIGlkZW50aWZpZWQgYnkg YSBVUkkgYW5kIGhvc3RlZCBvbiBhIHJlc291cmNlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5zZXJ2ZXIgaW4gY29uc3RyYWluZWQgZW52aXJvbm1lbnRzLiBBcyBh IHN0YXJ0aW5nIHBvaW50LCB0aGUgd29ya2luZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+Z3JvdXAgd2lsbCBhc3N1bWUgdGhhdCBhY2Nlc3MgdG8gcmVzb3VyY2Vz IGF0IGEgcmVzb3VyY2Ugc2VydmVyIGJ5IGE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPmNsaWVudCBkZXZpY2UgdGFrZXMgcGxhY2UgdXNpbmcgQ29BUCBhbmQgaXMg cHJvdGVjdGVkIGJ5IERUTFMuIEJvdGg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPnJlc291cmNlIHNlcnZlciBhbmQgY2xpZW50IG1heSBiZSBjb25zdHJhaW5lZC4g VGhpcyBhY2Nlc3Mgd2lsbCBiZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+bWVkaWF0ZWQgYnkgYW4gYXV0aG9yaXphdGlvbiBzZXJ2ZXIsIHdoaWNoIGlzIG5vdCBj b25zaWRlcmVkIHRvIGJlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5jb25zdHJhaW5lZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RXhpc3Rp bmcgYXV0aGVudGljYXRpb24gYW5kIGF1dGhvcml6YXRpb24gcHJvdG9jb2xzIHdpbGwgYmUgZXZh bHVhdGVkDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPmFuZCBy ZS11c2VkIHdoZXJlIGFwcGxpY2FibGUgdG8gYnVpbGQgdGhlIGNvbnN0cmFpbmVkLWVudmlyb25t ZW50IHNvbHV0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ VGhpcyByZXF1aXJlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ cmVsZXZhbnQgc3BlY2lmaWNhdGlvbnMgdG8gYmUgcmV2aWV3ZWQgZm9yIHN1aXRhYmlsaXR5LCBz ZWxlY3RpbmcgYTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+c3Vi c2V0IG9mIHRoZW0gYW5kIHJlc3RyaWN0aW5nIHRoZSBvcHRpb25zIHdpdGhpbiBlYWNoIG9mIHRo ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+c3BlY2lmaWNhdGlv bnMuIFNvbWUgZnVuY3Rpb25hbGl0eSwgaG93ZXZlciwgbWF5IG5vdCBiZSBhdmFpbGFibGUgaW48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPmV4aXN0aW5nIHByb3Rv Y29scywgaW4gd2hpY2ggY2FzZSB0aGUgc29sdXRpb24gbWF5IGFsc28gaW52b2x2ZSBuZXc8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPnByb3RvY29sIHdvcmsuIExl dmVyYWdpbmcgZXhpc3Rpbmcgd29yayBtZWFucyB0aGUgd29ya2luZyBncm91cCBiZW5lZml0czxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ZnJvbSBhdmFpbGFibGUg c2VjdXJpdHkgYW5hbHlzaXMsIGltcGxlbWVudGF0aW9uLCBhbmQgZGVwbG95bWVudDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ZXhwZXJpZW5jZS4gTW9yZW92ZXIs IGEgc3RhbmRhcmRpemVkIHNvbHV0aW9uIGZvciBmZWRlcmF0ZWQ8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPmF1dGhlbnRpY2F0aW9uIGFuZCBhdXRob3JpemF0aW9u IHdpbGwgaGVscCB0byBzdGltdWxhdGUgdGhlIGRlcGxveW1lbnQ8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPm9mIGNvbnN0cmFpbmVkIGRldmljZXMgdGhhdCBwcm92 aWRlIGluY3JlYXNlZCBzZWN1cml0eS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+T25jZSBwcm9ncmVzcyBpbiBpZGVudGlmeWluZyBzdWl0YWJsZSBjYW5kaWRhdGUgc29sdXRp b25zIGhhcyBiZWVuIG1hZGUsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj50aGUgd29ya2luZyBncm91cCB3aWxsIHZlcmlmeSB3aGV0aGVyIHRoZSBzYW1lIG1lY2hh bmlzbXMgYXJlIGFsc288bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PmFwcGxpY2FibGUgYmV5b25kIHRoZSB1c2Ugb2YgQ29BUCBhbmQgRFRMUywgd2hpY2ggYXJlIHRo ZSB0d28gbWFpbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+cHJv dG9jb2xzIHRoZSBncm91cCB3aWxsIGZvY3VzIG9uIGZvciBhY2Nlc3MgdG8gcmVzb3VyY2VzLiBJ bjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+cGFydGljdWxhciwg dGhlIGFiaWxpdHkgdG8gdXNlIHRoZSBkZXZlbG9wZWQgc29sdXRpb24gb3ZlciBIVFRQIGFuZCBU TFM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPndpbGwgYmUgaW52 ZXN0aWdhdGVkLiBOb3RlIHRoYXQgdGhlIGluaXRpYWwgZm9jdXMgaXMgb24gQ29BUCBhbmQgSFRU UCB3aXRoIERUTFMgYW5kIFRMUy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPk90aGVyIHNlY3VyaXR5IHByb3RvY29scyBtYXkgYmUgY29uc2lkZXJlZCBhcyBsb25n IGFzIHRoZSBwcmltYXJ5IGZvY3VzIGlzIG1haW50YWluZWQuJm5ic3A7DQo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSBncm91cCBpcyBzY29wZWQgdG8gd29y ayBvbmx5IG9uIHRoZSB3ZWIgcHJvdG9jb2xzIGFuZCBkYXRhIGNhcnJpZWQgd2l0aGluIHRoZW0u PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5GdXJ0aGVybW9yZSwg dG8gZ3VhcmFudGVlIHNtb290aCB0cmFuc2l0aW9uLCB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPmludGVncmF0aW9uIHdpdGggZXhpc3RpbmcgZGVwbG95bWVu dHMgd2lsbCBiZSBzdHVkaWVkLCBwYXJ0aWN1bGFybHk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPmNvbmNlcm5pbmcgdGhlIHVzZSBvZiBwcm90b2NvbCB0cmFuc2xh dGlvbiBwcm94aWVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGlzIHdv cmsgZG9lcyBub3QgbWFrZSB0aGUgYXNzdW1wdGlvbiB0aGF0IHRoZSBwYXJ0eSBvZmZlcmluZzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+YXBwbGljYXRpb24gbGF5 ZXIgc2VydmljZXMgaXMgYWx3YXlzIHRoZSBzYW1lIHBhcnR5IG9mZmVyaW5nIG5ldHdvcms8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPmFjY2VzcyBzZXJ2aWNlcy48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlIHdvcmtpbmcgZ3JvdXAgaGFz IHRoZSBmb2xsb3dpbmcgdGFza3M6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjEpIFByb2R1Y2UgdXNlIGNhc2VzIGFuZCByZXF1aXJlbWVudHM8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+MikgSWRlbnRpZnkgYXV0aGVudGljYXRpb24gYW5kIGF1dGhvcml6 YXRpb24gbWVjaGFuaXNtcyBzdWl0YWJsZSBmb3I8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPnJlc291cmNlIGFjY2VzcyBpbiBjb25zdHJhaW5lZCBlbnZpcm9ubWVu dHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk1pbGVzdG9uZXM6PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkRlYyAyMDE0IFN1Ym1pdCAmcXVvdDtVc2Ug Y2FzZXMgYW5kIFJlcXVpcmVtZW50cyZxdW90OyBhcyBhIFdHIGl0ZW0uPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5EZWMgMjAxNCBTdWJtaXQgJnF1b3Q7QXV0aGVu dGljYXRpb24gYW5kIEF1dGhvcml6YXRpb24gU29sdXRpb24mcXVvdDsgYXMgYSBXRyBpdGVtLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QXByIDIwMTUgT3B0aW9u YWxseSwgc3VibWl0ICZxdW90O1VzZSBjYXNlcyBhbmQgUmVxdWlyZW1lbnRzJnF1b3Q7IGRvY3Vt ZW50DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPnRvIHRoZSBJ RVNHIGZvciBwdWJsaWNhdGlvbiBhcyBhbiBJbmZvcm1hdGlvbmFsIFJGQy48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkp1bCAyMDE2IFN1Ym1pdCAmcXVvdDtBdXRo ZW50aWNhdGlvbiBhbmQgQXV0aG9yaXphdGlvbiBTb2x1dGlvbiZxdW90OzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+c3BlY2lmaWNhdGlvbiB0byB0aGUgSUVTRyBm b3IgcHVibGljYXRpb24gYXMgYSBQcm9wb3NlZCBTdGFuZGFyZC48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+UHJvcG9zZWQgTWlsZXN0b25lcw0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5ObyBtaWxlc3RvbmVzIGZvciBjaGFydGVyIGZvdW5k LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBw dDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij7lj5Hku7bkuro8c3BhbiBsYW5nPSJFTi1VUyI+ Ojwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdCI+IEthdGhsZWVuIE1vcmlhcnR5IFttYWlsdG86a2F0aGxlZW4ubW9yaWFydHkuaWV0ZkBn bWFpbC5jb21dDQo8YnI+DQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQi PuWPkemAgeaXtumXtDxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4gMjAxNDwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdCI+5bm0PHNwYW4gbGFuZz0iRU4tVVMiPjY8L3NwYW4+5pyI PHNwYW4gbGFuZz0iRU4tVVMiPjM8L3NwYW4+5pelPHNwYW4gbGFuZz0iRU4tVVMiPiAxNDozMDxi cj4NCjwvc3Bhbj48Yj7mlLbku7bkuro8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNw YW4gbGFuZz0iRU4tVVMiPiBMaWtlcGVuZzxicj4NCjwvc3Bhbj48Yj7mioTpgIE8c3BhbiBsYW5n PSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBCZW5vaXQgQ2xhaXNlOyBh ZHJpYW5Ab2xkZG9nLmNvLnVrOyBhYWEtZG9jdG9yc0BpZXRmLm9yZzsgVGhlIElFU0c7IGFjZUBp ZXRmLm9yZzxicj4NCjwvc3Bhbj48Yj7kuLvpopg8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48 L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBSZTogUmV2aXNlZCBjaGFydGVyIHByb3Bvc2FsOiBjaGFy dGVyLWlldGYtYWNlLTAwLTAyPG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+SGkgS2VwZW5nLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPklm IHdlIGFyZSBhdCBhIHBvaW50IHdoZXJlIEkgY2FuIHVwZGF0ZSB0aGUgY2hhcnRlciwgc2VlbXMg dGhhdCB3YXksIHBsZWFzZSBzZW5kIHRoZSBsYXRlc3QgdmVyc2lvbiB0aGF0IGhhcyBiZWVuIGFn cmVlZCB1cG9uIGFuZCBJJ2xsIHRha2UgY2FyZSBvZiB0aGUgdXBkYXRlLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhhbmtzLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj5PbiBUdWUsIEp1biAzLCAyMDE0IGF0IDY6MzEgQU0sIExpa2VwZW5nICZsdDs8YSBo cmVmPSJtYWlsdG86bGlrZXBlbmdAaHVhd2VpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmxpa2VwZW5n QGh1YXdlaS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBCZW5vaXQsPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZndDtOb3Qgb25seSB3b3VsZCBJIGtlZXAgJnF1b3Q7 QUFBJnF1b3Q7LA0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5P Sy48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jmd0O2J1dCBJIHdv dWxkIHByb3Bvc2U8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mZ3Q7T0xEOjwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPiZndDtFeGlzdGluZyBhdXRoZW50aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlv biBwcm90b2NvbHMgd2lsbCBiZSB1c2VkIHdoZXJlPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5hcHBs aWNhYmxlIHRvIGJ1aWxkIHRoZSBjb25zdHJhaW5lZC1lbnZpcm9ubWVudCBzb2x1dGlvbi48L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jmd0O05FVzo8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5FeGlzdGluZyBhdXRoZW50aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlvbiBwcm90b2NvbHMg d2lsbCBiZSBldmFsdWF0ZWQgYW5kIHJlLXVzZWQgd2hlcmU8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PmFwcGxpY2FibGUgdG8gYnVpbGQgdGhlIGNvbnN0cmFpbmVkLWVudmlyb25tZW50IHNvbHV0aW9u Ljwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk9LLCBmaW5lIHdpdGggbWUuPC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhbmtzIGZvciB0aGUgZmVlZGJhY2su DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5LaW5kIFJlZ2FyZHM8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5LZXBlbmc8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBj bSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0Ij7lj5Hku7bkuro8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L3NwYW4+PC9iPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+IEJlbm9pdCBDbGFpc2UgW21h aWx0bzo8YSBocmVmPSJtYWlsdG86YmNsYWlzZUBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj5i Y2xhaXNlQGNpc2NvLmNvbTwvYT5dDQo8YnI+DQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQiPuWPkemAgeaXtumXtDxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvc3Bh bj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4gMjAxNDwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+5bm0PHNwYW4gbGFuZz0iRU4tVVMi PjY8L3NwYW4+5pyIPHNwYW4gbGFuZz0iRU4tVVMiPjM8L3NwYW4+5pelPHNwYW4gbGFuZz0iRU4t VVMiPiAxMjoxNjwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj7mlLbku7bkuro8c3BhbiBs YW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBMaWtlcGVuZzsgS2F0 aGxlZW4gTW9yaWFydHk7DQo8YSBocmVmPSJtYWlsdG86YWRyaWFuQG9sZGRvZy5jby51ayIgdGFy Z2V0PSJfYmxhbmsiPmFkcmlhbkBvbGRkb2cuY28udWs8L2E+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj7mioTpgIE8c3BhbiBsYW5nPSJFTi1V UyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiA8YSBocmVmPSJtYWlsdG86YWFhLWRv Y3RvcnNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCmFhYS1kb2N0b3JzQGlldGYub3JnPC9h PjsgVGhlIElFU0c7IDxhIGhyZWY9Im1haWx0bzphY2VAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij4NCmFjZUBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+5Li76aKYPHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxz cGFuIGxhbmc9IkVOLVVTIj4gUmU6IFJldmlzZWQgY2hhcnRlciBwcm9wb3NhbDogY2hhcnRlci1p ZXRmLWFjZS0wMC0wMjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVO LVVTIj5IaSwNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPkhlbGxvIGFsbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+QmFzZWQgb24gcmVjZW50IGRpc2N1c3Npb25zLCBJ IG1hZGUgYSByZXZpc2VkIGNoYXJ0ZXIgcHJvcG9zYWwsIGFzIGluY2x1ZGVkIGluIHRoaXMgZW1h aWwsIG5vdCBvbiB0aGUgd2VicGFnZSB5ZXQuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy ZT48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl PjxzcGFuIGxhbmc9IkVOLVVTIj5QbGVhc2UgdGFrZSBhIGxvb2sgYW5kIGxldCB1cyBrbm93IGlm IHlvdSBoYXZlIGFueSBmdXJ0aGVyIGNvbW1lbnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5AQWRyaWFuIGFuZCBAQmVub2l0LCBwbGVhc2UgY2hlY2sg aWYgdGhlIHByb3Bvc2VkIHRleHRzIGNhbiByZXNvbHZlIHlvdXIgY29tbWVudHMuPG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPlRoYW5rcyw8bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPktpbmQgUmVnYXJkczxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+S2VwZW5nPG86cD48 L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw cmU+PHNwYW4gbGFuZz0iRU4tVVMiPkNvbXBhcmVkIHdpdGggY2hhcnRlci1pZXRmLWFjZS0wMC0w MSBvbiB0aGUgd2VicGFnZSwgdGhlIGNoYW5nZXMgYXJlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+ DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4oMSkmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgQWRkIG9uZSBjbGFyaWZpY2F0aW9uIHNlbnRlbmNlIGFib3V0IFJFU1QgYXJjaGl0ZWN0dXJl OjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+T0xEPG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUgSUVURiBo YXMgcmVjZW50bHkgZGV2ZWxvcGVkIHByb3RvY29scyBmb3IgdXNlIGluIGNvbnN0cmFpbmVkPG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5lbnZpcm9ubWVu dHMsIHdoZXJlIG5ldHdvcmsgbm9kZXMgYXJlIGxpbWl0ZWQgaW4gQ1BVLCBtZW1vcnkgYW5kIHBv d2VyLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPlJF U1QgYXJjaGl0ZWN0dXJlIGlzIHdpZGVseSB1c2VkIGZvciBzdWNoIGNvbnN0cmFpbmVkIGVudmly b25tZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMi PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+ TkVXPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUg SUVURiBoYXMgcmVjZW50bHkgZGV2ZWxvcGVkIHByb3RvY29scyBmb3IgdXNlIGluIGNvbnN0cmFp bmVkPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5lbnZp cm9ubWVudHMsIHdoZXJlIG5ldHdvcmsgbm9kZXMgYXJlIGxpbWl0ZWQgaW4gQ1BVLCBtZW1vcnkg YW5kIHBvd2VyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1V UyI+UkVTVCBhcmNoaXRlY3R1cmUgaXMgd2lkZWx5IHVzZWQgZm9yIHN1Y2ggY29uc3RyYWluZWQg ZW52aXJvbm1lbnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJF Ti1VUyI+RU5EPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5Db25zaWRlcmluZyB0aGF0IE9MRCBp czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5PTEQ8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSBJRVRGIGhhcyByZWNlbnRseSBkZXZl bG9wZWQgcHJvdG9jb2xzIGZvciB1c2UgaW4gY29uc3RyYWluZWQ8L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPmVudmlyb25tZW50cywgd2hlcmUg bmV0d29yayBub2RlcyBhcmUgbGltaXRlZCBpbiBDUFUsIG1lbW9yeSBhbmQgcG93ZXIuIDwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbTox Mi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4uLi4gZmluZSB3aXRoIG1lPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPigyKSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBSZW1vdmUgPC9zcGFuPuKAnDxzcGFuIGxhbmc9IkVOLVVTIj5BQUEgcHJvdG9jb2w8L3NwYW4+ 4oCdPHNwYW4gbGFuZz0iRU4tVVMiPiBmcm9tIHRoZSBjaGFydGVyOjxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+T0xEPG86cD48L286cD48L3NwYW4+PC9w cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUgSUVURiBoYXMgYSBsb25nIGhpc3Rvcnkg aW4gZGV2ZWxvcGluZyB0aHJlZS1wYXJ0eSBhdXRoZW50aWNhdGlvbiBhbmQ8bzpwPjwvbzpwPjwv c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPmF1dGhvcml6YXRpb24gcHJvdG9j b2xzIGZvciBkaXN0cmlidXRlZCBlbnZpcm9ubWVudHMuIEV4YW1wbGVzIGluY2x1ZGU8bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPktlcmJlcm9zLCB0aGUg UHVibGljIEtleSBJbmZyYXN0cnVjdHVyZSAoUEtJKSwgdGhlIEF1dGhlbnRpY2F0aW9uLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+QXV0aG9yaXphdGlv biBhbmQgQWNjb3VudGluZyAoQUFBKSBpbmZyYXN0cnVjdHVyZSwgYW5kIHRoZSBXZWI8bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPkF1dGhvcml6YXRpb24g UHJvdG9jb2wgKE9BdXRoKS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFu Zz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5n PSJFTi1VUyI+TkVXPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVO LVVTIj5UaGUgSUVURiBoYXMgYSBsb25nIGhpc3RvcnkgaW4gZGV2ZWxvcGluZyB0aHJlZS1wYXJ0 eSBhdXRoZW50aWNhdGlvbiBhbmQ8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g bGFuZz0iRU4tVVMiPmF1dGhvcml6YXRpb24gcHJvdG9jb2xzIGZvciBkaXN0cmlidXRlZCBlbnZp cm9ubWVudHMuIEV4YW1wbGVzIGluY2x1ZGU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+ PHNwYW4gbGFuZz0iRU4tVVMiPktlcmJlcm9zLCB0aGUgUHVibGljIEtleSBJbmZyYXN0cnVjdHVy ZSAoUEtJKSwgYW5kIHRoZSBXZWIgQXV0aG9yaXphdGlvbiBQcm90b2NvbCAoT0F1dGgpLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+RU5EPG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVT Ij5XZSBoYXZlIEFBQS1kb2N0b3JzIHRlbGxpbmc6IG1heWJlIFJBRElVUyBpcyBhcHBsaWNhYmxl Pzxicj4NClBlcnNvbmFsbHksIEkgZG9uJ3Qga25vdyBhbmQgaXQgZG9lc24ndCBtYXR0ZXIgYXQg dGhpcyBwb2ludC48YnI+DQpXZSByZWNlaXZlZCBmZWVkYmFjayBzdWNoIGFzOjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPkxl dCdzIGJlIGNsZWFyIGhlcmU6IEl0IHdhcyBuZXZlciBzYWlkIChpbiB0aGUgY2hhcnRlciBvciBh bnl3aGVyZSBlbHNlIGluIHRoZSBncm91cCB0byBteSBrbm93bGVkZ2UpIHRoYXQgUkFESVVTIChv ciBpbmRlZWQgYW55IG90aGVyIEFBQSBwcm90b2NvbCkgd291bGQgbm90DQogcnVuIG9uIGNvbnN0 cmFpbmVkIGRldmljZXMgKFJGQyA3MjI4KS4gVGhlIGNoYXJ0ZXIgc2ltcGx5IHNhaWQgdGhlIHBy b3RvY29scyB3ZXJlIG5vdCBvcHRpbWlzZWQgZm9yIGNvbnN0cmFpbmVkIGRldmljZXMuIFRoYXQg ZG9lcyBub3QgcHJlY2x1ZGUgY29uc2lkZXJpbmcgYW55IHByb3RvY29sIGZvciBzdWl0YWJpbGl0 eSBmb3IgY29uc3RyYWluZWQgZGV2aWNlcyBlaXRoZXIgYSkgYXMgaXMsIGIpIGluIGEgcmVzdHJp Y3RlZCB3YXkgb3IgYykgaW4NCiBhbiBhZGFwdGVkIHdheS48YnI+DQo8YnI+DQpTbywgYXQgdGhp cyBzdGFnZSwgSSBkb24ndCB0aGluayBhbnkgcHJvdG9jb2xzIHNob3VsZCBiZSBleGNsdWRlZCBm cm9tIGNvbnNpZGVyYXRpb24gYW5kIHNob3VsZCBjZXJ0YWlubHkgbm90IGJlIGVsaW1pbmF0ZWQg b24gYSBodW5jaCB0aGF0IHRoZXkgbWlnaHQgYmUgJnF1b3Q7dG9vIGJpZyZxdW90Oy4gTGV0J3Mg ZG8gdGhlIGFzc2Vzc21lbnQgcHJvcGVybHkgYXQgdGhlIGFwcHJvcHJpYXRlIHRpbWUuIEFzIGEg cmVtaW5kZXIgLSB0aGUgZm9jdXMgbm93IGlzIHRvDQogY29tcGxldGUgdGhlIGNoYXJ0ZXIuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF Ti1VUyI+T3I8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4m Z3Q7Jmd0O1RoZSBDaGFydGVyIG1ha2VzIGEgbnVtYmVyIG9mIGFzc2VydGlvbnMgdGhhdCBhcmUg cHJvdmFibHkgZmFsc2UsIHN1Y2ggYXMgdGhhdCBBQUEgcHJvdG9jb2xzIGFyZSBpbmFwcHJvcHJp YXRlIGZvciBjb25zdHJhaW5lZCBlbnZpcm9ubWVudHMuPG86cD48L286cD48L3NwYW4+PC9wcmU+ DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5JbiBmYWN0LCB0aGUgY2hhcnRlciBkb2VzIG5vdCBz YXkgdGhhdC4gQnV0IHRvIGF2b2lkIGNvbmZ1c2lvbiwgbGV0J3MgcmVtb3ZlIEFBQSBwcm90b2Nv bCBmcm9tIHRoZSBjaGFydGVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs YW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh bmc9IkVOLVVTIj5JbiB0aGUgY2hhcnRlciwgd2UgbWVudGlvbmVkIHRoYXQgd2Ugd2FudCB0byBy ZXVzZSBleGlzdGluZyBhdXRoZW50aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlvbiBwcm90b2NvbHMg d2hlcmUgYXBwbGljYWJsZSB0byBidWlsZCB0aGUgY29uc3RyYWluZWQtZW52aXJvbm1lbnQgc29s dXRpb24uPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxh bmc9IkVOLVVTIj4uLi4gd2hpY2ggSSByZWFkIGFzOiBsZXQncyBjb25zaWRlciB0aGUgQUFBIHBy b3RvY29scywgYW5kIGV2YWx1YXRlIGlmIHRoZXkgd291bGQgd29yayBpbiBjb25zdHJhaW5lZCBk ZXZpY2VzLjxicj4NCkkgZG9uJ3QgdW5kZXJzdGFuZCB0aGUgbG9naWM6IHdoeSBkbyB5b3Ugd2Fu dCB0byByZW1vdmUgQUFBIGZyb20gdGhlIGNoYXJ0ZXI/PGJyPg0KTm90IG9ubHkgd291bGQgSSBr ZWVwICZxdW90O0FBQSZxdW90OywgYnV0IEkgd291bGQgcHJvcG9zZTxicj4NCjxicj4NCk9MRDo8 YnI+DQpFeGlzdGluZyBhdXRoZW50aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlvbiBwcm90b2NvbHMg d2lsbCBiZSB1c2VkIHdoZXJlPGJyPg0KYXBwbGljYWJsZSB0byBidWlsZCB0aGUgY29uc3RyYWlu ZWQtZW52aXJvbm1lbnQgc29sdXRpb248YnI+DQo8YnI+DQpORVc6PGJyPg0KRXhpc3RpbmcgYXV0 aGVudGljYXRpb24gYW5kIGF1dGhvcml6YXRpb24gcHJvdG9jb2xzIHdpbGwgYmUgZXZhbHVhdGVk IGFuZCByZS11c2VkIHdoZXJlPGJyPg0KYXBwbGljYWJsZSB0byBidWlsZCB0aGUgY29uc3RyYWlu ZWQtZW52aXJvbm1lbnQgc29sdXRpb248YnI+DQo8YnI+DQpSZWdhcmRzLCBCZW5vaXQ8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+KDMpIENsYXJpZnkgdGhlIHNj b3BlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+T0xE OjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Tm90ZSB0 aGF0IHRoZSBpbml0aWFsIGZvY3VzIGlzIG9uIENvQVAgYW5kIEhUVFAgd2l0aCBEVExTIGFuZCBU TFMuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5PdGhl ciBzZWN1cml0eSBwcm90b2NvbHMgbWF5IGJlIGNvbnNpZGVyZWQgYXMgbG9uZyBhcyB0aGUgcHJp bWFyeSBmb2N1cyBpcyBtYWludGFpbmVkLiZuYnNwOyA8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N CjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPk90aGVyIGFwcGxpY2F0aW9uIHByb3RvY29scyBhbmQg cHJvdG9jb2xzIGF0IG90aGVyIGxheWVycyBpbiB0aGUgc3RhY2sgYXJlIG91dCBvZiBzY29wZS48 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+TkVXPG86cD48 L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5Ob3RlIHRoYXQgdGhl IGluaXRpYWwgZm9jdXMgaXMgb24gQ29BUCBhbmQgSFRUUCB3aXRoIERUTFMgYW5kIFRMUy48bzpw PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPk90aGVyIHNlY3Vy aXR5IHByb3RvY29scyBtYXkgYmUgY29uc2lkZXJlZCBhcyBsb25nIGFzIHRoZSBwcmltYXJ5IGZv Y3VzIGlzIG1haW50YWluZWQuJm5ic3A7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48 c3BhbiBsYW5nPSJFTi1VUyI+VGhlIGdyb3VwIGlzIHNjb3BlZCB0byB3b3JrIG9ubHkgb24gdGhl IHdlYiBwcm90b2NvbHMgYW5kIGRhdGEgY2FycmllZCB3aXRoaW4gdGhlbS48bzpwPjwvbzpwPjwv c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPkVORDxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4oNCkmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgVXBkYXRlIG1pbGVzdG9uZXMgZm9yIHRoZSB1c2UgY2FzZSAmYW1wOyByZXF1aXJlbWVudHMg ZG9jdW1lbnQ6PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVT Ij5PTEQ6PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5K dWwgMjAxNSBTdWJtaXQgPC9zcGFuPuKAnDxzcGFuIGxhbmc9IkVOLVVTIj5Vc2UgY2FzZXMgYW5k IFJlcXVpcmVtZW50czwvc3Bhbj7igJ08c3BhbiBsYW5nPSJFTi1VUyI+IGRvY3VtZW50IHRvIElF U0cgZm9yIHB1YmxpY2F0aW9uIGFzIGluZm9ybWF0aW9uYWwgUkZDLjxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5ORVc8bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPkRlYyAyMDE0IE9wdGlvbmFsbHksIHN1Ym1pdCAm cXVvdDtVc2UgY2FzZXMgYW5kIFJlcXVpcmVtZW50cyZxdW90OyBkb2N1bWVudCB0byB0aGUgSUVT RyBmb3IgcHVibGljYXRpb24gYXMgYW4gSW5mb3JtYXRpb25hbCBSRkMuPG86cD48L286cD48L3Nw YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5FTkQ8bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Q2hhcnRlciBjaGFydGVyLWlldGYtYWNlLTAwLTAyPG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5BdXRoZW50aWNh dGlvbiBhbmQgQXV0aG9yaXphdGlvbiBmb3IgQ29uc3RyYWluZWQ8bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPkVudmlyb25tZW50IChBQ0UpPG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPlRoZSBJRVRGIGhhcyByZWNl bnRseSBkZXZlbG9wZWQgcHJvdG9jb2xzIGZvciB1c2UgaW4gY29uc3RyYWluZWQ8bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPmVudmlyb25tZW50cywgd2hl cmUgbmV0d29yayBub2RlcyBhcmUgbGltaXRlZCBpbiBDUFUsIG1lbW9yeSBhbmQgcG93ZXIuIDxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+UkVTVCBhcmNo aXRlY3R1cmUgaXMgd2lkZWx5IHVzZWQgZm9yIHN1Y2ggY29uc3RyYWluZWQgZW52aXJvbm1lbnRz LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+SXQgaGFz IGJlZW4gb2JzZXJ2ZWQgdGhhdCBJbnRlcm5ldCBwcm90b2NvbHMgY2FuIGJlIGFwcGxpZWQgdG8g dGhlc2U8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPmNv bnN0cmFpbmVkIGVudmlyb25tZW50cywgb2Z0ZW4gb25seSByZXF1aXJpbmcgbWlub3IgdHdlYWtp bmcgYW5kPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5w cm9maWxpbmcuIEluIG90aGVyIGNhc2VzLCBuZXcgcHJvdG9jb2xzIGhhdmUgYmVlbiBkZWZpbmVk IHRvIGFkZHJlc3M8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4t VVMiPnRoZSBzcGVjaWZpYyByZXF1aXJlbWVudHMgb2YgY29uc3RyYWluZWQgZW52aXJvbm1lbnRz LiBBbiBleGFtcGxlIG9mPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9 IkVOLVVTIj5zdWNoIGEgcHJvdG9jb2wgaXMgdGhlIENvbnN0cmFpbmVkIEFwcGxpY2F0aW9uIFBy b3RvY29sIChDb0FQKS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i RU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJF Ti1VUyI+QXMgaW4gb3RoZXIgZW52aXJvbm1lbnRzLCBhdXRoZW50aWNhdGlvbiBhbmQgYXV0aG9y aXphdGlvbiBxdWVzdGlvbnM8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFu Zz0iRU4tVVMiPmFsc28gYXJpc2UgaW4gY29uc3RyYWluZWQgZW52aXJvbm1lbnRzLiBGb3IgZXhh bXBsZSwgYSBkb29yIGxvY2sgaGFzIHRvPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz cGFuIGxhbmc9IkVOLVVTIj5hdXRob3JpemUgdGhlIHBlcnNvbiBzZWVraW5nIGFjY2VzcyB1c2lu ZyBhICZxdW90O2RpZ2l0YWwga2V5JnF1b3Q7LiBXaGVyZSBpcyB0aGU8bzpwPjwvbzpwPjwvc3Bh bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPmF1dGhvcml6YXRpb24gcG9saWN5IHN0 b3JlZD8gSG93IGRvZXMgdGhlIGRpZ2l0YWwga2V5IGNvbW11bmljYXRlIHdpdGg8bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPnRoZSBsb2NrPyBEb2VzIHRo ZSBsb2NrIGludGVyYWN0IHdpdGggYW4gYXV0aG9yaXphdGlvbiBzZXJ2ZXIgdG8gb2J0YWluPG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5hdXRob3JpemF0 aW9uIGluZm9ybWF0aW9uPyBIb3cgY2FuIGFjY2VzcyBiZSB0ZW1wb3JhcmlseSBncmFudGVkIHRv PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5vdGhlciBw ZXJzb25zPyBIb3cgY2FuIGFjY2VzcyBiZSByZXZva2VkPyBUaGVzZSB0eXBlcyBvZiBxdWVzdGlv bnMgaGF2ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+ YmVlbiBhbnN3ZXJlZCBieSBleGlzdGluZyBwcm90b2NvbHMgZm9yIHVzZSBjYXNlcyBvdXRzaWRl IGNvbnN0cmFpbmVkPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVO LVVTIj5lbnZpcm9ubWVudHMsIGhvd2V2ZXIgaW4gY29uc3RyYWluZWQgZW52aXJvbm1lbnRzLCBh ZGRpdGlvbmFsIGFuZDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJF Ti1VUyI+ZGlmZmVyZW50IHJlcXVpcmVtZW50cyBwb3NlIGNoYWxsZW5nZXMgZm9yIHRoZSB1c2Ug b2YgdmFyaW91cyBzZWN1cml0eTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs YW5nPSJFTi1VUyI+cHJvdG9jb2xzLiBJbiBwYXJ0aWN1bGFyLCB0aGUgbmVlZCBhcmlzZXMgZm9y IGEgZHluYW1pYyBhbmQgZmluZSBncmFpbmVkPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl PjxzcGFuIGxhbmc9IkVOLVVTIj5hY2Nlc3MgY29udHJvbCBtZWNoYW5pc20sIHdoZXJlIGNsaWVu dHMgYW5kL29yIHJlc291cmNlIHNlcnZlcnMgYXJlPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5jb25zdHJhaW5lZC48bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+VGhlIElFVEYgaGFzIGEgbG9uZyBoaXN0b3J5IGlu IGRldmVsb3BpbmcgdGhyZWUtcGFydHkgYXV0aGVudGljYXRpb24gYW5kPG86cD48L286cD48L3Nw YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5hdXRob3JpemF0aW9uIHByb3RvY29s cyBmb3IgZGlzdHJpYnV0ZWQgZW52aXJvbm1lbnRzLiBFeGFtcGxlcyBpbmNsdWRlPG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5LZXJiZXJvcywgdGhlIFB1 YmxpYyBLZXkgSW5mcmFzdHJ1Y3R1cmUgKFBLSSksIGFuZCB0aGUgV2ViPG86cD48L286cD48L3Nw YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5BdXRob3JpemF0aW9uIFByb3RvY29s IChPQXV0aCkuIEFsbCB0aGVzZSBwcm90b2NvbHMgZW5qb3kgd2lkZXNwcmVhZDxvOnA+PC9vOnA+ PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+ZGVwbG95bWVudCBvbiB0aGUg SW50ZXJuZXQuIEFsdGhvdWdoIHRoZXkgYWxsIGFpbSB0byBzb2x2ZSBhIHNpbWlsYXI8bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPmdvYWwsIGF0IGFuIGFi c3RyYWN0IGxldmVsLCB0aGV5IG9mZmVyIHF1aXRlIGRpZmZlcmVudCBmdW5jdGlvbnMgYW5kPG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj51dGlsaXplIGRp ZmZlcmVudCBtZXNzYWdlIGV4Y2hhbmdlcy4gVGhlc2UgZGlmZmVyZW5jZXMgcmVzdWx0IGZyb20g dGhlPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5tYWlu IGRlcGxveW1lbnQgdXNlIGNhc2VzIHRoZXkgd2VyZSBkZXNpZ25lZCBmb3IgcmVzcGVjdGl2ZWx5 LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5SZXF1aXJl bWVudHMgZGVyaXZlZCBmcm9tIHVzZSBjYXNlcyBpbmRpY2F0ZSB0aGUgc3VpdGFiaWxpdHkgb2Yg ZXhpc3Rpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMi PndvcmsgYXMgYSBzb2x1dGlvbiBmb3IgY29uc3RyYWluZWQgZW52aXJvbm1lbnRzLiBUaGVzZSBw cm90b2NvbHMsPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVT Ij5ob3dldmVyLCB3ZXJlIG5vdCBvcHRpbWl6ZWQgZm9yIGNvbnN0cmFpbmVkIGVudmlyb25tZW50 cy4gQWRkaXRpb25hbDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJF Ti1VUyI+cmVxdWlyZW1lbnRzIHRoYXQgbmVlZCB0byBiZSB0YWtlbiBpbnRvIGFjY291bnQgYXJl IHRoZSBsYWNrIG9mIGE8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i RU4tVVMiPnN1aXRhYmxlIHVzZXItaW50ZXJmYWNlIGFuZCB0aGUgaW5hYmlsaXR5IG9mIGVtYmVk ZGVkIGRldmljZXMgdG8gY29udGFjdDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh biBsYW5nPSJFTi1VUyI+YW4gYXV0aG9yaXphdGlvbiBzZXJ2ZXIgaW4gcmVhbC10aW1lIHdpdGgg ZXZlcnkgcmVzb3VyY2UgYWNjZXNzIHJlcXVlc3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw cmU+PHNwYW4gbGFuZz0iRU4tVVMiPmR1ZSB0byBpbnRlcm1pdHRlbnQgY29ubmVjdGl2aXR5LCBl dGMuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPlRoaXMg d29ya2luZyBncm91cCB0aGVyZWZvcmUgYWltcyB0byBwcm9kdWNlIGEgc3RhbmRhcmRpemVkIHNv bHV0aW9uIGZvcjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1V UyI+YXV0aGVudGljYXRpb24gYW5kIGF1dGhvcml6YXRpb24gdG8gZW5hYmxlIGF1dGhvcml6ZWQg YWNjZXNzIChHRVQsIFBVVCwgUE9TVCwgPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz cGFuIGxhbmc9IkVOLVVTIj5ERUxFVEUpIHRvIHJlc291cmNlcyBpZGVudGlmaWVkIGJ5IGEgVVJJ IGFuZCBob3N0ZWQgb24gYSByZXNvdXJjZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48 c3BhbiBsYW5nPSJFTi1VUyI+c2VydmVyIGluIGNvbnN0cmFpbmVkIGVudmlyb25tZW50cy4gQXMg YSBzdGFydGluZyBwb2ludCwgdGhlIHdvcmtpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw cmU+PHNwYW4gbGFuZz0iRU4tVVMiPmdyb3VwIHdpbGwgYXNzdW1lIHRoYXQgYWNjZXNzIHRvIHJl c291cmNlcyBhdCBhIHJlc291cmNlIHNlcnZlciBieSBhPG86cD48L286cD48L3NwYW4+PC9wcmU+ DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5jbGllbnQgZGV2aWNlIHRha2VzIHBsYWNlIHVzaW5n IENvQVAgYW5kIGlzIHByb3RlY3RlZCBieSBEVExTLiBCb3RoPG86cD48L286cD48L3NwYW4+PC9w cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5yZXNvdXJjZSBzZXJ2ZXIgYW5kIGNsaWVudCBt YXkgYmUgY29uc3RyYWluZWQuIFRoaXMgYWNjZXNzIHdpbGwgYmU8bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPm1lZGlhdGVkIGJ5IGFuIGF1dGhvcml6YXRp b24gc2VydmVyLCB3aGljaCBpcyBub3QgY29uc2lkZXJlZCB0byBiZTxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Y29uc3RyYWluZWQuPG86cD48L286cD48 L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPkV4aXN0aW5nIGF1dGhlbnRpY2F0 aW9uIGFuZCBhdXRob3JpemF0aW9uIHByb3RvY29scyB3aWxsIGJlIHVzZWQgd2hlcmU8bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPmFwcGxpY2FibGUgdG8g YnVpbGQgdGhlIGNvbnN0cmFpbmVkLWVudmlyb25tZW50IHNvbHV0aW9uLiBUaGlzIHJlcXVpcmVz PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5yZWxldmFu dCBzcGVjaWZpY2F0aW9ucyB0byBiZSByZXZpZXdlZCBmb3Igc3VpdGFiaWxpdHksIHNlbGVjdGlu ZyBhPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5zdWJz ZXQgb2YgdGhlbSBhbmQgcmVzdHJpY3RpbmcgdGhlIG9wdGlvbnMgd2l0aGluIGVhY2ggb2YgdGhl PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5zcGVjaWZp Y2F0aW9ucy4gU29tZSBmdW5jdGlvbmFsaXR5LCBob3dldmVyLCBtYXkgbm90IGJlIGF2YWlsYWJs ZSBpbjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+ZXhp c3RpbmcgcHJvdG9jb2xzLCBpbiB3aGljaCBjYXNlIHRoZSBzb2x1dGlvbiBtYXkgYWxzbyBpbnZv bHZlIG5ldzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+ cHJvdG9jb2wgd29yay4gTGV2ZXJhZ2luZyBleGlzdGluZyB3b3JrIG1lYW5zIHRoZSB3b3JraW5n IGdyb3VwIGJlbmVmaXRzPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9 IkVOLVVTIj5mcm9tIGF2YWlsYWJsZSBzZWN1cml0eSBhbmFseXNpcywgaW1wbGVtZW50YXRpb24s IGFuZCBkZXBsb3ltZW50PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9 IkVOLVVTIj5leHBlcmllbmNlLiBNb3Jlb3ZlciwgYSBzdGFuZGFyZGl6ZWQgc29sdXRpb24gZm9y IGZlZGVyYXRlZDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1V UyI+YXV0aGVudGljYXRpb24gYW5kIGF1dGhvcml6YXRpb24gd2lsbCBoZWxwIHRvIHN0aW11bGF0 ZSB0aGUgZGVwbG95bWVudDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5n PSJFTi1VUyI+b2YgY29uc3RyYWluZWQgZGV2aWNlcyB0aGF0IHByb3ZpZGUgaW5jcmVhc2VkIHNl Y3VyaXR5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5P bmNlIHByb2dyZXNzIGluIGlkZW50aWZ5aW5nIHN1aXRhYmxlIGNhbmRpZGF0ZSBzb2x1dGlvbnMg aGFzIGJlZW4gbWFkZSw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i RU4tVVMiPnRoZSB3b3JraW5nIGdyb3VwIHdpbGwgdmVyaWZ5IHdoZXRoZXIgdGhlIHNhbWUgbWVj aGFuaXNtcyBhcmUgYWxzbzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5n PSJFTi1VUyI+YXBwbGljYWJsZSBiZXlvbmQgdGhlIHVzZSBvZiBDb0FQIGFuZCBEVExTLCB3aGlj aCBhcmUgdGhlIHR3byBtYWluPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh bmc9IkVOLVVTIj5wcm90b2NvbHMgdGhlIGdyb3VwIHdpbGwgZm9jdXMgb24gZm9yIGFjY2VzcyB0 byByZXNvdXJjZXMuIEluPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9 IkVOLVVTIj5wYXJ0aWN1bGFyLCB0aGUgYWJpbGl0eSB0byB1c2UgdGhlIGRldmVsb3BlZCBzb2x1 dGlvbiBvdmVyIEhUVFAgYW5kIFRMUzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh biBsYW5nPSJFTi1VUyI+d2lsbCBiZSBpbnZlc3RpZ2F0ZWQuIE5vdGUgdGhhdCB0aGUgaW5pdGlh bCBmb2N1cyBpcyBvbiBDb0FQIGFuZCBIVFRQIHdpdGggRFRMUyBhbmQgVExTLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+T3RoZXIgc2VjdXJpdHkgcHJv dG9jb2xzIG1heSBiZSBjb25zaWRlcmVkIGFzIGxvbmcgYXMgdGhlIHByaW1hcnkgZm9jdXMgaXMg bWFpbnRhaW5lZC4mbmJzcDsgPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh bmc9IkVOLVVTIj5UaGUgZ3JvdXAgaXMgc2NvcGVkIHRvIHdvcmsgb25seSBvbiB0aGUgd2ViIHBy b3RvY29scyBhbmQgZGF0YSBjYXJyaWVkIHdpdGhpbiB0aGVtLjxvOnA+PC9vOnA+PC9zcGFuPjwv cHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+RnVydGhlcm1vcmUsIHRvIGd1YXJhbnRlZSBz bW9vdGggdHJhbnNpdGlvbiwgdGhlPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu IGxhbmc9IkVOLVVTIj5pbnRlZ3JhdGlvbiB3aXRoIGV4aXN0aW5nIGRlcGxveW1lbnRzIHdpbGwg YmUgc3R1ZGllZCwgcGFydGljdWxhcmx5PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz cGFuIGxhbmc9IkVOLVVTIj5jb25jZXJuaW5nIHRoZSB1c2Ugb2YgcHJvdG9jb2wgdHJhbnNsYXRp b24gcHJveGllcy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4t VVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1V UyI+VGhpcyB3b3JrIGRvZXMgbm90IG1ha2UgdGhlIGFzc3VtcHRpb24gdGhhdCB0aGUgcGFydHkg b2ZmZXJpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMi PmFwcGxpY2F0aW9uIGxheWVyIHNlcnZpY2VzIGlzIGFsd2F5cyB0aGUgc2FtZSBwYXJ0eSBvZmZl cmluZyBuZXR3b3JrPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVO LVVTIj5hY2Nlc3Mgc2VydmljZXMuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu IGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g bGFuZz0iRU4tVVMiPlRoZSB3b3JraW5nIGdyb3VwIGhhcyB0aGUgZm9sbG93aW5nIHRhc2tzOjxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4xKSBQcm9kdWNl IHVzZSBjYXNlcyBhbmQgcmVxdWlyZW1lbnRzPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl PjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+ PHNwYW4gbGFuZz0iRU4tVVMiPjIpIElkZW50aWZ5IGF1dGhlbnRpY2F0aW9uIGFuZCBhdXRob3Jp emF0aW9uIG1lY2hhbmlzbXMgc3VpdGFibGUgZm9yPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5yZXNvdXJjZSBhY2Nlc3MgaW4gY29uc3RyYWluZWQgZW52 aXJvbm1lbnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1V UyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVT Ij5NaWxlc3RvbmVzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJF Ti1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVO LVVTIj5KdWwgMjAxNCBTdWJtaXQgJnF1b3Q7VXNlIGNhc2VzIGFuZCBSZXF1aXJlbWVudHMmcXVv dDsgYXMgYSBXRyBpdGVtLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5n PSJFTi1VUyI+RGVjIDIwMTQgU3VibWl0ICZxdW90O0F1dGhlbnRpY2F0aW9uIGFuZCBBdXRob3Jp emF0aW9uIFNvbHV0aW9uJnF1b3Q7IGFzIGEgV0cgaXRlbS48bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPkRlYyAyMDE0IE9wdGlvbmFsbHksIHN1Ym1pdCAm cXVvdDtVc2UgY2FzZXMgYW5kIFJlcXVpcmVtZW50cyZxdW90OyBkb2N1bWVudCA8bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPnRvIHRoZSBJRVNHIGZvciBw dWJsaWNhdGlvbiBhcyBhbiBJbmZvcm1hdGlvbmFsIFJGQy48bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPkp1bCAyMDE2IFN1Ym1pdCAmcXVvdDtBdXRoZW50 aWNhdGlvbiBhbmQgQXV0aG9yaXphdGlvbiBTb2x1dGlvbiZxdW90OzxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+c3BlY2lmaWNhdGlvbiB0byB0aGUgSUVT RyBmb3IgcHVibGljYXRpb24gYXMgYSBQcm9wb3NlZCBTdGFuZGFyZC48bzpwPjwvbzpwPjwvc3Bh bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+UHJvcG9zZWQgTWlsZXN0b25lcyA8bzpw PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPk5vIG1pbGVzdG9u ZXMgZm9yIGNoYXJ0ZXIgZm91bmQuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+LS0gPG86cD48L286cD48L3NwYW4+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPkJlc3QgcmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+S2F0aGxlZW48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_34966E97BE8AD64EAE9D3D6E4DEE36F25815405DSZXEMA501MBSchi_-- From nobody Tue Jun 3 07:39:56 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B2A81A02E5; Tue, 3 Jun 2014 07:39:53 -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 aBd_7Uzf5IiZ; Tue, 3 Jun 2014 07:39:48 -0700 (PDT) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3B371A02D5; Tue, 3 Jun 2014 07:39:46 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id l4so3562414lbv.31 for ; Tue, 03 Jun 2014 07:39:39 -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=n78nD9w1+zihB0EBsrWm7ED3zvokkzWE2MYmtuphvig=; b=gsR32TegcOk2OBl7tuAyMapp2yJrpl8hV65TMtCxnVYF0BeNLYg7F62YZgPB4rdMMU j+8tkh9AY9jleP5BRR8ptC8KiIHjWMtOnXPaLqoOOlBQuNNBHESU/Xw7GERvN4nF8qub m0TPyUB8TMAwTOPyFbWJzJ77gIRrpMYK98I6nWqKl5bR8qKbXYXEjMHXXJ+VDN6xRden BTKQ8WCfcLHB4BbxAMC5gR/W8ksKrDDZjZ1kMUa7ChuNq4UgIXJ/Jr4upvvPmL5gAKbA dkuSsMPYhI9MqpDvqXr+C5+IBS2nveKd5W8NrWZEJYcsYjNm27jh6pIAmpUVcUGXBkY8 vX2Q== MIME-Version: 1.0 X-Received: by 10.152.21.169 with SMTP id w9mr214178lae.90.1401806379619; Tue, 03 Jun 2014 07:39:39 -0700 (PDT) Received: by 10.112.33.36 with HTTP; Tue, 3 Jun 2014 07:39:39 -0700 (PDT) In-Reply-To: <34966E97BE8AD64EAE9D3D6E4DEE36F25815405D@SZXEMA501-MBS.china.huawei.com> References: <20140514221215.8150.56543.idtracker@ietfa.amsl.com> <34966E97BE8AD64EAE9D3D6E4DEE36F252B2A345@SZXEMA501-MBS.china.huawei.com> <34966E97BE8AD64EAE9D3D6E4DEE36F252B38978@SZXEMA501-MBS.china.huawei.com> <34966E97BE8AD64EAE9D3D6E4DEE36F258140E59@SZXEMA501-MBX.china.huawei.com> <538DA047.7080902@cisco.com> <34966E97BE8AD64EAE9D3D6E4DEE36F258153F43@SZXEMA501-MBS.china.huawei.com> <34966E97BE8AD64EAE9D3D6E4DEE36F25815405D@SZXEMA501-MBS.china.huawei.com> Date: Tue, 3 Jun 2014 10:39:39 -0400 Message-ID: From: Kathleen Moriarty To: Likepeng Content-Type: multipart/alternative; boundary=089e0158b6d24d195504faef7b7c Archived-At: http://mailarchive.ietf.org/arch/msg/ace/fordqGqe1r7lAa26HFfuR_8LASo Cc: Benoit Claise , "adrian@olddog.co.uk" , "ace@ietf.org" , The IESG , "aaa-doctors@ietf.org" Subject: Re: [Ace] Revised charter proposal: charter-ietf-ace-00-02 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments $ace$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 14:39:53 -0000 --089e0158b6d24d195504faef7b7c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I believe there is agreement on the proposed changes. I'll make the updates later in the day (it's about 11:30 my time, maybe at 4) in case anyone wants to chime in. If we are all in agreement, I'll have it sent for IETF review at that point. Thank you! On Tue, Jun 3, 2014 at 10:26 AM, Likepeng wrote: > Hi Kathleen and all, > > > > This is what I have now: > > > > Change #1: (Proposed by Kepeng, confirmed by Benoit) > > OLD > > The IETF has recently developed protocols for use in constrained > > environments, where network nodes are limited in CPU, memory and power. > > > > NEW > > The IETF has recently developed protocols for use in constrained > > environments, where network nodes are limited in CPU, memory and power. > > REST architecture is widely used for such constrained environments. > > END > > > > Change #2: (Proposal from Rene, supported by Stefanie) > > OLD: > > Requirements derived from use cases indicate the suitability of existing > > work as a solution for constrained environments > > > > NEW: > > Requirements derived from use cases may indicate that existing work is > > useful as basis for as a solution for constrained environments > > > > Change #3: (Proposal from Jari, supported by Barry, Robert and Behcet) > > OLD: > > Note that the initial focus is on CoAP and HTTP with DTLS and TLS. > > Other security protocols may be considered as long as the primary focus i= s maintained. > > Other application protocols and protocols at other layers in the stack ar= e out of scope. > > > > NEW > > Note that the initial focus is on CoAP and HTTP with DTLS and TLS. > > Other security protocols may be considered as long as the primary focus i= s maintained. > > The group is scoped to work only on the web protocols and data carried wi= thin them. > > END > > > > Change 4: (Proposal from Jari, revised by Rene, supported by Stefanie) > > OLD: > > Jul 2014 Submit "Use cases and Requirements"=C2=9D as a WG item. > > Jul 2015 Submit =E2=80=9CUse cases and Requirements=E2=80=9D document to = IESG for publication as informational RFC. > > > > NEW > > Dec 2014 Submit "Use cases and Requirements"=C2=9D as a WG item. > > Apr 2015 Optionally, submit "Use cases and Requirements" document to the = IESG for > > publication as an Informational RFC. > > END > > > > I think we covered all of the IESG review comments. > > > > If there is any open issue, please let us know. > > > > Thanks, > > > > Kind Regards > > Kepeng > > > -------------------------------------------------------------------------= ---------------------------------------------------------------------------= ---- > > > > Charter charter-ietf-ace-00-02 > > Authentication and Authorization for Constrained > > Environment (ACE) > > > > The IETF has recently developed protocols for use in constrained > > environments, where network nodes are limited in CPU, memory and power. > > REST architecture is widely used for such constrained environments. > > It has been observed that Internet protocols can be applied to these > > constrained environments, often only requiring minor tweaking and > > profiling. In other cases, new protocols have been defined to address > > the specific requirements of constrained environments. An example of > > such a protocol is the Constrained Application Protocol (CoAP). > > > > As in other environments, authentication and authorization questions > > also arise in constrained environments. For example, a door lock has to > > authorize the person seeking access using a "digital key". Where is the > > authorization policy stored? How does the digital key communicate with > > the lock? Does the lock interact with an authorization server to obtain > > authorization information? How can access be temporarily granted to > > other persons? How can access be revoked? These types of questions have > > been answered by existing protocols for use cases outside constrained > > environments, however in constrained environments, additional and > > different requirements pose challenges for the use of various security > > protocols. In particular, the need arises for a dynamic and fine grained > > access control mechanism, where clients and/or resource servers are > > constrained. > > > > The IETF has a long history in developing three-party authentication and > > authorization protocols for distributed environments. Examples include > > Kerberos, the Public Key Infrastructure (PKI), the Authentication, > > Authorization and Accounting (AAA) infrastructure,and the Web > > Authorization Protocol (OAuth). All these protocols enjoy widespread > > deployment on the Internet. Although they all aim to solve a similar > > goal, at an abstract level, they offer quite different functions and > > utilize different message exchanges. These differences result from the > > main deployment use cases they were designed for respectively. > > > > Requirements derived from use cases may indicate that existing work is > > useful as basis for as a solution for constrained environments. > > These protocols, > > however, were not optimized for constrained environments. Additional > > requirements that need to be taken into account are the lack of a > > suitable user-interface and the inability of embedded devices to contact > > an authorization server in real-time with every resource access request > > due to intermittent connectivity, etc. > > > > This working group therefore aims to produce a standardized solution for > > authentication and authorization to enable authorized access (GET, PUT, > POST, > > DELETE) to resources identified by a URI and hosted on a resource > > server in constrained environments. As a starting point, the working > > group will assume that access to resources at a resource server by a > > client device takes place using CoAP and is protected by DTLS. Both > > resource server and client may be constrained. This access will be > > mediated by an authorization server, which is not considered to be > > constrained. > > > > Existing authentication and authorization protocols will be evaluated > > and re-used where applicable to build the constrained-environment solutio= n. > > This requires > > relevant specifications to be reviewed for suitability, selecting a > > subset of them and restricting the options within each of the > > specifications. Some functionality, however, may not be available in > > existing protocols, in which case the solution may also involve new > > protocol work. Leveraging existing work means the working group benefits > > from available security analysis, implementation, and deployment > > experience. Moreover, a standardized solution for federated > > authentication and authorization will help to stimulate the deployment > > of constrained devices that provide increased security. > > > > Once progress in identifying suitable candidate solutions has been made, > > the working group will verify whether the same mechanisms are also > > applicable beyond the use of CoAP and DTLS, which are the two main > > protocols the group will focus on for access to resources. In > > particular, the ability to use the developed solution over HTTP and TLS > > will be investigated. Note that the initial focus is on CoAP and HTTP wit= h > DTLS and TLS. > > Other security protocols may be considered as long as the primary focus i= s > maintained. > > The group is scoped to work only on the web protocols and data carried > within them. > > Furthermore, to guarantee smooth transition, the > > integration with existing deployments will be studied, particularly > > concerning the use of protocol translation proxies. > > > > This work does not make the assumption that the party offering > > application layer services is always the same party offering network > > access services. > > > > The working group has the following tasks: > > > > 1) Produce use cases and requirements > > > > 2) Identify authentication and authorization mechanisms suitable for > > resource access in constrained environments. > > > > Milestones: > > > > Dec 2014 Submit "Use cases and Requirements" as a WG item. > > Dec 2014 Submit "Authentication and Authorization Solution" as a WG item. > > Apr 2015 Optionally, submit "Use cases and Requirements" document > > to the IESG for publication as an Informational RFC. > > Jul 2016 Submit "Authentication and Authorization Solution" > > specification to the IESG for publication as a Proposed Standard. > > > > Proposed Milestones > > No milestones for charter found. > > > > > > > > *=E5=8F=91=E4=BB=B6=E4=BA=BA:* Kathleen Moriarty [mailto:kathleen.moriart= y.ietf@gmail.com] > *=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4:* 2014=E5=B9=B46=E6=9C=883=E6=97=A5= 14:30 > *=E6=94=B6=E4=BB=B6=E4=BA=BA:* Likepeng > *=E6=8A=84=E9=80=81:* Benoit Claise; adrian@olddog.co.uk; aaa-doctors@iet= f.org; The IESG; > ace@ietf.org > *=E4=B8=BB=E9=A2=98:* Re: Revised charter proposal: charter-ietf-ace-00-0= 2 > > > > Hi Kepeng, > > > > If we are at a point where I can update the charter, seems that way, > please send the latest version that has been agreed upon and I'll take ca= re > of the update. > > > > Thanks. > > > > On Tue, Jun 3, 2014 at 6:31 AM, Likepeng wrote: > > Hi Benoit, > > > > >Not only would I keep "AAA", > > > > OK. > > > > >but I would propose > > > > >OLD: > > >Existing authentication and authorization protocols will be used where > > applicable to build the constrained-environment solution. > > > > >NEW: > > Existing authentication and authorization protocols will be evaluated and > re-used where > > applicable to build the constrained-environment solution. > > > > OK, fine with me. > > > > Thanks for the feedback. > > > > Kind Regards > > Kepeng > > > > *=E5=8F=91=E4=BB=B6=E4=BA=BA:* Benoit Claise [mailto:bclaise@cisco.com] > *=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4:* 2014=E5=B9=B46=E6=9C=883=E6=97=A5= 12:16 > > *=E6=94=B6=E4=BB=B6=E4=BA=BA:* Likepeng; Kathleen Moriarty; adrian@olddog= .co.uk > > *=E6=8A=84=E9=80=81:* aaa-doctors@ietf.org; The IESG; ace@ietf.org > > *=E4=B8=BB=E9=A2=98:* Re: Revised charter proposal: charter-ietf-ace-00-0= 2 > > > > Hi, > > Hello all, > > > > Based on recent discussions, I made a revised charter proposal, as includ= ed in this email, not on the webpage yet. > > > > Please take a look and let us know if you have any further comments. > > > > @Adrian and @Benoit, please check if the proposed texts can resolve your = comments. > > > > Thanks, > > Kind Regards > > Kepeng > > > > -------------------------------------------------------------------------= ---------------------------------------------------------------------------= --------- > > Compared with charter-ietf-ace-00-01 on the webpage, the changes are: > > > > (1) Add one clarification sentence about REST architecture: > > OLD > > The IETF has recently developed protocols for use in constrained > > environments, where network nodes are limited in CPU, memory and power. > > REST architecture is widely used for such constrained environments. > > > > NEW > > The IETF has recently developed protocols for use in constrained > > environments, where network nodes are limited in CPU, memory and power. > > REST architecture is widely used for such constrained environments. > > END > > Considering that OLD is > > OLD > > The IETF has recently developed protocols for use in constrained > > environments, where network nodes are limited in CPU, memory and power. > > ... fine with me > > > > > > (2) Remove =E2=80=9CAAA protocol=E2=80=9D from the charter: > > OLD > > The IETF has a long history in developing three-party authentication and > > authorization protocols for distributed environments. Examples include > > Kerberos, the Public Key Infrastructure (PKI), the Authentication, > > Authorization and Accounting (AAA) infrastructure, and the Web > > Authorization Protocol (OAuth). > > > > NEW > > The IETF has a long history in developing three-party authentication and > > authorization protocols for distributed environments. Examples include > > Kerberos, the Public Key Infrastructure (PKI), and the Web Authorization = Protocol (OAuth). > > END > > We have AAA-doctors telling: maybe RADIUS is applicable? > Personally, I don't know and it doesn't matter at this point. > We received feedback such as: > > Let's be clear here: It was never said (in the charter or anywhere else i= n > the group to my knowledge) that RADIUS (or indeed any other AAA protocol) > would not run on constrained devices (RFC 7228). The charter simply said > the protocols were not optimised for constrained devices. That does not > preclude considering any protocol for suitability for constrained devices > either a) as is, b) in a restricted way or c) in an adapted way. > > So, at this stage, I don't think any protocols should be excluded from > consideration and should certainly not be eliminated on a hunch that they > might be "too big". Let's do the assessment properly at the appropriate > time. As a reminder - the focus now is to complete the charter. > > Or > > >>The Charter makes a number of assertions that are provably false, such = as that AAA protocols are inappropriate for constrained environments. > > In fact, the charter does not say that. But to avoid confusion, let's rem= ove AAA protocol from the charter. > > > > In the charter, we mentioned that we want to reuse existing authenticatio= n and authorization protocols where applicable to build the constrained-env= ironment solution. > > ... which I read as: let's consider the AAA protocols, and evaluate if > they would work in constrained devices. > I don't understand the logic: why do you want to remove AAA from the > charter? > Not only would I keep "AAA", but I would propose > > OLD: > Existing authentication and authorization protocols will be used where > applicable to build the constrained-environment solution > > NEW: > Existing authentication and authorization protocols will be evaluated and > re-used where > applicable to build the constrained-environment solution > > Regards, Benoit > > > > > > (3) Clarify the scope: > > OLD: > > Note that the initial focus is on CoAP and HTTP with DTLS and TLS. > > Other security protocols may be considered as long as the primary focus i= s maintained. > > Other application protocols and protocols at other layers in the stack ar= e out of scope. > > > > NEW > > Note that the initial focus is on CoAP and HTTP with DTLS and TLS. > > Other security protocols may be considered as long as the primary focus i= s maintained. > > The group is scoped to work only on the web protocols and data carried wi= thin them. > > END > > > > (4) Update milestones for the use case & requirements document: > > OLD: > > Jul 2015 Submit =E2=80=9CUse cases and Requirements=E2=80=9D document to = IESG for publication as informational RFC. > > > > NEW > > Dec 2014 Optionally, submit "Use cases and Requirements" document to the = IESG for publication as an Informational RFC. > > END > > > > -------------------------------------------------------------------------= ---------------------------------------------------------------------------= ------------------------ > > Charter charter-ietf-ace-00-02 > > Authentication and Authorization for Constrained > > Environment (ACE) > > > > The IETF has recently developed protocols for use in constrained > > environments, where network nodes are limited in CPU, memory and power. > > REST architecture is widely used for such constrained environments. > > It has been observed that Internet protocols can be applied to these > > constrained environments, often only requiring minor tweaking and > > profiling. In other cases, new protocols have been defined to address > > the specific requirements of constrained environments. An example of > > such a protocol is the Constrained Application Protocol (CoAP). > > > > As in other environments, authentication and authorization questions > > also arise in constrained environments. For example, a door lock has to > > authorize the person seeking access using a "digital key". Where is the > > authorization policy stored? How does the digital key communicate with > > the lock? Does the lock interact with an authorization server to obtain > > authorization information? How can access be temporarily granted to > > other persons? How can access be revoked? These types of questions have > > been answered by existing protocols for use cases outside constrained > > environments, however in constrained environments, additional and > > different requirements pose challenges for the use of various security > > protocols. In particular, the need arises for a dynamic and fine grained > > access control mechanism, where clients and/or resource servers are > > constrained. > > > > The IETF has a long history in developing three-party authentication and > > authorization protocols for distributed environments. Examples include > > Kerberos, the Public Key Infrastructure (PKI), and the Web > > Authorization Protocol (OAuth). All these protocols enjoy widespread > > deployment on the Internet. Although they all aim to solve a similar > > goal, at an abstract level, they offer quite different functions and > > utilize different message exchanges. These differences result from the > > main deployment use cases they were designed for respectively. > > > > Requirements derived from use cases indicate the suitability of existing > > work as a solution for constrained environments. These protocols, > > however, were not optimized for constrained environments. Additional > > requirements that need to be taken into account are the lack of a > > suitable user-interface and the inability of embedded devices to contact > > an authorization server in real-time with every resource access request > > due to intermittent connectivity, etc. > > > > This working group therefore aims to produce a standardized solution for > > authentication and authorization to enable authorized access (GET, PUT, P= OST, > > DELETE) to resources identified by a URI and hosted on a resource > > server in constrained environments. As a starting point, the working > > group will assume that access to resources at a resource server by a > > client device takes place using CoAP and is protected by DTLS. Both > > resource server and client may be constrained. This access will be > > mediated by an authorization server, which is not considered to be > > constrained. > > > > Existing authentication and authorization protocols will be used where > > applicable to build the constrained-environment solution. This requires > > relevant specifications to be reviewed for suitability, selecting a > > subset of them and restricting the options within each of the > > specifications. Some functionality, however, may not be available in > > existing protocols, in which case the solution may also involve new > > protocol work. Leveraging existing work means the working group benefits > > from available security analysis, implementation, and deployment > > experience. Moreover, a standardized solution for federated > > authentication and authorization will help to stimulate the deployment > > of constrained devices that provide increased security. > > > > Once progress in identifying suitable candidate solutions has been made, > > the working group will verify whether the same mechanisms are also > > applicable beyond the use of CoAP and DTLS, which are the two main > > protocols the group will focus on for access to resources. In > > particular, the ability to use the developed solution over HTTP and TLS > > will be investigated. Note that the initial focus is on CoAP and HTTP wit= h DTLS and TLS. > > Other security protocols may be considered as long as the primary focus i= s maintained. > > The group is scoped to work only on the web protocols and data carried wi= thin them. > > Furthermore, to guarantee smooth transition, the > > integration with existing deployments will be studied, particularly > > concerning the use of protocol translation proxies. > > > > This work does not make the assumption that the party offering > > application layer services is always the same party offering network > > access services. > > > > The working group has the following tasks: > > > > 1) Produce use cases and requirements > > > > 2) Identify authentication and authorization mechanisms suitable for > > resource access in constrained environments. > > > > Milestones: > > > > Jul 2014 Submit "Use cases and Requirements" as a WG item. > > Dec 2014 Submit "Authentication and Authorization Solution" as a WG item. > > Dec 2014 Optionally, submit "Use cases and Requirements" document > > to the IESG for publication as an Informational RFC. > > Jul 2016 Submit "Authentication and Authorization Solution" > > specification to the IESG for publication as a Proposed Standard. > > > > Proposed Milestones > > No milestones for charter found. > > > > > > > > -- > > > > Best regards, > > Kathleen > --=20 Best regards, Kathleen --089e0158b6d24d195504faef7b7c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I believe there is agreement on the proposed changes. =C2= =A0I'll make the updates later in the day (it's about 11:30 my time= , maybe at 4) in case anyone wants to chime in. =C2=A0If we are all in agre= ement, I'll have it sent for IETF review at that point.

Thank you!

On Tue, Jun 3, 2014 at 10:26 AM, Likepeng <likep= eng@huawei.com> wrote:

Hi Kathlee= n and all,

=C2= =A0

This is wh= at I have now:

=C2= =A0

Change #1:= (Proposed by Kepeng, confirmed by Benoit)

OLD
The IETF has recently develo= ped protocols for use in constrained

environments, where network = nodes are limited in CPU, memory and power.

=C2=A0<= /pre>
NEW

The IETF has recently develo= ped protocols for use in constrained

environments, where network = nodes are limited in CPU, memory and power.

REST architecture is widely = used for such constrained environments.

END
=C2=A0<= /pre>
Change #2: (Proposal f= rom Rene, supported by Stefanie)

OLD:

Requirements derived from us= e cases indicate the suitability of existing

work as a solution for const= rained environments

=C2=A0<= /pre>
NEW:

Requirements derived from us= e cases may indicate that existing work is

useful as basis for a= s a solution for constrained environments

=C2=A0<= /pre>
Change #3: (Proposal from Ja= ri, supported by Barry, Robert and Behcet)

OLD:
Note that the initial focus = is on CoAP and HTTP with DTLS and TLS.

Other security protocols may= be considered as long as the primary focus is maintained.=C2=A0 =

Other application protocols = and protocols at other layers in the stack are out of scope.<= /span>

=C2=A0<= /pre>
NEW
Note that the initial focus = is on CoAP and HTTP with DTLS and TLS.

Other security protocols may= be considered as long as the primary focus is maintained.=C2=A0 =

The group is scoped to work = only on the web protocols and data carried within them.

END
=C2=A0<= /pre>
Change 4: (Proposal fr= om Jari, revised by Rene, supported by Stefanie)

OLD:

Jul 2014 Submit "Use ca= ses and Requirements"=C2=9D as a WG item.

Jul 2015 Submit =E2=80= =9CUse cases and Requirements=E2=80=9D document to IESG for publication as = informational RFC.

=C2=A0<= /pre>
NEW
Dec 2014 Submit "Use ca= ses and Requirements"=C2=9D as a WG item.

Apr 2015 Optionally, submit = "Use cases and Requirements" document to the IESG for

publication as an Informatio= nal RFC.

END
=C2= =A0

I th= ink we covered all of the IESG review comments.

=C2= =A0

If there i= s any open issue, please let us know.

=C2= =A0

Thanks,=

=C2= =A0

Kind Regar= ds

Kepeng<= /u>

----------= ---------------------------------------------------------------------------= -------------------------------------------------------------------<= u>

=C2= =A0

Charter ch= arter-ietf-ace-00-02

Authentica= tion and Authorization for Constrained

Environmen= t (ACE)

=C2= =A0

The IETF h= as recently developed protocols for use in constrained=

environmen= ts, where network nodes are limited in CPU, memory and power.

REST archi= tecture is widely used for such constrained environments.

It has bee= n observed that Internet protocols can be applied to these

constraine= d environments, often only requiring minor tweaking and

profiling.= In other cases, new protocols have been defined to address

the specif= ic requirements of constrained environments. An example of

such a pro= tocol is the Constrained Application Protocol (CoAP).<= /p>
=C2= =A0

As in othe= r environments, authentication and authorization questions

also arise= in constrained environments. For example, a door lock has to=

authorize = the person seeking access using a "digital key". Where is the<= /u>

authorizat= ion policy stored? How does the digital key communicate with<= /span>

the lock? = Does the lock interact with an authorization server to obtain=

authorizat= ion information? How can access be temporarily granted to

other pers= ons? How can access be revoked? These types of questions have=

been answe= red by existing protocols for use cases outside constrained

environmen= ts, however in constrained environments, additional and

different = requirements pose challenges for the use of various security<= /span>

protocols.= In particular, the need arises for a dynamic and fine grained

access con= trol mechanism, where clients and/or resource servers are

constraine= d.

=C2= =A0

The IETF h= as a long history in developing three-party authentication and

authorizat= ion protocols for distributed environments. Examples include<= /span>

Authorizat= ion and Accounting (AAA) infrastructure,and the Web

Authorizat= ion Protocol (OAuth). All these protocols enjoy widespread

deployment= on the Internet. Although they all aim to solve a similar

goal, at a= n abstract level, they offer quite different functions and

utilize di= fferent message exchanges. These differences result from the<= /span>

main deplo= yment use cases they were designed for respectively.
=C2= =A0

Requ= irements derived from use cases may indicate that existing work is

useful as = basis for as a solution for constrained environments.<= /p>

These prot= ocols,

however, w= ere not optimized for constrained environments. Additional

requiremen= ts that need to be taken into account are the lack of a

suitable u= ser-interface and the inability of embedded devices to contact

an authori= zation server in real-time with every resource access request=

due to int= ermittent connectivity, etc.

=C2= =A0

This worki= ng group therefore aims to produce a standardized solution for

authentica= tion and authorization to enable authorized access (GET, PUT, POST,

DELETE) to= resources identified by a URI and hosted on a resource

server in = constrained environments. As a starting point, the working

group will= assume that access to resources at a resource server by a

client dev= ice takes place using CoAP and is protected by DTLS. Both

resource s= erver and client may be constrained. This access will be

mediated b= y an authorization server, which is not considered to be

constraine= d.

=C2= =A0

Exis= ting authentication and authorization protocols will be evaluated

and re-use= d where applicable to build the constrained-environment solution.=

This= requires

relevant s= pecifications to be reviewed for suitability, selecting a

subset of = them and restricting the options within each of the
specificat= ions. Some functionality, however, may not be available in

existing p= rotocols, in which case the solution may also involve new

protocol w= ork. Leveraging existing work means the working group benefits

from avail= able security analysis, implementation, and deployment=

experience= . Moreover, a standardized solution for federated

authentica= tion and authorization will help to stimulate the deployment<= /span>

of constra= ined devices that provide increased security.

=C2= =A0

Once progr= ess in identifying suitable candidate solutions has been made,

the workin= g group will verify whether the same mechanisms are also

applicable= beyond the use of CoAP and DTLS, which are the two main

protocols = the group will focus on for access to resources. In
particular= , the ability to use the developed solution over HTTP and TLS=

will be in= vestigated. Note that the initial focus is on CoAP and HTTP with DTLS and T= LS.

Other secu= rity protocols may be considered as long as the primary focus is maintained= .=C2=A0

The group = is scoped to work only on the web protocols and data carried within them.

Furthermor= e, to guarantee smooth transition, the

integratio= n with existing deployments will be studied, particularly

concerning= the use of protocol translation proxies.

=C2= =A0

This work = does not make the assumption that the party offering
applicatio= n layer services is always the same party offering network

access ser= vices.

=C2= =A0

The workin= g group has the following tasks:

=C2= =A0

1) Produce= use cases and requirements

=C2= =A0

2) Identif= y authentication and authorization mechanisms suitable for

resource a= ccess in constrained environments.

=C2= =A0

Milestones= :

=C2= =A0

Dec 2014 S= ubmit "Authentication and Authorization Solution" as a WG item.

Apr = 2015 Optionally, submit "Use cases and Requirements" document

to the IES= G for publication as an Informational RFC.

Jul 2016 S= ubmit "Authentication and Authorization Solution"

specificat= ion to the IESG for publication as a Proposed Standard.

=C2= =A0

Proposed M= ilestones

No milesto= nes for charter found.

=C2= =A0

=C2= =A0

=C2= =A0

=E5=8F=91=E4=BB= =B6=E4=BA=BA: Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail= .com]
=E5=8F=91=E9=80=81=E6=97=B6=E9= =97=B4: 2014=E5=B9=B46=E6=9C=883=E6=97=A5<= span lang=3D"EN-US"> 14:30
=E6=94=B6=E4=BB=B6=E4=BA=BA: Likepeng
=E6=8A=84=E9=80=81: Benoit Claise; adrian@olddog.co.uk; aaa-doctors@ietf.org; The IESG; ace@ietf.org

=E4=B8=BB=E9=A2=98: Re: Revised charter proposal: cha= rter-ietf-ace-00-02

=C2=A0

Hi Kepeng,=

=C2=A0

If we are at a point where I ca= n update the charter, seems that way, please send the latest version that h= as been agreed upon and I'll take care of the update.

=C2=A0

Thanks.

= =C2=A0

On Tue, Jun 3, 2014 at 6:31 AM,= Likepeng <like= peng@huawei.com> wrote:

Hi Benoit,=

=C2=A0

>Not on= ly would I keep "AAA",

=C2=A0

OK.=

=C2=A0

>but I = would propose

=C2=A0

>OLD:

>Existi= ng authentication and authorization protocols will be used where

applicable= to build the constrained-environment solution.=

=C2=A0

>NEW:

Existing a= uthentication and authorization protocols will be evaluated and re-used whe= re

applicable= to build the constrained-environment solution.=

=C2=A0

OK, fine w= ith me.

=C2=A0

Thanks for= the feedback.

=C2=A0

Kind Regar= ds

Kepeng

=C2=A0

=E5=8F=91=E4=BB= =B6=E4=BA=BA: Benoit Claise [mailto:bclaise@cisco.com]
=E5=8F=91=E9=80=81=E6=97=B6=E9= =97=B4: 2014=E5=B9=B46=E6=9C=883=E6=97=A5<= span lang=3D"EN-US"> 12:16=

=E6=94=B6=E4=BB=B6=E4=BA=BA:= Likepeng; Kathleen Moriarty; adrian@olddog.co.u= k

=E6=8A=84=E9=80=81: aaa-doctors@ietf.org; The IESG; ace@ietf.org

=E4=B8=BB=E9=A2=98: Re: Revised charter proposal: charter-ietf-ace-00-0= 2

=C2=A0

= Hi,

Hello all,

=C2=A0

Based on recent discussions, I made a revised cha= rter proposal, as included in this email, not on the webpage yet.

=C2=A0

Please take a look and let us know if you have an= y further comments.

=C2=A0

@Adrian and @Benoit, please check if the proposed= texts can resolve your comments.

=C2=A0

Thanks,

Kind Regards

Kepeng

=C2=A0

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

Compared with charter-ietf-ace-00-01 on the webpa= ge, the changes are:

=C2=A0

(1)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Add one clarifi= cation sentence about REST architecture:

OLD

The IETF has recently developed protocols for use= in constrained

environments, where network nodes are limited in = CPU, memory and power.

REST architecture is widely used for such constra= ined environments.

=C2=A0

NEW

The IETF has recently developed protocols for use= in constrained

environments, where network nodes are limited in = CPU, memory and power.

REST architecture is widely used for such constra= ined environments.

END

Considering that OLD is<= u>

OLD

The IETF has recently develo= ped protocols for use in constrained<= /u>

environments, where network = nodes are limited in CPU, memory and power. =

= ... fine with me

=C2=A0

=C2=A0

(2)=C2=A0=C2=A0=C2=A0=C2=A0 Remove =E2=80= =9CAAA protocol=E2=80=9D f= rom the charter:

OLD

The IETF has a long history in developing three-p= arty authentication and

authorization protocols for distributed environme= nts. Examples include

Kerberos, the Public Key Infrastructure (PKI), th= e Authentication,

Authorization and Accounting (AAA) infrastructure= , and the Web

Authorization Protocol (OAuth).

=C2=A0

NEW

The IETF has a long history in developing three-p= arty authentication and

authorization protocols for distributed environme= nts. Examples include

Kerberos, the Public Key Infrastructure (PKI), an= d the Web Authorization Protocol (OAuth).

END

We have AAA-doctors telling: ma= ybe RADIUS is applicable?
Personally, I don't know and it doesn't matter at this point.
We received feedback such as:

Let's be clear here: It was= never said (in the charter or anywhere else in the group to my knowledge) = that RADIUS (or indeed any other AAA protocol) would not run on constrained devices (RFC 7228). The charter simply said the protoco= ls were not optimised for constrained devices. That does not preclude consi= dering any protocol for suitability for constrained devices either a) as is= , b) in a restricted way or c) in an adapted way.

So, at this stage, I don't think any protocols should be excluded from = consideration and should certainly not be eliminated on a hunch that they m= ight be "too big". Let's do the assessment properly at the ap= propriate time. As a reminder - the focus now is to complete the charter.

Or

>>The Charter makes a number of assertions = that are provably false, such as that AAA protocols are inappropriate for c= onstrained environments.

In fact, the charter does not say that. But to av= oid confusion, let's remove AAA protocol from the charter.

=C2=A0

In the charter, we mentioned that we want to reus= e existing authentication and authorization protocols where applicable to b= uild the constrained-environment solution.

= ... which I read as: let's consider the AAA protocols, and evaluate if = they would work in constrained devices.
I don't understand the logic: why do you want to remove AAA from the ch= arter?
Not only would I keep "AAA", but I would propose

OLD:
Existing authentication and authorization protocols will be used where
applicable to build the constrained-environment solution

NEW:
Existing authentication and authorization protocols will be evaluated and r= e-used where
applicable to build the constrained-environment solution

Regards, Benoit

=C2=A0

=C2=A0

(3) Clarify the scope:

OLD:

Note that the initial focus is on CoAP and HTTP w= ith DTLS and TLS.

Other security protocols may be considered as lon= g as the primary focus is maintained.=C2=A0

Other application protocols and protocols at othe= r layers in the stack are out of scope.

=C2=A0

NEW

Note that the initial focus is on CoAP and HTTP w= ith DTLS and TLS.

Other security protocols may be considered as lon= g as the primary focus is maintained.=C2=A0

The group is scoped to work only on the web proto= cols and data carried within them.

END

=C2=A0

(4)=C2=A0=C2=A0=C2=A0=C2=A0 Update milestones for= the use case & requirements document:

OLD:

Jul 2015 Submit =E2=80=9CUse cases and Requirements=E2=80=9D documen= t to IESG for publication as informational RFC.

=C2=A0

NEW

Dec 2014 Optionally, submit "Use cases and R= equirements" document to the IESG for publication as an Informational = RFC.

END

=C2=A0

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

Charter charter-ietf-ace-00-02

Authentication and Authorization for Constrained<= u>

Environment (ACE)

=C2=A0

The IETF has recently developed protocols for use= in constrained

environments, where network nodes are limited in = CPU, memory and power.

REST architecture is widely used for such constra= ined environments.

It has been observed that Internet protocols can = be applied to these

constrained environments, often only requiring mi= nor tweaking and

profiling. In other cases, new protocols have bee= n defined to address

the specific requirements of constrained environm= ents. An example of

such a protocol is the Constrained Application Pr= otocol (CoAP).

=C2=A0

As in other environments, authentication and auth= orization questions

also arise in constrained environments. For examp= le, a door lock has to

authorize the person seeking access using a "= ;digital key". Where is the

authorization policy stored? How does the digital= key communicate with

the lock? Does the lock interact with an authoriz= ation server to obtain

authorization information? How can access be temp= orarily granted to

other persons? How can access be revoked? These t= ypes of questions have

been answered by existing protocols for use cases= outside constrained

environments, however in constrained environments= , additional and

different requirements pose challenges for the us= e of various security

protocols. In particular, the need arises for a d= ynamic and fine grained

access control mechanism, where clients and/or re= source servers are

constrained.

=C2=A0

The IETF has a long history in developing three-p= arty authentication and

authorization protocols for distributed environme= nts. Examples include

Kerberos, the Public Key Infrastructure (PKI), an= d the Web

Authorization Protocol (OAuth). All these protoco= ls enjoy widespread

deployment on the Internet. Although they all aim= to solve a similar

goal, at an abstract level, they offer quite diff= erent functions and

utilize different message exchanges. These differ= ences result from the

main deployment use cases they were designed for = respectively.

=C2=A0

Requirements derived from use cases indicate the = suitability of existing

work as a solution for constrained environments. = These protocols,

however, were not optimized for constrained envir= onments. Additional

requirements that need to be taken into account a= re the lack of a

suitable user-interface and the inability of embe= dded devices to contact

an authorization server in real-time with every r= esource access request

due to intermittent connectivity, etc.<= /u>

=C2=A0

This working group therefore aims to produce a st= andardized solution for

authentication and authorization to enable author= ized access (GET, PUT, POST,

DELETE) to resources identified by a URI and host= ed on a resource

server in constrained environments. As a starting= point, the working

group will assume that access to resources at a r= esource server by a

client device takes place using CoAP and is prote= cted by DTLS. Both

resource server and client may be constrained. Th= is access will be

mediated by an authorization server, which is not= considered to be

constrained.

=C2=A0

Existing authentication and authorization protoco= ls will be used where

applicable to build the constrained-environment s= olution. This requires

relevant specifications to be reviewed for suitab= ility, selecting a

subset of them and restricting the options within= each of the

specifications. Some functionality, however, may = not be available in

existing protocols, in which case the solution ma= y also involve new

protocol work. Leveraging existing work means the= working group benefits

from available security analysis, implementation,= and deployment

experience. Moreover, a standardized solution for= federated

authentication and authorization will help to sti= mulate the deployment

of constrained devices that provide increased sec= urity.

=C2=A0

Once progress in identifying suitable candidate s= olutions has been made,

the working group will verify whether the same me= chanisms are also

applicable beyond the use of CoAP and DTLS, which= are the two main

protocols the group will focus on for access to r= esources. In

particular, the ability to use the developed solu= tion over HTTP and TLS

will be investigated. Note that the initial focus= is on CoAP and HTTP with DTLS and TLS.

Other security protocols may be considered as lon= g as the primary focus is maintained.=C2=A0

The group is scoped to work only on the web proto= cols and data carried within them.

Furthermore, to guarantee smooth transition, the<= u>

integration with existing deployments will be stu= died, particularly

concerning the use of protocol translation proxie= s.

=C2=A0

This work does not make the assumption that the p= arty offering

application layer services is always the same par= ty offering network

access services.

=C2=A0

The working group has the following tasks:=

=C2=A0

1) Produce use cases and requirements

=C2=A0

2) Identify authentication and authorization mech= anisms suitable for

resource access in constrained environments.

=C2=A0

Milestones:

=C2=A0

Jul 2014 Submit "Use cases and Requirements&= quot; as a WG item.

Dec 2014 Submit "Authentication and Authoriz= ation Solution" as a WG item.

Dec 2014 Optionally, submit "Use cases and R= equirements" document

to the IESG for publication as an Informational R= FC.

Jul 2016 Submit "Authentication and Authoriz= ation Solution"

specification to the IESG for publication as a Pr= oposed Standard.

=C2=A0

Proposed Milestones

No milestones for charter found.

=C2=A0

=C2=A0

--

=C2=A0

Best regards,

Kathleen

--

Best regards,
Kathleen

--089e0158b6d24d195504faef7b7c-- From nobody Tue Jun 3 08:00:47 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABFF61A02F6 for ; Tue, 3 Jun 2014 08:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hlJb_2j6ezM0 for ; Tue, 3 Jun 2014 08:00:43 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EC851A02F2 for ; Tue, 3 Jun 2014 08:00:43 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 5764E20029; Tue, 3 Jun 2014 11:03:44 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 8F28F63B0E; Tue, 3 Jun 2014 11:00:36 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 7848C63AED; Tue, 3 Jun 2014 11:00:36 -0400 (EDT) From: Michael Richardson To: Stefanie Gerdes In-Reply-To: <538DA583.4070200@tzi.de> References: <538DA583.4070200@tzi.de> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/ace/RKoEhaSiQ0tDQy3CE0xUpGIV2WA Cc: "ace@ietf.org" Subject: Re: [Ace] Security Domains X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments $ace$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 15:00:45 -0000 --=-=-= Stefanie Gerdes wrote: > In my draft about actors in the ACE architecture [1] I explained that > the client (the one that wants to access a resource) and the resource > server (the one that hosts the resource) might belong to different > security domains. There is some discussion going on if this really is > the case. > I did not really get yet what the disagreement is about, so maybe > someone can help me with that. > I might be wrong, but I guess the fact that devices of different owners > might need to interact with each other is not really the question, is > it? The scenarios described in the use cases draft [2] indicate that I think that some people think that all cross-realm communication will occur between brokers/proxies/"cloud services", vs occuring end to end. I think your documents are pretty clear that e2e can be made to work. Many people want to intermediate the relationship in order to charge a rent. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBU43jEYCLcPvd0N1lAQKKnQf+O49L3bY2AWGtYndjdmSvDDSDvrL8BN03 ZEdu4li2A7xjMKNnhosnAiPdFKQMF4+AkYv1ZrN0MKfW8HNuFBwonFE22ZAmqkRm HJNC2201eUr+BR9szWkXaeo49N3cpEb+l8IC/AI16yLuwB8NQERMuIQ8lmwHpDvV 8BG8PjCYvQBWK1xi2CzmIuY07YaARMMUrQePCA27pgPIw8WmDIWU8M9vHBIjJx7g aIim6vgb/5tv1Mq1VXGX31eg61bKRN+B5ocYq1krHktAPcBdFVIMzJq7pWM14/g8 /GPes8hIGYvzflJC8opczbM9H4k0CaKHxq83cdovgTR5zias6OAJPQ== =FtuB -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jun 3 09:46:47 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4AB61A02C4 for ; Tue, 3 Jun 2014 09:46:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 8_PhIsEfUqY9 for ; Tue, 3 Jun 2014 09:46:41 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41FA41A020E for ; Tue, 3 Jun 2014 09:46:41 -0700 (PDT) X-AuditID: c1b4fb25-f79226d000004024-96-538dfbe96556 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 81.F5.16420.9EBFD835; Tue, 3 Jun 2014 18:46:34 +0200 (CEST) Received: from ESESSMB303.ericsson.se ([169.254.3.215]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0174.001; Tue, 3 Jun 2014 18:46:33 +0200 From: =?iso-8859-1?Q?G=F6ran_Selander?= To: "Dr. Corinna Schmitt" , =?iso-8859-1?Q?Erik_Wahlstr=F6m?= , "Carsten Bormann" , Sandeep Kumar , Ludwig Seitz , Mohit Sethi M , "Hannes Tschofenig" Thread-Topic: ACE pre-WG meeting Thread-Index: AQHPf0tfHbf8anPloUGdPyoau4D4bg== Date: Tue, 3 Jun 2014 16:46:32 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_CFB3B7C313218goranselanderericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGIsWRmVeSWpSXmKPExsUyM+Jvje6r373BBjvmsFt8/9bDbHFkyl1W i2O7FrNZ3Jxxisli9rZuNotXrXeYLfY3XWB0YPdYM28No8eSJT+ZPO7t6GPx2Hr/N6PHrjON TB69x36zeUxblBnAHsVlk5Kak1mWWqRvl8CVcfnhc+aC3/wVv3eVNTBu5+1i5OSQEDCR6F18 nxnCFpO4cG89WxcjF4eQwFFGiT0ta6GcxYwSC5vfsoFUsQm4Shx48I4JJCEisINJ4u6hy2AJ ZgFFiXVz+oASHBzCAvIS3dsDQMIiAgoSF/eeZIKw9SR+rv/EAmKzCKhIXNvdzw5i8wpYSCzr WwQWZwS64vupNUwQI8Ulbj2ZzwRxnYDEkj3noS4VlXj5+B8riC0KNPPdcZgaJYnGJU9YIXpj JbZ3zGOGmC8ocXLmE5YJjCKzkIydhaRsFpIyiLiexI2pU9ggbG2JZQtfM0PYuhIz/h2CqrGW 2L7qDTOymgWMHKsYRYtTi5Ny042M9VKLMpOLi/Pz9PJSSzYxAiP64JbfqjsYL79xPMQowMGo xMP74HNPsBBrYllxZe4hRmkOFiVx3osa1cFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGAvu br3bz9vuFX6ZIbL5w8Y9j1wuzrqru1DY7r+xZYZE4iy+FUq5tr8699fUe7Rcu7Yv6uvPiDcG 62Wkzjw92jl91ryWvbsafJ50shX05ygfUee2D6if6ukwYUmm+/mVpxaIlJtn/9sgfejf89gc h9jNM6tvrDp5hVWlaW4TR+QE346jM3f5HlViKc5INNRiLipOBACQjuGByQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/ace/bm4Nar8fhfSsNOof619eblNjuPg Cc: "ace@ietf.org" Subject: Re: [Ace] ACE pre-WG meeting X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments $ace$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 16:46:44 -0000 --_000_CFB3B7C313218goranselanderericssoncom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear meeting participants, I want to thank you all for coming the informal ACE meeting in Stockholm a= nd contributing to the discussions. Thanks also to all who provided input b= efore or during the meeting. All inputs were discussed in one form or other= and some more than others, but they all made an impact on the problem desc= ription. For those of you that did not come, the results from the meeting will be ch= anneled through various drafts, in particular updates to the two internet d= rafts on use case and requirements, and problem statement. Thanks G=F6ran --_000_CFB3B7C313218goranselanderericssoncom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
Dear meeting participants,

I want to thank you all for coming the informal ACE meeting in S= tockholm and contributing to the discussions. Thanks also to all who provid= ed input before or during the meeting. All inputs were discussed in one for= m or other and some more than others, but they all made an impact on the problem description.

For those of you that did not come, the results from the meeting will = be channeled through various drafts, in particular updates to the two inter= net drafts on use case and requirements, and problem statement.

Thanks

G=F6ran

--_000_CFB3B7C313218goranselanderericssoncom_-- From nobody Tue Jun 3 13:27:47 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 471271A036D; Tue, 3 Jun 2014 13:27:41 -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 Dqkr7NPB9Ykj; Tue, 3 Jun 2014 13:27:36 -0700 (PDT) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010: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 EA17A1A0344; Tue, 3 Jun 2014 13:27:34 -0700 (PDT) Received: by mail-la0-f48.google.com with SMTP id mc6so3826996lab.35 for ; Tue, 03 Jun 2014 13:27:27 -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=oMf9sapUGre0oeS1YAgc+Z2H9PIXINlJWZc1ffkdp8c=; b=nMBPxYv9WbDKsytRl78S7PSOA7yRAeyww1FdrjQa0Uka24cHBQ4mDYshDZWzU6mMNJ MReXDCNP9lAILz/XwiPokUpgNnDKdwuYjBKQW4QaIt+O0VkqYA2AT04RvL7EN9XGLNO/ +HlnhNA+wqJx1XxjRRatHn7X+zaU9dfUNaZrE0niZbx1qFpuLI86R55TbKhkGcMkgnQg bxS+6GClySPSMY81MW1H4kYIPq4z5Qc4G9h1bMaJgfPZefgG77UNPKGtcX3o8EwRcrxO /iTOfpxc/8MB7La7Or/HYk4WfmEYtmlDDLNcYJtiXW8Jv/ujtGZsn3NUz1XGRQvDQJXF TkkA== MIME-Version: 1.0 X-Received: by 10.112.188.165 with SMTP id gb5mr4094673lbc.69.1401827247701; Tue, 03 Jun 2014 13:27:27 -0700 (PDT) Received: by 10.112.33.36 with HTTP; Tue, 3 Jun 2014 13:27:27 -0700 (PDT) In-Reply-To: References: <20140514221215.8150.56543.idtracker@ietfa.amsl.com> <34966E97BE8AD64EAE9D3D6E4DEE36F252B2A345@SZXEMA501-MBS.china.huawei.com> <34966E97BE8AD64EAE9D3D6E4DEE36F252B38978@SZXEMA501-MBS.china.huawei.com> <34966E97BE8AD64EAE9D3D6E4DEE36F258140E59@SZXEMA501-MBX.china.huawei.com> <538DA047.7080902@cisco.com> <34966E97BE8AD64EAE9D3D6E4DEE36F258153F43@SZXEMA501-MBS.china.huawei.com> <34966E97BE8AD64EAE9D3D6E4DEE36F25815405D@SZXEMA501-MBS.china.huawei.com> Date: Tue, 3 Jun 2014 16:27:27 -0400 Message-ID: From: Kathleen Moriarty To: Likepeng Content-Type: multipart/alternative; boundary=001a11c36da222c4fd04faf45794 Archived-At: http://mailarchive.ietf.org/arch/msg/ace/gw8fqsFp9fEE55J_SZZ4jE7ib60 Cc: Benoit Claise , "adrian@olddog.co.uk" , "ace@ietf.org" , The IESG , "aaa-doctors@ietf.org" Subject: Re: [Ace] Revised charter proposal: charter-ietf-ace-00-02 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments $ace$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 20:27:41 -0000 --001a11c36da222c4fd04faf45794 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The charter text has been updated, https://datatracker.ietf.org/doc/charter-ietf-ace/ Thank you all for your input and assistance. If this is good, we'll move it forward for IETF review. On Tue, Jun 3, 2014 at 10:39 AM, Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: > I believe there is agreement on the proposed changes. I'll make the > updates later in the day (it's about 11:30 my time, maybe at 4) in case > anyone wants to chime in. If we are all in agreement, I'll have it sent > for IETF review at that point. > > Thank you! > > > On Tue, Jun 3, 2014 at 10:26 AM, Likepeng wrote: > >> Hi Kathleen and all, >> >> >> >> This is what I have now: >> >> >> >> Change #1: (Proposed by Kepeng, confirmed by Benoit) >> >> OLD >> >> The IETF has recently developed protocols for use in constrained >> >> environments, where network nodes are limited in CPU, memory and power. >> >> >> >> NEW >> >> The IETF has recently developed protocols for use in constrained >> >> environments, where network nodes are limited in CPU, memory and power. >> >> REST architecture is widely used for such constrained environments. >> >> END >> >> >> >> Change #2: (Proposal from Rene, supported by Stefanie) >> >> OLD: >> >> Requirements derived from use cases indicate the suitability of existing >> >> work as a solution for constrained environments >> >> >> >> NEW: >> >> Requirements derived from use cases may indicate that existing work is >> >> useful as basis for as a solution for constrained environments >> >> >> >> Change #3: (Proposal from Jari, supported by Barry, Robert and Behcet) >> >> OLD: >> >> Note that the initial focus is on CoAP and HTTP with DTLS and TLS. >> >> Other security protocols may be considered as long as the primary focus = is maintained. >> >> Other application protocols and protocols at other layers in the stack a= re out of scope. >> >> >> >> NEW >> >> Note that the initial focus is on CoAP and HTTP with DTLS and TLS. >> >> Other security protocols may be considered as long as the primary focus = is maintained. >> >> The group is scoped to work only on the web protocols and data carried w= ithin them. >> >> END >> >> >> >> Change 4: (Proposal from Jari, revised by Rene, supported by Stefanie) >> >> OLD: >> >> Jul 2014 Submit "Use cases and Requirements" as a WG item. >> >> Jul 2015 Submit =E2=80=9CUse cases and Requirements=E2=80=9D document to= IESG for publication as informational RFC. >> >> >> >> NEW >> >> Dec 2014 Submit "Use cases and Requirements" as a WG item. >> >> Apr 2015 Optionally, submit "Use cases and Requirements" document to the= IESG for >> >> publication as an Informational RFC. >> >> END >> >> >> >> I think we covered all of the IESG review comments. >> >> >> >> If there is any open issue, please let us know. >> >> >> >> Thanks, >> >> >> >> Kind Regards >> >> Kepeng >> >> >> ------------------------------------------------------------------------= ---------------------------------------------------------------------------= ----- >> >> >> >> Charter charter-ietf-ace-00-02 >> >> Authentication and Authorization for Constrained >> >> Environment (ACE) >> >> >> >> The IETF has recently developed protocols for use in constrained >> >> environments, where network nodes are limited in CPU, memory and power. >> >> REST architecture is widely used for such constrained environments. >> >> It has been observed that Internet protocols can be applied to these >> >> constrained environments, often only requiring minor tweaking and >> >> profiling. In other cases, new protocols have been defined to address >> >> the specific requirements of constrained environments. An example of >> >> such a protocol is the Constrained Application Protocol (CoAP). >> >> >> >> As in other environments, authentication and authorization questions >> >> also arise in constrained environments. For example, a door lock has to >> >> authorize the person seeking access using a "digital key". Where is the >> >> authorization policy stored? How does the digital key communicate with >> >> the lock? Does the lock interact with an authorization server to obtain >> >> authorization information? How can access be temporarily granted to >> >> other persons? How can access be revoked? These types of questions have >> >> been answered by existing protocols for use cases outside constrained >> >> environments, however in constrained environments, additional and >> >> different requirements pose challenges for the use of various security >> >> protocols. In particular, the need arises for a dynamic and fine grained >> >> access control mechanism, where clients and/or resource servers are >> >> constrained. >> >> >> >> The IETF has a long history in developing three-party authentication and >> >> authorization protocols for distributed environments. Examples include >> >> Kerberos, the Public Key Infrastructure (PKI), the Authentication, >> >> Authorization and Accounting (AAA) infrastructure,and the Web >> >> Authorization Protocol (OAuth). All these protocols enjoy widespread >> >> deployment on the Internet. Although they all aim to solve a similar >> >> goal, at an abstract level, they offer quite different functions and >> >> utilize different message exchanges. These differences result from the >> >> main deployment use cases they were designed for respectively. >> >> >> >> Requirements derived from use cases may indicate that existing work is >> >> useful as basis for as a solution for constrained environments. >> >> These protocols, >> >> however, were not optimized for constrained environments. Additional >> >> requirements that need to be taken into account are the lack of a >> >> suitable user-interface and the inability of embedded devices to contact >> >> an authorization server in real-time with every resource access request >> >> due to intermittent connectivity, etc. >> >> >> >> This working group therefore aims to produce a standardized solution for >> >> authentication and authorization to enable authorized access (GET, PUT, >> POST, >> >> DELETE) to resources identified by a URI and hosted on a resource >> >> server in constrained environments. As a starting point, the working >> >> group will assume that access to resources at a resource server by a >> >> client device takes place using CoAP and is protected by DTLS. Both >> >> resource server and client may be constrained. This access will be >> >> mediated by an authorization server, which is not considered to be >> >> constrained. >> >> >> >> Existing authentication and authorization protocols will be evaluated >> >> and re-used where applicable to build the constrained-environment >> solution. >> >> This requires >> >> relevant specifications to be reviewed for suitability, selecting a >> >> subset of them and restricting the options within each of the >> >> specifications. Some functionality, however, may not be available in >> >> existing protocols, in which case the solution may also involve new >> >> protocol work. Leveraging existing work means the working group benefits >> >> from available security analysis, implementation, and deployment >> >> experience. Moreover, a standardized solution for federated >> >> authentication and authorization will help to stimulate the deployment >> >> of constrained devices that provide increased security. >> >> >> >> Once progress in identifying suitable candidate solutions has been made, >> >> the working group will verify whether the same mechanisms are also >> >> applicable beyond the use of CoAP and DTLS, which are the two main >> >> protocols the group will focus on for access to resources. In >> >> particular, the ability to use the developed solution over HTTP and TLS >> >> will be investigated. Note that the initial focus is on CoAP and HTTP >> with DTLS and TLS. >> >> Other security protocols may be considered as long as the primary focus >> is maintained. >> >> The group is scoped to work only on the web protocols and data carried >> within them. >> >> Furthermore, to guarantee smooth transition, the >> >> integration with existing deployments will be studied, particularly >> >> concerning the use of protocol translation proxies. >> >> >> >> This work does not make the assumption that the party offering >> >> application layer services is always the same party offering network >> >> access services. >> >> >> >> The working group has the following tasks: >> >> >> >> 1) Produce use cases and requirements >> >> >> >> 2) Identify authentication and authorization mechanisms suitable for >> >> resource access in constrained environments. >> >> >> >> Milestones: >> >> >> >> Dec 2014 Submit "Use cases and Requirements" as a WG item. >> >> Dec 2014 Submit "Authentication and Authorization Solution" as a WG item= . >> >> Apr 2015 Optionally, submit "Use cases and Requirements" document >> >> to the IESG for publication as an Informational RFC. >> >> Jul 2016 Submit "Authentication and Authorization Solution" >> >> specification to the IESG for publication as a Proposed Standard. >> >> >> >> Proposed Milestones >> >> No milestones for charter found. >> >> >> >> >> >> >> >> *=E5=8F=91=E4=BB=B6=E4=BA=BA:* Kathleen Moriarty [mailto:kathleen.moriar= ty.ietf@gmail.com] >> *=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4:* 2014=E5=B9=B46=E6=9C=883=E6=97= =A5 14:30 >> *=E6=94=B6=E4=BB=B6=E4=BA=BA:* Likepeng >> *=E6=8A=84=E9=80=81:* Benoit Claise; adrian@olddog.co.uk; aaa-doctors@ie= tf.org; The >> IESG; ace@ietf.org >> *=E4=B8=BB=E9=A2=98:* Re: Revised charter proposal: charter-ietf-ace-00-= 02 >> >> >> >> Hi Kepeng, >> >> >> >> If we are at a point where I can update the charter, seems that way, >> please send the latest version that has been agreed upon and I'll take c= are >> of the update. >> >> >> >> Thanks. >> >> >> >> On Tue, Jun 3, 2014 at 6:31 AM, Likepeng wrote: >> >> Hi Benoit, >> >> >> >> >Not only would I keep "AAA", >> >> >> >> OK. >> >> >> >> >but I would propose >> >> >> >> >OLD: >> >> >Existing authentication and authorization protocols will be used where >> >> applicable to build the constrained-environment solution. >> >> >> >> >NEW: >> >> Existing authentication and authorization protocols will be evaluated an= d >> re-used where >> >> applicable to build the constrained-environment solution. >> >> >> >> OK, fine with me. >> >> >> >> Thanks for the feedback. >> >> >> >> Kind Regards >> >> Kepeng >> >> >> >> *=E5=8F=91=E4=BB=B6=E4=BA=BA:* Benoit Claise [mailto:bclaise@cisco.com] >> *=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4:* 2014=E5=B9=B46=E6=9C=883=E6=97= =A5 12:16 >> >> *=E6=94=B6=E4=BB=B6=E4=BA=BA:* Likepeng; Kathleen Moriarty; adrian@olddo= g.co.uk >> >> *=E6=8A=84=E9=80=81:* aaa-doctors@ietf.org; The IESG; ace@ietf.org >> >> *=E4=B8=BB=E9=A2=98:* Re: Revised charter proposal: charter-ietf-ace-00-= 02 >> >> >> >> Hi, >> >> Hello all, >> >> >> >> Based on recent discussions, I made a revised charter proposal, as inclu= ded in this email, not on the webpage yet. >> >> >> >> Please take a look and let us know if you have any further comments. >> >> >> >> @Adrian and @Benoit, please check if the proposed texts can resolve your= comments. >> >> >> >> Thanks, >> >> Kind Regards >> >> Kepeng >> >> >> >> ------------------------------------------------------------------------= ---------------------------------------------------------------------------= ---------- >> >> Compared with charter-ietf-ace-00-01 on the webpage, the changes are: >> >> >> >> (1) Add one clarification sentence about REST architecture: >> >> OLD >> >> The IETF has recently developed protocols for use in constrained >> >> environments, where network nodes are limited in CPU, memory and power. >> >> REST architecture is widely used for such constrained environments. >> >> >> >> NEW >> >> The IETF has recently developed protocols for use in constrained >> >> environments, where network nodes are limited in CPU, memory and power. >> >> REST architecture is widely used for such constrained environments. >> >> END >> >> Considering that OLD is >> >> OLD >> >> The IETF has recently developed protocols for use in constrained >> >> environments, where network nodes are limited in CPU, memory and power. >> >> ... fine with me >> >> >> >> >> >> (2) Remove =E2=80=9CAAA protocol=E2=80=9D from the charter: >> >> OLD >> >> The IETF has a long history in developing three-party authentication and >> >> authorization protocols for distributed environments. Examples include >> >> Kerberos, the Public Key Infrastructure (PKI), the Authentication, >> >> Authorization and Accounting (AAA) infrastructure, and the Web >> >> Authorization Protocol (OAuth). >> >> >> >> NEW >> >> The IETF has a long history in developing three-party authentication and >> >> authorization protocols for distributed environments. Examples include >> >> Kerberos, the Public Key Infrastructure (PKI), and the Web Authorization= Protocol (OAuth). >> >> END >> >> We have AAA-doctors telling: maybe RADIUS is applicable? >> Personally, I don't know and it doesn't matter at this point. >> We received feedback such as: >> >> Let's be clear here: It was never said (in the charter or anywhere else >> in the group to my knowledge) that RADIUS (or indeed any other AAA >> protocol) would not run on constrained devices (RFC 7228). The charter >> simply said the protocols were not optimised for constrained devices. Th= at >> does not preclude considering any protocol for suitability for constrain= ed >> devices either a) as is, b) in a restricted way or c) in an adapted way. >> >> So, at this stage, I don't think any protocols should be excluded from >> consideration and should certainly not be eliminated on a hunch that the= y >> might be "too big". Let's do the assessment properly at the appropriate >> time. As a reminder - the focus now is to complete the charter. >> >> Or >> >> >>The Charter makes a number of assertions that are provably false, such= as that AAA protocols are inappropriate for constrained environments. >> >> In fact, the charter does not say that. But to avoid confusion, let's re= move AAA protocol from the charter. >> >> >> >> In the charter, we mentioned that we want to reuse existing authenticati= on and authorization protocols where applicable to build the constrained-en= vironment solution. >> >> ... which I read as: let's consider the AAA protocols, and evaluate if >> they would work in constrained devices. >> I don't understand the logic: why do you want to remove AAA from the >> charter? >> Not only would I keep "AAA", but I would propose >> >> OLD: >> Existing authentication and authorization protocols will be used where >> applicable to build the constrained-environment solution >> >> NEW: >> Existing authentication and authorization protocols will be evaluated an= d >> re-used where >> applicable to build the constrained-environment solution >> >> Regards, Benoit >> >> >> >> >> >> (3) Clarify the scope: >> >> OLD: >> >> Note that the initial focus is on CoAP and HTTP with DTLS and TLS. >> >> Other security protocols may be considered as long as the primary focus = is maintained. >> >> Other application protocols and protocols at other layers in the stack a= re out of scope. >> >> >> >> NEW >> >> Note that the initial focus is on CoAP and HTTP with DTLS and TLS. >> >> Other security protocols may be considered as long as the primary focus = is maintained. >> >> The group is scoped to work only on the web protocols and data carried w= ithin them. >> >> END >> >> >> >> (4) Update milestones for the use case & requirements document: >> >> OLD: >> >> Jul 2015 Submit =E2=80=9CUse cases and Requirements=E2=80=9D document to= IESG for publication as informational RFC. >> >> >> >> NEW >> >> Dec 2014 Optionally, submit "Use cases and Requirements" document to the= IESG for publication as an Informational RFC. >> >> END >> >> >> >> ------------------------------------------------------------------------= ---------------------------------------------------------------------------= ------------------------- >> >> Charter charter-ietf-ace-00-02 >> >> Authentication and Authorization for Constrained >> >> Environment (ACE) >> >> >> >> The IETF has recently developed protocols for use in constrained >> >> environments, where network nodes are limited in CPU, memory and power. >> >> REST architecture is widely used for such constrained environments. >> >> It has been observed that Internet protocols can be applied to these >> >> constrained environments, often only requiring minor tweaking and >> >> profiling. In other cases, new protocols have been defined to address >> >> the specific requirements of constrained environments. An example of >> >> such a protocol is the Constrained Application Protocol (CoAP). >> >> >> >> As in other environments, authentication and authorization questions >> >> also arise in constrained environments. For example, a door lock has to >> >> authorize the person seeking access using a "digital key". Where is the >> >> authorization policy stored? How does the digital key communicate with >> >> the lock? Does the lock interact with an authorization server to obtain >> >> authorization information? How can access be temporarily granted to >> >> other persons? How can access be revoked? These types of questions have >> >> been answered by existing protocols for use cases outside constrained >> >> environments, however in constrained environments, additional and >> >> different requirements pose challenges for the use of various security >> >> protocols. In particular, the need arises for a dynamic and fine grained >> >> access control mechanism, where clients and/or resource servers are >> >> constrained. >> >> >> >> The IETF has a long history in developing three-party authentication and >> >> authorization protocols for distributed environments. Examples include >> >> Kerberos, the Public Key Infrastructure (PKI), and the Web >> >> Authorization Protocol (OAuth). All these protocols enjoy widespread >> >> deployment on the Internet. Although they all aim to solve a similar >> >> goal, at an abstract level, they offer quite different functions and >> >> utilize different message exchanges. These differences result from the >> >> main deployment use cases they were designed for respectively. >> >> >> >> Requirements derived from use cases indicate the suitability of existing >> >> work as a solution for constrained environments. These protocols, >> >> however, were not optimized for constrained environments. Additional >> >> requirements that need to be taken into account are the lack of a >> >> suitable user-interface and the inability of embedded devices to contact >> >> an authorization server in real-time with every resource access request >> >> due to intermittent connectivity, etc. >> >> >> >> This working group therefore aims to produce a standardized solution for >> >> authentication and authorization to enable authorized access (GET, PUT, = POST, >> >> DELETE) to resources identified by a URI and hosted on a resource >> >> server in constrained environments. As a starting point, the working >> >> group will assume that access to resources at a resource server by a >> >> client device takes place using CoAP and is protected by DTLS. Both >> >> resource server and client may be constrained. This access will be >> >> mediated by an authorization server, which is not considered to be >> >> constrained. >> >> >> >> Existing authentication and authorization protocols will be used where >> >> applicable to build the constrained-environment solution. This requires >> >> relevant specifications to be reviewed for suitability, selecting a >> >> subset of them and restricting the options within each of the >> >> specifications. Some functionality, however, may not be available in >> >> existing protocols, in which case the solution may also involve new >> >> protocol work. Leveraging existing work means the working group benefits >> >> from available security analysis, implementation, and deployment >> >> experience. Moreover, a standardized solution for federated >> >> authentication and authorization will help to stimulate the deployment >> >> of constrained devices that provide increased security. >> >> >> >> Once progress in identifying suitable candidate solutions has been made, >> >> the working group will verify whether the same mechanisms are also >> >> applicable beyond the use of CoAP and DTLS, which are the two main >> >> protocols the group will focus on for access to resources. In >> >> particular, the ability to use the developed solution over HTTP and TLS >> >> will be investigated. Note that the initial focus is on CoAP and HTTP wi= th DTLS and TLS. >> >> Other security protocols may be considered as long as the primary focus = is maintained. >> >> The group is scoped to work only on the web protocols and data carried w= ithin them. >> >> Furthermore, to guarantee smooth transition, the >> >> integration with existing deployments will be studied, particularly >> >> concerning the use of protocol translation proxies. >> >> >> >> This work does not make the assumption that the party offering >> >> application layer services is always the same party offering network >> >> access services. >> >> >> >> The working group has the following tasks: >> >> >> >> 1) Produce use cases and requirements >> >> >> >> 2) Identify authentication and authorization mechanisms suitable for >> >> resource access in constrained environments. >> >> >> >> Milestones: >> >> >> >> Jul 2014 Submit "Use cases and Requirements" as a WG item. >> >> Dec 2014 Submit "Authentication and Authorization Solution" as a WG item= . >> >> Dec 2014 Optionally, submit "Use cases and Requirements" document >> >> to the IESG for publication as an Informational RFC. >> >> Jul 2016 Submit "Authentication and Authorization Solution" >> >> specification to the IESG for publication as a Proposed Standard. >> >> >> >> Proposed Milestones >> >> No milestones for charter found. >> >> >> >> >> >> >> >> -- >> >> >> >> Best regards, >> >> Kathleen >> > > > > -- > > Best regards, > Kathleen > --=20 Best regards, Kathleen --001a11c36da222c4fd04faf45794 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The charter text has been updated,=C2=A0https://datatracker.ietf.org/d= oc/charter-ietf-ace/

Thank you all for your input an= d assistance. =C2=A0If this is good, we'll move it forward for IETF rev= iew.

On Tue,= Jun 3, 2014 at 10:39 AM, Kathleen Moriarty <kathleen.mor= iarty.ietf@gmail.com> wrote:

I believe there is agreemen= t on the proposed changes. =C2=A0I'll make the updates later in the day= (it's about 11:30 my time, maybe at 4) in case anyone wants to chime i= n. =C2=A0If we are all in agreement, I'll have it sent for IETF review = at that point.

Thank you!

On Tue, Jun 3, 2014 at 10:26= AM, Likepeng <likepeng@huawei.com> wrote:

Hi Kathlee= n and all,

=C2= =A0

This is wh= at I have now:

=C2= =A0

Change #1:= (Proposed by Kepeng, confirmed by Benoit)

OLD
The IETF has recently develo= ped protocols for use in constrained

environments, where network = nodes are limited in CPU, memory and power.

=C2=A0<= /pre>
NEW

The IETF has recently develo= ped protocols for use in constrained

environments, where network = nodes are limited in CPU, memory and power.

REST architecture is widely = used for such constrained environments.

END
=C2=A0<= /pre>
Change #2: (Proposal f= rom Rene, supported by Stefanie)

OLD:

Requirements derived from us= e cases indicate the suitability of existing

work as a solution for const= rained environments

=C2=A0<= /pre>
NEW:

Requirements derived from us= e cases may indicate that existing work is

useful as basis for a= s a solution for constrained environments

=C2=A0<= /pre>
Change #3: (Proposal from Ja= ri, supported by Barry, Robert and Behcet)

OLD:
Note that the initial focus = is on CoAP and HTTP with DTLS and TLS.

Other security protocols may= be considered as long as the primary focus is maintained.=C2=A0 =

Other application protocols = and protocols at other layers in the stack are out of scope.<= /span>

=C2=A0<= /pre>
NEW
Note that the initial focus = is on CoAP and HTTP with DTLS and TLS.

Other security protocols may= be considered as long as the primary focus is maintained.=C2=A0 =

The group is scoped to work = only on the web protocols and data carried within them.

END
=C2=A0<= /pre>
Change 4: (Proposal fr= om Jari, revised by Rene, supported by Stefanie)

OLD:

Jul 2014 Submit "Use ca= ses and Requirements" as a WG item.

Jul 2015 Submit =E2=80= =9CUse cases and Requirements=E2=80=9D document to IESG for publication as = informational RFC.

=C2=A0<= /pre>
NEW
Dec 2014 Submit "Use ca= ses and Requirements" as a WG item.

Apr 2015 Optionally, submit = "Use cases and Requirements" document to the IESG for

publication as an Informatio= nal RFC.

END
=C2= =A0

I th= ink we covered all of the IESG review comments.

=C2= =A0

If there i= s any open issue, please let us know.

=C2= =A0

Thanks,=

=C2= =A0

Kind Regar= ds

Kepeng<= /u>

----------= ---------------------------------------------------------------------------= -------------------------------------------------------------------<= u>

=C2= =A0

Charter ch= arter-ietf-ace-00-02

Authentica= tion and Authorization for Constrained

Environmen= t (ACE)

=C2= =A0

The IETF h= as recently developed protocols for use in constrained=

environmen= ts, where network nodes are limited in CPU, memory and power.

REST archi= tecture is widely used for such constrained environments.

It has bee= n observed that Internet protocols can be applied to these

constraine= d environments, often only requiring minor tweaking and

profiling.= In other cases, new protocols have been defined to address

the specif= ic requirements of constrained environments. An example of

such a pro= tocol is the Constrained Application Protocol (CoAP).<= /p>
=C2= =A0

As in othe= r environments, authentication and authorization questions

also arise= in constrained environments. For example, a door lock has to=

authorize = the person seeking access using a "digital key". Where is the<= /u>

authorizat= ion policy stored? How does the digital key communicate with<= /span>

the lock? = Does the lock interact with an authorization server to obtain=

authorizat= ion information? How can access be temporarily granted to

other pers= ons? How can access be revoked? These types of questions have=

been answe= red by existing protocols for use cases outside constrained

environmen= ts, however in constrained environments, additional and

different = requirements pose challenges for the use of various security<= /span>

protocols.= In particular, the need arises for a dynamic and fine grained

access con= trol mechanism, where clients and/or resource servers are

constraine= d.

=C2= =A0

The IETF h= as a long history in developing three-party authentication and

authorizat= ion protocols for distributed environments. Examples include<= /span>

Authorizat= ion and Accounting (AAA) infrastructure,and the Web

Authorizat= ion Protocol (OAuth). All these protocols enjoy widespread

deployment= on the Internet. Although they all aim to solve a similar

goal, at a= n abstract level, they offer quite different functions and

utilize di= fferent message exchanges. These differences result from the<= /span>

main deplo= yment use cases they were designed for respectively.
=C2= =A0

Requ= irements derived from use cases may indicate that existing work is

useful as = basis for as a solution for constrained environments.<= /p>

These prot= ocols,

however, w= ere not optimized for constrained environments. Additional

requiremen= ts that need to be taken into account are the lack of a

suitable u= ser-interface and the inability of embedded devices to contact

an authori= zation server in real-time with every resource access request=

due to int= ermittent connectivity, etc.

=C2= =A0

This worki= ng group therefore aims to produce a standardized solution for

authentica= tion and authorization to enable authorized access (GET, PUT, POST,

DELETE) to= resources identified by a URI and hosted on a resource

server in = constrained environments. As a starting point, the working

group will= assume that access to resources at a resource server by a

client dev= ice takes place using CoAP and is protected by DTLS. Both

resource s= erver and client may be constrained. This access will be

mediated b= y an authorization server, which is not considered to be

constraine= d.

=C2= =A0

Exis= ting authentication and authorization protocols will be evaluated

and re-use= d where applicable to build the constrained-environment solution.=

This= requires

relevant s= pecifications to be reviewed for suitability, selecting a

subset of = them and restricting the options within each of the
specificat= ions. Some functionality, however, may not be available in

existing p= rotocols, in which case the solution may also involve new

protocol w= ork. Leveraging existing work means the working group benefits

from avail= able security analysis, implementation, and deployment=

experience= . Moreover, a standardized solution for federated

authentica= tion and authorization will help to stimulate the deployment<= /span>

of constra= ined devices that provide increased security.

=C2= =A0

Once progr= ess in identifying suitable candidate solutions has been made,

the workin= g group will verify whether the same mechanisms are also

applicable= beyond the use of CoAP and DTLS, which are the two main

protocols = the group will focus on for access to resources. In
particular= , the ability to use the developed solution over HTTP and TLS=

will be in= vestigated. Note that the initial focus is on CoAP and HTTP with DTLS and T= LS.

Other secu= rity protocols may be considered as long as the primary focus is maintained= .=C2=A0

The group = is scoped to work only on the web protocols and data carried within them.

Furthermor= e, to guarantee smooth transition, the

integratio= n with existing deployments will be studied, particularly

concerning= the use of protocol translation proxies.

=C2= =A0

This work = does not make the assumption that the party offering
applicatio= n layer services is always the same party offering network

access ser= vices.

=C2= =A0

The workin= g group has the following tasks:

=C2= =A0

1) Produce= use cases and requirements

=C2= =A0

2) Identif= y authentication and authorization mechanisms suitable for

resource a= ccess in constrained environments.

=C2= =A0

Milestones= :

=C2= =A0

Dec 2014 S= ubmit "Authentication and Authorization Solution" as a WG item.

Apr = 2015 Optionally, submit "Use cases and Requirements" document

to the IES= G for publication as an Informational RFC.

Jul 2016 S= ubmit "Authentication and Authorization Solution"

specificat= ion to the IESG for publication as a Proposed Standard.

=C2= =A0

Proposed M= ilestones

No milesto= nes for charter found.

=C2= =A0

=C2= =A0

=C2= =A0

=E5=8F=91=E4=BB= =B6=E4=BA=BA: Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail= .com]
=E5=8F=91=E9=80=81=E6=97=B6=E9= =97=B4: 2014=E5=B9=B46=E6=9C=883=E6=97=A5<= span lang=3D"EN-US"> 14:30
=E6=94=B6=E4=BB=B6=E4=BA=BA: Likepeng
=E6=8A=84=E9=80=81: Benoit Claise; adrian@olddog.co.uk; aaa-doctors@ietf.org; The IESG; ace@ietf.org

=E4=B8=BB=E9=A2=98: Re: Revised charter proposal: charter-ietf-ace= -00-02

=C2=A0

Hi Kepeng,=

=C2=A0

If we are at a point where I ca= n update the charter, seems that way, please send the latest version that h= as been agreed upon and I'll take care of the update.

=C2=A0

Thanks.

= =C2=A0

On Tue, Jun 3, 2014 at 6:31 AM,= Likepeng <like= peng@huawei.com> wrote:

Hi Benoit,=

=C2=A0

>Not on= ly would I keep "AAA",

=C2=A0

OK.=

=C2=A0

>but I = would propose

=C2=A0

>OLD:

>Existi= ng authentication and authorization protocols will be used where

applicable= to build the constrained-environment solution.=

=C2=A0

>NEW:

Existing a= uthentication and authorization protocols will be evaluated and re-used whe= re

applicable= to build the constrained-environment solution.=

=C2=A0

OK, fine w= ith me.

=C2=A0

Thanks for= the feedback.

=C2=A0

Kind Regar= ds

Kepeng

=C2=A0

=E5=8F=91=E4=BB= =B6=E4=BA=BA: Benoit Claise [mailto:bclaise@cisco.com]
=E5=8F=91=E9=80=81=E6=97=B6=E9= =97=B4: 2014=E5=B9=B46=E6=9C=883=E6=97=A5<= span lang=3D"EN-US"> 12:16=

=E6=94=B6=E4=BB=B6=E4=BA=BA:= Likepeng; Kathleen Moriarty; adrian@olddog.co.u= k

=E6=8A=84=E9=80=81: aaa-doctors@ietf.org; The IESG; ace@ietf.org

=E4=B8=BB=E9=A2=98: Re: Revised charter proposal: charter-ietf-ace-00-0= 2

=C2=A0

= Hi,

Hello all,

=C2=A0

Based on recent discussions, I made a revised cha= rter proposal, as included in this email, not on the webpage yet.

=C2=A0

Please take a look and let us know if you have an= y further comments.

=C2=A0

@Adrian and @Benoit, please check if the proposed= texts can resolve your comments.

=C2=A0

Thanks,

Kind Regards

Kepeng

=C2=A0

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

Compared with charter-ietf-ace-00-01 on the webpa= ge, the changes are:

=C2=A0

(1)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Add one clarifi= cation sentence about REST architecture:

OLD

The IETF has recently developed protocols for use= in constrained

environments, where network nodes are limited in = CPU, memory and power.

REST architecture is widely used for such constra= ined environments.

=C2=A0

NEW

The IETF has recently developed protocols for use= in constrained

environments, where network nodes are limited in = CPU, memory and power.

REST architecture is widely used for such constra= ined environments.

END

Considering that OLD is<= u>

OLD

The IETF has recently develo= ped protocols for use in constrained<= /u>

environments, where network = nodes are limited in CPU, memory and power. =

= ... fine with me

=C2=A0

=C2=A0

(2)=C2=A0=C2=A0=C2=A0=C2=A0 Remove =E2=80= =9CAAA protocol=E2=80=9D f= rom the charter:

OLD

The IETF has a long history in developing three-p= arty authentication and

authorization protocols for distributed environme= nts. Examples include

Kerberos, the Public Key Infrastructure (PKI), th= e Authentication,

Authorization and Accounting (AAA) infrastructure= , and the Web

Authorization Protocol (OAuth).

=C2=A0

NEW

The IETF has a long history in developing three-p= arty authentication and

authorization protocols for distributed environme= nts. Examples include

Kerberos, the Public Key Infrastructure (PKI), an= d the Web Authorization Protocol (OAuth).

END

We have AAA-doctors telling: ma= ybe RADIUS is applicable?
Personally, I don't know and it doesn't matter at this point.
We received feedback such as:

Let's be clear here: It was= never said (in the charter or anywhere else in the group to my knowledge) = that RADIUS (or indeed any other AAA protocol) would not run on constrained devices (RFC 7228). The charter simply said the protoco= ls were not optimised for constrained devices. That does not preclude consi= dering any protocol for suitability for constrained devices either a) as is= , b) in a restricted way or c) in an adapted way.

So, at this stage, I don't think any protocols should be excluded from = consideration and should certainly not be eliminated on a hunch that they m= ight be "too big". Let's do the assessment properly at the ap= propriate time. As a reminder - the focus now is to complete the charter.

Or

>>The Charter makes a number of assertions = that are provably false, such as that AAA protocols are inappropriate for c= onstrained environments.

In fact, the charter does not say that. But to av= oid confusion, let's remove AAA protocol from the charter.

=C2=A0

In the charter, we mentioned that we want to reus= e existing authentication and authorization protocols where applicable to b= uild the constrained-environment solution.

= ... which I read as: let's consider the AAA protocols, and evaluate if = they would work in constrained devices.
I don't understand the logic: why do you want to remove AAA from the ch= arter?
Not only would I keep "AAA", but I would propose

OLD:
Existing authentication and authorization protocols will be used where
applicable to build the constrained-environment solution

NEW:
Existing authentication and authorization protocols will be evaluated and r= e-used where
applicable to build the constrained-environment solution

Regards, Benoit

=C2=A0

=C2=A0

(3) Clarify the scope:

OLD:

Note that the initial focus is on CoAP and HTTP w= ith DTLS and TLS.

Other security protocols may be considered as lon= g as the primary focus is maintained.=C2=A0

Other application protocols and protocols at othe= r layers in the stack are out of scope.

=C2=A0

NEW

Note that the initial focus is on CoAP and HTTP w= ith DTLS and TLS.

Other security protocols may be considered as lon= g as the primary focus is maintained.=C2=A0

The group is scoped to work only on the web proto= cols and data carried within them.

END

=C2=A0

(4)=C2=A0=C2=A0=C2=A0=C2=A0 Update milestones for= the use case & requirements document:

OLD:

Jul 2015 Submit =E2=80=9CUse cases and Requirements=E2=80=9D documen= t to IESG for publication as informational RFC.

=C2=A0

NEW

Dec 2014 Optionally, submit "Use cases and R= equirements" document to the IESG for publication as an Informational = RFC.

END

=C2=A0

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

Charter charter-ietf-ace-00-02

Authentication and Authorization for Constrained<= u>

Environment (ACE)

=C2=A0

The IETF has recently developed protocols for use= in constrained

environments, where network nodes are limited in = CPU, memory and power.

REST architecture is widely used for such constra= ined environments.

It has been observed that Internet protocols can = be applied to these

constrained environments, often only requiring mi= nor tweaking and

profiling. In other cases, new protocols have bee= n defined to address

the specific requirements of constrained environm= ents. An example of

such a protocol is the Constrained Application Pr= otocol (CoAP).

=C2=A0

As in other environments, authentication and auth= orization questions

also arise in constrained environments. For examp= le, a door lock has to

authorize the person seeking access using a "= ;digital key". Where is the

authorization policy stored? How does the digital= key communicate with

the lock? Does the lock interact with an authoriz= ation server to obtain

authorization information? How can access be temp= orarily granted to

other persons? How can access be revoked? These t= ypes of questions have

been answered by existing protocols for use cases= outside constrained

environments, however in constrained environments= , additional and

different requirements pose challenges for the us= e of various security

protocols. In particular, the need arises for a d= ynamic and fine grained

access control mechanism, where clients and/or re= source servers are

constrained.

=C2=A0

The IETF has a long history in developing three-p= arty authentication and

authorization protocols for distributed environme= nts. Examples include

Kerberos, the Public Key Infrastructure (PKI), an= d the Web

Authorization Protocol (OAuth). All these protoco= ls enjoy widespread

deployment on the Internet. Although they all aim= to solve a similar

goal, at an abstract level, they offer quite diff= erent functions and

utilize different message exchanges. These differ= ences result from the

main deployment use cases they were designed for = respectively.

=C2=A0

Requirements derived from use cases indicate the = suitability of existing

work as a solution for constrained environments. = These protocols,

however, were not optimized for constrained envir= onments. Additional

requirements that need to be taken into account a= re the lack of a

suitable user-interface and the inability of embe= dded devices to contact

an authorization server in real-time with every r= esource access request

due to intermittent connectivity, etc.<= /u>

=C2=A0

This working group therefore aims to produce a st= andardized solution for

authentication and authorization to enable author= ized access (GET, PUT, POST,

DELETE) to resources identified by a URI and host= ed on a resource

server in constrained environments. As a starting= point, the working

group will assume that access to resources at a r= esource server by a

client device takes place using CoAP and is prote= cted by DTLS. Both

resource server and client may be constrained. Th= is access will be

mediated by an authorization server, which is not= considered to be

constrained.

=C2=A0

Existing authentication and authorization protoco= ls will be used where

applicable to build the constrained-environment s= olution. This requires

relevant specifications to be reviewed for suitab= ility, selecting a

subset of them and restricting the options within= each of the

specifications. Some functionality, however, may = not be available in

existing protocols, in which case the solution ma= y also involve new

protocol work. Leveraging existing work means the= working group benefits

from available security analysis, implementation,= and deployment

experience. Moreover, a standardized solution for= federated

authentication and authorization will help to sti= mulate the deployment

of constrained devices that provide increased sec= urity.

=C2=A0

Once progress in identifying suitable candidate s= olutions has been made,

the working group will verify whether the same me= chanisms are also

applicable beyond the use of CoAP and DTLS, which= are the two main

protocols the group will focus on for access to r= esources. In

particular, the ability to use the developed solu= tion over HTTP and TLS

will be investigated. Note that the initial focus= is on CoAP and HTTP with DTLS and TLS.

Other security protocols may be considered as lon= g as the primary focus is maintained.=C2=A0

The group is scoped to work only on the web proto= cols and data carried within them.

Furthermore, to guarantee smooth transition, the<= u>

integration with existing deployments will be stu= died, particularly

concerning the use of protocol translation proxie= s.

=C2=A0

This work does not make the assumption that the p= arty offering

application layer services is always the same par= ty offering network

access services.

=C2=A0

The working group has the following tasks:=

=C2=A0

1) Produce use cases and requirements

=C2=A0

2) Identify authentication and authorization mech= anisms suitable for

resource access in constrained environments.

=C2=A0

Milestones:

=C2=A0

Jul 2014 Submit "Use cases and Requirements&= quot; as a WG item.

Dec 2014 Submit "Authentication and Authoriz= ation Solution" as a WG item.

Dec 2014 Optionally, submit "Use cases and R= equirements" document

to the IESG for publication as an Informational R= FC.

Jul 2016 Submit "Authentication and Authoriz= ation Solution"

specification to the IESG for publication as a Pr= oposed Standard.

=C2=A0

Proposed Milestones

No milestones for charter found.

=C2=A0

=C2=A0

--

=C2=A0

Best regards,

Kathleen

--

Be= st regards,
Kathleen

--

Best regards,
Kathleen
--001a11c36da222c4fd04faf45794-- From nobody Tue Jun 3 23:50:07 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B33921A00AA; Tue, 3 Jun 2014 23:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.151 X-Spam-Level: X-Spam-Status: No, score=-10.151 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, RP_MATCHES_RCVD=-0.651, 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 hp_qMpcu7ysL; Tue, 3 Jun 2014 23:49:57 -0700 (PDT) Received: from bgl-iport-4.cisco.com (bgl-iport-4.cisco.com [72.163.197.28]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AE041A009C; Tue, 3 Jun 2014 23:49:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=100606; q=dns/txt; s=iport; t=1401864588; x=1403074188; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=wEYp+sxY5wmc4VL6HO175xp/65ZymIsg5TzD9z/mAbU=; b=Fl2RH/vNYWiJOkP1AlF8/6GtXHkYzDp+/sYVPMyF2PH7G137BKTHq+P0 +y3Lw5ukGHqTvddDEaXGg/E6+RginG8NF3xlaILg5v/tGCwIfcgssmF1j 6MEV94IEM3ifMv5mVqx7L+kBOQ96VLjp0ht5iUzYvaWdM0aw855u11vmo E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArEEALfAjlNIo8UY/2dsb2JhbABPCoJCgReDRIVbui8BgSN0giUBAQEEGgEICjoNBAEQCQISBgkMCgEBBgMCAgkDAgECAQ8lAw4GAQwBBQIBAReIEwMRkEycIJ9gDYYIF4w8gTQGBAcBAjYYBgEKgmuBSwEDhVWSQIF6hm+GUYV2gzo7L4EBCRcCAg X-IronPort-AV: E=Sophos; i="4.98,971,1392163200"; d="scan'208,217"; a="10999470" Received: from vla196-nat.cisco.com (HELO bgl-core-4.cisco.com) ([72.163.197.24]) by bgl-iport-4.cisco.com with ESMTP; 04 Jun 2014 06:49:43 +0000 Received: from [10.60.67.91] (ams-bclaise-89110.cisco.com [10.60.67.91]) by bgl-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s546nb5G016221; Wed, 4 Jun 2014 06:49:38 GMT Message-ID: <538EC180.6000005@cisco.com> Date: Wed, 04 Jun 2014 08:49:36 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Likepeng , Kathleen Moriarty References: <20140514221215.8150.56543.idtracker@ietfa.amsl.com> <34966E97BE8AD64EAE9D3D6E4DEE36F252B2A345@SZXEMA501-MBS.china.huawei.com> <34966E97BE8AD64EAE9D3D6E4DEE36F252B38978@SZXEMA501-MBS.china.huawei.com> <34966E97BE8AD64EAE9D3D6E4DEE36F258140E59@SZXEMA501-MBX.china.huawei.com> <538DA047.7080902@cisco.com> <34966E97BE8AD64EAE9D3D6E4DEE36F258153F43@SZXEMA501-MBS.china.huawei.com> <34966E97BE8AD64EAE9D3D6E4DEE36F25815405D@SZXEMA501-MBS.china.huawei.com> In-Reply-To: <34966E97BE8AD64EAE9D3D6E4DEE36F25815405D@SZXEMA501-MBS.china.huawei.com> Content-Type: multipart/alternative; boundary="------------090306030109020904050003" Archived-At: http://mailarchive.ietf.org/arch/msg/ace/vU1qpuV2RN22158pSN52jxErjJo Cc: "aaa-doctors@ietf.org" , "adrian@olddog.co.uk" , The IESG , "ace@ietf.org" Subject: Re: [Ace] Revised charter proposal: charter-ietf-ace-00-02 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments $ace$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 06:50:04 -0000 This is a multi-part message in MIME format. --------------090306030109020904050003 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi Likepeng, You forgot OLD: Existing authentication and authorization protocols will be used where applicable to build the constrained-environment solution NEW: Existing authentication and authorization protocols will be evaluated and re-used where applicable to build the constrained-environment solution Regards, Benoit > > Hi Kathleen and all, > > This is what I have now: > > Change #1: (Proposed by Kepeng, confirmed by Benoit) > > OLD > The IETF has recently developed protocols for use in constrained > environments, where network nodes are limited in CPU, memory and power. > > NEW > The IETF has recently developed protocols for use in constrained > environments, where network nodes are limited in CPU, memory and power. > REST architecture is widely used for such constrained environments. > END > > Change #2: (Proposal from Rene, supported by Stefanie) > OLD: > Requirements derived from use cases indicate the suitability of existing > work as a solution for constrained environments > > NEW: > Requirements derived from use cases may indicate that existing work is > useful as basis for as a solution for constrained environments > > Change #3: (Proposal from Jari, supported by Barry, Robert and Behcet) > OLD: > Note that the initial focus is on CoAP and HTTP with DTLS and TLS. > Other security protocols may be considered as long as the primary focus is maintained. > Other application protocols and protocols at other layers in the stack are out of scope. > > NEW > Note that the initial focus is on CoAP and HTTP with DTLS and TLS. > Other security protocols may be considered as long as the primary focus is maintained. > The group is scoped to work only on the web protocols and data carried within them. > END > > Change 4: (Proposal from Jari, revised by Rene, supported by Stefanie) > OLD: > Jul 2014 Submit "Use cases and Requirements" as a WG item. > Jul 2015 Submit “Use cases and Requirements” document to IESG for publication as informational RFC. > > NEW > Dec 2014 Submit "Use cases and Requirements" as a WG item. > Apr 2015 Optionally, submit "Use cases and Requirements" document to the IESG for > publication as an Informational RFC. > END > > I think we covered all of the IESG review comments. > > If there is any open issue, please let us know. > > Thanks, > > Kind Regards > > Kepeng > > -------------------------------------------------------------------------------------------------------------------------------------------------------- > > Charter charter-ietf-ace-00-02 > > Authentication and Authorization for Constrained > > Environment (ACE) > > The IETF has recently developed protocols for use in constrained > > environments, where network nodes are limited in CPU, memory and power. > > REST architecture is widely used for such constrained environments. > > It has been observed that Internet protocols can be applied to these > > constrained environments, often only requiring minor tweaking and > > profiling. In other cases, new protocols have been defined to address > > the specific requirements of constrained environments. An example of > > such a protocol is the Constrained Application Protocol (CoAP). > > As in other environments, authentication and authorization questions > > also arise in constrained environments. For example, a door lock has to > > authorize the person seeking access using a "digital key". Where is the > > authorization policy stored? How does the digital key communicate with > > the lock? Does the lock interact with an authorization server to obtain > > authorization information? How can access be temporarily granted to > > other persons? How can access be revoked? These types of questions have > > been answered by existing protocols for use cases outside constrained > > environments, however in constrained environments, additional and > > different requirements pose challenges for the use of various security > > protocols. In particular, the need arises for a dynamic and fine grained > > access control mechanism, where clients and/or resource servers are > > constrained. > > The IETF has a long history in developing three-party authentication and > > authorization protocols for distributed environments. Examples include > > Kerberos, the Public Key Infrastructure (PKI), the Authentication, > > Authorization and Accounting (AAA) infrastructure,and the Web > > Authorization Protocol (OAuth). All these protocols enjoy widespread > > deployment on the Internet. Although they all aim to solve a similar > > goal, at an abstract level, they offer quite different functions and > > utilize different message exchanges. These differences result from the > > main deployment use cases they were designed for respectively. > > Requirements derived from use cases may indicate that existing work is > > useful as basis for as a solution for constrained environments. > > These protocols, > > however, were not optimized for constrained environments. Additional > > requirements that need to be taken into account are the lack of a > > suitable user-interface and the inability of embedded devices to contact > > an authorization server in real-time with every resource access request > > due to intermittent connectivity, etc. > > This working group therefore aims to produce a standardized solution for > > authentication and authorization to enable authorized access (GET, > PUT, POST, > > DELETE) to resources identified by a URI and hosted on a resource > > server in constrained environments. As a starting point, the working > > group will assume that access to resources at a resource server by a > > client device takes place using CoAP and is protected by DTLS. Both > > resource server and client may be constrained. This access will be > > mediated by an authorization server, which is not considered to be > > constrained. > > Existing authentication and authorization protocols will be evaluated > > and re-used where applicable to build the constrained-environment > solution. > > This requires > > relevant specifications to be reviewed for suitability, selecting a > > subset of them and restricting the options within each of the > > specifications. Some functionality, however, may not be available in > > existing protocols, in which case the solution may also involve new > > protocol work. Leveraging existing work means the working group benefits > > from available security analysis, implementation, and deployment > > experience. Moreover, a standardized solution for federated > > authentication and authorization will help to stimulate the deployment > > of constrained devices that provide increased security. > > Once progress in identifying suitable candidate solutions has been made, > > the working group will verify whether the same mechanisms are also > > applicable beyond the use of CoAP and DTLS, which are the two main > > protocols the group will focus on for access to resources. In > > particular, the ability to use the developed solution over HTTP and TLS > > will be investigated. Note that the initial focus is on CoAP and HTTP > with DTLS and TLS. > > Other security protocols may be considered as long as the primary > focus is maintained. > > The group is scoped to work only on the web protocols and data carried > within them. > > Furthermore, to guarantee smooth transition, the > > integration with existing deployments will be studied, particularly > > concerning the use of protocol translation proxies. > > This work does not make the assumption that the party offering > > application layer services is always the same party offering network > > access services. > > The working group has the following tasks: > > 1) Produce use cases and requirements > > 2) Identify authentication and authorization mechanisms suitable for > > resource access in constrained environments. > > Milestones: > > Dec 2014 Submit "Use cases and Requirements" as a WG item. > > Dec 2014 Submit "Authentication and Authorization Solution" as a WG item. > > Apr 2015 Optionally, submit "Use cases and Requirements" document > > to the IESG for publication as an Informational RFC. > > Jul 2016 Submit "Authentication and Authorization Solution" > > specification to the IESG for publication as a Proposed Standard. > > Proposed Milestones > > No milestones for charter found. > > *发件人:*Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com] > *发送时间:*2014年6月3日14:30 > *收件人:*Likepeng > *抄送:*Benoit Claise; adrian@olddog.co.uk; aaa-doctors@ietf.org; The > IESG; ace@ietf.org > *主题:*Re: Revised charter proposal: charter-ietf-ace-00-02 > > Hi Kepeng, > > If we are at a point where I can update the charter, seems that way, > please send the latest version that has been agreed upon and I'll take > care of the update. > > Thanks. > > On Tue, Jun 3, 2014 at 6:31 AM, Likepeng > wrote: > > Hi Benoit, > > >Not only would I keep "AAA", > > OK. > > >but I would propose > > >OLD: > > >Existing authentication and authorization protocols will be used where > > applicable to build the constrained-environment solution. > > >NEW: > > Existing authentication and authorization protocols will be evaluated > and re-used where > > applicable to build the constrained-environment solution. > > OK, fine with me. > > Thanks for the feedback. > > Kind Regards > > Kepeng > > *发件人:*Benoit Claise [mailto:bclaise@cisco.com > ] > *发送时间:*2014年6月3日12:16 > > *收件人:*Likepeng; Kathleen Moriarty; adrian@olddog.co.uk > > > *抄送:*aaa-doctors@ietf.org ; The IESG; > ace@ietf.org > > *主题:*Re: Revised charter proposal: charter-ietf-ace-00-02 > > Hi, > > Hello all, > > > > Based on recent discussions, I made a revised charter proposal, as included in this email, not on the webpage yet. > > > > Please take a look and let us know if you have any further comments. > > > > @Adrian and @Benoit, please check if the proposed texts can resolve your comments. > > > > Thanks, > > Kind Regards > > Kepeng > > > > ------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Compared with charter-ietf-ace-00-01 on the webpage, the changes are: > > > > (1) Add one clarification sentence about REST architecture: > > OLD > > The IETF has recently developed protocols for use in constrained > > environments, where network nodes are limited in CPU, memory and power. > > REST architecture is widely used for such constrained environments. > > > > NEW > > The IETF has recently developed protocols for use in constrained > > environments, where network nodes are limited in CPU, memory and power. > > REST architecture is widely used for such constrained environments. > > END > > Considering that OLD is > > OLD > The IETF has recently developed protocols for use in constrained > environments, where network nodes are limited in CPU, memory and power. > > ... fine with me > > > > (2) Remove“AAA protocol” from the charter: > OLD > The IETF has a long history in developing three-party authentication and > authorization protocols for distributed environments. Examples include > Kerberos, the Public Key Infrastructure (PKI), the Authentication, > Authorization and Accounting (AAA) infrastructure, and the Web > Authorization Protocol (OAuth). > > NEW > The IETF has a long history in developing three-party authentication and > authorization protocols for distributed environments. Examples include > Kerberos, the Public Key Infrastructure (PKI), and the Web Authorization Protocol (OAuth). > END > > We have AAA-doctors telling: maybe RADIUS is applicable? > Personally, I don't know and it doesn't matter at this point. > We received feedback such as: > > Let's be clear here: It was never said (in the charter or anywhere > else in the group to my knowledge) that RADIUS (or indeed any other > AAA protocol) would not run on constrained devices (RFC 7228). The > charter simply said the protocols were not optimised for constrained > devices. That does not preclude considering any protocol for > suitability for constrained devices either a) as is, b) in a > restricted way or c) in an adapted way. > > So, at this stage, I don't think any protocols should be excluded from > consideration and should certainly not be eliminated on a hunch that > they might be "too big". Let's do the assessment properly at the > appropriate time. As a reminder - the focus now is to complete the > charter. > > Or > > >>The Charter makes a number of assertions that are provably false, such as that AAA protocols are inappropriate for constrained environments. > In fact, the charter does not say that. But to avoid confusion, let's remove AAA protocol from the charter. > > In the charter, we mentioned that we want to reuse existing authentication and authorization protocols where applicable to build the constrained-environment solution. > > ... which I read as: let's consider the AAA protocols, and evaluate if > they would work in constrained devices. > I don't understand the logic: why do you want to remove AAA from the > charter? > Not only would I keep "AAA", but I would propose > > OLD: > Existing authentication and authorization protocols will be used where > applicable to build the constrained-environment solution > > NEW: > Existing authentication and authorization protocols will be evaluated > and re-used where > applicable to build the constrained-environment solution > > Regards, Benoit > > > > (3) Clarify the scope: > OLD: > Note that the initial focus is on CoAP and HTTP with DTLS and TLS. > Other security protocols may be considered as long as the primary focus is maintained. > Other application protocols and protocols at other layers in the stack are out of scope. > > NEW > Note that the initial focus is on CoAP and HTTP with DTLS and TLS. > Other security protocols may be considered as long as the primary focus is maintained. > The group is scoped to work only on the web protocols and data carried within them. > END > > (4) Update milestones for the use case & requirements document: > OLD: > Jul 2015 Submit“Use cases and Requirements” document to IESG for publication as informational RFC. > > NEW > Dec 2014 Optionally, submit "Use cases and Requirements" document to the IESG for publication as an Informational RFC. > END > > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > Charter charter-ietf-ace-00-02 > Authentication and Authorization for Constrained > Environment (ACE) > > The IETF has recently developed protocols for use in constrained > environments, where network nodes are limited in CPU, memory and power. > REST architecture is widely used for such constrained environments. > It has been observed that Internet protocols can be applied to these > constrained environments, often only requiring minor tweaking and > profiling. In other cases, new protocols have been defined to address > the specific requirements of constrained environments. An example of > such a protocol is the Constrained Application Protocol (CoAP). > > As in other environments, authentication and authorization questions > also arise in constrained environments. For example, a door lock has to > authorize the person seeking access using a "digital key". Where is the > authorization policy stored? How does the digital key communicate with > the lock? Does the lock interact with an authorization server to obtain > authorization information? How can access be temporarily granted to > other persons? How can access be revoked? These types of questions have > been answered by existing protocols for use cases outside constrained > environments, however in constrained environments, additional and > different requirements pose challenges for the use of various security > protocols. In particular, the need arises for a dynamic and fine grained > access control mechanism, where clients and/or resource servers are > constrained. > > The IETF has a long history in developing three-party authentication and > authorization protocols for distributed environments. Examples include > Kerberos, the Public Key Infrastructure (PKI), and the Web > Authorization Protocol (OAuth). All these protocols enjoy widespread > deployment on the Internet. Although they all aim to solve a similar > goal, at an abstract level, they offer quite different functions and > utilize different message exchanges. These differences result from the > main deployment use cases they were designed for respectively. > > Requirements derived from use cases indicate the suitability of existing > work as a solution for constrained environments. These protocols, > however, were not optimized for constrained environments. Additional > requirements that need to be taken into account are the lack of a > suitable user-interface and the inability of embedded devices to contact > an authorization server in real-time with every resource access request > due to intermittent connectivity, etc. > > This working group therefore aims to produce a standardized solution for > authentication and authorization to enable authorized access (GET, PUT, POST, > DELETE) to resources identified by a URI and hosted on a resource > server in constrained environments. As a starting point, the working > group will assume that access to resources at a resource server by a > client device takes place using CoAP and is protected by DTLS. Both > resource server and client may be constrained. This access will be > mediated by an authorization server, which is not considered to be > constrained. > > Existing authentication and authorization protocols will be used where > applicable to build the constrained-environment solution. This requires > relevant specifications to be reviewed for suitability, selecting a > subset of them and restricting the options within each of the > specifications. Some functionality, however, may not be available in > existing protocols, in which case the solution may also involve new > protocol work. Leveraging existing work means the working group benefits > from available security analysis, implementation, and deployment > experience. Moreover, a standardized solution for federated > authentication and authorization will help to stimulate the deployment > of constrained devices that provide increased security. > > Once progress in identifying suitable candidate solutions has been made, > the working group will verify whether the same mechanisms are also > applicable beyond the use of CoAP and DTLS, which are the two main > protocols the group will focus on for access to resources. In > particular, the ability to use the developed solution over HTTP and TLS > will be investigated. Note that the initial focus is on CoAP and HTTP with DTLS and TLS. > Other security protocols may be considered as long as the primary focus is maintained. > The group is scoped to work only on the web protocols and data carried within them. > Furthermore, to guarantee smooth transition, the > integration with existing deployments will be studied, particularly > concerning the use of protocol translation proxies. > > This work does not make the assumption that the party offering > application layer services is always the same party offering network > access services. > > The working group has the following tasks: > > 1) Produce use cases and requirements > > 2) Identify authentication and authorization mechanisms suitable for > resource access in constrained environments. > > Milestones: > > Jul 2014 Submit "Use cases and Requirements" as a WG item. > Dec 2014 Submit "Authentication and Authorization Solution" as a WG item. > Dec 2014 Optionally, submit "Use cases and Requirements" document > to the IESG for publication as an Informational RFC. > Jul 2016 Submit "Authentication and Authorization Solution" > specification to the IESG for publication as a Proposed Standard. > > Proposed Milestones > No milestones for charter found. > > > > -- > > Best regards, > > Kathleen > --------------090306030109020904050003 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Hi Likepeng,

You forgot
OLD:
Existing authentication and authorization protocols will be used where
applicable to build the constrained-environment solution

NEW:
Existing authentication and authorization protocols will be evaluated and re-used where
applicable to build the constrained-environment solution

Regards, Benoit

Hi Kathleen and all,

This is what I have now:

Change #1: (Proposed by Kepeng, confirmed by Benoit)

OLD

The IETF has recently developed protocols for use in constrained

environments, where network nodes are limited in CPU, memory and power.

NEW

The IETF has recently developed protocols for use in constrained

environments, where network nodes are limited in CPU, memory and power.

REST architecture is widely used for such constrained environments.

END

Change #2: (Proposal from Rene, supported by Stefanie)

OLD:

Requirements derived from use cases indicate the suitability of existing

work as a solution for constrained environments

NEW:

Requirements derived from use cases may indicate that existing work is

useful as basis for as a solution for constrained environments

Change #3: (Proposal from Jari, supported by Barry, Robert and Behcet)

OLD:

Note that the initial focus is on CoAP and HTTP with DTLS and TLS.

Other security protocols may be considered as long as the primary focus is maintained.

Other application protocols and protocols at other layers in the stack are out of scope.

NEW

Note that the initial focus is on CoAP and HTTP with DTLS and TLS.

Other security protocols may be considered as long as the primary focus is maintained.

The group is scoped to work only on the web protocols and data carried within them.

END

Change 4: (Proposal from Jari, revised by Rene, supported by Stefanie)

OLD:

Jul 2014 Submit "Use cases and Requirements" as a WG item.

Jul 2015 Submit “Use cases and Requirements” document to IESG for publication as informational RFC.

NEW

Dec 2014 Submit "Use cases and Requirements" as a WG item.

Apr 2015 Optionally, submit "Use cases and Requirements" document to the IESG for

publication as an Informational RFC.

END

I think we covered all of the IESG review comments.

If there is any open issue, please let us know.

Thanks,

Kind Regards

Kepeng

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

Charter charter-ietf-ace-00-02

Authentication and Authorization for Constrained

Environment (ACE)

The IETF has recently developed protocols for use in constrained

environments, where network nodes are limited in CPU, memory and power.

REST architecture is widely used for such constrained environments.

It has been observed that Internet protocols can be applied to these

constrained environments, often only requiring minor tweaking and

profiling. In other cases, new protocols have been defined to address

the specific requirements of constrained environments. An example of

such a protocol is the Constrained Application Protocol (CoAP).

As in other environments, authentication and authorization questions

also arise in constrained environments. For example, a door lock has to

authorize the person seeking access using a "digital key". Where is the

authorization policy stored? How does the digital key communicate with

the lock? Does the lock interact with an authorization server to obtain

authorization information? How can access be temporarily granted to

other persons? How can access be revoked? These types of questions have

been answered by existing protocols for use cases outside constrained

environments, however in constrained environments, additional and

different requirements pose challenges for the use of various security

protocols. In particular, the need arises for a dynamic and fine grained

access control mechanism, where clients and/or resource servers are

constrained.

The IETF has a long history in developing three-party authentication and

authorization protocols for distributed environments. Examples include

Kerberos, the Public Key Infrastructure (PKI), the Authentication,

Authorization and Accounting (AAA) infrastructure,and the Web

Authorization Protocol (OAuth). All these protocols enjoy widespread

deployment on the Internet. Although they all aim to solve a similar

goal, at an abstract level, they offer quite different functions and

utilize different message exchanges. These differences result from the

main deployment use cases they were designed for respectively.

Requirements derived from use cases may indicate that existing work is

useful as basis for as a solution for constrained environments.

These protocols,

however, were not optimized for constrained environments. Additional

requirements that need to be taken into account are the lack of a

suitable user-interface and the inability of embedded devices to contact

an authorization server in real-time with every resource access request

due to intermittent connectivity, etc.

This working group therefore aims to produce a standardized solution for

authentication and authorization to enable authorized access (GET, PUT, POST,

DELETE) to resources identified by a URI and hosted on a resource

server in constrained environments. As a starting point, the working

group will assume that access to resources at a resource server by a

client device takes place using CoAP and is protected by DTLS. Both

resource server and client may be constrained. This access will be

mediated by an authorization server, which is not considered to be

constrained.

Existing authentication and authorization protocols will be evaluated

and re-used where applicable to build the constrained-environment solution.

This requires

relevant specifications to be reviewed for suitability, selecting a

subset of them and restricting the options within each of the

specifications. Some functionality, however, may not be available in

existing protocols, in which case the solution may also involve new

protocol work. Leveraging existing work means the working group benefits

from available security analysis, implementation, and deployment

experience. Moreover, a standardized solution for federated

authentication and authorization will help to stimulate the deployment

of constrained devices that provide increased security.

Once progress in identifying suitable candidate solutions has been made,

the working group will verify whether the same mechanisms are also

applicable beyond the use of CoAP and DTLS, which are the two main

protocols the group will focus on for access to resources. In

particular, the ability to use the developed solution over HTTP and TLS

will be investigated. Note that the initial focus is on CoAP and HTTP with DTLS and TLS.

Other security protocols may be considered as long as the primary focus is maintained.

The group is scoped to work only on the web protocols and data carried within them.

Furthermore, to guarantee smooth transition, the

integration with existing deployments will be studied, particularly

concerning the use of protocol translation proxies.

This work does not make the assumption that the party offering

application layer services is always the same party offering network

access services.

The working group has the following tasks:

1) Produce use cases and requirements

2) Identify authentication and authorization mechanisms suitable for

resource access in constrained environments.

Milestones:

Dec 2014 Submit "Use cases and Requirements" as a WG item.

Dec 2014 Submit "Authentication and Authorization Solution" as a WG item.

Apr 2015 Optionally, submit "Use cases and Requirements" document

to the IESG for publication as an Informational RFC.

Jul 2016 Submit "Authentication and Authorization Solution"

specification to the IESG for publication as a Proposed Standard.

Proposed Milestones

No milestones for charter found.

发件人: Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com]
发送时间: 2014年6月3日 14:30
收件人: Likepeng
抄送: Benoit Claise; adrian@olddog.co.uk; aaa-doctors@ietf.org; The IESG; ace@ietf.org
主题: Re: Revised charter proposal: charter-ietf-ace-00-02

Hi Kepeng,

If we are at a point where I can update the charter, seems that way, please send the latest version that has been agreed upon and I'll take care of the update.

Thanks.

On Tue, Jun 3, 2014 at 6:31 AM, Likepeng <likepeng@huawei.com> wrote:

Hi Benoit,

>Not only would I keep "AAA",

OK.

>but I would propose

>OLD:

>Existing authentication and authorization protocols will be used where

applicable to build the constrained-environment solution.

>NEW:

Existing authentication and authorization protocols will be evaluated and re-used where

applicable to build the constrained-environment solution.

OK, fine with me.

Thanks for the feedback.

Kind Regards

Kepeng

发件人: Benoit Claise [mailto:bclaise@cisco.com]
发送时间: 2014年6月3日 12:16

收件人: Likepeng; Kathleen Moriarty; adrian@olddog.co.uk

抄送: aaa-doctors@ietf.org; The IESG; ace@ietf.org

主题: Re: Revised charter proposal: charter-ietf-ace-00-02

Hi,

Hello all,

Based on recent discussions, I made a revised charter proposal, as included in this email, not on the webpage yet.

Please take a look and let us know if you have any further comments.

@Adrian and @Benoit, please check if the proposed texts can resolve your comments.

Thanks,

Kind Regards

Kepeng

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

Compared with charter-ietf-ace-00-01 on the webpage, the changes are:

(1)      Add one clarification sentence about REST architecture:

OLD

The IETF has recently developed protocols for use in constrained

environments, where network nodes are limited in CPU, memory and power.

REST architecture is widely used for such constrained environments.

NEW

The IETF has recently developed protocols for use in constrained

environments, where network nodes are limited in CPU, memory and power.

REST architecture is widely used for such constrained environments.

END

Considering that OLD is

OLD

The IETF has recently developed protocols for use in constrained

environments, where network nodes are limited in CPU, memory and power.

... fine with me

(2)     Remove “AAA protocol” from the charter:

OLD

The IETF has a long history in developing three-party authentication and

authorization protocols for distributed environments. Examples include

Kerberos, the Public Key Infrastructure (PKI), the Authentication,

Authorization and Accounting (AAA) infrastructure, and the Web

Authorization Protocol (OAuth).

NEW

The IETF has a long history in developing three-party authentication and

authorization protocols for distributed environments. Examples include

Kerberos, the Public Key Infrastructure (PKI), and the Web Authorization Protocol (OAuth).

END

We have AAA-doctors telling: maybe RADIUS is applicable?
Personally, I don't know and it doesn't matter at this point.
We received feedback such as:

Let's be clear here: It was never said (in the charter or anywhere else in the group to my knowledge) that RADIUS (or indeed any other AAA protocol) would not run on constrained devices (RFC 7228). The charter simply said the protocols were not optimised for constrained devices. That does not preclude considering any protocol for suitability for constrained devices either a) as is, b) in a restricted way or c) in an adapted way.

So, at this stage, I don't think any protocols should be excluded from consideration and should certainly not be eliminated on a hunch that they might be "too big". Let's do the assessment properly at the appropriate time. As a reminder - the focus now is to complete the charter.

Or

>>The Charter makes a number of assertions that are provably false, such as that AAA protocols are inappropriate for constrained environments.

In fact, the charter does not say that. But to avoid confusion, let's remove AAA protocol from the charter.

In the charter, we mentioned that we want to reuse existing authentication and authorization protocols where applicable to build the constrained-environment solution.

... which I read as: let's consider the AAA protocols, and evaluate if they would work in constrained devices.
I don't understand the logic: why do you want to remove AAA from the charter?
Not only would I keep "AAA", but I would propose

OLD:
Existing authentication and authorization protocols will be used where
applicable to build the constrained-environment solution

NEW:
Existing authentication and authorization protocols will be evaluated and re-used where
applicable to build the constrained-environment solution

Regards, Benoit

(3) Clarify the scope:

OLD:

Note that the initial focus is on CoAP and HTTP with DTLS and TLS.

Other security protocols may be considered as long as the primary focus is maintained.

Other application protocols and protocols at other layers in the stack are out of scope.

NEW

Note that the initial focus is on CoAP and HTTP with DTLS and TLS.

Other security protocols may be considered as long as the primary focus is maintained.

The group is scoped to work only on the web protocols and data carried within them.

END

(4)     Update milestones for the use case & requirements document:

OLD:

Jul 2015 Submit “Use cases and Requirements” document to IESG for publication as informational RFC.

NEW

Dec 2014 Optionally, submit "Use cases and Requirements" document to the IESG for publication as an Informational RFC.

END

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

Charter charter-ietf-ace-00-02

Authentication and Authorization for Constrained

Environment (ACE)

The IETF has recently developed protocols for use in constrained

environments, where network nodes are limited in CPU, memory and power.

REST architecture is widely used for such constrained environments.

It has been observed that Internet protocols can be applied to these

constrained environments, often only requiring minor tweaking and

profiling. In other cases, new protocols have been defined to address

the specific requirements of constrained environments. An example of

such a protocol is the Constrained Application Protocol (CoAP).

As in other environments, authentication and authorization questions

also arise in constrained environments. For example, a door lock has to

authorize the person seeking access using a "digital key". Where is the

authorization policy stored? How does the digital key communicate with

the lock? Does the lock interact with an authorization server to obtain

authorization information? How can access be temporarily granted to

other persons? How can access be revoked? These types of questions have

been answered by existing protocols for use cases outside constrained

environments, however in constrained environments, additional and

different requirements pose challenges for the use of various security

protocols. In particular, the need arises for a dynamic and fine grained

access control mechanism, where clients and/or resource servers are

constrained.

The IETF has a long history in developing three-party authentication and

authorization protocols for distributed environments. Examples include

Kerberos, the Public Key Infrastructure (PKI), and the Web

Authorization Protocol (OAuth). All these protocols enjoy widespread

deployment on the Internet. Although they all aim to solve a similar

goal, at an abstract level, they offer quite different functions and

utilize different message exchanges. These differences result from the

main deployment use cases they were designed for respectively.

Requirements derived from use cases indicate the suitability of existing

work as a solution for constrained environments. These protocols,

however, were not optimized for constrained environments. Additional

requirements that need to be taken into account are the lack of a

suitable user-interface and the inability of embedded devices to contact

an authorization server in real-time with every resource access request

due to intermittent connectivity, etc.

This working group therefore aims to produce a standardized solution for

authentication and authorization to enable authorized access (GET, PUT, POST,

DELETE) to resources identified by a URI and hosted on a resource

server in constrained environments. As a starting point, the working

group will assume that access to resources at a resource server by a

client device takes place using CoAP and is protected by DTLS. Both

resource server and client may be constrained. This access will be

mediated by an authorization server, which is not considered to be

constrained.

Existing authentication and authorization protocols will be used where

applicable to build the constrained-environment solution. This requires

relevant specifications to be reviewed for suitability, selecting a

subset of them and restricting the options within each of the

specifications. Some functionality, however, may not be available in

existing protocols, in which case the solution may also involve new

protocol work. Leveraging existing work means the working group benefits

from available security analysis, implementation, and deployment

experience. Moreover, a standardized solution for federated

authentication and authorization will help to stimulate the deployment

of constrained devices that provide increased security.

Once progress in identifying suitable candidate solutions has been made,

the working group will verify whether the same mechanisms are also

applicable beyond the use of CoAP and DTLS, which are the two main

protocols the group will focus on for access to resources. In

particular, the ability to use the developed solution over HTTP and TLS

will be investigated. Note that the initial focus is on CoAP and HTTP with DTLS and TLS.

Other security protocols may be considered as long as the primary focus is maintained.

The group is scoped to work only on the web protocols and data carried within them.

Furthermore, to guarantee smooth transition, the

integration with existing deployments will be studied, particularly

concerning the use of protocol translation proxies.

This work does not make the assumption that the party offering

application layer services is always the same party offering network

access services.

The working group has the following tasks:

1) Produce use cases and requirements

2) Identify authentication and authorization mechanisms suitable for

resource access in constrained environments.

Milestones:

Jul 2014 Submit "Use cases and Requirements" as a WG item.

Dec 2014 Submit "Authentication and Authorization Solution" as a WG item.

Dec 2014 Optionally, submit "Use cases and Requirements" document

to the IESG for publication as an Informational RFC.

Jul 2016 Submit "Authentication and Authorization Solution"

specification to the IESG for publication as a Proposed Standard.

Proposed Milestones

No milestones for charter found.

--

Best regards,

Kathleen

--------------090306030109020904050003-- From nobody Wed Jun 4 00:07:08 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 238E41A009E; Wed, 4 Jun 2014 00:06:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 wvHQMmNNW5MG; Wed, 4 Jun 2014 00:06:41 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1B6A1A00AD; Wed, 4 Jun 2014 00:06:39 -0700 (PDT) X-AuditID: c1b4fb30-f79a56d000006536-c6-538ec5787e9f Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 06.8B.25910.875CE835; Wed, 4 Jun 2014 09:06:32 +0200 (CEST) Received: from ESESSMB303.ericsson.se ([169.254.3.215]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0174.001; Wed, 4 Jun 2014 09:06:31 +0200 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Kathleen Moriarty , Likepeng Thread-Topic: [Ace] Revised charter proposal: charter-ietf-ace-00-02 Thread-Index: AQHPfzfhgp+NyfDDS0ih1oH/hpFnbptfU1SAgABhLYCAANQOgA== Date: Wed, 4 Jun 2014 07:06:31 +0000 Message-ID: References: <20140514221215.8150.56543.idtracker@ietfa.amsl.com> <34966E97BE8AD64EAE9D3D6E4DEE36F252B2A345@SZXEMA501-MBS.china.huawei.com> <34966E97BE8AD64EAE9D3D6E4DEE36F252B38978@SZXEMA501-MBS.china.huawei.com> <34966E97BE8AD64EAE9D3D6E4DEE36F258140E59@SZXEMA501-MBX.china.huawei.com> <538DA047.7080902@cisco.com> <34966E97BE8AD64EAE9D3D6E4DEE36F258153F43@SZXEMA501-MBS.china.huawei.com> <34966E97BE8AD64EAE9D3D6E4DEE36F25815405D@SZXEMA501-MBS.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [153.88.183.154] Content-Type: multipart/alternative; boundary="_000_CFB43838132A5goranselanderericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrKIsWRmVeSWpSXmKPExsUyM+JvjW7F0b5gg+UPZS1WHPrCZvH9Ww+z xY+eG8wWRx9LWMz4M5HZomFnvsWew03MDuweU35vZPXYOesuu0fLkbesHkuW/GTyWLF5JWMA axSXTUpqTmZZapG+XQJXRs/uC2wFi7ewV9xtc25gfDKbvYuRk0NCwETi6sQ5ULaYxIV769m6 GLk4hASOMkpMmzwbylnMKLF272xWkCo2AReJBw2PmEBsEYEoiY4Hm1lBipgF9jFKbF0zHSwh LOAsceTDInaIIheJPzt2QzU4Saz6P4ERxGYRUJGYs+YmM4jNK2AhsWnhEhaIbd9ZJVbumAs0 lYODUyBQ4uIfZ5AaRqDzvp9aAzaHWUBc4taT+UwQZwtILNlznhnCFpV4+fgf2KGiAnoS747D 1ChJLLr9Gao3VuJi+3MWiL2CEidnPmGZwCg2C8nYWUjKZiEpmwV0EbOApsT6XfoQJYoSU7of skPYGhKtc+ZC2dYSDfuOsiGrWcDIsYpRtDi1OCk33chIL7UoM7m4OD9PLy+1ZBMjMN4Pbvlt sIPx5XPHQ4wCHIxKPLwKvH3BQqyJZcWVuYcYpTlYlMR5L2pUBwsJpCeWpGanphakFsUXleak Fh9iZOLglGpg5Nwp9+my5MaXKzNTyxWsE7+eiD3ytiVWOsYiZsOmO+FRP81OlTrXf7/40VWF 4Uz+Ek+B/4EPua3YgiKXt5S8SHy3+tuygPRrXeyfDtlf+lXdfKvWMWvH8UzOkknCu+el6y6o W/33rF0379fCQ4pTrvk0XdYxaBD5s8Py3PnZkxYUXhY4VHD4gRJLcUaioRZzUXEiAPA9zWzY AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/ace/FCNN1W3ZGKTvHfWd3ZNuXGYexpA Cc: Benoit Claise , "adrian@olddog.co.uk" , "aaa-doctors@ietf.org" , The IESG , "ace@ietf.org" Subject: Re: [Ace] Revised charter proposal: charter-ietf-ace-00-02 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments $ace$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 07:06:56 -0000 --_000_CFB43838132A5goranselanderericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgS2F0aGxlZW4sDQoNCkluIGNoYW5nZSAjMyBvZiB0aGUgc3VtbWFyeSBLZXBlbmcgbWFkZSBi ZWxvdyBJIGZpbmQgdGhlIHNlbnRlbmNlOiA+Pk90aGVyIHNlY3VyaXR5IHByb3RvY29scyBtYXkg YmUgY29uc2lkZXJlZCBhcyBsb25nIGFzIHRoZSBwcmltYXJ5IGZvY3VzIGlzIG1haW50YWluZWQu ID4+IFRoaXMgc2VudGVuY2Ugc2VlbXMgdG8gYmUgbWlzc2luZyBmcm9tIGNoYXJ0ZXItaWV0Zi1h Y2UtMDAtMDQuDQoNClJlZ2FyZHMsDQpHw7ZyYW4NCg0KDQpGcm9tOiBLYXRobGVlbiBNb3JpYXJ0 eSA8a2F0aGxlZW4ubW9yaWFydHkuaWV0ZkBnbWFpbC5jb208bWFpbHRvOmthdGhsZWVuLm1vcmlh cnR5LmlldGZAZ21haWwuY29tPj4NCkRhdGU6IFR1ZXNkYXkgMyBKdW5lIDIwMTQgMjI6MjcNClRv OiBMaWtlcGVuZyA8bGlrZXBlbmdAaHVhd2VpLmNvbTxtYWlsdG86bGlrZXBlbmdAaHVhd2VpLmNv bT4+DQpDYzogQmVub2l0IENsYWlzZSA8YmNsYWlzZUBjaXNjby5jb208bWFpbHRvOmJjbGFpc2VA Y2lzY28uY29tPj4sICJhZHJpYW5Ab2xkZG9nLmNvLnVrPG1haWx0bzphZHJpYW5Ab2xkZG9nLmNv LnVrPiIgPGFkcmlhbkBvbGRkb2cuY28udWs8bWFpbHRvOmFkcmlhbkBvbGRkb2cuY28udWs+Piwg ImFjZUBpZXRmLm9yZzxtYWlsdG86YWNlQGlldGYub3JnPiIgPGFjZUBpZXRmLm9yZzxtYWlsdG86 YWNlQGlldGYub3JnPj4sIFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPG1haWx0bzppZXNnQGlldGYu b3JnPj4sICJhYWEtZG9jdG9yc0BpZXRmLm9yZzxtYWlsdG86YWFhLWRvY3RvcnNAaWV0Zi5vcmc+ IiA8YWFhLWRvY3RvcnNAaWV0Zi5vcmc8bWFpbHRvOmFhYS1kb2N0b3JzQGlldGYub3JnPj4NClN1 YmplY3Q6IFJlOiBbQWNlXSBSZXZpc2VkIGNoYXJ0ZXIgcHJvcG9zYWw6IGNoYXJ0ZXItaWV0Zi1h Y2UtMDAtMDINCg0KVGhlIGNoYXJ0ZXIgdGV4dCBoYXMgYmVlbiB1cGRhdGVkLCBodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9jaGFydGVyLWlldGYtYWNlLw0KDQpUaGFuayB5b3UgYWxs IGZvciB5b3VyIGlucHV0IGFuZCBhc3Npc3RhbmNlLiAgSWYgdGhpcyBpcyBnb29kLCB3ZSdsbCBt b3ZlIGl0IGZvcndhcmQgZm9yIElFVEYgcmV2aWV3Lg0KDQoNCk9uIFR1ZSwgSnVuIDMsIDIwMTQg YXQgMTA6MzkgQU0sIEthdGhsZWVuIE1vcmlhcnR5IDxrYXRobGVlbi5tb3JpYXJ0eS5pZXRmQGdt YWlsLmNvbTxtYWlsdG86a2F0aGxlZW4ubW9yaWFydHkuaWV0ZkBnbWFpbC5jb20+PiB3cm90ZToN CkkgYmVsaWV2ZSB0aGVyZSBpcyBhZ3JlZW1lbnQgb24gdGhlIHByb3Bvc2VkIGNoYW5nZXMuICBJ J2xsIG1ha2UgdGhlIHVwZGF0ZXMgbGF0ZXIgaW4gdGhlIGRheSAoaXQncyBhYm91dCAxMTozMCBt eSB0aW1lLCBtYXliZSBhdCA0KSBpbiBjYXNlIGFueW9uZSB3YW50cyB0byBjaGltZSBpbi4gIElm IHdlIGFyZSBhbGwgaW4gYWdyZWVtZW50LCBJJ2xsIGhhdmUgaXQgc2VudCBmb3IgSUVURiByZXZp ZXcgYXQgdGhhdCBwb2ludC4NCg0KVGhhbmsgeW91IQ0KDQoNCk9uIFR1ZSwgSnVuIDMsIDIwMTQg YXQgMTA6MjYgQU0sIExpa2VwZW5nIDxsaWtlcGVuZ0BodWF3ZWkuY29tPG1haWx0bzpsaWtlcGVu Z0BodWF3ZWkuY29tPj4gd3JvdGU6DQpIaSBLYXRobGVlbiBhbmQgYWxsLA0KDQpUaGlzIGlzIHdo YXQgSSBoYXZlIG5vdzoNCg0KQ2hhbmdlICMxOiAoUHJvcG9zZWQgYnkgS2VwZW5nLCBjb25maXJt ZWQgYnkgQmVub2l0KQ0KDQpPTEQNCg0KVGhlIElFVEYgaGFzIHJlY2VudGx5IGRldmVsb3BlZCBw cm90b2NvbHMgZm9yIHVzZSBpbiBjb25zdHJhaW5lZA0KDQplbnZpcm9ubWVudHMsIHdoZXJlIG5l dHdvcmsgbm9kZXMgYXJlIGxpbWl0ZWQgaW4gQ1BVLCBtZW1vcnkgYW5kIHBvd2VyLg0KDQoNCg0K TkVXDQoNClRoZSBJRVRGIGhhcyByZWNlbnRseSBkZXZlbG9wZWQgcHJvdG9jb2xzIGZvciB1c2Ug aW4gY29uc3RyYWluZWQNCg0KZW52aXJvbm1lbnRzLCB3aGVyZSBuZXR3b3JrIG5vZGVzIGFyZSBs aW1pdGVkIGluIENQVSwgbWVtb3J5IGFuZCBwb3dlci4NCg0KUkVTVCBhcmNoaXRlY3R1cmUgaXMg d2lkZWx5IHVzZWQgZm9yIHN1Y2ggY29uc3RyYWluZWQgZW52aXJvbm1lbnRzLg0KDQpFTkQNCg0K DQoNCkNoYW5nZSAjMjogKFByb3Bvc2FsIGZyb20gUmVuZSwgc3VwcG9ydGVkIGJ5IFN0ZWZhbmll KQ0KDQpPTEQ6DQoNClJlcXVpcmVtZW50cyBkZXJpdmVkIGZyb20gdXNlIGNhc2VzIGluZGljYXRl IHRoZSBzdWl0YWJpbGl0eSBvZiBleGlzdGluZw0KDQp3b3JrIGFzIGEgc29sdXRpb24gZm9yIGNv bnN0cmFpbmVkIGVudmlyb25tZW50cw0KDQoNCg0KTkVXOg0KDQpSZXF1aXJlbWVudHMgZGVyaXZl ZCBmcm9tIHVzZSBjYXNlcyBtYXkgaW5kaWNhdGUgdGhhdCBleGlzdGluZyB3b3JrIGlzDQoNCiB1 c2VmdWwgYXMgYmFzaXMgZm9yIGFzIGEgc29sdXRpb24gZm9yIGNvbnN0cmFpbmVkIGVudmlyb25t ZW50cw0KDQoNCg0KQ2hhbmdlICMzOiAoUHJvcG9zYWwgZnJvbSBKYXJpLCBzdXBwb3J0ZWQgYnkg QmFycnksIFJvYmVydCBhbmQgQmVoY2V0KQ0KDQpPTEQ6DQoNCk5vdGUgdGhhdCB0aGUgaW5pdGlh bCBmb2N1cyBpcyBvbiBDb0FQIGFuZCBIVFRQIHdpdGggRFRMUyBhbmQgVExTLg0KDQpPdGhlciBz ZWN1cml0eSBwcm90b2NvbHMgbWF5IGJlIGNvbnNpZGVyZWQgYXMgbG9uZyBhcyB0aGUgcHJpbWFy eSBmb2N1cyBpcyBtYWludGFpbmVkLg0KDQpPdGhlciBhcHBsaWNhdGlvbiBwcm90b2NvbHMgYW5k IHByb3RvY29scyBhdCBvdGhlciBsYXllcnMgaW4gdGhlIHN0YWNrIGFyZSBvdXQgb2Ygc2NvcGUu DQoNCg0KDQpORVcNCg0KTm90ZSB0aGF0IHRoZSBpbml0aWFsIGZvY3VzIGlzIG9uIENvQVAgYW5k IEhUVFAgd2l0aCBEVExTIGFuZCBUTFMuDQoNCk90aGVyIHNlY3VyaXR5IHByb3RvY29scyBtYXkg YmUgY29uc2lkZXJlZCBhcyBsb25nIGFzIHRoZSBwcmltYXJ5IGZvY3VzIGlzIG1haW50YWluZWQu DQoNClRoZSBncm91cCBpcyBzY29wZWQgdG8gd29yayBvbmx5IG9uIHRoZSB3ZWIgcHJvdG9jb2xz IGFuZCBkYXRhIGNhcnJpZWQgd2l0aGluIHRoZW0uDQoNCkVORA0KDQoNCg0KQ2hhbmdlIDQ6IChQ cm9wb3NhbCBmcm9tIEphcmksIHJldmlzZWQgYnkgUmVuZSwgc3VwcG9ydGVkIGJ5IFN0ZWZhbmll KQ0KDQpPTEQ6DQoNCkp1bCAyMDE0IFN1Ym1pdCAiVXNlIGNhc2VzIGFuZCBSZXF1aXJlbWVudHMi ICBhcyBhIFdHIGl0ZW0uDQoNCkp1bCAyMDE1IFN1Ym1pdCDigJxVc2UgY2FzZXMgYW5kIFJlcXVp cmVtZW50c+KAnSBkb2N1bWVudCB0byBJRVNHIGZvciBwdWJsaWNhdGlvbiBhcyBpbmZvcm1hdGlv bmFsIFJGQy4NCg0KDQoNCk5FVw0KDQpEZWMgMjAxNCBTdWJtaXQgIlVzZSBjYXNlcyBhbmQgUmVx dWlyZW1lbnRzIiAgYXMgYSBXRyBpdGVtLg0KDQpBcHIgMjAxNSBPcHRpb25hbGx5LCBzdWJtaXQg IlVzZSBjYXNlcyBhbmQgUmVxdWlyZW1lbnRzIiBkb2N1bWVudCB0byB0aGUgSUVTRyBmb3INCg0K cHVibGljYXRpb24gYXMgYW4gSW5mb3JtYXRpb25hbCBSRkMuDQoNCkVORA0KDQpJIHRoaW5rIHdl IGNvdmVyZWQgYWxsIG9mIHRoZSBJRVNHIHJldmlldyBjb21tZW50cy4NCg0KSWYgdGhlcmUgaXMg YW55IG9wZW4gaXNzdWUsIHBsZWFzZSBsZXQgdXMga25vdy4NCg0KVGhhbmtzLA0KDQpLaW5kIFJl Z2FyZHMNCktlcGVuZw0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0K Q2hhcnRlciBjaGFydGVyLWlldGYtYWNlLTAwLTAyDQpBdXRoZW50aWNhdGlvbiBhbmQgQXV0aG9y aXphdGlvbiBmb3IgQ29uc3RyYWluZWQNCkVudmlyb25tZW50IChBQ0UpDQoNClRoZSBJRVRGIGhh cyByZWNlbnRseSBkZXZlbG9wZWQgcHJvdG9jb2xzIGZvciB1c2UgaW4gY29uc3RyYWluZWQNCmVu dmlyb25tZW50cywgd2hlcmUgbmV0d29yayBub2RlcyBhcmUgbGltaXRlZCBpbiBDUFUsIG1lbW9y eSBhbmQgcG93ZXIuDQpSRVNUIGFyY2hpdGVjdHVyZSBpcyB3aWRlbHkgdXNlZCBmb3Igc3VjaCBj b25zdHJhaW5lZCBlbnZpcm9ubWVudHMuDQpJdCBoYXMgYmVlbiBvYnNlcnZlZCB0aGF0IEludGVy bmV0IHByb3RvY29scyBjYW4gYmUgYXBwbGllZCB0byB0aGVzZQ0KY29uc3RyYWluZWQgZW52aXJv bm1lbnRzLCBvZnRlbiBvbmx5IHJlcXVpcmluZyBtaW5vciB0d2Vha2luZyBhbmQNCnByb2ZpbGlu Zy4gSW4gb3RoZXIgY2FzZXMsIG5ldyBwcm90b2NvbHMgaGF2ZSBiZWVuIGRlZmluZWQgdG8gYWRk cmVzcw0KdGhlIHNwZWNpZmljIHJlcXVpcmVtZW50cyBvZiBjb25zdHJhaW5lZCBlbnZpcm9ubWVu dHMuIEFuIGV4YW1wbGUgb2YNCnN1Y2ggYSBwcm90b2NvbCBpcyB0aGUgQ29uc3RyYWluZWQgQXBw bGljYXRpb24gUHJvdG9jb2wgKENvQVApLg0KDQpBcyBpbiBvdGhlciBlbnZpcm9ubWVudHMsIGF1 dGhlbnRpY2F0aW9uIGFuZCBhdXRob3JpemF0aW9uIHF1ZXN0aW9ucw0KYWxzbyBhcmlzZSBpbiBj b25zdHJhaW5lZCBlbnZpcm9ubWVudHMuIEZvciBleGFtcGxlLCBhIGRvb3IgbG9jayBoYXMgdG8N CmF1dGhvcml6ZSB0aGUgcGVyc29uIHNlZWtpbmcgYWNjZXNzIHVzaW5nIGEgImRpZ2l0YWwga2V5 Ii4gV2hlcmUgaXMgdGhlDQphdXRob3JpemF0aW9uIHBvbGljeSBzdG9yZWQ/IEhvdyBkb2VzIHRo ZSBkaWdpdGFsIGtleSBjb21tdW5pY2F0ZSB3aXRoDQp0aGUgbG9jaz8gRG9lcyB0aGUgbG9jayBp bnRlcmFjdCB3aXRoIGFuIGF1dGhvcml6YXRpb24gc2VydmVyIHRvIG9idGFpbg0KYXV0aG9yaXph dGlvbiBpbmZvcm1hdGlvbj8gSG93IGNhbiBhY2Nlc3MgYmUgdGVtcG9yYXJpbHkgZ3JhbnRlZCB0 bw0Kb3RoZXIgcGVyc29ucz8gSG93IGNhbiBhY2Nlc3MgYmUgcmV2b2tlZD8gVGhlc2UgdHlwZXMg b2YgcXVlc3Rpb25zIGhhdmUNCmJlZW4gYW5zd2VyZWQgYnkgZXhpc3RpbmcgcHJvdG9jb2xzIGZv ciB1c2UgY2FzZXMgb3V0c2lkZSBjb25zdHJhaW5lZA0KZW52aXJvbm1lbnRzLCBob3dldmVyIGlu IGNvbnN0cmFpbmVkIGVudmlyb25tZW50cywgYWRkaXRpb25hbCBhbmQNCmRpZmZlcmVudCByZXF1 aXJlbWVudHMgcG9zZSBjaGFsbGVuZ2VzIGZvciB0aGUgdXNlIG9mIHZhcmlvdXMgc2VjdXJpdHkN CnByb3RvY29scy4gSW4gcGFydGljdWxhciwgdGhlIG5lZWQgYXJpc2VzIGZvciBhIGR5bmFtaWMg YW5kIGZpbmUgZ3JhaW5lZA0KYWNjZXNzIGNvbnRyb2wgbWVjaGFuaXNtLCB3aGVyZSBjbGllbnRz IGFuZC9vciByZXNvdXJjZSBzZXJ2ZXJzIGFyZQ0KY29uc3RyYWluZWQuDQoNClRoZSBJRVRGIGhh cyBhIGxvbmcgaGlzdG9yeSBpbiBkZXZlbG9waW5nIHRocmVlLXBhcnR5IGF1dGhlbnRpY2F0aW9u IGFuZA0KYXV0aG9yaXphdGlvbiBwcm90b2NvbHMgZm9yIGRpc3RyaWJ1dGVkIGVudmlyb25tZW50 cy4gRXhhbXBsZXMgaW5jbHVkZQ0KS2VyYmVyb3MsIHRoZSBQdWJsaWMgS2V5IEluZnJhc3RydWN0 dXJlIChQS0kpLCB0aGUgQXV0aGVudGljYXRpb24sDQpBdXRob3JpemF0aW9uIGFuZCBBY2NvdW50 aW5nIChBQUEpIGluZnJhc3RydWN0dXJlLGFuZCB0aGUgV2ViDQpBdXRob3JpemF0aW9uIFByb3Rv Y29sIChPQXV0aCkuIEFsbCB0aGVzZSBwcm90b2NvbHMgZW5qb3kgd2lkZXNwcmVhZA0KZGVwbG95 bWVudCBvbiB0aGUgSW50ZXJuZXQuIEFsdGhvdWdoIHRoZXkgYWxsIGFpbSB0byBzb2x2ZSBhIHNp bWlsYXINCmdvYWwsIGF0IGFuIGFic3RyYWN0IGxldmVsLCB0aGV5IG9mZmVyIHF1aXRlIGRpZmZl cmVudCBmdW5jdGlvbnMgYW5kDQp1dGlsaXplIGRpZmZlcmVudCBtZXNzYWdlIGV4Y2hhbmdlcy4g VGhlc2UgZGlmZmVyZW5jZXMgcmVzdWx0IGZyb20gdGhlDQptYWluIGRlcGxveW1lbnQgdXNlIGNh c2VzIHRoZXkgd2VyZSBkZXNpZ25lZCBmb3IgcmVzcGVjdGl2ZWx5Lg0KDQpSZXF1aXJlbWVudHMg ZGVyaXZlZCBmcm9tIHVzZSBjYXNlcyBtYXkgaW5kaWNhdGUgdGhhdCBleGlzdGluZyB3b3JrIGlz DQp1c2VmdWwgYXMgYmFzaXMgZm9yIGFzIGEgc29sdXRpb24gZm9yIGNvbnN0cmFpbmVkIGVudmly b25tZW50cy4NClRoZXNlIHByb3RvY29scywNCmhvd2V2ZXIsIHdlcmUgbm90IG9wdGltaXplZCBm b3IgY29uc3RyYWluZWQgZW52aXJvbm1lbnRzLiBBZGRpdGlvbmFsDQpyZXF1aXJlbWVudHMgdGhh dCBuZWVkIHRvIGJlIHRha2VuIGludG8gYWNjb3VudCBhcmUgdGhlIGxhY2sgb2YgYQ0Kc3VpdGFi bGUgdXNlci1pbnRlcmZhY2UgYW5kIHRoZSBpbmFiaWxpdHkgb2YgZW1iZWRkZWQgZGV2aWNlcyB0 byBjb250YWN0DQphbiBhdXRob3JpemF0aW9uIHNlcnZlciBpbiByZWFsLXRpbWUgd2l0aCBldmVy eSByZXNvdXJjZSBhY2Nlc3MgcmVxdWVzdA0KZHVlIHRvIGludGVybWl0dGVudCBjb25uZWN0aXZp dHksIGV0Yy4NCg0KVGhpcyB3b3JraW5nIGdyb3VwIHRoZXJlZm9yZSBhaW1zIHRvIHByb2R1Y2Ug YSBzdGFuZGFyZGl6ZWQgc29sdXRpb24gZm9yDQphdXRoZW50aWNhdGlvbiBhbmQgYXV0aG9yaXph dGlvbiB0byBlbmFibGUgYXV0aG9yaXplZCBhY2Nlc3MgKEdFVCwgUFVULCBQT1NULA0KREVMRVRF KSB0byByZXNvdXJjZXMgaWRlbnRpZmllZCBieSBhIFVSSSBhbmQgaG9zdGVkIG9uIGEgcmVzb3Vy Y2UNCnNlcnZlciBpbiBjb25zdHJhaW5lZCBlbnZpcm9ubWVudHMuIEFzIGEgc3RhcnRpbmcgcG9p bnQsIHRoZSB3b3JraW5nDQpncm91cCB3aWxsIGFzc3VtZSB0aGF0IGFjY2VzcyB0byByZXNvdXJj ZXMgYXQgYSByZXNvdXJjZSBzZXJ2ZXIgYnkgYQ0KY2xpZW50IGRldmljZSB0YWtlcyBwbGFjZSB1 c2luZyBDb0FQIGFuZCBpcyBwcm90ZWN0ZWQgYnkgRFRMUy4gQm90aA0KcmVzb3VyY2Ugc2VydmVy IGFuZCBjbGllbnQgbWF5IGJlIGNvbnN0cmFpbmVkLiBUaGlzIGFjY2VzcyB3aWxsIGJlDQptZWRp YXRlZCBieSBhbiBhdXRob3JpemF0aW9uIHNlcnZlciwgd2hpY2ggaXMgbm90IGNvbnNpZGVyZWQg dG8gYmUNCmNvbnN0cmFpbmVkLg0KDQpFeGlzdGluZyBhdXRoZW50aWNhdGlvbiBhbmQgYXV0aG9y aXphdGlvbiBwcm90b2NvbHMgd2lsbCBiZSBldmFsdWF0ZWQNCmFuZCByZS11c2VkIHdoZXJlIGFw cGxpY2FibGUgdG8gYnVpbGQgdGhlIGNvbnN0cmFpbmVkLWVudmlyb25tZW50IHNvbHV0aW9uLg0K VGhpcyByZXF1aXJlcw0KcmVsZXZhbnQgc3BlY2lmaWNhdGlvbnMgdG8gYmUgcmV2aWV3ZWQgZm9y IHN1aXRhYmlsaXR5LCBzZWxlY3RpbmcgYQ0Kc3Vic2V0IG9mIHRoZW0gYW5kIHJlc3RyaWN0aW5n IHRoZSBvcHRpb25zIHdpdGhpbiBlYWNoIG9mIHRoZQ0Kc3BlY2lmaWNhdGlvbnMuIFNvbWUgZnVu Y3Rpb25hbGl0eSwgaG93ZXZlciwgbWF5IG5vdCBiZSBhdmFpbGFibGUgaW4NCmV4aXN0aW5nIHBy b3RvY29scywgaW4gd2hpY2ggY2FzZSB0aGUgc29sdXRpb24gbWF5IGFsc28gaW52b2x2ZSBuZXcN CnByb3RvY29sIHdvcmsuIExldmVyYWdpbmcgZXhpc3Rpbmcgd29yayBtZWFucyB0aGUgd29ya2lu ZyBncm91cCBiZW5lZml0cw0KZnJvbSBhdmFpbGFibGUgc2VjdXJpdHkgYW5hbHlzaXMsIGltcGxl bWVudGF0aW9uLCBhbmQgZGVwbG95bWVudA0KZXhwZXJpZW5jZS4gTW9yZW92ZXIsIGEgc3RhbmRh cmRpemVkIHNvbHV0aW9uIGZvciBmZWRlcmF0ZWQNCmF1dGhlbnRpY2F0aW9uIGFuZCBhdXRob3Jp emF0aW9uIHdpbGwgaGVscCB0byBzdGltdWxhdGUgdGhlIGRlcGxveW1lbnQNCm9mIGNvbnN0cmFp bmVkIGRldmljZXMgdGhhdCBwcm92aWRlIGluY3JlYXNlZCBzZWN1cml0eS4NCg0KT25jZSBwcm9n cmVzcyBpbiBpZGVudGlmeWluZyBzdWl0YWJsZSBjYW5kaWRhdGUgc29sdXRpb25zIGhhcyBiZWVu IG1hZGUsDQp0aGUgd29ya2luZyBncm91cCB3aWxsIHZlcmlmeSB3aGV0aGVyIHRoZSBzYW1lIG1l Y2hhbmlzbXMgYXJlIGFsc28NCmFwcGxpY2FibGUgYmV5b25kIHRoZSB1c2Ugb2YgQ29BUCBhbmQg RFRMUywgd2hpY2ggYXJlIHRoZSB0d28gbWFpbg0KcHJvdG9jb2xzIHRoZSBncm91cCB3aWxsIGZv Y3VzIG9uIGZvciBhY2Nlc3MgdG8gcmVzb3VyY2VzLiBJbg0KcGFydGljdWxhciwgdGhlIGFiaWxp dHkgdG8gdXNlIHRoZSBkZXZlbG9wZWQgc29sdXRpb24gb3ZlciBIVFRQIGFuZCBUTFMNCndpbGwg YmUgaW52ZXN0aWdhdGVkLiBOb3RlIHRoYXQgdGhlIGluaXRpYWwgZm9jdXMgaXMgb24gQ29BUCBh bmQgSFRUUCB3aXRoIERUTFMgYW5kIFRMUy4NCk90aGVyIHNlY3VyaXR5IHByb3RvY29scyBtYXkg YmUgY29uc2lkZXJlZCBhcyBsb25nIGFzIHRoZSBwcmltYXJ5IGZvY3VzIGlzIG1haW50YWluZWQu DQpUaGUgZ3JvdXAgaXMgc2NvcGVkIHRvIHdvcmsgb25seSBvbiB0aGUgd2ViIHByb3RvY29scyBh bmQgZGF0YSBjYXJyaWVkIHdpdGhpbiB0aGVtLg0KRnVydGhlcm1vcmUsIHRvIGd1YXJhbnRlZSBz bW9vdGggdHJhbnNpdGlvbiwgdGhlDQppbnRlZ3JhdGlvbiB3aXRoIGV4aXN0aW5nIGRlcGxveW1l bnRzIHdpbGwgYmUgc3R1ZGllZCwgcGFydGljdWxhcmx5DQpjb25jZXJuaW5nIHRoZSB1c2Ugb2Yg cHJvdG9jb2wgdHJhbnNsYXRpb24gcHJveGllcy4NCg0KVGhpcyB3b3JrIGRvZXMgbm90IG1ha2Ug dGhlIGFzc3VtcHRpb24gdGhhdCB0aGUgcGFydHkgb2ZmZXJpbmcNCmFwcGxpY2F0aW9uIGxheWVy IHNlcnZpY2VzIGlzIGFsd2F5cyB0aGUgc2FtZSBwYXJ0eSBvZmZlcmluZyBuZXR3b3JrDQphY2Nl c3Mgc2VydmljZXMuDQoNClRoZSB3b3JraW5nIGdyb3VwIGhhcyB0aGUgZm9sbG93aW5nIHRhc2tz Og0KDQoxKSBQcm9kdWNlIHVzZSBjYXNlcyBhbmQgcmVxdWlyZW1lbnRzDQoNCjIpIElkZW50aWZ5 IGF1dGhlbnRpY2F0aW9uIGFuZCBhdXRob3JpemF0aW9uIG1lY2hhbmlzbXMgc3VpdGFibGUgZm9y DQpyZXNvdXJjZSBhY2Nlc3MgaW4gY29uc3RyYWluZWQgZW52aXJvbm1lbnRzLg0KDQpNaWxlc3Rv bmVzOg0KDQpEZWMgMjAxNCBTdWJtaXQgIlVzZSBjYXNlcyBhbmQgUmVxdWlyZW1lbnRzIiBhcyBh IFdHIGl0ZW0uDQpEZWMgMjAxNCBTdWJtaXQgIkF1dGhlbnRpY2F0aW9uIGFuZCBBdXRob3JpemF0 aW9uIFNvbHV0aW9uIiBhcyBhIFdHIGl0ZW0uDQpBcHIgMjAxNSBPcHRpb25hbGx5LCBzdWJtaXQg IlVzZSBjYXNlcyBhbmQgUmVxdWlyZW1lbnRzIiBkb2N1bWVudA0KdG8gdGhlIElFU0cgZm9yIHB1 YmxpY2F0aW9uIGFzIGFuIEluZm9ybWF0aW9uYWwgUkZDLg0KSnVsIDIwMTYgU3VibWl0ICJBdXRo ZW50aWNhdGlvbiBhbmQgQXV0aG9yaXphdGlvbiBTb2x1dGlvbiINCnNwZWNpZmljYXRpb24gdG8g dGhlIElFU0cgZm9yIHB1YmxpY2F0aW9uIGFzIGEgUHJvcG9zZWQgU3RhbmRhcmQuDQoNClByb3Bv c2VkIE1pbGVzdG9uZXMNCk5vIG1pbGVzdG9uZXMgZm9yIGNoYXJ0ZXIgZm91bmQuDQoNCg0KDQrl j5Hku7bkuro6IEthdGhsZWVuIE1vcmlhcnR5IFttYWlsdG86a2F0aGxlZW4ubW9yaWFydHkuaWV0 ZkBnbWFpbC5jb208bWFpbHRvOmthdGhsZWVuLm1vcmlhcnR5LmlldGZAZ21haWwuY29tPl0NCuWP kemAgeaXtumXtDogMjAxNOW5tDbmnIgz5pelIDE0OjMwDQrmlLbku7bkuro6IExpa2VwZW5nDQrm ioTpgIE6IEJlbm9pdCBDbGFpc2U7IGFkcmlhbkBvbGRkb2cuY28udWs8bWFpbHRvOmFkcmlhbkBv bGRkb2cuY28udWs+OyBhYWEtZG9jdG9yc0BpZXRmLm9yZzxtYWlsdG86YWFhLWRvY3RvcnNAaWV0 Zi5vcmc+OyBUaGUgSUVTRzsgYWNlQGlldGYub3JnPG1haWx0bzphY2VAaWV0Zi5vcmc+DQrkuLvp opg6IFJlOiBSZXZpc2VkIGNoYXJ0ZXIgcHJvcG9zYWw6IGNoYXJ0ZXItaWV0Zi1hY2UtMDAtMDIN Cg0KSGkgS2VwZW5nLA0KDQpJZiB3ZSBhcmUgYXQgYSBwb2ludCB3aGVyZSBJIGNhbiB1cGRhdGUg dGhlIGNoYXJ0ZXIsIHNlZW1zIHRoYXQgd2F5LCBwbGVhc2Ugc2VuZCB0aGUgbGF0ZXN0IHZlcnNp b24gdGhhdCBoYXMgYmVlbiBhZ3JlZWQgdXBvbiBhbmQgSSdsbCB0YWtlIGNhcmUgb2YgdGhlIHVw ZGF0ZS4NCg0KVGhhbmtzLg0KDQpPbiBUdWUsIEp1biAzLCAyMDE0IGF0IDY6MzEgQU0sIExpa2Vw ZW5nIDxsaWtlcGVuZ0BodWF3ZWkuY29tPG1haWx0bzpsaWtlcGVuZ0BodWF3ZWkuY29tPj4gd3Jv dGU6DQpIaSBCZW5vaXQsDQoNCj5Ob3Qgb25seSB3b3VsZCBJIGtlZXAgIkFBQSIsDQoNCk9LLg0K DQo+YnV0IEkgd291bGQgcHJvcG9zZQ0KDQo+T0xEOg0KPkV4aXN0aW5nIGF1dGhlbnRpY2F0aW9u IGFuZCBhdXRob3JpemF0aW9uIHByb3RvY29scyB3aWxsIGJlIHVzZWQgd2hlcmUNCmFwcGxpY2Fi bGUgdG8gYnVpbGQgdGhlIGNvbnN0cmFpbmVkLWVudmlyb25tZW50IHNvbHV0aW9uLg0KDQo+TkVX Og0KRXhpc3RpbmcgYXV0aGVudGljYXRpb24gYW5kIGF1dGhvcml6YXRpb24gcHJvdG9jb2xzIHdp bGwgYmUgZXZhbHVhdGVkIGFuZCByZS11c2VkIHdoZXJlDQphcHBsaWNhYmxlIHRvIGJ1aWxkIHRo ZSBjb25zdHJhaW5lZC1lbnZpcm9ubWVudCBzb2x1dGlvbi4NCg0KT0ssIGZpbmUgd2l0aCBtZS4N Cg0KVGhhbmtzIGZvciB0aGUgZmVlZGJhY2suDQoNCktpbmQgUmVnYXJkcw0KS2VwZW5nDQoNCuWP keS7tuS6ujogQmVub2l0IENsYWlzZSBbbWFpbHRvOmJjbGFpc2VAY2lzY28uY29tPG1haWx0bzpi Y2xhaXNlQGNpc2NvLmNvbT5dDQrlj5HpgIHml7bpl7Q6IDIwMTTlubQ25pyIM+aXpSAxMjoxNg0K 5pS25Lu25Lq6OiBMaWtlcGVuZzsgS2F0aGxlZW4gTW9yaWFydHk7IGFkcmlhbkBvbGRkb2cuY28u dWs8bWFpbHRvOmFkcmlhbkBvbGRkb2cuY28udWs+DQrmioTpgIE6IGFhYS1kb2N0b3JzQGlldGYu b3JnPG1haWx0bzphYWEtZG9jdG9yc0BpZXRmLm9yZz47IFRoZSBJRVNHOyBhY2VAaWV0Zi5vcmc8 bWFpbHRvOmFjZUBpZXRmLm9yZz4NCuS4u+mimDogUmU6IFJldmlzZWQgY2hhcnRlciBwcm9wb3Nh bDogY2hhcnRlci1pZXRmLWFjZS0wMC0wMg0KDQpIaSwNCg0KSGVsbG8gYWxsLA0KDQoNCg0KQmFz ZWQgb24gcmVjZW50IGRpc2N1c3Npb25zLCBJIG1hZGUgYSByZXZpc2VkIGNoYXJ0ZXIgcHJvcG9z YWwsIGFzIGluY2x1ZGVkIGluIHRoaXMgZW1haWwsIG5vdCBvbiB0aGUgd2VicGFnZSB5ZXQuDQoN Cg0KDQpQbGVhc2UgdGFrZSBhIGxvb2sgYW5kIGxldCB1cyBrbm93IGlmIHlvdSBoYXZlIGFueSBm dXJ0aGVyIGNvbW1lbnRzLg0KDQoNCg0KQEFkcmlhbiBhbmQgQEJlbm9pdCwgcGxlYXNlIGNoZWNr IGlmIHRoZSBwcm9wb3NlZCB0ZXh0cyBjYW4gcmVzb2x2ZSB5b3VyIGNvbW1lbnRzLg0KDQoNCg0K VGhhbmtzLA0KDQpLaW5kIFJlZ2FyZHMNCg0KS2VwZW5nDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCkNvbXBhcmVkIHdpdGggY2hhcnRlci1pZXRm LWFjZS0wMC0wMSBvbiB0aGUgd2VicGFnZSwgdGhlIGNoYW5nZXMgYXJlOg0KDQoNCg0KKDEpICAg ICAgQWRkIG9uZSBjbGFyaWZpY2F0aW9uIHNlbnRlbmNlIGFib3V0IFJFU1QgYXJjaGl0ZWN0dXJl Og0KDQpPTEQNCg0KVGhlIElFVEYgaGFzIHJlY2VudGx5IGRldmVsb3BlZCBwcm90b2NvbHMgZm9y IHVzZSBpbiBjb25zdHJhaW5lZA0KDQplbnZpcm9ubWVudHMsIHdoZXJlIG5ldHdvcmsgbm9kZXMg YXJlIGxpbWl0ZWQgaW4gQ1BVLCBtZW1vcnkgYW5kIHBvd2VyLg0KDQpSRVNUIGFyY2hpdGVjdHVy ZSBpcyB3aWRlbHkgdXNlZCBmb3Igc3VjaCBjb25zdHJhaW5lZCBlbnZpcm9ubWVudHMuDQoNCg0K DQpORVcNCg0KVGhlIElFVEYgaGFzIHJlY2VudGx5IGRldmVsb3BlZCBwcm90b2NvbHMgZm9yIHVz ZSBpbiBjb25zdHJhaW5lZA0KDQplbnZpcm9ubWVudHMsIHdoZXJlIG5ldHdvcmsgbm9kZXMgYXJl IGxpbWl0ZWQgaW4gQ1BVLCBtZW1vcnkgYW5kIHBvd2VyLg0KDQpSRVNUIGFyY2hpdGVjdHVyZSBp cyB3aWRlbHkgdXNlZCBmb3Igc3VjaCBjb25zdHJhaW5lZCBlbnZpcm9ubWVudHMuDQoNCkVORA0K Q29uc2lkZXJpbmcgdGhhdCBPTEQgaXMNCg0KT0xEDQoNClRoZSBJRVRGIGhhcyByZWNlbnRseSBk ZXZlbG9wZWQgcHJvdG9jb2xzIGZvciB1c2UgaW4gY29uc3RyYWluZWQNCg0KZW52aXJvbm1lbnRz LCB3aGVyZSBuZXR3b3JrIG5vZGVzIGFyZSBsaW1pdGVkIGluIENQVSwgbWVtb3J5IGFuZCBwb3dl ci4NCi4uLiBmaW5lIHdpdGggbWUNCg0KDQoNCg0KDQooMikgICAgIFJlbW92ZSDigJxBQUEgcHJv dG9jb2zigJ0gZnJvbSB0aGUgY2hhcnRlcjoNCg0KT0xEDQoNClRoZSBJRVRGIGhhcyBhIGxvbmcg aGlzdG9yeSBpbiBkZXZlbG9waW5nIHRocmVlLXBhcnR5IGF1dGhlbnRpY2F0aW9uIGFuZA0KDQph dXRob3JpemF0aW9uIHByb3RvY29scyBmb3IgZGlzdHJpYnV0ZWQgZW52aXJvbm1lbnRzLiBFeGFt cGxlcyBpbmNsdWRlDQoNCktlcmJlcm9zLCB0aGUgUHVibGljIEtleSBJbmZyYXN0cnVjdHVyZSAo UEtJKSwgdGhlIEF1dGhlbnRpY2F0aW9uLA0KDQpBdXRob3JpemF0aW9uIGFuZCBBY2NvdW50aW5n IChBQUEpIGluZnJhc3RydWN0dXJlLCBhbmQgdGhlIFdlYg0KDQpBdXRob3JpemF0aW9uIFByb3Rv Y29sIChPQXV0aCkuDQoNCg0KDQpORVcNCg0KVGhlIElFVEYgaGFzIGEgbG9uZyBoaXN0b3J5IGlu IGRldmVsb3BpbmcgdGhyZWUtcGFydHkgYXV0aGVudGljYXRpb24gYW5kDQoNCmF1dGhvcml6YXRp b24gcHJvdG9jb2xzIGZvciBkaXN0cmlidXRlZCBlbnZpcm9ubWVudHMuIEV4YW1wbGVzIGluY2x1 ZGUNCg0KS2VyYmVyb3MsIHRoZSBQdWJsaWMgS2V5IEluZnJhc3RydWN0dXJlIChQS0kpLCBhbmQg dGhlIFdlYiBBdXRob3JpemF0aW9uIFByb3RvY29sIChPQXV0aCkuDQoNCkVORA0KV2UgaGF2ZSBB QUEtZG9jdG9ycyB0ZWxsaW5nOiBtYXliZSBSQURJVVMgaXMgYXBwbGljYWJsZT8NClBlcnNvbmFs bHksIEkgZG9uJ3Qga25vdyBhbmQgaXQgZG9lc24ndCBtYXR0ZXIgYXQgdGhpcyBwb2ludC4NCldl IHJlY2VpdmVkIGZlZWRiYWNrIHN1Y2ggYXM6DQpMZXQncyBiZSBjbGVhciBoZXJlOiBJdCB3YXMg bmV2ZXIgc2FpZCAoaW4gdGhlIGNoYXJ0ZXIgb3IgYW55d2hlcmUgZWxzZSBpbiB0aGUgZ3JvdXAg dG8gbXkga25vd2xlZGdlKSB0aGF0IFJBRElVUyAob3IgaW5kZWVkIGFueSBvdGhlciBBQUEgcHJv dG9jb2wpIHdvdWxkIG5vdCBydW4gb24gY29uc3RyYWluZWQgZGV2aWNlcyAoUkZDIDcyMjgpLiBU aGUgY2hhcnRlciBzaW1wbHkgc2FpZCB0aGUgcHJvdG9jb2xzIHdlcmUgbm90IG9wdGltaXNlZCBm b3IgY29uc3RyYWluZWQgZGV2aWNlcy4gVGhhdCBkb2VzIG5vdCBwcmVjbHVkZSBjb25zaWRlcmlu ZyBhbnkgcHJvdG9jb2wgZm9yIHN1aXRhYmlsaXR5IGZvciBjb25zdHJhaW5lZCBkZXZpY2VzIGVp dGhlciBhKSBhcyBpcywgYikgaW4gYSByZXN0cmljdGVkIHdheSBvciBjKSBpbiBhbiBhZGFwdGVk IHdheS4NCg0KU28sIGF0IHRoaXMgc3RhZ2UsIEkgZG9uJ3QgdGhpbmsgYW55IHByb3RvY29scyBz aG91bGQgYmUgZXhjbHVkZWQgZnJvbSBjb25zaWRlcmF0aW9uIGFuZCBzaG91bGQgY2VydGFpbmx5 IG5vdCBiZSBlbGltaW5hdGVkIG9uIGEgaHVuY2ggdGhhdCB0aGV5IG1pZ2h0IGJlICJ0b28gYmln Ii4gTGV0J3MgZG8gdGhlIGFzc2Vzc21lbnQgcHJvcGVybHkgYXQgdGhlIGFwcHJvcHJpYXRlIHRp bWUuIEFzIGEgcmVtaW5kZXIgLSB0aGUgZm9jdXMgbm93IGlzIHRvIGNvbXBsZXRlIHRoZSBjaGFy dGVyLg0KT3INCg0KPj5UaGUgQ2hhcnRlciBtYWtlcyBhIG51bWJlciBvZiBhc3NlcnRpb25zIHRo YXQgYXJlIHByb3ZhYmx5IGZhbHNlLCBzdWNoIGFzIHRoYXQgQUFBIHByb3RvY29scyBhcmUgaW5h cHByb3ByaWF0ZSBmb3IgY29uc3RyYWluZWQgZW52aXJvbm1lbnRzLg0KDQpJbiBmYWN0LCB0aGUg Y2hhcnRlciBkb2VzIG5vdCBzYXkgdGhhdC4gQnV0IHRvIGF2b2lkIGNvbmZ1c2lvbiwgbGV0J3Mg cmVtb3ZlIEFBQSBwcm90b2NvbCBmcm9tIHRoZSBjaGFydGVyLg0KDQoNCg0KSW4gdGhlIGNoYXJ0 ZXIsIHdlIG1lbnRpb25lZCB0aGF0IHdlIHdhbnQgdG8gcmV1c2UgZXhpc3RpbmcgYXV0aGVudGlj YXRpb24gYW5kIGF1dGhvcml6YXRpb24gcHJvdG9jb2xzIHdoZXJlIGFwcGxpY2FibGUgdG8gYnVp bGQgdGhlIGNvbnN0cmFpbmVkLWVudmlyb25tZW50IHNvbHV0aW9uLg0KLi4uIHdoaWNoIEkgcmVh ZCBhczogbGV0J3MgY29uc2lkZXIgdGhlIEFBQSBwcm90b2NvbHMsIGFuZCBldmFsdWF0ZSBpZiB0 aGV5IHdvdWxkIHdvcmsgaW4gY29uc3RyYWluZWQgZGV2aWNlcy4NCkkgZG9uJ3QgdW5kZXJzdGFu ZCB0aGUgbG9naWM6IHdoeSBkbyB5b3Ugd2FudCB0byByZW1vdmUgQUFBIGZyb20gdGhlIGNoYXJ0 ZXI/DQpOb3Qgb25seSB3b3VsZCBJIGtlZXAgIkFBQSIsIGJ1dCBJIHdvdWxkIHByb3Bvc2UNCg0K T0xEOg0KRXhpc3RpbmcgYXV0aGVudGljYXRpb24gYW5kIGF1dGhvcml6YXRpb24gcHJvdG9jb2xz IHdpbGwgYmUgdXNlZCB3aGVyZQ0KYXBwbGljYWJsZSB0byBidWlsZCB0aGUgY29uc3RyYWluZWQt ZW52aXJvbm1lbnQgc29sdXRpb24NCg0KTkVXOg0KRXhpc3RpbmcgYXV0aGVudGljYXRpb24gYW5k IGF1dGhvcml6YXRpb24gcHJvdG9jb2xzIHdpbGwgYmUgZXZhbHVhdGVkIGFuZCByZS11c2VkIHdo ZXJlDQphcHBsaWNhYmxlIHRvIGJ1aWxkIHRoZSBjb25zdHJhaW5lZC1lbnZpcm9ubWVudCBzb2x1 dGlvbg0KDQpSZWdhcmRzLCBCZW5vaXQNCg0KDQoNCg0KDQooMykgQ2xhcmlmeSB0aGUgc2NvcGU6 DQoNCk9MRDoNCg0KTm90ZSB0aGF0IHRoZSBpbml0aWFsIGZvY3VzIGlzIG9uIENvQVAgYW5kIEhU VFAgd2l0aCBEVExTIGFuZCBUTFMuDQoNCk90aGVyIHNlY3VyaXR5IHByb3RvY29scyBtYXkgYmUg Y29uc2lkZXJlZCBhcyBsb25nIGFzIHRoZSBwcmltYXJ5IGZvY3VzIGlzIG1haW50YWluZWQuDQoN Ck90aGVyIGFwcGxpY2F0aW9uIHByb3RvY29scyBhbmQgcHJvdG9jb2xzIGF0IG90aGVyIGxheWVy cyBpbiB0aGUgc3RhY2sgYXJlIG91dCBvZiBzY29wZS4NCg0KDQoNCk5FVw0KDQpOb3RlIHRoYXQg dGhlIGluaXRpYWwgZm9jdXMgaXMgb24gQ29BUCBhbmQgSFRUUCB3aXRoIERUTFMgYW5kIFRMUy4N Cg0KT3RoZXIgc2VjdXJpdHkgcHJvdG9jb2xzIG1heSBiZSBjb25zaWRlcmVkIGFzIGxvbmcgYXMg dGhlIHByaW1hcnkgZm9jdXMgaXMgbWFpbnRhaW5lZC4NCg0KVGhlIGdyb3VwIGlzIHNjb3BlZCB0 byB3b3JrIG9ubHkgb24gdGhlIHdlYiBwcm90b2NvbHMgYW5kIGRhdGEgY2FycmllZCB3aXRoaW4g dGhlbS4NCg0KRU5EDQoNCg0KDQooNCkgICAgIFVwZGF0ZSBtaWxlc3RvbmVzIGZvciB0aGUgdXNl IGNhc2UgJiByZXF1aXJlbWVudHMgZG9jdW1lbnQ6DQoNCk9MRDoNCg0KSnVsIDIwMTUgU3VibWl0 IOKAnFVzZSBjYXNlcyBhbmQgUmVxdWlyZW1lbnRz4oCdIGRvY3VtZW50IHRvIElFU0cgZm9yIHB1 YmxpY2F0aW9uIGFzIGluZm9ybWF0aW9uYWwgUkZDLg0KDQoNCg0KTkVXDQoNCkRlYyAyMDE0IE9w dGlvbmFsbHksIHN1Ym1pdCAiVXNlIGNhc2VzIGFuZCBSZXF1aXJlbWVudHMiIGRvY3VtZW50IHRv IHRoZSBJRVNHIGZvciBwdWJsaWNhdGlvbiBhcyBhbiBJbmZvcm1hdGlvbmFsIFJGQy4NCg0KRU5E DQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQoNCkNoYXJ0ZXIgY2hhcnRlci1pZXRmLWFjZS0wMC0wMg0KDQpBdXRoZW50aWNh dGlvbiBhbmQgQXV0aG9yaXphdGlvbiBmb3IgQ29uc3RyYWluZWQNCg0KRW52aXJvbm1lbnQgKEFD RSkNCg0KDQoNClRoZSBJRVRGIGhhcyByZWNlbnRseSBkZXZlbG9wZWQgcHJvdG9jb2xzIGZvciB1 c2UgaW4gY29uc3RyYWluZWQNCg0KZW52aXJvbm1lbnRzLCB3aGVyZSBuZXR3b3JrIG5vZGVzIGFy ZSBsaW1pdGVkIGluIENQVSwgbWVtb3J5IGFuZCBwb3dlci4NCg0KUkVTVCBhcmNoaXRlY3R1cmUg aXMgd2lkZWx5IHVzZWQgZm9yIHN1Y2ggY29uc3RyYWluZWQgZW52aXJvbm1lbnRzLg0KDQpJdCBo YXMgYmVlbiBvYnNlcnZlZCB0aGF0IEludGVybmV0IHByb3RvY29scyBjYW4gYmUgYXBwbGllZCB0 byB0aGVzZQ0KDQpjb25zdHJhaW5lZCBlbnZpcm9ubWVudHMsIG9mdGVuIG9ubHkgcmVxdWlyaW5n IG1pbm9yIHR3ZWFraW5nIGFuZA0KDQpwcm9maWxpbmcuIEluIG90aGVyIGNhc2VzLCBuZXcgcHJv dG9jb2xzIGhhdmUgYmVlbiBkZWZpbmVkIHRvIGFkZHJlc3MNCg0KdGhlIHNwZWNpZmljIHJlcXVp cmVtZW50cyBvZiBjb25zdHJhaW5lZCBlbnZpcm9ubWVudHMuIEFuIGV4YW1wbGUgb2YNCg0Kc3Vj aCBhIHByb3RvY29sIGlzIHRoZSBDb25zdHJhaW5lZCBBcHBsaWNhdGlvbiBQcm90b2NvbCAoQ29B UCkuDQoNCg0KDQpBcyBpbiBvdGhlciBlbnZpcm9ubWVudHMsIGF1dGhlbnRpY2F0aW9uIGFuZCBh dXRob3JpemF0aW9uIHF1ZXN0aW9ucw0KDQphbHNvIGFyaXNlIGluIGNvbnN0cmFpbmVkIGVudmly b25tZW50cy4gRm9yIGV4YW1wbGUsIGEgZG9vciBsb2NrIGhhcyB0bw0KDQphdXRob3JpemUgdGhl IHBlcnNvbiBzZWVraW5nIGFjY2VzcyB1c2luZyBhICJkaWdpdGFsIGtleSIuIFdoZXJlIGlzIHRo ZQ0KDQphdXRob3JpemF0aW9uIHBvbGljeSBzdG9yZWQ/IEhvdyBkb2VzIHRoZSBkaWdpdGFsIGtl eSBjb21tdW5pY2F0ZSB3aXRoDQoNCnRoZSBsb2NrPyBEb2VzIHRoZSBsb2NrIGludGVyYWN0IHdp dGggYW4gYXV0aG9yaXphdGlvbiBzZXJ2ZXIgdG8gb2J0YWluDQoNCmF1dGhvcml6YXRpb24gaW5m b3JtYXRpb24/IEhvdyBjYW4gYWNjZXNzIGJlIHRlbXBvcmFyaWx5IGdyYW50ZWQgdG8NCg0Kb3Ro ZXIgcGVyc29ucz8gSG93IGNhbiBhY2Nlc3MgYmUgcmV2b2tlZD8gVGhlc2UgdHlwZXMgb2YgcXVl c3Rpb25zIGhhdmUNCg0KYmVlbiBhbnN3ZXJlZCBieSBleGlzdGluZyBwcm90b2NvbHMgZm9yIHVz ZSBjYXNlcyBvdXRzaWRlIGNvbnN0cmFpbmVkDQoNCmVudmlyb25tZW50cywgaG93ZXZlciBpbiBj b25zdHJhaW5lZCBlbnZpcm9ubWVudHMsIGFkZGl0aW9uYWwgYW5kDQoNCmRpZmZlcmVudCByZXF1 aXJlbWVudHMgcG9zZSBjaGFsbGVuZ2VzIGZvciB0aGUgdXNlIG9mIHZhcmlvdXMgc2VjdXJpdHkN Cg0KcHJvdG9jb2xzLiBJbiBwYXJ0aWN1bGFyLCB0aGUgbmVlZCBhcmlzZXMgZm9yIGEgZHluYW1p YyBhbmQgZmluZSBncmFpbmVkDQoNCmFjY2VzcyBjb250cm9sIG1lY2hhbmlzbSwgd2hlcmUgY2xp ZW50cyBhbmQvb3IgcmVzb3VyY2Ugc2VydmVycyBhcmUNCg0KY29uc3RyYWluZWQuDQoNCg0KDQpU aGUgSUVURiBoYXMgYSBsb25nIGhpc3RvcnkgaW4gZGV2ZWxvcGluZyB0aHJlZS1wYXJ0eSBhdXRo ZW50aWNhdGlvbiBhbmQNCg0KYXV0aG9yaXphdGlvbiBwcm90b2NvbHMgZm9yIGRpc3RyaWJ1dGVk IGVudmlyb25tZW50cy4gRXhhbXBsZXMgaW5jbHVkZQ0KDQpLZXJiZXJvcywgdGhlIFB1YmxpYyBL ZXkgSW5mcmFzdHJ1Y3R1cmUgKFBLSSksIGFuZCB0aGUgV2ViDQoNCkF1dGhvcml6YXRpb24gUHJv dG9jb2wgKE9BdXRoKS4gQWxsIHRoZXNlIHByb3RvY29scyBlbmpveSB3aWRlc3ByZWFkDQoNCmRl cGxveW1lbnQgb24gdGhlIEludGVybmV0LiBBbHRob3VnaCB0aGV5IGFsbCBhaW0gdG8gc29sdmUg YSBzaW1pbGFyDQoNCmdvYWwsIGF0IGFuIGFic3RyYWN0IGxldmVsLCB0aGV5IG9mZmVyIHF1aXRl IGRpZmZlcmVudCBmdW5jdGlvbnMgYW5kDQoNCnV0aWxpemUgZGlmZmVyZW50IG1lc3NhZ2UgZXhj aGFuZ2VzLiBUaGVzZSBkaWZmZXJlbmNlcyByZXN1bHQgZnJvbSB0aGUNCg0KbWFpbiBkZXBsb3lt ZW50IHVzZSBjYXNlcyB0aGV5IHdlcmUgZGVzaWduZWQgZm9yIHJlc3BlY3RpdmVseS4NCg0KDQoN ClJlcXVpcmVtZW50cyBkZXJpdmVkIGZyb20gdXNlIGNhc2VzIGluZGljYXRlIHRoZSBzdWl0YWJp bGl0eSBvZiBleGlzdGluZw0KDQp3b3JrIGFzIGEgc29sdXRpb24gZm9yIGNvbnN0cmFpbmVkIGVu dmlyb25tZW50cy4gVGhlc2UgcHJvdG9jb2xzLA0KDQpob3dldmVyLCB3ZXJlIG5vdCBvcHRpbWl6 ZWQgZm9yIGNvbnN0cmFpbmVkIGVudmlyb25tZW50cy4gQWRkaXRpb25hbA0KDQpyZXF1aXJlbWVu dHMgdGhhdCBuZWVkIHRvIGJlIHRha2VuIGludG8gYWNjb3VudCBhcmUgdGhlIGxhY2sgb2YgYQ0K DQpzdWl0YWJsZSB1c2VyLWludGVyZmFjZSBhbmQgdGhlIGluYWJpbGl0eSBvZiBlbWJlZGRlZCBk ZXZpY2VzIHRvIGNvbnRhY3QNCg0KYW4gYXV0aG9yaXphdGlvbiBzZXJ2ZXIgaW4gcmVhbC10aW1l IHdpdGggZXZlcnkgcmVzb3VyY2UgYWNjZXNzIHJlcXVlc3QNCg0KZHVlIHRvIGludGVybWl0dGVu dCBjb25uZWN0aXZpdHksIGV0Yy4NCg0KDQoNClRoaXMgd29ya2luZyBncm91cCB0aGVyZWZvcmUg YWltcyB0byBwcm9kdWNlIGEgc3RhbmRhcmRpemVkIHNvbHV0aW9uIGZvcg0KDQphdXRoZW50aWNh dGlvbiBhbmQgYXV0aG9yaXphdGlvbiB0byBlbmFibGUgYXV0aG9yaXplZCBhY2Nlc3MgKEdFVCwg UFVULCBQT1NULA0KDQpERUxFVEUpIHRvIHJlc291cmNlcyBpZGVudGlmaWVkIGJ5IGEgVVJJIGFu ZCBob3N0ZWQgb24gYSByZXNvdXJjZQ0KDQpzZXJ2ZXIgaW4gY29uc3RyYWluZWQgZW52aXJvbm1l bnRzLiBBcyBhIHN0YXJ0aW5nIHBvaW50LCB0aGUgd29ya2luZw0KDQpncm91cCB3aWxsIGFzc3Vt ZSB0aGF0IGFjY2VzcyB0byByZXNvdXJjZXMgYXQgYSByZXNvdXJjZSBzZXJ2ZXIgYnkgYQ0KDQpj bGllbnQgZGV2aWNlIHRha2VzIHBsYWNlIHVzaW5nIENvQVAgYW5kIGlzIHByb3RlY3RlZCBieSBE VExTLiBCb3RoDQoNCnJlc291cmNlIHNlcnZlciBhbmQgY2xpZW50IG1heSBiZSBjb25zdHJhaW5l ZC4gVGhpcyBhY2Nlc3Mgd2lsbCBiZQ0KDQptZWRpYXRlZCBieSBhbiBhdXRob3JpemF0aW9uIHNl cnZlciwgd2hpY2ggaXMgbm90IGNvbnNpZGVyZWQgdG8gYmUNCg0KY29uc3RyYWluZWQuDQoNCg0K DQpFeGlzdGluZyBhdXRoZW50aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlvbiBwcm90b2NvbHMgd2ls bCBiZSB1c2VkIHdoZXJlDQoNCmFwcGxpY2FibGUgdG8gYnVpbGQgdGhlIGNvbnN0cmFpbmVkLWVu dmlyb25tZW50IHNvbHV0aW9uLiBUaGlzIHJlcXVpcmVzDQoNCnJlbGV2YW50IHNwZWNpZmljYXRp b25zIHRvIGJlIHJldmlld2VkIGZvciBzdWl0YWJpbGl0eSwgc2VsZWN0aW5nIGENCg0Kc3Vic2V0 IG9mIHRoZW0gYW5kIHJlc3RyaWN0aW5nIHRoZSBvcHRpb25zIHdpdGhpbiBlYWNoIG9mIHRoZQ0K DQpzcGVjaWZpY2F0aW9ucy4gU29tZSBmdW5jdGlvbmFsaXR5LCBob3dldmVyLCBtYXkgbm90IGJl IGF2YWlsYWJsZSBpbg0KDQpleGlzdGluZyBwcm90b2NvbHMsIGluIHdoaWNoIGNhc2UgdGhlIHNv bHV0aW9uIG1heSBhbHNvIGludm9sdmUgbmV3DQoNCnByb3RvY29sIHdvcmsuIExldmVyYWdpbmcg ZXhpc3Rpbmcgd29yayBtZWFucyB0aGUgd29ya2luZyBncm91cCBiZW5lZml0cw0KDQpmcm9tIGF2 YWlsYWJsZSBzZWN1cml0eSBhbmFseXNpcywgaW1wbGVtZW50YXRpb24sIGFuZCBkZXBsb3ltZW50 DQoNCmV4cGVyaWVuY2UuIE1vcmVvdmVyLCBhIHN0YW5kYXJkaXplZCBzb2x1dGlvbiBmb3IgZmVk ZXJhdGVkDQoNCmF1dGhlbnRpY2F0aW9uIGFuZCBhdXRob3JpemF0aW9uIHdpbGwgaGVscCB0byBz dGltdWxhdGUgdGhlIGRlcGxveW1lbnQNCg0Kb2YgY29uc3RyYWluZWQgZGV2aWNlcyB0aGF0IHBy b3ZpZGUgaW5jcmVhc2VkIHNlY3VyaXR5Lg0KDQoNCg0KT25jZSBwcm9ncmVzcyBpbiBpZGVudGlm eWluZyBzdWl0YWJsZSBjYW5kaWRhdGUgc29sdXRpb25zIGhhcyBiZWVuIG1hZGUsDQoNCnRoZSB3 b3JraW5nIGdyb3VwIHdpbGwgdmVyaWZ5IHdoZXRoZXIgdGhlIHNhbWUgbWVjaGFuaXNtcyBhcmUg YWxzbw0KDQphcHBsaWNhYmxlIGJleW9uZCB0aGUgdXNlIG9mIENvQVAgYW5kIERUTFMsIHdoaWNo IGFyZSB0aGUgdHdvIG1haW4NCg0KcHJvdG9jb2xzIHRoZSBncm91cCB3aWxsIGZvY3VzIG9uIGZv ciBhY2Nlc3MgdG8gcmVzb3VyY2VzLiBJbg0KDQpwYXJ0aWN1bGFyLCB0aGUgYWJpbGl0eSB0byB1 c2UgdGhlIGRldmVsb3BlZCBzb2x1dGlvbiBvdmVyIEhUVFAgYW5kIFRMUw0KDQp3aWxsIGJlIGlu dmVzdGlnYXRlZC4gTm90ZSB0aGF0IHRoZSBpbml0aWFsIGZvY3VzIGlzIG9uIENvQVAgYW5kIEhU VFAgd2l0aCBEVExTIGFuZCBUTFMuDQoNCk90aGVyIHNlY3VyaXR5IHByb3RvY29scyBtYXkgYmUg Y29uc2lkZXJlZCBhcyBsb25nIGFzIHRoZSBwcmltYXJ5IGZvY3VzIGlzIG1haW50YWluZWQuDQoN ClRoZSBncm91cCBpcyBzY29wZWQgdG8gd29yayBvbmx5IG9uIHRoZSB3ZWIgcHJvdG9jb2xzIGFu ZCBkYXRhIGNhcnJpZWQgd2l0aGluIHRoZW0uDQoNCkZ1cnRoZXJtb3JlLCB0byBndWFyYW50ZWUg c21vb3RoIHRyYW5zaXRpb24sIHRoZQ0KDQppbnRlZ3JhdGlvbiB3aXRoIGV4aXN0aW5nIGRlcGxv eW1lbnRzIHdpbGwgYmUgc3R1ZGllZCwgcGFydGljdWxhcmx5DQoNCmNvbmNlcm5pbmcgdGhlIHVz ZSBvZiBwcm90b2NvbCB0cmFuc2xhdGlvbiBwcm94aWVzLg0KDQoNCg0KVGhpcyB3b3JrIGRvZXMg bm90IG1ha2UgdGhlIGFzc3VtcHRpb24gdGhhdCB0aGUgcGFydHkgb2ZmZXJpbmcNCg0KYXBwbGlj YXRpb24gbGF5ZXIgc2VydmljZXMgaXMgYWx3YXlzIHRoZSBzYW1lIHBhcnR5IG9mZmVyaW5nIG5l dHdvcmsNCg0KYWNjZXNzIHNlcnZpY2VzLg0KDQoNCg0KVGhlIHdvcmtpbmcgZ3JvdXAgaGFzIHRo ZSBmb2xsb3dpbmcgdGFza3M6DQoNCg0KDQoxKSBQcm9kdWNlIHVzZSBjYXNlcyBhbmQgcmVxdWly ZW1lbnRzDQoNCg0KDQoyKSBJZGVudGlmeSBhdXRoZW50aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlv biBtZWNoYW5pc21zIHN1aXRhYmxlIGZvcg0KDQpyZXNvdXJjZSBhY2Nlc3MgaW4gY29uc3RyYWlu ZWQgZW52aXJvbm1lbnRzLg0KDQoNCg0KTWlsZXN0b25lczoNCg0KDQoNCkp1bCAyMDE0IFN1Ym1p dCAiVXNlIGNhc2VzIGFuZCBSZXF1aXJlbWVudHMiIGFzIGEgV0cgaXRlbS4NCg0KRGVjIDIwMTQg U3VibWl0ICJBdXRoZW50aWNhdGlvbiBhbmQgQXV0aG9yaXphdGlvbiBTb2x1dGlvbiIgYXMgYSBX RyBpdGVtLg0KDQpEZWMgMjAxNCBPcHRpb25hbGx5LCBzdWJtaXQgIlVzZSBjYXNlcyBhbmQgUmVx dWlyZW1lbnRzIiBkb2N1bWVudA0KDQp0byB0aGUgSUVTRyBmb3IgcHVibGljYXRpb24gYXMgYW4g SW5mb3JtYXRpb25hbCBSRkMuDQoNCkp1bCAyMDE2IFN1Ym1pdCAiQXV0aGVudGljYXRpb24gYW5k IEF1dGhvcml6YXRpb24gU29sdXRpb24iDQoNCnNwZWNpZmljYXRpb24gdG8gdGhlIElFU0cgZm9y IHB1YmxpY2F0aW9uIGFzIGEgUHJvcG9zZWQgU3RhbmRhcmQuDQoNCg0KDQpQcm9wb3NlZCBNaWxl c3RvbmVzDQoNCk5vIG1pbGVzdG9uZXMgZm9yIGNoYXJ0ZXIgZm91bmQuDQoNCg0KDQoNCi0tDQoN CkJlc3QgcmVnYXJkcywNCkthdGhsZWVuDQoNCg0KDQotLQ0KDQpCZXN0IHJlZ2FyZHMsDQpLYXRo bGVlbg0KDQoNCg0KLS0NCg0KQmVzdCByZWdhcmRzLA0KS2F0aGxlZW4NCg== --_000_CFB43838132A5goranselanderericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <96707C59C3B25541B15DCCD962072D6D@ericsson.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdiBzdHlsZT0iY29s b3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQt c2l6ZTogMTRweDsiPg0KSGkgS2F0aGxlZW4sPC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdi KDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAx NHB4OyI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxkaXY+ DQo8ZGl2PkluIGNoYW5nZSAjMyBvZiB0aGUgc3VtbWFyeSBLZXBlbmcgbWFkZSBiZWxvdyZuYnNw Ozxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiI+SSBmaW5kIHRoZSBzZW50ZW5jZTogJmd0 OyZndDs8L2ZvbnQ+PGZvbnQgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmksc2Fucy1zZXJp ZiIgc2l6ZT0iMyI+T3RoZXIgc2VjdXJpdHkgcHJvdG9jb2xzIG1heSBiZSBjb25zaWRlcmVkIGFz IGxvbmcgYXMgdGhlIHByaW1hcnkgZm9jdXMgaXMgbWFpbnRhaW5lZC4NCiAmZ3Q7Jmd0OyZuYnNw OzwvZm9udD48c3BhbiBzdHlsZT0iY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IGZvbnQtc2l6ZTog bWVkaXVtOyI+VGhpcyZuYnNwO3NlbnRlbmNlIHNlZW1zIHRvIGJlIG1pc3NpbmcgZnJvbSBjaGFy dGVyLWlldGYtYWNlLTAwLTA0Ljwvc3Bhbj48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2 PlJlZ2FyZHMsPC9kaXY+DQo8ZGl2PjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDMxLCA3MywgMTI1 KTsiPkfDtnJhbjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPGRpdj48Zm9udCBjb2xvcj0iIzFmNDk3 ZCIgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIiBzaXplPSIzIj48YnI+DQo8L2ZvbnQ+PC9kaXY+ DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBD YWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxicj4NCjwvZGl2Pg0KPHNw YW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsg Zm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KPGRp diBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjExcHQ7IHRleHQtYWxpZ246 bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBCT1JERVItTEVG VDogbWVkaXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDogMGluOyBQ QURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBCT1JERVIt UklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0eWxlPSJmb250 LXdlaWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+S2F0aGxlZW4gTW9yaWFydHkgJmx0OzxhIGhyZWY9 Im1haWx0bzprYXRobGVlbi5tb3JpYXJ0eS5pZXRmQGdtYWlsLmNvbSI+a2F0aGxlZW4ubW9yaWFy dHkuaWV0ZkBnbWFpbC5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpi b2xkIj5EYXRlOiA8L3NwYW4+VHVlc2RheSAzIEp1bmUgMjAxNCAyMjoyNzxicj4NCjxzcGFuIHN0 eWxlPSJmb250LXdlaWdodDpib2xkIj5UbzogPC9zcGFuPkxpa2VwZW5nICZsdDs8YSBocmVmPSJt YWlsdG86bGlrZXBlbmdAaHVhd2VpLmNvbSI+bGlrZXBlbmdAaHVhd2VpLmNvbTwvYT4mZ3Q7PGJy Pg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkNjOiA8L3NwYW4+QmVub2l0IENsYWlz ZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJjbGFpc2VAY2lzY28uY29tIj5iY2xhaXNlQGNpc2NvLmNv bTwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86YWRyaWFuQG9sZGRvZy5jby51ayI+YWRy aWFuQG9sZGRvZy5jby51azwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzphZHJpYW5Ab2xk ZG9nLmNvLnVrIj5hZHJpYW5Ab2xkZG9nLmNvLnVrPC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1h aWx0bzphY2VAaWV0Zi5vcmciPmFjZUBpZXRmLm9yZzwvYT4mcXVvdDsNCiAmbHQ7PGEgaHJlZj0i bWFpbHRvOmFjZUBpZXRmLm9yZyI+YWNlQGlldGYub3JnPC9hPiZndDssIFRoZSBJRVNHICZsdDs8 YSBocmVmPSJtYWlsdG86aWVzZ0BpZXRmLm9yZyI+aWVzZ0BpZXRmLm9yZzwvYT4mZ3Q7LCAmcXVv dDs8YSBocmVmPSJtYWlsdG86YWFhLWRvY3RvcnNAaWV0Zi5vcmciPmFhYS1kb2N0b3JzQGlldGYu b3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFhYS1kb2N0b3JzQGlldGYub3JnIj5h YWEtZG9jdG9yc0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0 OmJvbGQiPlN1YmplY3Q6IDwvc3Bhbj5SZTogW0FjZV0gUmV2aXNlZCBjaGFydGVyIHByb3Bvc2Fs OiBjaGFydGVyLWlldGYtYWNlLTAwLTAyPGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxl PSJCT1JERVItTEVGVDogI2I1YzRkZiA1IHNvbGlkOyBQQURESU5HOjAgMCAwIDU7IE1BUkdJTjow IDAgMCA1OyI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgZGlyPSJsdHIiPlRoZSBjaGFydGVyIHRleHQg aGFzIGJlZW4gdXBkYXRlZCwmbmJzcDs8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9jaGFydGVyLWlldGYtYWNlLyI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvY2hhcnRlci1pZXRmLWFjZS88L2E+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGFuayB5 b3UgYWxsIGZvciB5b3VyIGlucHV0IGFuZCBhc3Npc3RhbmNlLiAmbmJzcDtJZiB0aGlzIGlzIGdv b2QsIHdlJ2xsIG1vdmUgaXQgZm9yd2FyZCBmb3IgSUVURiByZXZpZXcuPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L3NwYW4+PHNwYW4gaWQ9Ik9MS19TUkNf Qk9EWV9TRUNUSU9OIiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENh bGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KPGJsb2NrcXVvdGUgaWQ9Ik1B Q19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJCT1JERVItTEVGVDogI2I1 YzRkZiA1IHNvbGlkOyBQQURESU5HOjAgMCAwIDU7IE1BUkdJTjowIDAgMCA1OyI+DQo8ZGl2Pg0K PGRpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48YnI+DQo8YnI+DQo8ZGl2IGNsYXNzPSJn bWFpbF9xdW90ZSI+T24gVHVlLCBKdW4gMywgMjAxNCBhdCAxMDozOSBBTSwgS2F0aGxlZW4gTW9y aWFydHkgPHNwYW4gZGlyPSJsdHIiPg0KJmx0OzxhIGhyZWY9Im1haWx0bzprYXRobGVlbi5tb3Jp YXJ0eS5pZXRmQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmthdGhsZWVuLm1vcmlhcnR5Lmll dGZAZ21haWwuY29tPC9hPiZndDs8L3NwYW4+IHdyb3RlOjxicj4NCjxibG9ja3F1b3RlIGNsYXNz PSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAj Y2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBkaXI9Imx0ciI+SSBiZWxpZXZlIHRo ZXJlIGlzIGFncmVlbWVudCBvbiB0aGUgcHJvcG9zZWQgY2hhbmdlcy4gJm5ic3A7SSdsbCBtYWtl IHRoZSB1cGRhdGVzIGxhdGVyIGluIHRoZSBkYXkgKGl0J3MgYWJvdXQgMTE6MzAgbXkgdGltZSwg bWF5YmUgYXQgNCkgaW4gY2FzZSBhbnlvbmUgd2FudHMgdG8gY2hpbWUgaW4uICZuYnNwO0lmIHdl IGFyZSBhbGwgaW4gYWdyZWVtZW50LCBJJ2xsIGhhdmUgaXQgc2VudCBmb3IgSUVURiByZXZpZXcg YXQgdGhhdCBwb2ludC4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoYW5rIHlvdSE8L2Rpdj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPg0KPGRpdj4NCjxkaXYgY2xhc3M9Img1 Ij48YnI+DQo8YnI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gVHVlLCBKdW4gMywgMjAx NCBhdCAxMDoyNiBBTSwgTGlrZXBlbmcgPHNwYW4gZGlyPSJsdHIiPg0KJmx0OzxhIGhyZWY9Im1h aWx0bzpsaWtlcGVuZ0BodWF3ZWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+bGlrZXBlbmdAaHVhd2Vp LmNvbTwvYT4mZ3Q7PC9zcGFuPiB3cm90ZTo8YnI+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxf cXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xp ZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXYgbGFuZz0iWkgtQ04iIGxpbms9ImJsdWUiIHZsaW5r PSJwdXJwbGUiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNl cmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPkhpIEthdGhsZWVuIGFuZCBhbGwsPHU+PC91 Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMt c2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9y OiByZ2IoMzEsIDczLCAxMjUpOyI+VGhpcyBpcyB3aGF0IEkgaGF2ZSBub3c6PHU+PC91Pjx1Pjwv dT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7 IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2Io MzEsIDczLCAxMjUpOyI+Q2hhbmdlICMxOiAoUHJvcG9zZWQgYnkgS2VwZW5nLCBjb25maXJtZWQg YnkgQmVub2l0KTx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cHJlPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJp LCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPk9MRDx1PjwvdT48dT48L3U+ PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTog MTAuNXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwg NzMsIDEyNSk7Ij5UaGUgSUVURiBoYXMgcmVjZW50bHkgZGV2ZWxvcGVkIHByb3RvY29scyBmb3Ig dXNlIGluIGNvbnN0cmFpbmVkPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxp YnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPmVudmlyb25tZW50cywg d2hlcmUgbmV0d29yayBub2RlcyBhcmUgbGltaXRlZCBpbiBDUFUsIG1lbW9yeSBhbmQgcG93ZXIu IDx1PjwvdT48dT48L3U+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsg Y29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij48dT48L3U+Jm5ic3A7PHU+PC91Pjwvc3Bhbj48L3By ZT4NCjwvZGl2Pg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTAu NXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMs IDEyNSk7Ij5ORVc8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3ByZT4NCjxkaXY+DQo8cHJlPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxp YnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPlRoZSBJRVRGIGhhcyBy ZWNlbnRseSBkZXZlbG9wZWQgcHJvdG9jb2xzIGZvciB1c2UgaW4gY29uc3RyYWluZWQ8dT48L3U+ PHU+PC91Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiBy Z2IoMzEsIDczLCAxMjUpOyI+ZW52aXJvbm1lbnRzLCB3aGVyZSBuZXR3b3JrIG5vZGVzIGFyZSBs aW1pdGVkIGluIENQVSwgbWVtb3J5IGFuZCBwb3dlci48dT48L3U+PHU+PC91Pjwvc3Bhbj48L3By ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9u dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+ UkVTVCBhcmNoaXRlY3R1cmUgaXMgd2lkZWx5IHVzZWQgZm9yIHN1Y2ggY29uc3RyYWluZWQgZW52 aXJvbm1lbnRzLjx1PjwvdT48dT48L3U+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu cy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij5FTkQ8dT48L3U+PHU+PC91Pjwvc3Bh bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwLjVw dDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAx MjUpOyI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3NwYW4+PC9wcmU+DQo8L2Rpdj4NCjxwcmU+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENh bGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+Q2hhbmdlICMyOiAo UHJvcG9zYWwgZnJvbSBSZW5lLCBzdXBwb3J0ZWQgYnkgU3RlZmFuaWUpPHU+PC91Pjx1PjwvdT48 L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAx MC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3 MywgMTI1KTsiPk9MRDo8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3ByZT4NCjxkaXY+DQo8cHJlPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBD YWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPlJlcXVpcmVtZW50 cyBkZXJpdmVkIGZyb20gdXNlIGNhc2VzIGluZGljYXRlIHRoZSBzdWl0YWJpbGl0eSBvZiBleGlz dGluZzx1PjwvdT48dT48L3U+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJp ZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij53b3JrIGFzIGEgc29sdXRpb24gZm9yIGNvbnN0 cmFpbmVkIGVudmlyb25tZW50cyA8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENh bGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+PHU+PC91PiZuYnNw Ozx1PjwvdT48L3NwYW4+PC9wcmU+DQo8L2Rpdj4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7 IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+TkVXOjx1PjwvdT48dT48L3U+PC9zcGFuPjwvcHJl Pg0KPGRpdj4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwLjVw dDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAx MjUpOyI+UmVxdWlyZW1lbnRzIGRlcml2ZWQgZnJvbSB1c2UgY2FzZXMgbWF5IGluZGljYXRlIHRo YXQgZXhpc3Rpbmcgd29yayBpczx1PjwvdT48dT48L3U+PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8 cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFt aWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPiB1c2Vm dWwgYXMgYmFzaXMgZm9yIGFzIGEgc29sdXRpb24gZm9yIGNvbnN0cmFpbmVkIGVudmlyb25tZW50 czx1PjwvdT48dT48L3U+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsg Y29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij48dT48L3U+Jm5ic3A7PHU+PC91Pjwvc3Bhbj48L3By ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9u dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+ Q2hhbmdlICMzOiAoUHJvcG9zYWwgZnJvbSBKYXJpLCBzdXBwb3J0ZWQgYnkgQmFycnksIFJvYmVy dCBhbmQgQmVoY2V0KTx1PjwvdT48dT48L3U+PC9zcGFuPjwvcHJlPg0KPGRpdj4NCjxwcmU+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENh bGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+T0xEOjx1PjwvdT48 dT48L3U+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJn YigzMSwgNzMsIDEyNSk7Ij5Ob3RlIHRoYXQgdGhlIGluaXRpYWwgZm9jdXMgaXMgb24gQ29BUCBh bmQgSFRUUCB3aXRoIERUTFMgYW5kIFRMUy48dT48L3U+PHU+PC91Pjwvc3Bhbj48L3ByZT4NCjxw cmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1p bHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+T3RoZXIg c2VjdXJpdHkgcHJvdG9jb2xzIG1heSBiZSBjb25zaWRlcmVkIGFzIGxvbmcgYXMgdGhlIHByaW1h cnkgZm9jdXMgaXMgbWFpbnRhaW5lZC4mbmJzcDsgPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wcmU+ DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQt ZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPk90 aGVyIGFwcGxpY2F0aW9uIHByb3RvY29scyBhbmQgcHJvdG9jb2xzIGF0IG90aGVyIGxheWVycyBp biB0aGUgc3RhY2sgYXJlIG91dCBvZiBzY29wZS48dT48L3U+PHU+PC91Pjwvc3Bhbj48L3ByZT4N CjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1m YW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+PHU+ PC91PiZuYnNwOzx1PjwvdT48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlm OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPk5FVzx1PjwvdT48dT48L3U+PC9zcGFuPjwvcHJl Pg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250 LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij5O b3RlIHRoYXQgdGhlIGluaXRpYWwgZm9jdXMgaXMgb24gQ29BUCBhbmQgSFRUUCB3aXRoIERUTFMg YW5kIFRMUy48dT48L3U+PHU+PC91Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMt c2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+T3RoZXIgc2VjdXJpdHkgcHJvdG9jb2xz IG1heSBiZSBjb25zaWRlcmVkIGFzIGxvbmcgYXMgdGhlIHByaW1hcnkgZm9jdXMgaXMgbWFpbnRh aW5lZC4mbmJzcDsgPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBz YW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPlRoZSBncm91cCBpcyBzY29wZWQg dG8gd29yayBvbmx5IG9uIHRoZSB3ZWIgcHJvdG9jb2xzIGFuZCBkYXRhIGNhcnJpZWQgd2l0aGlu IHRoZW0uPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNl cmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPkVORDx1PjwvdT48dT48L3U+PC9zcGFuPjwv cHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBm b250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7 Ij48dT48L3U+Jm5ic3A7PHU+PC91Pjwvc3Bhbj48L3ByZT4NCjwvZGl2Pg0KPHByZT48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogQ2FsaWJy aSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij5DaGFuZ2UgNDogKFByb3Bv c2FsIGZyb20gSmFyaSwgcmV2aXNlZCBieSBSZW5lLCBzdXBwb3J0ZWQgYnkgU3RlZmFuaWUpPHU+ PC91Pjx1PjwvdT48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xv cjogcmdiKDMxLCA3MywgMTI1KTsiPk9MRDo8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3ByZT4NCjxk aXY+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsi Pkp1bCAyMDE0IFN1Ym1pdCAmcXVvdDtVc2UgY2FzZXMgYW5kIFJlcXVpcmVtZW50cyZxdW90OyAg YXMgYSBXRyBpdGVtLjx1PjwvdT48dT48L3U+PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8cHJlPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBD YWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPkp1bCAyMDE1IFN1 Ym1pdCDigJxVc2UgY2FzZXMgYW5kIFJlcXVpcmVtZW50c+KAnSBkb2N1bWVudCB0byBJRVNHIGZv ciBwdWJsaWNhdGlvbiBhcyBpbmZvcm1hdGlvbmFsIFJGQy48dT48L3U+PHU+PC91Pjwvc3Bhbj48 L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsg Zm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUp OyI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z LXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPk5FVzx1PjwvdT48dT48L3U+PC9zcGFu PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0 OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEy NSk7Ij5EZWMgMjAxNCBTdWJtaXQgJnF1b3Q7VXNlIGNhc2VzIGFuZCBSZXF1aXJlbWVudHMmcXVv dDsgIGFzIGEgV0cgaXRlbS48dT48L3U+PHU+PC91Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGli cmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+QXByIDIwMTUgT3B0aW9u YWxseSwgc3VibWl0ICZxdW90O1VzZSBjYXNlcyBhbmQgUmVxdWlyZW1lbnRzJnF1b3Q7IGRvY3Vt ZW50IHRvIHRoZSBJRVNHIGZvcjx1PjwvdT48dT48L3U+PC9zcGFuPjwvcHJlPg0KPGRpdj4NCjxw cmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1p bHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+cHVibGlj YXRpb24gYXMgYW4gSW5mb3JtYXRpb25hbCBSRkMuPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wcmU+ DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQt ZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPkVO RDx1PjwvdT48dT48L3U+PC9zcGFuPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGli cmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+PHU+PC91PiZuYnNwOzx1 PjwvdT48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwg c2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij5JIHRoaW5rIHdlIGNvdmVyZWQg YWxsIG9mIHRoZSBJRVNHIHJldmlldyBjb21tZW50cy48dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZTogMTAuNXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigz MSwgNzMsIDEyNSk7Ij48dT48L3U+Jm5ic3A7PHU+PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBm b250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7 Ij5JZiB0aGVyZSBpcyBhbnkgb3BlbiBpc3N1ZSwgcGxlYXNlIGxldCB1cyBrbm93Ljx1PjwvdT48 dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNl cmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjog cmdiKDMxLCA3MywgMTI1KTsiPlRoYW5rcyw8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTAu NXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMs IDEyNSk7Ij48dT48L3U+Jm5ic3A7PHU+PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZh bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij5LaW5k IFJlZ2FyZHM8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTog Q2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij5LZXBlbmc8dT48 L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5 OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEs IDczLCAxMjUpOyI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9u dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+ Q2hhcnRlciBjaGFydGVyLWlldGYtYWNlLTAwLTAyPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEs IDczLCAxMjUpOyI+QXV0aGVudGljYXRpb24gYW5kIEF1dGhvcml6YXRpb24gZm9yIENvbnN0cmFp bmVkPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGli cmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+RW52aXJvbm1lbnQgKEFD RSk8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogQ2FsaWJy aSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij48dT48L3U+Jm5ic3A7PHU+ PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJp ZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij5UaGUgSUVURiBoYXMgcmVjZW50bHkgZGV2ZWxv cGVkIHByb3RvY29scyBmb3IgdXNlIGluIGNvbnN0cmFpbmVkPHU+PC91Pjx1PjwvdT48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiBy Z2IoMzEsIDczLCAxMjUpOyI+ZW52aXJvbm1lbnRzLCB3aGVyZSBuZXR3b3JrIG5vZGVzIGFyZSBs aW1pdGVkIGluIENQVSwgbWVtb3J5IGFuZCBwb3dlci4NCjx1PjwvdT48dT48L3U+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdi KDMxLCA3MywgMTI1KTsiPlJFU1QgYXJjaGl0ZWN0dXJlIGlzIHdpZGVseSB1c2VkIGZvciBzdWNo IGNvbnN0cmFpbmVkIGVudmlyb25tZW50cy48dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTAu NXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMs IDEyNSk7Ij5JdCBoYXMgYmVlbiBvYnNlcnZlZCB0aGF0IEludGVybmV0IHByb3RvY29scyBjYW4g YmUgYXBwbGllZCB0byB0aGVzZTx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsi PmNvbnN0cmFpbmVkIGVudmlyb25tZW50cywgb2Z0ZW4gb25seSByZXF1aXJpbmcgbWlub3IgdHdl YWtpbmcgYW5kPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6 IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+cHJvZmlsaW5n LiBJbiBvdGhlciBjYXNlcywgbmV3IHByb3RvY29scyBoYXZlIGJlZW4gZGVmaW5lZCB0byBhZGRy ZXNzPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGli cmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+dGhlIHNwZWNpZmljIHJl cXVpcmVtZW50cyBvZiBjb25zdHJhaW5lZCBlbnZpcm9ubWVudHMuIEFuIGV4YW1wbGUgb2Y8dT48 L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu cy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij5zdWNoIGEgcHJvdG9jb2wgaXMgdGhl IENvbnN0cmFpbmVkIEFwcGxpY2F0aW9uIFByb3RvY29sIChDb0FQKS48dT48L3U+PHU+PC91Pjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29s b3I6IHJnYigzMSwgNzMsIDEyNSk7Ij48dT48L3U+Jm5ic3A7PHU+PC91Pjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTog MTAuNXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwg NzMsIDEyNSk7Ij5BcyBpbiBvdGhlciBlbnZpcm9ubWVudHMsIGF1dGhlbnRpY2F0aW9uIGFuZCBh dXRob3JpemF0aW9uIHF1ZXN0aW9uczx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7 IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1 KTsiPmFsc28gYXJpc2UgaW4gY29uc3RyYWluZWQgZW52aXJvbm1lbnRzLiBGb3IgZXhhbXBsZSwg YSBkb29yIGxvY2sgaGFzIHRvPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9u dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+ YXV0aG9yaXplIHRoZSBwZXJzb24gc2Vla2luZyBhY2Nlc3MgdXNpbmcgYSAmcXVvdDtkaWdpdGFs IGtleSZxdW90Oy4gV2hlcmUgaXMgdGhlPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwLjVw dDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAx MjUpOyI+YXV0aG9yaXphdGlvbiBwb2xpY3kgc3RvcmVkPyBIb3cgZG9lcyB0aGUgZGlnaXRhbCBr ZXkgY29tbXVuaWNhdGUgd2l0aDx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsi PnRoZSBsb2NrPyBEb2VzIHRoZSBsb2NrIGludGVyYWN0IHdpdGggYW4gYXV0aG9yaXphdGlvbiBz ZXJ2ZXIgdG8gb2J0YWluPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1m YW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+YXV0 aG9yaXphdGlvbiBpbmZvcm1hdGlvbj8gSG93IGNhbiBhY2Nlc3MgYmUgdGVtcG9yYXJpbHkgZ3Jh bnRlZCB0bzx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBD YWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPm90aGVyIHBlcnNv bnM/IEhvdyBjYW4gYWNjZXNzIGJlIHJldm9rZWQ/IFRoZXNlIHR5cGVzIG9mIHF1ZXN0aW9ucyBo YXZlPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGli cmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+YmVlbiBhbnN3ZXJlZCBi eSBleGlzdGluZyBwcm90b2NvbHMgZm9yIHVzZSBjYXNlcyBvdXRzaWRlIGNvbnN0cmFpbmVkPHU+ PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNh bnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+ZW52aXJvbm1lbnRzLCBob3dldmVy IGluIGNvbnN0cmFpbmVkIGVudmlyb25tZW50cywgYWRkaXRpb25hbCBhbmQ8dT48L3U+PHU+PC91 Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsg Y29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij5kaWZmZXJlbnQgcmVxdWlyZW1lbnRzIHBvc2UgY2hh bGxlbmdlcyBmb3IgdGhlIHVzZSBvZiB2YXJpb3VzIHNlY3VyaXR5PHU+PC91Pjx1PjwvdT48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9y OiByZ2IoMzEsIDczLCAxMjUpOyI+cHJvdG9jb2xzLiBJbiBwYXJ0aWN1bGFyLCB0aGUgbmVlZCBh cmlzZXMgZm9yIGEgZHluYW1pYyBhbmQgZmluZSBncmFpbmVkPHU+PC91Pjx1PjwvdT48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiBy Z2IoMzEsIDczLCAxMjUpOyI+YWNjZXNzIGNvbnRyb2wgbWVjaGFuaXNtLCB3aGVyZSBjbGllbnRz IGFuZC9vciByZXNvdXJjZSBzZXJ2ZXJzIGFyZTx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAx MC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3 MywgMTI1KTsiPmNvbnN0cmFpbmVkLjx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7 IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1 KTsiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5 OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPlRoZSBJRVRG IGhhcyBhIGxvbmcgaGlzdG9yeSBpbiBkZXZlbG9waW5nIHRocmVlLXBhcnR5IGF1dGhlbnRpY2F0 aW9uIGFuZDx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBD YWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPmF1dGhvcml6YXRp b24gcHJvdG9jb2xzIGZvciBkaXN0cmlidXRlZCBlbnZpcm9ubWVudHMuIEV4YW1wbGVzIGluY2x1 ZGU8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9u dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+ S2VyYmVyb3MsIHRoZSBQdWJsaWMgS2V5IEluZnJhc3RydWN0dXJlIChQS0kpLCB0aGUgQXV0aGVu dGljYXRpb24sPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6 IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+QXV0aG9yaXph dGlvbiBhbmQgQWNjb3VudGluZyAoQUFBKSBpbmZyYXN0cnVjdHVyZSxhbmQgdGhlIFdlYjx1Pjwv dT48dT48L3U+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogQ2FsaWJy aSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij5BdXRob3JpemF0aW9uIFBy b3RvY29sIChPQXV0aCkuIEFsbCB0aGVzZSBwcm90b2NvbHMgZW5qb3kgd2lkZXNwcmVhZDx1Pjwv dT48dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z LXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPmRlcGxveW1lbnQgb24gdGhlIEludGVy bmV0LiBBbHRob3VnaCB0aGV5IGFsbCBhaW0gdG8gc29sdmUgYSBzaW1pbGFyPHU+PC91Pjx1Pjwv dT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7 IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+Z29hbCwgYXQgYW4gYWJzdHJhY3QgbGV2ZWwsIHRo ZXkgb2ZmZXIgcXVpdGUgZGlmZmVyZW50IGZ1bmN0aW9ucyBhbmQ8dT48L3U+PHU+PC91Pjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6 IHJnYigzMSwgNzMsIDEyNSk7Ij51dGlsaXplIGRpZmZlcmVudCBtZXNzYWdlIGV4Y2hhbmdlcy4g VGhlc2UgZGlmZmVyZW5jZXMgcmVzdWx0IGZyb20gdGhlPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2Io MzEsIDczLCAxMjUpOyI+bWFpbiBkZXBsb3ltZW50IHVzZSBjYXNlcyB0aGV5IHdlcmUgZGVzaWdu ZWQgZm9yIHJlc3BlY3RpdmVseS48dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBm b250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7 Ij48dT48L3U+Jm5ic3A7PHU+PC91Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQt ZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPlJl cXVpcmVtZW50cyBkZXJpdmVkIGZyb20gdXNlIGNhc2VzIG1heSBpbmRpY2F0ZSB0aGF0IGV4aXN0 aW5nIHdvcmsgaXMNCjx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFt aWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPnVzZWZ1 bCBhcyBiYXNpcyBmb3IgYXMgYSBzb2x1dGlvbiBmb3IgY29uc3RyYWluZWQgZW52aXJvbm1lbnRz Ljx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTog Q2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij5UaGVzZSBwcm90 b2NvbHMsPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENh bGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+aG93ZXZlciwgd2Vy ZSBub3Qgb3B0aW1pemVkIGZvciBjb25zdHJhaW5lZCBlbnZpcm9ubWVudHMuIEFkZGl0aW9uYWw8 dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwg c2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij5yZXF1aXJlbWVudHMgdGhhdCBu ZWVkIHRvIGJlIHRha2VuIGludG8gYWNjb3VudCBhcmUgdGhlIGxhY2sgb2YgYTx1PjwvdT48dT48 L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlm OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPnN1aXRhYmxlIHVzZXItaW50ZXJmYWNlIGFuZCB0 aGUgaW5hYmlsaXR5IG9mIGVtYmVkZGVkIGRldmljZXMgdG8gY29udGFjdDx1PjwvdT48dT48L3U+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBj b2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPmFuIGF1dGhvcml6YXRpb24gc2VydmVyIGluIHJlYWwt dGltZSB3aXRoIGV2ZXJ5IHJlc291cmNlIGFjY2VzcyByZXF1ZXN0PHU+PC91Pjx1PjwvdT48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9y OiByZ2IoMzEsIDczLCAxMjUpOyI+ZHVlIHRvIGludGVybWl0dGVudCBjb25uZWN0aXZpdHksIGV0 Yy48dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogQ2FsaWJy aSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij48dT48L3U+Jm5ic3A7PHU+ PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJp ZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij5UaGlzIHdvcmtpbmcgZ3JvdXAgdGhlcmVmb3Jl IGFpbXMgdG8gcHJvZHVjZSBhIHN0YW5kYXJkaXplZCBzb2x1dGlvbiBmb3I8dT48L3U+PHU+PC91 Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsg Y29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij5hdXRoZW50aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlv biB0byBlbmFibGUgYXV0aG9yaXplZCBhY2Nlc3MgKEdFVCwgUFVULCBQT1NULA0KPHU+PC91Pjx1 PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2Vy aWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+REVMRVRFKSB0byByZXNvdXJjZXMgaWRlbnRp ZmllZCBieSBhIFVSSSBhbmQgaG9zdGVkIG9uIGEgcmVzb3VyY2U8dT48L3U+PHU+PC91Pjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6 IHJnYigzMSwgNzMsIDEyNSk7Ij5zZXJ2ZXIgaW4gY29uc3RyYWluZWQgZW52aXJvbm1lbnRzLiBB cyBhIHN0YXJ0aW5nIHBvaW50LCB0aGUgd29ya2luZzx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMx LCA3MywgMTI1KTsiPmdyb3VwIHdpbGwgYXNzdW1lIHRoYXQgYWNjZXNzIHRvIHJlc291cmNlcyBh dCBhIHJlc291cmNlIHNlcnZlciBieSBhPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwLjVw dDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAx MjUpOyI+Y2xpZW50IGRldmljZSB0YWtlcyBwbGFjZSB1c2luZyBDb0FQIGFuZCBpcyBwcm90ZWN0 ZWQgYnkgRFRMUy4gQm90aDx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQt ZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPnJl c291cmNlIHNlcnZlciBhbmQgY2xpZW50IG1heSBiZSBjb25zdHJhaW5lZC4gVGhpcyBhY2Nlc3Mg d2lsbCBiZTx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBD YWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPm1lZGlhdGVkIGJ5 IGFuIGF1dGhvcml6YXRpb24gc2VydmVyLCB3aGljaCBpcyBub3QgY29uc2lkZXJlZCB0byBiZTx1 PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBz YW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPmNvbnN0cmFpbmVkLjx1PjwvdT48 dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNl cmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7 IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+RXhpc3RpbmcgYXV0aGVudGljYXRpb24gYW5kIGF1 dGhvcml6YXRpb24gcHJvdG9jb2xzIHdpbGwgYmUgZXZhbHVhdGVkDQo8dT48L3U+PHU+PC91Pjwv c3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2Vy aWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+YW5kIHJlLXVzZWQgd2hlcmUgYXBwbGljYWJs ZSB0byBidWlsZCB0aGUgY29uc3RyYWluZWQtZW52aXJvbm1lbnQgc29sdXRpb24uPHU+PC91Pjx1 PjwvdT48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwg c2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij5UaGlzIHJlcXVpcmVzPHU+PC91 Pjx1PjwvdT48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTog Q2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij5yZWxldmFudCBz cGVjaWZpY2F0aW9ucyB0byBiZSByZXZpZXdlZCBmb3Igc3VpdGFiaWxpdHksIHNlbGVjdGluZyBh PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmks IHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+c3Vic2V0IG9mIHRoZW0gYW5k IHJlc3RyaWN0aW5nIHRoZSBvcHRpb25zIHdpdGhpbiBlYWNoIG9mIHRoZTx1PjwvdT48dT48L3U+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBj b2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPnNwZWNpZmljYXRpb25zLiBTb21lIGZ1bmN0aW9uYWxp dHksIGhvd2V2ZXIsIG1heSBub3QgYmUgYXZhaWxhYmxlIGluPHU+PC91Pjx1PjwvdT48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiBy Z2IoMzEsIDczLCAxMjUpOyI+ZXhpc3RpbmcgcHJvdG9jb2xzLCBpbiB3aGljaCBjYXNlIHRoZSBz b2x1dGlvbiBtYXkgYWxzbyBpbnZvbHZlIG5ldzx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAx MC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3 MywgMTI1KTsiPnByb3RvY29sIHdvcmsuIExldmVyYWdpbmcgZXhpc3Rpbmcgd29yayBtZWFucyB0 aGUgd29ya2luZyBncm91cCBiZW5lZml0czx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMC41 cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3Mywg MTI1KTsiPmZyb20gYXZhaWxhYmxlIHNlY3VyaXR5IGFuYWx5c2lzLCBpbXBsZW1lbnRhdGlvbiwg YW5kIGRlcGxveW1lbnQ8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZh bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij5leHBl cmllbmNlLiBNb3Jlb3ZlciwgYSBzdGFuZGFyZGl6ZWQgc29sdXRpb24gZm9yIGZlZGVyYXRlZDx1 PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBz YW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPmF1dGhlbnRpY2F0aW9uIGFuZCBh dXRob3JpemF0aW9uIHdpbGwgaGVscCB0byBzdGltdWxhdGUgdGhlIGRlcGxveW1lbnQ8dT48L3U+ PHU+PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1z ZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij5vZiBjb25zdHJhaW5lZCBkZXZpY2VzIHRo YXQgcHJvdmlkZSBpbmNyZWFzZWQgc2VjdXJpdHkuPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEs IDczLCAxMjUpOyI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9u dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+ T25jZSBwcm9ncmVzcyBpbiBpZGVudGlmeWluZyBzdWl0YWJsZSBjYW5kaWRhdGUgc29sdXRpb25z IGhhcyBiZWVuIG1hZGUsPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1m YW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+dGhl IHdvcmtpbmcgZ3JvdXAgd2lsbCB2ZXJpZnkgd2hldGhlciB0aGUgc2FtZSBtZWNoYW5pc21zIGFy ZSBhbHNvPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENh bGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+YXBwbGljYWJsZSBi ZXlvbmQgdGhlIHVzZSBvZiBDb0FQIGFuZCBEVExTLCB3aGljaCBhcmUgdGhlIHR3byBtYWluPHU+ PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNh bnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+cHJvdG9jb2xzIHRoZSBncm91cCB3 aWxsIGZvY3VzIG9uIGZvciBhY2Nlc3MgdG8gcmVzb3VyY2VzLiBJbjx1PjwvdT48dT48L3U+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xv cjogcmdiKDMxLCA3MywgMTI1KTsiPnBhcnRpY3VsYXIsIHRoZSBhYmlsaXR5IHRvIHVzZSB0aGUg ZGV2ZWxvcGVkIHNvbHV0aW9uIG92ZXIgSFRUUCBhbmQgVExTPHU+PC91Pjx1PjwvdT48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiBy Z2IoMzEsIDczLCAxMjUpOyI+d2lsbCBiZSBpbnZlc3RpZ2F0ZWQuIE5vdGUgdGhhdCB0aGUgaW5p dGlhbCBmb2N1cyBpcyBvbiBDb0FQIGFuZCBIVFRQIHdpdGggRFRMUyBhbmQgVExTLjx1PjwvdT48 dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNl cmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPk90aGVyIHNlY3VyaXR5IHByb3RvY29scyBt YXkgYmUgY29uc2lkZXJlZCBhcyBsb25nIGFzIHRoZSBwcmltYXJ5IGZvY3VzIGlzIG1haW50YWlu ZWQuJm5ic3A7DQo8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWls eTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij5UaGUgZ3Jv dXAgaXMgc2NvcGVkIHRvIHdvcmsgb25seSBvbiB0aGUgd2ViIHByb3RvY29scyBhbmQgZGF0YSBj YXJyaWVkIHdpdGhpbiB0aGVtLjx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsi PkZ1cnRoZXJtb3JlLCB0byBndWFyYW50ZWUgc21vb3RoIHRyYW5zaXRpb24sIHRoZTx1PjwvdT48 dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNl cmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPmludGVncmF0aW9uIHdpdGggZXhpc3Rpbmcg ZGVwbG95bWVudHMgd2lsbCBiZSBzdHVkaWVkLCBwYXJ0aWN1bGFybHk8dT48L3U+PHU+PC91Pjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29s b3I6IHJnYigzMSwgNzMsIDEyNSk7Ij5jb25jZXJuaW5nIHRoZSB1c2Ugb2YgcHJvdG9jb2wgdHJh bnNsYXRpb24gcHJveGllcy48dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250 LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij48 dT48L3U+Jm5ic3A7PHU+PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij5UaGlzIHdvcmsgZG9l cyBub3QgbWFrZSB0aGUgYXNzdW1wdGlvbiB0aGF0IHRoZSBwYXJ0eSBvZmZlcmluZzx1PjwvdT48 dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNl cmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPmFwcGxpY2F0aW9uIGxheWVyIHNlcnZpY2Vz IGlzIGFsd2F5cyB0aGUgc2FtZSBwYXJ0eSBvZmZlcmluZyBuZXR3b3JrPHU+PC91Pjx1PjwvdT48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNv bG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+YWNjZXNzIHNlcnZpY2VzLjx1PjwvdT48dT48L3U+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xv cjogcmdiKDMxLCA3MywgMTI1KTsiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAx MC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3 MywgMTI1KTsiPlRoZSB3b3JraW5nIGdyb3VwIGhhcyB0aGUgZm9sbG93aW5nIHRhc2tzOjx1Pjwv dT48dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z LXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xv cjogcmdiKDMxLCA3MywgMTI1KTsiPjEpIFByb2R1Y2UgdXNlIGNhc2VzIGFuZCByZXF1aXJlbWVu dHM8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogQ2FsaWJy aSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij48dT48L3U+Jm5ic3A7PHU+ PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJp ZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij4yKSBJZGVudGlmeSBhdXRoZW50aWNhdGlvbiBh bmQgYXV0aG9yaXphdGlvbiBtZWNoYW5pc21zIHN1aXRhYmxlIGZvcjx1PjwvdT48dT48L3U+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xv cjogcmdiKDMxLCA3MywgMTI1KTsiPnJlc291cmNlIGFjY2VzcyBpbiBjb25zdHJhaW5lZCBlbnZp cm9ubWVudHMuPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6 IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+PHU+PC91PiZu YnNwOzx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNh bnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+TWlsZXN0b25lczo8dT48L3U+PHU+ PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJp ZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij48dT48L3U+Jm5ic3A7PHU+PC91Pjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMt c2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+RGVjIDIwMTQgU3VibWl0ICZxdW90O1Vz ZSBjYXNlcyBhbmQgUmVxdWlyZW1lbnRzJnF1b3Q7IGFzIGEgV0cgaXRlbS48dT48L3U+PHU+PC91 Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMt c2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+RGVjIDIwMTQgU3VibWl0ICZxdW90O0F1 dGhlbnRpY2F0aW9uIGFuZCBBdXRob3JpemF0aW9uIFNvbHV0aW9uJnF1b3Q7IGFzIGEgV0cgaXRl bS48dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5 OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPkFwciAyMDE1 IE9wdGlvbmFsbHksIHN1Ym1pdCAmcXVvdDtVc2UgY2FzZXMgYW5kIFJlcXVpcmVtZW50cyZxdW90 OyBkb2N1bWVudA0KPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsi PnRvIHRoZSBJRVNHIGZvciBwdWJsaWNhdGlvbiBhcyBhbiBJbmZvcm1hdGlvbmFsIFJGQy48dT48 L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu cy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij5KdWwgMjAxNiBTdWJtaXQgJnF1b3Q7 QXV0aGVudGljYXRpb24gYW5kIEF1dGhvcml6YXRpb24gU29sdXRpb24mcXVvdDs8dT48L3U+PHU+ PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJp ZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij5zcGVjaWZpY2F0aW9uIHRvIHRoZSBJRVNHIGZv ciBwdWJsaWNhdGlvbiBhcyBhIFByb3Bvc2VkIFN0YW5kYXJkLjx1PjwvdT48dT48L3U+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjog cmdiKDMxLCA3MywgMTI1KTsiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMC41 cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3Mywg MTI1KTsiPlByb3Bvc2VkIE1pbGVzdG9uZXMNCjx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAx MC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3 MywgMTI1KTsiPk5vIG1pbGVzdG9uZXMgZm9yIGNoYXJ0ZXIgZm91bmQuPHU+PC91Pjx1PjwvdT48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNv bG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEs IDczLCAxMjUpOyI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9u dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+ PHU+PC91PiZuYnNwOzx1PjwvdT48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNiNWM0ZGYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20g MGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdCI+5Y+R5Lu25Lq6PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9zcGFuPjwvYj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiBLYXRobGVlbiBNb3Jp YXJ0eSBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzprYXRobGVlbi5tb3JpYXJ0eS5pZXRmQGdtYWls LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmthdGhsZWVuLm1vcmlhcnR5LmlldGZAZ21haWwuY29tPC9h Pl0NCjxicj4NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+5Y+R6YCB 5pe26Ze0PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiAyMDE0PC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0Ij7lubQ8c3BhbiBsYW5nPSJFTi1VUyI+Njwvc3Bhbj7mnIg8c3BhbiBs YW5nPSJFTi1VUyI+Mzwvc3Bhbj7ml6U8c3BhbiBsYW5nPSJFTi1VUyI+IDE0OjMwPGJyPg0KPC9z cGFuPjxiPuaUtuS7tuS6ujxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5n PSJFTi1VUyI+IExpa2VwZW5nPGJyPg0KPC9zcGFuPjxiPuaKhOmAgTxzcGFuIGxhbmc9IkVOLVVT Ij46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IEJlbm9pdCBDbGFpc2U7IDxhIGhyZWY9 Im1haWx0bzphZHJpYW5Ab2xkZG9nLmNvLnVrIiB0YXJnZXQ9Il9ibGFuayI+DQphZHJpYW5Ab2xk ZG9nLmNvLnVrPC9hPjsgPGEgaHJlZj0ibWFpbHRvOmFhYS1kb2N0b3JzQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+YWFhLWRvY3RvcnNAaWV0Zi5vcmc8L2E+OyBUaGUgSUVTRzsNCjxhIGhyZWY9 Im1haWx0bzphY2VAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5hY2VAaWV0Zi5vcmc8L2E+PGJy Pg0KPC9zcGFuPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj48Yj7kuLvpopg8c3BhbiBsYW5nPSJF Ti1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBSZTogUmV2aXNlZCBjaGFydGVy IHByb3Bvc2FsOiBjaGFydGVyLWlldGYtYWNlLTAwLTAyPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9k aXY+DQo8L2Rpdj4NCjxwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3NwYW4+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5IaSBLZXBl bmcsPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj48dT48L3U+Jm5ic3A7PHU+PC91Pjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SWYgd2Ug YXJlIGF0IGEgcG9pbnQgd2hlcmUgSSBjYW4gdXBkYXRlIHRoZSBjaGFydGVyLCBzZWVtcyB0aGF0 IHdheSwgcGxlYXNlIHNlbmQgdGhlIGxhdGVzdCB2ZXJzaW9uIHRoYXQgaGFzIGJlZW4gYWdyZWVk IHVwb24gYW5kIEknbGwgdGFrZSBjYXJlIG9mIHRoZSB1cGRhdGUuPHU+PC91Pjx1PjwvdT48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGFua3MuPHU+PC91Pjx1Pjwv dT48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48dT48L3U+ Jm5ic3A7PHU+PC91Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPk9uIFR1ZSwgSnVuIDMsIDIwMTQgYXQgNjozMSBBTSwgTGlrZXBlbmcg Jmx0OzxhIGhyZWY9Im1haWx0bzpsaWtlcGVuZ0BodWF3ZWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+ bGlrZXBlbmdAaHVhd2VpLmNvbTwvYT4mZ3Q7IHdyb3RlOjx1PjwvdT48dT48L3U+PC9zcGFuPjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2Vy aWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+SGkgQmVub2l0LDwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyI+PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQt ZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPiZu YnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEs IDczLCAxMjUpOyI+Jmd0O05vdCBvbmx5IHdvdWxkIEkga2VlcCAmcXVvdDtBQUEmcXVvdDssDQo8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMC41 cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3Mywg MTI1KTsiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PHU+PC91Pjx1PjwvdT48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJp ZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij5PSy48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi Pjx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTog Q2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij4mbmJzcDs8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiPjx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7 IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1 KTsiPiZndDtidXQgSSB3b3VsZCBwcm9wb3NlPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48dT48 L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu cy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiPjx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5 OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPiZndDtPTEQ6 PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTAu NXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMs IDEyNSk7Ij4mZ3Q7RXhpc3RpbmcgYXV0aGVudGljYXRpb24gYW5kIGF1dGhvcml6YXRpb24gcHJv dG9jb2xzIHdpbGwgYmUgdXNlZCB3aGVyZTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PHU+PC91 Pjx1PjwvdT48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogQ2FsaWJy aSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij5hcHBsaWNhYmxlIHRvIGJ1 aWxkIHRoZSBjb25zdHJhaW5lZC1lbnZpcm9ubWVudCBzb2x1dGlvbi48L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiPjx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250 LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij4m bmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMx LCA3MywgMTI1KTsiPiZndDtORVc6PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48dT48L3U+PHU+ PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJp ZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij5FeGlzdGluZyBhdXRoZW50aWNhdGlvbiBhbmQg YXV0aG9yaXphdGlvbiBwcm90b2NvbHMgd2lsbCBiZSBldmFsdWF0ZWQgYW5kIHJlLXVzZWQgd2hl cmU8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiBy Z2IoMzEsIDczLCAxMjUpOyI+YXBwbGljYWJsZSB0byBidWlsZCB0aGUgY29uc3RyYWluZWQtZW52 aXJvbm1lbnQgc29sdXRpb24uPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48dT48L3U+PHU+PC91 Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsg Y29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi Pjx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJp LCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPk9LLCBmaW5lIHdpdGggbWUu PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTAu NXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMs IDEyNSk7Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjx1PjwvdT48dT48L3U+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xv cjogcmdiKDMxLCA3MywgMTI1KTsiPlRoYW5rcyBmb3IgdGhlIGZlZWRiYWNrLg0KPC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIj48dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250 LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij4m bmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMx LCA3MywgMTI1KTsiPktpbmQgUmVnYXJkczwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PHU+PC91 Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMt c2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+S2VwZW5nPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIj48dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTog Q2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij4mbmJzcDs8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiPjx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNiNWM0ZGYgMS4wcHQ7cGFk ZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdCI+5Y+R5Lu25Lq6PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3Nw YW4+PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQi PiBCZW5vaXQgQ2xhaXNlIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmJjbGFpc2VAY2lzY28uY29t IiB0YXJnZXQ9Il9ibGFuayI+YmNsYWlzZUBjaXNjby5jb208L2E+XQ0KPGJyPg0KPC9zcGFuPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij7lj5HpgIHml7bpl7Q8c3BhbiBsYW5nPSJF Ti1VUyI+Ojwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdCI+IDIwMTQ8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPuW5 tDxzcGFuIGxhbmc9IkVOLVVTIj42PC9zcGFuPuaciDxzcGFuIGxhbmc9IkVOLVVTIj4zPC9zcGFu PuaXpTxzcGFuIGxhbmc9IkVOLVVTIj4gMTI6MTY8L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIj48dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+5pS25Lu25Lq6PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9 IkVOLVVTIj4gTGlrZXBlbmc7IEthdGhsZWVuIE1vcmlhcnR5Ow0KPGEgaHJlZj0ibWFpbHRvOmFk cmlhbkBvbGRkb2cuY28udWsiIHRhcmdldD0iX2JsYW5rIj5hZHJpYW5Ab2xkZG9nLmNvLnVrPC9h Pjx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+5oqE6YCBPHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVT Ij4gPGEgaHJlZj0ibWFpbHRvOmFhYS1kb2N0b3JzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ DQphYWEtZG9jdG9yc0BpZXRmLm9yZzwvYT47IFRoZSBJRVNHOyA8YSBocmVmPSJtYWlsdG86YWNl QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQphY2VAaWV0Zi5vcmc8L2E+PHU+PC91Pjx1Pjwv dT48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPuS4u+mimDxzcGFu IGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IFJlOiBSZXZpc2Vk IGNoYXJ0ZXIgcHJvcG9zYWw6IGNoYXJ0ZXItaWV0Zi1hY2UtMDAtMDI8dT48L3U+PHU+PC91Pjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4g bGFuZz0iRU4tVVMiPkhpLCA8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5IZWxsbyBhbGwsPHU+PC91Pjx1Pjwv dT48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8dT48L3U+PHU+ PC91Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPkJhc2VkIG9uIHJlY2Vu dCBkaXNjdXNzaW9ucywgSSBtYWRlIGEgcmV2aXNlZCBjaGFydGVyIHByb3Bvc2FsLCBhcyBpbmNs dWRlZCBpbiB0aGlzIGVtYWlsLCBub3Qgb24gdGhlIHdlYnBhZ2UgeWV0LiA8dT48L3U+PHU+PC91 Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzx1PjwvdT48dT48 L3U+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+UGxlYXNlIHRha2UgYSBs b29rIGFuZCBsZXQgdXMga25vdyBpZiB5b3UgaGF2ZSBhbnkgZnVydGhlciBjb21tZW50cy48dT48 L3U+PHU+PC91Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzx1 PjwvdT48dT48L3U+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+QEFkcmlh biBhbmQgQEJlbm9pdCwgcGxlYXNlIGNoZWNrIGlmIHRoZSBwcm9wb3NlZCB0ZXh0cyBjYW4gcmVz b2x2ZSB5b3VyIGNvbW1lbnRzLjx1PjwvdT48dT48L3U+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh biBsYW5nPSJFTi1VUyI+Jm5ic3A7PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wcmU+DQo8cHJlPjxz cGFuIGxhbmc9IkVOLVVTIj5UaGFua3MsPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wcmU+DQo8cHJl PjxzcGFuIGxhbmc9IkVOLVVTIj5LaW5kIFJlZ2FyZHM8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3By ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPktlcGVuZzx1PjwvdT48dT48L3U+PC9zcGFuPjwv cHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PHU+PC91Pjx1PjwvdT48L3NwYW4+ PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu IGxhbmc9IkVOLVVTIj5Db21wYXJlZCB3aXRoIGNoYXJ0ZXItaWV0Zi1hY2UtMDAtMDEgb24gdGhl IHdlYnBhZ2UsIHRoZSBjaGFuZ2VzIGFyZTo8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3ByZT4NCjxw cmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzx1PjwvdT48dT48L3U+PC9zcGFuPjwvcHJlPg0K PHByZT48c3BhbiBsYW5nPSJFTi1VUyI+KDEpJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IEFkZCBvbmUgY2xhcmlmaWNhdGlvbiBzZW50ZW5jZSBhYm91dCBSRVNUIGFyY2hpdGVjdHVyZTo8 dT48L3U+PHU+PC91Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPk9MRDx1 PjwvdT48dT48L3U+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+VGhlIElF VEYgaGFzIHJlY2VudGx5IGRldmVsb3BlZCBwcm90b2NvbHMgZm9yIHVzZSBpbiBjb25zdHJhaW5l ZDx1PjwvdT48dT48L3U+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+ZW52 aXJvbm1lbnRzLCB3aGVyZSBuZXR3b3JrIG5vZGVzIGFyZSBsaW1pdGVkIGluIENQVSwgbWVtb3J5 IGFuZCBwb3dlci4gPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9 IkVOLVVTIj5SRVNUIGFyY2hpdGVjdHVyZSBpcyB3aWRlbHkgdXNlZCBmb3Igc3VjaCBjb25zdHJh aW5lZCBlbnZpcm9ubWVudHMuPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu IGxhbmc9IkVOLVVTIj4mbmJzcDs8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw YW4gbGFuZz0iRU4tVVMiPk5FVzx1PjwvdT48dT48L3U+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh biBsYW5nPSJFTi1VUyI+VGhlIElFVEYgaGFzIHJlY2VudGx5IGRldmVsb3BlZCBwcm90b2NvbHMg Zm9yIHVzZSBpbiBjb25zdHJhaW5lZDx1PjwvdT48dT48L3U+PC9zcGFuPjwvcHJlPg0KPHByZT48 c3BhbiBsYW5nPSJFTi1VUyI+ZW52aXJvbm1lbnRzLCB3aGVyZSBuZXR3b3JrIG5vZGVzIGFyZSBs aW1pdGVkIGluIENQVSwgbWVtb3J5IGFuZCBwb3dlci48dT48L3U+PHU+PC91Pjwvc3Bhbj48L3By ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPlJFU1QgYXJjaGl0ZWN0dXJlIGlzIHdpZGVseSB1 c2VkIGZvciBzdWNoIGNvbnN0cmFpbmVkIGVudmlyb25tZW50cy48dT48L3U+PHU+PC91Pjwvc3Bh bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPkVORDx1PjwvdT48dT48L3U+PC9zcGFu PjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPkNvbnNpZGVyaW5nIHRoYXQgT0xEIGlzPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0K PHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZh bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij5PTEQ8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjx1PjwvdT48dT48L3U+PC9zcGFuPjwvcHJlPg0KPHBy ZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWls eTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij5UaGUgSUVU RiBoYXMgcmVjZW50bHkgZGV2ZWxvcGVkIHByb3RvY29scyBmb3IgdXNlIGluIGNvbnN0cmFpbmVk PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48dT48L3U+PHU+PC91Pjwvc3Bhbj48L3ByZT4NCjxw cmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1p bHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+ZW52aXJv bm1lbnRzLCB3aGVyZSBuZXR3b3JrIG5vZGVzIGFyZSBsaW1pdGVkIGluIENQVSwgbWVtb3J5IGFu ZCBwb3dlci4gPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48dT48L3U+PHU+PC91Pjwvc3Bhbj48 L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ PHNwYW4gbGFuZz0iRU4tVVMiPi4uLiBmaW5lIHdpdGggbWU8dT48L3U+PHU+PC91Pjwvc3Bhbj48 L3A+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8dT48L3U+PHU+PC91Pjwvc3Bhbj48 L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzx1PjwvdT48dT48L3U+PC9zcGFu PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+KDIpJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IFJlbW92ZSA8L3NwYW4+4oCcPHNwYW4gbGFuZz0iRU4tVVMiPkFBQSBwcm90b2NvbDwvc3Bh bj7igJ08c3BhbiBsYW5nPSJFTi1VUyI+IGZyb20gdGhlIGNoYXJ0ZXI6PHU+PC91Pjx1PjwvdT48 L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5PTEQ8dT48L3U+PHU+PC91Pjwv c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPlRoZSBJRVRGIGhhcyBhIGxvbmcg aGlzdG9yeSBpbiBkZXZlbG9waW5nIHRocmVlLXBhcnR5IGF1dGhlbnRpY2F0aW9uIGFuZDx1Pjwv dT48dT48L3U+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+YXV0aG9yaXph dGlvbiBwcm90b2NvbHMgZm9yIGRpc3RyaWJ1dGVkIGVudmlyb25tZW50cy4gRXhhbXBsZXMgaW5j bHVkZTx1PjwvdT48dT48L3U+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+ S2VyYmVyb3MsIHRoZSBQdWJsaWMgS2V5IEluZnJhc3RydWN0dXJlIChQS0kpLCB0aGUgQXV0aGVu dGljYXRpb24sPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVO LVVTIj5BdXRob3JpemF0aW9uIGFuZCBBY2NvdW50aW5nIChBQUEpIGluZnJhc3RydWN0dXJlLCBh bmQgdGhlIFdlYjx1PjwvdT48dT48L3U+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJF Ti1VUyI+QXV0aG9yaXphdGlvbiBQcm90b2NvbCAoT0F1dGgpLjx1PjwvdT48dT48L3U+PC9zcGFu PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PHU+PC91Pjx1PjwvdT48L3Nw YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5ORVc8dT48L3U+PHU+PC91Pjwvc3Bh bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPlRoZSBJRVRGIGhhcyBhIGxvbmcgaGlz dG9yeSBpbiBkZXZlbG9waW5nIHRocmVlLXBhcnR5IGF1dGhlbnRpY2F0aW9uIGFuZDx1PjwvdT48 dT48L3U+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+YXV0aG9yaXphdGlv biBwcm90b2NvbHMgZm9yIGRpc3RyaWJ1dGVkIGVudmlyb25tZW50cy4gRXhhbXBsZXMgaW5jbHVk ZTx1PjwvdT48dT48L3U+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+S2Vy YmVyb3MsIHRoZSBQdWJsaWMgS2V5IEluZnJhc3RydWN0dXJlIChQS0kpLCBhbmQgdGhlIFdlYiBB dXRob3JpemF0aW9uIFByb3RvY29sIChPQXV0aCkuPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wcmU+ DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5FTkQ8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3ByZT4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5XZSBoYXZlIEFBQS1kb2N0 b3JzIHRlbGxpbmc6IG1heWJlIFJBRElVUyBpcyBhcHBsaWNhYmxlPzxicj4NClBlcnNvbmFsbHks IEkgZG9uJ3Qga25vdyBhbmQgaXQgZG9lc24ndCBtYXR0ZXIgYXQgdGhpcyBwb2ludC48YnI+DQpX ZSByZWNlaXZlZCBmZWVkYmFjayBzdWNoIGFzOjx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5MZXQncyBiZSBjbGVhciBoZXJl OiBJdCB3YXMgbmV2ZXIgc2FpZCAoaW4gdGhlIGNoYXJ0ZXIgb3IgYW55d2hlcmUgZWxzZSBpbiB0 aGUgZ3JvdXAgdG8gbXkga25vd2xlZGdlKSB0aGF0IFJBRElVUyAob3IgaW5kZWVkIGFueSBvdGhl ciBBQUEgcHJvdG9jb2wpIHdvdWxkIG5vdCBydW4gb24gY29uc3RyYWluZWQgZGV2aWNlcyAoUkZD IDcyMjgpLiBUaGUgY2hhcnRlciBzaW1wbHkNCiBzYWlkIHRoZSBwcm90b2NvbHMgd2VyZSBub3Qg b3B0aW1pc2VkIGZvciBjb25zdHJhaW5lZCBkZXZpY2VzLiBUaGF0IGRvZXMgbm90IHByZWNsdWRl IGNvbnNpZGVyaW5nIGFueSBwcm90b2NvbCBmb3Igc3VpdGFiaWxpdHkgZm9yIGNvbnN0cmFpbmVk IGRldmljZXMgZWl0aGVyIGEpIGFzIGlzLCBiKSBpbiBhIHJlc3RyaWN0ZWQgd2F5IG9yIGMpIGlu IGFuIGFkYXB0ZWQgd2F5Ljxicj4NCjxicj4NClNvLCBhdCB0aGlzIHN0YWdlLCBJIGRvbid0IHRo aW5rIGFueSBwcm90b2NvbHMgc2hvdWxkIGJlIGV4Y2x1ZGVkIGZyb20gY29uc2lkZXJhdGlvbiBh bmQgc2hvdWxkIGNlcnRhaW5seSBub3QgYmUgZWxpbWluYXRlZCBvbiBhIGh1bmNoIHRoYXQgdGhl eSBtaWdodCBiZSAmcXVvdDt0b28gYmlnJnF1b3Q7LiBMZXQncyBkbyB0aGUgYXNzZXNzbWVudCBw cm9wZXJseSBhdCB0aGUgYXBwcm9wcmlhdGUgdGltZS4gQXMgYSByZW1pbmRlciAtIHRoZSBmb2N1 cyBub3cgaXMgdG8NCiBjb21wbGV0ZSB0aGUgY2hhcnRlci48dT48L3U+PHU+PC91Pjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+T3I8dT48L3U+PHU+ PC91Pjwvc3Bhbj48L3A+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7Jmd0O1RoZSBDaGFy dGVyIG1ha2VzIGEgbnVtYmVyIG9mIGFzc2VydGlvbnMgdGhhdCBhcmUgcHJvdmFibHkgZmFsc2Us IHN1Y2ggYXMgdGhhdCBBQUEgcHJvdG9jb2xzIGFyZSBpbmFwcHJvcHJpYXRlIGZvciBjb25zdHJh aW5lZCBlbnZpcm9ubWVudHMuPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu IGxhbmc9IkVOLVVTIj5JbiBmYWN0LCB0aGUgY2hhcnRlciBkb2VzIG5vdCBzYXkgdGhhdC4gQnV0 IHRvIGF2b2lkIGNvbmZ1c2lvbiwgbGV0J3MgcmVtb3ZlIEFBQSBwcm90b2NvbCBmcm9tIHRoZSBj aGFydGVyLjx1PjwvdT48dT48L3U+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1V UyI+Jm5ic3A7PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVO LVVTIj5JbiB0aGUgY2hhcnRlciwgd2UgbWVudGlvbmVkIHRoYXQgd2Ugd2FudCB0byByZXVzZSBl eGlzdGluZyBhdXRoZW50aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlvbiBwcm90b2NvbHMgd2hlcmUg YXBwbGljYWJsZSB0byBidWlsZCB0aGUgY29uc3RyYWluZWQtZW52aXJvbm1lbnQgc29sdXRpb24u PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4uLi4gd2hpY2ggSSByZWFk IGFzOiBsZXQncyBjb25zaWRlciB0aGUgQUFBIHByb3RvY29scywgYW5kIGV2YWx1YXRlIGlmIHRo ZXkgd291bGQgd29yayBpbiBjb25zdHJhaW5lZCBkZXZpY2VzLjxicj4NCkkgZG9uJ3QgdW5kZXJz dGFuZCB0aGUgbG9naWM6IHdoeSBkbyB5b3Ugd2FudCB0byByZW1vdmUgQUFBIGZyb20gdGhlIGNo YXJ0ZXI/PGJyPg0KTm90IG9ubHkgd291bGQgSSBrZWVwICZxdW90O0FBQSZxdW90OywgYnV0IEkg d291bGQgcHJvcG9zZTxicj4NCjxicj4NCk9MRDo8YnI+DQpFeGlzdGluZyBhdXRoZW50aWNhdGlv biBhbmQgYXV0aG9yaXphdGlvbiBwcm90b2NvbHMgd2lsbCBiZSB1c2VkIHdoZXJlPGJyPg0KYXBw bGljYWJsZSB0byBidWlsZCB0aGUgY29uc3RyYWluZWQtZW52aXJvbm1lbnQgc29sdXRpb248YnI+ DQo8YnI+DQpORVc6PGJyPg0KRXhpc3RpbmcgYXV0aGVudGljYXRpb24gYW5kIGF1dGhvcml6YXRp b24gcHJvdG9jb2xzIHdpbGwgYmUgZXZhbHVhdGVkIGFuZCByZS11c2VkIHdoZXJlPGJyPg0KYXBw bGljYWJsZSB0byBidWlsZCB0aGUgY29uc3RyYWluZWQtZW52aXJvbm1lbnQgc29sdXRpb248YnI+ DQo8YnI+DQpSZWdhcmRzLCBCZW5vaXQ8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8cHJlPjxz cGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3ByZT4NCjxwcmU+ PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzx1PjwvdT48dT48L3U+PC9zcGFuPjwvcHJlPg0KPHBy ZT48c3BhbiBsYW5nPSJFTi1VUyI+KDMpIENsYXJpZnkgdGhlIHNjb3BlOjx1PjwvdT48dT48L3U+ PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+T0xEOjx1PjwvdT48dT48L3U+ PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Tm90ZSB0aGF0IHRoZSBpbml0 aWFsIGZvY3VzIGlzIG9uIENvQVAgYW5kIEhUVFAgd2l0aCBEVExTIGFuZCBUTFMuPHU+PC91Pjx1 PjwvdT48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5PdGhlciBzZWN1cml0 eSBwcm90b2NvbHMgbWF5IGJlIGNvbnNpZGVyZWQgYXMgbG9uZyBhcyB0aGUgcHJpbWFyeSBmb2N1 cyBpcyBtYWludGFpbmVkLiZuYnNwOyA8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3ByZT4NCjxwcmU+ PHNwYW4gbGFuZz0iRU4tVVMiPk90aGVyIGFwcGxpY2F0aW9uIHByb3RvY29scyBhbmQgcHJvdG9j b2xzIGF0IG90aGVyIGxheWVycyBpbiB0aGUgc3RhY2sgYXJlIG91dCBvZiBzY29wZS48dT48L3U+ PHU+PC91Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzx1Pjwv dT48dT48L3U+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+TkVXPHU+PC91 Pjx1PjwvdT48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5Ob3RlIHRoYXQg dGhlIGluaXRpYWwgZm9jdXMgaXMgb24gQ29BUCBhbmQgSFRUUCB3aXRoIERUTFMgYW5kIFRMUy48 dT48L3U+PHU+PC91Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPk90aGVy IHNlY3VyaXR5IHByb3RvY29scyBtYXkgYmUgY29uc2lkZXJlZCBhcyBsb25nIGFzIHRoZSBwcmlt YXJ5IGZvY3VzIGlzIG1haW50YWluZWQuJm5ic3A7IDx1PjwvdT48dT48L3U+PC9zcGFuPjwvcHJl Pg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+VGhlIGdyb3VwIGlzIHNjb3BlZCB0byB3b3JrIG9u bHkgb24gdGhlIHdlYiBwcm90b2NvbHMgYW5kIGRhdGEgY2FycmllZCB3aXRoaW4gdGhlbS48dT48 L3U+PHU+PC91Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPkVORDx1Pjwv dT48dT48L3U+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PHU+ PC91Pjx1PjwvdT48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4oNCkmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgVXBkYXRlIG1pbGVzdG9uZXMgZm9yIHRoZSB1c2UgY2FzZSAm YW1wOyByZXF1aXJlbWVudHMgZG9jdW1lbnQ6PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wcmU+DQo8 cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5PTEQ6PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wcmU+DQo8 cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5KdWwgMjAxNSBTdWJtaXQgPC9zcGFuPuKAnDxzcGFuIGxh bmc9IkVOLVVTIj5Vc2UgY2FzZXMgYW5kIFJlcXVpcmVtZW50czwvc3Bhbj7igJ08c3BhbiBsYW5n PSJFTi1VUyI+IGRvY3VtZW50IHRvIElFU0cgZm9yIHB1YmxpY2F0aW9uIGFzIGluZm9ybWF0aW9u YWwgUkZDLjx1PjwvdT48dT48L3U+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1V UyI+Jm5ic3A7PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVO LVVTIj5ORVc8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4t VVMiPkRlYyAyMDE0IE9wdGlvbmFsbHksIHN1Ym1pdCAmcXVvdDtVc2UgY2FzZXMgYW5kIFJlcXVp cmVtZW50cyZxdW90OyBkb2N1bWVudCB0byB0aGUgSUVTRyBmb3IgcHVibGljYXRpb24gYXMgYW4g SW5mb3JtYXRpb25hbCBSRkMuPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu IGxhbmc9IkVOLVVTIj5FTkQ8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g bGFuZz0iRU4tVVMiPiZuYnNwOzx1PjwvdT48dT48L3U+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh biBsYW5nPSJFTi1VUyI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLTx1PjwvdT48dT48L3U+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs YW5nPSJFTi1VUyI+Q2hhcnRlciBjaGFydGVyLWlldGYtYWNlLTAwLTAyPHU+PC91Pjx1PjwvdT48 L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5BdXRoZW50aWNhdGlvbiBhbmQg QXV0aG9yaXphdGlvbiBmb3IgQ29uc3RyYWluZWQ8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3ByZT4N CjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPkVudmlyb25tZW50IChBQ0UpPHU+PC91Pjx1PjwvdT48 L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8dT48L3U+PHU+PC91 Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPlRoZSBJRVRGIGhhcyByZWNl bnRseSBkZXZlbG9wZWQgcHJvdG9jb2xzIGZvciB1c2UgaW4gY29uc3RyYWluZWQ8dT48L3U+PHU+ PC91Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPmVudmlyb25tZW50cywg d2hlcmUgbmV0d29yayBub2RlcyBhcmUgbGltaXRlZCBpbiBDUFUsIG1lbW9yeSBhbmQgcG93ZXIu IDx1PjwvdT48dT48L3U+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+UkVT VCBhcmNoaXRlY3R1cmUgaXMgd2lkZWx5IHVzZWQgZm9yIHN1Y2ggY29uc3RyYWluZWQgZW52aXJv bm1lbnRzLjx1PjwvdT48dT48L3U+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1V UyI+SXQgaGFzIGJlZW4gb2JzZXJ2ZWQgdGhhdCBJbnRlcm5ldCBwcm90b2NvbHMgY2FuIGJlIGFw cGxpZWQgdG8gdGhlc2U8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFu Zz0iRU4tVVMiPmNvbnN0cmFpbmVkIGVudmlyb25tZW50cywgb2Z0ZW4gb25seSByZXF1aXJpbmcg bWlub3IgdHdlYWtpbmcgYW5kPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu IGxhbmc9IkVOLVVTIj5wcm9maWxpbmcuIEluIG90aGVyIGNhc2VzLCBuZXcgcHJvdG9jb2xzIGhh dmUgYmVlbiBkZWZpbmVkIHRvIGFkZHJlc3M8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3ByZT4NCjxw cmU+PHNwYW4gbGFuZz0iRU4tVVMiPnRoZSBzcGVjaWZpYyByZXF1aXJlbWVudHMgb2YgY29uc3Ry YWluZWQgZW52aXJvbm1lbnRzLiBBbiBleGFtcGxlIG9mPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9w cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5zdWNoIGEgcHJvdG9jb2wgaXMgdGhlIENvbnN0 cmFpbmVkIEFwcGxpY2F0aW9uIFByb3RvY29sIChDb0FQKS48dT48L3U+PHU+PC91Pjwvc3Bhbj48 L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzx1PjwvdT48dT48L3U+PC9zcGFu PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+QXMgaW4gb3RoZXIgZW52aXJvbm1lbnRz LCBhdXRoZW50aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlvbiBxdWVzdGlvbnM8dT48L3U+PHU+PC91 Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPmFsc28gYXJpc2UgaW4gY29u c3RyYWluZWQgZW52aXJvbm1lbnRzLiBGb3IgZXhhbXBsZSwgYSBkb29yIGxvY2sgaGFzIHRvPHU+ PC91Pjx1PjwvdT48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5hdXRob3Jp emUgdGhlIHBlcnNvbiBzZWVraW5nIGFjY2VzcyB1c2luZyBhICZxdW90O2RpZ2l0YWwga2V5JnF1 b3Q7LiBXaGVyZSBpcyB0aGU8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g bGFuZz0iRU4tVVMiPmF1dGhvcml6YXRpb24gcG9saWN5IHN0b3JlZD8gSG93IGRvZXMgdGhlIGRp Z2l0YWwga2V5IGNvbW11bmljYXRlIHdpdGg8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3ByZT4NCjxw cmU+PHNwYW4gbGFuZz0iRU4tVVMiPnRoZSBsb2NrPyBEb2VzIHRoZSBsb2NrIGludGVyYWN0IHdp dGggYW4gYXV0aG9yaXphdGlvbiBzZXJ2ZXIgdG8gb2J0YWluPHU+PC91Pjx1PjwvdT48L3NwYW4+ PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5hdXRob3JpemF0aW9uIGluZm9ybWF0aW9u PyBIb3cgY2FuIGFjY2VzcyBiZSB0ZW1wb3JhcmlseSBncmFudGVkIHRvPHU+PC91Pjx1PjwvdT48 L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5vdGhlciBwZXJzb25zPyBIb3cg Y2FuIGFjY2VzcyBiZSByZXZva2VkPyBUaGVzZSB0eXBlcyBvZiBxdWVzdGlvbnMgaGF2ZTx1Pjwv dT48dT48L3U+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+YmVlbiBhbnN3 ZXJlZCBieSBleGlzdGluZyBwcm90b2NvbHMgZm9yIHVzZSBjYXNlcyBvdXRzaWRlIGNvbnN0cmFp bmVkPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5l bnZpcm9ubWVudHMsIGhvd2V2ZXIgaW4gY29uc3RyYWluZWQgZW52aXJvbm1lbnRzLCBhZGRpdGlv bmFsIGFuZDx1PjwvdT48dT48L3U+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1V UyI+ZGlmZmVyZW50IHJlcXVpcmVtZW50cyBwb3NlIGNoYWxsZW5nZXMgZm9yIHRoZSB1c2Ugb2Yg dmFyaW91cyBzZWN1cml0eTx1PjwvdT48dT48L3U+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs YW5nPSJFTi1VUyI+cHJvdG9jb2xzLiBJbiBwYXJ0aWN1bGFyLCB0aGUgbmVlZCBhcmlzZXMgZm9y IGEgZHluYW1pYyBhbmQgZmluZSBncmFpbmVkPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wcmU+DQo8 cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5hY2Nlc3MgY29udHJvbCBtZWNoYW5pc20sIHdoZXJlIGNs aWVudHMgYW5kL29yIHJlc291cmNlIHNlcnZlcnMgYXJlPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9w cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5jb25zdHJhaW5lZC48dT48L3U+PHU+PC91Pjwv c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzx1PjwvdT48dT48L3U+ PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+VGhlIElFVEYgaGFzIGEgbG9u ZyBoaXN0b3J5IGluIGRldmVsb3BpbmcgdGhyZWUtcGFydHkgYXV0aGVudGljYXRpb24gYW5kPHU+ PC91Pjx1PjwvdT48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5hdXRob3Jp emF0aW9uIHByb3RvY29scyBmb3IgZGlzdHJpYnV0ZWQgZW52aXJvbm1lbnRzLiBFeGFtcGxlcyBp bmNsdWRlPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVT Ij5LZXJiZXJvcywgdGhlIFB1YmxpYyBLZXkgSW5mcmFzdHJ1Y3R1cmUgKFBLSSksIGFuZCB0aGUg V2ViPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5B dXRob3JpemF0aW9uIFByb3RvY29sIChPQXV0aCkuIEFsbCB0aGVzZSBwcm90b2NvbHMgZW5qb3kg d2lkZXNwcmVhZDx1PjwvdT48dT48L3U+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJF Ti1VUyI+ZGVwbG95bWVudCBvbiB0aGUgSW50ZXJuZXQuIEFsdGhvdWdoIHRoZXkgYWxsIGFpbSB0 byBzb2x2ZSBhIHNpbWlsYXI8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g bGFuZz0iRU4tVVMiPmdvYWwsIGF0IGFuIGFic3RyYWN0IGxldmVsLCB0aGV5IG9mZmVyIHF1aXRl IGRpZmZlcmVudCBmdW5jdGlvbnMgYW5kPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wcmU+DQo8cHJl PjxzcGFuIGxhbmc9IkVOLVVTIj51dGlsaXplIGRpZmZlcmVudCBtZXNzYWdlIGV4Y2hhbmdlcy4g VGhlc2UgZGlmZmVyZW5jZXMgcmVzdWx0IGZyb20gdGhlPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9w cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5tYWluIGRlcGxveW1lbnQgdXNlIGNhc2VzIHRo ZXkgd2VyZSBkZXNpZ25lZCBmb3IgcmVzcGVjdGl2ZWx5Ljx1PjwvdT48dT48L3U+PC9zcGFuPjwv cHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PHU+PC91Pjx1PjwvdT48L3NwYW4+ PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5SZXF1aXJlbWVudHMgZGVyaXZlZCBmcm9t IHVzZSBjYXNlcyBpbmRpY2F0ZSB0aGUgc3VpdGFiaWxpdHkgb2YgZXhpc3Rpbmc8dT48L3U+PHU+ PC91Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPndvcmsgYXMgYSBzb2x1 dGlvbiBmb3IgY29uc3RyYWluZWQgZW52aXJvbm1lbnRzLiBUaGVzZSBwcm90b2NvbHMsPHU+PC91 Pjx1PjwvdT48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5ob3dldmVyLCB3 ZXJlIG5vdCBvcHRpbWl6ZWQgZm9yIGNvbnN0cmFpbmVkIGVudmlyb25tZW50cy4gQWRkaXRpb25h bDx1PjwvdT48dT48L3U+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+cmVx dWlyZW1lbnRzIHRoYXQgbmVlZCB0byBiZSB0YWtlbiBpbnRvIGFjY291bnQgYXJlIHRoZSBsYWNr IG9mIGE8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMi PnN1aXRhYmxlIHVzZXItaW50ZXJmYWNlIGFuZCB0aGUgaW5hYmlsaXR5IG9mIGVtYmVkZGVkIGRl dmljZXMgdG8gY29udGFjdDx1PjwvdT48dT48L3U+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs YW5nPSJFTi1VUyI+YW4gYXV0aG9yaXphdGlvbiBzZXJ2ZXIgaW4gcmVhbC10aW1lIHdpdGggZXZl cnkgcmVzb3VyY2UgYWNjZXNzIHJlcXVlc3Q8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3ByZT4NCjxw cmU+PHNwYW4gbGFuZz0iRU4tVVMiPmR1ZSB0byBpbnRlcm1pdHRlbnQgY29ubmVjdGl2aXR5LCBl dGMuPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4m bmJzcDs8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMi PlRoaXMgd29ya2luZyBncm91cCB0aGVyZWZvcmUgYWltcyB0byBwcm9kdWNlIGEgc3RhbmRhcmRp emVkIHNvbHV0aW9uIGZvcjx1PjwvdT48dT48L3U+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs YW5nPSJFTi1VUyI+YXV0aGVudGljYXRpb24gYW5kIGF1dGhvcml6YXRpb24gdG8gZW5hYmxlIGF1 dGhvcml6ZWQgYWNjZXNzIChHRVQsIFBVVCwgUE9TVCwgPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9w cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5ERUxFVEUpIHRvIHJlc291cmNlcyBpZGVudGlm aWVkIGJ5IGEgVVJJIGFuZCBob3N0ZWQgb24gYSByZXNvdXJjZTx1PjwvdT48dT48L3U+PC9zcGFu PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+c2VydmVyIGluIGNvbnN0cmFpbmVkIGVu dmlyb25tZW50cy4gQXMgYSBzdGFydGluZyBwb2ludCwgdGhlIHdvcmtpbmc8dT48L3U+PHU+PC91 Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPmdyb3VwIHdpbGwgYXNzdW1l IHRoYXQgYWNjZXNzIHRvIHJlc291cmNlcyBhdCBhIHJlc291cmNlIHNlcnZlciBieSBhPHU+PC91 Pjx1PjwvdT48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5jbGllbnQgZGV2 aWNlIHRha2VzIHBsYWNlIHVzaW5nIENvQVAgYW5kIGlzIHByb3RlY3RlZCBieSBEVExTLiBCb3Ro PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5yZXNv dXJjZSBzZXJ2ZXIgYW5kIGNsaWVudCBtYXkgYmUgY29uc3RyYWluZWQuIFRoaXMgYWNjZXNzIHdp bGwgYmU8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMi Pm1lZGlhdGVkIGJ5IGFuIGF1dGhvcml6YXRpb24gc2VydmVyLCB3aGljaCBpcyBub3QgY29uc2lk ZXJlZCB0byBiZTx1PjwvdT48dT48L3U+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJF Ti1VUyI+Y29uc3RyYWluZWQuPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu IGxhbmc9IkVOLVVTIj4mbmJzcDs8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw YW4gbGFuZz0iRU4tVVMiPkV4aXN0aW5nIGF1dGhlbnRpY2F0aW9uIGFuZCBhdXRob3JpemF0aW9u IHByb3RvY29scyB3aWxsIGJlIHVzZWQgd2hlcmU8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3ByZT4N CjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPmFwcGxpY2FibGUgdG8gYnVpbGQgdGhlIGNvbnN0cmFp bmVkLWVudmlyb25tZW50IHNvbHV0aW9uLiBUaGlzIHJlcXVpcmVzPHU+PC91Pjx1PjwvdT48L3Nw YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5yZWxldmFudCBzcGVjaWZpY2F0aW9u cyB0byBiZSByZXZpZXdlZCBmb3Igc3VpdGFiaWxpdHksIHNlbGVjdGluZyBhPHU+PC91Pjx1Pjwv dT48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5zdWJzZXQgb2YgdGhlbSBh bmQgcmVzdHJpY3RpbmcgdGhlIG9wdGlvbnMgd2l0aGluIGVhY2ggb2YgdGhlPHU+PC91Pjx1Pjwv dT48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5zcGVjaWZpY2F0aW9ucy4g U29tZSBmdW5jdGlvbmFsaXR5LCBob3dldmVyLCBtYXkgbm90IGJlIGF2YWlsYWJsZSBpbjx1Pjwv dT48dT48L3U+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+ZXhpc3Rpbmcg cHJvdG9jb2xzLCBpbiB3aGljaCBjYXNlIHRoZSBzb2x1dGlvbiBtYXkgYWxzbyBpbnZvbHZlIG5l dzx1PjwvdT48dT48L3U+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+cHJv dG9jb2wgd29yay4gTGV2ZXJhZ2luZyBleGlzdGluZyB3b3JrIG1lYW5zIHRoZSB3b3JraW5nIGdy b3VwIGJlbmVmaXRzPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9 IkVOLVVTIj5mcm9tIGF2YWlsYWJsZSBzZWN1cml0eSBhbmFseXNpcywgaW1wbGVtZW50YXRpb24s IGFuZCBkZXBsb3ltZW50PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh bmc9IkVOLVVTIj5leHBlcmllbmNlLiBNb3Jlb3ZlciwgYSBzdGFuZGFyZGl6ZWQgc29sdXRpb24g Zm9yIGZlZGVyYXRlZDx1PjwvdT48dT48L3U+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5n PSJFTi1VUyI+YXV0aGVudGljYXRpb24gYW5kIGF1dGhvcml6YXRpb24gd2lsbCBoZWxwIHRvIHN0 aW11bGF0ZSB0aGUgZGVwbG95bWVudDx1PjwvdT48dT48L3U+PC9zcGFuPjwvcHJlPg0KPHByZT48 c3BhbiBsYW5nPSJFTi1VUyI+b2YgY29uc3RyYWluZWQgZGV2aWNlcyB0aGF0IHByb3ZpZGUgaW5j cmVhc2VkIHNlY3VyaXR5Ljx1PjwvdT48dT48L3U+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs YW5nPSJFTi1VUyI+Jm5ic3A7PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu IGxhbmc9IkVOLVVTIj5PbmNlIHByb2dyZXNzIGluIGlkZW50aWZ5aW5nIHN1aXRhYmxlIGNhbmRp ZGF0ZSBzb2x1dGlvbnMgaGFzIGJlZW4gbWFkZSw8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3ByZT4N CjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPnRoZSB3b3JraW5nIGdyb3VwIHdpbGwgdmVyaWZ5IHdo ZXRoZXIgdGhlIHNhbWUgbWVjaGFuaXNtcyBhcmUgYWxzbzx1PjwvdT48dT48L3U+PC9zcGFuPjwv cHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+YXBwbGljYWJsZSBiZXlvbmQgdGhlIHVzZSBv ZiBDb0FQIGFuZCBEVExTLCB3aGljaCBhcmUgdGhlIHR3byBtYWluPHU+PC91Pjx1PjwvdT48L3Nw YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5wcm90b2NvbHMgdGhlIGdyb3VwIHdp bGwgZm9jdXMgb24gZm9yIGFjY2VzcyB0byByZXNvdXJjZXMuIEluPHU+PC91Pjx1PjwvdT48L3Nw YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5wYXJ0aWN1bGFyLCB0aGUgYWJpbGl0 eSB0byB1c2UgdGhlIGRldmVsb3BlZCBzb2x1dGlvbiBvdmVyIEhUVFAgYW5kIFRMUzx1PjwvdT48 dT48L3U+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+d2lsbCBiZSBpbnZl c3RpZ2F0ZWQuIE5vdGUgdGhhdCB0aGUgaW5pdGlhbCBmb2N1cyBpcyBvbiBDb0FQIGFuZCBIVFRQ IHdpdGggRFRMUyBhbmQgVExTLjx1PjwvdT48dT48L3U+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh biBsYW5nPSJFTi1VUyI+T3RoZXIgc2VjdXJpdHkgcHJvdG9jb2xzIG1heSBiZSBjb25zaWRlcmVk IGFzIGxvbmcgYXMgdGhlIHByaW1hcnkgZm9jdXMgaXMgbWFpbnRhaW5lZC4mbmJzcDsgPHU+PC91 Pjx1PjwvdT48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUgZ3JvdXAg aXMgc2NvcGVkIHRvIHdvcmsgb25seSBvbiB0aGUgd2ViIHByb3RvY29scyBhbmQgZGF0YSBjYXJy aWVkIHdpdGhpbiB0aGVtLjx1PjwvdT48dT48L3U+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs YW5nPSJFTi1VUyI+RnVydGhlcm1vcmUsIHRvIGd1YXJhbnRlZSBzbW9vdGggdHJhbnNpdGlvbiwg dGhlPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5p bnRlZ3JhdGlvbiB3aXRoIGV4aXN0aW5nIGRlcGxveW1lbnRzIHdpbGwgYmUgc3R1ZGllZCwgcGFy dGljdWxhcmx5PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVO LVVTIj5jb25jZXJuaW5nIHRoZSB1c2Ugb2YgcHJvdG9jb2wgdHJhbnNsYXRpb24gcHJveGllcy48 dT48L3U+PHU+PC91Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNw Ozx1PjwvdT48dT48L3U+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+VGhp cyB3b3JrIGRvZXMgbm90IG1ha2UgdGhlIGFzc3VtcHRpb24gdGhhdCB0aGUgcGFydHkgb2ZmZXJp bmc8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPmFw cGxpY2F0aW9uIGxheWVyIHNlcnZpY2VzIGlzIGFsd2F5cyB0aGUgc2FtZSBwYXJ0eSBvZmZlcmlu ZyBuZXR3b3JrPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVO LVVTIj5hY2Nlc3Mgc2VydmljZXMuPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wcmU+DQo8cHJlPjxz cGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3ByZT4NCjxwcmU+ PHNwYW4gbGFuZz0iRU4tVVMiPlRoZSB3b3JraW5nIGdyb3VwIGhhcyB0aGUgZm9sbG93aW5nIHRh c2tzOjx1PjwvdT48dT48L3U+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+ Jm5ic3A7PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVT Ij4xKSBQcm9kdWNlIHVzZSBjYXNlcyBhbmQgcmVxdWlyZW1lbnRzPHU+PC91Pjx1PjwvdT48L3Nw YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8dT48L3U+PHU+PC91Pjwv c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPjIpIElkZW50aWZ5IGF1dGhlbnRp Y2F0aW9uIGFuZCBhdXRob3JpemF0aW9uIG1lY2hhbmlzbXMgc3VpdGFibGUgZm9yPHU+PC91Pjx1 PjwvdT48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5yZXNvdXJjZSBhY2Nl c3MgaW4gY29uc3RyYWluZWQgZW52aXJvbm1lbnRzLjx1PjwvdT48dT48L3U+PC9zcGFuPjwvcHJl Pg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9w cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5NaWxlc3RvbmVzOjx1PjwvdT48dT48L3U+PC9z cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PHU+PC91Pjx1PjwvdT48 L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5KdWwgMjAxNCBTdWJtaXQgJnF1 b3Q7VXNlIGNhc2VzIGFuZCBSZXF1aXJlbWVudHMmcXVvdDsgYXMgYSBXRyBpdGVtLjx1PjwvdT48 dT48L3U+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+RGVjIDIwMTQgU3Vi bWl0ICZxdW90O0F1dGhlbnRpY2F0aW9uIGFuZCBBdXRob3JpemF0aW9uIFNvbHV0aW9uJnF1b3Q7 IGFzIGEgV0cgaXRlbS48dT48L3U+PHU+PC91Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFu Zz0iRU4tVVMiPkRlYyAyMDE0IE9wdGlvbmFsbHksIHN1Ym1pdCAmcXVvdDtVc2UgY2FzZXMgYW5k IFJlcXVpcmVtZW50cyZxdW90OyBkb2N1bWVudCA8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3ByZT4N CjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPnRvIHRoZSBJRVNHIGZvciBwdWJsaWNhdGlvbiBhcyBh biBJbmZvcm1hdGlvbmFsIFJGQy48dT48L3U+PHU+PC91Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw YW4gbGFuZz0iRU4tVVMiPkp1bCAyMDE2IFN1Ym1pdCAmcXVvdDtBdXRoZW50aWNhdGlvbiBhbmQg QXV0aG9yaXphdGlvbiBTb2x1dGlvbiZxdW90Ozx1PjwvdT48dT48L3U+PC9zcGFuPjwvcHJlPg0K PHByZT48c3BhbiBsYW5nPSJFTi1VUyI+c3BlY2lmaWNhdGlvbiB0byB0aGUgSUVTRyBmb3IgcHVi bGljYXRpb24gYXMgYSBQcm9wb3NlZCBTdGFuZGFyZC48dT48L3U+PHU+PC91Pjwvc3Bhbj48L3By ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzx1PjwvdT48dT48L3U+PC9zcGFuPjwv cHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+UHJvcG9zZWQgTWlsZXN0b25lcyA8dT48L3U+ PHU+PC91Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPk5vIG1pbGVzdG9u ZXMgZm9yIGNoYXJ0ZXIgZm91bmQuPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wcmU+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PHU+PC91Pjx1PjwvdT48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQo8YnIgY2xlYXI9ImFsbCI+DQo8 dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPi0tIDx1PjwvdT48dT48L3U+ PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5CZXN0IHJlZ2FyZHMsPHU+PC91Pjx1PjwvdT48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPkthdGhsZWVuPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjxicj4NCjxiciBjbGVhcj0iYWxsIj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPHNwYW4gY2xhc3M9IkhPRW5aYiI+PGZvbnQgY29sb3I9IiM4ODg4ODgiPi0tIDxi cj4NCjxkaXYgZGlyPSJsdHIiPjxicj4NCjxkaXY+QmVzdCByZWdhcmRzLDwvZGl2Pg0KPGRpdj5L YXRobGVlbjwvZGl2Pg0KPC9kaXY+DQo8L2ZvbnQ+PC9zcGFuPjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8YnI+DQo8YnIgY2xlYXI9ImFsbCI+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KLS0g PGJyPg0KPGRpdiBkaXI9Imx0ciI+PGJyPg0KPGRpdj5CZXN0IHJlZ2FyZHMsPC9kaXY+DQo8ZGl2 PkthdGhsZWVuPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvc3Bhbj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_CFB43838132A5goranselanderericssoncom_-- From nobody Wed Jun 4 06:41:47 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2E211A0246 for ; Wed, 4 Jun 2014 06:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.15 X-Spam-Level: X-Spam-Status: No, score=0.15 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 GpkBQzJdJ0eO for ; Wed, 4 Jun 2014 06:41:44 -0700 (PDT) Received: from omr-d08.mx.aol.com (omr-d08.mx.aol.com [205.188.109.207]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFE221A023E for ; Wed, 4 Jun 2014 06:41:43 -0700 (PDT) Received: from mtaout-aad02.mx.aol.com (mtaout-aad02.mx.aol.com [172.26.127.226]) by omr-d08.mx.aol.com (Outbound Mail Relay) with ESMTP id 5E6DF70044655; Wed, 4 Jun 2014 09:41:37 -0400 (EDT) Received: from [10.181.176.188] (unknown [10.181.176.188]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-aad02.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 173D038000084; Wed, 4 Jun 2014 09:41:37 -0400 (EDT) Message-ID: <538F2210.1020800@aol.com> Date: Wed, 04 Jun 2014 09:41:36 -0400 From: George Fletcher Organization: AOL LLC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Carsten Bormann , Rene Struik References: <538DA583.4070200@tzi.de> <538DD2FD.2020400@gmail.com> <521AAE69-A9C5-4EF9-BD11-86A6AE06A0DA@tzi.org> In-Reply-To: <521AAE69-A9C5-4EF9-BD11-86A6AE06A0DA@tzi.org> Content-Type: multipart/alternative; boundary="------------000707080803050707080507" x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20121107; t=1401889297; bh=rvdEqONTM8Lny8yK/GSYhF7ByG3UcG9h5PzlyRNyz/k=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=wucR81TmeaZG+0XOgJBbgH3zIRYJ9vfAgbeWvMZyf14ZBLMCdELcfORBMTHNnRd7w EMaGs5W6W7d4mHeNnwaTppFsQpOvKQ42bfVn66HfVlfn9sV312Lkg1fCA0HuKOhht0 5Mgvljgu3sPOZjgCIYt10b5zXoT2Wip3MQ0xeSos= x-aol-sid: 3039ac1a7fe2538f22110cf8 X-AOL-IP: 10.181.176.188 Archived-At: http://mailarchive.ietf.org/arch/msg/ace/YTYmGHZTBGHfr5SOd1dCCwbgNbI Cc: Stefanie Gerdes , "ace@ietf.org" Subject: Re: [Ace] Security Domains X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments $ace$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 13:41:45 -0000 This is a multi-part message in MIME format. --------------000707080803050707080507 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Just a quick comment. The OAuth2 flows started from a "single-owner" perspective and just doesn't cover a lot of use cases so the work by the User Managed Access (UMA) group in the Kantara Initiative is working to address access to resources by arbitrary (as yet not introduced) entities. Not exactly the same as the "multi-owner" problem but there are some similarities. I'm in favor of supporting a multi-owner model. Thanks, George On 6/3/14, 10:15 AM, Carsten Bormann wrote: > On 03 Jun 2014, at 15:51, Rene Struik wrote: > >> I did not really get yet what the disagreement is about, so maybe >> someone can help me with that. > Here in Stockholm there was a relatively extended discussion whether it is worth to separate the client owner and the resource owner function in the architecture and analogously separate out the Authorization Manager (less-constrained counterpart of the client) from the Authorization Server (less-constrained counterpart of the resource server). > > http://tools.ietf.org/html/draft-gerdes-ace-actors takes the view that this exercise is worthwhile. > > Obviously, this is an architectural model and does not say anything how these functions are mapped to specific devices in a specific deployment. If you don’t separate out the functions in the architecture, I believe the result will be single-owner thinking and it will be very hard to later address the multiple-owner aspect that is so central to the Internet of Things idea. Others believe that initial deployments will all be single-owner and it will be hard to drum up input to an architecture enabled for multiple owners, but it will be relatively easy to extend the single-owner architecture later. > > Grüße, Carsten > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > > --------------000707080803050707080507 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Just a quick comment. The OAuth2 flows started from a "single-owner" perspective and just doesn't cover a lot of use cases so the work by the User Managed Access (UMA) group in the Kantara Initiative is working to address access to resources by arbitrary (as yet not introduced) entities. Not exactly the same as the "multi-owner" problem but there are some similarities.

I'm in favor of supporting a multi-owner model.

Thanks,
George

On 6/3/14, 10:15 AM, Carsten Bormann wrote:

On 03 Jun 2014, at 15:51, Rene Struik <rstruik.ext@gmail.com> wrote:

I did not really get yet what the disagreement is about, so maybe someone can help me with that.

Here in Stockholm there was a relatively extended discussion whether it is worth to separate the client owner and the resource owner function in the architecture and analogously separate out the Authorization Manager (less-constrained counterpart of the client) from the Authorization Server (less-constrained counterpart of the resource server). http://tools.ietf.org/html/draft-gerdes-ace-actors takes the view that this exercise is worthwhile. Obviously, this is an architectural model and does not say anything how these functions are mapped to specific devices in a specific deployment. If you don’t separate out the functions in the architecture, I believe the result will be single-owner thinking and it will be very hard to later address the multiple-owner aspect that is so central to the Internet of Things idea. Others believe that initial deployments will all be single-owner and it will be hard to drum up input to an architecture enabled for multiple owners, but it will be relatively easy to extend the single-owner architecture later. Grüße, Carsten _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace

--------------000707080803050707080507-- From nobody Wed Jun 4 06:59:39 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59D881A0246 for ; Wed, 4 Jun 2014 06:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_DOMAIN_NOVOWEL=0.5, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 CUenzV18Wt1k for ; Wed, 4 Jun 2014 06:59:35 -0700 (PDT) Received: from mail.promanage-inc.com (eliasisrael.com [50.47.36.5]) by ietfa.amsl.com (Postfix) with ESMTP id 2D0EF1A0213 for ; Wed, 4 Jun 2014 06:59:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.promanage-inc.com (Postfix) with ESMTP id 45F7C4775C6F; Wed, 4 Jun 2014 06:59:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at promanage-inc.com Received: from mail.promanage-inc.com ([127.0.0.1]) by localhost (greendome.promanage-inc.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hZUdmZp1hl-r; Wed, 4 Jun 2014 06:59:26 -0700 (PDT) Received: from [192.168.6.92] (ip-64-134-231-2.public.wayport.net [64.134.231.2]) by mail.promanage-inc.com (Postfix) with ESMTPSA id 34A044775C52; Wed, 4 Jun 2014 06:59:26 -0700 (PDT) References: <538DA583.4070200@tzi.de> <538DD2FD.2020400@gmail.com> <521AAE69-A9C5-4EF9-BD11-86A6AE06A0DA@tzi.org> <538F2210.1020800@aol.com> In-Reply-To: <538F2210.1020800@aol.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-208C6462-CA82-4E3C-B4D3-7C5C9189DFE9 Message-Id: X-Mailer: iPad Mail (11D201) From: Eve Maler Date: Wed, 4 Jun 2014 06:59:24 -0700 To: George Fletcher Archived-At: http://mailarchive.ietf.org/arch/msg/ace/8cX6TAgK1D3m9RvwuO8cVhBFl0Q Cc: Stefanie Gerdes , Carsten Bormann , Rene Struik , "ace@ietf.org" Subject: Re: [Ace] Security Domains X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments $ace$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 13:59:37 -0000 --Apple-Mail-208C6462-CA82-4E3C-B4D3-7C5C9189DFE9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable If the two owners in question are, as described below, the resource owner an= d the client owner, this actually seems to align nicely with UMA's resource o= wner and requesting party (defined as "An end-user, or a corporation or othe= r legal person, that uses the client to seek access to a protected resource.= The requesting party may or may not be the same party as the resource owner= ."). A goodly part of the UMA architecture is dedicated to details necessary= to separate these two entities. http://tools.ietf.org/html/draft-hardjono-oauth-umacore-09 Eve Maler (sent from my iPad) cell +1 425 345 6756 eve@xmlgrrl.com > On Jun 4, 2014, at 6:41 AM, George Fletcher wrote: >=20 > Just a quick comment. The OAuth2 flows started from a "single-owner" persp= ective and just doesn't cover a lot of use cases so the work by the User Man= aged Access (UMA) group in the Kantara Initiative is working to address acce= ss to resources by arbitrary (as yet not introduced) entities. Not exactly t= he same as the "multi-owner" problem but there are some similarities. >=20 > I'm in favor of supporting a multi-owner model. >=20 > Thanks, > George >=20 >> On 6/3/14, 10:15 AM, Carsten Bormann wrote: >>> On 03 Jun 2014, at 15:51, Rene Struik wrote: >>>=20 >>> I did not really get yet what the disagreement is about, so maybe >>> someone can help me with that. >> Here in Stockholm there was a relatively extended discussion whether it i= s worth to separate the client owner and the resource owner function in the a= rchitecture and analogously separate out the Authorization Manager (less-con= strained counterpart of the client) from the Authorization Server (less-cons= trained counterpart of the resource server). =20 >>=20 >> http://tools.ietf.org/html/draft-gerdes-ace-actors takes the view that th= is exercise is worthwhile. >>=20 >> Obviously, this is an architectural model and does not say anything how t= hese functions are mapped to specific devices in a specific deployment. If y= ou don=E2=80=99t separate out the functions in the architecture, I believe t= he result will be single-owner thinking and it will be very hard to later ad= dress the multiple-owner aspect that is so central to the Internet of Things= idea. Others believe that initial deployments will all be single-owner and= it will be hard to drum up input to an architecture enabled for multiple ow= ners, but it will be relatively easy to extend the single-owner architecture= later. >>=20 >> Gr=C3=BC=C3=9Fe, Carsten >>=20 >> _______________________________________________ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace >>=20 >>=20 >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace --Apple-Mail-208C6462-CA82-4E3C-B4D3-7C5C9189DFE9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
If the two owners in question are, as described below, the resource owne= r and the client owner, this actually seems to align nicely with UMA's resou= rce owner and requesting party (defined as "An end-user, or a corporation or= other legal person, that uses the client to seek access to a protected reso= urce. The requesting party may or may not be the same party as the resource o= wner."). A goodly part of the UMA architecture is dedicated to details neces= sary to separate these two entities.

= http://tools.ietf.org/html/draft-hardjono-oauth-umacore-09
Eve Maler (sent from my iPad= )
cell +1 425 345 6756
eve@xmlgrrl.com

On Jun 4, 2014, at 6:41 AM, George Fletcher <gffletch@aol.com> wrote:

=20 =20 =20 Just a quick comment. The OAuth2 flows started from a "single-owner" perspective and just doesn't cover a lot of use cases so the work by the User Managed Access (UMA) group in the Kantara Initiative is working to address access to resources by arbitrary (as yet not introduced) entities. Not exactly the same as the "multi-owner" problem but there are some similarities.

I'm in favor of supporting a multi-owner model.

Thanks,
George

On 6/3/14, 10:15 AM, Carsten Bormann wrote:

On 03 Jun 2014, at 15:51, Rene Struik <rstruik.ext@gmai= l.com> wrote:

I did not really get yet what the disagreement is abo= ut, so maybe someone can help me with that.

Here in Stockholm there was a relatively extended discu= ssion whether it is worth to separate the client owner and the resource owne= r function in the architecture and analogously separate out the Authorizatio= n Manager (less-constrained counterpart of the client) from the Authorizatio= n Server (less-constrained counterpart of the resource server). =20 http://tools.ietf.org/html/draft-gerdes-ace-actors ta= kes the view that this exercise is worthwhile. Obviously, this is an architectural model and does not say anything how thes= e functions are mapped to specific devices in a specific deployment. If you= don=E2=80=99t separate out the functions in the architecture, I believe the= result will be single-owner thinking and it will be very hard to later addr= ess the multiple-owner aspect that is so central to the Internet of Things i= dea. Others believe that initial deployments will all be single-owner and i= t will be hard to drum up input to an architecture enabled for multiple owne= rs, but it will be relatively easy to extend the single-owner architecture l= ater. Gr=C3=BC=C3=9Fe, Carsten _______________________________________________ Ace mailing list Ace@ietf.= org https://www.ietf.org/mailman/listinfo/ace

=20
_______________________________________________=
Ace mailing list
A= ce@ietf.org
https://www.ietf.org/mailman/listinfo/ace
= --Apple-Mail-208C6462-CA82-4E3C-B4D3-7C5C9189DFE9-- From nobody Wed Jun 4 07:05:53 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F83A1A0276; Wed, 4 Jun 2014 07:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 qN58lLOMjXPG; Wed, 4 Jun 2014 07:05:46 -0700 (PDT) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03C4F1A0213; Wed, 4 Jun 2014 07:05:44 -0700 (PDT) Received: by mail-la0-f54.google.com with SMTP id pv20so4344167lab.41 for ; Wed, 04 Jun 2014 07:05:37 -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=AIr/ljN6G6iBOLqjzbSl59o367OWaYndbJceYQZ6J48=; b=rTP3yZgS/InpIheXXg+EHoWbM9wccz/i4IyCvliFVtIcdmQtJCXtc+9kxpCe7ki8Z/ q4+eUVgUa2MbY5O1eKZVUfsB3RXvxaG3MZ97H9kJ1mLkUCCl+N+I1V738ginkIafo7JK 3m5I3ptjbfUc48/7Wc8HO6JL78hcjC5muf9kRaFm9SySBXWm22tq+JKTnV37BiOBAwnB jNHp1JpEez9WDGWQQLi1WwNSxrLj+mS+inU5iDZg5W6PNELftJhUFAI4pwQRLqG+cPeO XPprg7Pk08lnT5Uhc114zhn9WlVOryiUFj0ZyhXcSV6U7pQmsd0dqWOAnyYnPXXmR1MP 64KA== MIME-Version: 1.0 X-Received: by 10.112.131.8 with SMTP id oi8mr2448216lbb.87.1401890737177; Wed, 04 Jun 2014 07:05:37 -0700 (PDT) Received: by 10.112.33.36 with HTTP; Wed, 4 Jun 2014 07:05:37 -0700 (PDT) In-Reply-To: References: <20140514221215.8150.56543.idtracker@ietfa.amsl.com> <34966E97BE8AD64EAE9D3D6E4DEE36F252B2A345@SZXEMA501-MBS.china.huawei.com> <34966E97BE8AD64EAE9D3D6E4DEE36F252B38978@SZXEMA501-MBS.china.huawei.com> <34966E97BE8AD64EAE9D3D6E4DEE36F258140E59@SZXEMA501-MBX.china.huawei.com> <538DA047.7080902@cisco.com> <34966E97BE8AD64EAE9D3D6E4DEE36F258153F43@SZXEMA501-MBS.china.huawei.com> <34966E97BE8AD64EAE9D3D6E4DEE36F25815405D@SZXEMA501-MBS.china.huawei.com> Date: Wed, 4 Jun 2014 10:05:37 -0400 Message-ID: From: Kathleen Moriarty To: =?UTF-8?Q?G=C3=B6ran_Selander?= Content-Type: multipart/alternative; boundary=e89a8f23501567490804fb031ffe Archived-At: http://mailarchive.ietf.org/arch/msg/ace/EAH0PtL6k9eKyAy0z_hq518wTEY Cc: "aaa-doctors@ietf.org" , The IESG , Likepeng , "ace@ietf.org" , Benoit Claise , "adrian@olddog.co.uk" Subject: Re: [Ace] Revised charter proposal: charter-ietf-ace-00-02 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments $ace$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 14:05:51 -0000 --e89a8f23501567490804fb031ffe Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thank you, G=C3=B6ran. It must have been a cut-n-paste error. The first sentence for the 'replace' did not match the original or the new either. If the next version isn't quite right, pasting in a new full version may be better. I'll look back through Benoit's comment now as well. On Wed, Jun 4, 2014 at 3:06 AM, G=C3=B6ran Selander wrote: > Hi Kathleen, > > In change #3 of the summary Kepeng made below I find the sentence: >>Ot= her > security protocols may be considered as long as the primary focus is > maintained. >> This sentence seems to be missing from > charter-ietf-ace-00-04. > > Regards, > G=C3=B6ran > > > From: Kathleen Moriarty > Date: Tuesday 3 June 2014 22:27 > To: Likepeng > Cc: Benoit Claise , "adrian@olddog.co.uk" < > adrian@olddog.co.uk>, "ace@ietf.org" , The IESG < > iesg@ietf.org>, "aaa-doctors@ietf.org" > Subject: Re: [Ace] Revised charter proposal: charter-ietf-ace-00-02 > > The charter text has been updated, > https://datatracker.ietf.org/doc/charter-ietf-ace/ > > Thank you all for your input and assistance. If this is good, we'll > move it forward for IETF review. > > > > On Tue, Jun 3, 2014 at 10:39 AM, Kathleen Moriarty < > kathleen.moriarty.ietf@gmail.com> wrote: > >> I believe there is agreement on the proposed changes. I'll make the >> updates later in the day (it's about 11:30 my time, maybe at 4) in case >> anyone wants to chime in. If we are all in agreement, I'll have it sent >> for IETF review at that point. >> >> Thank you! >> >> >> On Tue, Jun 3, 2014 at 10:26 AM, Likepeng wrote: >> >>> Hi Kathleen and all, >>> >>> >>> >>> This is what I have now: >>> >>> >>> >>> Change #1: (Proposed by Kepeng, confirmed by Benoit) >>> >>> OLD >>> >>> The IETF has recently developed protocols for use in constrained >>> >>> environments, where network nodes are limited in CPU, memory and power. >>> >>> >>> >>> NEW >>> >>> The IETF has recently developed protocols for use in constrained >>> >>> environments, where network nodes are limited in CPU, memory and power. >>> >>> REST architecture is widely used for such constrained environments. >>> >>> END >>> >>> >>> >>> Change #2: (Proposal from Rene, supported by Stefanie) >>> >>> OLD: >>> >>> Requirements derived from use cases indicate the suitability of existi= ng >>> >>> work as a solution for constrained environments >>> >>> >>> >>> NEW: >>> >>> Requirements derived from use cases may indicate that existing work is >>> >>> useful as basis for as a solution for constrained environments >>> >>> >>> >>> Change #3: (Proposal from Jari, supported by Barry, Robert and Behcet) >>> >>> OLD: >>> >>> Note that the initial focus is on CoAP and HTTP with DTLS and TLS. >>> >>> Other security protocols may be considered as long as the primary focus= is maintained. >>> >>> Other application protocols and protocols at other layers in the stack = are out of scope. >>> >>> >>> >>> NEW >>> >>> Note that the initial focus is on CoAP and HTTP with DTLS and TLS. >>> >>> Other security protocols may be considered as long as the primary focus= is maintained. >>> >>> The group is scoped to work only on the web protocols and data carried = within them. >>> >>> END >>> >>> >>> >>> Change 4: (Proposal from Jari, revised by Rene, supported by Stefanie) >>> >>> OLD: >>> >>> Jul 2014 Submit "Use cases and Requirements" as a WG item. >>> >>> Jul 2015 Submit =E2=80=9CUse cases and Requirements=E2=80=9D document = to IESG for publication as informational RFC. >>> >>> >>> >>> NEW >>> >>> Dec 2014 Submit "Use cases and Requirements" as a WG item. >>> >>> Apr 2015 Optionally, submit "Use cases and Requirements" document to th= e IESG for >>> >>> publication as an Informational RFC. >>> >>> END >>> >>> >>> >>> I think we covered all of the IESG review comments. >>> >>> >>> >>> If there is any open issue, please let us know. >>> >>> >>> >>> Thanks, >>> >>> >>> >>> Kind Regards >>> >>> Kepeng >>> >>> >>> -----------------------------------------------------------------------= ---------------------------------------------------------------------------= ------ >>> >>> >>> >>> Charter charter-ietf-ace-00-02 >>> >>> Authentication and Authorization for Constrained >>> >>> Environment (ACE) >>> >>> >>> >>> The IETF has recently developed protocols for use in constrained >>> >>> environments, where network nodes are limited in CPU, memory and power. >>> >>> REST architecture is widely used for such constrained environments. >>> >>> It has been observed that Internet protocols can be applied to these >>> >>> constrained environments, often only requiring minor tweaking and >>> >>> profiling. In other cases, new protocols have been defined to address >>> >>> the specific requirements of constrained environments. An example of >>> >>> such a protocol is the Constrained Application Protocol (CoAP). >>> >>> >>> >>> As in other environments, authentication and authorization questions >>> >>> also arise in constrained environments. For example, a door lock has to >>> >>> authorize the person seeking access using a "digital key". Where is the >>> >>> authorization policy stored? How does the digital key communicate with >>> >>> the lock? Does the lock interact with an authorization server to obtain >>> >>> authorization information? How can access be temporarily granted to >>> >>> other persons? How can access be revoked? These types of questions have >>> >>> been answered by existing protocols for use cases outside constrained >>> >>> environments, however in constrained environments, additional and >>> >>> different requirements pose challenges for the use of various security >>> >>> protocols. In particular, the need arises for a dynamic and fine graine= d >>> >>> access control mechanism, where clients and/or resource servers are >>> >>> constrained. >>> >>> >>> >>> The IETF has a long history in developing three-party authentication an= d >>> >>> authorization protocols for distributed environments. Examples include >>> >>> Kerberos, the Public Key Infrastructure (PKI), the Authentication, >>> >>> Authorization and Accounting (AAA) infrastructure,and the Web >>> >>> Authorization Protocol (OAuth). All these protocols enjoy widespread >>> >>> deployment on the Internet. Although they all aim to solve a similar >>> >>> goal, at an abstract level, they offer quite different functions and >>> >>> utilize different message exchanges. These differences result from the >>> >>> main deployment use cases they were designed for respectively. >>> >>> >>> >>> Requirements derived from use cases may indicate that existing work is >>> >>> useful as basis for as a solution for constrained environments. >>> >>> These protocols, >>> >>> however, were not optimized for constrained environments. Additional >>> >>> requirements that need to be taken into account are the lack of a >>> >>> suitable user-interface and the inability of embedded devices to contac= t >>> >>> an authorization server in real-time with every resource access request >>> >>> due to intermittent connectivity, etc. >>> >>> >>> >>> This working group therefore aims to produce a standardized solution fo= r >>> >>> authentication and authorization to enable authorized access (GET, PUT, >>> POST, >>> >>> DELETE) to resources identified by a URI and hosted on a resource >>> >>> server in constrained environments. As a starting point, the working >>> >>> group will assume that access to resources at a resource server by a >>> >>> client device takes place using CoAP and is protected by DTLS. Both >>> >>> resource server and client may be constrained. This access will be >>> >>> mediated by an authorization server, which is not considered to be >>> >>> constrained. >>> >>> >>> >>> Existing authentication and authorization protocols will be evaluated >>> >>> and re-used where applicable to build the constrained-environment >>> solution. >>> >>> This requires >>> >>> relevant specifications to be reviewed for suitability, selecting a >>> >>> subset of them and restricting the options within each of the >>> >>> specifications. Some functionality, however, may not be available in >>> >>> existing protocols, in which case the solution may also involve new >>> >>> protocol work. Leveraging existing work means the working group benefit= s >>> >>> from available security analysis, implementation, and deployment >>> >>> experience. Moreover, a standardized solution for federated >>> >>> authentication and authorization will help to stimulate the deployment >>> >>> of constrained devices that provide increased security. >>> >>> >>> >>> Once progress in identifying suitable candidate solutions has been made= , >>> >>> the working group will verify whether the same mechanisms are also >>> >>> applicable beyond the use of CoAP and DTLS, which are the two main >>> >>> protocols the group will focus on for access to resources. In >>> >>> particular, the ability to use the developed solution over HTTP and TLS >>> >>> will be investigated. Note that the initial focus is on CoAP and HTTP >>> with DTLS and TLS. >>> >>> Other security protocols may be considered as long as the primary focus >>> is maintained. >>> >>> The group is scoped to work only on the web protocols and data carried >>> within them. >>> >>> Furthermore, to guarantee smooth transition, the >>> >>> integration with existing deployments will be studied, particularly >>> >>> concerning the use of protocol translation proxies. >>> >>> >>> >>> This work does not make the assumption that the party offering >>> >>> application layer services is always the same party offering network >>> >>> access services. >>> >>> >>> >>> The working group has the following tasks: >>> >>> >>> >>> 1) Produce use cases and requirements >>> >>> >>> >>> 2) Identify authentication and authorization mechanisms suitable for >>> >>> resource access in constrained environments. >>> >>> >>> >>> Milestones: >>> >>> >>> >>> Dec 2014 Submit "Use cases and Requirements" as a WG item. >>> >>> Dec 2014 Submit "Authentication and Authorization Solution" as a WG ite= m. >>> >>> Apr 2015 Optionally, submit "Use cases and Requirements" document >>> >>> to the IESG for publication as an Informational RFC. >>> >>> Jul 2016 Submit "Authentication and Authorization Solution" >>> >>> specification to the IESG for publication as a Proposed Standard. >>> >>> >>> >>> Proposed Milestones >>> >>> No milestones for charter found. >>> >>> >>> >>> >>> >>> >>> >>> *=E5=8F=91=E4=BB=B6=E4=BA=BA:* Kathleen Moriarty [mailto:kathleen.moria= rty.ietf@gmail.com] >>> *=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4:* 2014=E5=B9=B46=E6=9C=883=E6=97= =A5 14:30 >>> *=E6=94=B6=E4=BB=B6=E4=BA=BA:* Likepeng >>> *=E6=8A=84=E9=80=81:* Benoit Claise; adrian@olddog.co.uk; aaa-doctors@i= etf.org; The >>> IESG; ace@ietf.org >>> *=E4=B8=BB=E9=A2=98:* Re: Revised charter proposal: charter-ietf-ace-0= 0-02 >>> >>> >>> >>> Hi Kepeng, >>> >>> >>> >>> If we are at a point where I can update the charter, seems that way, >>> please send the latest version that has been agreed upon and I'll take = care >>> of the update. >>> >>> >>> >>> Thanks. >>> >>> >>> >>> On Tue, Jun 3, 2014 at 6:31 AM, Likepeng wrote: >>> >>> Hi Benoit, >>> >>> >>> >>> >Not only would I keep "AAA", >>> >>> >>> >>> OK. >>> >>> >>> >>> >but I would propose >>> >>> >>> >>> >OLD: >>> >>> >Existing authentication and authorization protocols will be used where >>> >>> applicable to build the constrained-environment solution. >>> >>> >>> >>> >NEW: >>> >>> Existing authentication and authorization protocols will be evaluated >>> and re-used where >>> >>> applicable to build the constrained-environment solution. >>> >>> >>> >>> OK, fine with me. >>> >>> >>> >>> Thanks for the feedback. >>> >>> >>> >>> Kind Regards >>> >>> Kepeng >>> >>> >>> >>> *=E5=8F=91=E4=BB=B6=E4=BA=BA:* Benoit Claise [mailto:bclaise@cisco.com] >>> *=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4:* 2014=E5=B9=B46=E6=9C=883=E6=97= =A5 12:16 >>> >>> *=E6=94=B6=E4=BB=B6=E4=BA=BA:* Likepeng; Kathleen Moriarty; adrian@oldd= og.co.uk >>> >>> *=E6=8A=84=E9=80=81:* aaa-doctors@ietf.org; The IESG; ace@ietf.org >>> >>> *=E4=B8=BB=E9=A2=98:* Re: Revised charter proposal: charter-ietf-ace-00= -02 >>> >>> >>> >>> Hi, >>> >>> Hello all, >>> >>> >>> >>> Based on recent discussions, I made a revised charter proposal, as incl= uded in this email, not on the webpage yet. >>> >>> >>> >>> Please take a look and let us know if you have any further comments. >>> >>> >>> >>> @Adrian and @Benoit, please check if the proposed texts can resolve you= r comments. >>> >>> >>> >>> Thanks, >>> >>> Kind Regards >>> >>> Kepeng >>> >>> >>> >>> -----------------------------------------------------------------------= ---------------------------------------------------------------------------= ----------- >>> >>> Compared with charter-ietf-ace-00-01 on the webpage, the changes are: >>> >>> >>> >>> (1) Add one clarification sentence about REST architecture: >>> >>> OLD >>> >>> The IETF has recently developed protocols for use in constrained >>> >>> environments, where network nodes are limited in CPU, memory and power. >>> >>> REST architecture is widely used for such constrained environments. >>> >>> >>> >>> NEW >>> >>> The IETF has recently developed protocols for use in constrained >>> >>> environments, where network nodes are limited in CPU, memory and power. >>> >>> REST architecture is widely used for such constrained environments. >>> >>> END >>> >>> Considering that OLD is >>> >>> OLD >>> >>> The IETF has recently developed protocols for use in constrained >>> >>> environments, where network nodes are limited in CPU, memory and power. >>> >>> ... fine with me >>> >>> >>> >>> >>> >>> (2) Remove =E2=80=9CAAA protocol=E2=80=9D from the charter: >>> >>> OLD >>> >>> The IETF has a long history in developing three-party authentication an= d >>> >>> authorization protocols for distributed environments. Examples include >>> >>> Kerberos, the Public Key Infrastructure (PKI), the Authentication, >>> >>> Authorization and Accounting (AAA) infrastructure, and the Web >>> >>> Authorization Protocol (OAuth). >>> >>> >>> >>> NEW >>> >>> The IETF has a long history in developing three-party authentication an= d >>> >>> authorization protocols for distributed environments. Examples include >>> >>> Kerberos, the Public Key Infrastructure (PKI), and the Web Authorizatio= n Protocol (OAuth). >>> >>> END >>> >>> We have AAA-doctors telling: maybe RADIUS is applicable? >>> Personally, I don't know and it doesn't matter at this point. >>> We received feedback such as: >>> >>> Let's be clear here: It was never said (in the charter or anywhere else >>> in the group to my knowledge) that RADIUS (or indeed any other AAA >>> protocol) would not run on constrained devices (RFC 7228). The charter >>> simply said the protocols were not optimised for constrained devices. T= hat >>> does not preclude considering any protocol for suitability for constrai= ned >>> devices either a) as is, b) in a restricted way or c) in an adapted way= . >>> >>> So, at this stage, I don't think any protocols should be excluded from >>> consideration and should certainly not be eliminated on a hunch that th= ey >>> might be "too big". Let's do the assessment properly at the appropriate >>> time. As a reminder - the focus now is to complete the charter. >>> >>> Or >>> >>> >>The Charter makes a number of assertions that are provably false, suc= h as that AAA protocols are inappropriate for constrained environments. >>> >>> In fact, the charter does not say that. But to avoid confusion, let's r= emove AAA protocol from the charter. >>> >>> >>> >>> In the charter, we mentioned that we want to reuse existing authenticat= ion and authorization protocols where applicable to build the constrained-e= nvironment solution. >>> >>> ... which I read as: let's consider the AAA protocols, and evaluate if >>> they would work in constrained devices. >>> I don't understand the logic: why do you want to remove AAA from the >>> charter? >>> Not only would I keep "AAA", but I would propose >>> >>> OLD: >>> Existing authentication and authorization protocols will be used where >>> applicable to build the constrained-environment solution >>> >>> NEW: >>> Existing authentication and authorization protocols will be evaluated >>> and re-used where >>> applicable to build the constrained-environment solution >>> >>> Regards, Benoit >>> >>> >>> >>> >>> >>> (3) Clarify the scope: >>> >>> OLD: >>> >>> Note that the initial focus is on CoAP and HTTP with DTLS and TLS. >>> >>> Other security protocols may be considered as long as the primary focus= is maintained. >>> >>> Other application protocols and protocols at other layers in the stack = are out of scope. >>> >>> >>> >>> NEW >>> >>> Note that the initial focus is on CoAP and HTTP with DTLS and TLS. >>> >>> Other security protocols may be considered as long as the primary focus= is maintained. >>> >>> The group is scoped to work only on the web protocols and data carried = within them. >>> >>> END >>> >>> >>> >>> (4) Update milestones for the use case & requirements document: >>> >>> OLD: >>> >>> Jul 2015 Submit =E2=80=9CUse cases and Requirements=E2=80=9D document t= o IESG for publication as informational RFC. >>> >>> >>> >>> NEW >>> >>> Dec 2014 Optionally, submit "Use cases and Requirements" document to th= e IESG for publication as an Informational RFC. >>> >>> END >>> >>> >>> >>> -----------------------------------------------------------------------= ---------------------------------------------------------------------------= -------------------------- >>> >>> Charter charter-ietf-ace-00-02 >>> >>> Authentication and Authorization for Constrained >>> >>> Environment (ACE) >>> >>> >>> >>> The IETF has recently developed protocols for use in constrained >>> >>> environments, where network nodes are limited in CPU, memory and power. >>> >>> REST architecture is widely used for such constrained environments. >>> >>> It has been observed that Internet protocols can be applied to these >>> >>> constrained environments, often only requiring minor tweaking and >>> >>> profiling. In other cases, new protocols have been defined to address >>> >>> the specific requirements of constrained environments. An example of >>> >>> such a protocol is the Constrained Application Protocol (CoAP). >>> >>> >>> >>> As in other environments, authentication and authorization questions >>> >>> also arise in constrained environments. For example, a door lock has to >>> >>> authorize the person seeking access using a "digital key". Where is the >>> >>> authorization policy stored? How does the digital key communicate with >>> >>> the lock? Does the lock interact with an authorization server to obtain >>> >>> authorization information? How can access be temporarily granted to >>> >>> other persons? How can access be revoked? These types of questions have >>> >>> been answered by existing protocols for use cases outside constrained >>> >>> environments, however in constrained environments, additional and >>> >>> different requirements pose challenges for the use of various security >>> >>> protocols. In particular, the need arises for a dynamic and fine graine= d >>> >>> access control mechanism, where clients and/or resource servers are >>> >>> constrained. >>> >>> >>> >>> The IETF has a long history in developing three-party authentication an= d >>> >>> authorization protocols for distributed environments. Examples include >>> >>> Kerberos, the Public Key Infrastructure (PKI), and the Web >>> >>> Authorization Protocol (OAuth). All these protocols enjoy widespread >>> >>> deployment on the Internet. Although they all aim to solve a similar >>> >>> goal, at an abstract level, they offer quite different functions and >>> >>> utilize different message exchanges. These differences result from the >>> >>> main deployment use cases they were designed for respectively. >>> >>> >>> >>> Requirements derived from use cases indicate the suitability of existin= g >>> >>> work as a solution for constrained environments. These protocols, >>> >>> however, were not optimized for constrained environments. Additional >>> >>> requirements that need to be taken into account are the lack of a >>> >>> suitable user-interface and the inability of embedded devices to contac= t >>> >>> an authorization server in real-time with every resource access request >>> >>> due to intermittent connectivity, etc. >>> >>> >>> >>> This working group therefore aims to produce a standardized solution fo= r >>> >>> authentication and authorization to enable authorized access (GET, PUT,= POST, >>> >>> DELETE) to resources identified by a URI and hosted on a resource >>> >>> server in constrained environments. As a starting point, the working >>> >>> group will assume that access to resources at a resource server by a >>> >>> client device takes place using CoAP and is protected by DTLS. Both >>> >>> resource server and client may be constrained. This access will be >>> >>> mediated by an authorization server, which is not considered to be >>> >>> constrained. >>> >>> >>> >>> Existing authentication and authorization protocols will be used where >>> >>> applicable to build the constrained-environment solution. This requires >>> >>> relevant specifications to be reviewed for suitability, selecting a >>> >>> subset of them and restricting the options within each of the >>> >>> specifications. Some functionality, however, may not be available in >>> >>> existing protocols, in which case the solution may also involve new >>> >>> protocol work. Leveraging existing work means the working group benefit= s >>> >>> from available security analysis, implementation, and deployment >>> >>> experience. Moreover, a standardized solution for federated >>> >>> authentication and authorization will help to stimulate the deployment >>> >>> of constrained devices that provide increased security. >>> >>> >>> >>> Once progress in identifying suitable candidate solutions has been made= , >>> >>> the working group will verify whether the same mechanisms are also >>> >>> applicable beyond the use of CoAP and DTLS, which are the two main >>> >>> protocols the group will focus on for access to resources. In >>> >>> particular, the ability to use the developed solution over HTTP and TLS >>> >>> will be investigated. Note that the initial focus is on CoAP and HTTP w= ith DTLS and TLS. >>> >>> Other security protocols may be considered as long as the primary focus= is maintained. >>> >>> The group is scoped to work only on the web protocols and data carried = within them. >>> >>> Furthermore, to guarantee smooth transition, the >>> >>> integration with existing deployments will be studied, particularly >>> >>> concerning the use of protocol translation proxies. >>> >>> >>> >>> This work does not make the assumption that the party offering >>> >>> application layer services is always the same party offering network >>> >>> access services. >>> >>> >>> >>> The working group has the following tasks: >>> >>> >>> >>> 1) Produce use cases and requirements >>> >>> >>> >>> 2) Identify authentication and authorization mechanisms suitable for >>> >>> resource access in constrained environments. >>> >>> >>> >>> Milestones: >>> >>> >>> >>> Jul 2014 Submit "Use cases and Requirements" as a WG item. >>> >>> Dec 2014 Submit "Authentication and Authorization Solution" as a WG ite= m. >>> >>> Dec 2014 Optionally, submit "Use cases and Requirements" document >>> >>> to the IESG for publication as an Informational RFC. >>> >>> Jul 2016 Submit "Authentication and Authorization Solution" >>> >>> specification to the IESG for publication as a Proposed Standard. >>> >>> >>> >>> Proposed Milestones >>> >>> No milestones for charter found. >>> >>> >>> >>> >>> >>> >>> >>> -- >>> >>> >>> >>> Best regards, >>> >>> Kathleen >>> >> >> >> >> -- >> >> Best regards, >> Kathleen >> > > > > -- > > Best regards, > Kathleen > > --=20 Best regards, Kathleen --e89a8f23501567490804fb031ffe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thank you,=C2=A0G=C3=B6ran.

It must have been a cut= -n-paste error. =C2=A0The first sentence for the 'replace' did not = match the original or the new either. =C2=A0If the next version isn't q= uite right, pasting in a new full version may be better. =C2=A0I'll loo= k back through Benoit's comment now as well.

On Wed,= Jun 4, 2014 at 3:06 AM, G=C3=B6ran Selander <goran.selander@er= icsson.com> wrote:

Hi Kathleen,

In change #3 of the summary Kepeng made below=C2=A0I find the sentence: >>Other security protocols may be cons= idered as long as the primary focus is maintained. >>=C2=A0This=C2=A0sentence seems to be missing from charter-ietf-ace-00-04.=

Regards,

G=C3=B6ran

From: Kathleen Moriarty <kathleen.mor= iarty.ietf@gmail.com>
Date: Tuesday 3 June 2014 22:27
To: Likepeng <likepeng@huawei.com>
Cc: Benoit Claise <bclaise@cisco.com>, "= adrian@olddog.co.u= k" <ad= rian@olddog.co.uk>, "ace@ietf.org" <ace@ietf.org>= , The IESG <iesg@ietf= .org>, "aaa-doctors@ietf.org" <aaa-doctors@ietf.org>
Subject: Re: [Ace] Revised charter = proposal: charter-ietf-ace-00-02

The charter text has been updated,=C2=A0https://data= tracker.ietf.org/doc/charter-ietf-ace/

Thank you all for your input and assistance. =C2=A0If this is good, we= 'll move it forward for IETF review.

On Tue, Jun 3, 2014 at 10:39 AM, Kathleen Moriar= ty <k= athleen.moriarty.ietf@gmail.com> wrote:

I believe there is agreement on the proposed changes. =C2= =A0I'll make the updates later in the day (it's about 11:30 my time= , maybe at 4) in case anyone wants to chime in. =C2=A0If we are all in agre= ement, I'll have it sent for IETF review at that point.

Thank you!

On Tue, Jun 3, 2014 at 10:26 AM, Likepeng <likepeng@huawe= i.com> wrote:

Hi Kathleen and all,=

=C2=A0=

This is what I have now:=

=C2=A0=

Change #1: (Proposed by Kep= eng, confirmed by Benoit)

OLD

The IETF has recently developed protocols for= use in constrained

environments, where network nodes are limited= in CPU, memory and power.

=C2=A0

NEW

The IETF has recently developed protocols for= use in constrained

environments, where network nodes are limited= in CPU, memory and power.

REST architecture is widely used for such con= strained environments.

END

=C2=A0

Change #2: (Proposal from Rene, supported by = Stefanie)

OLD:

Requirements derived from use cases indicate = the suitability of existing

work as a solution for constrained environmen= ts

=C2=A0

NEW:

Requirements derived from use cases may indic= ate that existing work is

useful as basis for as a solution for constr= ained environments

=C2=A0

Change #3: (Proposal from Jari, supported by = Barry, Robert and Behcet)

OLD:

Note that the initial focus is on CoAP and HT= TP with DTLS and TLS.

Other security protocols may be considered as= long as the primary focus is maintained.=C2=A0

Other application protocols and protocols at = other layers in the stack are out of scope.

=C2=A0

NEW

Note that the initial focus is on CoAP and HT= TP with DTLS and TLS.

Other security protocols may be considered as= long as the primary focus is maintained.=C2=A0

The group is scoped to work only on the web p= rotocols and data carried within them.

END

=C2=A0

Change 4: (Proposal from Jari, revised by Ren= e, supported by Stefanie)

OLD:

Jul 2014 Submit "Use cases and Requireme= nts" as a WG item.

Jul 2015 Submit =E2=80=9CUse cases and Requir= ements=E2=80=9D document to IESG for publication as informational RFC.

=C2=A0

NEW

Dec 2014 Submit "Use cases and Requireme= nts" as a WG item.

Apr 2015 Optionally, submit "Use cases a= nd Requirements" document to the IESG for

publication as an Informational RFC.

END

=C2=A0=

I think we covered all of t= he IESG review comments.

=C2=A0=

If there is any open issue,= please let us know.

=C2=A0=

Thanks,

=C2=A0=

Kind Regards<= /span>

Kepeng=

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

=C2=A0=

Charter charter-ietf-ace-00= -02

Authentication and Authoriz= ation for Constrained

Environment (ACE)=

=C2=A0=

The IETF has recently devel= oped protocols for use in constrained

environments, where network= nodes are limited in CPU, memory and power.

REST architecture is widely= used for such constrained environments.

It has been observed that I= nternet protocols can be applied to these

constrained environments, o= ften only requiring minor tweaking and

profiling. In other cases, = new protocols have been defined to address

the specific requirements o= f constrained environments. An example of

such a protocol is the Cons= trained Application Protocol (CoAP).

=C2=A0=

As in other environments, a= uthentication and authorization questions

also arise in constrained e= nvironments. For example, a door lock has to

authorize the person seekin= g access using a "digital key". Where is the=

authorization policy stored= ? How does the digital key communicate with

the lock? Does the lock int= eract with an authorization server to obtain

authorization information? = How can access be temporarily granted to

other persons? How can acce= ss be revoked? These types of questions have

been answered by existing p= rotocols for use cases outside constrained

environments, however in co= nstrained environments, additional and

different requirements pose= challenges for the use of various security

protocols. In particular, t= he need arises for a dynamic and fine grained

access control mechanism, w= here clients and/or resource servers are

constrained.<= /span>

=C2=A0=

The IETF has a long history= in developing three-party authentication and

authorization protocols for= distributed environments. Examples include

Kerberos, the Public Key In= frastructure (PKI), the Authentication,

Authorization and Accountin= g (AAA) infrastructure,and the Web

Authorization Protocol (OAu= th). All these protocols enjoy widespread

deployment on the Internet.= Although they all aim to solve a similar

goal, at an abstract level,= they offer quite different functions and

utilize different message e= xchanges. These differences result from the

main deployment use cases t= hey were designed for respectively.

=C2=A0=

Requirements derived from u= se cases may indicate that existing work is

useful as basis for as a so= lution for constrained environments.

These protocols,<= /u>

however, were not optimized= for constrained environments. Additional

requirements that need to b= e taken into account are the lack of a

suitable user-interface and= the inability of embedded devices to contact

an authorization server in = real-time with every resource access request

due to intermittent connect= ivity, etc.

=C2=A0=

This working group therefor= e aims to produce a standardized solution for

authentication and authoriz= ation to enable authorized access (GET, PUT, POST,

DELETE) to resources identi= fied by a URI and hosted on a resource

server in constrained envir= onments. As a starting point, the working

group will assume that acce= ss to resources at a resource server by a

client device takes place u= sing CoAP and is protected by DTLS. Both

resource server and client = may be constrained. This access will be

mediated by an authorizatio= n server, which is not considered to be

constrained.<= /span>

=C2=A0=

Existing authentication and= authorization protocols will be evaluated

and re-used where applicabl= e to build the constrained-environment solution.

This requires=

relevant specifications to = be reviewed for suitability, selecting a

subset of them and restrict= ing the options within each of the

specifications. Some functi= onality, however, may not be available in

existing protocols, in whic= h case the solution may also involve new

protocol work. Leveraging e= xisting work means the working group benefits

from available security ana= lysis, implementation, and deployment

experience. Moreover, a sta= ndardized solution for federated

authentication and authoriz= ation will help to stimulate the deployment

of constrained devices that= provide increased security.

=C2=A0=

Once progress in identifyin= g suitable candidate solutions has been made,

the working group will veri= fy whether the same mechanisms are also

applicable beyond the use o= f CoAP and DTLS, which are the two main

protocols the group will fo= cus on for access to resources. In

particular, the ability to = use the developed solution over HTTP and TLS

will be investigated. Note = that the initial focus is on CoAP and HTTP with DTLS and TLS.=

Other security protocols ma= y be considered as long as the primary focus is maintained.=C2=A0

The group is scoped to work= only on the web protocols and data carried within them.

Furthermore, to guarantee s= mooth transition, the

integration with existing d= eployments will be studied, particularly

concerning the use of proto= col translation proxies.

=C2=A0=

This work does not make the= assumption that the party offering

application layer services = is always the same party offering network

access services.<= /u>

=C2=A0=

The working group has the f= ollowing tasks:

=C2=A0=

1) Produce use cases and re= quirements

=C2=A0=

2) Identify authentication = and authorization mechanisms suitable for

resource access in constrai= ned environments.

=C2=A0=

Milestones:

=C2=A0=

Dec 2014 Submit "Use c= ases and Requirements" as a WG item.

Dec 2014 Submit "Authe= ntication and Authorization Solution" as a WG item.

Apr 2015 Optionally, submit= "Use cases and Requirements" document

to the IESG for publication= as an Informational RFC.

Jul 2016 Submit "Authe= ntication and Authorization Solution"

specification to the IESG f= or publication as a Proposed Standard.

=C2=A0=

Proposed Milestones

No milestones for charter f= ound.

=C2=A0=

=C2=A0=

=C2=A0=

=E5=8F=91=E4=BB= =B6=E4=BA=BA: Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail= .com]
=E5=8F=91=E9=80=81=E6=97=B6=E9= =97=B4: 2014=E5=B9=B46=E6=9C=883=E6=97=A5<= span lang=3D"EN-US"> 14:30
=E6=94=B6=E4=BB=B6=E4=BA=BA: Likepeng
=E6=8A=84=E9=80=81: Benoit Claise; adrian@olddog.co.uk; aaa-doctors@ietf.org; The IESG; ace@ietf.org

=E4=B8=BB=E9=A2=98: Re: Revised charter proposal: charter-ietf-ace-00-02

=C2=A0

Hi Kepeng,=

=C2=A0

If we are at a point where I ca= n update the charter, seems that way, please send the latest version that h= as been agreed upon and I'll take care of the update.

=C2=A0

Thanks.

= =C2=A0

On Tue, Jun 3, 2014 at 6:31 AM,= Likepeng <like= peng@huawei.com> wrote:

Hi Benoit,

=C2=A0

>Not only would I keep &= quot;AAA",

=C2=A0

OK.

=C2=A0

>but I would propose

=C2=A0

>OLD:

>Existing authentication= and authorization protocols will be used where=

applicable to build the con= strained-environment solution.

=C2=A0

>NEW:

Existing authentication and= authorization protocols will be evaluated and re-used where

applicable to build the con= strained-environment solution.

=C2=A0

OK, fine with me.

=C2=A0

Thanks for the feedback.

=C2=A0

Kind Regards

Kepeng

=C2=A0

=E5=8F=91=E4=BB= =B6=E4=BA=BA: Benoit Claise [mailto:bclaise@cisco.com]
=E5=8F=91=E9=80=81=E6=97=B6=E9= =97=B4: 2014=E5=B9=B46=E6=9C=883=E6=97=A5<= span lang=3D"EN-US"> 12:16=

=E6=94=B6=E4=BB=B6=E4=BA=BA:= Likepeng; Kathleen Moriarty; adrian@olddog.co.u= k

=E6=8A=84=E9=80=81: aaa-doctors@ietf.org; The IESG; ace@ietf.org

=E4=B8=BB=E9=A2=98: Re: Revised charter proposal: charter-ietf-ace-00-0= 2

=C2=A0

= Hi,

Hello all,

=C2=A0

Based on recent discussions, I made a revised cha= rter proposal, as included in this email, not on the webpage yet.

=C2=A0

Please take a look and let us know if you have an= y further comments.

=C2=A0

@Adrian and @Benoit, please check if the proposed= texts can resolve your comments.

=C2=A0

Thanks,

Kind Regards

Kepeng

=C2=A0

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

Compared with charter-ietf-ace-00-01 on the webpa= ge, the changes are:

=C2=A0

(1)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Add one clarifi= cation sentence about REST architecture:

OLD

The IETF has recently developed protocols for use= in constrained

environments, where network nodes are limited in = CPU, memory and power.

REST architecture is widely used for such constra= ined environments.

=C2=A0

NEW

The IETF has recently developed protocols for use= in constrained

environments, where network nodes are limited in = CPU, memory and power.

REST architecture is widely used for such constra= ined environments.

END

Considering that OLD is<= u>

OLD=

The IETF has recently developed protocols for= use in constrained

environments, where network nodes are limited= in CPU, memory and power.

= ... fine with me

=C2=A0

=C2=A0

(2)=C2=A0=C2=A0=C2=A0=C2=A0 Remove =E2=80= =9CAAA protocol=E2=80=9D f= rom the charter:

OLD

The IETF has a long history in developing three-p= arty authentication and

authorization protocols for distributed environme= nts. Examples include

Kerberos, the Public Key Infrastructure (PKI), th= e Authentication,

Authorization and Accounting (AAA) infrastructure= , and the Web

Authorization Protocol (OAuth).

=C2=A0

NEW

The IETF has a long history in developing three-p= arty authentication and

authorization protocols for distributed environme= nts. Examples include

Kerberos, the Public Key Infrastructure (PKI), an= d the Web Authorization Protocol (OAuth).

END

We have AAA-doctors telling: ma= ybe RADIUS is applicable?
Personally, I don't know and it doesn't matter at this point.
We received feedback such as:

Let's be clear here: It was= never said (in the charter or anywhere else in the group to my knowledge) = that RADIUS (or indeed any other AAA protocol) would not run on constrained= devices (RFC 7228). The charter simply said the protocols were not optimised for constrained devices. That does n= ot preclude considering any protocol for suitability for constrained device= s either a) as is, b) in a restricted way or c) in an adapted way.

So, at this stage, I don't think any protocols should be excluded from = consideration and should certainly not be eliminated on a hunch that they m= ight be "too big". Let's do the assessment properly at the ap= propriate time. As a reminder - the focus now is to complete the charter.

Or

>>The Charter makes a number of assertions = that are provably false, such as that AAA protocols are inappropriate for c= onstrained environments.

In fact, the charter does not say that. But to av= oid confusion, let's remove AAA protocol from the charter.

=C2=A0

In the charter, we mentioned that we want to reus= e existing authentication and authorization protocols where applicable to b= uild the constrained-environment solution.

= ... which I read as: let's consider the AAA protocols, and evaluate if = they would work in constrained devices.
I don't understand the logic: why do you want to remove AAA from the ch= arter?
Not only would I keep "AAA", but I would propose

OLD:
Existing authentication and authorization protocols will be used where
applicable to build the constrained-environment solution

NEW:
Existing authentication and authorization protocols will be evaluated and r= e-used where
applicable to build the constrained-environment solution

Regards, Benoit

=C2=A0

=C2=A0

(3) Clarify the scope:

OLD:

Note that the initial focus is on CoAP and HTTP w= ith DTLS and TLS.

Other security protocols may be considered as lon= g as the primary focus is maintained.=C2=A0

Other application protocols and protocols at othe= r layers in the stack are out of scope.

=C2=A0

NEW

Note that the initial focus is on CoAP and HTTP w= ith DTLS and TLS.

Other security protocols may be considered as lon= g as the primary focus is maintained.=C2=A0

The group is scoped to work only on the web proto= cols and data carried within them.

END

=C2=A0

(4)=C2=A0=C2=A0=C2=A0=C2=A0 Update milestones for= the use case & requirements document:

OLD:

Jul 2015 Submit =E2=80=9CUse cases and Requirements=E2=80=9D documen= t to IESG for publication as informational RFC.

=C2=A0

NEW

Dec 2014 Optionally, submit "Use cases and R= equirements" document to the IESG for publication as an Informational = RFC.

END

=C2=A0

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

Charter charter-ietf-ace-00-02

Authentication and Authorization for Constrained<= u>

Environment (ACE)

=C2=A0

The IETF has recently developed protocols for use= in constrained

environments, where network nodes are limited in = CPU, memory and power.

REST architecture is widely used for such constra= ined environments.

It has been observed that Internet protocols can = be applied to these

constrained environments, often only requiring mi= nor tweaking and

profiling. In other cases, new protocols have bee= n defined to address

the specific requirements of constrained environm= ents. An example of

such a protocol is the Constrained Application Pr= otocol (CoAP).

=C2=A0

As in other environments, authentication and auth= orization questions

also arise in constrained environments. For examp= le, a door lock has to

authorize the person seeking access using a "= ;digital key". Where is the

authorization policy stored? How does the digital= key communicate with

the lock? Does the lock interact with an authoriz= ation server to obtain

authorization information? How can access be temp= orarily granted to

other persons? How can access be revoked? These t= ypes of questions have

been answered by existing protocols for use cases= outside constrained

environments, however in constrained environments= , additional and

different requirements pose challenges for the us= e of various security

protocols. In particular, the need arises for a d= ynamic and fine grained

access control mechanism, where clients and/or re= source servers are

constrained.

=C2=A0

The IETF has a long history in developing three-p= arty authentication and

authorization protocols for distributed environme= nts. Examples include

Kerberos, the Public Key Infrastructure (PKI), an= d the Web

Authorization Protocol (OAuth). All these protoco= ls enjoy widespread

deployment on the Internet. Although they all aim= to solve a similar

goal, at an abstract level, they offer quite diff= erent functions and

utilize different message exchanges. These differ= ences result from the

main deployment use cases they were designed for = respectively.

=C2=A0

Requirements derived from use cases indicate the = suitability of existing

work as a solution for constrained environments. = These protocols,

however, were not optimized for constrained envir= onments. Additional

requirements that need to be taken into account a= re the lack of a

suitable user-interface and the inability of embe= dded devices to contact

an authorization server in real-time with every r= esource access request

due to intermittent connectivity, etc.<= /u>

=C2=A0

This working group therefore aims to produce a st= andardized solution for

authentication and authorization to enable author= ized access (GET, PUT, POST,

DELETE) to resources identified by a URI and host= ed on a resource

server in constrained environments. As a starting= point, the working

group will assume that access to resources at a r= esource server by a

client device takes place using CoAP and is prote= cted by DTLS. Both

resource server and client may be constrained. Th= is access will be

mediated by an authorization server, which is not= considered to be

constrained.

=C2=A0

Existing authentication and authorization protoco= ls will be used where

applicable to build the constrained-environment s= olution. This requires

relevant specifications to be reviewed for suitab= ility, selecting a

subset of them and restricting the options within= each of the

specifications. Some functionality, however, may = not be available in

existing protocols, in which case the solution ma= y also involve new

protocol work. Leveraging existing work means the= working group benefits

from available security analysis, implementation,= and deployment

experience. Moreover, a standardized solution for= federated

authentication and authorization will help to sti= mulate the deployment

of constrained devices that provide increased sec= urity.

=C2=A0

Once progress in identifying suitable candidate s= olutions has been made,

the working group will verify whether the same me= chanisms are also

applicable beyond the use of CoAP and DTLS, which= are the two main

protocols the group will focus on for access to r= esources. In

particular, the ability to use the developed solu= tion over HTTP and TLS

will be investigated. Note that the initial focus= is on CoAP and HTTP with DTLS and TLS.

Other security protocols may be considered as lon= g as the primary focus is maintained.=C2=A0

The group is scoped to work only on the web proto= cols and data carried within them.

Furthermore, to guarantee smooth transition, the<= u>

integration with existing deployments will be stu= died, particularly

concerning the use of protocol translation proxie= s.

=C2=A0

This work does not make the assumption that the p= arty offering

application layer services is always the same par= ty offering network

access services.

=C2=A0

The working group has the following tasks:=

=C2=A0

1) Produce use cases and requirements

=C2=A0

2) Identify authentication and authorization mech= anisms suitable for

resource access in constrained environments.

=C2=A0

Milestones:

=C2=A0

Jul 2014 Submit "Use cases and Requirements&= quot; as a WG item.

Dec 2014 Submit "Authentication and Authoriz= ation Solution" as a WG item.

Dec 2014 Optionally, submit "Use cases and R= equirements" document

to the IESG for publication as an Informational R= FC.

Jul 2016 Submit "Authentication and Authoriz= ation Solution"

specification to the IESG for publication as a Pr= oposed Standard.

=C2=A0

Proposed Milestones

No milestones for charter found.

=C2=A0

=C2=A0

--

=C2=A0

Best regards,

Kathleen

--

Best regards,

Kathleen

--

Best regards,

Kathleen

--

Best regards,
Kathleen

--e89a8f23501567490804fb031ffe-- From nobody Wed Jun 4 07:55:14 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 695FF1A036D; Wed, 4 Jun 2014 07:55:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 JYe-NY-fr3gc; Wed, 4 Jun 2014 07:55:04 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C12D61A0367; Wed, 4 Jun 2014 07:55:03 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BEW27597; Wed, 04 Jun 2014 14:54:56 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 4 Jun 2014 15:54:02 +0100 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; Wed, 4 Jun 2014 15:54:49 +0100 Received: from SZXEMA501-MBS.china.huawei.com ([169.254.2.214]) by SZXEMA410-HUB.china.huawei.com ([10.82.72.42]) with mapi id 14.03.0158.001; Wed, 4 Jun 2014 22:54:43 +0800 From: Likepeng To: Benoit Claise , Kathleen Moriarty Thread-Topic: [Ace] Revised charter proposal: charter-ietf-ace-00-02 Thread-Index: AQHPeLrW9teE9ryEO0GmvALEdUzf8JtesfKAgACKjwD//5riAIAAjBcwgACnQACAAQ2jIA== Date: Wed, 4 Jun 2014 14:54:42 +0000 Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F258154550@SZXEMA501-MBS.china.huawei.com> References: <20140514221215.8150.56543.idtracker@ietfa.amsl.com> <34966E97BE8AD64EAE9D3D6E4DEE36F252B2A345@SZXEMA501-MBS.china.huawei.com> <34966E97BE8AD64EAE9D3D6E4DEE36F252B38978@SZXEMA501-MBS.china.huawei.com> <34966E97BE8AD64EAE9D3D6E4DEE36F258140E59@SZXEMA501-MBX.china.huawei.com> <538DA047.7080902@cisco.com> <34966E97BE8AD64EAE9D3D6E4DEE36F258153F43@SZXEMA501-MBS.china.huawei.com> <34966E97BE8AD64EAE9D3D6E4DEE36F25815405D@SZXEMA501-MBS.china.huawei.com> <538EC180.6000005@cisco.com> In-Reply-To: <538EC180.6000005@cisco.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.65.116] Content-Type: multipart/alternative; boundary="_000_34966E97BE8AD64EAE9D3D6E4DEE36F258154550SZXEMA501MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/ace/CNVtms0emyLkw4xmsOPRhuALGd8 Cc: "aaa-doctors@ietf.org" , "adrian@olddog.co.uk" , The IESG , "ace@ietf.org" Subject: Re: [Ace] Revised charter proposal: charter-ietf-ace-00-02 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments $ace$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 14:55:09 -0000 --_000_34966E97BE8AD64EAE9D3D6E4DEE36F258154550SZXEMA501MBSchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQmVub2l0LA0KDQpTb3JyeSwgbXkgbWlzdGFrZS4gSSBmb3Jnb3QgdG8gbWFrZSB0aGF0IGNo YW5nZS4NCg0KQEtldGhsZWVuLCBwbGVhc2UgaGVscCB0byBtYWtlIHRoZSBzdWdnZXN0ZWQgY2hh bmdlLg0KDQpUaGFua3MgYSBsb3QsDQoNCktpbmQgUmVnYXJkcw0KS2VwZW5nDQoNCuWPkeS7tuS6 ujogQWNlIFttYWlsdG86YWNlLWJvdW5jZXNAaWV0Zi5vcmddIOS7o+ihqCBCZW5vaXQgQ2xhaXNl DQrlj5HpgIHml7bpl7Q6IDIwMTTlubQ25pyINOaXpSA4OjUwDQrmlLbku7bkuro6IExpa2VwZW5n OyBLYXRobGVlbiBNb3JpYXJ0eQ0K5oqE6YCBOiBhYWEtZG9jdG9yc0BpZXRmLm9yZzsgYWRyaWFu QG9sZGRvZy5jby51azsgVGhlIElFU0c7IGFjZUBpZXRmLm9yZw0K5Li76aKYOiBSZTogW0FjZV0g UmV2aXNlZCBjaGFydGVyIHByb3Bvc2FsOiBjaGFydGVyLWlldGYtYWNlLTAwLTAyDQoNCkhpIExp a2VwZW5nLA0KDQpZb3UgZm9yZ290DQpPTEQ6DQpFeGlzdGluZyBhdXRoZW50aWNhdGlvbiBhbmQg YXV0aG9yaXphdGlvbiBwcm90b2NvbHMgd2lsbCBiZSB1c2VkIHdoZXJlDQphcHBsaWNhYmxlIHRv IGJ1aWxkIHRoZSBjb25zdHJhaW5lZC1lbnZpcm9ubWVudCBzb2x1dGlvbg0KDQpORVc6DQpFeGlz dGluZyBhdXRoZW50aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlvbiBwcm90b2NvbHMgd2lsbCBiZSBl dmFsdWF0ZWQgYW5kIHJlLXVzZWQgd2hlcmUNCmFwcGxpY2FibGUgdG8gYnVpbGQgdGhlIGNvbnN0 cmFpbmVkLWVudmlyb25tZW50IHNvbHV0aW9uDQoNClJlZ2FyZHMsIEJlbm9pdA0KDQo= --_000_34966E97BE8AD64EAE9D3D6E4DEE36F258154550SZXEMA501MBSchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OuWui+S9kzsNCgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1h cmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzsN Cgljb2xvcjpibGFjazt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls ZS1saW5rOiJIVE1MIOmihOiuvuagvOW8jyBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzsN Cgljb2xvcjpibGFjazt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0 YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi5om55rOo5qGG 5paH5pysIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv bnQtc2l6ZTo5LjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bh bi5IVE1MQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCDpooTorr7moLzlvI8gQ2hhciI7DQoJ bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIOmihOiuvuagvOW8 jyI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkNoYXINCgl7bXNvLXN0eWxl LW5hbWU6IuaJueazqOahhuaWh+acrCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ bXNvLXN0eWxlLWxpbms65om55rOo5qGG5paH5pysOw0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQpz cGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMjMNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2Ug V29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAu MHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iWkgtQ04iIGxpbms9 ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+SGkgQmVub2l0LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5Tb3JyeSwgbXkgbWlzdGFrZS4gSSBmb3Jnb3QgdG8gbWFrZSB0aGF0IGNoYW5nZS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QEtldGhsZWVuLCBwbGVhc2UgaGVscCB0 byBtYWtlIHRoZSBzdWdnZXN0ZWQgY2hhbmdlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5UaGFua3MgYSBsb3QsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PktpbmQgUmVnYXJkczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ S2VwZW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29s b3I6d2luZG93dGV4dCI+5Y+R5Lu25Lq6PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9zcGFu PjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6d2lu ZG93dGV4dCI+IEFjZSBbbWFpbHRvOmFjZS1ib3VuY2VzQGlldGYub3JnXQ0KPC9zcGFuPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOndpbmRvd3RleHQiPuS7o+ihqCA8L3Nw YW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjp3 aW5kb3d0ZXh0Ij5CZW5vaXQgQ2xhaXNlPGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2NvbG9yOndpbmRvd3RleHQiPuWPkemAgeaXtumXtDxzcGFuIGxhbmc9IkVO LVVTIj46PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2NvbG9yOndpbmRvd3RleHQiPiAyMDE0PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2NvbG9yOndpbmRvd3RleHQiPuW5tDxzcGFuIGxhbmc9IkVOLVVTIj42PC9z cGFuPuaciDxzcGFuIGxhbmc9IkVOLVVTIj40PC9zcGFuPuaXpTxzcGFuIGxhbmc9IkVOLVVTIj4N CiA4OjUwPGJyPg0KPC9zcGFuPjxiPuaUtuS7tuS6ujxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFu PjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IExpa2VwZW5nOyBLYXRobGVlbiBNb3JpYXJ0eTxicj4N Cjwvc3Bhbj48Yj7mioTpgIE8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFu Zz0iRU4tVVMiPiBhYWEtZG9jdG9yc0BpZXRmLm9yZzsgYWRyaWFuQG9sZGRvZy5jby51azsgVGhl IElFU0c7IGFjZUBpZXRmLm9yZzxicj4NCjwvc3Bhbj48Yj7kuLvpopg8c3BhbiBsYW5nPSJFTi1V UyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBSZTogW0FjZV0gUmV2aXNlZCBjaGFy dGVyIHByb3Bvc2FsOiBjaGFydGVyLWlldGYtYWNlLTAwLTAyPG86cD48L286cD48L3NwYW4+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5IaSBMaWtlcGVuZyw8YnI+DQo8YnI+DQpZb3Ug Zm9yZ290PGJyPg0KT0xEOjxicj4NCkV4aXN0aW5nIGF1dGhlbnRpY2F0aW9uIGFuZCBhdXRob3Jp emF0aW9uIHByb3RvY29scyB3aWxsIGJlIHVzZWQgd2hlcmU8YnI+DQphcHBsaWNhYmxlIHRvIGJ1 aWxkIHRoZSBjb25zdHJhaW5lZC1lbnZpcm9ubWVudCBzb2x1dGlvbjxicj4NCjxicj4NCk5FVzo8 YnI+DQpFeGlzdGluZyBhdXRoZW50aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlvbiBwcm90b2NvbHMg d2lsbCBiZSBldmFsdWF0ZWQgYW5kIHJlLXVzZWQgd2hlcmU8YnI+DQphcHBsaWNhYmxlIHRvIGJ1 aWxkIHRoZSBjb25zdHJhaW5lZC1lbnZpcm9ubWVudCBzb2x1dGlvbjxicj4NCjxicj4NClJlZ2Fy ZHMsIEJlbm9pdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_34966E97BE8AD64EAE9D3D6E4DEE36F258154550SZXEMA501MBSchi_-- From nobody Wed Jun 4 07:56:47 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4CA61A02B3; Wed, 4 Jun 2014 07:56:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 DFLR0MhNO9xN; Wed, 4 Jun 2014 07:56:40 -0700 (PDT) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDC9F1A036D; Wed, 4 Jun 2014 07:56:35 -0700 (PDT) Received: by mail-lb0-f177.google.com with SMTP id s7so4308405lbd.8 for ; Wed, 04 Jun 2014 07:56:28 -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=5MKB4YiAF0Bct4BohgCIMFHfsI5MxI0rm856lcYaUnE=; b=hNWjyWtu3LcELf7OeYgBJF9JHfIyrX3PPzJir4rqNVBj0UfXH+9vNEjpA+rUPq29sn QKmIbB2RmPKuOa45mMss8d0/BRoiri5yf23A1PI/Kn9WDGaezAjm7cfz0bF+vpNDno13 e3/ngRbyzup9vRmf+3HbkR61mNqWJqOY4iYIIvA6NABNquAARfLmXEnfTz4alCKsUkDl uHzUv/jEPeXlSMJQooiLZd7klirdP/2edi/8kXZUnEBsuUHicf12pCri6SCqLimCoI1W uj9zHu+eZaYK04zs90uUX4qkikLDdhZYIYptRbhRWMXtQaQAapR5EkxtyIYFaNkM1bsM lGag== MIME-Version: 1.0 X-Received: by 10.112.188.165 with SMTP id gb5mr3034231lbc.69.1401893788031; Wed, 04 Jun 2014 07:56:28 -0700 (PDT) Received: by 10.112.33.36 with HTTP; Wed, 4 Jun 2014 07:56:27 -0700 (PDT) In-Reply-To: References: <20140514221215.8150.56543.idtracker@ietfa.amsl.com> <34966E97BE8AD64EAE9D3D6E4DEE36F252B2A345@SZXEMA501-MBS.china.huawei.com> <34966E97BE8AD64EAE9D3D6E4DEE36F252B38978@SZXEMA501-MBS.china.huawei.com> <34966E97BE8AD64EAE9D3D6E4DEE36F258140E59@SZXEMA501-MBX.china.huawei.com> <538DA047.7080902@cisco.com> <34966E97BE8AD64EAE9D3D6E4DEE36F258153F43@SZXEMA501-MBS.china.huawei.com> <34966E97BE8AD64EAE9D3D6E4DEE36F25815405D@SZXEMA501-MBS.china.huawei.com> Date: Wed, 4 Jun 2014 10:56:27 -0400 Message-ID: From: Kathleen Moriarty To: =?UTF-8?Q?G=C3=B6ran_Selander?= Content-Type: multipart/alternative; boundary=001a11c36da23fa1e804fb03d5f9 Archived-At: http://mailarchive.ietf.org/arch/msg/ace/dlXMQqOdAvxIcGURnu2ZE9IExv4 Cc: "aaa-doctors@ietf.org" , The IESG , Likepeng , "ace@ietf.org" , Benoit Claise , "adrian@olddog.co.uk" Subject: Re: [Ace] Revised charter proposal: charter-ietf-ace-00-02 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments $ace$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 14:56:45 -0000 --001a11c36da23fa1e804fb03d5f9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Benoit had one other change mentioned in a previous email that was left out. He agrees that it is editorial. I'm fine with adding it if that is okay, but would prefer to leave "used" in instead of "re-used" as it isn't needed (IMO). Is the last option agreeable and would it clear your concerns, Benoit? OLD: Existing authentication and authorization protocols will be used where applicable to build the constrained-environment solution NEW: Existing authentication and authorization protocols will be evaluated and re-used where applicable to build the constrained-environment solution NEWER: Existing authentication and authorization protocols will be evaluated and used where applicable to build the constrained-environment solution On Wed, Jun 4, 2014 at 10:05 AM, Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: > Thank you, G=C3=B6ran. > > It must have been a cut-n-paste error. The first sentence for the > 'replace' did not match the original or the new either. If the next > version isn't quite right, pasting in a new full version may be better. > I'll look back through Benoit's comment now as well. > > > On Wed, Jun 4, 2014 at 3:06 AM, G=C3=B6ran Selander < > goran.selander@ericsson.com> wrote: > >> Hi Kathleen, >> >> In change #3 of the summary Kepeng made below I find the sentence: >>O= ther >> security protocols may be considered as long as the primary focus is >> maintained. >> This sentence seems to be missing from >> charter-ietf-ace-00-04. >> >> Regards, >> G=C3=B6ran >> >> >> From: Kathleen Moriarty >> Date: Tuesday 3 June 2014 22:27 >> To: Likepeng >> Cc: Benoit Claise , "adrian@olddog.co.uk" < >> adrian@olddog.co.uk>, "ace@ietf.org" , The IESG < >> iesg@ietf.org>, "aaa-doctors@ietf.org" >> Subject: Re: [Ace] Revised charter proposal: charter-ietf-ace-00-02 >> >> The charter text has been updated, >> https://datatracker.ietf.org/doc/charter-ietf-ace/ >> >> Thank you all for your input and assistance. If this is good, we'll >> move it forward for IETF review. >> >> >> >> On Tue, Jun 3, 2014 at 10:39 AM, Kathleen Moriarty < >> kathleen.moriarty.ietf@gmail.com> wrote: >> >>> I believe there is agreement on the proposed changes. I'll make the >>> updates later in the day (it's about 11:30 my time, maybe at 4) in case >>> anyone wants to chime in. If we are all in agreement, I'll have it sen= t >>> for IETF review at that point. >>> >>> Thank you! >>> >>> >>> On Tue, Jun 3, 2014 at 10:26 AM, Likepeng wrote: >>> >>>> Hi Kathleen and all, >>>> >>>> >>>> >>>> This is what I have now: >>>> >>>> >>>> >>>> Change #1: (Proposed by Kepeng, confirmed by Benoit) >>>> >>>> OLD >>>> >>>> The IETF has recently developed protocols for use in constrained >>>> >>>> environments, where network nodes are limited in CPU, memory and power= . >>>> >>>> >>>> >>>> NEW >>>> >>>> The IETF has recently developed protocols for use in constrained >>>> >>>> environments, where network nodes are limited in CPU, memory and power= . >>>> >>>> REST architecture is widely used for such constrained environments. >>>> >>>> END >>>> >>>> >>>> >>>> Change #2: (Proposal from Rene, supported by Stefanie) >>>> >>>> OLD: >>>> >>>> Requirements derived from use cases indicate the suitability of exist= ing >>>> >>>> work as a solution for constrained environments >>>> >>>> >>>> >>>> NEW: >>>> >>>> Requirements derived from use cases may indicate that existing work i= s >>>> >>>> useful as basis for as a solution for constrained environments >>>> >>>> >>>> >>>> Change #3: (Proposal from Jari, supported by Barry, Robert and Behcet) >>>> >>>> OLD: >>>> >>>> Note that the initial focus is on CoAP and HTTP with DTLS and TLS. >>>> >>>> Other security protocols may be considered as long as the primary focu= s is maintained. >>>> >>>> Other application protocols and protocols at other layers in the stack= are out of scope. >>>> >>>> >>>> >>>> NEW >>>> >>>> Note that the initial focus is on CoAP and HTTP with DTLS and TLS. >>>> >>>> Other security protocols may be considered as long as the primary focu= s is maintained. >>>> >>>> The group is scoped to work only on the web protocols and data carried= within them. >>>> >>>> END >>>> >>>> >>>> >>>> Change 4: (Proposal from Jari, revised by Rene, supported by Stefanie= ) >>>> >>>> OLD: >>>> >>>> Jul 2014 Submit "Use cases and Requirements" as a WG item. >>>> >>>> Jul 2015 Submit =E2=80=9CUse cases and Requirements=E2=80=9D document= to IESG for publication as informational RFC. >>>> >>>> >>>> >>>> NEW >>>> >>>> Dec 2014 Submit "Use cases and Requirements" as a WG item. >>>> >>>> Apr 2015 Optionally, submit "Use cases and Requirements" document to t= he IESG for >>>> >>>> publication as an Informational RFC. >>>> >>>> END >>>> >>>> >>>> >>>> I think we covered all of the IESG review comments. >>>> >>>> >>>> >>>> If there is any open issue, please let us know. >>>> >>>> >>>> >>>> Thanks, >>>> >>>> >>>> >>>> Kind Regards >>>> >>>> Kepeng >>>> >>>> >>>> ----------------------------------------------------------------------= ---------------------------------------------------------------------------= ------- >>>> >>>> >>>> >>>> Charter charter-ietf-ace-00-02 >>>> >>>> Authentication and Authorization for Constrained >>>> >>>> Environment (ACE) >>>> >>>> >>>> >>>> The IETF has recently developed protocols for use in constrained >>>> >>>> environments, where network nodes are limited in CPU, memory and power= . >>>> >>>> REST architecture is widely used for such constrained environments. >>>> >>>> It has been observed that Internet protocols can be applied to these >>>> >>>> constrained environments, often only requiring minor tweaking and >>>> >>>> profiling. In other cases, new protocols have been defined to address >>>> >>>> the specific requirements of constrained environments. An example of >>>> >>>> such a protocol is the Constrained Application Protocol (CoAP). >>>> >>>> >>>> >>>> As in other environments, authentication and authorization questions >>>> >>>> also arise in constrained environments. For example, a door lock has t= o >>>> >>>> authorize the person seeking access using a "digital key". Where is th= e >>>> >>>> authorization policy stored? How does the digital key communicate with >>>> >>>> the lock? Does the lock interact with an authorization server to obtai= n >>>> >>>> authorization information? How can access be temporarily granted to >>>> >>>> other persons? How can access be revoked? These types of questions hav= e >>>> >>>> been answered by existing protocols for use cases outside constrained >>>> >>>> environments, however in constrained environments, additional and >>>> >>>> different requirements pose challenges for the use of various security >>>> >>>> protocols. In particular, the need arises for a dynamic and fine grain= ed >>>> >>>> access control mechanism, where clients and/or resource servers are >>>> >>>> constrained. >>>> >>>> >>>> >>>> The IETF has a long history in developing three-party authentication a= nd >>>> >>>> authorization protocols for distributed environments. Examples include >>>> >>>> Kerberos, the Public Key Infrastructure (PKI), the Authentication, >>>> >>>> Authorization and Accounting (AAA) infrastructure,and the Web >>>> >>>> Authorization Protocol (OAuth). All these protocols enjoy widespread >>>> >>>> deployment on the Internet. Although they all aim to solve a similar >>>> >>>> goal, at an abstract level, they offer quite different functions and >>>> >>>> utilize different message exchanges. These differences result from the >>>> >>>> main deployment use cases they were designed for respectively. >>>> >>>> >>>> >>>> Requirements derived from use cases may indicate that existing work is >>>> >>>> useful as basis for as a solution for constrained environments. >>>> >>>> These protocols, >>>> >>>> however, were not optimized for constrained environments. Additional >>>> >>>> requirements that need to be taken into account are the lack of a >>>> >>>> suitable user-interface and the inability of embedded devices to conta= ct >>>> >>>> an authorization server in real-time with every resource access reques= t >>>> >>>> due to intermittent connectivity, etc. >>>> >>>> >>>> >>>> This working group therefore aims to produce a standardized solution f= or >>>> >>>> authentication and authorization to enable authorized access (GET, PUT= , >>>> POST, >>>> >>>> DELETE) to resources identified by a URI and hosted on a resource >>>> >>>> server in constrained environments. As a starting point, the working >>>> >>>> group will assume that access to resources at a resource server by a >>>> >>>> client device takes place using CoAP and is protected by DTLS. Both >>>> >>>> resource server and client may be constrained. This access will be >>>> >>>> mediated by an authorization server, which is not considered to be >>>> >>>> constrained. >>>> >>>> >>>> >>>> Existing authentication and authorization protocols will be evaluated >>>> >>>> and re-used where applicable to build the constrained-environment >>>> solution. >>>> >>>> This requires >>>> >>>> relevant specifications to be reviewed for suitability, selecting a >>>> >>>> subset of them and restricting the options within each of the >>>> >>>> specifications. Some functionality, however, may not be available in >>>> >>>> existing protocols, in which case the solution may also involve new >>>> >>>> protocol work. Leveraging existing work means the working group benefi= ts >>>> >>>> from available security analysis, implementation, and deployment >>>> >>>> experience. Moreover, a standardized solution for federated >>>> >>>> authentication and authorization will help to stimulate the deployment >>>> >>>> of constrained devices that provide increased security. >>>> >>>> >>>> >>>> Once progress in identifying suitable candidate solutions has been mad= e, >>>> >>>> the working group will verify whether the same mechanisms are also >>>> >>>> applicable beyond the use of CoAP and DTLS, which are the two main >>>> >>>> protocols the group will focus on for access to resources. In >>>> >>>> particular, the ability to use the developed solution over HTTP and TL= S >>>> >>>> will be investigated. Note that the initial focus is on CoAP and HTTP >>>> with DTLS and TLS. >>>> >>>> Other security protocols may be considered as long as the primary focu= s >>>> is maintained. >>>> >>>> The group is scoped to work only on the web protocols and data carried >>>> within them. >>>> >>>> Furthermore, to guarantee smooth transition, the >>>> >>>> integration with existing deployments will be studied, particularly >>>> >>>> concerning the use of protocol translation proxies. >>>> >>>> >>>> >>>> This work does not make the assumption that the party offering >>>> >>>> application layer services is always the same party offering network >>>> >>>> access services. >>>> >>>> >>>> >>>> The working group has the following tasks: >>>> >>>> >>>> >>>> 1) Produce use cases and requirements >>>> >>>> >>>> >>>> 2) Identify authentication and authorization mechanisms suitable for >>>> >>>> resource access in constrained environments. >>>> >>>> >>>> >>>> Milestones: >>>> >>>> >>>> >>>> Dec 2014 Submit "Use cases and Requirements" as a WG item. >>>> >>>> Dec 2014 Submit "Authentication and Authorization Solution" as a WG >>>> item. >>>> >>>> Apr 2015 Optionally, submit "Use cases and Requirements" document >>>> >>>> to the IESG for publication as an Informational RFC. >>>> >>>> Jul 2016 Submit "Authentication and Authorization Solution" >>>> >>>> specification to the IESG for publication as a Proposed Standard. >>>> >>>> >>>> >>>> Proposed Milestones >>>> >>>> No milestones for charter found. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> *=E5=8F=91=E4=BB=B6=E4=BA=BA:* Kathleen Moriarty [mailto:kathleen.mori= arty.ietf@gmail.com] >>>> *=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4:* 2014=E5=B9=B46=E6=9C=883=E6=97= =A5 14:30 >>>> *=E6=94=B6=E4=BB=B6=E4=BA=BA:* Likepeng >>>> *=E6=8A=84=E9=80=81:* Benoit Claise; adrian@olddog.co.uk; aaa-doctors@= ietf.org; The >>>> IESG; ace@ietf.org >>>> *=E4=B8=BB=E9=A2=98:* Re: Revised charter proposal: charter-ietf-ace-= 00-02 >>>> >>>> >>>> >>>> Hi Kepeng, >>>> >>>> >>>> >>>> If we are at a point where I can update the charter, seems that way, >>>> please send the latest version that has been agreed upon and I'll take= care >>>> of the update. >>>> >>>> >>>> >>>> Thanks. >>>> >>>> >>>> >>>> On Tue, Jun 3, 2014 at 6:31 AM, Likepeng wrote: >>>> >>>> Hi Benoit, >>>> >>>> >>>> >>>> >Not only would I keep "AAA", >>>> >>>> >>>> >>>> OK. >>>> >>>> >>>> >>>> >but I would propose >>>> >>>> >>>> >>>> >OLD: >>>> >>>> >Existing authentication and authorization protocols will be used wher= e >>>> >>>> applicable to build the constrained-environment solution. >>>> >>>> >>>> >>>> >NEW: >>>> >>>> Existing authentication and authorization protocols will be evaluated >>>> and re-used where >>>> >>>> applicable to build the constrained-environment solution. >>>> >>>> >>>> >>>> OK, fine with me. >>>> >>>> >>>> >>>> Thanks for the feedback. >>>> >>>> >>>> >>>> Kind Regards >>>> >>>> Kepeng >>>> >>>> >>>> >>>> *=E5=8F=91=E4=BB=B6=E4=BA=BA:* Benoit Claise [mailto:bclaise@cisco.com= ] >>>> *=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4:* 2014=E5=B9=B46=E6=9C=883=E6=97= =A5 12:16 >>>> >>>> *=E6=94=B6=E4=BB=B6=E4=BA=BA:* Likepeng; Kathleen Moriarty; adrian@old= dog.co.uk >>>> >>>> *=E6=8A=84=E9=80=81:* aaa-doctors@ietf.org; The IESG; ace@ietf.org >>>> >>>> *=E4=B8=BB=E9=A2=98:* Re: Revised charter proposal: charter-ietf-ace-0= 0-02 >>>> >>>> >>>> >>>> Hi, >>>> >>>> Hello all, >>>> >>>> >>>> >>>> Based on recent discussions, I made a revised charter proposal, as inc= luded in this email, not on the webpage yet. >>>> >>>> >>>> >>>> Please take a look and let us know if you have any further comments. >>>> >>>> >>>> >>>> @Adrian and @Benoit, please check if the proposed texts can resolve yo= ur comments. >>>> >>>> >>>> >>>> Thanks, >>>> >>>> Kind Regards >>>> >>>> Kepeng >>>> >>>> >>>> >>>> ----------------------------------------------------------------------= ---------------------------------------------------------------------------= ------------ >>>> >>>> Compared with charter-ietf-ace-00-01 on the webpage, the changes are: >>>> >>>> >>>> >>>> (1) Add one clarification sentence about REST architecture: >>>> >>>> OLD >>>> >>>> The IETF has recently developed protocols for use in constrained >>>> >>>> environments, where network nodes are limited in CPU, memory and power= . >>>> >>>> REST architecture is widely used for such constrained environments. >>>> >>>> >>>> >>>> NEW >>>> >>>> The IETF has recently developed protocols for use in constrained >>>> >>>> environments, where network nodes are limited in CPU, memory and power= . >>>> >>>> REST architecture is widely used for such constrained environments. >>>> >>>> END >>>> >>>> Considering that OLD is >>>> >>>> OLD >>>> >>>> The IETF has recently developed protocols for use in constrained >>>> >>>> environments, where network nodes are limited in CPU, memory and power= . >>>> >>>> ... fine with me >>>> >>>> >>>> >>>> >>>> >>>> (2) Remove =E2=80=9CAAA protocol=E2=80=9D from the charter: >>>> >>>> OLD >>>> >>>> The IETF has a long history in developing three-party authentication a= nd >>>> >>>> authorization protocols for distributed environments. Examples include >>>> >>>> Kerberos, the Public Key Infrastructure (PKI), the Authentication, >>>> >>>> Authorization and Accounting (AAA) infrastructure, and the Web >>>> >>>> Authorization Protocol (OAuth). >>>> >>>> >>>> >>>> NEW >>>> >>>> The IETF has a long history in developing three-party authentication a= nd >>>> >>>> authorization protocols for distributed environments. Examples include >>>> >>>> Kerberos, the Public Key Infrastructure (PKI), and the Web Authorizati= on Protocol (OAuth). >>>> >>>> END >>>> >>>> We have AAA-doctors telling: maybe RADIUS is applicable? >>>> Personally, I don't know and it doesn't matter at this point. >>>> We received feedback such as: >>>> >>>> Let's be clear here: It was never said (in the charter or anywhere els= e >>>> in the group to my knowledge) that RADIUS (or indeed any other AAA >>>> protocol) would not run on constrained devices (RFC 7228). The charter >>>> simply said the protocols were not optimised for constrained devices. = That >>>> does not preclude considering any protocol for suitability for constra= ined >>>> devices either a) as is, b) in a restricted way or c) in an adapted wa= y. >>>> >>>> So, at this stage, I don't think any protocols should be excluded from >>>> consideration and should certainly not be eliminated on a hunch that t= hey >>>> might be "too big". Let's do the assessment properly at the appropriat= e >>>> time. As a reminder - the focus now is to complete the charter. >>>> >>>> Or >>>> >>>> >>The Charter makes a number of assertions that are provably false, su= ch as that AAA protocols are inappropriate for constrained environments. >>>> >>>> In fact, the charter does not say that. But to avoid confusion, let's = remove AAA protocol from the charter. >>>> >>>> >>>> >>>> In the charter, we mentioned that we want to reuse existing authentica= tion and authorization protocols where applicable to build the constrained-= environment solution. >>>> >>>> ... which I read as: let's consider the AAA protocols, and evaluate if >>>> they would work in constrained devices. >>>> I don't understand the logic: why do you want to remove AAA from the >>>> charter? >>>> Not only would I keep "AAA", but I would propose >>>> >>>> OLD: >>>> Existing authentication and authorization protocols will be used where >>>> applicable to build the constrained-environment solution >>>> >>>> NEW: >>>> Existing authentication and authorization protocols will be evaluated >>>> and re-used where >>>> applicable to build the constrained-environment solution >>>> >>>> Regards, Benoit >>>> >>>> >>>> >>>> >>>> >>>> (3) Clarify the scope: >>>> >>>> OLD: >>>> >>>> Note that the initial focus is on CoAP and HTTP with DTLS and TLS. >>>> >>>> Other security protocols may be considered as long as the primary focu= s is maintained. >>>> >>>> Other application protocols and protocols at other layers in the stack= are out of scope. >>>> >>>> >>>> >>>> NEW >>>> >>>> Note that the initial focus is on CoAP and HTTP with DTLS and TLS. >>>> >>>> Other security protocols may be considered as long as the primary focu= s is maintained. >>>> >>>> The group is scoped to work only on the web protocols and data carried= within them. >>>> >>>> END >>>> >>>> >>>> >>>> (4) Update milestones for the use case & requirements document: >>>> >>>> OLD: >>>> >>>> Jul 2015 Submit =E2=80=9CUse cases and Requirements=E2=80=9D document = to IESG for publication as informational RFC. >>>> >>>> >>>> >>>> NEW >>>> >>>> Dec 2014 Optionally, submit "Use cases and Requirements" document to t= he IESG for publication as an Informational RFC. >>>> >>>> END >>>> >>>> >>>> >>>> ----------------------------------------------------------------------= ---------------------------------------------------------------------------= --------------------------- >>>> >>>> Charter charter-ietf-ace-00-02 >>>> >>>> Authentication and Authorization for Constrained >>>> >>>> Environment (ACE) >>>> >>>> >>>> >>>> The IETF has recently developed protocols for use in constrained >>>> >>>> environments, where network nodes are limited in CPU, memory and power= . >>>> >>>> REST architecture is widely used for such constrained environments. >>>> >>>> It has been observed that Internet protocols can be applied to these >>>> >>>> constrained environments, often only requiring minor tweaking and >>>> >>>> profiling. In other cases, new protocols have been defined to address >>>> >>>> the specific requirements of constrained environments. An example of >>>> >>>> such a protocol is the Constrained Application Protocol (CoAP). >>>> >>>> >>>> >>>> As in other environments, authentication and authorization questions >>>> >>>> also arise in constrained environments. For example, a door lock has t= o >>>> >>>> authorize the person seeking access using a "digital key". Where is th= e >>>> >>>> authorization policy stored? How does the digital key communicate with >>>> >>>> the lock? Does the lock interact with an authorization server to obtai= n >>>> >>>> authorization information? How can access be temporarily granted to >>>> >>>> other persons? How can access be revoked? These types of questions hav= e >>>> >>>> been answered by existing protocols for use cases outside constrained >>>> >>>> environments, however in constrained environments, additional and >>>> >>>> different requirements pose challenges for the use of various security >>>> >>>> protocols. In particular, the need arises for a dynamic and fine grain= ed >>>> >>>> access control mechanism, where clients and/or resource servers are >>>> >>>> constrained. >>>> >>>> >>>> >>>> The IETF has a long history in developing three-party authentication a= nd >>>> >>>> authorization protocols for distributed environments. Examples include >>>> >>>> Kerberos, the Public Key Infrastructure (PKI), and the Web >>>> >>>> Authorization Protocol (OAuth). All these protocols enjoy widespread >>>> >>>> deployment on the Internet. Although they all aim to solve a similar >>>> >>>> goal, at an abstract level, they offer quite different functions and >>>> >>>> utilize different message exchanges. These differences result from the >>>> >>>> main deployment use cases they were designed for respectively. >>>> >>>> >>>> >>>> Requirements derived from use cases indicate the suitability of existi= ng >>>> >>>> work as a solution for constrained environments. These protocols, >>>> >>>> however, were not optimized for constrained environments. Additional >>>> >>>> requirements that need to be taken into account are the lack of a >>>> >>>> suitable user-interface and the inability of embedded devices to conta= ct >>>> >>>> an authorization server in real-time with every resource access reques= t >>>> >>>> due to intermittent connectivity, etc. >>>> >>>> >>>> >>>> This working group therefore aims to produce a standardized solution f= or >>>> >>>> authentication and authorization to enable authorized access (GET, PUT= , POST, >>>> >>>> DELETE) to resources identified by a URI and hosted on a resource >>>> >>>> server in constrained environments. As a starting point, the working >>>> >>>> group will assume that access to resources at a resource server by a >>>> >>>> client device takes place using CoAP and is protected by DTLS. Both >>>> >>>> resource server and client may be constrained. This access will be >>>> >>>> mediated by an authorization server, which is not considered to be >>>> >>>> constrained. >>>> >>>> >>>> >>>> Existing authentication and authorization protocols will be used where >>>> >>>> applicable to build the constrained-environment solution. This require= s >>>> >>>> relevant specifications to be reviewed for suitability, selecting a >>>> >>>> subset of them and restricting the options within each of the >>>> >>>> specifications. Some functionality, however, may not be available in >>>> >>>> existing protocols, in which case the solution may also involve new >>>> >>>> protocol work. Leveraging existing work means the working group benefi= ts >>>> >>>> from available security analysis, implementation, and deployment >>>> >>>> experience. Moreover, a standardized solution for federated >>>> >>>> authentication and authorization will help to stimulate the deployment >>>> >>>> of constrained devices that provide increased security. >>>> >>>> >>>> >>>> Once progress in identifying suitable candidate solutions has been mad= e, >>>> >>>> the working group will verify whether the same mechanisms are also >>>> >>>> applicable beyond the use of CoAP and DTLS, which are the two main >>>> >>>> protocols the group will focus on for access to resources. In >>>> >>>> particular, the ability to use the developed solution over HTTP and TL= S >>>> >>>> will be investigated. Note that the initial focus is on CoAP and HTTP = with DTLS and TLS. >>>> >>>> Other security protocols may be considered as long as the primary focu= s is maintained. >>>> >>>> The group is scoped to work only on the web protocols and data carried= within them. >>>> >>>> Furthermore, to guarantee smooth transition, the >>>> >>>> integration with existing deployments will be studied, particularly >>>> >>>> concerning the use of protocol translation proxies. >>>> >>>> >>>> >>>> This work does not make the assumption that the party offering >>>> >>>> application layer services is always the same party offering network >>>> >>>> access services. >>>> >>>> >>>> >>>> The working group has the following tasks: >>>> >>>> >>>> >>>> 1) Produce use cases and requirements >>>> >>>> >>>> >>>> 2) Identify authentication and authorization mechanisms suitable for >>>> >>>> resource access in constrained environments. >>>> >>>> >>>> >>>> Milestones: >>>> >>>> >>>> >>>> Jul 2014 Submit "Use cases and Requirements" as a WG item. >>>> >>>> Dec 2014 Submit "Authentication and Authorization Solution" as a WG it= em. >>>> >>>> Dec 2014 Optionally, submit "Use cases and Requirements" document >>>> >>>> to the IESG for publication as an Informational RFC. >>>> >>>> Jul 2016 Submit "Authentication and Authorization Solution" >>>> >>>> specification to the IESG for publication as a Proposed Standard. >>>> >>>> >>>> >>>> Proposed Milestones >>>> >>>> No milestones for charter found. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> >>>> >>>> >>>> Best regards, >>>> >>>> Kathleen >>>> >>> >>> >>> >>> -- >>> >>> Best regards, >>> Kathleen >>> >> >> >> >> -- >> >> Best regards, >> Kathleen >> >> > > > -- > > Best regards, > Kathleen > --=20 Best regards, Kathleen --001a11c36da23fa1e804fb03d5f9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Benoit=C2=A0had one other change mentioned in a previous email that was l= eft out. He agrees that it is editorial. =C2=A0I'm fine with adding it = if that is okay, but would prefer to leave "used" in instead of &= quot;re-used" as it isn't needed (IMO).

Is the last option agreeable and would it clear your concern= s, Benoit?
OLD:
Existing= authentication and authorization protocols will be used where
applicable to build the constrained-environment solution

NEW:
Exi= sting authentication and authorization protocols will be evaluated and re-u= sed where
applicable to build the constrained-environment solution

NEWER:
Existing authentication and authorization protocols will be e= valuated and used where
applicable to build the constrained-environment = solution

On Wed, Jun 4, 2014 at 10:05 AM, Kathleen Moriarty <kathlee= n.moriarty.ietf@gmail.com> wrote:

Thank you,=C2=A0G=C3=B6ran.

It must have been a cut= -n-paste error. =C2=A0The first sentence for the 'replace' did not = match the original or the new either. =C2=A0If the next version isn't q= uite right, pasting in a new full version may be better. =C2=A0I'll loo= k back through Benoit's comment now as well.

On Wed, Jun 4, 2014 at 3:06 AM, G=C3=B6ran Selander <goran.selander@ericsson.com> wrote:

Hi Kathleen,

In change #3 of the summary Kepeng made below=C2=A0I find the sentence: >>Other security protocols may be cons= idered as long as the primary focus is maintained. >>=C2=A0This=C2=A0sentence seems to be missing from charter-ietf-ace-00-04.=

Regards,

G=C3=B6ran

From: Kathleen Moriarty <kathleen.mor= iarty.ietf@gmail.com>
Date: Tuesday 3 June 2014 22:27
To: Likepeng <likepeng@huawei.com>
Cc: Benoit Claise <bclaise@cisco.com>, "= adrian@olddog.co.u= k" <ad= rian@olddog.co.uk>, "ace@ietf.org" <ace@ietf.org>= , The IESG <iesg@ietf= .org>, "aaa-doctors@ietf.org" <aaa-doctors@ietf.org>
Subject: Re: [Ace] Revised charter = proposal: charter-ietf-ace-00-02

The charter text has been updated,=C2=A0https://data= tracker.ietf.org/doc/charter-ietf-ace/

Thank you all for your input and assistance. =C2=A0If this is good, we= 'll move it forward for IETF review.

On Tue, Jun 3, 2014 at 10:39 AM, Kathleen Moriar= ty <k= athleen.moriarty.ietf@gmail.com> wrote:

I believe there is agreement on the proposed changes. =C2= =A0I'll make the updates later in the day (it's about 11:30 my time= , maybe at 4) in case anyone wants to chime in. =C2=A0If we are all in agre= ement, I'll have it sent for IETF review at that point.

Thank you!

On Tue, Jun 3, 2014 at 10:26 AM, Likepeng <likepeng@huawe= i.com> wrote:

Hi Kathleen and all,=

=C2=A0=

This is what I have now:=

=C2=A0=

Change #1: (Proposed by Kep= eng, confirmed by Benoit)

OLD

The IETF has recently developed protocols for= use in constrained

environments, where network nodes are limited= in CPU, memory and power.

=C2=A0

NEW

The IETF has recently developed protocols for= use in constrained

environments, where network nodes are limited= in CPU, memory and power.

REST architecture is widely used for such con= strained environments.

END

=C2=A0

Change #2: (Proposal from Rene, supported by = Stefanie)

OLD:

Requirements derived from use cases indicate = the suitability of existing

work as a solution for constrained environmen= ts

=C2=A0

NEW:

Requirements derived from use cases may indic= ate that existing work is

useful as basis for as a solution for constr= ained environments

=C2=A0

Change #3: (Proposal from Jari, supported by = Barry, Robert and Behcet)

OLD:

Note that the initial focus is on CoAP and HT= TP with DTLS and TLS.

Other security protocols may be considered as= long as the primary focus is maintained.=C2=A0

Other application protocols and protocols at = other layers in the stack are out of scope.

=C2=A0

NEW

Note that the initial focus is on CoAP and HT= TP with DTLS and TLS.

Other security protocols may be considered as= long as the primary focus is maintained.=C2=A0

The group is scoped to work only on the web p= rotocols and data carried within them.

END

=C2=A0

Change 4: (Proposal from Jari, revised by Ren= e, supported by Stefanie)

OLD:

Jul 2014 Submit "Use cases and Requireme= nts" as a WG item.

Jul 2015 Submit =E2=80=9CUse cases and Requir= ements=E2=80=9D document to IESG for publication as informational RFC.

=C2=A0

NEW

Dec 2014 Submit "Use cases and Requireme= nts" as a WG item.

Apr 2015 Optionally, submit "Use cases a= nd Requirements" document to the IESG for

publication as an Informational RFC.

END

=C2=A0=

I think we covered all of t= he IESG review comments.

=C2=A0=

If there is any open issue,= please let us know.

=C2=A0=

Thanks,

=C2=A0=

Kind Regards<= /span>

Kepeng=

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

=C2=A0=

Charter charter-ietf-ace-00= -02

Authentication and Authoriz= ation for Constrained

Environment (ACE)=

=C2=A0=

The IETF has recently devel= oped protocols for use in constrained

environments, where network= nodes are limited in CPU, memory and power.

REST architecture is widely= used for such constrained environments.

It has been observed that I= nternet protocols can be applied to these

constrained environments, o= ften only requiring minor tweaking and

profiling. In other cases, = new protocols have been defined to address

the specific requirements o= f constrained environments. An example of

such a protocol is the Cons= trained Application Protocol (CoAP).

=C2=A0=

As in other environments, a= uthentication and authorization questions

also arise in constrained e= nvironments. For example, a door lock has to

authorize the person seekin= g access using a "digital key". Where is the=

authorization policy stored= ? How does the digital key communicate with

the lock? Does the lock int= eract with an authorization server to obtain

authorization information? = How can access be temporarily granted to

other persons? How can acce= ss be revoked? These types of questions have

been answered by existing p= rotocols for use cases outside constrained

environments, however in co= nstrained environments, additional and

different requirements pose= challenges for the use of various security

protocols. In particular, t= he need arises for a dynamic and fine grained

access control mechanism, w= here clients and/or resource servers are

constrained.<= /span>

=C2=A0=

The IETF has a long history= in developing three-party authentication and

authorization protocols for= distributed environments. Examples include

Kerberos, the Public Key In= frastructure (PKI), the Authentication,

Authorization and Accountin= g (AAA) infrastructure,and the Web

Authorization Protocol (OAu= th). All these protocols enjoy widespread

deployment on the Internet.= Although they all aim to solve a similar

goal, at an abstract level,= they offer quite different functions and

utilize different message e= xchanges. These differences result from the

main deployment use cases t= hey were designed for respectively.

=C2=A0=

Requirements derived from u= se cases may indicate that existing work is

useful as basis for as a so= lution for constrained environments.

These protocols,<= /u>

however, were not optimized= for constrained environments. Additional

requirements that need to b= e taken into account are the lack of a

suitable user-interface and= the inability of embedded devices to contact

an authorization server in = real-time with every resource access request

due to intermittent connect= ivity, etc.

=C2=A0=

This working group therefor= e aims to produce a standardized solution for

authentication and authoriz= ation to enable authorized access (GET, PUT, POST,

DELETE) to resources identi= fied by a URI and hosted on a resource

server in constrained envir= onments. As a starting point, the working

group will assume that acce= ss to resources at a resource server by a

client device takes place u= sing CoAP and is protected by DTLS. Both

resource server and client = may be constrained. This access will be

mediated by an authorizatio= n server, which is not considered to be

constrained.<= /span>

=C2=A0=

Existing authentication and= authorization protocols will be evaluated

and re-used where applicabl= e to build the constrained-environment solution.

This requires=

relevant specifications to = be reviewed for suitability, selecting a

subset of them and restrict= ing the options within each of the

specifications. Some functi= onality, however, may not be available in

existing protocols, in whic= h case the solution may also involve new

protocol work. Leveraging e= xisting work means the working group benefits

from available security ana= lysis, implementation, and deployment

experience. Moreover, a sta= ndardized solution for federated

authentication and authoriz= ation will help to stimulate the deployment

of constrained devices that= provide increased security.

=C2=A0=

Once progress in identifyin= g suitable candidate solutions has been made,

the working group will veri= fy whether the same mechanisms are also

applicable beyond the use o= f CoAP and DTLS, which are the two main

protocols the group will fo= cus on for access to resources. In

particular, the ability to = use the developed solution over HTTP and TLS

will be investigated. Note = that the initial focus is on CoAP and HTTP with DTLS and TLS.=

Other security protocols ma= y be considered as long as the primary focus is maintained.=C2=A0

The group is scoped to work= only on the web protocols and data carried within them.

Furthermore, to guarantee s= mooth transition, the

integration with existing d= eployments will be studied, particularly

concerning the use of proto= col translation proxies.

=C2=A0=

This work does not make the= assumption that the party offering

application layer services = is always the same party offering network

access services.<= /u>

=C2=A0=

The working group has the f= ollowing tasks:

=C2=A0=

1) Produce use cases and re= quirements

=C2=A0=

2) Identify authentication = and authorization mechanisms suitable for

resource access in constrai= ned environments.

=C2=A0=

Milestones:

=C2=A0=

Dec 2014 Submit "Use c= ases and Requirements" as a WG item.

Dec 2014 Submit "Authe= ntication and Authorization Solution" as a WG item.

Apr 2015 Optionally, submit= "Use cases and Requirements" document

to the IESG for publication= as an Informational RFC.

Jul 2016 Submit "Authe= ntication and Authorization Solution"

specification to the IESG f= or publication as a Proposed Standard.

=C2=A0=

Proposed Milestones

No milestones for charter f= ound.

=C2=A0=

=C2=A0=

=C2=A0=

=E5=8F=91=E4=BB= =B6=E4=BA=BA: Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail= .com]
=E5=8F=91=E9=80=81=E6=97=B6=E9= =97=B4: 2014=E5=B9=B46=E6=9C=883=E6=97=A5<= span lang=3D"EN-US"> 14:30
=E6=94=B6=E4=BB=B6=E4=BA=BA: Likepeng
=E6=8A=84=E9=80=81: Benoit Claise; adrian@olddog.co.uk; aaa-doctors@ietf.org; The IESG; ace@ietf.org

=E4=B8=BB=E9=A2=98: Re: Revised charter proposal: charter-ietf-ace-00-02

=C2=A0

Hi Kepeng,=

=C2=A0

If we are at a point where I ca= n update the charter, seems that way, please send the latest version that h= as been agreed upon and I'll take care of the update.

=C2=A0

Thanks.

= =C2=A0

On Tue, Jun 3, 2014 at 6:31 AM,= Likepeng <like= peng@huawei.com> wrote:

Hi Benoit,

=C2=A0

>Not only would I keep &= quot;AAA",

=C2=A0

OK.

=C2=A0

>but I would propose

=C2=A0

>OLD:

>Existing authentication= and authorization protocols will be used where=

applicable to build the con= strained-environment solution.

=C2=A0

>NEW:

Existing authentication and= authorization protocols will be evaluated and re-used where

applicable to build the con= strained-environment solution.

=C2=A0

OK, fine with me.

=C2=A0

Thanks for the feedback.

=C2=A0

Kind Regards

Kepeng

=C2=A0

=E5=8F=91=E4=BB= =B6=E4=BA=BA: Benoit Claise [mailto:bclaise@cisco.com]
=E5=8F=91=E9=80=81=E6=97=B6=E9= =97=B4: 2014=E5=B9=B46=E6=9C=883=E6=97=A5<= span lang=3D"EN-US"> 12:16=

=E6=94=B6=E4=BB=B6=E4=BA=BA:= Likepeng; Kathleen Moriarty; adrian@olddog.co.u= k

=E6=8A=84=E9=80=81: aaa-doctors@ietf.org; The IESG; ace@ietf.org

=E4=B8=BB=E9=A2=98: Re: Revised charter proposal: charter-ietf-ace-00-0= 2

=C2=A0

= Hi,

Hello all,

=C2=A0

Based on recent discussions, I made a revised cha= rter proposal, as included in this email, not on the webpage yet.

=C2=A0

Please take a look and let us know if you have an= y further comments.

=C2=A0

@Adrian and @Benoit, please check if the proposed= texts can resolve your comments.

=C2=A0

Thanks,

Kind Regards

Kepeng

=C2=A0

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

Compared with charter-ietf-ace-00-01 on the webpa= ge, the changes are:

=C2=A0

(1)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Add one clarifi= cation sentence about REST architecture:

OLD

The IETF has recently developed protocols for use= in constrained

environments, where network nodes are limited in = CPU, memory and power.

REST architecture is widely used for such constra= ined environments.

=C2=A0

NEW

The IETF has recently developed protocols for use= in constrained

environments, where network nodes are limited in = CPU, memory and power.

REST architecture is widely used for such constra= ined environments.

END

Considering that OLD is<= u>

OLD=

The IETF has recently developed protocols for= use in constrained

environments, where network nodes are limited= in CPU, memory and power.

= ... fine with me

=C2=A0

=C2=A0

(2)=C2=A0=C2=A0=C2=A0=C2=A0 Remove =E2=80= =9CAAA protocol=E2=80=9D f= rom the charter:

OLD

The IETF has a long history in developing three-p= arty authentication and

authorization protocols for distributed environme= nts. Examples include

Kerberos, the Public Key Infrastructure (PKI), th= e Authentication,

Authorization and Accounting (AAA) infrastructure= , and the Web

Authorization Protocol (OAuth).

=C2=A0

NEW

The IETF has a long history in developing three-p= arty authentication and

authorization protocols for distributed environme= nts. Examples include

Kerberos, the Public Key Infrastructure (PKI), an= d the Web Authorization Protocol (OAuth).

END

We have AAA-doctors telling: ma= ybe RADIUS is applicable?
Personally, I don't know and it doesn't matter at this point.
We received feedback such as:

Let's be clear here: It was= never said (in the charter or anywhere else in the group to my knowledge) = that RADIUS (or indeed any other AAA protocol) would not run on constrained= devices (RFC 7228). The charter simply said the protocols were not optimised for constrained devices. That does n= ot preclude considering any protocol for suitability for constrained device= s either a) as is, b) in a restricted way or c) in an adapted way.

So, at this stage, I don't think any protocols should be excluded from = consideration and should certainly not be eliminated on a hunch that they m= ight be "too big". Let's do the assessment properly at the ap= propriate time. As a reminder - the focus now is to complete the charter.

Or

>>The Charter makes a number of assertions = that are provably false, such as that AAA protocols are inappropriate for c= onstrained environments.

In fact, the charter does not say that. But to av= oid confusion, let's remove AAA protocol from the charter.

=C2=A0

In the charter, we mentioned that we want to reus= e existing authentication and authorization protocols where applicable to b= uild the constrained-environment solution.

= ... which I read as: let's consider the AAA protocols, and evaluate if = they would work in constrained devices.
I don't understand the logic: why do you want to remove AAA from the ch= arter?
Not only would I keep "AAA", but I would propose

OLD:
Existing authentication and authorization protocols will be used where
applicable to build the constrained-environment solution

NEW:
Existing authentication and authorization protocols will be evaluated and r= e-used where
applicable to build the constrained-environment solution

Regards, Benoit

=C2=A0

=C2=A0

(3) Clarify the scope:

OLD:

Note that the initial focus is on CoAP and HTTP w= ith DTLS and TLS.

Other security protocols may be considered as lon= g as the primary focus is maintained.=C2=A0

Other application protocols and protocols at othe= r layers in the stack are out of scope.

=C2=A0

NEW

Note that the initial focus is on CoAP and HTTP w= ith DTLS and TLS.

Other security protocols may be considered as lon= g as the primary focus is maintained.=C2=A0

The group is scoped to work only on the web proto= cols and data carried within them.

END

=C2=A0

(4)=C2=A0=C2=A0=C2=A0=C2=A0 Update milestones for= the use case & requirements document:

OLD:

Jul 2015 Submit =E2=80=9CUse cases and Requirements=E2=80=9D documen= t to IESG for publication as informational RFC.

=C2=A0

NEW

Dec 2014 Optionally, submit "Use cases and R= equirements" document to the IESG for publication as an Informational = RFC.

END

=C2=A0

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

Charter charter-ietf-ace-00-02

Authentication and Authorization for Constrained<= u>

Environment (ACE)

=C2=A0

The IETF has recently developed protocols for use= in constrained

environments, where network nodes are limited in = CPU, memory and power.

REST architecture is widely used for such constra= ined environments.

It has been observed that Internet protocols can = be applied to these

constrained environments, often only requiring mi= nor tweaking and

profiling. In other cases, new protocols have bee= n defined to address

the specific requirements of constrained environm= ents. An example of

such a protocol is the Constrained Application Pr= otocol (CoAP).

=C2=A0

As in other environments, authentication and auth= orization questions

also arise in constrained environments. For examp= le, a door lock has to

authorize the person seeking access using a "= ;digital key". Where is the

authorization policy stored? How does the digital= key communicate with

the lock? Does the lock interact with an authoriz= ation server to obtain

authorization information? How can access be temp= orarily granted to

other persons? How can access be revoked? These t= ypes of questions have

been answered by existing protocols for use cases= outside constrained

environments, however in constrained environments= , additional and

different requirements pose challenges for the us= e of various security

protocols. In particular, the need arises for a d= ynamic and fine grained

access control mechanism, where clients and/or re= source servers are

constrained.

=C2=A0

The IETF has a long history in developing three-p= arty authentication and

authorization protocols for distributed environme= nts. Examples include

Kerberos, the Public Key Infrastructure (PKI), an= d the Web

Authorization Protocol (OAuth). All these protoco= ls enjoy widespread

deployment on the Internet. Although they all aim= to solve a similar

goal, at an abstract level, they offer quite diff= erent functions and

utilize different message exchanges. These differ= ences result from the

main deployment use cases they were designed for = respectively.

=C2=A0

Requirements derived from use cases indicate the = suitability of existing

work as a solution for constrained environments. = These protocols,

however, were not optimized for constrained envir= onments. Additional

requirements that need to be taken into account a= re the lack of a

suitable user-interface and the inability of embe= dded devices to contact

an authorization server in real-time with every r= esource access request

due to intermittent connectivity, etc.<= /u>

=C2=A0

This working group therefore aims to produce a st= andardized solution for

authentication and authorization to enable author= ized access (GET, PUT, POST,

DELETE) to resources identified by a URI and host= ed on a resource

server in constrained environments. As a starting= point, the working

group will assume that access to resources at a r= esource server by a

client device takes place using CoAP and is prote= cted by DTLS. Both

resource server and client may be constrained. Th= is access will be

mediated by an authorization server, which is not= considered to be

constrained.

=C2=A0

Existing authentication and authorization protoco= ls will be used where

applicable to build the constrained-environment s= olution. This requires

relevant specifications to be reviewed for suitab= ility, selecting a

subset of them and restricting the options within= each of the

specifications. Some functionality, however, may = not be available in

existing protocols, in which case the solution ma= y also involve new

protocol work. Leveraging existing work means the= working group benefits

from available security analysis, implementation,= and deployment

experience. Moreover, a standardized solution for= federated

authentication and authorization will help to sti= mulate the deployment

of constrained devices that provide increased sec= urity.

=C2=A0

Once progress in identifying suitable candidate s= olutions has been made,

the working group will verify whether the same me= chanisms are also

applicable beyond the use of CoAP and DTLS, which= are the two main

protocols the group will focus on for access to r= esources. In

particular, the ability to use the developed solu= tion over HTTP and TLS

will be investigated. Note that the initial focus= is on CoAP and HTTP with DTLS and TLS.

Other security protocols may be considered as lon= g as the primary focus is maintained.=C2=A0

The group is scoped to work only on the web proto= cols and data carried within them.

Furthermore, to guarantee smooth transition, the<= u>

integration with existing deployments will be stu= died, particularly

concerning the use of protocol translation proxie= s.

=C2=A0

This work does not make the assumption that the p= arty offering

application layer services is always the same par= ty offering network

access services.

=C2=A0

The working group has the following tasks:=

=C2=A0

1) Produce use cases and requirements

=C2=A0

2) Identify authentication and authorization mech= anisms suitable for

resource access in constrained environments.

=C2=A0

Milestones:

=C2=A0

Jul 2014 Submit "Use cases and Requirements&= quot; as a WG item.

Dec 2014 Submit "Authentication and Authoriz= ation Solution" as a WG item.

Dec 2014 Optionally, submit "Use cases and R= equirements" document

to the IESG for publication as an Informational R= FC.

Jul 2016 Submit "Authentication and Authoriz= ation Solution"

specification to the IESG for publication as a Pr= oposed Standard.

=C2=A0

Proposed Milestones

No milestones for charter found.

=C2=A0

=C2=A0

--

=C2=A0

Best regards,

Kathleen

--

Best regards,

Kathleen

--

Best regards,

Kathleen

--

Be= st regards,
Kathleen

--

Best regards,
Kathleen
--001a11c36da23fa1e804fb03d5f9-- From nobody Wed Jun 4 09:39:00 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E89A1A02F3; Wed, 4 Jun 2014 09:38:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.851 X-Spam-Level: X-Spam-Status: No, score=-9.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651, 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 n-1l8IAK6ynH; Wed, 4 Jun 2014 09:38:48 -0700 (PDT) Received: from bgl-iport-4.cisco.com (bgl-iport-4.cisco.com [72.163.197.28]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DDEE1A0311; Wed, 4 Jun 2014 09:38:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=195208; q=dns/txt; s=iport; t=1401899917; x=1403109517; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=ccICiiYMLZtYgJrtHir5yYuIwj6UA+BPNuRvaUprPQQ=; b=ePum645mAmp4SZrqfNqG1/nJTvsJZ2V2dYRB1WXI1j8FNmkzjvDoMVvY qF4WNdHgBzwZ745eLPW335IZCRgLaQFaEn+qEpR0SsEx1+Dkwm6o2MJ9y vJZ3RXQRyV8vWGIFYNhA5eEoT2ETnDeVfGW7LaiXOYvuflLzvbFQg1N5Z U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq0EAM5Kj1NIo8UY/2dsb2JhbABPCoJCgReDRIVbui0BgSJ0giUBAQEEGgEIRA0EARAJAhEBAgECAQkMCgEBBgMCAgkDAgECAQ8lAwYIBgEMAQUCAQEXiBMDEQ2PbJwgn1wNhggTBIkzgwmBNAYEBwECNgcRBgEGBIJrgUsBA4VWkkOBeoZwhlKFd4M6Oy+BAQkXAgI X-IronPort-AV: E=Sophos; i="4.98,974,1392163200"; d="scan'208,217"; a="11013958" Received: from vla196-nat.cisco.com (HELO bgl-core-4.cisco.com) ([72.163.197.24]) by bgl-iport-4.cisco.com with ESMTP; 04 Jun 2014 16:38:32 +0000 Received: from [10.60.67.91] (ams-bclaise-89110.cisco.com [10.60.67.91]) by bgl-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s54GcRmr003717; Wed, 4 Jun 2014 16:38:28 GMT Message-ID: <538F4B83.1090404@cisco.com> Date: Wed, 04 Jun 2014 18:38:27 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Kathleen Moriarty , =?UTF-8?B?R8O2cg==?= =?UTF-8?B?YW4gU2VsYW5kZXI=?= References: <20140514221215.8150.56543.idtracker@ietfa.amsl.com> <34966E97BE8AD64EAE9D3D6E4DEE36F252B2A345@SZXEMA501-MBS.china.huawei.com> <34966E97BE8AD64EAE9D3D6E4DEE36F252B38978@SZXEMA501-MBS.china.huawei.com> <34966E97BE8AD64EAE9D3D6E4DEE36F258140E59@SZXEMA501-MBX.china.huawei.com> <538DA047.7080902@cisco.com> <34966E97BE8AD64EAE9D3D6E4DEE36F258153F43@SZXEMA501-MBS.china.huawei.com> <34966E97BE8AD64EAE9D3D6E4DEE36F25815405D@SZXEMA501-MBS.china.huawei.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070402070706030303040206" Archived-At: http://mailarchive.ietf.org/arch/msg/ace/YECwMQf0EAH2Ewf4TU3wClw2Mo8 Cc: "aaa-doctors@ietf.org" , "adrian@olddog.co.uk" , The IESG , Likepeng , "ace@ietf.org" Subject: Re: [Ace] Revised charter proposal: charter-ietf-ace-00-02 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments $ace$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 16:38:55 -0000 This is a multi-part message in MIME format. --------------070402070706030303040206 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi Kathleen, Fine with me Regards, B. > Benoit had one other change mentioned in a previous email that was > left out. He agrees that it is editorial. I'm fine with adding it if > that is okay, but would prefer to leave "used" in instead of "re-used" > as it isn't needed (IMO). > > Is the last option agreeable and would it clear your concerns, Benoit? > > OLD: > Existing authentication and authorization protocols will be used where > applicable to build the constrained-environment solution > > NEW: > Existing authentication and authorization protocols will be > evaluated and re-used where > applicable to build the constrained-environment solution > > NEWER: > Existing authentication and authorization protocols will be > evaluated and used where > applicable to build the constrained-environment solution > > > > On Wed, Jun 4, 2014 at 10:05 AM, Kathleen Moriarty > > wrote: > > Thank you, Göran. > > It must have been a cut-n-paste error. The first sentence for the > 'replace' did not match the original or the new either. If the > next version isn't quite right, pasting in a new full version may > be better. I'll look back through Benoit's comment now as well. > > > On Wed, Jun 4, 2014 at 3:06 AM, Göran Selander > > > wrote: > > Hi Kathleen, > > In change #3 of the summary Kepeng made below I find the > sentence: >>Other security protocols may be considered as long > as the primary focus is maintained. >> This sentence seems to > be missing from charter-ietf-ace-00-04. > > Regards, > Göran > > > From: Kathleen Moriarty > > Date: Tuesday 3 June 2014 22:27 > To: Likepeng > > Cc: Benoit Claise >, "adrian@olddog.co.uk > " >, "ace@ietf.org > " >, > The IESG >, > "aaa-doctors@ietf.org " > > > Subject: Re: [Ace] Revised charter proposal: > charter-ietf-ace-00-02 > > The charter text has been updated, > https://datatracker.ietf.org/doc/charter-ietf-ace/ > > Thank you all for your input and assistance. If this is > good, we'll move it forward for IETF review. > > > > On Tue, Jun 3, 2014 at 10:39 AM, Kathleen Moriarty > > wrote: > > I believe there is agreement on the proposed changes. > I'll make the updates later in the day (it's about > 11:30 my time, maybe at 4) in case anyone wants to > chime in. If we are all in agreement, I'll have it > sent for IETF review at that point. > > Thank you! > > > On Tue, Jun 3, 2014 at 10:26 AM, Likepeng > > wrote: > > Hi Kathleen and all, > > This is what I have now: > > Change #1: (Proposed by Kepeng, confirmed by Benoit) > > OLD > > The IETF has recently developed protocols for use in constrained > > environments, where network nodes are limited in CPU, memory and power. > > > > NEW > > The IETF has recently developed protocols for use in constrained > > environments, where network nodes are limited in CPU, memory and power. > > REST architecture is widely used for such constrained environments. > > END > > > > Change #2: (Proposal from Rene, supported by Stefanie) > > OLD: > > Requirements derived from use cases indicate the suitability of existing > > work as a solution for constrained environments > > > > NEW: > > Requirements derived from use cases may indicate that existing work is > > useful as basis for as a solution for constrained environments > > > > Change #3: (Proposal from Jari, supported by Barry, Robert and Behcet) > > OLD: > > Note that the initial focus is on CoAP and HTTP with DTLS and TLS. > > Other security protocols may be considered as long as the primary focus is maintained. > > Other application protocols and protocols at other layers in the stack are out of scope. > > > > NEW > > Note that the initial focus is on CoAP and HTTP with DTLS and TLS. > > Other security protocols may be considered as long as the primary focus is maintained. > > The group is scoped to work only on the web protocols and data carried within them. > > END > > > > Change 4: (Proposal from Jari, revised by Rene, supported by Stefanie) > > OLD: > > Jul 2014 Submit "Use cases and Requirements" as a WG item. > > Jul 2015 Submit “Use cases and Requirements” document to IESG for publication as informational RFC. > > > > NEW > > Dec 2014 Submit "Use cases and Requirements" as a WG item. > > Apr 2015 Optionally, submit "Use cases and Requirements" document to the IESG for > > publication as an Informational RFC. > > END > > I think we covered all of the IESG review comments. > > If there is any open issue, please let us know. > > Thanks, > > Kind Regards > > Kepeng > > -------------------------------------------------------------------------------------------------------------------------------------------------------- > > Charter charter-ietf-ace-00-02 > > Authentication and Authorization for Constrained > > Environment (ACE) > > The IETF has recently developed protocols for use > in constrained > > environments, where network nodes are limited in > CPU, memory and power. > > REST architecture is widely used for such > constrained environments. > > It has been observed that Internet protocols can > be applied to these > > constrained environments, often only requiring > minor tweaking and > > profiling. In other cases, new protocols have been > defined to address > > the specific requirements of constrained > environments. An example of > > such a protocol is the Constrained Application > Protocol (CoAP). > > As in other environments, authentication and > authorization questions > > also arise in constrained environments. For > example, a door lock has to > > authorize the person seeking access using a > "digital key". Where is the > > authorization policy stored? How does the digital > key communicate with > > the lock? Does the lock interact with an > authorization server to obtain > > authorization information? How can access be > temporarily granted to > > other persons? How can access be revoked? These > types of questions have > > been answered by existing protocols for use cases > outside constrained > > environments, however in constrained environments, > additional and > > different requirements pose challenges for the use > of various security > > protocols. In particular, the need arises for a > dynamic and fine grained > > access control mechanism, where clients and/or > resource servers are > > constrained. > > The IETF has a long history in developing > three-party authentication and > > authorization protocols for distributed > environments. Examples include > > Kerberos, the Public Key Infrastructure (PKI), the > Authentication, > > Authorization and Accounting (AAA) > infrastructure,and the Web > > Authorization Protocol (OAuth). All these > protocols enjoy widespread > > deployment on the Internet. Although they all aim > to solve a similar > > goal, at an abstract level, they offer quite > different functions and > > utilize different message exchanges. These > differences result from the > > main deployment use cases they were designed for > respectively. > > Requirements derived from use cases may indicate > that existing work is > > useful as basis for as a solution for constrained > environments. > > These protocols, > > however, were not optimized for constrained > environments. Additional > > requirements that need to be taken into account > are the lack of a > > suitable user-interface and the inability of > embedded devices to contact > > an authorization server in real-time with every > resource access request > > due to intermittent connectivity, etc. > > This working group therefore aims to produce a > standardized solution for > > authentication and authorization to enable > authorized access (GET, PUT, POST, > > DELETE) to resources identified by a URI and > hosted on a resource > > server in constrained environments. As a starting > point, the working > > group will assume that access to resources at a > resource server by a > > client device takes place using CoAP and is > protected by DTLS. Both > > resource server and client may be constrained. > This access will be > > mediated by an authorization server, which is not > considered to be > > constrained. > > Existing authentication and authorization > protocols will be evaluated > > and re-used where applicable to build the > constrained-environment solution. > > This requires > > relevant specifications to be reviewed for > suitability, selecting a > > subset of them and restricting the options within > each of the > > specifications. Some functionality, however, may > not be available in > > existing protocols, in which case the solution may > also involve new > > protocol work. Leveraging existing work means the > working group benefits > > from available security analysis, implementation, > and deployment > > experience. Moreover, a standardized solution for > federated > > authentication and authorization will help to > stimulate the deployment > > of constrained devices that provide increased > security. > > Once progress in identifying suitable candidate > solutions has been made, > > the working group will verify whether the same > mechanisms are also > > applicable beyond the use of CoAP and DTLS, which > are the two main > > protocols the group will focus on for access to > resources. In > > particular, the ability to use the developed > solution over HTTP and TLS > > will be investigated. Note that the initial focus > is on CoAP and HTTP with DTLS and TLS. > > Other security protocols may be considered as long > as the primary focus is maintained. > > The group is scoped to work only on the web > protocols and data carried within them. > > Furthermore, to guarantee smooth transition, the > > integration with existing deployments will be > studied, particularly > > concerning the use of protocol translation proxies. > > This work does not make the assumption that the > party offering > > application layer services is always the same > party offering network > > access services. > > The working group has the following tasks: > > 1) Produce use cases and requirements > > 2) Identify authentication and authorization > mechanisms suitable for > > resource access in constrained environments. > > Milestones: > > Dec 2014 Submit "Use cases and Requirements" as a > WG item. > > Dec 2014 Submit "Authentication and Authorization > Solution" as a WG item. > > Apr 2015 Optionally, submit "Use cases and > Requirements" document > > to the IESG for publication as an Informational RFC. > > Jul 2016 Submit "Authentication and Authorization > Solution" > > specification to the IESG for publication as a > Proposed Standard. > > Proposed Milestones > > No milestones for charter found. > > *发件人:*Kathleen Moriarty > [mailto:kathleen.moriarty.ietf@gmail.com > ] > *发送时间:*2014年6月3日14:30 > *收件人:*Likepeng > *抄送:*Benoit Claise; adrian@olddog.co.uk > ; aaa-doctors@ietf.org > ; The IESG; > ace@ietf.org > > *主题:*Re: Revised charter proposal: > charter-ietf-ace-00-02 > > Hi Kepeng, > > If we are at a point where I can update the > charter, seems that way, please send the latest > version that has been agreed upon and I'll take > care of the update. > > Thanks. > > On Tue, Jun 3, 2014 at 6:31 AM, Likepeng > > > wrote: > > Hi Benoit, > > >Not only would I keep "AAA", > > OK. > > >but I would propose > > >OLD: > > >Existing authentication and authorization protocols will > be used where > > applicable to build the constrained-environment > solution. > > >NEW: > > Existing authentication and authorization > protocols will be evaluated and re-used where > > applicable to build the constrained-environment > solution. > > OK, fine with me. > > Thanks for the feedback. > > Kind Regards > > Kepeng > > *发件人:*Benoit Claise [mailto:bclaise@cisco.com > ] > *发送时间:*2014年6月3日12:16 > > *收件人:*Likepeng; Kathleen Moriarty; > adrian@olddog.co.uk > > *抄送:*aaa-doctors@ietf.org > ; The IESG; > ace@ietf.org > > *主题:*Re: Revised charter proposal: > charter-ietf-ace-00-02 > > Hi, > > Hello all, > > > > Based on recent discussions, I made a revised charter proposal, as included in this email, not on the webpage yet. > > > > Please take a look and let us know if you have any further comments. > > > > @Adrian and @Benoit, please check if the proposed texts can resolve your comments. > > > > Thanks, > > Kind Regards > > Kepeng > > > > ------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Compared with charter-ietf-ace-00-01 on the webpage, the changes are: > > > > (1) Add one clarification sentence about REST architecture: > > OLD > > The IETF has recently developed protocols for use in constrained > > environments, where network nodes are limited in CPU, memory and power. > > REST architecture is widely used for such constrained environments. > > > > NEW > > The IETF has recently developed protocols for use in constrained > > environments, where network nodes are limited in CPU, memory and power. > > REST architecture is widely used for such constrained environments. > > END > > Considering that OLD is > > OLD > > The IETF has recently developed protocols for use in constrained > > environments, where network nodes are limited in CPU, memory and power. > > ... fine with me > > > > > > (2) Remove“AAA protocol” from the charter: > > OLD > > The IETF has a long history in developing three-party authentication and > > authorization protocols for distributed environments. Examples include > > Kerberos, the Public Key Infrastructure (PKI), the Authentication, > > Authorization and Accounting (AAA) infrastructure, and the Web > > Authorization Protocol (OAuth). > > > > NEW > > The IETF has a long history in developing three-party authentication and > > authorization protocols for distributed environments. Examples include > > Kerberos, the Public Key Infrastructure (PKI), and the Web Authorization Protocol (OAuth). > > END > > We have AAA-doctors telling: maybe RADIUS is > applicable? > Personally, I don't know and it doesn't matter at > this point. > We received feedback such as: > > Let's be clear here: It was never said (in the > charter or anywhere else in the group to my > knowledge) that RADIUS (or indeed any other AAA > protocol) would not run on constrained devices > (RFC 7228). The charter simply said the protocols > were not optimised for constrained devices. That > does not preclude considering any protocol for > suitability for constrained devices either a) as > is, b) in a restricted way or c) in an adapted way. > > So, at this stage, I don't think any protocols > should be excluded from consideration and should > certainly not be eliminated on a hunch that they > might be "too big". Let's do the assessment > properly at the appropriate time. As a reminder - > the focus now is to complete the charter. > > Or > > >>The Charter makes a number of assertions that are provably false, such as that AAA protocols are inappropriate for constrained environments. > > In fact, the charter does not say that. But to avoid confusion, let's remove AAA protocol from the charter. > > > > In the charter, we mentioned that we want to reuse existing authentication and authorization protocols where applicable to build the constrained-environment solution. > > ... which I read as: let's consider the AAA > protocols, and evaluate if they would work in > constrained devices. > I don't understand the logic: why do you want to > remove AAA from the charter? > Not only would I keep "AAA", but I would propose > > OLD: > Existing authentication and authorization > protocols will be used where > applicable to build the constrained-environment > solution > > NEW: > Existing authentication and authorization > protocols will be evaluated and re-used where > applicable to build the constrained-environment > solution > > Regards, Benoit > > > > > > (3) Clarify the scope: > > OLD: > > Note that the initial focus is on CoAP and HTTP with DTLS and TLS. > > Other security protocols may be considered as long as the primary focus is maintained. > > Other application protocols and protocols at other layers in the stack are out of scope. > > > > NEW > > Note that the initial focus is on CoAP and HTTP with DTLS and TLS. > > Other security protocols may be considered as long as the primary focus is maintained. > > The group is scoped to work only on the web protocols and data carried within them. > > END > > > > (4) Update milestones for the use case & requirements document: > > OLD: > > Jul 2015 Submit“Use cases and Requirements” document to IESG for publication as informational RFC. > > > > NEW > > Dec 2014 Optionally, submit "Use cases and Requirements" document to the IESG for publication as an Informational RFC. > > END > > > > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Charter charter-ietf-ace-00-02 > > Authentication and Authorization for Constrained > > Environment (ACE) > > > > The IETF has recently developed protocols for use in constrained > > environments, where network nodes are limited in CPU, memory and power. > > REST architecture is widely used for such constrained environments. > > It has been observed that Internet protocols can be applied to these > > constrained environments, often only requiring minor tweaking and > > profiling. In other cases, new protocols have been defined to address > > the specific requirements of constrained environments. An example of > > such a protocol is the Constrained Application Protocol (CoAP). > > > > As in other environments, authentication and authorization questions > > also arise in constrained environments. For example, a door lock has to > > authorize the person seeking access using a "digital key". Where is the > > authorization policy stored? How does the digital key communicate with > > the lock? Does the lock interact with an authorization server to obtain > > authorization information? How can access be temporarily granted to > > other persons? How can access be revoked? These types of questions have > > been answered by existing protocols for use cases outside constrained > > environments, however in constrained environments, additional and > > different requirements pose challenges for the use of various security > > protocols. In particular, the need arises for a dynamic and fine grained > > access control mechanism, where clients and/or resource servers are > > constrained. > > > > The IETF has a long history in developing three-party authentication and > > authorization protocols for distributed environments. Examples include > > Kerberos, the Public Key Infrastructure (PKI), and the Web > > Authorization Protocol (OAuth). All these protocols enjoy widespread > > deployment on the Internet. Although they all aim to solve a similar > > goal, at an abstract level, they offer quite different functions and > > utilize different message exchanges. These differences result from the > > main deployment use cases they were designed for respectively. > > > > Requirements derived from use cases indicate the suitability of existing > > work as a solution for constrained environments. These protocols, > > however, were not optimized for constrained environments. Additional > > requirements that need to be taken into account are the lack of a > > suitable user-interface and the inability of embedded devices to contact > > an authorization server in real-time with every resource access request > > due to intermittent connectivity, etc. > > > > This working group therefore aims to produce a standardized solution for > > authentication and authorization to enable authorized access (GET, PUT, POST, > > DELETE) to resources identified by a URI and hosted on a resource > > server in constrained environments. As a starting point, the working > > group will assume that access to resources at a resource server by a > > client device takes place using CoAP and is protected by DTLS. Both > > resource server and client may be constrained. This access will be > > mediated by an authorization server, which is not considered to be > > constrained. > > > > Existing authentication and authorization protocols will be used where > > applicable to build the constrained-environment solution. This requires > > relevant specifications to be reviewed for suitability, selecting a > > subset of them and restricting the options within each of the > > specifications. Some functionality, however, may not be available in > > existing protocols, in which case the solution may also involve new > > protocol work. Leveraging existing work means the working group benefits > > from available security analysis, implementation, and deployment > > experience. Moreover, a standardized solution for federated > > authentication and authorization will help to stimulate the deployment > > of constrained devices that provide increased security. > > > > Once progress in identifying suitable candidate solutions has been made, > > the working group will verify whether the same mechanisms are also > > applicable beyond the use of CoAP and DTLS, which are the two main > > protocols the group will focus on for access to resources. In > > particular, the ability to use the developed solution over HTTP and TLS > > will be investigated. Note that the initial focus is on CoAP and HTTP with DTLS and TLS. > > Other security protocols may be considered as long as the primary focus is maintained. > > The group is scoped to work only on the web protocols and data carried within them. > > Furthermore, to guarantee smooth transition, the > > integration with existing deployments will be studied, particularly > > concerning the use of protocol translation proxies. > > > > This work does not make the assumption that the party offering > > application layer services is always the same party offering network > > access services. > > > > The working group has the following tasks: > > > > 1) Produce use cases and requirements > > > > 2) Identify authentication and authorization mechanisms suitable for > > resource access in constrained environments. > > > > Milestones: > > > > Jul 2014 Submit "Use cases and Requirements" as a WG item. > > Dec 2014 Submit "Authentication and Authorization Solution" as a WG item. > > Dec 2014 Optionally, submit "Use cases and Requirements" document > > to the IESG for publication as an Informational RFC. > > Jul 2016 Submit "Authentication and Authorization Solution" > > specification to the IESG for publication as a Proposed Standard. > > > > Proposed Milestones > > No milestones for charter found. > > > > -- > > Best regards, > > Kathleen > > > > > -- > > Best regards, > Kathleen > > > > > -- > > Best regards, > Kathleen > > > > > -- > > Best regards, > Kathleen > > > > > -- > > Best regards, > Kathleen --------------070402070706030303040206 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Hi Kathleen,

Fine with me

Regards, B.

Benoit had one other change mentioned in a previous email that was left out. He agrees that it is editorial. I'm fine with adding it if that is okay, but would prefer to leave "used" in instead of "re-used" as it isn't needed (IMO).

Is the last option agreeable and would it clear your concerns, Benoit?

OLD:
Existing authentication and authorization protocols will be used where
applicable to build the constrained-environment solution

NEW:
Existing authentication and authorization protocols will be evaluated and re-used where
applicable to build the constrained-environment solution

NEWER:
Existing authentication and authorization protocols will be evaluated and used where
applicable to build the constrained-environment solution

On Wed, Jun 4, 2014 at 10:05 AM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:

Thank you, Göran.

It must have been a cut-n-paste error. The first sentence for the 'replace' did not match the original or the new either. If the next version isn't quite right, pasting in a new full version may be better. I'll look back through Benoit's comment now as well.

On Wed, Jun 4, 2014 at 3:06 AM, Göran Selander <goran.selander@ericsson.com> wrote:

Hi Kathleen,

In change #3 of the summary Kepeng made below I find the sentence: >>Other security protocols may be considered as long as the primary focus is maintained. >> This sentence seems to be missing from charter-ietf-ace-00-04.

Regards,

Göran

From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Date: Tuesday 3 June 2014 22:27
To: Likepeng <likepeng@huawei.com>
Cc: Benoit Claise <bclaise@cisco.com>, "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "ace@ietf.org" <ace@ietf.org>, The IESG <iesg@ietf.org>, "aaa-doctors@ietf.org" <aaa-doctors@ietf.org>
Subject: Re: [Ace] Revised charter proposal: charter-ietf-ace-00-02

The charter text has been updated, https://datatracker.ietf.org/doc/charter-ietf-ace/

Thank you all for your input and assistance. If this is good, we'll move it forward for IETF review.

On Tue, Jun 3, 2014 at 10:39 AM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:

I believe there is agreement on the proposed changes. I'll make the updates later in the day (it's about 11:30 my time, maybe at 4) in case anyone wants to chime in. If we are all in agreement, I'll have it sent for IETF review at that point.

Thank you!

On Tue, Jun 3, 2014 at 10:26 AM, Likepeng <likepeng@huawei.com> wrote:

Hi Kathleen and all,

This is what I have now:

Change #1: (Proposed by Kepeng, confirmed by Benoit)

OLD

The IETF has recently developed protocols for use in constrained

environments, where network nodes are limited in CPU, memory and power.

NEW

The IETF has recently developed protocols for use in constrained

environments, where network nodes are limited in CPU, memory and power.

REST architecture is widely used for such constrained environments.

END

Change #2: (Proposal from Rene, supported by Stefanie)

OLD:

Requirements derived from use cases indicate the suitability of existing

work as a solution for constrained environments

NEW:

Requirements derived from use cases may indicate that existing work is

useful as basis for as a solution for constrained environments

Change #3: (Proposal from Jari, supported by Barry, Robert and Behcet)

OLD:

Note that the initial focus is on CoAP and HTTP with DTLS and TLS.

Other security protocols may be considered as long as the primary focus is maintained.

Other application protocols and protocols at other layers in the stack are out of scope.

NEW

Note that the initial focus is on CoAP and HTTP with DTLS and TLS.

Other security protocols may be considered as long as the primary focus is maintained.

The group is scoped to work only on the web protocols and data carried within them.

END

Change 4: (Proposal from Jari, revised by Rene, supported by Stefanie)

OLD:

Jul 2014 Submit "Use cases and Requirements" as a WG item.

Jul 2015 Submit “Use cases and Requirements” document to IESG for publication as informational RFC.

NEW

Dec 2014 Submit "Use cases and Requirements" as a WG item.

Apr 2015 Optionally, submit "Use cases and Requirements" document to the IESG for

publication as an Informational RFC.

END

I think we covered all of the IESG review comments.

If there is any open issue, please let us know.

Thanks,

Kind Regards

Kepeng

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

Charter charter-ietf-ace-00-02

Authentication and Authorization for Constrained

Environment (ACE)

The IETF has recently developed protocols for use in constrained

environments, where network nodes are limited in CPU, memory and power.

REST architecture is widely used for such constrained environments.

It has been observed that Internet protocols can be applied to these

constrained environments, often only requiring minor tweaking and

profiling. In other cases, new protocols have been defined to address

the specific requirements of constrained environments. An example of

such a protocol is the Constrained Application Protocol (CoAP).

As in other environments, authentication and authorization questions

also arise in constrained environments. For example, a door lock has to

authorize the person seeking access using a "digital key". Where is the

authorization policy stored? How does the digital key communicate with

the lock? Does the lock interact with an authorization server to obtain

authorization information? How can access be temporarily granted to

other persons? How can access be revoked? These types of questions have

been answered by existing protocols for use cases outside constrained

environments, however in constrained environments, additional and

different requirements pose challenges for the use of various security

protocols. In particular, the need arises for a dynamic and fine grained

access control mechanism, where clients and/or resource servers are

constrained.

The IETF has a long history in developing three-party authentication and

authorization protocols for distributed environments. Examples include

Kerberos, the Public Key Infrastructure (PKI), the Authentication,

Authorization and Accounting (AAA) infrastructure,and the Web

Authorization Protocol (OAuth). All these protocols enjoy widespread

deployment on the Internet. Although they all aim to solve a similar

goal, at an abstract level, they offer quite different functions and

utilize different message exchanges. These differences result from the

main deployment use cases they were designed for respectively.

Requirements derived from use cases may indicate that existing work is

useful as basis for as a solution for constrained environments.

These protocols,

however, were not optimized for constrained environments. Additional

requirements that need to be taken into account are the lack of a

suitable user-interface and the inability of embedded devices to contact

an authorization server in real-time with every resource access request

due to intermittent connectivity, etc.

This working group therefore aims to produce a standardized solution for

authentication and authorization to enable authorized access (GET, PUT, POST,

DELETE) to resources identified by a URI and hosted on a resource

server in constrained environments. As a starting point, the working

group will assume that access to resources at a resource server by a

client device takes place using CoAP and is protected by DTLS. Both

resource server and client may be constrained. This access will be

mediated by an authorization server, which is not considered to be

constrained.

Existing authentication and authorization protocols will be evaluated

and re-used where applicable to build the constrained-environment solution.

This requires

relevant specifications to be reviewed for suitability, selecting a

subset of them and restricting the options within each of the

specifications. Some functionality, however, may not be available in

existing protocols, in which case the solution may also involve new

protocol work. Leveraging existing work means the working group benefits

from available security analysis, implementation, and deployment

experience. Moreover, a standardized solution for federated

authentication and authorization will help to stimulate the deployment

of constrained devices that provide increased security.

Once progress in identifying suitable candidate solutions has been made,

the working group will verify whether the same mechanisms are also

applicable beyond the use of CoAP and DTLS, which are the two main

protocols the group will focus on for access to resources. In

particular, the ability to use the developed solution over HTTP and TLS

will be investigated. Note that the initial focus is on CoAP and HTTP with DTLS and TLS.

Other security protocols may be considered as long as the primary focus is maintained.

The group is scoped to work only on the web protocols and data carried within them.

Furthermore, to guarantee smooth transition, the

integration with existing deployments will be studied, particularly

concerning the use of protocol translation proxies.

This work does not make the assumption that the party offering

application layer services is always the same party offering network

access services.

The working group has the following tasks:

1) Produce use cases and requirements

2) Identify authentication and authorization mechanisms suitable for

resource access in constrained environments.

Milestones:

Dec 2014 Submit "Use cases and Requirements" as a WG item.

Dec 2014 Submit "Authentication and Authorization Solution" as a WG item.

Apr 2015 Optionally, submit "Use cases and Requirements" document

to the IESG for publication as an Informational RFC.

Jul 2016 Submit "Authentication and Authorization Solution"

specification to the IESG for publication as a Proposed Standard.

Proposed Milestones

No milestones for charter found.

发件人: Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com]
发送时间: 2014年6月3日 14:30
收件人: Likepeng
抄送: Benoit Claise; adrian@olddog.co.uk; aaa-doctors@ietf.org; The IESG; ace@ietf.org

主题: Re: Revised charter proposal: charter-ietf-ace-00-02

Hi Kepeng,

If we are at a point where I can update the charter, seems that way, please send the latest version that has been agreed upon and I'll take care of the update.

Thanks.

On Tue, Jun 3, 2014 at 6:31 AM, Likepeng <likepeng@huawei.com> wrote:

Hi Benoit,

>Not only would I keep "AAA",

OK.

>but I would propose

>OLD:

>Existing authentication and authorization protocols will be used where

applicable to build the constrained-environment solution.

>NEW:

Existing authentication and authorization protocols will be evaluated and re-used where

applicable to build the constrained-environment solution.

OK, fine with me.

Thanks for the feedback.

Kind Regards

Kepeng

发件人: Benoit Claise [mailto:bclaise@cisco.com]
发送时间: 2014年6月3日 12:16

收件人: Likepeng; Kathleen Moriarty; adrian@olddog.co.uk

抄送: aaa-doctors@ietf.org; The IESG; ace@ietf.org

主题: Re: Revised charter proposal: charter-ietf-ace-00-02

Hi,

Hello all,

Based on recent discussions, I made a revised charter proposal, as included in this email, not on the webpage yet.

Please take a look and let us know if you have any further comments.

@Adrian and @Benoit, please check if the proposed texts can resolve your comments.

Thanks,

Kind Regards

Kepeng

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

Compared with charter-ietf-ace-00-01 on the webpage, the changes are:

(1)      Add one clarification sentence about REST architecture:

OLD

The IETF has recently developed protocols for use in constrained

environments, where network nodes are limited in CPU, memory and power.

REST architecture is widely used for such constrained environments.

NEW

The IETF has recently developed protocols for use in constrained

environments, where network nodes are limited in CPU, memory and power.

REST architecture is widely used for such constrained environments.

END

Considering that OLD is

OLD

The IETF has recently developed protocols for use in constrained

environments, where network nodes are limited in CPU, memory and power.

... fine with me

(2)     Remove “AAA protocol” from the charter:

OLD

The IETF has a long history in developing three-party authentication and

authorization protocols for distributed environments. Examples include

Kerberos, the Public Key Infrastructure (PKI), the Authentication,

Authorization and Accounting (AAA) infrastructure, and the Web

Authorization Protocol (OAuth).

NEW

The IETF has a long history in developing three-party authentication and

authorization protocols for distributed environments. Examples include

Kerberos, the Public Key Infrastructure (PKI), and the Web Authorization Protocol (OAuth).

END

We have AAA-doctors telling: maybe RADIUS is applicable?
Personally, I don't know and it doesn't matter at this point.
We received feedback such as:

Let's be clear here: It was never said (in the charter or anywhere else in the group to my knowledge) that RADIUS (or indeed any other AAA protocol) would not run on constrained devices (RFC 7228). The charter simply said the protocols were not optimised for constrained devices. That does not preclude considering any protocol for suitability for constrained devices either a) as is, b) in a restricted way or c) in an adapted way.

So, at this stage, I don't think any protocols should be excluded from consideration and should certainly not be eliminated on a hunch that they might be "too big". Let's do the assessment properly at the appropriate time. As a reminder - the focus now is to complete the charter.

Or

>>The Charter makes a number of assertions that are provably false, such as that AAA protocols are inappropriate for constrained environments.

In fact, the charter does not say that. But to avoid confusion, let's remove AAA protocol from the charter.

In the charter, we mentioned that we want to reuse existing authentication and authorization protocols where applicable to build the constrained-environment solution.

... which I read as: let's consider the AAA protocols, and evaluate if they would work in constrained devices.
I don't understand the logic: why do you want to remove AAA from the charter?
Not only would I keep "AAA", but I would propose

OLD:
Existing authentication and authorization protocols will be used where
applicable to build the constrained-environment solution

NEW:
Existing authentication and authorization protocols will be evaluated and re-used where
applicable to build the constrained-environment solution

Regards, Benoit

(3) Clarify the scope:

OLD:

Note that the initial focus is on CoAP and HTTP with DTLS and TLS.

Other security protocols may be considered as long as the primary focus is maintained.

Other application protocols and protocols at other layers in the stack are out of scope.

NEW

Note that the initial focus is on CoAP and HTTP with DTLS and TLS.

Other security protocols may be considered as long as the primary focus is maintained.

The group is scoped to work only on the web protocols and data carried within them.

END

(4)     Update milestones for the use case & requirements document:

OLD:

Jul 2015 Submit “Use cases and Requirements” document to IESG for publication as informational RFC.

NEW

Dec 2014 Optionally, submit "Use cases and Requirements" document to the IESG for publication as an Informational RFC.

END

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

Charter charter-ietf-ace-00-02

Authentication and Authorization for Constrained

Environment (ACE)

The IETF has recently developed protocols for use in constrained

environments, where network nodes are limited in CPU, memory and power.

REST architecture is widely used for such constrained environments.

It has been observed that Internet protocols can be applied to these

constrained environments, often only requiring minor tweaking and

profiling. In other cases, new protocols have been defined to address

the specific requirements of constrained environments. An example of

such a protocol is the Constrained Application Protocol (CoAP).

As in other environments, authentication and authorization questions

also arise in constrained environments. For example, a door lock has to

authorize the person seeking access using a "digital key". Where is the

authorization policy stored? How does the digital key communicate with

the lock? Does the lock interact with an authorization server to obtain

authorization information? How can access be temporarily granted to

other persons? How can access be revoked? These types of questions have

been answered by existing protocols for use cases outside constrained

environments, however in constrained environments, additional and

different requirements pose challenges for the use of various security

protocols. In particular, the need arises for a dynamic and fine grained

access control mechanism, where clients and/or resource servers are

constrained.

The IETF has a long history in developing three-party authentication and

authorization protocols for distributed environments. Examples include

Kerberos, the Public Key Infrastructure (PKI), and the Web

Authorization Protocol (OAuth). All these protocols enjoy widespread

deployment on the Internet. Although they all aim to solve a similar

goal, at an abstract level, they offer quite different functions and

utilize different message exchanges. These differences result from the

main deployment use cases they were designed for respectively.

Requirements derived from use cases indicate the suitability of existing

work as a solution for constrained environments. These protocols,

however, were not optimized for constrained environments. Additional

requirements that need to be taken into account are the lack of a

suitable user-interface and the inability of embedded devices to contact

an authorization server in real-time with every resource access request

due to intermittent connectivity, etc.

This working group therefore aims to produce a standardized solution for

authentication and authorization to enable authorized access (GET, PUT, POST,

DELETE) to resources identified by a URI and hosted on a resource

server in constrained environments. As a starting point, the working

group will assume that access to resources at a resource server by a

client device takes place using CoAP and is protected by DTLS. Both

resource server and client may be constrained. This access will be

mediated by an authorization server, which is not considered to be

constrained.

Existing authentication and authorization protocols will be used where

applicable to build the constrained-environment solution. This requires

relevant specifications to be reviewed for suitability, selecting a

subset of them and restricting the options within each of the

specifications. Some functionality, however, may not be available in

existing protocols, in which case the solution may also involve new

protocol work. Leveraging existing work means the working group benefits

from available security analysis, implementation, and deployment

experience. Moreover, a standardized solution for federated

authentication and authorization will help to stimulate the deployment

of constrained devices that provide increased security.

Once progress in identifying suitable candidate solutions has been made,

the working group will verify whether the same mechanisms are also

applicable beyond the use of CoAP and DTLS, which are the two main

protocols the group will focus on for access to resources. In

particular, the ability to use the developed solution over HTTP and TLS

will be investigated. Note that the initial focus is on CoAP and HTTP with DTLS and TLS.

Other security protocols may be considered as long as the primary focus is maintained.

The group is scoped to work only on the web protocols and data carried within them.

Furthermore, to guarantee smooth transition, the

integration with existing deployments will be studied, particularly

concerning the use of protocol translation proxies.

This work does not make the assumption that the party offering

application layer services is always the same party offering network

access services.

The working group has the following tasks:

1) Produce use cases and requirements

2) Identify authentication and authorization mechanisms suitable for

resource access in constrained environments.

Milestones:

Jul 2014 Submit "Use cases and Requirements" as a WG item.

Dec 2014 Submit "Authentication and Authorization Solution" as a WG item.

Dec 2014 Optionally, submit "Use cases and Requirements" document

to the IESG for publication as an Informational RFC.

Jul 2016 Submit "Authentication and Authorization Solution"

specification to the IESG for publication as a Proposed Standard.

Proposed Milestones

No milestones for charter found.

--

Best regards,

Kathleen

--

Best regards,

Kathleen

--

Best regards,

Kathleen

--

Best regards,

Kathleen

--

Best regards,

Kathleen

--------------070402070706030303040206-- From nobody Wed Jun 4 10:05:08 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04A041A034D; Wed, 4 Jun 2014 10:05:07 -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 aV0rHhGFYl41; Wed, 4 Jun 2014 10:05:01 -0700 (PDT) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A526C1A02D9; Wed, 4 Jun 2014 10:04:52 -0700 (PDT) Received: by mail-lb0-f174.google.com with SMTP id n15so4560618lbi.33 for ; Wed, 04 Jun 2014 10:04:45 -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=KXzSaHva53uxQ5X4O8RyOLWuvij3N2odqnQ/svOnd84=; b=bDeSIj+h5AM/yw/9ASBR6o9yyzoCsNAgDhfvkMhQsxLP+DghXdwOjouz8Pdwk+prui DlLbCZ5QdObUa1d0ZlL8zzYAkfx7weEcgq7nbABLyt9VIzXnVuSmu7bDp4XFPWzMWfwk 8Q8JG1zhL4xUQZRsV0vCV45l+E2izu7FN6h8URdrESIm3FaF/9yJttxk5kQwSxSqiBDm uysBZbljGMFwprvNNbwejjbdh7+Ux4cmAbivkgjRhxv9QNSW2lH/XviNaDb3gZPiYE6A bpycUvYfq0X8FiS4CEfCct8zC4f0Rkfuee6PbOEYvg+dMU4WR9e2dQzz2eUkMiFND6iS Xyng== MIME-Version: 1.0 X-Received: by 10.152.10.168 with SMTP id j8mr42209101lab.37.1401901484925; Wed, 04 Jun 2014 10:04:44 -0700 (PDT) Received: by 10.112.33.36 with HTTP; Wed, 4 Jun 2014 10:04:44 -0700 (PDT) In-Reply-To: <538F4B83.1090404@cisco.com> References: <20140514221215.8150.56543.idtracker@ietfa.amsl.com> <34966E97BE8AD64EAE9D3D6E4DEE36F252B2A345@SZXEMA501-MBS.china.huawei.com> <34966E97BE8AD64EAE9D3D6E4DEE36F252B38978@SZXEMA501-MBS.china.huawei.com> <34966E97BE8AD64EAE9D3D6E4DEE36F258140E59@SZXEMA501-MBX.china.huawei.com> <538DA047.7080902@cisco.com> <34966E97BE8AD64EAE9D3D6E4DEE36F258153F43@SZXEMA501-MBS.china.huawei.com> <34966E97BE8AD64EAE9D3D6E4DEE36F25815405D@SZXEMA501-MBS.china.huawei.com> <538F4B83.1090404@cisco.com> Date: Wed, 4 Jun 2014 13:04:44 -0400 Message-ID: From: Kathleen Moriarty To: Benoit Claise Content-Type: multipart/alternative; boundary=001a1133146404e96304fb05a01a Archived-At: http://mailarchive.ietf.org/arch/msg/ace/vjPYK3jhHl_LH_eyRQTip7LriV4 Cc: "aaa-doctors@ietf.org" , The IESG , Likepeng , "ace@ietf.org" , "adrian@olddog.co.uk" , =?UTF-8?Q?G=C3=B6ran_Selander?= Subject: Re: [Ace] Revised charter proposal: charter-ietf-ace-00-02 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments $ace$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 17:05:07 -0000 --001a1133146404e96304fb05a01a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks, Benoit! The change has been made. Once agreed upon and cleared, I'll progress this= . On Wed, Jun 4, 2014 at 12:38 PM, Benoit Claise wrote: > Hi Kathleen, > > Fine with me > > Regards, B. > > Benoit had one other change mentioned in a previous email that was left > out. He agrees that it is editorial. I'm fine with adding it if that is > okay, but would prefer to leave "used" in instead of "re-used" as it isn'= t > needed (IMO). > > Is the last option agreeable and would it clear your concerns, Benoit? > > OLD: > Existing authentication and authorization protocols will be used where > applicable to build the constrained-environment solution > > NEW: > Existing authentication and authorization protocols will be evaluated and > re-used where > applicable to build the constrained-environment solution > > NEWER: > Existing authentication and authorization protocols will be evaluated and > used where > applicable to build the constrained-environment solution > > > > On Wed, Jun 4, 2014 at 10:05 AM, Kathleen Moriarty < > kathleen.moriarty.ietf@gmail.com> wrote: > >> Thank you, G=C3=B6ran. >> >> It must have been a cut-n-paste error. The first sentence for the >> 'replace' did not match the original or the new either. If the next >> version isn't quite right, pasting in a new full version may be better. >> I'll look back through Benoit's comment now as well. >> >> >> On Wed, Jun 4, 2014 at 3:06 AM, G=C3=B6ran Selander < >> goran.selander@ericsson.com> wrote: >> >>> Hi Kathleen, >>> >>> In change #3 of the summary Kepeng made below I find the sentence: >>= Other >>> security protocols may be considered as long as the primary focus is >>> maintained. >> This sentence seems to be missing from >>> charter-ietf-ace-00-04. >>> >>> Regards, >>> G=C3=B6ran >>> >>> >>> From: Kathleen Moriarty >>> Date: Tuesday 3 June 2014 22:27 >>> To: Likepeng >>> Cc: Benoit Claise , "adrian@olddog.co.uk" < >>> adrian@olddog.co.uk>, "ace@ietf.org" , The IESG < >>> iesg@ietf.org>, "aaa-doctors@ietf.org" >>> Subject: Re: [Ace] Revised charter proposal: charter-ietf-ace-00-02 >>> >>> The charter text has been updated, >>> https://datatracker.ietf.org/doc/charter-ietf-ace/ >>> >>> Thank you all for your input and assistance. If this is good, we'll >>> move it forward for IETF review. >>> >>> >>> >>> On Tue, Jun 3, 2014 at 10:39 AM, Kathleen Moriarty < >>> kathleen.moriarty.ietf@gmail.com> wrote: >>> >>>> I believe there is agreement on the proposed changes. I'll make the >>>> updates later in the day (it's about 11:30 my time, maybe at 4) in cas= e >>>> anyone wants to chime in. If we are all in agreement, I'll have it se= nt >>>> for IETF review at that point. >>>> >>>> Thank you! >>>> >>>> >>>> On Tue, Jun 3, 2014 at 10:26 AM, Likepeng wrote: >>>> >>>>> Hi Kathleen and all, >>>>> >>>>> >>>>> >>>>> This is what I have now: >>>>> >>>>> >>>>> >>>>> Change #1: (Proposed by Kepeng, confirmed by Benoit) >>>>> >>>>> OLD >>>>> >>>>> The IETF has recently developed protocols for use in constrained >>>>> >>>>> environments, where network nodes are limited in CPU, memory and powe= r. >>>>> >>>>> >>>>> >>>>> NEW >>>>> >>>>> The IETF has recently developed protocols for use in constrained >>>>> >>>>> environments, where network nodes are limited in CPU, memory and powe= r. >>>>> >>>>> REST architecture is widely used for such constrained environments. >>>>> >>>>> END >>>>> >>>>> >>>>> >>>>> Change #2: (Proposal from Rene, supported by Stefanie) >>>>> >>>>> OLD: >>>>> >>>>> Requirements derived from use cases indicate the suitability of exis= ting >>>>> >>>>> work as a solution for constrained environments >>>>> >>>>> >>>>> >>>>> NEW: >>>>> >>>>> Requirements derived from use cases may indicate that existing work = is >>>>> >>>>> useful as basis for as a solution for constrained environments >>>>> >>>>> >>>>> >>>>> Change #3: (Proposal from Jari, supported by Barry, Robert and Behcet= ) >>>>> >>>>> OLD: >>>>> >>>>> Note that the initial focus is on CoAP and HTTP with DTLS and TLS. >>>>> >>>>> Other security protocols may be considered as long as the primary foc= us is maintained. >>>>> >>>>> Other application protocols and protocols at other layers in the stac= k are out of scope. >>>>> >>>>> >>>>> >>>>> NEW >>>>> >>>>> Note that the initial focus is on CoAP and HTTP with DTLS and TLS. >>>>> >>>>> Other security protocols may be considered as long as the primary foc= us is maintained. >>>>> >>>>> The group is scoped to work only on the web protocols and data carrie= d within them. >>>>> >>>>> END >>>>> >>>>> >>>>> >>>>> Change 4: (Proposal from Jari, revised by Rene, supported by Stefani= e) >>>>> >>>>> OLD: >>>>> >>>>> Jul 2014 Submit "Use cases and Requirements" as a WG item. >>>>> >>>>> Jul 2015 Submit =E2=80=9CUse cases and Requirements=E2=80=9D documen= t to IESG for publication as informational RFC. >>>>> >>>>> >>>>> >>>>> NEW >>>>> >>>>> Dec 2014 Submit "Use cases and Requirements" as a WG item. >>>>> >>>>> Apr 2015 Optionally, submit "Use cases and Requirements" document to = the IESG for >>>>> >>>>> publication as an Informational RFC. >>>>> >>>>> END >>>>> >>>>> >>>>> >>>>> I think we covered all of the IESG review comments. >>>>> >>>>> >>>>> >>>>> If there is any open issue, please let us know. >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> >>>>> >>>>> Kind Regards >>>>> >>>>> Kepeng >>>>> >>>>> >>>>> ---------------------------------------------------------------------= ---------------------------------------------------------------------------= -------- >>>>> >>>>> >>>>> >>>>> Charter charter-ietf-ace-00-02 >>>>> >>>>> Authentication and Authorization for Constrained >>>>> >>>>> Environment (ACE) >>>>> >>>>> >>>>> >>>>> The IETF has recently developed protocols for use in constrained >>>>> >>>>> environments, where network nodes are limited in CPU, memory and >>>>> power. >>>>> >>>>> REST architecture is widely used for such constrained environments. >>>>> >>>>> It has been observed that Internet protocols can be applied to these >>>>> >>>>> constrained environments, often only requiring minor tweaking and >>>>> >>>>> profiling. In other cases, new protocols have been defined to address >>>>> >>>>> the specific requirements of constrained environments. An example of >>>>> >>>>> such a protocol is the Constrained Application Protocol (CoAP). >>>>> >>>>> >>>>> >>>>> As in other environments, authentication and authorization questions >>>>> >>>>> also arise in constrained environments. For example, a door lock has = to >>>>> >>>>> authorize the person seeking access using a "digital key". Where is t= he >>>>> >>>>> authorization policy stored? How does the digital key communicate wit= h >>>>> >>>>> the lock? Does the lock interact with an authorization server to obta= in >>>>> >>>>> authorization information? How can access be temporarily granted to >>>>> >>>>> other persons? How can access be revoked? These types of questions ha= ve >>>>> >>>>> been answered by existing protocols for use cases outside constrained >>>>> >>>>> environments, however in constrained environments, additional and >>>>> >>>>> different requirements pose challenges for the use of various securit= y >>>>> >>>>> protocols. In particular, the need arises for a dynamic and fine >>>>> grained >>>>> >>>>> access control mechanism, where clients and/or resource servers are >>>>> >>>>> constrained. >>>>> >>>>> >>>>> >>>>> The IETF has a long history in developing three-party authentication >>>>> and >>>>> >>>>> authorization protocols for distributed environments. Examples includ= e >>>>> >>>>> Kerberos, the Public Key Infrastructure (PKI), the Authentication, >>>>> >>>>> Authorization and Accounting (AAA) infrastructure,and the Web >>>>> >>>>> Authorization Protocol (OAuth). All these protocols enjoy widespread >>>>> >>>>> deployment on the Internet. Although they all aim to solve a similar >>>>> >>>>> goal, at an abstract level, they offer quite different functions and >>>>> >>>>> utilize different message exchanges. These differences result from th= e >>>>> >>>>> main deployment use cases they were designed for respectively. >>>>> >>>>> >>>>> >>>>> Requirements derived from use cases may indicate that existing work i= s >>>>> >>>>> useful as basis for as a solution for constrained environments. >>>>> >>>>> These protocols, >>>>> >>>>> however, were not optimized for constrained environments. Additional >>>>> >>>>> requirements that need to be taken into account are the lack of a >>>>> >>>>> suitable user-interface and the inability of embedded devices to >>>>> contact >>>>> >>>>> an authorization server in real-time with every resource access reque= st >>>>> >>>>> due to intermittent connectivity, etc. >>>>> >>>>> >>>>> >>>>> This working group therefore aims to produce a standardized solution >>>>> for >>>>> >>>>> authentication and authorization to enable authorized access (GET, >>>>> PUT, POST, >>>>> >>>>> DELETE) to resources identified by a URI and hosted on a resource >>>>> >>>>> server in constrained environments. As a starting point, the working >>>>> >>>>> group will assume that access to resources at a resource server by a >>>>> >>>>> client device takes place using CoAP and is protected by DTLS. Both >>>>> >>>>> resource server and client may be constrained. This access will be >>>>> >>>>> mediated by an authorization server, which is not considered to be >>>>> >>>>> constrained. >>>>> >>>>> >>>>> >>>>> Existing authentication and authorization protocols will be evaluated >>>>> >>>>> and re-used where applicable to build the constrained-environment >>>>> solution. >>>>> >>>>> This requires >>>>> >>>>> relevant specifications to be reviewed for suitability, selecting a >>>>> >>>>> subset of them and restricting the options within each of the >>>>> >>>>> specifications. Some functionality, however, may not be available in >>>>> >>>>> existing protocols, in which case the solution may also involve new >>>>> >>>>> protocol work. Leveraging existing work means the working group >>>>> benefits >>>>> >>>>> from available security analysis, implementation, and deployment >>>>> >>>>> experience. Moreover, a standardized solution for federated >>>>> >>>>> authentication and authorization will help to stimulate the deploymen= t >>>>> >>>>> of constrained devices that provide increased security. >>>>> >>>>> >>>>> >>>>> Once progress in identifying suitable candidate solutions has been >>>>> made, >>>>> >>>>> the working group will verify whether the same mechanisms are also >>>>> >>>>> applicable beyond the use of CoAP and DTLS, which are the two main >>>>> >>>>> protocols the group will focus on for access to resources. In >>>>> >>>>> particular, the ability to use the developed solution over HTTP and T= LS >>>>> >>>>> will be investigated. Note that the initial focus is on CoAP and HTTP >>>>> with DTLS and TLS. >>>>> >>>>> Other security protocols may be considered as long as the primary >>>>> focus is maintained. >>>>> >>>>> The group is scoped to work only on the web protocols and data carrie= d >>>>> within them. >>>>> >>>>> Furthermore, to guarantee smooth transition, the >>>>> >>>>> integration with existing deployments will be studied, particularly >>>>> >>>>> concerning the use of protocol translation proxies. >>>>> >>>>> >>>>> >>>>> This work does not make the assumption that the party offering >>>>> >>>>> application layer services is always the same party offering network >>>>> >>>>> access services. >>>>> >>>>> >>>>> >>>>> The working group has the following tasks: >>>>> >>>>> >>>>> >>>>> 1) Produce use cases and requirements >>>>> >>>>> >>>>> >>>>> 2) Identify authentication and authorization mechanisms suitable for >>>>> >>>>> resource access in constrained environments. >>>>> >>>>> >>>>> >>>>> Milestones: >>>>> >>>>> >>>>> >>>>> Dec 2014 Submit "Use cases and Requirements" as a WG item. >>>>> >>>>> Dec 2014 Submit "Authentication and Authorization Solution" as a WG >>>>> item. >>>>> >>>>> Apr 2015 Optionally, submit "Use cases and Requirements" document >>>>> >>>>> to the IESG for publication as an Informational RFC. >>>>> >>>>> Jul 2016 Submit "Authentication and Authorization Solution" >>>>> >>>>> specification to the IESG for publication as a Proposed Standard. >>>>> >>>>> >>>>> >>>>> Proposed Milestones >>>>> >>>>> No milestones for charter found. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> *=E5=8F=91=E4=BB=B6=E4=BA=BA:* Kathleen Moriarty [mailto:kathleen.mor= iarty.ietf@gmail.com] >>>>> *=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4:* 2014=E5=B9=B46=E6=9C=883=E6= =97=A5 14:30 >>>>> *=E6=94=B6=E4=BB=B6=E4=BA=BA:* Likepeng >>>>> *=E6=8A=84=E9=80=81:* Benoit Claise; adrian@olddog.co.uk; aaa-doctors= @ietf.org; The >>>>> IESG; ace@ietf.org >>>>> *=E4=B8=BB=E9=A2=98:* Re: Revised charter proposal: charter-ietf-ace= -00-02 >>>>> >>>>> >>>>> >>>>> Hi Kepeng, >>>>> >>>>> >>>>> >>>>> If we are at a point where I can update the charter, seems that way, >>>>> please send the latest version that has been agreed upon and I'll tak= e care >>>>> of the update. >>>>> >>>>> >>>>> >>>>> Thanks. >>>>> >>>>> >>>>> >>>>> On Tue, Jun 3, 2014 at 6:31 AM, Likepeng wrote: >>>>> >>>>> Hi Benoit, >>>>> >>>>> >>>>> >>>>> >Not only would I keep "AAA", >>>>> >>>>> >>>>> >>>>> OK. >>>>> >>>>> >>>>> >>>>> >but I would propose >>>>> >>>>> >>>>> >>>>> >OLD: >>>>> >>>>> >Existing authentication and authorization protocols will be used whe= re >>>>> >>>>> applicable to build the constrained-environment solution. >>>>> >>>>> >>>>> >>>>> >NEW: >>>>> >>>>> Existing authentication and authorization protocols will be evaluated >>>>> and re-used where >>>>> >>>>> applicable to build the constrained-environment solution. >>>>> >>>>> >>>>> >>>>> OK, fine with me. >>>>> >>>>> >>>>> >>>>> Thanks for the feedback. >>>>> >>>>> >>>>> >>>>> Kind Regards >>>>> >>>>> Kepeng >>>>> >>>>> >>>>> >>>>> *=E5=8F=91=E4=BB=B6=E4=BA=BA:* Benoit Claise [mailto:bclaise@cisco.co= m] >>>>> *=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4:* 2014=E5=B9=B46=E6=9C=883=E6= =97=A5 12:16 >>>>> >>>>> *=E6=94=B6 =E4=BB=B6=E4=BA=BA:* Likepeng; Kathleen Moriarty; adrian@o= lddog.co.uk >>>>> >>>>> *=E6=8A=84 =E9=80=81:* aaa-doctors@ietf.org; The IESG; ace@ietf.org >>>>> >>>>> *=E4=B8=BB =E9=A2=98:* Re: Revised charter proposal: charter-ietf-ace= -00-02 >>>>> >>>>> >>>>> >>>>> Hi, >>>>> >>>>> Hello all, >>>>> >>>>> >>>>> >>>>> Based on recent discussions, I made a revised charter proposal, as in= cluded in this email, not on the webpage yet. >>>>> >>>>> >>>>> >>>>> Please take a look and let us know if you have any further comments. >>>>> >>>>> >>>>> >>>>> @Adrian and @Benoit, please check if the proposed texts can resolve y= our comments. >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Kind Regards >>>>> >>>>> Kepeng >>>>> >>>>> >>>>> >>>>> ---------------------------------------------------------------------= ---------------------------------------------------------------------------= ------------- >>>>> >>>>> Compared with charter-ietf-ace-00-01 on the webpage, the changes are: >>>>> >>>>> >>>>> >>>>> (1) Add one clarification sentence about REST architecture: >>>>> >>>>> OLD >>>>> >>>>> The IETF has recently developed protocols for use in constrained >>>>> >>>>> environments, where network nodes are limited in CPU, memory and powe= r. >>>>> >>>>> REST architecture is widely used for such constrained environments. >>>>> >>>>> >>>>> >>>>> NEW >>>>> >>>>> The IETF has recently developed protocols for use in constrained >>>>> >>>>> environments, where network nodes are limited in CPU, memory and powe= r. >>>>> >>>>> REST architecture is widely used for such constrained environments. >>>>> >>>>> END >>>>> >>>>> Considering that OLD is >>>>> >>>>> OLD >>>>> >>>>> The IETF has recently developed protocols for use in constrained >>>>> >>>>> environments, where network nodes are limited in CPU, memory and powe= r. >>>>> >>>>> ... fine with me >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> (2) Remove =E2=80=9CAAA protocol=E2=80=9D from the charter: >>>>> >>>>> OLD >>>>> >>>>> The IETF has a long history in developing three-party authentication = and >>>>> >>>>> authorization protocols for distributed environments. Examples includ= e >>>>> >>>>> Kerberos, the Public Key Infrastructure (PKI), the Authentication, >>>>> >>>>> Authorization and Accounting (AAA) infrastructure, and the Web >>>>> >>>>> Authorization Protocol (OAuth). >>>>> >>>>> >>>>> >>>>> NEW >>>>> >>>>> The IETF has a long history in developing three-party authentication = and >>>>> >>>>> authorization protocols for distributed environments. Examples includ= e >>>>> >>>>> Kerberos, the Public Key Infrastructure (PKI), and the Web Authorizat= ion Protocol (OAuth). >>>>> >>>>> END >>>>> >>>>> We have AAA-doctors telling: maybe RADIUS is applicable? >>>>> Personally, I don't know and it doesn't matter at this point. >>>>> We received feedback such as: >>>>> >>>>> Let's be clear here: It was never said (in the charter or anywhere >>>>> else in the group to my knowledge) that RADIUS (or indeed any other A= AA >>>>> protocol) would not run on constrained devices (RFC 7228). The charte= r >>>>> simply said the protocols were not optimised for constrained devices.= That >>>>> does not preclude considering any protocol for suitability for constr= ained >>>>> devices either a) as is, b) in a restricted way or c) in an adapted w= ay. >>>>> >>>>> So, at this stage, I don't think any protocols should be excluded fro= m >>>>> consideration and should certainly not be eliminated on a hunch that = they >>>>> might be "too big". Let's do the assessment properly at the appropria= te >>>>> time. As a reminder - the focus now is to complete the charter. >>>>> >>>>> Or >>>>> >>>>> >>The Charter makes a number of assertions that are provably false, s= uch as that AAA protocols are inappropriate for constrained environments. >>>>> >>>>> In fact, the charter does not say that. But to avoid confusion, let's= remove AAA protocol from the charter. >>>>> >>>>> >>>>> >>>>> In the charter, we mentioned that we want to reuse existing authentic= ation and authorization protocols where applicable to build the constrained= -environment solution. >>>>> >>>>> ... which I read as: let's consider the AAA protocols, and evaluate i= f >>>>> they would work in constrained devices. >>>>> I don't understand the logic: why do you want to remove AAA from the >>>>> charter? >>>>> Not only would I keep "AAA", but I would propose >>>>> >>>>> OLD: >>>>> Existing authentication and authorization protocols will be used wher= e >>>>> applicable to build the constrained-environment solution >>>>> >>>>> NEW: >>>>> Existing authentication and authorization protocols will be evaluated >>>>> and re-used where >>>>> applicable to build the constrained-environment solution >>>>> >>>>> Regards, Benoit >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> (3) Clarify the scope: >>>>> >>>>> OLD: >>>>> >>>>> Note that the initial focus is on CoAP and HTTP with DTLS and TLS. >>>>> >>>>> Other security protocols may be considered as long as the primary foc= us is maintained. >>>>> >>>>> Other application protocols and protocols at other layers in the stac= k are out of scope. >>>>> >>>>> >>>>> >>>>> NEW >>>>> >>>>> Note that the initial focus is on CoAP and HTTP with DTLS and TLS. >>>>> >>>>> Other security protocols may be considered as long as the primary foc= us is maintained. >>>>> >>>>> The group is scoped to work only on the web protocols and data carrie= d within them. >>>>> >>>>> END >>>>> >>>>> >>>>> >>>>> (4) Update milestones for the use case & requirements document: >>>>> >>>>> OLD: >>>>> >>>>> Jul 2015 Submit =E2=80=9CUse cases and Requirements=E2=80=9D document= to IESG for publication as informational RFC. >>>>> >>>>> >>>>> >>>>> NEW >>>>> >>>>> Dec 2014 Optionally, submit "Use cases and Requirements" document to = the IESG for publication as an Informational RFC. >>>>> >>>>> END >>>>> >>>>> >>>>> >>>>> ---------------------------------------------------------------------= ---------------------------------------------------------------------------= ---------------------------- >>>>> >>>>> Charter charter-ietf-ace-00-02 >>>>> >>>>> Authentication and Authorization for Constrained >>>>> >>>>> Environment (ACE) >>>>> >>>>> >>>>> >>>>> The IETF has recently developed protocols for use in constrained >>>>> >>>>> environments, where network nodes are limited in CPU, memory and powe= r. >>>>> >>>>> REST architecture is widely used for such constrained environments. >>>>> >>>>> It has been observed that Internet protocols can be applied to these >>>>> >>>>> constrained environments, often only requiring minor tweaking and >>>>> >>>>> profiling. In other cases, new protocols have been defined to address >>>>> >>>>> the specific requirements of constrained environments. An example of >>>>> >>>>> such a protocol is the Constrained Application Protocol (CoAP). >>>>> >>>>> >>>>> >>>>> As in other environments, authentication and authorization questions >>>>> >>>>> also arise in constrained environments. For example, a door lock has = to >>>>> >>>>> authorize the person seeking access using a "digital key". Where is t= he >>>>> >>>>> authorization policy stored? How does the digital key communicate wit= h >>>>> >>>>> the lock? Does the lock interact with an authorization server to obta= in >>>>> >>>>> authorization information? How can access be temporarily granted to >>>>> >>>>> other persons? How can access be revoked? These types of questions ha= ve >>>>> >>>>> been answered by existing protocols for use cases outside constrained >>>>> >>>>> environments, however in constrained environments, additional and >>>>> >>>>> different requirements pose challenges for the use of various securit= y >>>>> >>>>> protocols. In particular, the need arises for a dynamic and fine grai= ned >>>>> >>>>> access control mechanism, where clients and/or resource servers are >>>>> >>>>> constrained. >>>>> >>>>> >>>>> >>>>> The IETF has a long history in developing three-party authentication = and >>>>> >>>>> authorization protocols for distributed environments. Examples includ= e >>>>> >>>>> Kerberos, the Public Key Infrastructure (PKI), and the Web >>>>> >>>>> Authorization Protocol (OAuth). All these protocols enjoy widespread >>>>> >>>>> deployment on the Internet. Although they all aim to solve a similar >>>>> >>>>> goal, at an abstract level, they offer quite different functions and >>>>> >>>>> utilize different message exchanges. These differences result from th= e >>>>> >>>>> main deployment use cases they were designed for respectively. >>>>> >>>>> >>>>> >>>>> Requirements derived from use cases indicate the suitability of exist= ing >>>>> >>>>> work as a solution for constrained environments. These protocols, >>>>> >>>>> however, were not optimized for constrained environments. Additional >>>>> >>>>> requirements that need to be taken into account are the lack of a >>>>> >>>>> suitable user-interface and the inability of embedded devices to cont= act >>>>> >>>>> an authorization server in real-time with every resource access reque= st >>>>> >>>>> due to intermittent connectivity, etc. >>>>> >>>>> >>>>> >>>>> This working group therefore aims to produce a standardized solution = for >>>>> >>>>> authentication and authorization to enable authorized access (GET, PU= T, POST, >>>>> >>>>> DELETE) to resources identified by a URI and hosted on a resource >>>>> >>>>> server in constrained environments. As a starting point, the working >>>>> >>>>> group will assume that access to resources at a resource server by a >>>>> >>>>> client device takes place using CoAP and is protected by DTLS. Both >>>>> >>>>> resource server and client may be constrained. This access will be >>>>> >>>>> mediated by an authorization server, which is not considered to be >>>>> >>>>> constrained. >>>>> >>>>> >>>>> >>>>> Existing authentication and authorization protocols will be used wher= e >>>>> >>>>> applicable to build the constrained-environment solution. This requir= es >>>>> >>>>> relevant specifications to be reviewed for suitability, selecting a >>>>> >>>>> subset of them and restricting the options within each of the >>>>> >>>>> specifications. Some functionality, however, may not be available in >>>>> >>>>> existing protocols, in which case the solution may also involve new >>>>> >>>>> protocol work. Leveraging existing work means the working group benef= its >>>>> >>>>> from available security analysis, implementation, and deployment >>>>> >>>>> experience. Moreover, a standardized solution for federated >>>>> >>>>> authentication and authorization will help to stimulate the deploymen= t >>>>> >>>>> of constrained devices that provide increased security. >>>>> >>>>> >>>>> >>>>> Once progress in identifying suitable candidate solutions has been ma= de, >>>>> >>>>> the working group will verify whether the same mechanisms are also >>>>> >>>>> applicable beyond the use of CoAP and DTLS, which are the two main >>>>> >>>>> protocols the group will focus on for access to resources. In >>>>> >>>>> particular, the ability to use the developed solution over HTTP and T= LS >>>>> >>>>> will be investigated. Note that the initial focus is on CoAP and HTTP= with DTLS and TLS. >>>>> >>>>> Other security protocols may be considered as long as the primary foc= us is maintained. >>>>> >>>>> The group is scoped to work only on the web protocols and data carrie= d within them. >>>>> >>>>> Furthermore, to guarantee smooth transition, the >>>>> >>>>> integration with existing deployments will be studied, particularly >>>>> >>>>> concerning the use of protocol translation proxies. >>>>> >>>>> >>>>> >>>>> This work does not make the assumption that the party offering >>>>> >>>>> application layer services is always the same party offering network >>>>> >>>>> access services. >>>>> >>>>> >>>>> >>>>> The working group has the following tasks: >>>>> >>>>> >>>>> >>>>> 1) Produce use cases and requirements >>>>> >>>>> >>>>> >>>>> 2) Identify authentication and authorization mechanisms suitable for >>>>> >>>>> resource access in constrained environments. >>>>> >>>>> >>>>> >>>>> Milestones: >>>>> >>>>> >>>>> >>>>> Jul 2014 Submit "Use cases and Requirements" as a WG item. >>>>> >>>>> Dec 2014 Submit "Authentication and Authorization Solution" as a WG i= tem. >>>>> >>>>> Dec 2014 Optionally, submit "Use cases and Requirements" document >>>>> >>>>> to the IESG for publication as an Informational RFC. >>>>> >>>>> Jul 2016 Submit "Authentication and Authorization Solution" >>>>> >>>>> specification to the IESG for publication as a Proposed Standard. >>>>> >>>>> >>>>> >>>>> Proposed Milestones >>>>> >>>>> No milestones for charter found. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> >>>>> >>>>> Best regards, >>>>> >>>>> Kathleen >>>>> >>>> >>>> >>>> >>>> -- >>>> >>>> Best regards, >>>> Kathleen >>>> >>> >>> >>> >>> -- >>> >>> Best regards, >>> Kathleen >>> >>> >> >> >> -- >> >> Best regards, >> Kathleen >> > > > > -- > > Best regards, > Kathleen > > > --=20 Best regards, Kathleen --001a1133146404e96304fb05a01a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks, Benoit!

The change has been mad= e. =C2=A0Once agreed upon and cleared, I'll progress this.
<= div class=3D"gmail_extra">

On Wed, Jun 4,= 2014 at 12:38 PM, Benoit Claise <bclaise@cisco.com> wrote:<= br>
=20 =20 =20

Hi Kathleen,

Fine with me

Regards, B.

=20
Benoit=C2=A0had one other change mentioned in a previous email that was left out. He agrees that it is editorial. =C2=A0I'm fine with adding it= if that is okay, but would prefer to leave "used" in inste= ad of "re-used" as it isn't needed (IMO).

Is the last option agreeable and would it clear your concerns, Benoit?

OLD:
Existing authentication and authorization protocols will be used where
applicable to build the constrained-environment solution

NEW:
Existing authentication and authorization protocols will be evaluated and re-used where
applicable to build the constrained-environment solution

NEWER:
Existing authentication and authorization protocols will be evaluated and used where
applicable to build the constrained-environment solution

On Wed, Jun 4, 2014 at 10:05 AM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:

Thank you,=C2=A0G=C3=B6ran.

It must have been a cut-n-paste error. =C2=A0The first senten= ce for the 'replace' did not match the original or the n= ew either. =C2=A0If the next version isn't quite right, past= ing in a new full version may be better. =C2=A0I'll look back th= rough Benoit's comment now as well.

On Wed, Jun 4, 2014 at 3:06 AM, G=C3=B6ran Selander <goran.selander@er= icsson.com> wrote:

Hi Kathleen,

In change #3 of the summary Kepeng made below=C2=A0= I find the sentence: >>Other security protocols may be considered as long as the primary focus is maintained. >>=C2=A0This=C2=A0sentence seems to be missing from charter-ietf-ace-00-04.

Regards,

G=C3= =B6ran

From: K= athleen Moriarty <kathleen.moriarty.ietf@gmail.com>= ;
Date: T= uesday 3 June 2014 22:27
To: Lik= epeng <likepeng@huawei.com>
Cc: Ben= oit Claise <bclaise@cisco.com>, "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "ace@ietf.org" <ace@ietf.org>, The IESG <iesg@ietf.org>, "aaa-doctors@ietf.org" <aaa-doctors@ietf.org>
Subject: Re: [Ace] Revised charter proposal: charter-ietf-ace-00-02

The charter text has been updated,=C2=A0https://data= tracker.ietf.org/doc/charter-ietf-ace/

Thank you all for your input and assistance. =C2=A0If this is good, we'll move it forward for IETF review.

On Tue, Jun 3, 2014 at 10:39 AM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:

I believe there is agreement on the proposed changes. =C2=A0I'll make th= e updates later in the day (it's about 11:30 my time, maybe at 4) in case anyone wants to chime in. =C2=A0If we are all in agreement, I'll have it sent for IETF review at that point.

Thank you!

= On Tue, Jun 3, 2014 at 10:26 AM, Likepeng <likepeng@huawei.com> wrote:

Hi Kathleen and all,

=C2=A0

This is what I have now:

=C2=A0

Change #1: (Proposed by Kepeng, confirmed by Benoit)

OLD

The IETF has recently developed protocols for use in constrai= ned

environments, where network nodes are limited in CPU, memory = and power.

=C2=A0

NEW

The IETF has recently developed protocols for use in constrai= ned

environments, where network nodes are limited in CPU, memory = and power.

REST architecture is widely used for such constrained environ= ments.

END

=C2=A0

Change #2: (Proposal from Rene, supported by Stefanie)
OLD:

Requirements derived from use cases indicate the suitability = of existing

work as a solution for constrained environments

=C2=A0

NEW:

Requirements derived from use cases may indicate that existin= g work is

useful as basis for as a solution for constrained environments<= /span>

=C2=A0

Change #3: (Proposal from Jari, supported by Barry, Robert and B= ehcet)

OLD:

Note that the initial focus is on CoAP and HTTP with DTLS and= TLS.

Other security protocols may be considered as long as the pri= mary focus is maintained.=C2=A0

Other application protocols and protocols at other layers in = the stack are out of scope.

=C2=A0

NEW

Note that the initial focus is on CoAP and HTTP with DTLS and= TLS.

Other security protocols may be considered as long as the pri= mary focus is maintained.=C2=A0

The group is scoped to work only on the web protocols and dat= a carried within them.

END

=C2=A0

Change 4: (Proposal from Jari, revised by Rene, supported by Ste= fanie)

OLD:

Jul 2014 Submit "Use cases and Requirements" as a = WG item.

Jul 2015 Submit =E2=80=9CUse cases and Requirements=E2=80=9D doc= ument to IESG for publication as informational RFC.

=C2=A0

NEW

Dec 2014 Submit "Use cases and Requirements" as a WG = item.

Apr 2015 Optionally, submit "Use cases and Requirements&quo= t; document to the IESG for

publication as an Informational RFC.

END

=C2=A0

I think we covered all of the IESG review comments.<= /p>
=C2=A0

If there is any open issue, please let us know.

=C2=A0

Thanks,

=C2=A0

Kind Regards
Kepeng

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

=C2=A0

Charter charter-ietf-ace-00-02

Authentication and Authorization for Constrained

Environment (ACE)

=C2=A0

The IETF has recently developed protocols for use in constrained

environments, where network nodes are limited in CPU, memory and power.

REST architecture is widely used for such constrained environments.

It has been observed that Internet protocols can be applied to these

constrained environments, often only requiring minor tweaking and

profiling. In other cases, new protocols have been defined to address=

the specific requirements of constrained environments. An example of

such a protocol is the Constrained Application Protocol (CoAP).
=C2=A0

As in other environments, authentication and authorization questions<= /p>
also arise in constrained environments. For example, a door lock has to

authorize the person seeking access using a "digital key= ". Where is the

authorization policy stored? How does the digital key communicate with

the lock? Does the lock interact with an authorization server to obtain

authorization information? How can access be temporarily granted to=

other persons? How can access be revoked? These types of questions have

been answered by existing protocols for use cases outside constrained

environments, however in constrained environments, additional and

different requirements pose challenges for the use of various security
protocols. In particular, the need arises for a dynamic and fine grained

access control mechanism, where clients and/or resource servers are

constrained.

=C2=A0

The IETF has a long history in developing three-party authentication and

authorization protocols for distributed environments. Examples include

Kerberos, the Public Key Infrastructure (PKI), the Authentication,

Authorization and Accounting (AAA) infrastructure,an= d the Web

Authorization Protocol (OAuth). All these protocols enjoy widespread=

deployment on the Internet. Although they all aim to solve a similar
goal, at an abstract level, they offer quite different functions and

utilize different message exchanges. These differences result from the

main deployment use cases they were designed for respectively.

=C2=A0

Requirements derived from use cases may indicate that existing work is

useful as basis for as a solution for constrained environments.

These protocols,=

however, were not optimized for constrained environments. Additional=

requirements that need to be taken into account are the lack of a

suitable user-interface and the inability of embedded devices to contact
an authorization server in real-time with every resource access request

due to intermittent connectivity, etc.

=C2=A0

This working group therefore aims to produce a standardized solution for

authentication and authorization to enable authorized access (GET, PUT, POST,

DELETE) to resources identified by a URI and hosted on a resource
server in constrained environments. As a starting point, the working
group will assume that access to resources at a resource server by a

client device takes place using CoAP and is protected by DTLS. Both=

resource server and client may be constrained. This access will be
mediated by an authorization server, which is not considered to be

constrained.

=C2=A0

Existing authentication and authorization protocols will be evaluated

and re-used where applicable to build the constrained-envir= onment solution.<= /p>

This requires

relevant specifications to be reviewed for suitability, selecting a

subset of them and restricting the options within each of the

specifications. Some functionality, however, may not be available in

existing protocols, in which case the solution may also involve new

protocol work. Leveraging existing work means the working group benefits
from available security analysis, implementation, and deployment

experience. Moreover, a standardized solution for federated<= /p>
authentication and authorization will help to stimulate the deployment=

of constrained devices that provide increased security.<= /p>
=C2=A0

Once progress in identifying suitable candidate solutions has been made,=

the working group will verify whether the same mechanisms are also

applicable beyond the use of CoAP and DTLS, which are the two main

protocols the group will focus on for access to resources. In

particular, the ability to use the developed solution over HTTP and TLS

will be investigated. Note that the initial focus is on CoAP and HTTP with DTLS and TLS.
Other security protocols may be considered as long as the primary focus is maintained.=C2=A0

The group is scoped to work only on the web protocols and data carried within them.

Furthermore, to guarantee smooth transition, the

integration with existing deployments will be studied, particularly

concerning the use of protocol translation proxies.
=C2=A0

This work does not make the assumption that the party offering
application layer services is always the same party offering network
access services.<= /p>
=C2=A0

The working group has the following tasks:

=C2=A0

1) Produce use cases and requirements

=C2=A0

2) Identify authentication and authorization mechanisms suitable for

resource access in constrained environments.

=C2=A0

Milestones:

=C2=A0

Dec 2014 Submit "Use cases a= nd Requirements"= ; as a WG item.

Dec 2014 Submit "Authenticat= ion and Authorization Solution" as= a WG item.

Apr 2015 Optionally, submit "Use cases and Requirements"= ; document

to the IESG for publication as an Informational RFC.

Jul 2016 Submit "Authenticat= ion and Authorization Solution"

specification to the IESG for publication as a Proposed Standard.<= /p>
=C2=A0

Proposed Milestones

No milestones for charter found.

=C2=A0

=C2=A0

=C2=A0

=E5=8F=91=E4=BB=B6=E4=BA=BA: Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com]
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4:= 2014=E5=B9=B4= 6=E6=9C=883=E6=97=A5 14:30
=E6=94= =B6=E4=BB=B6=E4=BA=BA: Likepeng
=E6=8A= =84=E9=80=81: Benoit Claise; adrian@olddog.co.uk; aaa-doctors@ietf.org; The IESG; ace@ietf.org

=E4=B8=BB= =E9=A2=98: Re: Revised charter proposal: charter-ietf-ace-= 00-02

=C2=A0

Hi Kepeng,

=C2=A0

If we are at a point where I can update the charter, seems that way, please send the latest version that has been agreed upon and I'll take care of the update.

=C2=A0

Thanks.

=C2=A0

On Tue, Jun 3, 2014 at 6:31 AM, Likepeng <likepeng@huawei.com> wrote:

Hi Benoit,

=C2=A0
>Not only would I keep "AAA&qu= ot;,

=C2=A0

OK.

=C2=A0
>but I would propose

=C2=A0
>OLD:<= /p>
>Existing authentication and authorization protocols will be used where

applicable to build the constrained-envir= onment solution.<= span lang=3D"EN-US">

=C2=A0
>NEW:<= /p>
Existing authentication and authorization protocols will be evaluated and re-used where

applicable to build the constrained-envir= onment solution.<= span lang=3D"EN-US">

=C2=A0
OK, fine with me.

=C2=A0
Thanks for the feedback.

=C2=A0
Kind Regards

Kepeng
=C2=A0

=E5=8F=91=E4=BB=B6=E4=BA=BA: Benoit Claise [mailto:bclaise@cisco.com]
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4:= 2014=E5=B9=B4= 6=E6=9C=883=E6=97=A5 12:16

=E6=94=B6 =E4=BB=B6=E4=BA= =BA: Likepeng; Kathleen Moriarty; adrian@olddog.co.uk

=E6=8A=84 =E9=80=81: aaa-doctors@ietf.org; The IESG; ace@ietf.org<= /span>

=E4=B8=BB =E9=A2=98: Re: Revised charter proposal: charter-ietf-ace-= 00-02

=C2=A0

Hi,

Hello all,

=C2=A0

Based on recent discussions, I made a revised charter proposal, = as included in this email, not on the webpage yet.

=C2=A0

Please take a look and let us know if you have any further comme= nts.

=C2=A0

@Adrian and @Benoit, please check if the proposed texts can reso= lve your comments.

=C2=A0

Thanks,

Kind Regards

Kepeng

=C2=A0

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

Compared with charter-ietf-ace-00-01 on the webpage, the changes= are:

=C2=A0

(1)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Add one clarification sentence= about REST architecture:

OLD

The IETF has recently developed protocols for use in constrained=

environments, where network nodes are limited in CPU, memory and= power.

REST architecture is widely used for such constrained environmen= ts.

=C2=A0

NEW

The IETF has recently developed protocols for use in constrained=

environments, where network nodes are limited in CPU, memory and= power.

REST architecture is widely used for such constrained environmen= ts.

END

Considering that OLD is

OLD

The IETF has recently developed protocols for use in constrai= ned

environments, where network nodes are limited in CPU, memory = and power.

... fine with me<= /span>

=C2=A0

=C2=A0

(2)=C2=A0=C2=A0=C2=A0=C2=A0 Remove =E2=80=9CAAA protocol=E2=80=9D from the charter:=

OLD

The IETF has a long history in developing three-party authentica= tion and

authorization protocols for distributed environments. Examples i= nclude

Kerberos, the Public Key Infrastructure (PKI), the Authenticatio= n,

Authorization and Accounting (AAA) infrastructure, and the Web

Authorization Protocol (OAuth).

=C2=A0

NEW

The IETF has a long history in developing three-party authentica= tion and

authorization protocols for distributed environments. Examples i= nclude

Kerberos, the Public Key Infrastructure (PKI), and the Web Autho= rization Protocol (OAuth).

END

We have AAA-doctors telling: maybe RADIUS is applicable?
Personally, I don't know an= d it doesn't matter at this point.
We received feedback such as:

Let's be clear here: It was never said (in the charter or anywhere else in the group to my knowledge) that RADIUS (or indeed any other AAA protocol) would not run on constrained devices (RFC 7228). The charter simply said the protocols were not optimised for constrained devices. That does not preclude considering any protocol for suitability for constrained devices either a) as is, b) in a restricted way or c) in an adapted way.

So, at this stage, I don'= t think any protocols should be excluded from consideration and should certainly not be eliminated on a hunch that they might be "to= o big". Let= 9;s do the assessment properly at the appropriate time. As a reminder - the focus now is to complete the charter.

Or

>>The Charter makes a number of assertions that are provab= ly false, such as that AAA protocols are inappropriate for constrained envi= ronments.

In fact, the charter does not say that. But to avoid confusion, = let's remove AAA protocol from the charter.

=C2=A0

In the charter, we mentioned that we want to reuse existing auth= entication and authorization protocols where applicable to build the constr= ained-environment solution.

... which I read = as: let's conside= r the AAA protocols, and evaluate if they would work in constrained devices.
I don't understand the logic: why do you want to remove AAA from the charter?
Not only would I keep "AAA&= quot;, but I would propose

OLD:
Existing authentication and authorization protocols will be used where
applicable to build the constrained-envir= onment solution

NEW:
Existing authentication and authorization protocols will be evaluated and re-used where
applicable to build the constrained-envir= onment solution

Regards, Benoit

=C2=A0

=C2=A0

(3) Clarify the scope:

OLD:

Note that the initial focus is on CoAP and HTTP with DTLS and TL= S.

Other security protocols may be considered as long as the primar= y focus is maintained.=C2=A0

Other application protocols and protocols at other layers in the= stack are out of scope.

=C2=A0

NEW

Note that the initial focus is on CoAP and HTTP with DTLS and TL= S.

Other security protocols may be considered as long as the primar= y focus is maintained.=C2=A0

The group is scoped to work only on the web protocols and data c= arried within them.

END

=C2=A0

(4)=C2=A0=C2=A0=C2=A0=C2=A0 Update milestones for the use case &= amp; requirements document:

OLD:

Jul 2015 Submit =E2=80=9CUse cases a= nd Requirements=E2=80=9D document to IESG for p= ublication as informational RFC.

=C2=A0

NEW

Dec 2014 Optionally, submit "Use cases and Requirements&quo= t; document to the IESG for publication as an Informational RFC.
END

=C2=A0

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

Charter charter-ietf-ace-00-02

Authentication and Authorization for Constrained

Environment (ACE)

=C2=A0

The IETF has recently developed protocols for use in constrained=

environments, where network nodes are limited in CPU, memory and= power.

REST architecture is widely used for such constrained environmen= ts.

It has been observed that Internet protocols can be applied to t= hese

constrained environments, often only requiring minor tweaking an= d

profiling. In other cases, new protocols have been defined to ad= dress

the specific requirements of constrained environments. An exampl= e of

such a protocol is the Constrained Application Protocol (CoAP).<= /span>

=C2=A0

As in other environments, authentication and authorization quest= ions

also arise in constrained environments. For example, a door lock= has to

authorize the person seeking access using a "digital key&qu= ot;. Where is the

authorization policy stored? How does the digital key communicat= e with

the lock? Does the lock interact with an authorization server to= obtain

authorization information? How can access be temporarily granted= to

other persons? How can access be revoked? These types of questio= ns have

been answered by existing protocols for use cases outside constr= ained

environments, however in constrained environments, additional an= d

different requirements pose challenges for the use of various se= curity

protocols. In particular, the need arises for a dynamic and fine= grained

access control mechanism, where clients and/or resource servers = are

constrained.

=C2=A0

The IETF has a long history in developing three-party authentica= tion and

authorization protocols for distributed environments. Examples i= nclude

Kerberos, the Public Key Infrastructure (PKI), and the Web

Authorization Protocol (OAuth). All these protocols enjoy widesp= read

deployment on the Internet. Although they all aim to solve a sim= ilar

goal, at an abstract level, they offer quite different functions= and

utilize different message exchanges. These differences result fr= om the

main deployment use cases they were designed for respectively.

=C2=A0

Requirements derived from use cases indicate the suitability of = existing

work as a solution for constrained environments. These protocols= ,

however, were not optimized for constrained environments. Additi= onal

requirements that need to be taken into account are the lack of = a

suitable user-interface and the inability of embedded devices to= contact

an authorization server in real-time with every resource access = request

due to intermittent connectivity, etc.

=C2=A0

This working group therefore aims to produce a standardized solu= tion for

authentication and authorization to enable authorized access (GE= T, PUT, POST,

DELETE) to resources identified by a URI and hosted on a resourc= e

server in constrained environments. As a starting point, the wor= king

group will assume that access to resources at a resource server = by a

client device takes place using CoAP and is protected by DTLS. B= oth

resource server and client may be constrained. This access will = be

mediated by an authorization server, which is not considered to = be

constrained.

=C2=A0

Existing authentication and authorization protocols will be used= where

applicable to build the constrained-environment solution. This r= equires

relevant specifications to be reviewed for suitability, selectin= g a

subset of them and restricting the options within each of the

specifications. Some functionality, however, may not be availabl= e in

existing protocols, in which case the solution may also involve = new

protocol work. Leveraging existing work means the working group = benefits

from available security analysis, implementation, and deployment=

experience. Moreover, a standardized solution for federated

authentication and authorization will help to stimulate the depl= oyment

of constrained devices that provide increased security.
=C2=A0

Once progress in identifying suitable candidate solutions has be= en made,

the working group will verify whether the same mechanisms are al= so

applicable beyond the use of CoAP and DTLS, which are the two ma= in

protocols the group will focus on for access to resources. In

particular, the ability to use the developed solution over HTTP = and TLS

will be investigated. Note that the initial focus is on CoAP and= HTTP with DTLS and TLS.

Other security protocols may be considered as long as the primar= y focus is maintained.=C2=A0

The group is scoped to work only on the web protocols and data c= arried within them.

Furthermore, to guarantee smooth transition, the

integration with existing deployments will be studied, particula= rly

concerning the use of protocol translation proxies.

=C2=A0

This work does not make the assumption that the party offering

application layer services is always the same party offering net= work

access services.

=C2=A0

The working group has the following tasks:

=C2=A0

1) Produce use cases and requirements

=C2=A0

2) Identify authentication and authorization mechanisms suitable= for

resource access in constrained environments.

=C2=A0

Milestones:

=C2=A0

Jul 2014 Submit "Use cases and Requirements" as a WG i= tem.

Dec 2014 Submit "Authentication and Authorization Solution&= quot; as a WG item.

Dec 2014 Optionally, submit "Use cases and Requirements&quo= t; document

to the IESG for publication as an Informational RFC.
Jul 2016 Submit "Authentication and Authorization Solution&= quot;

specification to the IESG for publication as a Proposed Standard= .

=C2=A0

Proposed Milestones

No milestones for charter found.

=C2=A0

=C2=A0

--

=C2=A0

Best regards,

Kathleen

-= -

Best regards,

Kathleen

--

Best regards,

Kathleen

--

Best regards,

Kathleen

--

Best regards,

Kathleen

--

Best regards,
Kathleen
--001a1133146404e96304fb05a01a-- From nobody Wed Jun 4 12:56:01 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 158471A0257 for ; Wed, 4 Jun 2014 11:54:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 ufa1Ol0uw4IY for ; Wed, 4 Jun 2014 11:54:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ED271A0327 for ; Wed, 4 Jun 2014 11:54:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140604185425.18777.67010.idtracker@ietfa.amsl.com> Date: Wed, 04 Jun 2014 11:54:25 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/ace/J-9dW95yDwaOsc-GemJ-WkCmhHw X-Mailman-Approved-At: Wed, 04 Jun 2014 12:55:58 -0700 Subject: [Ace] State changed: charter-ietf-ace-00-06 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Authentication and Authorization for Constrained Environments $ace$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 18:54:29 -0000 State changed to External review. URL: http://datatracker.ietf.org/doc/charter-ietf-ace/ From nobody Wed Jun 4 12:56:06 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10AA61A033A; Wed, 4 Jun 2014 12:14:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 dYx3sSxFwVvt; Wed, 4 Jun 2014 12:14:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D27371A026B; Wed, 4 Jun 2014 12:14:07 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.4.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140604191407.685.47510.idtracker@ietfa.amsl.com> Date: Wed, 04 Jun 2014 12:14:07 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/ace/Z9G9guCrVuKfzlIVBPqZm6Uwczg X-Mailman-Approved-At: Wed, 04 Jun 2014 12:55:58 -0700 Cc: ace WG Subject: [Ace] WG Review: Authentication and Authorization for Constrained Environments (ace) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Authentication and Authorization for Constrained Environments $ace$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 19:14:10 -0000 A new IETF working group has been proposed in the Security Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2014-06-14. Authentication and Authorization for Constrained Environments (ace) ------------------------------------------------ Current Status: Proposed WG Chairs: Hannes Tschofenig Kepeng Li Assigned Area Director: Kathleen Moriarty Mailing list Address: ace@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ace Archive: http://www.ietf.org/mail-archive/web/ace/current/maillist.html Charter: Authentication and Authorization for Constrained Environment (ACE) The IETF has recently developed protocols for use in constrained environments, where network nodes are limited in CPU, memory and power. REST architecture is widely used for such constrained environments. It has been observed that Internet protocols can be applied to these constrained environments, often only requiring minor tweaking and profiling. In other cases, new protocols have been defined to address the specific requirements of constrained environments. An example of such a protocol is the Constrained Application Protocol (CoAP). As in other environments, authentication and authorization questions also arise in constrained environments. For example, a door lock has to authorize the person seeking access using a "digital key". Where is the authorization policy stored? How does the digital key communicate with the lock? Does the lock interact with an authorization server to obtain authorization information? How can access be temporarily granted to other persons? How can access be revoked? These types of questions have been answered by existing protocols for use cases outside constrained environments, however in constrained environments, additional and different requirements pose challenges for the use of various security protocols. In particular, the need arises for a dynamic and fine grained access control mechanism, where clients and/or resource servers are constrained. The IETF has a long history in developing three-party authentication and authorization protocols for distributed environments. Examples include Kerberos, the Public Key Infrastructure (PKI), the Authentication, Authorization and Accounting (AAA) infrastructure, and the Web Authorization Protocol (OAuth). All these protocols enjoy widespread deployment on the Internet. Although they all aim to solve a similar goal, at an abstract level, they offer quite different functions and utilize different message exchanges. These differences result from the main deployment use cases they were designed for respectively. Requirements derived from use cases may indicate that existing work is useful as basis for a solution for constrained environments. These protocols, however, were not optimized for constrained environments. Additional requirements that need to be taken into account are the lack of a suitable user-interface and the inability of embedded devices to contact an authorization server in real-time with every resource access request due to intermittent connectivity, etc. This working group therefore aims to produce a standardized solution for authentication and authorization to enable authorized access (Get, Put, Post, Delete) to resources identified by a URI and hosted on a resource server in constrained environments. As a starting point, the working group will assume that access to resources at a resource server by a client device takes place using CoAP and is protected by DTLS. Both resource server and client may be constrained. This access will be mediated by an authorization server, which is not considered to be constrained. Existing authentication and authorization protocols will be evaluated and used where applicable to build the constrained-environment solution. This requires relevant specifications to be reviewed for suitability, selecting a subset of them and restricting the options within each of the specifications. Some functionality, however, may not be available in existing protocols, in which case the solution may also involve new protocol work. Leveraging existing work means the working group benefits from available security analysis, implementation, and deployment experience. Moreover, a standardized solution for federated authentication and authorization will help to stimulate the deployment of constrained devices that provide increased security. Once progress in identifying suitable candidate solutions has been made, the working group will verify whether the same mechanisms are also applicable beyond the use of CoAP and DTLS, which are the two main protocols the group will focus on for access to resources. In particular, the ability to use the developed solution over HTTP and TLS will be investigated. Note that the initial focus is on CoAP and HTTP with DTLS and TLS. Other security protocols may be considered as long as the primary focus is maintained. The group is scoped to work only on the web protocols and data carried within them. Furthermore, to guarantee smooth transition, the integration with existing deployments will be studied, particularly concerning the use of protocol translation proxies. This work does not make the assumption that the party offering application layer services is always the same party offering network access services. The working group has the following tasks: 1) Produce use cases and requirements 2) Identify authentication and authorization mechanisms suitable for resource access in constrained environments. Milestones: Jul 2014 Submit "Use cases and Requirements" as a WG item. Dec 2014 Submit "Authentication and Authorization Solution" as a WG item. Apr 2015 Optionally, submit "Use cases and Requirements" document to the IESG for publication as an Informational RFC. Jul 2016 Submit "Authentication and Authorization Solution" specification to the IESG for publication as a Proposed Standard. From nobody Wed Jun 4 13:26:38 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70B161A02F0; Wed, 4 Jun 2014 13:26:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1DTVCfptiHHA; Wed, 4 Jun 2014 13:26:32 -0700 (PDT) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 584491A0085; Wed, 4 Jun 2014 13:26:32 -0700 (PDT) Received: by mail-ig0-f182.google.com with SMTP id a13so1503053igq.15 for ; Wed, 04 Jun 2014 13:26:26 -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; bh=T2y1ay30n2BlO5i7aEusTsh8a9iYN/KrVLDtohm+9yY=; b=ZBBRpq0qOhvK94tr2pziM9XRkK4GEVjeleZ86iSMHst9w/Lyrs941o7aFNQ+Tz48gv GY7Z0jQ/wsrBia0Y2Z89w0T1drnJ3lFVIBh2V6NBIbGAvm41rDY+xZibG+4PL1h5ZcDg AARmLzSOGbrRoC5gFul+vzvXmSJ4TmA0PVG44IdgRfUQ6nRcJYfUE4vned4RMAK9IFd4 d4KgvlOXRQHvEbiYsew79B4aLJ+rY79t9v5IPc/rUDIB/dldjwvyT9g+Vvn5Pe4YkBSL rL3DqFYlM6HbHa9LATEuZS7wtQIcFHfshU7iottpdpFpsGKo3IqQNMhkFgjLIpwE8uuB C4BQ== X-Received: by 10.50.79.131 with SMTP id j3mr11034737igx.23.1401913586054; Wed, 04 Jun 2014 13:26:26 -0700 (PDT) Received: from [192.168.1.103] (CPE0013100e2c51-CM001cea35caa6.cpe.net.cable.rogers.com. [99.231.3.110]) by mx.google.com with ESMTPSA id l5sm31669063igr.15.2014.06.04.13.26.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Jun 2014 13:26:25 -0700 (PDT) Message-ID: <538F80EC.2@gmail.com> Date: Wed, 04 Jun 2014 16:26:20 -0400 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: ietf@ietf.org, IETF-Announce References: <20140604191407.685.47510.idtracker@ietfa.amsl.com> In-Reply-To: <20140604191407.685.47510.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------000506070105050605050504" Archived-At: http://mailarchive.ietf.org/arch/msg/ace/CJbByZ6DmC39FoGQVphNOyMuFMo Cc: ace WG Subject: Re: [Ace] WG Review: Authentication and Authorization for Constrained Environments (ace) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments $ace$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 20:26:35 -0000 This is a multi-part message in MIME format. --------------000506070105050605050504 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Kathleen: I do not want to be a pain, but in the rev-06 doc the timeline is still the old one (see excerpt copied in .txt reference). I believe it should have been the one below from one of the previous messages: Dec 2014 Submit "Use cases and Requirements" as a WG item. Dec 2014 Submit "Authentication and Authorization Solution" as a WG item. Apr 2015 Optionally, submit "Use cases and Requirements" documentto the IESG for publication as an Informational RFC. Jul 2016 Submit "Authentication and Authorization Solution"specification to the IESG for publication as a Proposed Standard. Milestones (as mentioned in http://www.ietf.org/charter/charter-ietf-ace-00-06.txt): Jul 2014 Submit "Use cases and Requirements" as a WG item. Dec 2014 Submit "Authentication and Authorization Solution" as a WG item. Apr 2015 Optionally, submit "Use cases and Requirements" document to the IESG for publication as an Informational RFC. Jul 2016 Submit "Authentication and Authorization Solution" specification to the IESG for publication as a Proposed Standard. On 6/4/2014 3:14 PM, The IESG wrote: > A new IETF working group has been proposed in the Security Area. The IESG > has not made any determination yet. The following draft charter was > submitted, and is provided for informational purposes only. Please send > your comments to the IESG mailing list (iesg at ietf.org) by 2014-06-14. > > Authentication and Authorization for Constrained Environments (ace) > ------------------------------------------------ > Current Status: Proposed WG > > Chairs: > Hannes Tschofenig > Kepeng Li > > Assigned Area Director: > Kathleen Moriarty > > Mailing list > Address: ace@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/ace > Archive: http://www.ietf.org/mail-archive/web/ace/current/maillist.html > > Charter: > > Authentication and Authorization for Constrained > Environment (ACE) > > The IETF has recently developed protocols for use in constrained > environments, where network nodes are limited in CPU, memory and power. > REST architecture is widely used for such constrained environments. > It has been observed that Internet protocols can be applied to these > constrained environments, often only requiring minor tweaking and > profiling. In other cases, new protocols have been defined to address > the specific requirements of constrained environments. An example of > such a protocol is the Constrained Application Protocol (CoAP). > > As in other environments, authentication and authorization questions > also arise in constrained environments. For example, a door lock has to > authorize the person seeking access using a "digital key". Where is the > authorization policy stored? How does the digital key communicate with > the lock? Does the lock interact with an authorization server to obtain > authorization information? How can access be temporarily granted to > other persons? How can access be revoked? These types of questions have > been answered by existing protocols for use cases outside constrained > environments, however in constrained environments, additional and > different requirements pose challenges for the use of various security > protocols. In particular, the need arises for a dynamic and fine grained > access control mechanism, where clients and/or resource servers are > constrained. > > The IETF has a long history in developing three-party authentication and > authorization protocols for distributed environments. Examples include > Kerberos, the Public Key Infrastructure (PKI), the Authentication, > Authorization and Accounting (AAA) infrastructure, and the Web > Authorization Protocol (OAuth). All these protocols enjoy widespread > deployment on the Internet. Although they all aim to solve a similar > goal, at an abstract level, they offer quite different functions and > utilize different message exchanges. These differences result from the > main deployment use cases they were designed for respectively. > > Requirements derived from use cases may indicate that existing work is > useful as basis for a solution for constrained environments. These > protocols, however, were not optimized for constrained environments. > Additional requirements that need to be taken into account are the lack > of a suitable user-interface and the inability of embedded devices to > contact an authorization server in real-time with every resource access > request due to intermittent connectivity, etc. > > This working group therefore aims to produce a standardized solution for > authentication and authorization to enable authorized access (Get, Put, > Post, Delete) to resources identified by a URI and hosted on a resource > server in constrained environments. As a starting point, the working > group will assume that access to resources at a resource server by a > client device takes place using CoAP and is protected by DTLS. Both > resource server and client may be constrained. This access will be > mediated by an authorization server, which is not considered to be > constrained. > > Existing authentication and authorization protocols will be evaluated > and used where applicable to build the constrained-environment solution. > This requires relevant specifications to be reviewed for suitability, > selecting a subset of them and restricting the options within each of > the specifications. Some functionality, however, may not be available in > existing protocols, in which case the solution may also involve new > protocol work. Leveraging existing work means the working group benefits > from available security analysis, implementation, and deployment > experience. Moreover, a standardized solution for federated > authentication and authorization will help to stimulate the deployment > of constrained devices that provide increased security. > > Once progress in identifying suitable candidate solutions has been made, > the working group will verify whether the same mechanisms are also > applicable beyond the use of CoAP and DTLS, which are the two main > protocols the group will focus on for access to resources. In > particular, the ability to use the developed solution over HTTP and TLS > will be investigated. Note that the initial focus is on CoAP and HTTP > with DTLS and TLS. Other security protocols may be considered as long as > the primary focus is maintained. The group is scoped to work only on the > web protocols and data carried within them. Furthermore, to guarantee > smooth transition, the integration with existing deployments will be > studied, particularly concerning the use of protocol translation > proxies. > > This work does not make the assumption that the party offering > application layer services is always the same party offering network > access services. > > The working group has the following tasks: > > 1) Produce use cases and requirements > > 2) Identify authentication and authorization mechanisms suitable for > resource access in constrained environments. > > Milestones: > > Jul 2014 Submit "Use cases and Requirements" as a WG item. > Dec 2014 Submit "Authentication and Authorization Solution" as a WG > item. > Apr 2015 Optionally, submit "Use cases and Requirements" document to the > IESG for publication as an Informational RFC. > Jul 2016 Submit "Authentication and Authorization Solution" > specification to the IESG for publication as a Proposed > Standard. > -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 --------------000506070105050605050504 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Kathleen:

I do not want to be a pain, but in the rev-06 doc the timeline is still the old one (see excerpt copied in .txt reference). I believe it should have been the one below from one of the previous messages:

Dec 2014 Submit "Use cases and Requirements" as a WG item.

Dec 2014 Submit "Authentication and Authorization Solution" as a WG item.

Apr 2015 Optionally, submit "Use cases and Requirements" document to the IESG for publication as an Informational RFC.

Jul 2016 Submit "Authentication and Authorization Solution" specification to the IESG for publication as a Proposed Standard.

Milestones (as mentioned in http://www.ietf.org/charter/charter-ietf-ace-00-06.txt): Jul 2014 Submit "Use cases and Requirements" as a WG item. Dec 2014 Submit "Authentication and Authorization Solution" as a WG item. Apr 2015 Optionally, submit "Use cases and Requirements" document to the IESG for publication as an Informational RFC. Jul 2016 Submit "Authentication and Authorization Solution" specification to the IESG for publication as a Proposed Standard.

On 6/4/2014 3:14 PM, The IESG wrote:

A new IETF working group has been proposed in the Security Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2014-06-14. Authentication and Authorization for Constrained Environments (ace) ------------------------------------------------ Current Status: Proposed WG Chairs: Hannes Tschofenig <Hannes.Tschofenig@gmx.net> Kepeng Li <likepeng@huawei.com> Assigned Area Director: Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com> Mailing list Address: ace@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ace Archive: http://www.ietf.org/mail-archive/web/ace/current/maillist.html Charter: Authentication and Authorization for Constrained Environment (ACE) The IETF has recently developed protocols for use in constrained environments, where network nodes are limited in CPU, memory and power. REST architecture is widely used for such constrained environments. It has been observed that Internet protocols can be applied to these constrained environments, often only requiring minor tweaking and profiling. In other cases, new protocols have been defined to address the specific requirements of constrained environments. An example of such a protocol is the Constrained Application Protocol (CoAP). As in other environments, authentication and authorization questions also arise in constrained environments. For example, a door lock has to authorize the person seeking access using a "digital key". Where is the authorization policy stored? How does the digital key communicate with the lock? Does the lock interact with an authorization server to obtain authorization information? How can access be temporarily granted to other persons? How can access be revoked? These types of questions have been answered by existing protocols for use cases outside constrained environments, however in constrained environments, additional and different requirements pose challenges for the use of various security protocols. In particular, the need arises for a dynamic and fine grained access control mechanism, where clients and/or resource servers are constrained. The IETF has a long history in developing three-party authentication and authorization protocols for distributed environments. Examples include Kerberos, the Public Key Infrastructure (PKI), the Authentication, Authorization and Accounting (AAA) infrastructure, and the Web Authorization Protocol (OAuth). All these protocols enjoy widespread deployment on the Internet. Although they all aim to solve a similar goal, at an abstract level, they offer quite different functions and utilize different message exchanges. These differences result from the main deployment use cases they were designed for respectively. Requirements derived from use cases may indicate that existing work is useful as basis for a solution for constrained environments. These protocols, however, were not optimized for constrained environments. Additional requirements that need to be taken into account are the lack of a suitable user-interface and the inability of embedded devices to contact an authorization server in real-time with every resource access request due to intermittent connectivity, etc. This working group therefore aims to produce a standardized solution for authentication and authorization to enable authorized access (Get, Put, Post, Delete) to resources identified by a URI and hosted on a resource server in constrained environments. As a starting point, the working group will assume that access to resources at a resource server by a client device takes place using CoAP and is protected by DTLS. Both resource server and client may be constrained. This access will be mediated by an authorization server, which is not considered to be constrained. Existing authentication and authorization protocols will be evaluated and used where applicable to build the constrained-environment solution. This requires relevant specifications to be reviewed for suitability, selecting a subset of them and restricting the options within each of the specifications. Some functionality, however, may not be available in existing protocols, in which case the solution may also involve new protocol work. Leveraging existing work means the working group benefits from available security analysis, implementation, and deployment experience. Moreover, a standardized solution for federated authentication and authorization will help to stimulate the deployment of constrained devices that provide increased security. Once progress in identifying suitable candidate solutions has been made, the working group will verify whether the same mechanisms are also applicable beyond the use of CoAP and DTLS, which are the two main protocols the group will focus on for access to resources. In particular, the ability to use the developed solution over HTTP and TLS will be investigated. Note that the initial focus is on CoAP and HTTP with DTLS and TLS. Other security protocols may be considered as long as the primary focus is maintained. The group is scoped to work only on the web protocols and data carried within them. Furthermore, to guarantee smooth transition, the integration with existing deployments will be studied, particularly concerning the use of protocol translation proxies. This work does not make the assumption that the party offering application layer services is always the same party offering network access services. The working group has the following tasks: 1) Produce use cases and requirements 2) Identify authentication and authorization mechanisms suitable for resource access in constrained environments. Milestones: Jul 2014 Submit "Use cases and Requirements" as a WG item. Dec 2014 Submit "Authentication and Authorization Solution" as a WG item. Apr 2015 Optionally, submit "Use cases and Requirements" document to the IESG for publication as an Informational RFC. Jul 2016 Submit "Authentication and Authorization Solution" specification to the IESG for publication as a Proposed Standard.

-- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
--------------000506070105050605050504-- From nobody Thu Jun 5 05:47:12 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ACB01A0092 for ; Thu, 5 Jun 2014 05:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 Cukx7wSY4d7e for ; Thu, 5 Jun 2014 05:47:06 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 124901A008D for ; Thu, 5 Jun 2014 05:47:05 -0700 (PDT) X-AuditID: c1b4fb30-f79a56d000006536-de-539066c16643 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 67.CB.25910.1C660935; Thu, 5 Jun 2014 14:46:58 +0200 (CEST) Received: from ESESSMB303.ericsson.se ([169.254.3.215]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0174.001; Thu, 5 Jun 2014 14:26:02 +0200 From: =?iso-8859-1?Q?G=F6ran_Selander?= To: Carsten Bormann , Rene Struik Thread-Topic: [Ace] Security Domains Thread-Index: AQHPfxfpKrDYTz7JGUKKZUdu4LTXuZtfRkGAgAAGsoCAAyd7AA== Date: Thu, 5 Jun 2014 12:26:01 +0000 Message-ID: References: <538DA583.4070200@tzi.de> <538DD2FD.2020400@gmail.com> <521AAE69-A9C5-4EF9-BD11-86A6AE06A0DA@tzi.org> In-Reply-To: <521AAE69-A9C5-4EF9-BD11-86A6AE06A0DA@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <19E30630B39CE84D9F257F8BBDE4F6E1@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMIsWRmVeSWpSXmKPExsUyM+Jvje6htAnBBn/6BCy+f+thtjgy5S6r xcaLdxktVt94zuLA4rFz1l12jyVLfjJ5bHv7ldlj2qLMAJYoLpuU1JzMstQifbsEroylL7+y FrwQr7jYs4OpgfG8cBcjB4eEgInE4UMxXYycQKaYxIV769m6GLk4hASOMkp0P7rJDOEsZpTo n7uFDaSKTcBV4sCDd0wgtoiAu8SdBysYQQYxCzhJtHyXAgkLCyhLfH+xgRmiREVi4vZVrBC2 k8SLw/fYQWwWoPjf5dPB4rwCFhJHHl0CGy8kUCzx+8UqFhCbU8Ba4t6THYwgNiPQcd9PrQFb yywgLnHryXwmiKMFJJbsOc8MYYtKvHz8D2ymqICexLvjMDVKEotuf4bq1ZO4MXUKG4RtLXH0 +2VGCFtbYtnC18wQ9whKnJz5hGUCo8QsJOtmIWmfhaR9FpL2WUjaFzCyrmIULU4tTspNNzLS Sy3KTC4uzs/Ty0st2cQIjNWDW34b7GB8+dzxEKMAB6MSD++CuP5gIdbEsuLK3EOM0hwsSuK8 FzWqg4UE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwOj+cufp69+tvm7Ze93yq0dS8I9drxl72 y1MfJH1tubDX80bg5Su9LNoqRnxGlyx+r9jb+c47oq9X0v1cxrx1GZHZn6q/CFyIWPHyr8fq NcmLVxnNl5nW9NTosKGK09XZVs+nrXp57Pw9k/yjPvuTXnBozVGtXRnI1iM1xVT63+OUlwVm XP+3LVJiKc5INNRiLipOBADQP3ULtgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/ace/1eeX-23X49yjAfmcywXheIeUH1Q Cc: Stefanie Gerdes , "ace@ietf.org" Subject: Re: [Ace] Security Domains X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments $ace$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 12:47:08 -0000 On 03/06/14 16:15, "Carsten Bormann" wrote: >On 03 Jun 2014, at 15:51, Rene Struik wrote: > >> I did not really get yet what the disagreement is about, so maybe >> someone can help me with that. > >Here in Stockholm there was a relatively extended discussion whether it >is worth to separate the client owner and the resource owner function in >the architecture and analogously separate out the Authorization Manager >(less-constrained counterpart of the client) from the Authorization >Server (less-constrained counterpart of the resource server). As Carsten said, and please note that this was not just a discussion of single-owner/domain vs. multi-owner/domain. This was also a discussion of three-party vs four-party architecture. You may support the assumption of multiple domains/owners without supporting the Authorization Manager (AM) as a fourth node of the ACE architecture. The role of the AM is to somehow support a constrained client in the client domain. But none of the currently included use cases illustrate the situation of (I) client and resource server in different domains AND (II) the client being constrained. For example, in the case of light switches and light bulbs, those are typically part of the same domain. If you allow your guests to turn on lights in your home with their own device, that device is typically something like a smartphone and not constrained. Now, if the client and resource server are in the same domain, whatever functionality the AM supports the client with, it could be subsumed by the AS. If the client is not constrained, then it can perform the functionality itself. So, do we need the AM in the architecture? The are other use cases, e.g. during commissioning of a lightning system, when ownership is being transferred from manufacturer of light switch to the owner of the building. It was discussed whether this is the initial scope for ACE and if so, whether that motivates a fourth node in the architecture.=20 (This is not trying to recap the whole discussion, just providing some more context.) G=F6ran > >http://tools.ietf.org/html/draft-gerdes-ace-actors takes the view that >this exercise is worthwhile. > >Obviously, this is an architectural model and does not say anything how >these functions are mapped to specific devices in a specific deployment. >If you don=B9t separate out the functions in the architecture, I believe >the result will be single-owner thinking and it will be very hard to >later address the multiple-owner aspect that is so central to the >Internet of Things idea. Others believe that initial deployments will >all be single-owner and it will be hard to drum up input to an >architecture enabled for multiple owners, but it will be relatively easy >to extend the single-owner architecture later. > >Gr=FC=DFe, Carsten > >_______________________________________________ >Ace mailing list >Ace@ietf.org >https://www.ietf.org/mailman/listinfo/ace From nobody Thu Jun 5 07:33:34 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A957C1A0175 for ; Thu, 5 Jun 2014 07:33:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.251 X-Spam-Level: X-Spam-Status: No, score=-1.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, SPF_HELO_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 YYjf4lAtk9FP for ; Thu, 5 Jun 2014 07:33:30 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C66681A016E for ; Thu, 5 Jun 2014 07:33:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s55EXAKl025438; Thu, 5 Jun 2014 16:33:10 +0200 (CEST) Received: from [134.102.218.214] (dynamic-218-o.informatik.uni-bremen.de [134.102.218.214]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 936C117D5; Thu, 5 Jun 2014 16:33:10 +0200 (CEST) Message-ID: <53907FA6.5040801@tzi.de> Date: Thu, 05 Jun 2014 16:33:10 +0200 From: Stefanie Gerdes User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?G=F6ran_Selander?= , Carsten Bormann , Rene Struik References: <538DA583.4070200@tzi.de> <538DD2FD.2020400@gmail.com> <521AAE69-A9C5-4EF9-BD11-86A6AE06A0DA@tzi.org> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/ace/x7as_5fWuvBp_pEi8zNCVf_Z0GE Cc: "ace@ietf.org" Subject: Re: [Ace] Security Domains X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments $ace$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 14:33:31 -0000 Hi, On 06/05/2014 02:26 PM, G�ran Selander wrote: > > > On 03/06/14 16:15, "Carsten Bormann" wrote: > >> On 03 Jun 2014, at 15:51, Rene Struik wrote: >> >>> I did not really get yet what the disagreement is about, so maybe >>> someone can help me with that. >> >> Here in Stockholm there was a relatively extended discussion whether it >> is worth to separate the client owner and the resource owner function in >> the architecture and analogously separate out the Authorization Manager >> (less-constrained counterpart of the client) from the Authorization >> Server (less-constrained counterpart of the resource server). > > As Carsten said, and please note that this was not just a discussion of > single-owner/domain vs. multi-owner/domain. This was also a discussion of > three-party vs four-party architecture. You may support the assumption of > multiple domains/owners without supporting the Authorization Manager (AM) > as a fourth node of the ACE architecture. In the actors draft, the AM is not a node but an actor. An actor is a set of certain tasks and characteristics. AM's characteristic is that it belongs to C's owner (CO). Its task is to safeguards CO's interests. It does that by determining if RS is an authorized source for R and aiding C in the authentication of RS. For C, AM is the authority for claims about RS. > > The role of the AM is to somehow support a constrained client in the > client domain. But none of the currently included use cases illustrate the > situation of (I) client and resource server in different domains AND (II) > the client being constrained. For example, in the case of light switches > and light bulbs, those are typically part of the same domain. If you allow > your guests to turn on lights in your home with their own device, that > device is typically something like a smartphone and not constrained. I don't think the use cases document states that clearly which devices are constrained and which are not. In many cases it depends on how things are built. In the home automation use case, Jeffrey might use a key-thing to enter Jane's house. In the container use case, the sensors in the container might communicate directly with the cooling system of the ship. In the health monitoring system, the emergency physician might have a sensor to check John's body functions. I don't understand why we would want to rule out scenarios where both devices are constrained and belong to different security domains. > > Now, if the client and resource server are in the same domain, whatever > functionality the AM supports the client with, it could be subsumed by the > AS. If the client is not constrained, then it can perform the > functionality itself. So, do we need the AM in the architecture? > > The are other use cases, e.g. during commissioning of a lightning system, > when ownership is being transferred from manufacturer of light switch to > the owner of the building. It was discussed whether this is the initial > scope for ACE and if so, whether that motivates a fourth node in the > architecture. Even if commissioning is not in scope for ACE it seems useful to me to have a solution which can be used for both instead of inventing two different mechanisms. But maybe there is a good reason for this that I just didn't understand yet. What do we gain from restricting the scenarios and not supporting multi-domain constrained device to constrained device communication? Best regards, Steffi From nobody Sun Jun 8 22:41:57 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 334451B27E3 for ; Sun, 8 Jun 2014 22:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 5JR1_2LGvA-5 for ; Sun, 8 Jun 2014 22:41:52 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8D0D1B27E4 for ; Sun, 8 Jun 2014 22:41:51 -0700 (PDT) X-AuditID: c1b4fb30-f79a56d000006536-a5-5395491eb1ae Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id C4.F6.25910.E1945935; Mon, 9 Jun 2014 07:41:50 +0200 (CEST) Received: from ESESSMB303.ericsson.se ([169.254.3.215]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0174.001; Mon, 9 Jun 2014 07:41:49 +0200 From: =?iso-8859-1?Q?G=F6ran_Selander?= To: Stefanie Gerdes , Carsten Bormann , "Rene Struik" Thread-Topic: [Ace] Security Domains Thread-Index: AQHPfxfpKrDYTz7JGUKKZUdu4LTXuZtfRkGAgAAGsoCAAyd7AIAAAgAAgAXWYgA= Date: Mon, 9 Jun 2014 05:41:48 +0000 Message-ID: References: <538DA583.4070200@tzi.de> <538DD2FD.2020400@gmail.com> <521AAE69-A9C5-4EF9-BD11-86A6AE06A0DA@tzi.org> <53907FA6.5040801@tzi.de> In-Reply-To: <53907FA6.5040801@tzi.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGIsWRmVeSWpSXmKPExsUyM+Jvja6c59Rgg96bwhbfv/UwWxyZcpfV YuPFu4wWq288Z3Fg8dg56y67x5IlP5k8tr39yuwxbVFmAEsUl01Kak5mWWqRvl0CV8aMgy0s BT8NKr43/GNrYNyp3sXIySEhYCKx4fcCRghbTOLCvfVsXYxcHEICRxkltnzexgThLGaU6JwM 4nBysAm4Shx48A7MFhHIkbi14hMbiM0soCixbk4fWFxYQFni+4sNzBA1KhITt69ihbD9JP68 b2AHsVmA4p1LPoJt5hWwkGiZfJEZYtkeRol5a5vBGjgF1CTmH5wLVsQIdN73U2uYIJaJS9x6 Mp8J4mwBiSV7zjND2KISLx//A+sVFdCTeHccpkZJYsX2S4wQvXoSN6ZOgTraWmLxv1PsELa2 xLKFr5khDhKUODnzCcsERolZSNbNQtI+C0n7LCTts5C0L2BkXcUoWpxanJSbbmSkl1qUmVxc nJ+nl5dasokRGLEHt/w22MH48rnjIUYBDkYlHl4F0anBQqyJZcWVuYcYpTlYlMR5L2pUBwsJ pCeWpGanphakFsUXleakFh9iZOLglGpgdI2o1F6SXP7SzbV8XtYir479UlqOAglaMzm2Cb/6 bXilcPkOl11vYm4LyM1+dSrEWTypQ+HawwnaxxxOnK7/eHqNY951FZd7Jd+3T66a0rH2eY0l e3WH7CqTK09+pb/065quNeHy94TqUFFvrZg239QDuYoVjO0Rmddby45eyStIu7XD/aaoEktx RqKhFnNRcSIA7pp0LLkCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/ace/5aP6xv79cjWAO0uJi_qMvHxFDtQ Cc: "ace@ietf.org" Subject: Re: [Ace] Security Domains X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments $ace$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 05:41:55 -0000 Hi Steffi, Thanks. We saw this discussion coming when we prepared the BOF in London. Now that the charter has come further it is good that we try to sort out the arguments and move forward. On 05/06/14 16:33, "Stefanie Gerdes" wrote: >Hi, > >On 06/05/2014 02:26 PM, G=F6ran Selander wrote: >>=20 >>=20 >> On 03/06/14 16:15, "Carsten Bormann" wrote: >>=20 >>> On 03 Jun 2014, at 15:51, Rene Struik wrote: >>> >>>> I did not really get yet what the disagreement is about, so maybe >>>> someone can help me with that. >>> >>> Here in Stockholm there was a relatively extended discussion whether it >>> is worth to separate the client owner and the resource owner function >>>in >>> the architecture and analogously separate out the Authorization Manager >>> (less-constrained counterpart of the client) from the Authorization >>> Server (less-constrained counterpart of the resource server). >>=20 >> As Carsten said, and please note that this was not just a discussion of >> single-owner/domain vs. multi-owner/domain. This was also a discussion >>of >> three-party vs four-party architecture. You may support the assumption >>of >> multiple domains/owners without supporting the Authorization Manager >>(AM) >> as a fourth node of the ACE architecture. > >In the actors draft, the AM is not a node but an actor. An actor is a >set of certain tasks and characteristics. AM's characteristic is that it >belongs to C's owner (CO). Its task is to safeguards CO's interests. It >does that by determining if RS is an authorized source for R and aiding >C in the authentication of RS. For C, AM is the authority for claims >about RS. Agreed, AM is not a node. To me, an actor is a business entity taking a CO or RO role, but let=B9s not get into words. I understand that AM represents some function. One problem I have is to understand the function of AM consistently described in the different cases where 1. AM is stand-alone 2. AM and C are co-located, and 3. AM and AS are co-located For example =B3aiding C in the authentication of RS=B2: If AM is standalone, I take it is not directly authenticating the RS, but rather authenticating to the AS somehow on behalf of C. In this case C would have to prove to RS that it is in the domain of CO to benefit from the authentication (and authorisation) made for AM by AS. If AM and C are co-located, authenticating on behalf of C would be an unnecessary indirection. If AM and AS are co-located, AM does not have this functionality at all, or does it? > >>=20 >> The role of the AM is to somehow support a constrained client in the >> client domain. But none of the currently included use cases illustrate >>the >> situation of (I) client and resource server in different domains AND >>(II) >> the client being constrained. For example, in the case of light switches >> and light bulbs, those are typically part of the same domain. If you >>allow >> your guests to turn on lights in your home with their own device, that >> device is typically something like a smartphone and not constrained. > >I don't think the use cases document states that clearly which devices >are constrained and which are not. In many cases it depends on how >things are built. In the home automation use case, Jeffrey might use a >key-thing to enter Jane's house. In the container use case, the sensors >in the container might communicate directly with the cooling system of >the ship. In the health monitoring system, the emergency physician might >have a sensor to check John's body functions. You are right that some use cases could be realized with constrained clients in other domain than resource server. And there is nothing wrong with such a problem statement execpt that I am not aware that we have specifically addressed such use cases. > >I don't understand why we would want to rule out scenarios where both >devices are constrained and belong to different security domains. YMMV, but I find the four-party architecture more complicated than the three-party, since we may need to consider protocols between more parties. If we can address the use cases in scope with a three-party (multi-owner) architecture I think this would be an advantage. I believe we could consider other support functionality appearing in some use cases, rather than having a permanent =B3actor=B2 making the simple use cases more complicated. > >>=20 >> Now, if the client and resource server are in the same domain, whatever >> functionality the AM supports the client with, it could be subsumed by >>the >> AS. If the client is not constrained, then it can perform the >> functionality itself. So, do we need the AM in the architecture? >>=20 >> The are other use cases, e.g. during commissioning of a lightning >>system, >> when ownership is being transferred from manufacturer of light switch to >> the owner of the building. It was discussed whether this is the initial >> scope for ACE and if so, whether that motivates a fourth node in the >> architecture.=20 > >Even if commissioning is not in scope for ACE it seems useful to me to >have a solution which can be used for both instead of inventing two >different mechanisms. I am not saying that we should exclude commissioning, or that commissioning necessitates an AM. We have said that we should exclude certain key provisioning such as how the AS and RS establishes keys. During this process some commissioning may as well take place, and thus seems unnecessary to have a use case for. > >But maybe there is a good reason for this that I just didn't understand >yet. What do we gain from restricting the scenarios and not supporting >multi-domain constrained device to constrained device communication? IMHO, we gain simplicity by leaving out the AM, and then we don=B9t have to work out the different cases where AM functionality is stand-alone or coinciding with some other function. Best regards G=F6ran > >Best regards, >Steffi > >_______________________________________________ >Ace mailing list >Ace@ietf.org >https://www.ietf.org/mailman/listinfo/ace From nobody Tue Jun 10 14:40:38 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77FCA1A02FC; Tue, 10 Jun 2014 14:40:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=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 bu-h8VgZe1HV; Tue, 10 Jun 2014 14:40:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 90DB01A02C6; Tue, 10 Jun 2014 14:40:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140610214034.13525.18350.idtracker@ietfa.amsl.com> Date: Tue, 10 Jun 2014 14:40:34 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/ace/rzruRO1pGmyZwuxp2dsSxD0U5cg Cc: ace@ietf.org Subject: [Ace] Kathleen Moriarty's Yes on charter-ietf-ace-00-06 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Authentication and Authorization for Constrained Environments $ace$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 21:40:35 -0000 Kathleen Moriarty has entered the following ballot position for charter-ietf-ace-00-06: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/charter-ietf-ace/ There are no remarks associated with this position. From nobody Tue Jun 10 17:48:04 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA4B31A02C7; Tue, 10 Jun 2014 14:21:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.522 X-Spam-Level: * X-Spam-Status: No, score=1.522 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, 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 zw3BLi_mTpUE; Tue, 10 Jun 2014 14:21:22 -0700 (PDT) Received: from mail-ve0-x230.google.com (mail-ve0-x230.google.com [IPv6:2607:f8b0:400c:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C39BF1A02C6; Tue, 10 Jun 2014 14:21:21 -0700 (PDT) Received: by mail-ve0-f176.google.com with SMTP id db12so6053079veb.7 for ; Tue, 10 Jun 2014 14:21:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MIncnq8sQIs7wApfWhyJ1pDH3g44HBtTe1VPntgmmIY=; b=RmQ163Kb1LdwnqbGkLCTHOT5nEJK5pSKnyvSe7gUlIHdaUsfIzYbgNvlAk9qJTuMrm kvMPZJS5K8fot0mmIQTPcLrPuMfUiCc+txP21GjjiqjgB4xy7el0jFXsDkLsB6i25m49 EHelGRsh9+YUfGKdUn1Cg/OtuMvFGgs7uAXLiLI1UQ4hcq9Nv0s9UL9LgU2GZgs9Lz2r 3Wb8hbhync1NgyIC5xgFmmLYFZQy7GN/azrII2s1buskHWEsnavoL5cTV6B2YLSy1M/y UVbXyOBIVEAZolR95qeskC4QFtPiR1uVHHYUp3CfrBbKIlt71foPRIB0r7EcjXgT4mRT DgmA== MIME-Version: 1.0 X-Received: by 10.221.20.199 with SMTP id qp7mr35108377vcb.24.1402435280720; Tue, 10 Jun 2014 14:21:20 -0700 (PDT) Received: by 10.221.16.3 with HTTP; Tue, 10 Jun 2014 14:21:20 -0700 (PDT) In-Reply-To: References: Date: Wed, 11 Jun 2014 00:21:20 +0300 Message-ID: From: Ines Robles To: ietf Content-Type: multipart/alternative; boundary=001a11339e2eba82fc04fb81e825 Archived-At: http://mailarchive.ietf.org/arch/msg/ace/UtSGnjV-mr97lE_xf-rohRdFmNc X-Mailman-Approved-At: Tue, 10 Jun 2014 17:48:01 -0700 Cc: "ipv6@ietf.org" , 6tisch-security@ietf.org, lwip@ietf.org, roll , ace@ietf.org, dtls-iot@ietf.org, Xavier Vilajosana , coman@ietf.org, core@ietf.org, 6lo@ietf.org, "6tisch@ietf.org" <6tisch@ietf.org> Subject: Re: [Ace] LLN Plugfest at IETF 90 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments $ace$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 21:21:25 -0000 --001a11339e2eba82fc04fb81e825 Content-Type: text/plain; charset=UTF-8 Dear all, This is a kindly reminder :-) . We call for participants. The deadline to receive topics to present or demonstrate in the event is 06/20/2014 :-). Interested audience is also welcome and we encourage audience to participate in the feedback session. More information: https://bitbucket.org/6tisch/meetings/wiki/140720a_ietf90_toronto_plugfest We hope to see you there! Xavier and Ines. 2014-06-02 1:02 GMT+03:00 Ines Robles : > Dear all, > > We would like to announce the plugfest event at the 90th IETF Meeting in > Toronto. > > We call for participants. The deadline to receive topics to present or > demonstrate in the event is 06/13/2014. Interested audience is also welcome > and we encourage audience to participate in the feedback session. > > Please find next the plugfest information. > > We hope to see you there! > > Xavier and Ines. > > ----------------------- > Low Power and Lossy Networks plugfest at IETF90 > > The IETF 6TiSCH , IETF > 6lo and IETF ROLL > working groups are > hosting an informal "plugfest" event at the IETF90 meeting, in Toronto, CA, > during the week of July 20-25 2014. > Goals > > The goal of this event is to bring together people interested in hands-on > experience around the technology developed by the 6TiSCH, 6lo and ROLL > working groups, with a particular focus on the TSCH mode of IEEE802.15.4e, > 6lowpan, RPL and new WG specifications. > When and where ? > > - *Date*: Sunday July 20 2014, 0900-1300 EDT. > - *Location*: Meeting Room TBD, Fairmont Royal York Hotel 100 Front > Street W, Toronto, CA. > > *Early access: TBD if the plugfest room will be open starting 8am EDT on > Sunday 20 2014 to allow people to set up.* > Topology proposed - TBD > > - Star topology > - IPv6 > > Complementary angles > > This event will feature the following complementary angles: > > - Interoperation > - Demonstration > - Tools > > Focus 1: Interoperation > > Download the interoperation guidelines: > > - - TBD for Toronto - interoperation guidelines, version 1 (London) > > > The goal is to achieve interoperation between different hardware and > software implementations on the different aspects addressed by 6lo, 6TiSCH > and ROLL WGs. This include 6TiSCH minimal draft implementation, > demonstrating TSCH synchronization and OF0 for RPL on a minimal network. > 6lowpan to demostrate cross link layer inter-operability by means of > bridges or backbones routers. Storing and non-storing RPL implementation > including its coexistance in different sub-networks. > > The focus during this event is open to demonstrating 6lo, ROLL or 6TiSCH > drafts implementations, including but not limited to: e.g. - 6TiSCH minimal > draft: http://tools.ietf.org/html/draft-ietf-6tisch-minimal-00. - TBD > > Participants are encouraged to bring devices which implement parts or all > of the listed drafts. > > Levels of interoperation are proposed: > > - *Level 1*, star topology. A single BBR devices acts as the time > source neighbor for all other nodes. Nodes need to demonstrate frame-based > and acknowledgement-based synchronization. The static TSCH schedule, as > well as all slot timings are taken from draft-ietf-6tisch-minimal-00. > - *Level 2*, multi-hop topology. This level builds upon level 1. The > goal of this level is full compliance to draft-ietf-6tisch-minimal-00, > including multi-hop routing (RPL). > - *Level 3*, on-the-fly scheduling. [optional] Preliminary > implementations of > http://tools.ietf.org/html/draft-dujovne-6tisch-on-the-fly can be > shown. > - *Level 4*, drafts from ROLL, such as: > draft-ietf-roll-mpl-parameter-configuration, > draft-ko-roll-mix-network-pathology, Opportunistic routing, selective DIS, > and others that participants want to show > - *Level 5*, drafts from 6lo, such as: draft-ietf-6lo-btle, > draft-ietf-6lo-ghc,draft-ietf-6lo-lowpanz, and others that participants > want to show. > - *Level 6* Other drafts, such as > draft-thubert-6man-flow-label-for-rpl, etc. > > Focus 2: Demonstration > > Participants are encouraged to bring devices and technology based on > 6TiSCH, 6lo and ROLL which they believe can be of interest for the other > participants. These devices may or may not participate in the > interoperation event. Demonstration of more complete systems are > encouraged, for example systems which show the interconnection of a 6TiSCH > based mesh to traditional networks. > Focus 3: Tools > > Participants are encouraged to bring and present different tools developed > around 6TiSCH/6lo/ROLL networks. Possible tools include, but are not > limited to: > > - acquisition devices (i.e. "sniffers") > - packet analysis tools (e.g. Wireshark) > - simulation/emulation platforms > > Important Dates > > The preparation of this event will be held during a portion of the > bi-weekly 6TiSCH call (*To Be Decided how and when!!!*). In particular: > > - *06/02/2014* Announcement of the plugfest event to the WG/ML related > with constrained devices, such as: 6tisch, 6lo, roll, core, lwig, dtls-iot, > coman, ace, etc. > - *06/06/2014* Adoption of the plugfest call by the WGs, and call for > participants at each group. > - *06/02/2014-06/13/2014* Participants have contacted the plugfest > chairs (Xavier or Ines) with a tentative description of what they wish to > participate in. > - *06/20/2014* Synchronization point 1. Participants can share the > state of advancement of the implementation and raise blocking points. > - *07/11/2014* Synchronization point 2. Participants can share the > state of advancement of the implementation and raise blocking points. > - *07/20/2014*. Plugfest at IETF90. > > Tentative Agenda from 9:00 to 13:00 > > - *[09.00]* Welcome and Initial Instructions > - *[09.05]* Participants Pitch (5 min per Participant) > - *[09.45]* Participants Pitch Tools (5 min per Participant) > - *[10.15]* Interoperation (Islands) > - *[11.50]* Feedback and open discussion. > - *[12.40]* Acknowledgements and Plugfest End > > For More Information > > - *Contact*: Xavi Vilajosana xvilajosana@eecs.berkeley.edu - Ines > Robles mariainesrobles@gmail.com > > Note Well > > This event is organized as part of the IETF90 standardization meeting. You > need to register to the IETF90 conference to be able to participate. Daily > passes are available. The IETF Note Well applies to this plugfest, see > http://www.ietf.org/about/note-well.html. > About > > The IETF 6TiSCH working group standardizes mechanisms focusing on enabling > IPv6 over the TSCH mode of the IEEE802.15.4e standard. You can access the > charter at http://datatracker.ietf.org/wg/6tisch/charter/, which also > contains links to the mailing list and the Internet-Drafts published by the > group. 6TiSCH holds weekly phone calls on Friday 8am PST. Participation is > open, and is subject to the IETF Note Well. > > The IETF 6lo working group focuses on the work that facilitates IPv6 > connectivity over constrained node networks with the characteristics of: > limited power, memory and processing resources;. You can access the charter > at https://datatracker.ietf.org/wg/6lo/charter/, which also contains > links to the mailing list and the I-D published by the group. > > The IETF ROLL working group is focused on routing issues for LLN (Low > Power and Lossy Networks), in IPv6 routing architectural framework for the > industrial, connected home, building and urban sensor networks application > scenarios. You can access the charter at > https://datatracker.ietf.org/wg/roll/charter/, which also contains links > to the mailing list and the I-D published by the group. > --001a11339e2eba82fc04fb81e825 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear all,

This is a kindly reminder :-)= .

We call for participants. The deadline to receive = topics to present or demonstrate in the event is 06/20/2014 :-). Interested= audience is also welcome and we encourage audience to participate in the f= eedback session.

More information:=C2=A0https:/= /bitbucket.org/6tisch/meetings/wiki/140720a_ietf90_toronto_plugfest

We hope to see you there!

Xavier a= nd Ines.

2014-06-02 1:02 GMT+03:00 Ines Robles <mariainesrobl= es@googlemail.com>:

Dear all,

We would like to announce the plugfe= st event at the 90th IETF Meeting in Toronto.
We call for participants. The deadli= ne to receive topics to present or demonstrate in the event is 06/13/2014. = Interested audience is also welcome and we encourage audience to participat= e in the feedback session.

<= font face=3D"arial, helvetica, sans-serif">Please find next the plugfest in= formation.=C2=A0

We hope= to see you there!

Xavier and Ines.

-----------------------
Low Power and Lossy Networks plugfest at IETF90
The=C2=A0IETF 6TiSCH,=C2=A0IETF 6lo=C2=A0and=C2=A0IETF ROLL=C2=A0working g= roups are hosting an informal "plugfest" event at the IETF90 meet= ing, in Toronto, CA, during the week of July 20-25 2014.

Goals=
When and where ?

Date: Sunday July 20 20= 14, 0900-1300 EDT.
Location<= /strong>: Meeting Room TBD, Fairmont Royal York Hotel 100 Front Street W, T= oronto, CA.

Topol= ogy proposed - TBD

Star topology
IPv6
Complementary angles
This event will feature the following complementary a= ngles:

= Interoperation
Demonstration
Tools
Focus 1: Interoperation

Dow= nload the interoperation guidelines:

- TBD for Toronto - interoperation guidelines, version 1 (Lon= don)

The= focus during this event is open to demonstrating 6lo, ROLL or 6TiSCH draft= s implementations, including but not limited to: e.g. - 6TiSCH minimal draf= t:=C2=A0http://tools.ietf.org/html/draft-ietf-6tisch-minimal-00. = - TBD

Par= ticipants are encouraged to bring devices which implement parts or all of t= he listed drafts.

Lev= els of interoperation are proposed:

Level 1, star topology.= A single BBR devices acts as the time source neighbor for all other nodes.= Nodes need to demonstrate frame-based and acknowledgement-based synchroniz= ation. The static TSCH schedule, as well as all slot timings are taken from= draft-ietf-6tisch-minimal-00.

Level 2, multi-hop topo= logy. This level builds upon level 1. The goal of this level is full compli= ance to draft-ietf-6tisch-minimal-00, including multi-hop routing (RPL).
Level 3, on-the-fly sch= eduling. [optional] Preliminary implementations of=C2=A0http://to= ols.ietf.org/html/draft-dujovne-6tisch-on-the-fly=C2=A0can be shown.
Level 4, drafts from RO= LL, such as: draft-ietf-roll-mpl-parameter-configuration, draft-ko-roll-mix= -network-pathology, Opportunistic routing, selective DIS, and others that p= articipants want to show

Level 5, drafts from 6l= o, such as: draft-ietf-6lo-btle, draft-ietf-6lo-ghc,draft-ietf-6lo-lowpanz,= and others that participants want to show.
Level 6=C2=A0Other drafts, such as draft-thubert-6man-flow= -label-for-rpl, etc.
Focus 2: Demonstration
Participants are encouraged to bring devices and te= chnology based on 6TiSCH, 6lo and ROLL which they believe can be of interes= t for the other participants. These devices may or may not participate in t= he interoperation event. Demonstration of more complete systems are encoura= ged, for example systems which show the interconnection of a 6TiSCH based m= esh to traditional networks.

Focus= 3: Tools
Participants are encouraged to bring and present different tools developed = around 6TiSCH/6lo/ROLL networks. Possible tools include, but are not limite= d to:

acquisition devices (i.e. "sniffers= ")
packet analysis tools (e.g. = Wireshark)
simulation/emulation plat= forms

= Important Dates
The preparation of this event will be held during a portion of the bi-weekl= y 6TiSCH call (To Be Decided how and when!!!). In particul= ar:

06/02/2014=C2=A0Announc= ement of the plugfest event to the WG/ML related with constrained devices, = such as: 6tisch, 6lo, roll, core, lwig, dtls-iot, coman, ace, etc.
06/06/2014=C2=A0Adoption of the plugfest call by the WGs, = and call for participants at each group.
06/02/2014-06/13/2014=C2=A0Participants have contacte= d the plugfest chairs (Xavier or Ines) with a tentative description of what= they wish to participate in.

06/20/2014=C2=A0Synchro= nization point 1. Participants can share the state of advancement of the im= plementation and raise blocking points.
07/11/2014=C2=A0Synchronization point 2. Participants can = share the state of advancement of the implementation and raise blocking poi= nts.

07/20/2014. Plugfest at= IETF90.
Tentative Agenda from 9:00 to 13:00
[09.00]=C2=A0Welcome and I= nitial Instructions

[09.05]=C2=A0Participants Pitch= (5 min per Participant)
[09.45]= =C2=A0Participants Pitch Tools (5 min per Participant)
[10.15]=C2=A0Interoperation (Islands)
[11.50]=C2=A0Feedback and open discussion.
[12.40]=C2=A0Acknowledgements and Plugf= est End

For M= ore Information

Contact: Xavi Vilajosan= a=C2=A0xvilajosana@eecs.berkel= ey.edu=C2=A0- Ines Robles=C2=A0mariainesrobles@gmail.com

= Note Well
This event is organized as part of the IETF90 standardization meeting. You = need to register to the IETF90 conference to be able to participate. Daily = passes are available. The IETF Note Well applies to this plugfest, see=C2= =A0http:/= /www.ietf.org/about/note-well.html.

About=
http://datatracker.ietf.org/wg/6tisch/charter/, which also = contains links to the mailing list and the Internet-Drafts published by the= group. 6TiSCH holds weekly phone calls on Friday 8am PST. Participation is= open, and is subject to the IETF Note Well.

The= IETF 6lo working group focuses on the work that facilitates IPv6 connectiv= ity over constrained node networks with the characteristics of: limited pow= er, memory and processing resources;. You can access the charter at=C2=A0https:/= /datatracker.ietf.org/wg/6lo/charter/, which also contains links to the= mailing list and the I-D published by the group.

The= IETF ROLL working group is focused on routing issues for LLN (Low Power an= d Lossy Networks), in IPv6 routing architectural framework for the industri= al, connected home, building and urban sensor networks application scenario= s. You can access the charter at=C2=A0https://datatracker.ietf.org/wg/roll/char= ter/, which also contains links to the mailing list and the I-D publish= ed by the group.

--001a11339e2eba82fc04fb81e825-- From nobody Tue Jun 10 17:48:06 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 464CD1A02E3 for ; Tue, 10 Jun 2014 14:38:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 ADgRIAX04Tj8 for ; Tue, 10 Jun 2014 14:38:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AFA551A02C6 for ; Tue, 10 Jun 2014 14:38:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140610213842.7442.45210.idtracker@ietfa.amsl.com> Date: Tue, 10 Jun 2014 14:38:42 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/ace/nXWL0UQD_MqMYW-mhsim-xPaeWI X-Mailman-Approved-At: Tue, 10 Jun 2014 17:48:02 -0700 Subject: [Ace] State changed: charter-ietf-ace-00-06 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Authentication and Authorization for Constrained Environments $ace$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 21:38:44 -0000 State changed to IESG review. URL: http://datatracker.ietf.org/doc/charter-ietf-ace/ From nobody Mon Jun 16 18:01:00 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2B1F1A02A5; Mon, 16 Jun 2014 15:34:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 jTBsBxl7BmBT; Mon, 16 Jun 2014 15:34:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D9D61A02A7; Mon, 16 Jun 2014 15:34:04 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140616223404.14891.17793.idtracker@ietfa.amsl.com> Date: Mon, 16 Jun 2014 15:34:04 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/ace/IvlzktrSN7QxQc3IbRl2gJz6s7Y X-Mailman-Approved-At: Mon, 16 Jun 2014 18:00:58 -0700 Cc: ace WG Subject: [Ace] WG Action: Formed Authentication and Authorization for Constrained Environments (ace) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Authentication and Authorization for Constrained Environments $ace$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 22:34:08 -0000 A new IETF working group has been formed in the Security Area. For additional information please contact the Area Directors or the WG Chairs. Authentication and Authorization for Constrained Environments (ace) ------------------------------------------------ Current Status: Proposed WG Chairs: Hannes Tschofenig Kepeng Li Assigned Area Director: Kathleen Moriarty Mailing list Address: ace@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ace Archive: http://www.ietf.org/mail-archive/web/ace/current/maillist.html Charter: The IETF has recently developed protocols for use in constrained environments, where network nodes are limited in CPU, memory and power. REST architecture is widely used for such constrained environments. It has been observed that Internet protocols can be applied to these constrained environments, often only requiring minor tweaking and profiling. In other cases, new protocols have been defined to address the specific requirements of constrained environments. An example of such a protocol is the Constrained Application Protocol (CoAP). As in other environments, authentication and authorization questions also arise in constrained environments. For example, a door lock has to authorize the person seeking access using a "digital key". Where is the authorization policy stored? How does the digital key communicate with the lock? Does the lock interact with an authorization server to obtain authorization information? How can access be temporarily granted to other persons? How can access be revoked? These types of questions have been answered by existing protocols for use cases outside constrained environments, however in constrained environments, additional and different requirements pose challenges for the use of various security protocols. In particular, the need arises for a dynamic and fine grained access control mechanism, where clients and/or resource servers are constrained. The IETF has a long history in developing three-party authentication and authorization protocols for distributed environments. Examples include Kerberos, the Public Key Infrastructure (PKI), the Authentication, Authorization and Accounting (AAA) infrastructure, and the Web Authorization Protocol (OAuth). All these protocols enjoy widespread deployment on the Internet. Although they all aim to solve a similar goal, at an abstract level, they offer quite different functions and utilize different message exchanges. These differences result from the main deployment use cases they were designed for respectively. Requirements derived from use cases may indicate that existing work is useful as basis for a solution for constrained environments. These protocols, however, were not optimized for constrained environments. Additional requirements that need to be taken into account are the lack of a suitable user-interface and the inability of embedded devices to contact an authorization server in real-time with every resource access request due to intermittent connectivity, etc. This working group therefore aims to produce a standardized solution for authentication and authorization to enable authorized access (Get, Put, Post, Delete) to resources identified by a URI and hosted on a resource server in constrained environments. As a starting point, the working group will assume that access to resources at a resource server by a client device takes place using CoAP and is protected by DTLS. Both resource server and client may be constrained. This access will be mediated by an authorization server, which is not considered to be constrained. Existing authentication and authorization protocols will be evaluated and used where applicable to build the constrained-environment solution. This requires relevant specifications to be reviewed for suitability, selecting a subset of them and restricting the options within each of the specifications. Some functionality, however, may not be available in existing protocols, in which case the solution may also involve new protocol work. Leveraging existing work means the working group benefits from available security analysis, implementation, and deployment experience. Moreover, a standardized solution for federated authentication and authorization will help to stimulate the deployment of constrained devices that provide increased security. Once progress in identifying suitable candidate solutions has been made, the working group will verify whether the same mechanisms are also applicable beyond the use of CoAP and DTLS, which are the two main protocols the group will focus on for access to resources. In particular, the ability to use the developed solution over HTTP and TLS will be investigated. Note that the initial focus is on CoAP and HTTP with DTLS and TLS. Other security protocols may be considered as long as the primary focus is maintained. The group is scoped to work only on the web protocols and data carried within them. Furthermore, to guarantee smooth transition, the integration with existing deployments will be studied, particularly concerning the use of protocol translation proxies. This work does not make the assumption that the party offering application layer services is always the same party offering network access services. ACE will need to interact with CORE and LWIG to ensure coordination. The working group has the following tasks: 1) Produce use cases and requirements 2) Identify authentication and authorization mechanisms suitable for resource access in constrained environments. Milestones: Jul 2014 - Submit "Use cases and Requirements" as a WG item. Dec 2014 - Submit "Authentication and Authorization Solution" as a WG item. Apr 2015 - Optionally, submit "Use cases and Requirements" document to the IESG for publication as an Informational RFC. Jul 2015 - Submit "Authentication and Authorization Solution" specification to the IESG for publication as a Proposed Standard. From nobody Mon Jun 16 20:45:35 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A7561A0171 for ; Mon, 16 Jun 2014 20:45:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.063 X-Spam-Level: X-Spam-Status: No, score=-2.063 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 dvoknFSMZRco for ; Mon, 16 Jun 2014 20:45:28 -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 C74DD1A0167 for ; Mon, 16 Jun 2014 20:45:27 -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 BIM80354; Tue, 17 Jun 2014 03:45:25 +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; Tue, 17 Jun 2014 04:45:24 +0100 Received: from SZXEMA501-MBS.china.huawei.com ([169.254.2.214]) by SZXEMA410-HUB.china.huawei.com ([10.82.72.42]) with mapi id 14.03.0158.001; Tue, 17 Jun 2014 11:45:19 +0800 From: Likepeng To: ace WG Thread-Topic: [Ace] WG Action: Formed Authentication and Authorization for Constrained Environments (ace) Thread-Index: AQHPicedqjdXxzlpEEG2pTnLs15y15t0kXyQ Date: Tue, 17 Jun 2014 03:45:18 +0000 Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F25815C539@SZXEMA501-MBS.china.huawei.com> References: <20140616223404.14891.17793.idtracker@ietfa.amsl.com> In-Reply-To: <20140616223404.14891.17793.idtracker@ietfa.amsl.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.167.122] 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/ace/6Oud_wtXS78jgCZwQbOOY9E7lMI Subject: Re: [Ace] WG Action: Formed Authentication and Authorization for Constrained Environments (ace) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments $ace$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 03:45:31 -0000 SGVsbG8gYWxsLA0KDQpOb3cgb3VyIGNoYXJ0ZXIgaGFzIGJlZW4gYXBwcm92ZWQgYW5kIFdHIGhh cyBiZWVuIGZvcm1lZC4NCg0KVGhhbmsgeW91IGFsbCBmb3IgeW91ciBpbnRlcmVzdHMgYW5kIHN1 cHBvcnRzIGZvciB0aGlzIG5ldyBXRy4NCg0KVG8gdGhlIGRyYWZ0IGF1dGhvcnMsIGlmIHlvdSBo YXZlIHJlbGV2YW50IGRyYWZ0cywgYnV0IHRoZXkgYXJlIG5vdCBsaXN0ZWQgb24gdGhlIFdHIHdl YiBwYWdlLCBwbGVhc2UgY2hhbmdlIHRoZSBkb2N1bWVudCBuYW1lICh0aGF0IGlzLCBjb250YWlu IHRoZSBzdHJpbmcgJy1hY2UtJyBpbiB0aGUgZHJhZnQgbmFtZSkgdG8gbGluayB0aGVtIGhlcmU6 DQpodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvd2cvYWNlLw0KDQpUaGFua3MsDQoNCktpbmQg UmVnYXJkcw0KS2VwZW5nDQoNCj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ILeivP7IyzogQWNlIFtt YWlsdG86YWNlLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gVGhlIElFU0cNCj4gt6LLzcqxvOQ6IDIw MTTE6jbUwjE3yNUgNjozNA0KPiDK1bz+yMs6IElFVEYtQW5ub3VuY2UNCj4gs63LzTogYWNlIFdH DQo+INb3zOI6IFtBY2VdIFdHIEFjdGlvbjogRm9ybWVkIEF1dGhlbnRpY2F0aW9uIGFuZCBBdXRo b3JpemF0aW9uIGZvcg0KPiBDb25zdHJhaW5lZCBFbnZpcm9ubWVudHMgKGFjZSkNCj4gDQo+IEEg bmV3IElFVEYgd29ya2luZyBncm91cCBoYXMgYmVlbiBmb3JtZWQgaW4gdGhlIFNlY3VyaXR5IEFy ZWEuIEZvciBhZGRpdGlvbmFsDQo+IGluZm9ybWF0aW9uIHBsZWFzZSBjb250YWN0IHRoZSBBcmVh IERpcmVjdG9ycyBvciB0aGUgV0cgQ2hhaXJzLg0KPiANCj4gQXV0aGVudGljYXRpb24gYW5kIEF1 dGhvcml6YXRpb24gZm9yIENvbnN0cmFpbmVkIEVudmlyb25tZW50cyAoYWNlKQ0KPiAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gQ3VycmVudCBTdGF0 dXM6IFByb3Bvc2VkIFdHDQo+IA0KPiBDaGFpcnM6DQo+ICAgSGFubmVzIFRzY2hvZmVuaWcgPEhh bm5lcy5Uc2Nob2ZlbmlnQGdteC5uZXQ+DQo+ICAgS2VwZW5nIExpIDxsaWtlcGVuZ0BodWF3ZWku Y29tPg0KPiANCj4gQXNzaWduZWQgQXJlYSBEaXJlY3RvcjoNCj4gICBLYXRobGVlbiBNb3JpYXJ0 eSA8S2F0aGxlZW4uTW9yaWFydHkuaWV0ZkBnbWFpbC5jb20+DQo+IA0KPiBNYWlsaW5nIGxpc3QN Cj4gICBBZGRyZXNzOiBhY2VAaWV0Zi5vcmcNCj4gICBUbyBTdWJzY3JpYmU6IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYWNlDQo+ICAgQXJjaGl2ZTogaHR0cDovL3d3dy5p ZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2FjZS9jdXJyZW50L21haWxsaXN0Lmh0bWwNCj4gDQo+ IENoYXJ0ZXI6DQo+IA0KPiBUaGUgSUVURiBoYXMgcmVjZW50bHkgZGV2ZWxvcGVkIHByb3RvY29s cyBmb3IgdXNlIGluIGNvbnN0cmFpbmVkDQo+IGVudmlyb25tZW50cywgd2hlcmUgbmV0d29yayBu b2RlcyBhcmUgbGltaXRlZCBpbiBDUFUsIG1lbW9yeSBhbmQgcG93ZXIuDQo+IFJFU1QgYXJjaGl0 ZWN0dXJlIGlzIHdpZGVseSB1c2VkIGZvciBzdWNoIGNvbnN0cmFpbmVkIGVudmlyb25tZW50cy4N Cj4gSXQgaGFzIGJlZW4gb2JzZXJ2ZWQgdGhhdCBJbnRlcm5ldCBwcm90b2NvbHMgY2FuIGJlIGFw cGxpZWQgdG8gdGhlc2UNCj4gY29uc3RyYWluZWQgZW52aXJvbm1lbnRzLCBvZnRlbiBvbmx5IHJl cXVpcmluZyBtaW5vciB0d2Vha2luZyBhbmQgcHJvZmlsaW5nLg0KPiBJbiBvdGhlciBjYXNlcywg bmV3IHByb3RvY29scyBoYXZlIGJlZW4gZGVmaW5lZCB0byBhZGRyZXNzIHRoZSBzcGVjaWZpYw0K PiByZXF1aXJlbWVudHMgb2YgY29uc3RyYWluZWQgZW52aXJvbm1lbnRzLiBBbiBleGFtcGxlIG9m IHN1Y2ggYSBwcm90b2NvbCBpcw0KPiB0aGUgQ29uc3RyYWluZWQgQXBwbGljYXRpb24gUHJvdG9j b2wgKENvQVApLg0KPiANCj4gQXMgaW4gb3RoZXIgZW52aXJvbm1lbnRzLCBhdXRoZW50aWNhdGlv biBhbmQgYXV0aG9yaXphdGlvbiBxdWVzdGlvbnMgYWxzbw0KPiBhcmlzZSBpbiBjb25zdHJhaW5l ZCBlbnZpcm9ubWVudHMuIEZvciBleGFtcGxlLCBhIGRvb3IgbG9jayBoYXMgdG8gYXV0aG9yaXpl DQo+IHRoZSBwZXJzb24gc2Vla2luZyBhY2Nlc3MgdXNpbmcgYSAiZGlnaXRhbCBrZXkiLiBXaGVy ZSBpcyB0aGUgYXV0aG9yaXphdGlvbg0KPiBwb2xpY3kgc3RvcmVkPyBIb3cgZG9lcyB0aGUgZGln aXRhbCBrZXkgY29tbXVuaWNhdGUgd2l0aCB0aGUgbG9jaz8gRG9lcyB0aGUNCj4gbG9jayBpbnRl cmFjdCB3aXRoIGFuIGF1dGhvcml6YXRpb24gc2VydmVyIHRvIG9idGFpbiBhdXRob3JpemF0aW9u IGluZm9ybWF0aW9uPw0KPiBIb3cgY2FuIGFjY2VzcyBiZSB0ZW1wb3JhcmlseSBncmFudGVkIHRv IG90aGVyIHBlcnNvbnM/IEhvdyBjYW4gYWNjZXNzIGJlDQo+IHJldm9rZWQ/IFRoZXNlIHR5cGVz IG9mIHF1ZXN0aW9ucyBoYXZlIGJlZW4gYW5zd2VyZWQgYnkgZXhpc3RpbmcgcHJvdG9jb2xzDQo+ IGZvciB1c2UgY2FzZXMgb3V0c2lkZSBjb25zdHJhaW5lZCBlbnZpcm9ubWVudHMsIGhvd2V2ZXIg aW4gY29uc3RyYWluZWQNCj4gZW52aXJvbm1lbnRzLCBhZGRpdGlvbmFsIGFuZCBkaWZmZXJlbnQg cmVxdWlyZW1lbnRzIHBvc2UgY2hhbGxlbmdlcyBmb3IgdGhlDQo+IHVzZSBvZiB2YXJpb3VzIHNl Y3VyaXR5IHByb3RvY29scy4gSW4gcGFydGljdWxhciwgdGhlIG5lZWQgYXJpc2VzIGZvciBhIGR5 bmFtaWMNCj4gYW5kIGZpbmUgZ3JhaW5lZCBhY2Nlc3MgY29udHJvbCBtZWNoYW5pc20sIHdoZXJl IGNsaWVudHMgYW5kL29yIHJlc291cmNlDQo+IHNlcnZlcnMgYXJlIGNvbnN0cmFpbmVkLg0KPiAN Cj4gVGhlIElFVEYgaGFzIGEgbG9uZyBoaXN0b3J5IGluIGRldmVsb3BpbmcgdGhyZWUtcGFydHkg YXV0aGVudGljYXRpb24gYW5kDQo+IGF1dGhvcml6YXRpb24gcHJvdG9jb2xzIGZvciBkaXN0cmli dXRlZCBlbnZpcm9ubWVudHMuIEV4YW1wbGVzIGluY2x1ZGUNCj4gS2VyYmVyb3MsIHRoZSBQdWJs aWMgS2V5IEluZnJhc3RydWN0dXJlIChQS0kpLCB0aGUgQXV0aGVudGljYXRpb24sIEF1dGhvcml6 YXRpb24NCj4gYW5kIEFjY291bnRpbmcgKEFBQSkgaW5mcmFzdHJ1Y3R1cmUsIGFuZCB0aGUgV2Vi IEF1dGhvcml6YXRpb24gUHJvdG9jb2wNCj4gKE9BdXRoKS4gQWxsIHRoZXNlIHByb3RvY29scyBl bmpveSB3aWRlc3ByZWFkIGRlcGxveW1lbnQgb24gdGhlIEludGVybmV0Lg0KPiBBbHRob3VnaCB0 aGV5IGFsbCBhaW0gdG8gc29sdmUgYSBzaW1pbGFyIGdvYWwsIGF0IGFuIGFic3RyYWN0IGxldmVs LCB0aGV5IG9mZmVyDQo+IHF1aXRlIGRpZmZlcmVudCBmdW5jdGlvbnMgYW5kIHV0aWxpemUgZGlm ZmVyZW50IG1lc3NhZ2UgZXhjaGFuZ2VzLiBUaGVzZQ0KPiBkaWZmZXJlbmNlcyByZXN1bHQgZnJv bSB0aGUgbWFpbiBkZXBsb3ltZW50IHVzZSBjYXNlcyB0aGV5IHdlcmUgZGVzaWduZWQgZm9yDQo+ IHJlc3BlY3RpdmVseS4NCj4gDQo+IFJlcXVpcmVtZW50cyBkZXJpdmVkIGZyb20gdXNlIGNhc2Vz IG1heSBpbmRpY2F0ZSB0aGF0IGV4aXN0aW5nIHdvcmsgaXMgdXNlZnVsDQo+IGFzIGJhc2lzIGZv ciBhIHNvbHV0aW9uIGZvciBjb25zdHJhaW5lZCBlbnZpcm9ubWVudHMuIFRoZXNlIHByb3RvY29s cywgaG93ZXZlciwNCj4gd2VyZSBub3Qgb3B0aW1pemVkIGZvciBjb25zdHJhaW5lZCBlbnZpcm9u bWVudHMuDQo+IEFkZGl0aW9uYWwgcmVxdWlyZW1lbnRzIHRoYXQgbmVlZCB0byBiZSB0YWtlbiBp bnRvIGFjY291bnQgYXJlIHRoZSBsYWNrIG9mIGENCj4gc3VpdGFibGUgdXNlci1pbnRlcmZhY2Ug YW5kIHRoZSBpbmFiaWxpdHkgb2YgZW1iZWRkZWQgZGV2aWNlcyB0byBjb250YWN0IGFuDQo+IGF1 dGhvcml6YXRpb24gc2VydmVyIGluIHJlYWwtdGltZSB3aXRoIGV2ZXJ5IHJlc291cmNlIGFjY2Vz cyByZXF1ZXN0IGR1ZSB0bw0KPiBpbnRlcm1pdHRlbnQgY29ubmVjdGl2aXR5LCBldGMuDQo+IA0K PiBUaGlzIHdvcmtpbmcgZ3JvdXAgdGhlcmVmb3JlIGFpbXMgdG8gcHJvZHVjZSBhIHN0YW5kYXJk aXplZCBzb2x1dGlvbiBmb3INCj4gYXV0aGVudGljYXRpb24gYW5kIGF1dGhvcml6YXRpb24gdG8g ZW5hYmxlIGF1dGhvcml6ZWQgYWNjZXNzIChHZXQsIFB1dCwgUG9zdCwNCj4gRGVsZXRlKSB0byBy ZXNvdXJjZXMgaWRlbnRpZmllZCBieSBhIFVSSSBhbmQgaG9zdGVkIG9uIGEgcmVzb3VyY2Ugc2Vy dmVyIGluDQo+IGNvbnN0cmFpbmVkIGVudmlyb25tZW50cy4gQXMgYSBzdGFydGluZyBwb2ludCwg dGhlIHdvcmtpbmcgZ3JvdXAgd2lsbCBhc3N1bWUNCj4gdGhhdCBhY2Nlc3MgdG8gcmVzb3VyY2Vz IGF0IGEgcmVzb3VyY2Ugc2VydmVyIGJ5IGEgY2xpZW50IGRldmljZSB0YWtlcyBwbGFjZQ0KPiB1 c2luZyBDb0FQIGFuZCBpcyBwcm90ZWN0ZWQgYnkgRFRMUy4gQm90aCByZXNvdXJjZSBzZXJ2ZXIg YW5kIGNsaWVudCBtYXkgYmUNCj4gY29uc3RyYWluZWQuIFRoaXMgYWNjZXNzIHdpbGwgYmUgbWVk aWF0ZWQgYnkgYW4gYXV0aG9yaXphdGlvbiBzZXJ2ZXIsIHdoaWNoIGlzDQo+IG5vdCBjb25zaWRl cmVkIHRvIGJlIGNvbnN0cmFpbmVkLg0KPiANCj4gRXhpc3RpbmcgYXV0aGVudGljYXRpb24gYW5k IGF1dGhvcml6YXRpb24gcHJvdG9jb2xzIHdpbGwgYmUgZXZhbHVhdGVkIGFuZCB1c2VkDQo+IHdo ZXJlIGFwcGxpY2FibGUgdG8gYnVpbGQgdGhlIGNvbnN0cmFpbmVkLWVudmlyb25tZW50IHNvbHV0 aW9uLg0KPiBUaGlzIHJlcXVpcmVzIHJlbGV2YW50IHNwZWNpZmljYXRpb25zIHRvIGJlIHJldmll d2VkIGZvciBzdWl0YWJpbGl0eSwgc2VsZWN0aW5nIGENCj4gc3Vic2V0IG9mIHRoZW0gYW5kIHJl c3RyaWN0aW5nIHRoZSBvcHRpb25zIHdpdGhpbiBlYWNoIG9mIHRoZSBzcGVjaWZpY2F0aW9ucy4N Cj4gU29tZSBmdW5jdGlvbmFsaXR5LCBob3dldmVyLCBtYXkgbm90IGJlIGF2YWlsYWJsZSBpbiBl eGlzdGluZyBwcm90b2NvbHMsIGluDQo+IHdoaWNoIGNhc2UgdGhlIHNvbHV0aW9uIG1heSBhbHNv IGludm9sdmUgbmV3IHByb3RvY29sIHdvcmsuIExldmVyYWdpbmcNCj4gZXhpc3Rpbmcgd29yayBt ZWFucyB0aGUgd29ya2luZyBncm91cCBiZW5lZml0cyBmcm9tIGF2YWlsYWJsZSBzZWN1cml0eQ0K PiBhbmFseXNpcywgaW1wbGVtZW50YXRpb24sIGFuZCBkZXBsb3ltZW50IGV4cGVyaWVuY2UuIE1v cmVvdmVyLCBhDQo+IHN0YW5kYXJkaXplZCBzb2x1dGlvbiBmb3IgZmVkZXJhdGVkIGF1dGhlbnRp Y2F0aW9uIGFuZCBhdXRob3JpemF0aW9uIHdpbGwgaGVscA0KPiB0byBzdGltdWxhdGUgdGhlIGRl cGxveW1lbnQgb2YgY29uc3RyYWluZWQgZGV2aWNlcyB0aGF0IHByb3ZpZGUgaW5jcmVhc2VkDQo+ IHNlY3VyaXR5Lg0KPiANCj4gT25jZSBwcm9ncmVzcyBpbiBpZGVudGlmeWluZyBzdWl0YWJsZSBj YW5kaWRhdGUgc29sdXRpb25zIGhhcyBiZWVuIG1hZGUsIHRoZQ0KPiB3b3JraW5nIGdyb3VwIHdp bGwgdmVyaWZ5IHdoZXRoZXIgdGhlIHNhbWUgbWVjaGFuaXNtcyBhcmUgYWxzbyBhcHBsaWNhYmxl DQo+IGJleW9uZCB0aGUgdXNlIG9mIENvQVAgYW5kIERUTFMsIHdoaWNoIGFyZSB0aGUgdHdvIG1h aW4gcHJvdG9jb2xzIHRoZSBncm91cA0KPiB3aWxsIGZvY3VzIG9uIGZvciBhY2Nlc3MgdG8gcmVz b3VyY2VzLiBJbiBwYXJ0aWN1bGFyLCB0aGUgYWJpbGl0eSB0byB1c2UgdGhlDQo+IGRldmVsb3Bl ZCBzb2x1dGlvbiBvdmVyIEhUVFAgYW5kIFRMUyB3aWxsIGJlIGludmVzdGlnYXRlZC4gTm90ZSB0 aGF0IHRoZSBpbml0aWFsDQo+IGZvY3VzIGlzIG9uIENvQVAgYW5kIEhUVFAgd2l0aCBEVExTIGFu ZCBUTFMuIE90aGVyIHNlY3VyaXR5IHByb3RvY29scyBtYXkgYmUNCj4gY29uc2lkZXJlZCBhcyBs b25nIGFzIHRoZSBwcmltYXJ5IGZvY3VzIGlzIG1haW50YWluZWQuIFRoZSBncm91cCBpcyBzY29w ZWQgdG8NCj4gd29yayBvbmx5IG9uIHRoZSB3ZWIgcHJvdG9jb2xzIGFuZCBkYXRhIGNhcnJpZWQg d2l0aGluIHRoZW0uIEZ1cnRoZXJtb3JlLCB0bw0KPiBndWFyYW50ZWUgc21vb3RoIHRyYW5zaXRp b24sIHRoZSBpbnRlZ3JhdGlvbiB3aXRoIGV4aXN0aW5nIGRlcGxveW1lbnRzIHdpbGwgYmUNCj4g c3R1ZGllZCwgcGFydGljdWxhcmx5IGNvbmNlcm5pbmcgdGhlIHVzZSBvZiBwcm90b2NvbCB0cmFu c2xhdGlvbiBwcm94aWVzLg0KPiANCj4gVGhpcyB3b3JrIGRvZXMgbm90IG1ha2UgdGhlIGFzc3Vt cHRpb24gdGhhdCB0aGUgcGFydHkgb2ZmZXJpbmcgYXBwbGljYXRpb24NCj4gbGF5ZXIgc2Vydmlj ZXMgaXMgYWx3YXlzIHRoZSBzYW1lIHBhcnR5IG9mZmVyaW5nIG5ldHdvcmsgYWNjZXNzIHNlcnZp Y2VzLiAgQUNFDQo+IHdpbGwgbmVlZCB0byBpbnRlcmFjdCB3aXRoIENPUkUgYW5kIExXSUcgdG8g ZW5zdXJlIGNvb3JkaW5hdGlvbi4NCj4gDQo+IFRoZSB3b3JraW5nIGdyb3VwIGhhcyB0aGUgZm9s bG93aW5nIHRhc2tzOg0KPiANCj4gMSkgUHJvZHVjZSB1c2UgY2FzZXMgYW5kIHJlcXVpcmVtZW50 cw0KPiANCj4gMikgSWRlbnRpZnkgYXV0aGVudGljYXRpb24gYW5kIGF1dGhvcml6YXRpb24gbWVj aGFuaXNtcyBzdWl0YWJsZSBmb3IgcmVzb3VyY2UNCj4gYWNjZXNzIGluIGNvbnN0cmFpbmVkIGVu dmlyb25tZW50cy4NCj4gDQo+IE1pbGVzdG9uZXM6DQo+ICAgSnVsIDIwMTQgLSBTdWJtaXQgIlVz ZSBjYXNlcyBhbmQgUmVxdWlyZW1lbnRzIiBhcyBhIFdHIGl0ZW0uDQo+ICAgRGVjIDIwMTQgLSBT dWJtaXQgIkF1dGhlbnRpY2F0aW9uIGFuZCBBdXRob3JpemF0aW9uIFNvbHV0aW9uIiBhcyBhIFdH DQo+IGl0ZW0uDQo+ICAgQXByIDIwMTUgLSBPcHRpb25hbGx5LCBzdWJtaXQgIlVzZSBjYXNlcyBh bmQgUmVxdWlyZW1lbnRzIiBkb2N1bWVudCB0bw0KPiB0aGUgSUVTRyBmb3IgcHVibGljYXRpb24g YXMgYW4gSW5mb3JtYXRpb25hbCBSRkMuDQo+ICAgSnVsIDIwMTUgLSBTdWJtaXQgIkF1dGhlbnRp Y2F0aW9uIGFuZCBBdXRob3JpemF0aW9uIFNvbHV0aW9uIg0KPiBzcGVjaWZpY2F0aW9uIHRvIHRo ZSBJRVNHIGZvciBwdWJsaWNhdGlvbiBhcyBhIFByb3Bvc2VkIFN0YW5kYXJkLg0KPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBBY2UgbWFpbGluZyBs aXN0DQo+IEFjZUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2FjZQ0K From nobody Mon Jun 16 23:12:43 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48A1F1A0284 for ; Mon, 16 Jun 2014 23:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CZmXybSO08HC for ; Mon, 16 Jun 2014 23:12:37 -0700 (PDT) Received: from bohuslav.ifi.uzh.ch (bohuslav.ifi.uzh.ch [130.60.155.10]) by ietfa.amsl.com (Postfix) with ESMTP id ECEA11A027F for ; Mon, 16 Jun 2014 23:12:36 -0700 (PDT) Received: from authenticated sender schmitt by bohuslav.ifi.uzh.ch (postfix) with ESMTPSA id SA for ; ace@ietf.org Message-ID: <539FDC52.6080602@ifi.uzh.ch> Date: Tue, 17 Jun 2014 08:12:34 +0200 From: Corinna Schmitt User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: ace@ietf.org References: <20140616223404.14891.17793.idtracker@ietfa.amsl.com> In-Reply-To: <20140616223404.14891.17793.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------040007080401010104000601" X-Virus-Scanned: clamav-milter 0.97.8 at bohuslav X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/ace/YVb64afx173zX6k_pb_6nNlF1wo Subject: Re: [Ace] WG Action: Formed Authentication and Authorization for Constrained Environments (ace) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments $ace$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 06:12:41 -0000 This is a multi-part message in MIME format. --------------040007080401010104000601 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Good Morning ACE, that`s good news in the early morning when starting office. Thanks to all involved persons for the great work. Let`s start in Toronto as a WG officially. Regards from Zurich, Corinna Am 17.06.14 00:34, schrieb The IESG: > A new IETF working group has been formed in the Security Area. For > additional information please contact the Area Directors or the WG > Chairs. > > Authentication and Authorization for Constrained Environments (ace) > ------------------------------------------------ > Current Status: Proposed WG > > Chairs: > Hannes Tschofenig > Kepeng Li > > Assigned Area Director: > Kathleen Moriarty > > Mailing list > Address: ace@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/ace > Archive: http://www.ietf.org/mail-archive/web/ace/current/maillist.html > > Charter: > > The IETF has recently developed protocols for use in constrained > environments, where network nodes are limited in CPU, memory and power. > REST architecture is widely used for such constrained environments. > It has been observed that Internet protocols can be applied to these > constrained environments, often only requiring minor tweaking and > profiling. In other cases, new protocols have been defined to address > the specific requirements of constrained environments. An example of > such a protocol is the Constrained Application Protocol (CoAP). > > As in other environments, authentication and authorization questions > also arise in constrained environments. For example, a door lock has to > authorize the person seeking access using a "digital key". Where is the > authorization policy stored? How does the digital key communicate with > the lock? Does the lock interact with an authorization server to obtain > authorization information? How can access be temporarily granted to > other persons? How can access be revoked? These types of questions have > been answered by existing protocols for use cases outside constrained > environments, however in constrained environments, additional and > different requirements pose challenges for the use of various security > protocols. In particular, the need arises for a dynamic and fine grained > access control mechanism, where clients and/or resource servers are > constrained. > > The IETF has a long history in developing three-party authentication and > authorization protocols for distributed environments. Examples include > Kerberos, the Public Key Infrastructure (PKI), the Authentication, > Authorization and Accounting (AAA) infrastructure, and the Web > Authorization Protocol (OAuth). All these protocols enjoy widespread > deployment on the Internet. Although they all aim to solve a similar > goal, at an abstract level, they offer quite different functions and > utilize different message exchanges. These differences result from the > main deployment use cases they were designed for respectively. > > Requirements derived from use cases may indicate that existing work is > useful as basis for a solution for constrained environments. These > protocols, however, were not optimized for constrained environments. > Additional requirements that need to be taken into account are the lack > of a suitable user-interface and the inability of embedded devices to > contact an authorization server in real-time with every resource access > request due to intermittent connectivity, etc. > > This working group therefore aims to produce a standardized solution for > authentication and authorization to enable authorized access (Get, Put, > Post, Delete) to resources identified by a URI and hosted on a resource > server in constrained environments. As a starting point, the working > group will assume that access to resources at a resource server by a > client device takes place using CoAP and is protected by DTLS. Both > resource server and client may be constrained. This access will be > mediated by an authorization server, which is not considered to be > constrained. > > Existing authentication and authorization protocols will be evaluated > and used where applicable to build the constrained-environment solution. > This requires relevant specifications to be reviewed for suitability, > selecting a subset of them and restricting the options within each of > the specifications. Some functionality, however, may not be available in > existing protocols, in which case the solution may also involve new > protocol work. Leveraging existing work means the working group benefits > from available security analysis, implementation, and deployment > experience. Moreover, a standardized solution for federated > authentication and authorization will help to stimulate the deployment > of constrained devices that provide increased security. > > Once progress in identifying suitable candidate solutions has been made, > the working group will verify whether the same mechanisms are also > applicable beyond the use of CoAP and DTLS, which are the two main > protocols the group will focus on for access to resources. In > particular, the ability to use the developed solution over HTTP and TLS > will be investigated. Note that the initial focus is on CoAP and HTTP > with DTLS and TLS. Other security protocols may be considered as long as > the primary focus is maintained. The group is scoped to work only on the > web protocols and data carried within them. Furthermore, to guarantee > smooth transition, the integration with existing deployments will be > studied, particularly concerning the use of protocol translation > proxies. > > This work does not make the assumption that the party offering > application layer services is always the same party offering network > access services. ACE will need to interact with CORE and LWIG to > ensure coordination. > > The working group has the following tasks: > > 1) Produce use cases and requirements > > 2) Identify authentication and authorization mechanisms suitable for > resource access in constrained environments. > > Milestones: > Jul 2014 - Submit "Use cases and Requirements" as a WG item. > Dec 2014 - Submit "Authentication and Authorization Solution" as a WG > item. > Apr 2015 - Optionally, submit "Use cases and Requirements" document to > the IESG for publication as an Informational RFC. > Jul 2015 - Submit "Authentication and Authorization Solution" > specification to the IESG for publication as a Proposed Standard. > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > -- --------------040007080401010104000601 Content-Type: multipart/related; boundary="------------000402080209010607090000" --------------000402080209010607090000 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Good Morning ACE,

that`s good news in the early morning when starting office.
Thanks to all involved persons for the great work.

Let`s start in Toronto as a WG officially.

Regards from Zurich,
Corinna

Am 17.06.14 00:34, schrieb The IESG:

A new IETF working group has been formed in the Security Area. For additional information please contact the Area Directors or the WG Chairs. Authentication and Authorization for Constrained Environments (ace) ------------------------------------------------ Current Status: Proposed WG Chairs: Hannes Tschofenig <Hannes.Tschofenig@gmx.net> Kepeng Li <likepeng@huawei.com> Assigned Area Director: Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com> Mailing list Address: ace@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ace Archive: http://www.ietf.org/mail-archive/web/ace/current/maillist.html Charter: The IETF has recently developed protocols for use in constrained environments, where network nodes are limited in CPU, memory and power. REST architecture is widely used for such constrained environments. It has been observed that Internet protocols can be applied to these constrained environments, often only requiring minor tweaking and profiling. In other cases, new protocols have been defined to address the specific requirements of constrained environments. An example of such a protocol is the Constrained Application Protocol (CoAP). As in other environments, authentication and authorization questions also arise in constrained environments. For example, a door lock has to authorize the person seeking access using a "digital key". Where is the authorization policy stored? How does the digital key communicate with the lock? Does the lock interact with an authorization server to obtain authorization information? How can access be temporarily granted to other persons? How can access be revoked? These types of questions have been answered by existing protocols for use cases outside constrained environments, however in constrained environments, additional and different requirements pose challenges for the use of various security protocols. In particular, the need arises for a dynamic and fine grained access control mechanism, where clients and/or resource servers are constrained. The IETF has a long history in developing three-party authentication and authorization protocols for distributed environments. Examples include Kerberos, the Public Key Infrastructure (PKI), the Authentication, Authorization and Accounting (AAA) infrastructure, and the Web Authorization Protocol (OAuth). All these protocols enjoy widespread deployment on the Internet. Although they all aim to solve a similar goal, at an abstract level, they offer quite different functions and utilize different message exchanges. These differences result from the main deployment use cases they were designed for respectively. Requirements derived from use cases may indicate that existing work is useful as basis for a solution for constrained environments. These protocols, however, were not optimized for constrained environments. Additional requirements that need to be taken into account are the lack of a suitable user-interface and the inability of embedded devices to contact an authorization server in real-time with every resource access request due to intermittent connectivity, etc. This working group therefore aims to produce a standardized solution for authentication and authorization to enable authorized access (Get, Put, Post, Delete) to resources identified by a URI and hosted on a resource server in constrained environments. As a starting point, the working group will assume that access to resources at a resource server by a client device takes place using CoAP and is protected by DTLS. Both resource server and client may be constrained. This access will be mediated by an authorization server, which is not considered to be constrained. Existing authentication and authorization protocols will be evaluated and used where applicable to build the constrained-environment solution. This requires relevant specifications to be reviewed for suitability, selecting a subset of them and restricting the options within each of the specifications. Some functionality, however, may not be available in existing protocols, in which case the solution may also involve new protocol work. Leveraging existing work means the working group benefits from available security analysis, implementation, and deployment experience. Moreover, a standardized solution for federated authentication and authorization will help to stimulate the deployment of constrained devices that provide increased security. Once progress in identifying suitable candidate solutions has been made, the working group will verify whether the same mechanisms are also applicable beyond the use of CoAP and DTLS, which are the two main protocols the group will focus on for access to resources. In particular, the ability to use the developed solution over HTTP and TLS will be investigated. Note that the initial focus is on CoAP and HTTP with DTLS and TLS. Other security protocols may be considered as long as the primary focus is maintained. The group is scoped to work only on the web protocols and data carried within them. Furthermore, to guarantee smooth transition, the integration with existing deployments will be studied, particularly concerning the use of protocol translation proxies. This work does not make the assumption that the party offering application layer services is always the same party offering network access services. ACE will need to interact with CORE and LWIG to ensure coordination. The working group has the following tasks: 1) Produce use cases and requirements 2) Identify authentication and authorization mechanisms suitable for resource access in constrained environments. Milestones: Jul 2014 - Submit "Use cases and Requirements" as a WG item. Dec 2014 - Submit "Authentication and Authorization Solution" as a WG item. Apr 2015 - Optionally, submit "Use cases and Requirements" document to the IESG for publication as an Informational RFC. Jul 2015 - Submit "Authentication and Authorization Solution" specification to the IESG for publication as a Proposed Standard. _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace

--

--------------000402080209010607090000 Content-Type: image/png; x-mac-type="0"; x-mac-creator="0"; name="visitenkarte.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="visitenkarte.png" iVBORw0KGgoAAAANSUhEUgAAASgAAACgCAIAAAAw8WZPAAAAAXNSR0IArs4c6QAAAARnQU1B AACxjwv8YQUAAAAgY0hSTQAAeiYAAICEAAD6AAAAgOgAAHUwAADqYAAAOpgAABdwnLpRPAAA buNJREFUeF7t3Qe8FtXRP3CT901i2htTTVeTGE035Z+YZkxijFFjQcVKVXrvvffee6/Se+9I R0CahSqCgtJBQKTl/9099y4P9yIiEOXq83zwus8+Z8+ePTtzZs7Mb2Y+9p///OeKd/uMGTNm 5cqVWq1atWr//v3v1jz9e3oGPnIzcOWVV/7ud7/z2DfeeON9993n67tMAcZ7p8/s2bMfeeSR q666Skd14s/o0aOdTH/SM5CegSwzMHny5MAjWAbXYRnMcg7muuKsvz333HOuvPXWW59++ul9 +/ad4/r0T+kZSM9A9hnAdTjopptuwp9nnZ+zMB5mu/nmm8/Nr+m5Ts9AegbedQYIMNKLGMze MivjVa1alax866233rXTdIP0DKRn4HxmIOifWXjqDMbDdRqdOnXqZPqTnoH0DFyKGcBNmLNP nz40z1QuPc14NEx86bc0412KCU/3kZ6BaAYC4/k0adKEYEt4L4PxKKP2dUEaphkvTTLpGbhU M5AwHs4i2Ii3wHsZjJdq/bxgxsvk7XPovWkl9lK90HQ/OWMGUhlvx44d1157bRBvEeNxQdxx xx0Ju7wnxjtx4sTJEyeSa/fs2b1mzZrp06YPHzp02JAh/jmYOmUyifrGG28kzU6eyBmzlh5l egYucgZSGQ/9ly1btk2bNhmMh+vw3oUxXrhq586dkyZNatyoYY1q1apXq1anVq0G9eo1rFu3 ob/16tWrU6d61arVq1WvX6/+6FGjt219NVx1kY+Uvjw9A5f/DGRhvJdffpnQixiP4INNSbV1 no/EI+hsBl2/ffuOnj17li9XrmrlKhivaZMmXTt3fnrwoKlTpsyeNXvO7NnTp00bNnRoj27d WjRv3rhhw+pVq5cuWbpTx46bN28K7KerSGymP+kZ+DDOQBbGQ/CMKYsWLboiMWa+J4kXGGb0 qFHlypatVrVqy+YtunbpsnDBgtkzZo4bOzb7Jm/evGecX75sWa+ePTWuXatW2dKl+/fre/jw YY2PH08z3oeR6NLPlGLVTJgiIMuuCP9LZZVzSzwsovGunTsbN2pUsUKF5k2bDujf74Xnn8c8 zg8cMLBCuXKv79hhzhM5dvTo2y2bN2/YoMHxY8e12bhhw/BhQ1s0bVa1cuWaNWps2rgxrXam SfTDOgPZJV5Ak12RP39+3r3zZzwtX968mW5Zr27dNq3bLFiwYPOmTXv37Hb+hRdeaFCvfptW rVu1aJnwkoO5s+c4o/3gQQN9XfbssmeXLiX9Onbo0KhRw9IlSzr+b8i9YPi55IbU49aY4yfi 5enSKclRT8czPD5pj86HiAuzMx49k7Z5RRbLCgY4h8Tz6ytbtpQpXTrs5ba8vMWZwQMHkn57 du/R47/vvPPfd92FLZ0/cuTI4UOHHIwaOfLef//7zjvuaNWyha99+vRt3qz59te2b33llT69 e7do1qxYkaKB984x4cnSENqkPs/5X3VJXijGyzKYLF8v6C6RvvD228defOGFtWvWHHrzzfPZ aV/QjdIXva8zkJ3xgn3lCiDOLADqs77y2JryH5EKNnXNmzXr3Knj/v37aJj169WbMX0GY+bK 5cunTJ78VMGCRQsXLl60qM3bcyuemzljhqt6dutWMH/+J/PntxvkynDJvr372rZp88zcuW+8 /kbMe81Lliix5eWXw9Yxu63l2LHjSxYvNs6DBw8ans+xt48tXrSI8ebNN98860Rqc/To0WZN m+Z54vF169ZdQjrW1fLlyx95ODeJ/fbbb7u7UZHhe/fuveC7RPrC88/f8+9/f+H//u/zn//c nDlz0ur3+8of/7WbXSzjRULm5Ek806RxEzZJTNK5c+eXXnypdMlSFM6li5doMGHcuP59+w3q 379mjeq7du3EVBs2rHfjwQMGdOvSuX/v3jWrVX/z4MG9+/Y9u2RJm9athw8btmDe/Igze/Zs 3bKVHeORw4dTN4cZwu3kyTffPPSrm276whe+sHbN2iBe9u8/8LOf/vSLX/wipgpSOhB9+DU8 LSfHN77+dfGIvXr0SG2TCMxwSTI1CdtEfcVdht6yCFhnmjZpqtsfXn/9gQMHjr711r3/vucr X/7y2rXR2MJVZ3QV95X6ZrPcMQy+YIEC+rzt73+rVq3qhg0bLoyHQ1cXdu1/jfbesePsmsI7 jTx5rZdwkBc8S8mFyajO0VXyrpOHfW8Sz2Vjx4whslq3arV169Y1q1a3atmyc8eOc2bNInwi Ujt5EkNWrVK1ZvXq+fPmxZlUphnTp1PMGjdswOJSrXLlgvny7969J2KJN97ApdOnTp01c2bb 1m22b9/eoV077r4e3bpHhH6md+HUyVOHDh36xc9//vnPfU6fmYy3/yc//jH58NJLEeNl/3jg 48feHjt6NA5n7EkaBHF61kvCSfvC1F+1T7ZeCR/a5TZv3oKEj9ofP/HTn/7ks5/97OZYYqcS U1ATMroNojzlTJYx/PmPf/z85z+/efPm6PwF4dSzdHjBhBUT9wljiN7FRXzi53jHLXagyH37 9x858lbGHTMfIPWeYcYgLvbu3Xfs2LGLGE7GpfFDnX6lnvQ99RnGGAZ//Ngxo0rOvJPmleW9 nC/jRZR36hQzZrkyZVq1aLFkyeIN69e3b9vu9dffGDVixBtv7Iyf5MT+ffuKFylSqkSJ8mXL 3H7bbfx4M6ZNw0779u3Ndd99LCj8B84vmB+JuPBZtHDRYw8/XKRQ4SOHDlO0WjVv7vL16zdk ed/uTnH91S9vuuqqLwSp4rP/wIGf/exnX/rSlzZu2Lh39+4qVau0bNmCCM11/3333ntP/379 XMU52aN791q1a7GjEstFixV1d+dPHD9OSyxUqBDLELZp367dnf/61x3//CdPo02pBtOmTS1W tOjAAf1LlSzlV2cGDhjwQK5ct/7lFiYi82u0NarXGPL009aXEiVKkKsUxNy5czdu0mTcuHGF Cxfu0rmLnr2fiRMnPvXUU8xXpihsDnfseB2Q4K4777rvnnt5Vg4dPvzKK6+UKF7i29/+1he+ 8H+PPfaYTa+Rv1e20X79uvXlypUrUqRI2TJlFi9afDFsE+xSR986+p6IMkvjt98+ijTfiRxx Ea/Sr3716+B/Mn6zWqVKlddefTXLuvP6668/kvvhv9zyl02bIt/vxQzJteSEV/PSSy8VLVLE HSN6OG/W03j1qlVVqlTdtXMX/rnrzjvZJ+2ngEN2vrHzrK/swiVeWHL43+rWrt2zRw/W/0kT Jgzo15/EM61+Oha74Xbv2tm+bZsmjRsVL1KU0Js0aSK6rFK58p7du/kMKlUoX71K5SqVKs5N 2b34SbfPPbdy8qRJWzZvfnrQ4LatW9uVvSfG44hH/V/60hc/9alPfe5zn/vaV79KYSMJly5Z ao/32//3/3y1GwQMd/DUk0/pnF3nq1/56qc++ckVK1bQb50nTn/60586sINFA40bN3aMl/wl 5Ht07/Hxj30Md/36l78qXqyYHkYMH+Gnf99993MrVlxzzTWf/cxn3Vr7W//ylzGjR/vp61// OsuTSb/9H7f72r170HVPbtu69ZY//9mZL171RQNwULRoUUP97ne+S2aSeKT67f/4x6HDkVHq PVGY9rNmzvrSF7/YpHHjMqVKXfPda6ZNm5Zlrc0i6rN8zUIiDerXDyr6WT/n1hpcsn79+rxP PHFg//7kQbL0w/b2veuus0JFciymMWTg8VetXJml5cL5C0y+peTc488+zuxEbzdeIF++l154 ccf2HTVq1CRCAg4k++esklCzMaNGf/5zn31126vWi+98+9tbt24bOWK4YdsdnPWVXTjjedp9 e/dWrVyJL47DAJXXrlmT6HtlyytBbQsikfb49KBBxYoUQXwMJ+PHje3SqXPRwkU2b9zUskWL B+6/P+/jjzdt1IhBJfVNWOybN23WsWOHl1560Z6Q2aZyxYpbtkTG0sTEgmAPHz70q1/+8qpo j5epah7YHyQe3WzrK1u9wv/5n//B2mYk1/33h30dLedvf/3rlZ/6FPfFiuXLceP1P/gByCjx 9bGPfezRRx5hSkXuv/rVr55fu3b5s8u+/73vfeMb39i9a1e7tm01+OY3vwlzQw0mD3XYrGmz iHliNZXW/Yn//d+HHngAb6Own//sZ/afkDomgXB2U+179+q9Yd26r3z5K9ddey0pF15tgwYN /PTYo4/ywcycMfNb3/qmUS1auNBk/u63/w83mh/KxQVAeXTuWur3ju2vOc6fL999993rYNu2 baR0o0aNyA2moA4dOljsKlWsNH78eL+aPQxWoWLFCRMmWEb7+/Tt1759+759+qD13/z611On Th0zekzXLl3r16/ft29feweT7EldK+1VyxYtrarI9403XgdB7Na1K5EFR/HG66+b3s9+5jPl ypazGw+i4PChw927dStXrvzokSMJ/0YNG331K1955OFHwoZWhzOmT0PKq1etHjpsWLeu3WrX qt2nV6+XN7/M4/W1r32NimFuF8xfULlSJauz9/j2sbcZGgy1d+/e8+fPN+zWrVozmLOu165d u3//fnQMQrJevegBJ0+afOjNQ7ZCn/70p5944gnaVvfu3V/dts19bRkqVKjYuWMncqxbNMJy NlCJjhxeXLJDmThhwnXXXkOhe+CBB1CLm9Kzvvud79h9XGLGi5aiyZOrVanct3dvE2pZmj9v Xs/uPRgVkiXZxBFfdWvXKl2iBN4rWCA/bHTtGjWeeOzxhfPnFy1cqFTxElTNxx99ZN68eanj 8wLwkvfXrk1b74+QbNywkYmM22RoAIHxfnnTTV+86iq6QZiIAwcO/uynP2Nc2bRxE7fEtddc 861vfSvMY4Xy5RE3kJq3/feY8RZRKU+cuOOfd2AnXPf44499/OMfR08jRowgJ6+++ms/+P73 se6nr7ySyFm/bl37du31QNsM96pZvYavhEm+vHkxcMJ4D+bK5cEt2L/+1a8w3sYYCeDTqVMn 7b1dmqQDil+w1Wh5+23/+N///d+pk6eElsyYH7viiqcHD3Z8y5//5BZWorO+v3eVfq7CeD/+ 0Y3r173k2GMa1fbXXnvwgQdKly6NDRhvmIK+fvXX/3LLn8uXL2/GVj73HDpmMKtUsSLSIf// 9te/0R2KFyuKmH584423/f3v3pdrv//97wPhMiA98fjjjzz88E0///mePXtoB48/9pjO/3n7 7XT4z332s3nz5OFM+v3NN1tWSpUs8fWvX61zQsbg0bHjm37xi2rVql1//fVDhwxF93g7f778 mD+T8aYbxuqVq+jhN97ww6pVqnztq18Z0H+A4V199dWYbf78BT/+0Y95s/7+178ZCRv7d77z bbxqOaMrff6zn9X5jTfeYCbDJYTkvGeeiVaW+Hk5kO1Hrv7a14x85IgRX/7SlxYvXITrvPpy 5cv36dW7Vo2aP/3xT9q2aQvnGI04/jAH7tu7J1CjiaXu6Wr2rJkF8hf49je/2aNHjxGB8V6+ 1IxnUlq2bNmsSZNpU6fOnjWrQL78hZ58avOm6DanF+Z4E2jBo4K21rhp0+FDhloL8z6RZ+6c udAtlhOYsjq1a82de4ahXCe4ZdCAAVga3VAz3Kh+3bpvHz29u4j2eIcOeWfUuUQPsdx+77rv mcRXXtmC8a757ncxD1+iDpECcqcVZzDelVdivIgfOnZ03j7zuuuuu/GHN9iU2gqSk7RBK6tF vXevXkOGDLEussdoSVC4yt2ZdpiUCEYnTTrl3rJH4sWM58W8GUnjq64KyoYP6f31q6/+7ne/ S9H9zGc+E7TrsOdElJ/8xCdmTJseWt59190f//jHRg4fbtfxpz/+0TpCfl4s470UMR440c2/ +x3z1be+8Y3q1asRgN/51rc2rN/wk5/8JISE/b9f/waxejSbAjveb3/725jtnnvuKVuGsh19 /n3nXcC3DpB4sVjBxsl2sLSeG274oZf1oxtvLFKoEBFHsg0aOJA2sW7dehTyg+99nwCc/8w8 rLt7d4SsoBQdPHDA5W7kq/UrX958NpA//clPpkyaFJ7XX+IUBa9ZvcpiUalSJWd+8Yufe4/0 +R//6Edert3NH3//B+fnzpn9/eu+x8LHrNWhfdRnty5db/7dzQ6KFStaqlQpBz/76U+s4wcP HJw0cSK59K1vftMBU/uNN9yw6rmVa9aspoksXby4QH6mwLzhkd3rB9ddZ80KLOeVEQx5Hn+c HiHsJrTBeFh9x47t48aOY2nXDDE4c4kZz51wfO1aNQkBhIXErZED+/c/cvjIGVvJmPEG9OvH X3fLH/8oIqFVq1b0GS9m5PARsNF33XFH7vvvb1Cv7jPPnFY1g5pK139m9pxXX3112bPP2gKx x9SqWdNXUiJZ5smKe/59D7q3CmK5I2+9xQNBdPzpD384fPgI1RTjURR37dplwKVLl4kYr3v3 LIxHInmvn/zkJzEbQ5GWtsX/8z8f/8Pv/0DHCNO6d89ef1u1aqkHARaBJmgsDvCbd+a8NXLK pMmB8fhYvFpbxM9+9jMzZ8586+hRQ/VQeZ54gnS1M7zlT382gYm1wDvWAxsS4TNr1syvfvWr FNpNmzYee/voJWG8SNWMTbhUuHz58nF+WpuEokTaY9++r732Ggq2uGjw29/8Bh0XLlS40FOF xo8bT6ZhvHvvucci69djb79929/+1qhBzHiPPVayZElbod/+9rd0H4IRw8yZNfuGH/7Q47Rr 165bt+5Urx9eHzEeje5HN9zw+o7tkyZOuuGH16OKTMY7aHnq1DFikvzYLm9eKr3BkDxZGG/t mtUYj2LpjtScXj17zJ8/z8xDbjA7sf1qz8/pdbNzSOM1NrbNWDdN4FtH3ipSuIi1wBnXDh40 GF8xoowbN55YmzB+PDObBZqoF7x23XXXLlm0mJvXJ7x9HwqdJZ5QDZYwBGrPXLBgweBAThiP Yd80/uJnP7eg6Pa/wnicdZUqVOzfty/RRJR5+LlxxrIzlJ9Tp6KtUes2jz/yCFNPoSefZLKz DbUXomHmfeLx+++55+EHHyhVongWVRNOSle8eeXLlitbqvTLmzaNGDacO962J7lFsO7QDEkP VGtl/fGPf+yAAAxKmhWBpkcR4rjz9amnCvm1U4cOGA95OZ4XbywjGnr8CV/pmfNj/yEevuvO aP/2zW9886+33oqSbM8MqWmTyLjCrBKuMvV/+P3v//ynPzn585/93F2gwx3f8c/bI9Pf0bf/ cdttvtqxMI1SuV1Cif30p690I8SdPIiDCRMm2ohrHGm2n/50tHVsEhmT7F5wL15lbcs6t++q ZcYNXEXaXPWF/6tRowat8qc/+TGf/ltHjtx9513snLiOZ4V8u+GGG/51xx3aWIOsoZ733nvv bdSwodEOHjTI17qxnCeBWYft8ZYsWfLQgw8SmJw6P/zh9XCGzlAR1730Em7MlStXv379vYXF ixfT3J5f+/zY0WO+8bWrX3t1m/0IzblunXp8sJH0OHnKevrLm36h/x98/3vDhgy1xuknvMEw /kzjynN01zKly7iEUIpcVnNm2w6w6onq5DtlD/vHP/7x8MMP79u3n6pJrLmWfmg5sI1kFi5e vDgWcS0VhsXBIBs2aGjHMWrkKHa1a7/73WJFi8nR/OUvfXHJokVI9Jvf+EaFCuXJTLLOpvHv f/ubBciON4iWQAPJMaqmVFvr+/Xrd813vst6BJjlzMZNZ4ccX6BxxS3ZAJh9Md7G9etNk72s dTSb5fTU3j17atWoQdvs368/QUdjHD923LgxY7t37fbEo4/16tnLDpjUpnNnIayYc9bPmTnr 1a1bEcrkiROrValii5jaLIwe7z36yKM0qN/f/DtK7MQJE6MZOXmS6YLW7n1gJC3tCiypqJCk kujCcsXOHhlFTv0H0gUNiRikT4Y+Ga8xmLn+/e9+h23sNo8fP0am5c2Td9SokWHSeRSQoAW1 RPHiwYPPKmMppQVYF/XDfkhJ++Mf/mBxpXlqsPWVLV48gYYWkwcJkpPZ84FcD+jt3nvu7dun L/Jykt7VsH59BEFeZZvb8+O8k6dsd2vWqFmmTBnvi0IY6AWJoHVCb8yoUXjg5z//ueelyJFv brRi+YqKFSsxhjVv3gwcp1evXjNmzAz384y2RowrWo6MzSFt2rTlzrELbdq0KdXLbNNrSpcq jb6Z3CxPFDANoAvsAL3KLp0716hZ004s2SzR9umBQ4cMiZTPgwebNWuGl8Lz+mvRsR/zRiwT 4ydMwPyWLZYSYkqfNiMeiOOX8QPgnvT2pnhTV65cpQOLSPv2Hdgdhg0bzt5o9SS6Vz5na7Ky YsWK7dq2a9q0mS+nTp4YNmxo5cqV586d26RJ02ARwUulSpVs2aI5FjJ7xhC2nYnCmbxBJ9nh 2Jm4o5cvX4ZaQD4YKfiHdu7cddYXd+GMN2rkCM9pO2TG+/XpQzcI+JIsH9qzrVqgVK+qZ4/u S5csYSgfO2Yswg3nWVCQfhbGMzKq4+yZszp16EiVJbgtwEwj2ZuFTuyUCJlwHCGLjx9PlqXw Nfzk48WEg6AuZsdYnnFh7BqJrzrt9c6Yej6tlMspk4Fb4saZ3Ub++miNDOexPVMNs0TcQ4aV KBpqpgNdJ8k4Q4vw9UK57mTq06VOTnIXB5Re3kJrfGaD03OV2syDhDiSM06mTGY0pbGqknxQ aXwy4yniB8qYRi/Fw3oXqSSYiiXIJKSM9kmz5InCGV1mecbk/SYHJzIHGRxd2T/ZZyk1f0Jq e2/8bAve6YfKmMNMensnxPyFM97oUSObNGw4aOCANatXYyFCL9ipsjLe668PHjjA4rRg3ryh Q4dWLF/e1q5e3ToWcraKFcuWPb92DRGRnfEisjtxgnmDJ501zBJr09+hfcSrZ9wiepWR3yKF QDOwIGG9DCQb+zair5nH0fnIG5wZphS3cybTaXoiK946/JTKAKk3DbfMaKCnTIdK8s7sdkDG f/Ob3/zPxz8ePGkp98q4NpXlkmdMHuFs7/t8zp3hBs4YZ+QGP33ezpxxclkmHj1pk9F7ZsvM Z8zwFWUAieKOwin/S+YhzHP0Y+bf1DPJcWr7cDJz6s71aPFbzHiEjDd4+sKMyYxXtvCM8WsO RynPknqD0/fNPJs8Vvxc5+tKT52qcNMwK9kf5mIYb0STBg1sABg/+vbuQ1PasX171oX51Enb 6B7du61du2bJ4iV0D1av4sWK534oN92M089+w1aYNynVgR5GqSsrIhvM1MmT165ebXfets3Z GO98aO+cbc4hTM4qbcKUZZ+45GTWu8XtOSHs3Ig7bqjwdBc98EvWQdhRx+p5+vM+zcDFMN4o sqtf374vb9o8fOgwaiToY3Z6YlRo3KD++LFjJk2YaBNFarEWCH+gNDLiUbvpkFx8z8zNsseL hJgOqZqCD2wbJowf53bAIqkSL2gyWT6xKHv3JSqs08m1Z7kkFqRZnyhDrGUsDUGlJCoTXora x4tw6gt0jl4wfuzYZUuXXjzW8ZKTRliUz2fSLvmtP7IdXjjjzZo1i0fO7o6Jn1zCVCReNhTv qZ2vvzH06aeZJWV5GD9u3HPPrWCoFezHz8bzvmTxInFmAVR9pg4ZEf3uXbsF+DVt3Hj5smep alUqVZaeLGmGUN566whQKLACRJx/0f9ff8NW0xJ+Pm/Utg0yo0XzFnrI3p6tr3jRYpCWYJ8Z N7UTO3Vq5vTpDRvU50WwdWbCejh3boYZXgoGJCsFW47gpuyyI3V1OJ+xpdt8uGfgwhnvpRdf tGGjZLKckntVK1WGLcimap7avXNnm9atGJHZLZk07QnFH4wYPnzqlEnMaM/MmQPCUrlChSyq Jqai+SyYP09L1iHBdazD3AlgRwnjOXj22We5azm+v/+979/wwxt++hPW8p+wPmfdB57tHWoD z816TgPs0L79GZfEu8ED+w/w7TA3c9QGPSwe1X969+x19113Pf/883//298pzLkffIiVuU2r Vjf/9ndQS4zXwXvx4aab9NNd5AxcIOPZtRAIsGAd2rWN4NETJ/bt1WvksGEg3ll4jx8PQgUQ wVatXp3anTq0nzVj+qwZM8SniwmaOmnStMmTy5YqlYrVjLekkcmLnXfixEmECfNuuzZtuCX4 W1IZD1CLP5S/FSry+ut/wOuNi8ZPiNCG4RPUp3DM4JYchzMEJgt7rvtzrVq5KiiHqXKJD5SR nRvQEpN6vl+fvgBQrOr/uO0f856ZB3ixcOHC3j17Yjnu6V/8/BfBX3+RLyZ9+Yd7Bi6Q8QKN Mkvy0tDWGC25E3r16EmyZaE5+h/n2/wFCwYNGkQWsX/CxYEOtG/Tlpth3JgxrNhdO3cJ+Npk rh2/+MKLTRs3nT59OifysqXPRpCxevXejhDrGa0i5nz7bcIQcAyUjDMN1/3zn/90hhWUX5GM 1fTwkUP82pHR9QDZvA+wYMaM6Ry7RiKGCMNjpNdf3xFQzgsWzHeeXxV4JUBPOHO576iRTViA ZkcgL+VvwRpvu+22alWr0YS5vAsXKgTnTYCDlYJZ7ty1K0H0fbipJ/10FzwDF8V406dOg9Vi q+QlB03gN0wiwRMRQeJhMHEMUPDQJ3yRi+3rnn8eAA9Kk1bmQxcNEi/1s2fvXszTulVLTmeQ P7Z4PsNEiMVSMXrqcAlNVYwCkMRS1ov//IfqG8D+jnfv3oU3YAi2bttmt/blL38ZWpIL+9NX fgrAh5aoZfC589sKSvDVBzrp0KHDv/zlLwU6XHvtNeGk2KJFcTwbvzAMDe824QZ8LNo92l/u 3MlRy88bocMu+IWkL/xozMCFM575sQsSWQdrv3DBQqSPjnUnxiR8jsrRc+zY9ldf4zSHwo/5 oQ/XeWAVYTUCTMMxYRLhvk+eDFfF/44GnyZLyboXX6SsVixfAWIzizh1iX7hG/9yyy0YI8lH OGDAAF/hVLS3KED04UlGIJLQpg4CS0YZ64ULBSx+/H8+PmvGTKoj5gTvgquIIi3mz+eWxHga 61zyeVApfYK8ZFkgsn+9rFwFHw0yznlPeeGMFywNZAvjXpVKlbgHunfp2kUIXdu2Hdu3jw/a AUbyH1SqUKFzhw7du3QRU2eb17VTpy6dOrVs1kxcpgP/BA3Vr1vHgWtdqLEDpk6XQ8oBKHVo 115wQ3auCxIPCAhL/O63v2MFDWwwcOBAZ4SWOBa7ASKMozIZ79uEHkSSn/D2vffe94lPfILH AtzUJaVKlEwYiWYKF0sGBldHk0YRUDOEJuS895we8WU2AxfOeIHoyROM0axxYzF1AszBncFZ alStWrJYcdgUdsiSJYqTV+wiUoxxxLVo1hSXVqxQ3p4NrlrqB9wovV+F8uVEo8vCAjztwJap fNmyMtuKCxbhDvgXAo5SZy+IRKBHGHAIY3HWCc9AtWKSggUKOmNrx/KZMJ4wEPbPkOKFQBYV ivHIW+nMXAKV5nyYFPKQpcSFIdhPUJIGHirNeJcZDefI4VwU4wXeY9IUEsrMwJjO9gjNLEpN zPi0KVMdkCQTxk9wnsSgjjKW3HfPPYLBxRAJNxRiSLUTAFq3Th0ijspXl+WzY0cxfngAZzYS zFi/PvuHG2X18J44CZ4pegM/PFmwIMuJVWDXrt3YyW7QSeGYrqI3iuYWBRMkHsZjBQ3xYIHx /vcT/wtC2bB+FAPONBJyfjLb4NjAeHzfacbLkdR9GQ/6Yhkv5r1TjRs1Jgrq1a3HrMevBRVF HEWwzMaN+bKLFC4s8teBXH033nCj8BPmeDEX4tA3btwApSnEi+4HPoYnwcapdrff9neARior BmYtlEkhOx4FMzCifupTnxRl873rrrWRu1702HXXiR9l5Rdf97Uog8DDbiTQTiiKZAc8H1/5 ylfiCL0Mxrvrrjvxm+Xg2aXP/t///Z9jO7q77767RrXqkaj88Y9lTAlRtqJX/Er8piXeZUzP OWZol4DxdCHEA2JDkIHkFrAsQoDhbhkwJ44bB8zRo2vXIYMHyXriQIRbrH+W+MY3vl63Vi0h RXJptmjalK+MRte+TRueCciPAX37yWUiaqNkyRJCE95pd4dp+bgF2tA2JbqQSuhrX/uquFtG mqJFikoJwV5SoEAB2YfkPhAwwhopPYGgSRKPNkniiQoVqC+oxC369O4jJyet9cpPXVmyRMk3 3zwoQwTx+EKcwkyGGFbNd9pq5pgXnh7o5TEDl4DxgpWFIle2dJnmzZsjX3Aqhkr1Ejq1b1+m ZKmunbrI605vnD51CiVT2pnyZcpiBtksbJzq162HY/3jKO/TsydoGBu9/EhqLURxbjHRv9Nc SQYvLdTpj+Pt2wW5eCoBLMRvCKySzUGzYGt9fcfrYGU0yeNxrBAOZF8NAU1hy2ozKdAJPEAM DCeBzjkJPCNbi2eEGk1jGi8P0s3Zo7gEjBcmIOK9ba8KJcRLHHpt2rQWB2R3JIpRRL1/XNJQ woKgBQLLsCBHC1w1kWV/JcUFBJYNGKEnmR+/vA2eXNROnluvS6wpWQ7CeLJ8AuI5nEwc3Emb yDNxZs3opJPgHkhtmbPfeXr0l8EMXDLGC2HUZAtZx1ApE96A/v1BsZIb0DzlgChfpsyTBQqo RpLniTyMnPIOLJgXGet95JKQb4cuV61K1Tq1a2/bGqUGuwymKD2E9Axc+hm4ZIyXyD3cItIH DlNFBF4v6BNGS0Dn3Xv2+NuwXv0QF8MKKlWE8jcRimXaNJ43fMiAoaIQeFeI/730j5vuMT0D l8cMXGLGS0DJ9k7SYJJd0kKxpjSoX89XyWSLFy0yacL4qZMnVShXntuAVGzauBEHoH8ay/YX cmCmue7yII/0KP5bM3CJGc8wQxR9YB6aJy8f/zhnQ/Wq1TgY+MS5B2r4r3JlTvOqVSqrSaIc lwwuIuoyWC4leP+/9dzpftMz8IHOwKVnvNTHSQwSUJ2SK4p2le5TZJ0SsIIS4EXomcrHnbZb XE4JET7Q95K++Yd8Bv67jJeksnkn82OmiEvnHfiQ01n68bLMwH+X8dLTnZ6B9AycdQbSjJcm jPQMfAAzkGa8D2DS07dMz0Ca8dI0kJ6BD2AGPpKMF2w+mZ/zmfX31PhdO0y9eXbkZzgTRWOk ZD4+V5+Z+Zsv7SDf9SnSDS5mBnI242VHY57PXCDULBe+61WXFqgZYOXJJwvvqScQygBHjBRV s36XD7R3AjJVGyCN4X63Cbssfs/BjGfoEpCJJFDDxUeKlMT/fu5k95oJVgLR7tipk7ydIhIC DPqdPn5dvWZNz569xDGcu+V5vlIDWLN6jVwZ3bt1X71qZZY+fVVnr3jxElteeeW8bnfqpIrN hvf88y8YQMoacbqkxHkOLN3sfZuBHMx4KEwAqwKOii0LxpPWUshcVAg6qFyZJXgcJEIgZIuQ 4EwyCFnJfvXrX//gB98XOBsQaoFkIx0vviTjZCxNVFFWhW9BnE43yKLkwHGYxDNOuntSR+WM WhnRANSjEkAo0k8JVaWJw02TSkO+CtuXSDcpc5tUPgoqaBhYUnbHVxVdRB7iPceyYsvYLWGh XqU5DWWHo/7T4IT3javO40Y5m/EmTpz46U9/pkOHjmKO7vxXVEoS9jr1kYjBKNleZmklxA0L qoghupdmQq22lzdvUhA8cNHevXtCEuhUPsSD5OquXTvXrn1exs5Enkj+Jy1nKr85Vv8tFLIy 87hFbbTdu/YEvTF5F9JVSMJ7y5/+BCAu6yGJnSDsDr75piSBcoS2adNGVC9MuQhj5cdSxyMD m7sEXtW/TG6ORQkKXAxh9YraWVNCugqRh4Lyk6Lt50EP6Sbv0wzkbMZTAfiqL1wV6qdLMi0a XeoHRRQ6deoo64TUg+o0pJZN10w9a/wp5C9hIQc4UCDS9773vWu+e43KktgMyrRixQq9evZU JlL6sxUrlovKFeCLGYoUKdy9e/e//vWvxKZKLC6H9q5Vq5a6hJLJ537oIdyC4nPdd79q7IqD Fi9WLMTmxlLq5JEjb/38pz8V6r569ZrTYvP48c6dOunwW9/6drkypQ3v61+7OveDD6ru4kYy d5LkkkpJhJEvTx55QQUZlyhWTP4YgcUwd5s2bVLYUZZeqXu///3vKT4uf+GggYOUQZUlTVpR 9d+tGmmZ9z5x1Xnc5sPAeKHcHBnw6KOPUgiVDZMB6ZOf/MQd/7yjR48eGC8p3aORDLyf/MQn 1CVPpJCDfn37OVm3Tl3JNr/whf+rXKmiSPZrr/nu16++WtXyBfPnhwy5KJtodfBArlwSY197 zTWqr7BnPPrIw5/8xCeFIFavVv3jH/+YMoCkaL06dWfOnKXqqqroI4ZnVPQOeqngep1IAwMr HmSsYoNXfvJTTxV8UuXuaVOnafCpT35SNaUuXbpKgla7dm3Z5tVzJ6uxk+f62BVXVK9eQ5Jf Bd+HDx9uYPJ/eljppG6++feSO+XJk2fK5CmVKlV2F0XGW7RoIaY+bXc5D454n5p8mBjvP2qs KyA+/5l5aj5ffbWK25EOqSxoQnC+ivdD06rUZzBeJAVOPProI6ovBKVOaW+UunHDevJHnukg lDCeXCxKN6qy4kCKNCextxzvbx48IKyesMWBG+NkSnZofnVepRZK41VXXdWkcZQGNxJ48Rpw 7NjbzCo33vBD7KcT8vbJgk/qYf++DLy4pGxqNrwYB+Cr7S6HmtxnNrHKEjnTrl27r3z5SwKv rA62uPICW2vcpWfPnn4lLV3L2uRY9hqrg7ymqXd/nygrfZtzzsCHgfGYWBAWmlZ73gIvhYQg 9x/dcOOBffsz9MlTGVusQJfIXXhuJCIzjSKqnP/5z3+Wy8zJwk899aMf3Sj3EsZTuzyD8fr1 y2S8ufKOKccZGO+mm26SEwnj/eRHP4qDel/A8HL4CryQRRffyu1px2XnmZB+YoORWub+++77 8he/+NILL+bO/fBvf/tbwjncDuMRtspq40kGmEJPPRUYz4LiV0kTv/XNb0iJv2nTxm9945tN mzSWoA3jqVTuV1U+pc1evSra48ntfc13viNxcHjYNC9cPjPwYWC8efPmI6xhQ4dR6iRaJ0/y 5817w/U/3LN7DyqP0hYpdRJ/NGPHJxBQuaRjEY3LOX/0aJlSpSXefHnzywTSH/7w+7/+9dZX trwsXyCKPyvjqeXgvLydzCSB8X584402cljl61+/WqVbumgkA48fW7Vq5Re/+MWmKRLPSfUk QreyHhqMjEw1alT/3Oc+F1JWR4zXurXx2E8eOXLkhz+8PmE8i4JfW7Vs+c1vfF0WpsB4zZo2 SWU8aRaxuiVAyy1btmhQpnSa8S4fjssYSc5mPDsi4uuvf/ubRJ0sCtgAsSK4B+6//+qvfVUq aHn7ZNGcOmVqEDiB94TCf+ELX7jh+uvt3277+9+nTJqocAIr4q9/9evb/n7b5z73WXwlv5hU gY89+kjgBNYUN1q0cFHY49kKOkmgsce4S+7cD3FoOOAAkM+ziZj6GjVtGnPlyvWnP/5R+9o1 a4YBUDTfOnpU1m2bwwceeMBmjFDl+mCTNE7M9uCDD1WrUkXCqOBOOHT4kAd5/NFHidNvf/tb IUVvwwYNlHRWHWXd+nWf+fSnpfpUJ8xdOnXqHD1dr16Ob/nzLSqHSvL7y5t+oe6KwkZvvnno sqO+j/CAcjDjRX7t1avLly//1JNP2iMxLXJhoTx03LdvX5aSw4cPod1ixUvIlptpVMwogrdk yRKZJvLlzVumTJmQoX3pkiWly5QhWzjBfN2/b7/k1gMHDoom6NSpRYsWlStXzsZJ/s9y5crL FoOJevfu3ahRY0qgBBb16tU/fOiwnLlVqlRRBkwy3BbNmxmXHNgMnqHPsMezFRQK7KcCBQr2 6N6dwyNTFK9ma3niiTzdu3aTSLtq1ap6s+1knlGDRQJCObVlpqEvsr5UrVKN319hzWrVqqki ZmDlK1ScN3++rrgWWrVspX9Zfd1UGaZiRYs1atgoLpT77jiYjzAvvK+PnoMZLwvwKoim4DtP jsNBIu7iqWVXzJr8L0tXiWxMlZOOQ82jjM5jX3y4Y3KQfTazDCD49pOTKWPOejK6XVzMPdtd Mu6LiVNulzGwgBA4PciUeyWmnfeVvtI3e4cZyMGM54kCICP5JM8YzoSv72RUOPdVSedJJ6kd huPkLllud8avmbfJMv/Z736Wx3mHu5zrdpmPnPrUqe3TjHCZzEDOZrzMScyE88d5ls49s7Ek OXviwFAUNsiZiA1SOzpxdgY+U5ZGl4QJvbC3G+RbKt8GGXthvSVXpfYQS9ywZFxst9lHFeT5 eRpPo3m+yAfLyZfnYMYLalXMJxnFzVNddmd9KciCnVAi97MSDaZl6oTw0HOis6WSLzY4gxmh yQ4dCkBKn5DS9+jRt0DMLmA3hR/Azdhgjx59O1Bwklz0+LsFKZxDpgW7bpZBBlY0d5eWdJN5 i5Ljv8MKmDHUeInxXJd2ADmotxzMeIYu/bsqPw5e27Zt5MiRGStuCj1loUgvm9Fvfpy7OnlJ QcI4M3bM2LJlynAqRILr5MlevXoqmB54+9CbB2vWqLEmNpkmOiFoJQxXEhWhKkP//v1nz5rZ qWOnpNlZNcwst05t075t29WrVrmcfaV69erlyparUaPmwhicfVaqSgafNIjQ1plNiTWrABvp nrgsWXhMZiR2I3lMzd5Zx5mI3NN3jKYoQ7s++zD8GkmwE6Bt3bt1MxWhWap+Hs6E/ScLsLLy qswT6HGb00tA/MoybhIdXerV4TJhzhzMeN4fFOWwYcMcrF29mjkxxazwH2rMGV8zzQwd2rdX F8VPQeVKbcNEmdRIQQ4lixd/KNcDwavO38BTFy5MPvsP7GeHJD/DGX48BlI2RgX9UpvFq39W m0pQa8MnlSKV5gRDcRICUywSg+2Lz78AL5baONFmk5PPPPPMCy9EjrvsHzRdpnTpBPzN3aLP uXPnrl+/HtLgrFOUejI1BiI5HwaQxZATfuUyZUNOFqPs42FP5tv0yM8tXx6gQhmTQPU9ccac ZJmfy4RhLtUwcjbjATEHZti6ZUsokrx27RoHEF4onS9B4T4FjJT88ZxDnh4CzIXspPcM5G55 htKEhLT245l//ON2QOdDh4CJT1HzlLYtVrjIizFBk5PFihThxHPVwAEDXeK+Rw4dIiGbNWuu OBmfOAwXMSUdfdPGjV0yccIEjgTgSb3Fmt6pdevWqT0GWaLw2PbtO/r169+sWTM98+D79O7Z S4F1qLckGogDoGbNmkYCitm7V2+IcEU2ZSilD/MouESue9VdDB7MTb0xGG6xF9DhilhzpZBy XO2G91SBAkHi+bRs0Tx1+bBqqJ7rcaZMnkT2zJgxs0uXLk0aN546dVrTpk1HjBjBf6j8k3ir nj17jBo5yvysX7/hjTdeBwQ1FRz3oS6Np2ioEsaYsaIlxowZy5uiTevWrT2vmoRmHgZ9/Ljx O19/49FHHgHdduHE8RN4VlauWKGUd9u2bT2Xik5eh/cFgkPfBtCrV68e2PdpCXipqP4y6CeH M16PHhxxFDz0V6N6dZuZmjWqL126lMyZO2f22jWrVSnqipQ6d/YWoftR8MO5c8+cPiNQ4YRx 413F+6wi9IplyytUqICybRTDm27epInqYoMHDrRjaVCvXtu2bZC4gs9g1oLcSpUsaWnX26hR o/jxlPJbv2FDsaJFpk6Z3LJ5c5KTgrdi+Yry5crjk9Dh2tVrli97dvCgwfh/1apV4pjokGTm ooULJ0+ajDQXLlx0/733GXO8LpzikYO6tr/DLerAvPzylnJlyr7x+uuulX57wfwF4h6sC5gN 0UNI099g06wOHdp3oAh07NABt4wfPz7XffeFrMH4X83QLS9vCeuOvwL5pPQGDADIVtUMB5ol K8uDDzwAzlr4qULLly2/9S9/GTd2bNHCRejVVjRTQWxWr1YtWo969hTN6NdHcudetHixsocW l7x58ryyZYvGvKkrn1u5bcuWObNnqZgtOmnDunWtW7cSh4Eb8z7++I7XtoOzzZhuwO29Jrgf RUsVG9W5laVooUKehVj+UNpgcjrjdcc5EydN4j1HuC+9+MJDDzyABIXwwDELz1F+CCwLir9P r17oA61079o1YTyiaVG8fVK62RIuvGD9+nW+hl2HIipCSJX1e27Fii5xmQegUChKQkybIUOe dgv4LMoVE0uNaAe42r0wXpvWrYiRpwoWhFp+5OFH4mJjERR7z569cG21a9dRBX41aRzXW+cc VzJJjaTFixZFEql58xXLl6cwXjWi28Ixa0a0WACg7Nq5U6Q5BrMXjW8XgXKQOEf53j17H3zg wU6dO4uHsvRUqVgxCDq3c5UDXcHQIPqE8dxu7uzZvpooSb7bt2urHwjPRvUbOFmnZk2kryq9 Y8vX4oULYdAUuLeiQc84CbNqVmnXVA9fmzVpGuEQSpZc/uwy/JzQlqXNSzG2DRs2KBplzHTR EsWKLlqw0AriwmiJqV5j+fJloVvIoeHDhls+OnboGJaMJKLyMpBVl2YIOZ3xeii57sVs2bwZ HYPzI3cUbBexbdurVStXUbeoV4+ezZs2xVpjRo/REouKQI/kXUQoTYT8OOjTp09c46Hl889H dTAD4ylstH7dOu3xtj5Rw/Rp05FmYDzhORivdu1aGI8hVJsMxpscM17/ARaC5cuXr1m7lh2V ukipU5hFvomhQ4ay06xa+Zy7h1tPGDcOPwcLCjVvxbJlWRiPNJg5Yzp5VblSZbqfZPj169XT Zt/+/YSneHYYmvnz52G8fHnzzJkzd8WKFQBlFcqWjRjv1KmK5cqJMAyP3LF9h4DwDh86ZFC8 RTnFjNeOVCf6LEmmgPoAc1eubFk6uQr1JDPgTq0aNaSrSBhPKv6pU6d4Cp24iq2rdMkStsTl SpdW/dNJJRCB4BYvXkJXN59DBj89bep0ANfiRYsuWbS4Tq1a2hi5NWXF8mUe31cQ9rHxy/Jy K5YvB/j24bOw5GzG69ShA7LzhtauXmWZP3L4kIrQY8eOmzNn9tZXtqrCZ9OCRqtbpNeuLVu2 7IwZM/55++30yUB2djIVCY2pU9lRtmx5GcosWBRjxjtRvUoVYT5UtVtvuQW5d+3WbdLESRiV MjZt2lS6mQiAu++6i/Ylao5eR1oWK1x4wrixlDEaoOKbtCb/mBDYcWzkShYvMWH8BMTtdkgz ADi7dOo8dtQosbyRfjVt2t9uvXXZ0qUx451EjuwiMN842bpgVJUrVcLSipm5+7atVLjZQn7b t21H4tE2d+/ehR/69+s/b94zIoawa/v27QcPHqTEvP1neK6tW7fBqhmzqaDaPfPMPHFStqYl ihWn1EGWkdgUh9o1a5gBxQynTJla+MknBUlAfs+bO4eSSQCSe+Da5u3BXLlEA5oiMln/BrZw wULMbxMrWMmiYAJ6dO9mxZk/f/6/77rTRprMr1O7Di0gz+OP7XzjdcqzXZyWdolUaOuXfhg8 Bw0Y4OmETRbMn4+4jhnvQ6Vy5mDG8yps53CUA+YTlISyrNYtmregpciqYLPEQgDfGCwco0aN FlBDY6RrhU0XKUT+MGYKnGOnmz17Djt4+IlWNnPGTK9cLDnCcvLZZ5996aV13j5SYyBhGGRI wIrdunbDdSLfhPkISF+37qUgEl2Ojok4VhDCSqcvvvCiMtQDBgw01Fdf3Yaw3IcNEwNoMHjg IMF77CUqchqAreabhw5ZGt4+dgxSFFc7iSXQqBxJrvUULVu2tDti15HsqEWLlhs2bIRWpTC3 atXKGYKCqta5c5cRw4YdOhhbjOJ93Yb1G8RGNW3SFOLUyfA4OjQDwiNog0L4bWbNgOAmSw8r CFMHcaeCvFgkthn9WCMYThTTtsS8tG4dY4n2Otm69ZWxY8dQHQ8ePEA7ZXbasH4dZcE4hw0d ynwiSNLwbJLhV60pONBusFu3bpCufsVqfBI0BTrLwAH9CUD7z2gVjLyCaca7NFruxfZyNhzj acRjlhUlC0IyZq0zai/7GsRgGFZG+0x3Q3J5oN3wyeKxSAFyngZwRs0yP8mFp3vIhJVmsdpn ONDjeyV3yfII2Xs7x5nEMJh9HlIGkzF7wcmS2jLJCpM5RWdBlqZ6F7Iv52cdW+pkJpdk91KE 7FUXSy6X2fU5W+JdZpOZHk56Bs53BnI244WlMDyDv/+NdfG8nEjvgOTM/hKMMAMReib67Hxf 17u1o6clYiQW25dOUMT5qoMwjKc6gqWE40QipaoM7zbSj/rvOZjxImTgsSi5nWc4cvhIAApe SlIL4XMAlJlozOzE4tY+4dbnRUoxgIad8xwpn0Of59XbmY3CTlL/zDkh7V8MXr2Ans5ySUaw VZxEmCE3mvaTMqYd0f2xY8cxYvxconwjS+alueWHupcczHgBlGxbz5gmHlQmr8R+EA4CBWec jMD4Z5yMfsgkkYTQkwszcsyePMkAGNIohJkKxJCx0mceMJ8wHjCuhPMZvUUwwwBFPM1FbJvA GdBtsgwi3+R2qaPN6OJsMUEBpZ3cInNIp/tnfhRcW6tWTaCZZc8uCyDIlIfKGH/2543Dfc/F 7R6Njy6a6qpVx4we/eqrrzVu2Ei0LjOmK3kO1LiHs6lZs4Zmad5710UjBzOeoUNISIk3e/Zs tjKZS84EQJ6BwwxaEBRI9l0+MRkLh+NhLlIrKyDFjRs2nC4WHRN+zF0Z3fCYAXIxq0iORBSk dp6p8sX6WCa78kZwasGy6DbcNwnbTa6dMGHCypUrU7six7MPO+PNRewSc2PMj107dwFzEboO xsUgmfJ2U0N44+CjTANSKmDVc51VdOtH5l9wNu51YLfXXnuVvZEbAGhG6he99ezenbN029at 7psYjd+V+D7KDXIw43nfDOuSWCZEiWgGDRhYpWrV3r37HH377aefHgLhIWPCqBEjYa840y3M cICcXc2aN2fdrlql6jPPzMUwjPi0MokkeAIgs6Smrle3Hm8SdPLokchr6759e1u0bFGrVm2+ JmEQfG4w+ERcseLF//WvO3E+vziQNN8G1JVkDbyCL7zwYrt27bnRIdpwV5hoRvmypcsEGyZX Ne+WA64tcrtJk6Zt2rR9Ye3zd999N+Al2z1HWeUqVYYNG+7K0aPHcJPobeTIUXXq1DVgcBl4 EYiZkLrChx+iQrnyQQ8MH+tRl85denTvsWPH6zzgnpcj0Ug4SPRPUXRrDhjhFJ4XkitSHUMs YmYPiYQ3G+pMJD0DAwG7hK98DOXKlnFt8utHmaPO89lzNuNhKlnDYrmBlE/xDpUvWxbFYwzw rkKFCtG7+HaLFi4Mc8hxDOj477vvHj92HLAvyCVvFXyTNZs/2n6Ok7pr5058g8CNWKhK5SpL Fi/hXwawhF8BziBDZKpdumQpkQKECc4CRgzvAh8t1R9S1icHF6xww/r1YankJuKnKl2ylFCA RMh07tTZ7dQ/AVXhsufyMmYAK5UPeL2xE5TzyBEjXFizeg1eNU5zmaQrV66M1qGN9UnMQoE8 PWhw6VIljYTHMkhX4+Gdc2DwHGikK6aSahrcxIVgJc57XoPx+Dz4ADe84YSYrE3AAIQYn57L 9cbDKdxB4plEVjds0PD5taejoghtqVy6du2q/arnVsLKOjBmrsjZs2afW2s9T9L8cDfL2YyH Vp59NgPn4cVDPwyPBSBHMEhHvbp16J8L5y/o1qWLkyWLF/NVPAHUv8zNI0cMf/Pgm+XLlFa9 AJoR40lSBPW7bNmzUBra8+pOmzKldq0oHK5i+fJJqAuEIfRJ7ty5582dC5gClmkSixQqTGpF AMW4aoIIicGDBgYEI7h9iPSJfcCRrLMdhbDhLyaCpkyZ0qFdO7gtTAuo7VeLBeCVWz/84EO2 jlKhLVq0MGStxYEtmjXXpnKFiuDaoGc4n8pK3YwYYOWqgOR6bfv2jh07YoaNGzcEMKSFwNLj oG+fvqCVXNjQBWRUtapVwFwAXPwEMSOeIEgt0ljaX0tA4EN/HYen8DW4+PbvP2AAAGh0yxAa 4om6dumapFT7cHPORT5dzmY82wxbi0TDGdCvX8h4CQMFMIUa1r30EjgFxsMMJYsVI5QwHigW /iRVYD6gojAevnLV9OnTevXoQRSgS19VCALdYE4gScqWKqWyl5PPrXgOdtGODriJXgrKGKCP gPwEkRgCE8qiiCKHPj0kpHZu0gT8MuCeMwwzjjEerVI8IY6dNjWKbNq2bWvZMmVF2UgyLawB OLNK5UrSh23dtk3RH1wEo+zXls1bIHxISLAsWiGciicNMwAUTrp6HMe2ZDHmez2hGo2hUSPA SAc0zxnTpoO/gNFE4M+KFa0drVtGz2t9oW068AjgY8IvILaC7HKSug5ikkx1OLCQlS9bThAQ /Tlgr23zwMqTh71I6vwQX56DGc+6Kw4I2M/mR6wXzSpCSxYtKmyMQkX+UNIYJKOok3btAK+e zJ9fcQ9qJ+Ai/oTWlTzTV0GiwJODBw/Ony+/JNBUTUod0rH8Q3VCZgLv2klWqlDRBgnErHSp UsTUww/lxqgLFiwsXqz42jVr8z2RBy4Z9kpyS4AskmrihImdOnTUj3BvgwkEjSswqruDO9tb zpg+TdkgLI3oGWkMHnga4llsgQgAjya2TVwfM73dncD5WKlr4MFJb2OzaxXWoDxQIHR/NS5S uPBo4Q6t2xCSJCSkuPNw4bZ/IP+lSpSkb7OFkI1AniJ94dGo3/aQ1atWE0aQdBVYK5C+kZtq wFGg6nHjxi1cYCzP2OtaDlh9NbMdtYKYeboAqGp84SXyY3xImS8HM17AFqlZ1a9fX2YMUdi+ KpwgqjJKanDq1Lxn5gpPhVoUFcZ2ggPZJ2logkRffPFFOx+bHNs8+5nVq1d16NCBGAQRtPvC J6QKsbNl88u6xRiWfVYNbZCySBlCxoZQYBty7NWrN7aBzHQM2ElRpPFKaiAsdeXKVZhEEKBq dcEHsHvXbtB7Ymfzps1GawtHAut8/vwFbdu2U3VMG/BuDYgOGE7PhVvkcdEJeKf+RXB7cBuz lSufAxPt06c3QRfkUtAAlyxaRFZ369ZVnmmTYz2KvJHHjsFG4gpD0obMpwaDU5PYrP8Vylc0 5kmTJodOEmZLpfloqnfvxmYqNwgFZGSKZmzYcA6MYJ59dslS97XrE5KX2s+HlHEu9rFyMOMl pJboP6mQwiABsvwUnjb5KRycFQOZ5WTYRGX/pE5flkQSoXEqyDO6XYqPQ6g7AcKtl9ptAhk9 Y/DvkMbi9NPFZBB4JvsgA7onOZ/l0UClGVTDr+dgmHMgRWP80BkOj3DmYmnzQ319zma8nPtq zLtNXefOnXfv2nlmIsH3+5nYReWcjtj2PME37/cAP5z3SzPeB/Zes8irD2QciWs+QtsdT8uo 9+8lpBnv/Zvr9J3SM5DMQJrx0sSQnoEPYAbSjPcBTHr6lukZSDNemgbSM/ABzECa8T6ASU/f Mj0DacZL00B6Bj6AGUgz3gcw6elbpmcgzXhpGkjPwAcwA2nG+wAmPX3L9AykGS9NA+kZ+ABm IM14H8Ckp2+ZnoEczHhxmscMMH5I7hhCb97rS4WZDLMQgIuOU+H277W3828f7hINOyOO4fSl IVDg3J8kniCjcQhNCBkv40+YkPiJMrJZJ8EZyU9JCEVSFDI1ju7MsImMyQkhF8ktUoeadBs1 eIfohIxHzoyWOOszhnGeT3xD8qbC857njL3b1L4fv+doxjsugaRMOwoehPcktDQqzfMeP+Lo JIOQux9QWIidIL04LewJGUfE1L1T6EBCxO/xbqebG3AIKfQ3yTLkZyvHoWgw70hGgR/kL1Ip QfomyQX90YnAQtmZMugvypwbLUzCC50PS5IDl8R3PPHWkWjqhCbs2bM7JErcs3uvZ08YSdj7 jtdff3Xbq8IRpb2QXdRESQkTzU9mHIObRj9l1pR3awUbBPueIywoZHPzV4LAqBTz2RbKI6rP HDoUErqde3rdyPOLAIwm8JwgbzdSP1C5lQt+X5f2whzMeN6KkiCFCxcpX768mjvmRSEuQdln ov5Px6Elj5p6gAIkhhg3Zkwo6dy8aZP1L70Ueli6eHHd2nVioZqZqTqOxQ5SMdBxdJz5axLz FjFPyoqeiKZIIsWfRFxYo5VFkU9JHGo476/g1Hx58qKSs5Kdk35Sk0z6oxrVqklmMWTw4Pnz 5rujNCoSioWrYu49JEGLHBOK9QiWlQRNLgwJHUJ2DPHjhQsXln9T7LmvIoNKlyotq8XmzS+H B1RJS+2X2nXqlChRQj4YZ6Q2Gz92rIygoorDg8ho5hYh2UT4KLckv2DqY2al1xMnhSM3adRY foCe3Xsk61d007ipg0mTJgmxdZyljkKsz2Smr86czEOHolJ7wurDTSPxHmVJy3jvyd39pNRu wwb1w7u7tFx0Ab3lbMYLOeeIK7m3vH605aVaBRFEyE0kdlu0NbKTalptGhOuio3zcS7naJmX EkKWPqm+oguPH1ezTra8kKlOqhW14MK6G9ggfFSl079mqhxbm8PqLhDbT/v37Uu4S/0gvzqJ evQfsu6RTqFlLO2itV8AePWqVTrG6YZcK/+SxJsPP/RQKKyV5Y0GaabmkdQS+MqodCv1g1QU 0YAXLmwYF5TMYOAZM2vXrOUWEq5MnKh82Fi50qSZqVi+whtv7JR/dvLEqFyZgXhezC+4XslI SdNCD+5ltP6akwH9+jspnp1AM11uahyRgD1yBMWHUuYmXz9SV+jBGwlBydnVPyeV1FMQk9Q1 53oIExjl84z0jKiQ4N69+6gbo0eNxn6+xm9nj+eVsjp5F5HUlUj32DGZF4sWLqTCkZ/27tsb K9sIIJreAwf2hzGEN67iZ4P69dKMdwHLxBmXmE35C6QeMbOWZNXhlFaUXESevFo1a6urLNeY 1H0Ki1etVk3qFOWOK1WsJNlJqxYtJUeRztkbVU1WZjuqZs8ePWlRsnFpQ0qowuU91aldS+eq z+lNTgdZfVSQrFatuvSYbVq1/sMf/oA4QqJOmQUlcZHQWvE3SVz69elrRVfRynIg54ocKtu3 vybZniRIJJWsE15/RGsxN0pRERjPZ9SIEf379lXQTycJC4WfgiClK6q8l5o8V5EwCSw0UNFS TdbQ2EdmJDUDpSSUr0VWmKaNm4Q8ufILyq0iA0WD+g0krUDrMlyE0sqknPRHFqkgE5yRu1Yi I6wlHYb0FmHOlYyVRUJ9eckpLAFS11A0ypevgLFNmhTD7qgs4e7dewIDJ0MKfbq7BIcmPzCh rKS4i1yVf0lqDPM5YcLEAf0HFCxYUBHZpc8+a3klq/M8kWf9upeGPP10hQoVpcawQjVp3ERi JSl0S5coIfWTZlKqCuo/8tYRiVUVnY5qa0s3HKeiqVSpcolixcx/SO59scR30dfnbIknKdgT jz/x5JNPNmsSZbZq07pNvz59LN5UUDm/VCr2RjGVcseoTQlLqY1e3rzl3rvvlgTJu5w+daqc JbNnziI6MJu/UdHWoUPkyUOyVE2aiaRjRJAstxUrlKdrPVXgSbLIvkKbGtVrWEddSNkjHCSH xhV66N2zR8F8+W0nsJZ8gZhZs2NH30aO8rXIfSLlHiZKDANy+6mwafwouE6t2mR1tSqVSYNA H74qE42BQ+72TZs216xZK17Io0IRDtq1aZsnTx6FKQsWKFi/Xn2XHIlqJ0RqcMkSJf/fb35D vURrmPmlFyMt2pDGjBqFQ3AsQmzbuo1nlKEoqJdlS5ci2SI+jzvv2qWzTDAOqH/9+kVZKnCm CntPFsj/zNw5tpSFCz2Fc0yC/bAMn1RN+UtlH5UwSh7BaJwnT3quSZMmWhnDE/krd8uTBQvK oSYHXKsWzTdt3HDHP26nvCycPx/34u2e3bpT/vv37xfeoIQuMhpa7yxnJtYyKjna448+Kukb SViiaFF7UfMvMWmp4sXVpldfVvFtSdaktLHLxefyXHl98jgaUprxLmrdiFZf5Ua7dpN6VeYv mpIcRCqJSuq65eXNqEeWS6RJF6JxeT1jxoxWAN3uR6lXKopMW7Z2gwYOkM6ImiR7LD3KCrp5 40aqqWoMC+fPsxVR1TH3Q7mbNm1WuFAhRRLpdWQdBpOtCK0bg0xbJFggTYmrH3n4YTk7EZbz XraRyDOp6KQslI8+/EjtWrXUHmgoU1hmfRUXSs2E2hy0bdO2atVqhC1VU1KjIB+sDldccYWF IFAMc0iF8hVcHudgjxp0aNe+b99+iHhklIEvSr9ZrVpV2fgIfyPctHGT7KOSiNKyQs5pOyvF n4MUOnb8mOxpshjGtZ2lEjtcoVyUri/6Lb5X9WpVg248beq0wYOj1NG1atRcv36DdKO7d+4k ssuWKW3XJ0116HDNmjVkjgMZqCRfDCc9nUfo27t3xM+ZezNZp3DF5s2baMKG59WYW3J42dJn B/bvp8w19Vj604h1T5zUZt2LL9FuHnzgAVkGZVKTetAW14pmybPHw3gjRgwnAx+4PxfhLJep h2VzkiLR17pxweeN6zeEEtNpxrtYxkNDiMacyq4Z8md6YWafUkfJrFq5UmQ76drVrlob/IAC vKeqFSsxYsppOX7cWGqkjF00N/obxtOPVJxv7NxZQzmO+fMaNWgwYfw4RPnmm4cOxkVV9UO9 JLJY0uSx9tW2SlXUtavXlCxRwg4K71GfnJcXjG4TLrH8Y0V0tmr1qsM0uSgzV/RJrClKk2um 7rG0fOq8/uWWW9wl2HAYFSWcJaAsGWHfZdl+Ji46Gz6SF6JCB1jOoqNz+iHpLb2f3KHO+5XU tdAQtr7Wr1sXe4RryZMK5ctZODz+sbeP4l5LQxBKfu3bu0+oEe9DZ+vff4CDMqVKrd+wgagk 1mybCRP6BR4IzVavWa0EswNSS20TBzpT+hxTydUZKdjRJ8PIVKZUaZk5ZWcsX6YsPqGTV65Y ycj79O5F37ZQhpkk8IcNifIUW0qsj8yqllEagc3qgf0HPG+ZUiWlVLXAUV9NjvRNqtWSvQS4 bYOnsxOJ52dZtGlPG1cuiu3ihVPuV6nUbc/oHl6YysNegL2HN03BkHOWQvj4Y4/LZCklprIK FmbWDUqLNyd565hRo627pCWZwDxDqWNIWPfii6+/sZNiJnlk3dq1WR3Z+qKq3IMGIg70pLFc sfrPlzcvC2SDevWdl41PyXXcpZ/evXrTyuyC6I0SUBIINDELBIlE3EkFL5Ulug6Gh4gxZsyU 4jJhJAdVK1UKxqFEPjiOWsfqn61agXz5KYoeH/V36tB+aqzU0cQ8e9KPgsaFnnrKgIsULqLW NLovUbwEg1CdWrVw7zNz5lIWlExo37YtUrRm2Z3KqDtz5ozQA6lu6iQvpKiTyXaMZL6Huutf /6Lu1qheTRZ3/dDeLXOutQzhwCWLF4WEtj169AwSL8seD08/v/Z59lL8Zj3yq+LYD+TKRQex ajxZoGB0bfcexKORFC9aTIp+Sqkq87LQSwFM0bXBk5rNg5PVrFk8D9RL2RatHfJk57rv/pjx mq5eufLAwQMVypbDqHazkhRbGW1D9J+WeBfJeiet0CNGjLQuBlMEFUj9ILttTIi1qKCUfsV3 hg8fMXnylI0bqX6bvWDrPdcTQqRKIeVZs2exgqgr8NZbR5Xz3r9/H3cg4tCnv7qVqdZ+Q4ER Ak25Dx2+eehNQ6d5yodp48SAqdkLz6+VSRZXUJ+wmeyuVFbjkQyXuT961LhKOCmEaJJ3H+wl EmwmcxHl+Vy1yvbpbPQRmf/ci3mDP0AaX5TnqVhuULAkogaT9KMZ48eQIUNtdwMvrVmzdsTI kbt2RuXEJH72UDNnzjIhhBLzCTvTM1G6segT7fcOHpRp0/RqRvvVP51NNls7KJZh02WG5cx+ bsUK+gLiHjt2rLoRJs2qpzG3xGvbtgX5lvrx1XThEzMZKxEnvaOQXt4uMVS091pf3vwyFXfi xEkyoCqDYdiS1StJz/eowAMlxcbPezRLVlJjsAQsW7bMhFhq2V3pI5HJ9OhR6wV92DFXkzdI nblYmrtE1+dg40qqNMiyssZrWkoKyxRpEq5Krj2zslesAmUa9MJFqQt2SjcZtofkzFnzYZ7R PsW5Fw0ghR5Dsyxn3tHwdmbyzOT9JeNMJYxkAIHtU0abJQ3m6WycyeVZKIOim/I4mbXHYqUx Ow0lg8nuToi4OqWj1JZZJjx7t6nzmepeP+sYkrechU4uEeNcbDc5m/Eu9unT16dn4AOagRzM eBbLZPRBOwoC6lLOZOYtguk/rLJZbhCt2SnFYrNInowLM4Esrk0VO6niNFEss8jYLG0iQGnS W1yJ/Ayxlu3howk5w5OWkez9vc5SIo6S580+1Umb0HmQOUGSx6PIQKWeqUecgYzNuCS+PExd xtPFVplU8Z78FCpsJhpH7IS/pDTwXmfq/NrnZMY7fpxxcssWxRG2ej0HDhxUEOHSTrqXGpAT sQUyep1gK1lqptIJbTDsKjOoTZVwu59Dh8LXBJpoJ7bjte0xnOKg3SZkhjH7avuhyMGGjRtY U5JLbOE2bNjI4geWoQ3XCD+4j32XF+Z2Nqs2OTjQ3mzbtlc3bFivOOtZnz1GyBzne1SyyxgS pMj5kUdGK0NVOMVGLjx7BAw6cCAq457Sizb2xgyOYRjhjRheJuNFLGQ36CnswWxVudftM5l4 wzzYHJoFM2OEoddQKzce+UZmEvMMPrpp8+bDbx6KqDae54ALDcgyW2VTcekX3/c0U+fdOAcz nilmqCxQoACsCazjunUvhepwyaoZjkmEQAepP6WKytS5ymJrdgksCNe58wiCAZBlLwJ2pIC5 tOGLZ0EN/b999K08jz/OPZg5jKikEeM7uytfBXplZgRe4dTmxEdMjgEs9PB8XGndYI6+fZQR r06dOmXKlKlapTLjQblyZSFu6tevhzIxKkc8MynPHuMNFEjevHlq166lxhBTx1nsMXFNJYUs QXaAeEKxsWha4k+4Y/T3zD1laj/hF2WG2HK13LtnjzEbQ2ob/WGApwoW7NGtW+jfje6+8061 BMMtNN7+2nYGZC+rR7fuVpAWzZt5BP4DDIMhlWoyh0yj/EChZxeqjlKkUCHNmG2xPb8O2IqZ dIlnZyKGEIAo0nLRosWKGbHfqj2YEMB5c8EH0DBnM556yEyall44abYvrlXIzEgURNrYKedB +EFEYmo+xueDaKK3EpePVXkHXDPWTML6Gq+cQb+JpYSWjGBPFSjA4a6BGIg+vftwWwErhVcb tB1m6wL58sVglIhW+KYfffhhjuCEppVibtUy8inrMwYiRmOAseKWcEmtWrWA9AMnJO8/0C4X Ip+BS/Ati2tykjfZsRKtHhlqhA09/HRW8tEtaczUHiBabkO0sg1akAio0C3RQTQlAtOsRDOT oSJGz6gSYJ5HH2vXJipbCQ4CjRlVoowrwifzAOf5+COPdOvcOQyGizXXvfc+M3t2Mg9gesEd J5ri6FtH98NVxvg1dcswlRqd4cIgVONhHyxetCgfaXTy2DFOF04Lx1FVtvETeGUxeVRbs0oV r4mnbu2aNdtffY3v4aww1w+At855y5zNeKRHcKBXr16DLbtA/ny1atYCwmShZmeP5EyFCtxK bx48wDmrUhwX9sJ4DSYh8SpGpUEFig+KzYwZylYtdQbtOetaLxicivvBSbKOeAp8kvAqMATg RQSJOHWKpZ6rmi+R6zkm8ij+BU1wJXNeE1YJbXFgQDBpYJ3u3r370qVLUjknNIM+4zcH91WC jz+NX85JhcSqVKqs8BjAGvs7lGapUqVZ+XftysB2ZhHvboHTVN4MHhdAFsLKs4tRgLHi4Nqz ew9NwTKUcL4DZQBVBQuPQEo3atBQnc0O7TOcjZwf0KfJUqGN9U5XADrd4yqZ3Bgtm7ckIWdn egWxfdmyZUBPpkyZZM6jQcbhHcFJyNOdN29eJQq5ExJG5QUh3HhKleNzkqfE2+TM4OLHaSbc JDhP4sGaQagErDaVRNG11Mm83FgujCeHM16PHqWjaoktOUxfevGFwk89ZTvUqWMnPiLeapAO OgxZBPFQIF9e72zunLla8sMiRE68ShUqzJsXvdRkpz5s+PA5szNAIZzOMGj2TlGlxZgqufgq la/A+5QQh57xGJcgwIqTsKMLFixQjxaAJuqWpH3r6EMPPIDhjYpqRMKAGloa/nXHHevXrder oIGBAweWKF4c80TdZm6QOAA5fMkiG6rRI0ciUGUrLS7aAEz97re/LV+uLJFjm9S/Xz8162hx RERQIHm0Bw0cZCsVhwedNAlPPPYYqlUxE4DOP15paiGOov268OlBg1yVaoYB++IfD/w/bOgw /jF4zgQXpta5KuoJ42kD0wyGCnwXqk+bDY44LLFg3rzQCdfl7X//O7CBn1q2bOV2XkeRIoWB 4/bt248DKedQRDz+bhQumTFt2q233NKlSxfaKfyDMwKXbv7tb82VZRFWRl1eJ7naoXA9CICO Pv9w880BqHR58lsyqhzPeDVr1qRu2QhZv4MONnTokJHDh9uPzZsblapE0JDQ9WrXpmpGK3GL FlMnTwKVUBQOzYnKCeQO0QurlS9/vmLFiou7EdngQBktQBNUy6VrpiLGq1AhqJq+gkrnzZMX TkW19IIFCgBM5H7oIVqQJRk+m/pkli3DDz34IIe4S4gaVIWRoF4QKPBkYm/k66cyhSUgiCxA DRU2HSQxaQplUi89jnEK/rXkI7hAo6HzZXE5eB+AG9hIkPxAf0ailDRmo2F6EIoiafn4o4/x Pnv8m37xC0IvuvXxEyJqBw8aDORx/3331YCfbtvWQz2cOzcfOgBa8WLFAn4a4yUSz1chObly 5YJxIzltPufMmQPdakkqWqQIHGmIh8J4ue6/H07aMfgIaCUtkWlEYGGIRQwf8U1hJxkdT5qM Dx2wCVFeQGHtUe0dDI+4BoUNwDfAIC1FMFN26tdvkDfPE8xI4cEv50/OZjwY6UBePiB5ETWw uAwcOGrkCLssaAdfMQ8oE5Cetw5WInATjIvwQRDEEUNZWOnhLQirunXrQUELlmFJGzNmTFQV uUGDu+++O6hA9CUlvyPTYhy1ybo4bNhwberUqY2qFi9eMnDAwN59ehcrVgzFJOEFkPIQzy5n PEiWc2AL28UQFuRDAQY7jqg/7KxOnoRTiwo4xyFnoQ2lC/W3Ugx5bCQbx40dg3UTksXqNjm+ Ghi8OAlJ4kER6M0eD60LHfAroCblmTRjtCDxdFi0cJFhQ6OtVwhTMkVMGsWLl6BtstzQZgd4 qN69WTUee/QxS4aW1i97vNB5vB7tJ6ysbqVKlbIAqWXta+/evXLnzq2ZWdKG/blkyZK0DA9I /qsNGEYOj0JHTZ5C1I99e/hqd0fERQcvvqASPXEdxjl92nT6vP02DdPX2lHQUwb0lApqHtwr dcN8ebJfzma8Xj17jB0zOrwnaK9Qu9yajbZodHQzWigwJ+t8zWrVAb5QFZ3Ei8EDUIt4EjmG lxQ6oaAmqmY4s3XrKxbXcEwpgg+0ZcowK2T60yiNtosJ9YDVU958Dd2CUJIVjRo2omjZaFnR O3ToWKhQIbApVGi9V9O4VKmS6DW6JCreesomqljRIqxEemCTJFHhpMlnazwiwyp0SyBJ+z2B diSAzuG5Q4qHLHu8iPH2G3aFsMezKgm9o28XyC+uZy5IKv4sVbIUiZF6LVmHSZInip9iUbfO 0f7NBzbVGpekWkiaUfYE4yRfgSotYck8AH2VK1OO7AJ8hSZjLnYX4ExbNc8IrWpmPKOY+qAw W3GaNW4irI51F9SOUs1oqWB14UKFCepXX32VZdhCCZ7qwWkxwLelS5acMSPCml6ezJY6qhzM eKj21ddeQ0+BYmDWoxQpJ07s2LH9jTeiRADIl34Cx4iWvTZaH20zorC4CPjkKVMIIpEjYTqC LXPH9h0Qj8G6Gc6Tb9Sz8NUL1qe/Wd6rbqNbZ35sooiUMKqQQGn16jWsKThWz4gG2jNE6MQS ZpWvhpdCLicobzwHBuVyEQDMKoLiUGSgaY3Jeaq1Y3XJp02bTrsL9snsBBebUt8Kj+9XEl4k m8gJC5PIJmZAV3GgGXMiJTws76idYWJn9ZMbKc4e1gVTDU1JPmahJLalCP4afzSz3oVY2PAh vYULG6ox0DPtt6M68ps3G4ApJV1BQ4NETXowBpZbQXfhwe0bx0+YCIubOQ+bpk6dRp671/r1 68yJZchPOcF/npONKymJseL3Gn+SXVMqeDL8mqwxWX5KKCMxsaTSUyoqJfSTnbhDgo/TFBZG kvIJYwsnU4+zf40vyoBrZHo6znVJ0ttZB5Y6pAyBlg3BmsxYlgFn0daS6T091TGiIPtjvtM8 pK7xqccZbJn5JKlskzxdWALOMXWnW0bzl0auZCfS9Jn0DKRnIEe7E876+s4qtc4io86mkATn +RkyJEYYhjOpP1EUQuN3IqHkkosZZJo+P8QzkIP3eGd9K1QSWxf/zmHXOvrWW7bmGcn54n18 0FEDa7HCrX3+ed5bEKegv9m6MKPbAs6YPoPrwh4yoBbfifF0yJDDCmLbmJofNhmwQdrC2WVd /sa3DzHpf7CPlrMZL2Xbdhqn//TTTwe7c8xOpzcGSWOmF5462MuQC1Azlr3Qnj2aoa9xo4YM bsAuTI6YBO6EV4oFnJlUtGW3rl1eBLOMWSqDac/cQ+pHFgYG1WRfl+w6kjFI4yPj0OkGHywV pO/+vs9ADma8iGdi0xk8brAQbHt1Gx/xsCFDnh78tLBxDm7cAZEo5Jm5TBuNiTt2wt17MN1e TgXJMzmvubm279jBssdCPf+ZeTiNKRwaA8SRI5v7wWfylKmSJsGOuTDOWxzJPKZCljfH7nLo 8GEeYSbQ3Xt261b2LrbNKINDDBzzZsNcGwOMr6RMI4YNjwXv0Q8+19z7TnbpG+ZgxkOv0FLl ypWHHfEiBw4YwIErzaOTeZ/IU7VqFeikyBfUrBlJVbx4cRlQgI/gvzZu2sixK5vlX2+9Fe+1 bNni9zf/XoIGPi7/eCCkypk4YeL9997L7ydjUpfOnSQO4Em//fbbpUtp2iTKJxkJq1P/ASuT GdYRcJkERDxyNWrWBONgKBejoPOKFStyeERcFzOexpzCXTp37t2zl5Qt0Plc2AaZ1jk/aqyY UxnPuNHrUwUKBlAIoAmpFXLxQ7s3b9rMDqxSpUpbt2yRlgfWkRe7dKmSXNIA7zKIyP8FMMX3 ChIpb7E2OpHoVnJleaxs88TCgXqSk9WqVMVpoDAEY+sYnl+2dGnJ0oOWSAWV/8cBNNOi2Fk8 Y9p0OZdopFHeruPHuKrlUwqN9QBXEVUFOHUK0AMUAwBaqiwyMGwm05+PzgzkVMYLMoQjWDiJ FNHgVLBUgb4BxKLceBE8ql4E4GzcGD6LqQOhO1mhbNk5c2djHjpnzHivUB2rx4xH3EmJi9Pk gcM2sqqCwsAHSwoowSOAYuu4BwBrGXXCvcSqdI0DYVq3ar1s6VLgKeBdQa7u2L5dlBxaQthp U6P86j4ghe3btAnHVocA/JXzC8Y6zXgfHZYLT5qDGS+ghwkxsEOSqnSJkiG3PugwQL0DYGWM B7m7dPESMqpl8xYeWA5Glkk4SRfWrVP3tde22+5RQbUXgikAh2pKTI0fO44SmPeJJwCa2rRt K/BHviqRYJrhyZUrngvTh/F0G/FzhQoyTwtKCGhMEq91XIRAHjuBambZjhRqXjhpcN9rKSWZ A7E/bLBpxkszHvDTtddee8Wtt96KQMPyHD6X1T7EYEDpJaWVLBkKmdTq2LEjbbN71279+/WX MNOAYflBpaLkykuXCleV6hz1V6lUUeQBqcX0Iic09K3AH8hJqGKX4C6cIMEjeKRiA5C44FGY Z+zo0WvWrpXpmX1EgmqAr9mz59jgMZPA4LvR3XfdBbIklTpjZteu3aZOnRKCaOSulKFdRoOn nx7CCkqiijETmtCrZ69JEybojVjmV0gzXprxcgbjeU+AjIIjxYABXkbrwslTjPhEDd8A6HME vNyxg1gTSCLOUkESRkvbQtZOqHzmRJdjV1vEkLpD5E6IA1Aoz0n7QDGjYbkRJKql9ObYLAKI viqkJToOFWrs0BYtWoh7FZojHl24YOFCv8aZRU6wrEBy+mzdGoEYiTtgaE5C5wUZgTtu377D lvKjRnbp583BqqaXl0jj+PgMGGL4NXm8VIdbuCq5PGkTqCGLkE8AK2d12WVpn3ptfIvTSbJS 73jmsC8vVSLNEu/PDORsxnt/5ih9l/QMXPIZyMGMd56wzOxTFm9YMyK7L4eNaxCA7wRAy/KY voZ3ltRDPjtNnAk6Df0HFeCsKNN33WSee5CXnC4/9B3mYMbzbpYtWy6vUcI8iQUoOcj+/jQW GGoPFkfuvR6Fk3+gL9l4hNvZN77TKGBKhYTbpkaPGYO2wWVgYqK0lpkg7ezP66HUalQ55OWX N6uywJcYb1Zfj/JhZkOZAuLYKvOvvNMy5LxtsL1uFi39A525nH3zHMx4iKBZ0yZRfoTMj/JU IcW/g7h2+elPwJSFp4XknD51GmMMt4GkfdH5zEC7ZDoyY/ZOB3R7zxmiJlPmRMaSk6nZrDM2 mUnLhEwDh5y5zTu9I+W3UEU5yOHTci8TZcrkw7UYJeTL3JfCo6m5lfp0MppED5gZER9+4tnv 3r0HV6dEZkp/GKp8M+r1hV8Dj4Vj7scK5cpivDNHmHoHNdNHuC87kDXLD2pNhoLVOZv8P7jR 52zGU3VNcishycePvQ2DIv+U5Hxy4xQvXkzCPLZEpsXVa9ZESTgkxoyqdUcVt9XiYsEXcCAB GQKKQJfHjqmJB4epJDrz4yG5igUl7NoVYTJPnFAfWGQ6OSFHy062yrhouISqfnIlAlabJi5D o0TOZoPRj58UFla7izMd54SMmu7omKFVOjC5H6XE4pZg3pT1QGIyFxJlADeJjUeGwlWrVovp VoKPTz+OSY9YRfrAkOCAT9+v7iKdCd8GDKrjUAuJKVU6CZnzpE6RlcSA9+7Z7Xk5UdTc4TUJ 1SfNlXEaAyeK3oTnO3mQBfiNndJym65169dp76TBw52q1KM3hm+w1aefHhzVOr8Myhp/cOxz 4XfO2YwHrSIBifLWXTt3ARC55Za/cLUpaHjLLbeEBGFAm9Wj/MT1uRMgUVCpnLZ8dzhBklaV 2WSMlRcE/cFh+lUmr/vuuUeZO7Qr8xxwCWkg52yUDnDrVkWbpd9CjqNHjxoSZ/gy8T169ChX tpwkKMDZfHTWAv4JiLCyZctyl1euVNG9otSA+/Yjbn6IRQsXkFdr1z7fpGkT2VflIDEGGACZ nsmoqHH8oXzCl0n1JSFn+bJlIcsgUSdMGO8nydQsHIBplStXIb2hdv7yl7/ECQ5fhBZQh10e Md6RO+64Q+Yy2ZnuvfdeTPXs0iUywEoPY7TyC4HLSFgGOOrCjRvWgwpUr1ZdAb1Vq1YpQKmu rdybUVKTOnXAXC09JnbihPGm4p577sH55kHVctrs5bBJvnDy/+CufEfGy58/P8JN1TYutyk2 NimGZJImpmhTXG1y/vB3m0y5vgkjnAZvqZmVfuHCRSFXCroPBcf9BNglozMyIhlyP/jgnNmz nh48qG3r1nLOyeEhPzSwGFHTplWrXj16Eq0YMs9jjxFTZGZAqBBxvPa41LF0Q/37RlXCBeMp m4r96GalS5biMDR1SjHjH7FIdlM6DBMLU0ogG4l8hFguPEX4SUag4XFwEymsN6kyn3/hBWxg n+avx1RqPGR0pWRKOEsiEbkyqamjkC9PHntXEDlZUlaufE6dR8147WU3mjZlqjLikXq5b7+R h6TLBw7sl2aTDJ8xY6YM0PJhmgQ7OreQH0ViMnVhZROcOWM6AFDPnlFv1jWLVFrVvGDOzc54 NKCbbrrpiqpVqwL+XuaMR7ysWPEcCIsCvDRJ9U0RLoUQWIwWJKnrvLlzPYJ4BVlxwrMIsSPi qIING9SXT5LWhIvgXYQSYUiJruCtmzRuBEs5eOBAVYXJrihT6vLl7dq0AcvEWoIhZJgO2fIk DnJ56Pm1ba/Cdnbu2Im0UcnZmTgZbv0AZONFV80U89t0yfnpDFEmJ6SD9u3bcf1TFKFqMG3o DbmHxKwYT0QFvVcaNfEWBq9SsfNMMmQUw4m9Wf26Uf4yCq+MmrVq1yarqakGuWH9Biq3NOna k2x8/ThfAV05wmTgVrs43ItOThrj/HnPPEMaW18sBDLf1qsjT/spD+i83mbNmCFTU7euUW8k /JLFZ2S/vmAS/GhemJ3xFLumpFwhg2/RokUvc8aT2hUpSAlesVx52zDYMcv2kbeOUNuwnxgc ATgegUBApgwDTtLTGFRgo6mp2M+mS+o7mqS48pLFi8u3aeNmyS+YL7/U1IhVSnBKJjYr/ORT UgOKbn/iscfJKM1syeS9kkIzlCUI9nr64fBhQ/2VcJrEK1tabfG3jTBUAnCJVJz6sUwApilR 4BKiiXFFmrAKRNCu3YapK3FG3bp09atr6caGR+IRxX169ZZkNrw2m668efJs2fKyXK6ygHk0 WDn1ekg8GjV0uASb4pjIbUH0+EfPAZ0zsP8AS0OZ0qVkE/NVOQcrl9mZPWumNcjKMmTQYJEZ AjU8ZqMG9a1fJJ7UzoI8BF65pEXLlhL+Ofhoss3FP3V2xgscd0VAjl3mjCcv+nPLlrEcEHFY TpSd1OLibiz79jlq7lj7baLwGIrv1bM3/VBouaXdvmh4DKSOFu+2bUNx+qqVq7ZqFSGbyTGp pnUrSK9gwYKRyDp1Cn+iYDOO1iWTtSHs3iNKV96vbx85p7Foz+7dataoKREtD4fErOqJlyhW nJa4bes2iE28JOxdks98efJaDkaNGvXE4483btzIMCSEJPEwHouFyKahQ4fRgXfu3GV7ZgXB xpLwYlTWlyaNGotdAlUjOYkgkRlgop6XJJRJmtosV6xtWMECBUl+T6rAyNKlz9oysP2SY0aL c+gyZUqXkb1X2maZKsUZCi+kJ9u7UoNpBzQFYVDuiJNZj9q0aknM6g3oVLSUxzd7xi+TvI3i 5bYBuXiWeH96yM54xB2hd4WXdPPNN1svE9673KYYKdOR6E5WcTF1NnUkwPoNG3x1nkyzq0G1 dkchpSSDJFMe6cQJwOgXWeTi2CI2TFXv4t4OImL9RKa/3XvYF0kbPUdugxMnXCjVioOouDYi PfLWGzsjNKb5YZthtECpLIohyTnepvup0SF1vN5wkZa4RVJkmzSWHssERlq1ehWZaTCYnPSL IKbHjslFaYemE4MJedfd2rVUSrfWf1zL6Di9kYWGePdePDg902aS0SXq8ODBuKzfgWich9/y q0+cJ+aE/wkLJMPDa2Ud4WkwFXL1unVczTxqSWzqwSDdSD+GZ0rDjLH6CunwK65Oavq9P8T6 YbpLFsbzpq666ip/I8aTzJxp7rJlvGBbT/xRiVcqOWC0nD49Y2uXnAzaUXioxHCf5WSYlHM3 S9pkX7pwvs1bq1atK1aoGDaZqb2lKhFZ5jal2RkJocP55Eapw07tOXUkyeSkOvdSM9CkdpLl eVMHnDEJmR7CZE6yDObDxBLvz7NkIZuE1yLGw3+0TRj/8CYuN4l37gkK/rdIvr2/nyj38/Hj FHVxQ2SCeSNC3wXe9f6OMH23y2EGUhkvldEixvMRrHnfffflUMYLw34nDOR/a/ZjKGQiyoKa +n6P4b/1bOl+L9kMpDJeqmqZwXgIiKWFvSXHSbxLNkPpjtIz8F+YgYTxmFEEnYeqmj6nGc8p 9pYs0ehn3aikT6ZnID0D72kGbEmYMJPd3BmM5wvrlp8lin1PnaYbp2cgPQPnmAGyDlvhvdQ2 pyVeOEvuPfLII1xAmDA9m+kZSM/AxcwAbrKvo2GmyrqsqmbqDYDI2Dldk2a/i5n39LUf5RmA Z7jxxhs56pJ93bkkXvIblnMNZx9rJ6OLvR8P7Ed5HtPPnp6Bc89A7FuabadGZ7zyyiuFH2RR L8+L8ZJGPA0MnsQl9lXqPv1Jz0B6Bs46A5REbILr8N5ZpVwq4/1/9BckHFTJneYAAAAASUVO RK5CYII= --------------000402080209010607090000-- --------------040007080401010104000601-- From nobody Mon Jun 23 13:06:09 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C12001B2C4B; Mon, 23 Jun 2014 13:06:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_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 tdq1svAAAL54; Mon, 23 Jun 2014 13:06:03 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C6881B2C33; Mon, 23 Jun 2014 13:06:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s5NK5u5m007257; Mon, 23 Jun 2014 22:05:56 +0200 (CEST) Received: from [192.168.217.145] (p54891060.dip0.t-ipconnect.de [84.137.16.96]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 60EAA159B; Mon, 23 Jun 2014 22:05:55 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 $1878.2$) From: Carsten Bormann In-Reply-To: Date: Mon, 23 Jun 2014 22:05:54 +0200 X-Mao-Original-Outgoing-Id: 425246754.149578-3944e772140e9cab6d30a3eada28576f Content-Transfer-Encoding: quoted-printable Message-Id: <63722FD9-BA11-48E6-951A-7A3823F5EFD5@tzi.org> References: To: dtls-iot@ietf.org, core , ace@ietf.org, "6lo@ietf.org WG" <6lo@ietf.org>, lwip@ietf.org X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/ace/gcrhWwcED-YxTCDK-ihn5lndVy4 Subject: [Ace] Constrained Node/Network Cluster @ IETF90, early draft version X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments $ace$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 20:06:05 -0000 A first draft version of the IETF90 agenda is out. ** THIS IS GOING TO CHANGE ** for conflict resolution, so please don't make travel arrangements based on it. Here is my usual eclectic condensed agenda built from that. =20 The Constrained Node/Network group meetings are nicely spread out over = the week. All times are EDT (UTC-0400) (use = https://datatracker.ietf.org/meeting/agenda-utc and press the button to = get your local time in case you want to listen in from remote). Gr=FC=DFe, Carsten MONDAY, July 21, 2014 0900-1130 Morning Session I Ontario APP appsawg Applications Area Working Group WG - = Combined with APPAREA Canadian OPS v6ops IPv6 Operations WG 1300-1500 Afternoon Session I Ontario APP httpbis Hypertext Transfer Protocol WG Ballroom INT intarea Internet Area Working Group WG Salon A SEC jose Javascript Object Signing and Encryption = WG 1520-1650 Afternoon Session II Territories INT *** 6tisch IPv6 over the TSCH mode of IEEE = 802.15.4e WG Ontario SEC tls Transport Layer Security WG Ballroom TSV taps Transport Services WG TUESDAY, July 22, 2014 0900-1130 Morning Session I Ontario APP uta Using TLS in Applications WG Territories TSV tsvwg Transport Area Working Group WG 1300-1400 Afternoon Session I Ontario INT *** lwig Light-Weight Implementation Guidance WG Canadian TSV tsvwg Transport Area Working Group WG 1420-1620 Afternoon Session II Territories APP httpbis Hypertext Transfer Protocol WG Ontario OPS v6ops IPv6 Operations WG 1640-1840 Afternoon Session III Tudor 7/8 RTG *** roll Routing Over Low power and Lossy = networks WG WEDNESDAY, July 23, 2014 0900-1130 Morning Session I Tudor 7/8 SEC *** ace Authentication and Authorization for = Constrained Environments WG 1300-1500 Afternoon Session I Ballroom OPS ucan Use Cases for Autonomic Networking BOF Tudor 7/8 TSV tcpinc TCP Increased Security WG 1520-1650 Afternoon Session II Territories APP *** core Constrained RESTful Environments WG THURSDAY, July 24, 2014 0900-1130 Morning Session I Tudor 7/8 INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG Salon B SEC httpauth Hypertext Transfer Protocol = Authentication WG - 1000-1130 1300-1500 Afternoon Session I Canadian SEC saag Security Area Open Meeting Ballroom TSV rmcat RTP Media Congestion Avoidance = Techniques WG 1520-1720 Afternoon Session II Canadian INT dnssd Extensions for Scalable DNS Service = Discovery WG Salon A OPS eman Energy Management WG Ontario RTG rtgarea Routing Area Open Meeting Manitoba SEC oauth Web Authorization Protocol WG 1730-1830 Afternoon Session III Salon B APP *** core Constrained RESTful Environments WG Ontario SEC tls Transport Layer Security WG Ballroom TSV rmcat RTP Media Congestion Avoidance = Techniques WG FRIDAY, July 25, 2014 0900-1130 Morning Session I Canadian INT homenet Home Networking WG 1150-1320 Afternoon Session I Salon B SEC *** dice DTLS In Constrained Environments WG From nobody Tue Jun 24 02:24:49 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B41921B28A6 for ; Tue, 24 Jun 2014 02:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 O8XMKecGZCye for ; Tue, 24 Jun 2014 02:24:46 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A48C1B289C for ; Tue, 24 Jun 2014 02:24:46 -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 BJE16102; Tue, 24 Jun 2014 09:24:44 +0000 (GMT) Received: from SZXEMA403-HUB.china.huawei.com (10.82.72.35) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 24 Jun 2014 10:24:37 +0100 Received: from SZXEMA501-MBS.china.huawei.com ([169.254.2.128]) by SZXEMA403-HUB.china.huawei.com ([10.82.72.35]) with mapi id 14.03.0158.001; Tue, 24 Jun 2014 17:24:33 +0800 From: Likepeng To: "ace@ietf.org" Thread-Topic: IETF 90 (Toronto) meeting plan Thread-Index: AQHPj44bYTrpTomJXkmxhvjAv1EAgA== Date: Tue, 24 Jun 2014 09:24:32 +0000 Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F2581703EA@SZXEMA501-MBS.china.huawei.com> References: <63722FD9-BA11-48E6-951A-7A3823F5EFD5@tzi.org> In-Reply-To: <63722FD9-BA11-48E6-951A-7A3823F5EFD5@tzi.org> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.167.122] 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/ace/fTyOYTwEDq2vtGESOjtZCay_R1Q Subject: [Ace] IETF 90 (Toronto) meeting plan X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments $ace$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 09:24:47 -0000 Hello all, For planning the IETF 90 (Toronto) F2F meeting, please tell the chairs if y= ou need a time slot at this meeting. The information we'd like to have (but anything preliminary already helps w= ith planning): -Objective, i.e. what do we want to achieve by using face-to-face time; -Discussion leader/presenter; -Approximate time needed in the meeting; -Internet-Draft (name/URI). Preference will be given to slot requests with Internet-Drafts and recent d= iscussion; but the detailed planning will happen later. Remind that the cut-off date for draft submission is 4th Jul, 2014.=20 If you have related draft but it is not shown on the working group webpage,= please change the document name with "ace", so the draft can be linked her= e: http://datatracker.ietf.org/wg/ace/ Thanks, Kind Regards Kepeng From nobody Fri Jun 27 02:29:32 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A07D1B2F48; Fri, 27 Jun 2014 02:29:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 AGRswDZ5Q82j; Fri, 27 Jun 2014 02:29: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 3B2BF1B2F37; Fri, 27 Jun 2014 02:29:25 -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 BJI13456; Fri, 27 Jun 2014 09:29:23 +0000 (GMT) Received: from SZXEMA409-HUB.china.huawei.com (10.82.72.41) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 27 Jun 2014 10:29:22 +0100 Received: from SZXEMA501-MBS.china.huawei.com ([169.254.2.128]) by SZXEMA409-HUB.china.huawei.com ([10.82.72.41]) with mapi id 14.03.0158.001; Fri, 27 Jun 2014 17:29:19 +0800 From: Likepeng To: Abhijan Bhattacharyya Thread-Topic: [core] Fw: New Version Notification for draft-li-core-coap-node-id-option-01.txt Thread-Index: AQHPkeUaGPqdR9HIPkGw1A+VKaXvTpuErCYQ Date: Fri, 27 Jun 2014 09:29:18 +0000 Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F258171A34@SZXEMA501-MBS.china.huawei.com> References: 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.167.122] Content-Type: multipart/alternative; boundary="_000_34966E97BE8AD64EAE9D3D6E4DEE36F258171A34SZXEMA501MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/ace/WzdH0r6WUFz2RsNhgv2rm2QIQNE Cc: "core@ietf.org" , "ace@ietf.org" Subject: Re: [Ace] [core] Fw: New Version Notification for draft-li-core-coap-node-id-option-01.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments $ace$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 09:29:30 -0000 --_000_34966E97BE8AD64EAE9D3D6E4DEE36F258171A34SZXEMA501MBSchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWJoaWphbiwNCg0KVGhhbmtzIGZvciB0aGUgZmVlZGJhY2suDQoNClNpbmNlIHRoaXMgaXMg cmVsYXRlZCB0byBhdXRoZW50aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlvbiwgSSBhbHNvIGNvcHkg dG8gYWNlIG1haWxpbmcgbGlzdCBmb3IgZGlzY3Vzc2lvbi4NCg0KSSBjaGVja2VkIHNlY3VyZSBy ZWNvbmZpZ3VyYXRpb24gZHJhZnQsIGl0IGFsc28gaW5jbHVkZXMgTm9kZSBJZGVudGlmaWVyIGZv ciBhdXRoZW50aWNhdGlvbi4NCmh0dHA6Ly90b29scy5pZXRmLm9yZy9wZGYvZHJhZnQta2FuZy1j b3JlLXNlY3VyZS1yZWNvbmZpZ3VyYXRpb24tMDEucGRmDQoNCkFuZCBJIGNoZWNrZWQgQXV0aG9y aXphdGlvbiBJbmZvcm1hdGlvbiBGb3JtYXQgZHJhZnQsIGl0IHByb3Bvc2VzIHRvIHVzZSBVUkkt SG9zdCBmb3IgYXV0aGVudGljYXRpb24uDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvcGRmL2RyYWZ0 LWJvcm1hbm4tY29yZS1hY2UtYWlmLTAwLnBkZg0KDQpJIHdpbGwgYWxzbyBjaGVjayBvdGhlciBy ZWxhdGVkIGRyYWZ0cyB0byBzZWUgd2hpY2ggaWRlbnRpZmllciBpcyB1c2VkLCBEZXZpY2VJRC8g Tm9kZUlEIG9yIFVSSS1Ib3N0Lg0KDQpJbiBteSBvcGluaW9uLCB1c3VhbGx5IFVSSS1Ib3N0IGlz IGRvbWFpbiBuYW1lIG9yIElQIGFkZHJlc3MsIGFuZCBpdCBpcyB2ZXJ5IGVhc2lseSB0byBiZSBj aGFuZ2VkLiBOb2RlSUQgaXMgbW9yZSBzdGFibGUgZm9yIGF1dGhlbnRpY2F0aW9uIGFuZCBhdXRo b3JpemF0aW9uLg0KDQpBbHNvLCBpZiB0aGlzIGlkZW50aWZpZXIgaW5mb3JtYXRpb24gaXMgY29u dmV5ZWQgaW4gYSBzdGFuZGFyZGl6ZWQgd2F5LCBmb3IgZXhhbXBsZSwgaW5jbHVkZWQgaW4gdGhl IENvQVAgaGVhZGVyIGFzIGFuIG9wdGlvbiwgaXQgd2lsbCBpbXByb3ZlIHRoZSBpbnRlcm9wZXJh YmlsaXR5Lg0KDQpLaW5kIFJlZ2FyZHMNCktlcGVuZw0KDQrlj5Hku7bkuro6IEFiaGlqYW4gQmhh dHRhY2hhcnl5YSBbbWFpbHRvOmFiaGlqYW4uYmhhdHRhY2hhcnl5YUB0Y3MuY29tXQ0K5Y+R6YCB 5pe26Ze0OiAyMDE05bm0NuaciDI35pelIDE2OjUyDQrmlLbku7bkuro6IExpa2VwZW5nDQrmioTp gIE6IGNvcmVAaWV0Zi5vcmcNCuS4u+mimDogUmU6IFtjb3JlXSBGdzogTmV3IFZlcnNpb24gTm90 aWZpY2F0aW9uIGZvciBkcmFmdC1saS1jb3JlLWNvYXAtbm9kZS1pZC1vcHRpb24tMDEudHh0DQoN CkhpIEtlcGVuZywNClRoYW5rcyBmb3IgdGhpcyBpbnRlcmVzdGluZyBkcmFmdC4gVGhlIGNvbmNl cHQgbWlnaHQgYmUgdXNlZnVsIGluIG1hbnkgY2FzZXMuIEluIGZhY3QsIHdlIGhhdmUgYWxzbyB1 c2VkIHRoZSBjb25jZXB0IG9mIE5vZGUgSUQgaW4gdGhlIGRyYWZ0IGh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWJoYXR0YWNoYXJ5eWEtY29yZS1jb2FwLWxpdGUtYXV0aC0wMCAoRmln LiAxIGFuZCAyKSB3aGljaCBwcmVzZW50cyBvdXIgd29yay1pbi1wcm9ncmVzcyBvbiBsaWdodHdl aWdodCBhdXRoZW50aWNhdGlvbiBhbmQga2V5LXNoYXJpbmcgd2hpY2ggd2Ugc2hhcmVkIGZldyBt b250aHMgYmFjay4gSG93ZXZlciwgd2UgdXNlZCB0aGUgcGF5bG9hZCBpdHNlbGYgZm9yIGNvbnZl eWluZyB0aGUgTm9kZUlEIGluZm9ybWF0aW9uLiBIYXZpbmcgYW4gYWRkaXRpb25hbCBvcHRpb24g dG8gY29udmV5IHRoZSBOb2RlSUQgd291bGQgYmUgdXNlZnVsLg0KDQoNClJlZ2FyZHMNCkFiaGlq YW4gQmhhdHRhY2hhcnl5YQ0KQXNzb2NpYXRlIENvbnN1bHRhbnQNClNjaWVudGlzdCwgSW5ub3Zh dGlvbiBMYWIsIEtvbGthdGEsIEluZGlhDQpUYXRhIENvbnN1bHRhbmN5IFNlcnZpY2VzIExpbWl0 ZWQNCk1haWx0bzogYWJoaWphbi5iaGF0dGFjaGFyeXlhQHRjcy5jb208bWFpbHRvOmFiaGlqYW4u YmhhdHRhY2hhcnl5YUB0Y3MuY29tPg0KV2Vic2l0ZTogaHR0cDovL3d3dy50Y3MuY29tPGh0dHA6 Ly93d3cudGNzLmNvbS8+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KRXhwZXJpZW5jZSBjZXJ0YWludHkuICAgICAgICBJVCBTZXJ2aWNlcw0KICAgICAgICAg ICAgICAgICAgICAgICBCdXNpbmVzcyBTb2x1dGlvbnMNCiAgICAgICAgICAgICAgICAgICAgICAg Q29uc3VsdGluZw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Ci0tLS0tIEZvcndhcmRlZCBieSBBYmhpamFuIEJoYXR0YWNoYXJ5eWEvS09ML1RDUyBvbiAwNi8y Ny8yMDE0IDAyOjAxIFBNIC0tLS0tDQoNCkZyb206ICAgICAgICBBYmhpamFuIEJoYXR0YWNoYXJ5 eWEgPGFiaGlqYW4uYmhhdHRhY2hhcnl5YUBnbWFpbC5jb208bWFpbHRvOmFiaGlqYW4uYmhhdHRh Y2hhcnl5YUBnbWFpbC5jb20+Pg0KVG86ICAgICAgICBBYmhpamFuIEJoYXR0YWNoYXJ5eWEgPGFi aGlqYW4uYmhhdHRhY2hhcnl5YUB0Y3MuY29tPG1haWx0bzphYmhpamFuLmJoYXR0YWNoYXJ5eWFA dGNzLmNvbT4+DQpEYXRlOiAgICAgICAgMDYvMjcvMjAxNCAxMjo0NSBQTQ0KU3ViamVjdDogICAg ICAgIEZ3ZDogW2NvcmVdIEZ3OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWxp LWNvcmUtY29hcC1ub2RlLWlkLW9wdGlvbi0wMS50eHQNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQoNCg0KDQoNCg0KLS0tLS0tLS0tLSBGb3J3YXJkZWQgbWVzc2FnZSAtLS0tLS0t LS0tDQpGcm9tOiBMaWtlcGVuZyA8bGlrZXBlbmdAaHVhd2VpLmNvbTxtYWlsdG86bGlrZXBlbmdA aHVhd2VpLmNvbT4+DQpEYXRlOiBXZWQsIEp1biAyNSwgMjAxNCBhdCAxMjo1NSBQTQ0KU3ViamVj dDogW2NvcmVdIEZ3OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWxpLWNvcmUt Y29hcC1ub2RlLWlkLW9wdGlvbi0wMS50eHQNClRvOiAiY29yZUBpZXRmLm9yZzxtYWlsdG86Y29y ZUBpZXRmLm9yZz4iIDxjb3JlQGlldGYub3JnPG1haWx0bzpjb3JlQGlldGYub3JnPj4NCg0KDQpI ZWxsbyBhbGwsDQoNClRoaXMgZHJhZnQgaXMgcXVpdGUgc2ltcGxlLg0KDQpIb3BlIHlvdSBjYW4g c3BlbmQgc29tZSBzaG9ydCB0aW1lIHRvIHJldmlldyBpdCBhbmQgZ2l2ZSBzb21lIGZlZWRiYWNr Lg0KDQpUaGFua3MsDQpLaW5kIFJlZ2FyZHMNCktlcGVuZw0KDQotLS0tLemCruS7tuWOn+S7ti0t LS0tDQrlj5Hku7bkuro6IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzxtYWlsdG86aW50ZXJuZXQt ZHJhZnRzQGlldGYub3JnPiBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzxtYWlsdG86 aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPl0NCuWPkemAgeaXtumXtDogMjAxNOW5tDbmnIgyNeaX pSAxNDowNQ0K5pS25Lu25Lq6OiBHZW5neXUgV2VpOyBHZW5neXUgV2VpOyBMaWtlcGVuZzsgTGlr ZXBlbmcNCuS4u+mimDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1saS1jb3Jl LWNvYXAtbm9kZS1pZC1vcHRpb24tMDEudHh0DQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFm dC1saS1jb3JlLWNvYXAtbm9kZS1pZC1vcHRpb24tMDEudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVs bHkgc3VibWl0dGVkIGJ5IEtlcGVuZyBMaSBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRv cnkuDQoNCk5hbWU6ICAgICAgICAgICBkcmFmdC1saS1jb3JlLWNvYXAtbm9kZS1pZC1vcHRpb24N ClJldmlzaW9uOiAgICAgICAwMQ0KVGl0bGU6ICAgICAgICAgIENvQVAgT3B0aW9uIEV4dGVuc2lv bjogTm9kZUlkDQpEb2N1bWVudCBkYXRlOiAgMjAxNC0wNi0yNA0KR3JvdXA6ICAgICAgICAgIElu ZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6ICAgICAgICAgIDcNClVSTDogICAgICAgICAgICBo dHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1saS1jb3JlLWNvYXAtbm9k ZS1pZC1vcHRpb24tMDEudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtbGktY29yZS1jb2FwLW5vZGUtaWQtb3B0aW9uLw0KSHRtbGl6ZWQ6 ICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWxpLWNvcmUtY29hcC1ub2Rl LWlkLW9wdGlvbi0wMQ0KRGlmZjogICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlm Zj91cmwyPWRyYWZ0LWxpLWNvcmUtY29hcC1ub2RlLWlkLW9wdGlvbi0wMQ0KDQpBYnN0cmFjdDoN CiAgIENvQVAgaXMgYSBSRVNUZnVsIGFwcGxpY2F0aW9uIHByb3RvY29sIGZvciBjb25zdHJhaW5l ZCBub2RlcyBhbmQNCiAgIG5ldHdvcmtzLiAgVGhpcyBzcGVjaWZpY2F0aW9uIHByb3ZpZGVzIGEg c2ltcGxlIGV4dGVuc2lvbiBmb3IgQ29BUCwNCiAgIHRoZSBOb2RlSWQgT3B0aW9uLiAgVGhpcyBP cHRpb24gY2FuIGJlIHVzZWQgdG8gaWRlbnRpZnkgdGhlIG5vZGUsDQogICBlaXRoZXIgdGhlIGNs aWVudCBvciB0aGUgc2VydmVyLg0KDQpOb3RlDQoNCiAgIERpc2N1c3Npb24gYW5kIHN1Z2dlc3Rp b25zIGZvciBpbXByb3ZlbWVudCBhcmUgcmVxdWVzdGVkLCBhbmQgc2hvdWxkDQogICBiZSBzZW50 IHRvIGNvcmVAaWV0Zi5vcmc8bWFpbHRvOmNvcmVAaWV0Zi5vcmc+Lg0KDQoNClBsZWFzZSBub3Rl IHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1 Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJs ZSBhdCB0b29scy5pZXRmLm9yZzxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvPi4NCg0KVGhlIElFVEYg U2VjcmV0YXJpYXQNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCmNvcmUgbWFpbGluZyBsaXN0DQpjb3JlQGlldGYub3JnPG1haWx0bzpjb3JlQGlldGYu b3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlDQoNCj09PT09 LS0tLS09PT09PS0tLS0tPT09PT0NCk5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBp biB0aGlzIGUtbWFpbA0KbWVzc2FnZSBhbmQvb3IgYXR0YWNobWVudHMgdG8gaXQgbWF5IGNvbnRh aW4NCmNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uLiBJZiB5b3UgYXJlDQpu b3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgYW55IGRpc3NlbWluYXRpb24sIHVzZSwNCnJldmll dywgZGlzdHJpYnV0aW9uLCBwcmludGluZyBvciBjb3B5aW5nIG9mIHRoZQ0KaW5mb3JtYXRpb24g Y29udGFpbmVkIGluIHRoaXMgZS1tYWlsIG1lc3NhZ2UNCmFuZC9vciBhdHRhY2htZW50cyB0byBp dCBhcmUgc3RyaWN0bHkgcHJvaGliaXRlZC4gSWYNCnlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29t bXVuaWNhdGlvbiBpbiBlcnJvciwNCnBsZWFzZSBub3RpZnkgdXMgYnkgcmVwbHkgZS1tYWlsIG9y IHRlbGVwaG9uZSBhbmQNCmltbWVkaWF0ZWx5IGFuZCBwZXJtYW5lbnRseSBkZWxldGUgdGhlIG1l c3NhZ2UNCmFuZCBhbnkgYXR0YWNobWVudHMuIFRoYW5rIHlvdQ0K --_000_34966E97BE8AD64EAE9D3D6E4DEE36F258171A34SZXEMA501MBSchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OuWui+S9kzsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiXEDlrovkvZMiOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUg RGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwN Cgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCglt YXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7 fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IuaJueazqOahhuaWh+acrCBDaGFyIjsN CgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OS4wcHQ7 DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkNoYXINCgl7bXNvLXN0eWxlLW5hbWU6IuaJueazqOah huaWh+acrCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6 5om55rOo5qGG5paH5pysOw0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6 ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGxhbmc9IlpILUNOIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIEFiaGlqYW4sPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyBmb3IgdGhlIGZlZWRiYWNrLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TaW5jZSB0aGlzIGlzIHJlbGF0ZWQgdG8g YXV0aGVudGljYXRpb24gYW5kIGF1dGhvcml6YXRpb24sIEkgYWxzbyBjb3B5IHRvIGFjZSBtYWls aW5nIGxpc3QgZm9yIGRpc2N1c3Npb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPkkgY2hlY2tlZCBzZWN1cmUgcmVjb25maWd1cmF0aW9uIGRyYWZ0LCBpdCBhbHNvIGluY2x1 ZGVzIE5vZGUgSWRlbnRpZmllciBmb3IgYXV0aGVudGljYXRpb24uPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcv cGRmL2RyYWZ0LWthbmctY29yZS1zZWN1cmUtcmVjb25maWd1cmF0aW9uLTAxLnBkZiI+aHR0cDov L3Rvb2xzLmlldGYub3JnL3BkZi9kcmFmdC1rYW5nLWNvcmUtc2VjdXJlLXJlY29uZmlndXJhdGlv bi0wMS5wZGY8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFuZCBJIGNo ZWNrZWQgQXV0aG9yaXphdGlvbiBJbmZvcm1hdGlvbiBGb3JtYXQgZHJhZnQsIGl0IHByb3Bvc2Vz IHRvIHVzZSBVUkktSG9zdCBmb3IgYXV0aGVudGljYXRpb24uPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvcGRm L2RyYWZ0LWJvcm1hbm4tY29yZS1hY2UtYWlmLTAwLnBkZiI+aHR0cDovL3Rvb2xzLmlldGYub3Jn L3BkZi9kcmFmdC1ib3JtYW5uLWNvcmUtYWNlLWFpZi0wMC5wZGY8L2E+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgd2lsbCBhbHNvIGNoZWNrIG90aGVyIHJlbGF0ZWQgZHJh ZnRzIHRvIHNlZSB3aGljaCBpZGVudGlmaWVyIGlzIHVzZWQsIERldmljZUlELyBOb2RlSUQgb3Ig VVJJLUhvc3QuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SW4gbXkgb3Bp bmlvbiwgdXN1YWxseSBVUkktSG9zdCBpcyBkb21haW4gbmFtZSBvciBJUCBhZGRyZXNzLCBhbmQg aXQgaXMgdmVyeSBlYXNpbHkgdG8gYmUgY2hhbmdlZC4gTm9kZUlEIGlzIG1vcmUgc3RhYmxlIGZv ciBhdXRoZW50aWNhdGlvbiBhbmQNCiBhdXRob3JpemF0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5BbHNvLCBpZiB0aGlzIGlkZW50aWZpZXIgaW5mb3JtYXRpb24gaXMg Y29udmV5ZWQgaW4gYSBzdGFuZGFyZGl6ZWQgd2F5LCBmb3IgZXhhbXBsZSwgaW5jbHVkZWQgaW4g dGhlIENvQVAgaGVhZGVyIGFzIGFuIG9wdGlvbiwgaXQgd2lsbCBpbXByb3ZlDQogdGhlIGludGVy b3BlcmFiaWxpdHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPktpbmQgUmVn YXJkczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+S2VwZW5nPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBi bHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0Ij7lj5Hku7bkuro8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L3NwYW4+ PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+IEFiaGlqYW4g QmhhdHRhY2hhcnl5YSBbbWFpbHRvOmFiaGlqYW4uYmhhdHRhY2hhcnl5YUB0Y3MuY29tXQ0KPGJy Pg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij7lj5HpgIHml7bpl7Q8 c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdCI+IDIwMTQ8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQiPuW5tDxzcGFuIGxhbmc9IkVOLVVTIj42PC9zcGFuPuaciDxzcGFuIGxhbmc9IkVO LVVTIj4yNzwvc3Bhbj7ml6U8c3BhbiBsYW5nPSJFTi1VUyI+IDE2OjUyPGJyPg0KPC9zcGFuPjxi PuaUtuS7tuS6ujxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1V UyI+IExpa2VwZW5nPGJyPg0KPC9zcGFuPjxiPuaKhOmAgTxzcGFuIGxhbmc9IkVOLVVTIj46PC9z cGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IGNvcmVAaWV0Zi5vcmc8YnI+DQo8L3NwYW4+PGI+ 5Li76aKYPHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4g UmU6IFtjb3JlXSBGdzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1saS1jb3Jl LWNvYXAtbm9kZS1pZC1vcHRpb24tMDEudHh0PG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkhpIEtlcGVuZyw8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiPg0KPGJyPg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5UaGFua3MgZm9yIHRoaXMgaW50ZXJlc3RpbmcgZHJhZnQuIFRoZSBjb25jZXB0 IG1pZ2h0IGJlIHVzZWZ1bCBpbiBtYW55IGNhc2VzLiBJbiBmYWN0LCB3ZSBoYXZlIGFsc28gdXNl ZCB0aGUgY29uY2VwdCBvZiBOb2RlIElEIGluIHRoZSBkcmFmdA0KPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIj48YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1iaGF0dGFj aGFyeXlhLWNvcmUtY29hcC1saXRlLWF1dGgtMDAiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi Pmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJoYXR0YWNoYXJ5eWEtY29yZS1jb2Fw LWxpdGUtYXV0aC0wMDwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij4oRmlnLiAxIGFuZCAyKSB3aGljaCBwcmVzZW50cyBvdXIgd29yay1p bi1wcm9ncmVzcyBvbiBsaWdodHdlaWdodCBhdXRoZW50aWNhdGlvbiBhbmQga2V5LXNoYXJpbmcg d2hpY2ggd2Ugc2hhcmVkIGZldyBtb250aHMgYmFjay4gSG93ZXZlciwgd2UgdXNlZCB0aGUgcGF5 bG9hZCBpdHNlbGYgZm9yIGNvbnZleWluZw0KIHRoZSBOb2RlSUQgaW5mb3JtYXRpb24uIEhhdmlu ZyBhbiBhZGRpdGlvbmFsIG9wdGlvbiB0byBjb252ZXkgdGhlIE5vZGVJRCB3b3VsZCBiZSB1c2Vm dWwuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj4NCjxicj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0KPGJyPg0KUmVnYXJkczxicj4NCkFiaGlq YW4gQmhhdHRhY2hhcnl5YTxicj4NCkFzc29jaWF0ZSBDb25zdWx0YW50PGJyPg0KU2NpZW50aXN0 LCBJbm5vdmF0aW9uIExhYiwgS29sa2F0YSwgSW5kaWE8YnI+DQpUYXRhIENvbnN1bHRhbmN5IFNl cnZpY2VzIExpbWl0ZWQ8YnI+DQpNYWlsdG86IDxhIGhyZWY9Im1haWx0bzphYmhpamFuLmJoYXR0 YWNoYXJ5eWFAdGNzLmNvbSI+YWJoaWphbi5iaGF0dGFjaGFyeXlhQHRjcy5jb208L2E+PGJyPg0K V2Vic2l0ZTogPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48YSBocmVmPSJodHRwOi8vd3d3LnRj cy5jb20vIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5odHRwOi8vd3d3LnRjcy5jb208L3Nw YW4+PC9hPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJy Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpFeHBl cmllbmNlIGNlcnRhaW50eS4gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7SVQgU2VydmljZXM8 YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0J1c2luZXNzIFNvbHV0aW9uczxicj4NCiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Q29uc3VsdGluZzxicj4NCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj4gPGJy Pg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6cHVy cGxlIj4tLS0tLSBGb3J3YXJkZWQgYnkgQWJoaWphbiBCaGF0dGFjaGFyeXlhL0tPTC9UQ1Mgb24g MDYvMjcvMjAxNCAwMjowMSBQTSAtLS0tLTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+DQo8YnI+ DQo8YnI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojNUY1RjVGIj5Gcm9tOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+QWJoaWphbiBCaGF0dGFjaGFyeXlhICZs dDs8YSBocmVmPSJtYWlsdG86YWJoaWphbi5iaGF0dGFjaGFyeXlhQGdtYWlsLmNvbSI+YWJoaWph bi5iaGF0dGFjaGFyeXlhQGdtYWlsLmNvbTwvYT4mZ3Q7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT Ij4NCjxicj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo3LjVw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiM1RjVGNUYiPlRvOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+QWJoaWphbiBCaGF0dGFjaGFyeXlhICZs dDs8YSBocmVmPSJtYWlsdG86YWJoaWphbi5iaGF0dGFjaGFyeXlhQHRjcy5jb20iPmFiaGlqYW4u YmhhdHRhY2hhcnl5YUB0Y3MuY29tPC9hPiZndDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPg0K PGJyPg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzVGNUY1RiI+RGF0ZTogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjA2LzI3LzIwMTQgMTI6NDUgUE08L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiPg0KPGJyPg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzVGNUY1RiI+U3ViamVjdDogJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjcuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZ3 ZDogW2NvcmVdIEZ3OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWxpLWNvcmUt Y29hcC1ub2RlLWlkLW9wdGlvbi0wMS50eHQ8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPg0KPG86 cD48L286cD48L3NwYW4+PC9wPg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVy IiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPjxzcGFuIGxhbmc9IkVOLVVTIj4NCjxociBzaXpl PSIzIiB3aWR0aD0iMTAwJSIgbm9zaGFkZT0iIiBzdHlsZT0iY29sb3I6I0EwQTBBMCIgYWxpZ249 ImNlbnRlciI+DQo8L3NwYW4+PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KLS0tLS0tLS0tLSBGb3J3YXJk ZWQgbWVzc2FnZSAtLS0tLS0tLS0tPGJyPg0KRnJvbTogPGI+TGlrZXBlbmc8L2I+ICZsdDs8YSBo cmVmPSJtYWlsdG86bGlrZXBlbmdAaHVhd2VpLmNvbSI+bGlrZXBlbmdAaHVhd2VpLmNvbTwvYT4m Z3Q7PGJyPg0KRGF0ZTogV2VkLCBKdW4gMjUsIDIwMTQgYXQgMTI6NTUgUE08YnI+DQpTdWJqZWN0 OiBbY29yZV0gRnc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbGktY29yZS1j b2FwLW5vZGUtaWQtb3B0aW9uLTAxLnR4dDxicj4NClRvOiAmcXVvdDs8YSBocmVmPSJtYWlsdG86 Y29yZUBpZXRmLm9yZyI+Y29yZUBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0 bzpjb3JlQGlldGYub3JnIj5jb3JlQGlldGYub3JnPC9hPiZndDs8YnI+DQo8YnI+DQo8YnI+DQpI ZWxsbyBhbGwsPGJyPg0KPGJyPg0KVGhpcyBkcmFmdCBpcyBxdWl0ZSBzaW1wbGUuPGJyPg0KPGJy Pg0KSG9wZSB5b3UgY2FuIHNwZW5kIHNvbWUgc2hvcnQgdGltZSB0byByZXZpZXcgaXQgYW5kIGdp dmUgc29tZSBmZWVkYmFjay48YnI+DQo8YnI+DQpUaGFua3MsPGJyPg0KS2luZCBSZWdhcmRzPGJy Pg0KS2VwZW5nPGJyPg0KPGJyPg0KLS0tLS08L3NwYW4+6YKu5Lu25Y6f5Lu2PHNwYW4gbGFuZz0i RU4tVVMiPi0tLS0tPGJyPg0KPC9zcGFuPuWPkeS7tuS6ujxzcGFuIGxhbmc9IkVOLVVTIj46IDxh IGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciPmludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZzwvYT4gW21haWx0bzo8YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnIj5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L2E+XTxicj4NCjwvc3Bhbj7lj5HpgIHml7bp l7Q8c3BhbiBsYW5nPSJFTi1VUyI+OiAyMDE0PC9zcGFuPuW5tDxzcGFuIGxhbmc9IkVOLVVTIj42 PC9zcGFuPuaciDxzcGFuIGxhbmc9IkVOLVVTIj4yNTwvc3Bhbj7ml6U8c3BhbiBsYW5nPSJFTi1V UyI+IDE0OjA1PGJyPg0KPC9zcGFuPuaUtuS7tuS6ujxzcGFuIGxhbmc9IkVOLVVTIj46IEdlbmd5 dSBXZWk7IEdlbmd5dSBXZWk7IExpa2VwZW5nOyBMaWtlcGVuZzxicj4NCjwvc3Bhbj7kuLvpopg8 c3BhbiBsYW5nPSJFTi1VUyI+OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWxp LWNvcmUtY29hcC1ub2RlLWlkLW9wdGlvbi0wMS50eHQ8YnI+DQo8YnI+DQpBIG5ldyB2ZXJzaW9u IG9mIEktRCwgZHJhZnQtbGktY29yZS1jb2FwLW5vZGUtaWQtb3B0aW9uLTAxLnR4dDxicj4NCmhh cyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgS2VwZW5nIExpIGFuZCBwb3N0ZWQgdG8g dGhlIElFVEYgcmVwb3NpdG9yeS48YnI+DQo8YnI+DQpOYW1lOiAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IGRyYWZ0LWxpLWNvcmUtY29hcC1ub2RlLWlkLW9wdGlvbjxicj4NClJl dmlzaW9uOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAwMTxicj4NClRpdGxlOiAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7Q29BUCBPcHRpb24gRXh0ZW5zaW9uOiBOb2RlSWQ8YnI+DQpE b2N1bWVudCBkYXRlOiAmbmJzcDsyMDE0LTA2LTI0PGJyPg0KR3JvdXA6ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDtJbmRpdmlkdWFsIFN1Ym1pc3Npb248YnI+DQpQYWdlczogJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzc8YnI+DQpVUkw6ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9p bnRlcm5ldC1kcmFmdHMvZHJhZnQtbGktY29yZS1jb2FwLW5vZGUtaWQtb3B0aW9uLTAxLnR4dCIg dGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0 LWxpLWNvcmUtY29hcC1ub2RlLWlkLW9wdGlvbi0wMS50eHQ8L2E+PGJyPg0KU3RhdHVzOiAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtbGktY29yZS1jb2FwLW5vZGUtaWQtb3B0aW9uLyIgdGFyZ2V0PSJfYmxh bmsiPg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbGktY29yZS1jb2Fw LW5vZGUtaWQtb3B0aW9uLzwvYT48YnI+DQpIdG1saXplZDogJm5ic3A7ICZuYnNwOyAmbmJzcDsg PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbGktY29yZS1jb2FwLW5v ZGUtaWQtb3B0aW9uLTAxIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1saS1jb3JlLWNvYXAtbm9kZS1pZC1vcHRpb24tMDE8L2E+PGJyPg0KRGlmZjog Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8YSBocmVmPSJodHRwOi8vd3d3Lmll dGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1saS1jb3JlLWNvYXAtbm9kZS1pZC1vcHRpb24tMDEi IHRhcmdldD0iX2JsYW5rIj4NCmh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0 LWxpLWNvcmUtY29hcC1ub2RlLWlkLW9wdGlvbi0wMTwvYT48YnI+DQo8YnI+DQpBYnN0cmFjdDo8 YnI+DQombmJzcDsgJm5ic3A7Q29BUCBpcyBhIFJFU1RmdWwgYXBwbGljYXRpb24gcHJvdG9jb2wg Zm9yIGNvbnN0cmFpbmVkIG5vZGVzIGFuZDxicj4NCiZuYnNwOyAmbmJzcDtuZXR3b3Jrcy4gJm5i c3A7VGhpcyBzcGVjaWZpY2F0aW9uIHByb3ZpZGVzIGEgc2ltcGxlIGV4dGVuc2lvbiBmb3IgQ29B UCw8YnI+DQombmJzcDsgJm5ic3A7dGhlIE5vZGVJZCBPcHRpb24uICZuYnNwO1RoaXMgT3B0aW9u IGNhbiBiZSB1c2VkIHRvIGlkZW50aWZ5IHRoZSBub2RlLDxicj4NCiZuYnNwOyAmbmJzcDtlaXRo ZXIgdGhlIGNsaWVudCBvciB0aGUgc2VydmVyLjxicj4NCjxicj4NCk5vdGU8YnI+DQo8YnI+DQom bmJzcDsgJm5ic3A7RGlzY3Vzc2lvbiBhbmQgc3VnZ2VzdGlvbnMgZm9yIGltcHJvdmVtZW50IGFy ZSByZXF1ZXN0ZWQsIGFuZCBzaG91bGQ8YnI+DQombmJzcDsgJm5ic3A7YmUgc2VudCB0byA8YSBo cmVmPSJtYWlsdG86Y29yZUBpZXRmLm9yZyI+Y29yZUBpZXRmLm9yZzwvYT4uPGJyPg0KPGJyPg0K PGJyPg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZy b20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQg ZGlmZiBhcmUgYXZhaWxhYmxlIGF0DQo8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvIiB0 YXJnZXQ9Il9ibGFuayI+dG9vbHMuaWV0Zi5vcmc8L2E+Ljxicj4NCjxicj4NClRoZSBJRVRGIFNl Y3JldGFyaWF0PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188YnI+DQpjb3JlIG1haWxpbmcgbGlzdDx1PjxzcGFuIHN0eWxlPSJjb2xvcjpi bHVlIj48YnI+DQo8L3NwYW4+PC91PjxhIGhyZWY9Im1haWx0bzpjb3JlQGlldGYub3JnIj5jb3Jl QGlldGYub3JnPC9hPjx1PjxzcGFuIHN0eWxlPSJjb2xvcjpibHVlIj48YnI+DQo8L3NwYW4+PC91 PjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZSIgdGFy Z2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZTwv YT4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIj49PT09PS0t LS0tPT09PT0tLS0tLT09PT09PGJyPg0KTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVk IGluIHRoaXMgZS1tYWlsPGJyPg0KbWVzc2FnZSBhbmQvb3IgYXR0YWNobWVudHMgdG8gaXQgbWF5 IGNvbnRhaW4gPGJyPg0KY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24uIElm IHlvdSBhcmUgPGJyPg0Kbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBkaXNzZW1pbmF0 aW9uLCB1c2UsIDxicj4NCnJldmlldywgZGlzdHJpYnV0aW9uLCBwcmludGluZyBvciBjb3B5aW5n IG9mIHRoZSA8YnI+DQppbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBlLW1haWwgbWVzc2Fn ZSA8YnI+DQphbmQvb3IgYXR0YWNobWVudHMgdG8gaXQgYXJlIHN0cmljdGx5IHByb2hpYml0ZWQu IElmIDxicj4NCnlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwg PGJyPg0KcGxlYXNlIG5vdGlmeSB1cyBieSByZXBseSBlLW1haWwgb3IgdGVsZXBob25lIGFuZCA8 YnI+DQppbW1lZGlhdGVseSBhbmQgcGVybWFuZW50bHkgZGVsZXRlIHRoZSBtZXNzYWdlIDxicj4N CmFuZCBhbnkgYXR0YWNobWVudHMuIFRoYW5rIHlvdTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_34966E97BE8AD64EAE9D3D6E4DEE36F258171A34SZXEMA501MBSchi_-- From nobody Mon Jun 30 01:32:39 2014 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D89F01A005F for ; Mon, 30 Jun 2014 01:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.151 X-Spam-Level: X-Spam-Status: No, score=0.151 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4A2tkkuL0yFI for ; Mon, 30 Jun 2014 01:32:32 -0700 (PDT) Received: from bohuslav.ifi.uzh.ch (bohuslav.ifi.uzh.ch [130.60.155.10]) by ietfa.amsl.com (Postfix) with ESMTP id CFD971A0048 for ; Mon, 30 Jun 2014 01:32:30 -0700 (PDT) Received: from authenticated sender schmitt by bohuslav.ifi.uzh.ch (postfix) with ESMTPSA id SA; <229F27FC6B> Message-ID: <53B1209C.5020200@ifi.uzh.ch> Date: Mon, 30 Jun 2014 10:32:28 +0200 From: Corinna Schmitt User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: ace@ietf.org, Hannes Tschofenig References: <53086642.5050609@gmx.net> <53134E58.20608@ifi.uzh.ch> <531F6177.5040704@gmx.net> In-Reply-To: <531F6177.5040704@gmx.net> Content-Type: multipart/alternative; boundary="------------030008080208010109030404" X-Virus-Scanned: clamav-milter 0.97.8 at bohuslav X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/ace/3GwDJ9zPPIE3tL8TDT_8KfTQVI0 Cc: Burkhard Stiller Subject: Re: [Ace] draft-schmitt-two-way-authentication-for-iot-02 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments $ace$" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 08:32:38 -0000 This is a multi-part message in MIME format. --------------030008080208010109030404 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Dear Hannes, based on the discussions of the pre-meeting in Stockholm we updated our draft and generalized it. Our old draft "draft-schmitt-two-way-authentication-for-iot" is now replaced by "draft-schmitt-ace-twowayauth-for-iot". The mentioned projects are only examples where we have the work integrated and where it runs already successful. So we believe the draft fits into ACE and also maps the requirements outlined in https://tools.ietf.org/html/draft-seitz-ace-usecases-00. See you in Toronto at IETF 90, Corinna Am 11.03.14 20:18, schrieb Hannes Tschofenig: > Hi Corinna, > > thanks for the response. > > My suggestion would be to produce a write-up that is of generic use > (independent from your specific implementation and your EU funded project). > > However, given the charter discussions and the BOF I have my doubts > whether the work would meet many of the requirements outlined in > https://tools.ietf.org/html/draft-seitz-ace-usecases-00. > > Ciao > Hannes > > On 03/02/2014 04:29 PM, Dr. Corinna Schmitt wrote: >> Dear Hannes, >>> Hi Corinna, Hi Burkhard, >>> >>> thanks for your document. I have read through it and I ran into a few >>> questions. Your response would help me to better understand the proposed >>> idea. >> Thanks for reading the draft and make comments to it to improve it. Some >> comments can be answered right away. >>> 1) Why do you assume IEEE 802.15.4? Currently it seems that the 15.4 >>> radio will mostly be used in specialized industry segments only. Is >>> there anything in the document that would make the idea less suitable >>> for other radio technologies, for example BTLE? >> Potentially the proposed solution can work on every stack you like. So >> you can do an implementation independently of IEEE 802.15.4. >> We put IEEE 802.15.4 there, because our used stack (BLIP) uses it. >>> 2) The assumed network stack does not show 6lowpan. Was this intentional? >> Same as above. You can use the stack you want. So also 6lowpan can be >> used. It depends n you what you require and what you want to support. >>> 3) You show RPL in the stack and I was wondering whether you assume it >>> being mandatory to implement for your assumed architecture? It does not >>> seem to show up elsewhere in the document. It appears to be irrelevant >>> for your design. >> RPL was just mentioned due to our other publications. Currently our plan >> is to change to RPL (CoAP) in the future. >>> 4) Subscriber identity: You write -- >>> " >>> The identity of a default subscriber is usually preconfigured on a >>> publisher before it is deployed. >>> " >>> >>> Could you explain more what you assume is pre-configured and where it is >>> preconfigured? >> Here pre-configures means that our devices are equipped with the >> certification during compiling and programming them before deployment. >> This is due to the application scenario we support at the moment. Before >> deploying the device you have to run to steps: First creation of >> certificate, and second compiling code and play it on the device. >>> I would also suggest to avoid the term subscriber since it has two other >>> meanings that might confuse: >>> a) The term subscriber is often used in context of telecommunication as >>> the user who has a contract with a telecommunication operator. >>> b) The second use is in context of protocols that use asynchronous >>> communication (like XMPP). >>> >>> I believe your notion of subscriber does not relate to those two >>> existing uses. I guess you are more using the term subscriber to refer >>> to a device that wants some data from a sensor. Is this correct? >> Thanks for the hint. Yes you are right. The subscriber should be a >> device that wants data from the sensor. >> Usually this is one outside of the WSN. Do you have a suggestion for new >> name? >>> 5) Roles in your architecture. >>> >>> It seems that you assume that the IoT devices are publishers and that >>> there are subscribers who talk to these publishers. In some other cases >>> I have seen architectures where the IoT devices (sensors) upload the >>> data to some servers without having to act as servers themselves. In >>> your architecture it feels like the sensor nodes implement the >>> server-side functionality >> That was not our intention. >> Our network has push characteristics up to the server. Data publishing >> runs over server, because it has more resources and, therefore, can >> handle requests better. It is the gate to the world. >> Pull is only performed if you require data (measurements) at a time that >> is not pre-defined. >>> In Section 4.2.2 you write that you recommend an OpenSSL implementation >>> on the server side but the server-side would be the IoT device. While it >>> would be inappropriate to recommend a specific implementation in an IETF >>> draft/RFC it also raises the questions about the expectations on the >>> server-side. >> Thanks for the hint. >> We use OpenSSL on the server but not within the WSN. OpenSSL is used >> especially for managing rights, requests, and certificates. >>> 6. Certificate content >>> >>> In Section 4.2.2 you describe the content of a certificate and you >>> indicate that the commonName is set to "localhost". It seems to be >>> useless to include this in the certificate since a CA would not be able >>> to verify this identity information nor would any party verifying it be >>> able to use it in a meaningful way. >> Localhost in our case is a special IP address (here: sink). You are >> right, we should rename it and make clear that it is an IP address. So >> you can set is like you want. >>> It also seems to be in violation of what you write in Section 5.2 where >>> you state that "every publisher in the network MUST have an unique >>> identity.". >>> >>> You also indicated more complete information for inclusion in the >>> certificate but it is not clear to me what purpose it serves. Could you >>> explain? >> Will do it asap. >>> 7. Privacy >>> >>> In Section 5 you indicate some privacy related aspects and you hint to " >>> access regulations based on legal and regulative implications". Could >>> you briefly explain what those requirements are? >> This part we put in due to the deployment and project relations we are >> running at the moment. >> Here it means that not every device can be able to access the data, for >> example, due to legal issues in the region (EU, CH, US rights). >> This has to be stored central in the network and it has to be checked >> before giving access and creating the corresponding access ticket. >> Here we refer to the following publications: >> >> Radhika Garg, Corinna Schmitt, Burkhard Stiller: /Investigating >> Regulative Implications for User-generated Content and a Design >> Proposal/; Degruyter, PIK-Praxis der Informationsverarbeitung und >> Kommunikation, Vol. 36, No. 4, December 2013, ISSN 0930-5157, pp 1--11. >> doi:10.1515/pik-2013-0042 URL: >> http://www.degruyter.com/view/j/piko.ahead-of-print/pik-2013-0042/pik-2013-0042.xml >> >> Radhika Garg, Christos Tsiaras, Burkhard Stiller, Corinna Schmitt, >> Daniel D�nni: /Deliverable D7.1 - Basics, Requirements, Scenarios, and >> Architecture: In FLAMINGO/; Radhika Garg (Edt.), Z�rich, Switzerland, >> October 2013 >>> 8. Use Cases. >>> >>> I suggest to omit the use cases from the document since the description >>> is too brief to be useful. A small remark: From my work in the emergency >>> services environment I had gotten the impression that there are no plans >>> to take sensor input directly when initiating alerts. In fact, sensor >>> alerts do rarely even get directly to the emergency services authorities >>> but are rather pre-processed by an intermediate organization (by >>> humans). Maybe you have spoken with other people, who have different >>> plans. Where did you got your information from? >> This section is based on discussion with our project partners within >> SmartenIT (www.smartenit.eu) and Flamingo ( http://www.fp7-flamingo.eu). >> >> >>> 9. Architecture >>> >>> Figure 3 shows the architecture but it is a bit confusing since it is >>> not clear what the boxes and the lines mean. The publisher is a box >>> separate from the sensors and from the earlier description I thought >>> that the sensors are actually the publishers. Furthermore, the gateway >>> was not discussed as a role up to that point in the document. The >>> gateway shows up in Section 5.3 and its role confuses me. You write: >>> >>> " A sensor node has published its data, which is transmitted in >>> direction to the global sink (cf. Figure 3 where global sink is >>> located in the gateway component). >>> " >>> >>> Does the sensor publish the data at the gateway? From the earlier >>> sections I thought that the subscriber talks to the publisher instead. >>> Is the gateway the subscriber? Why doesn't the sensor uploads the data >>> to some server instead (which is frequently done in today's IoT >>> deployments). >> Lots of comments. >> I will address and clarify them asap. >> Furthermore, I will add a legend to the Figure and perhaps modify it >> based on you aforementioned comments. >>> Why do you call the entire document "two-way authentication" when the >>> the two way authentication is just one small part of the overall >>> authentication procedure. In fact the two-way authentication is used >>> between the subscriber and the access control server (as shown in Figure >>> 4), and between the publisher and the gateway. Furthermore, there has to >>> be some authentication between the subscriber and the publisher as well >>> (at least I hope so). >>> >>> What is the purpose of the access ticket? It shows up in Section 5.3 and >>> I wonder why there is a need for an access ticket when the two parties >>> (subscriber and publisher) already have a certificate. Why cannot you >>> use the certificate for authentication with the publisher right away? >>> >>> Where do you see the access control server being deployed? Is this an >>> entity in the local network or something you would have on the Internet? >>> >>> Why does the publisher have to authenticate to the gateway? From Figure >>> 4 it is not clear whether the gateway is just an optional component or >>> an integral part of the architecture. >>> >>> The document does not explain what the access token is and how it is >>> exchanged between the subscriber and the publisher. >>> >>> Btw, the term CA standards for Certification Authority rather than >>> Certificate Authority. >> Will be addressed soon. >>> 10. Hardware requirements. >>> >>> Hardware requirements typically are not appropriate for IETF documents. >>> While you make the argument that an RSA-based public key cryptosystem is >>> good enough from a performance point of view the currently mandatory >>> ciphersuites used in CoAP are based on ECC (for those that rely on >>> asymmetric crypto). While having hardware support for key storage is a >>> great idea I was wondering how much your architecture actually relies on >>> it. My impression that it would work fine just without a TPM chip. But >>> you might have more hardware experience than I have. Could you point me >>> to some hardware that you have in mind using? >>> >> We put this section for completeness and to show that an implementation >> exists. >> Concerning sensor nodes and TPM we are using OPAL from CSIRO. Trusting >> Computing becomes relevant nowadays when thinking about securing data. >> Drawback is that if the TPM chip is broken or you change something >> during booting everything is lost. Advantage is that the storage root >> key is stored safely and only derivates are used for your applications. >> >> Hope to answer most important questions or comments now. Others will be >> addressed soon. >> You can also talk to me during IETF in London. >> >> Regards, >> Corinna >> >> >> >> _______________________________________________ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace >> > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace -- --------------030008080208010109030404 Content-Type: multipart/related; boundary="------------040304050606050206060108" --------------040304050606050206060108 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Dear Hannes,

based on the discussions of the pre-meeting in Stockholm we updated our draft and generalized it. Our old draft "draft-schmitt-two-way-authentication-for-iot" is now replaced by "draft-schmitt-ace-twowayauth-for-iot".

The mentioned projects are only examples where we have the work integrated and where it runs already successful.
So we believe the draft fits into ACE and also maps the requirements outlined in https://tools.ietf.org/html/draft-seitz-ace-usecases-00.

See you in Toronto at IETF 90,
Corinna

Am 11.03.14 20:18, schrieb Hannes Tschofenig:

Hi Corinna, thanks for the response. My suggestion would be to produce a write-up that is of generic use (independent from your specific implementation and your EU funded project). However, given the charter discussions and the BOF I have my doubts whether the work would meet many of the requirements outlined in https://tools.ietf.org/html/draft-seitz-ace-usecases-00. Ciao Hannes On 03/02/2014 04:29 PM, Dr. Corinna Schmitt wrote:

Dear Hannes,

Hi Corinna, Hi Burkhard, thanks for your document. I have read through it and I ran into a few questions. Your response would help me to better understand the proposed idea.

Thanks for reading the draft and make comments to it to improve it. Some comments can be answered right away.

1) Why do you assume IEEE 802.15.4? Currently it seems that the 15.4 radio will mostly be used in specialized industry segments only. Is there anything in the document that would make the idea less suitable for other radio technologies, for example BTLE?

Potentially the proposed solution can work on every stack you like. So you can do an implementation independently of IEEE 802.15.4. We put IEEE 802.15.4 there, because our used stack (BLIP) uses it.

2) The assumed network stack does not show 6lowpan. Was this intentional?

Same as above. You can use the stack you want. So also 6lowpan can be used. It depends n you what you require and what you want to support.

3) You show RPL in the stack and I was wondering whether you assume it being mandatory to implement for your assumed architecture? It does not seem to show up elsewhere in the document. It appears to be irrelevant for your design.

RPL was just mentioned due to our other publications. Currently our plan is to change to RPL (CoAP) in the future.

4) Subscriber identity: You write -- " The identity of a default subscriber is usually preconfigured on a publisher before it is deployed. " Could you explain more what you assume is pre-configured and where it is preconfigured?

Here pre-configures means that our devices are equipped with the certification during compiling and programming them before deployment. This is due to the application scenario we support at the moment. Before deploying the device you have to run to steps: First creation of certificate, and second compiling code and play it on the device.

I would also suggest to avoid the term subscriber since it has two other meanings that might confuse: a) The term subscriber is often used in context of telecommunication as the user who has a contract with a telecommunication operator. b) The second use is in context of protocols that use asynchronous communication (like XMPP). I believe your notion of subscriber does not relate to those two existing uses. I guess you are more using the term subscriber to refer to a device that wants some data from a sensor. Is this correct?

Thanks for the hint. Yes you are right. The subscriber should be a device that wants data from the sensor. Usually this is one outside of the WSN. Do you have a suggestion for new name?

5) Roles in your architecture. It seems that you assume that the IoT devices are publishers and that there are subscribers who talk to these publishers. In some other cases I have seen architectures where the IoT devices (sensors) upload the data to some servers without having to act as servers themselves. In your architecture it feels like the sensor nodes implement the server-side functionality

That was not our intention. Our network has push characteristics up to the server. Data publishing runs over server, because it has more resources and, therefore, can handle requests better. It is the gate to the world. Pull is only performed if you require data (measurements) at a time that is not pre-defined.

In Section 4.2.2 you write that you recommend an OpenSSL implementation on the server side but the server-side would be the IoT device. While it would be inappropriate to recommend a specific implementation in an IETF draft/RFC it also raises the questions about the expectations on the server-side.

Thanks for the hint. We use OpenSSL on the server but not within the WSN. OpenSSL is used especially for managing rights, requests, and certificates.

6. Certificate content In Section 4.2.2 you describe the content of a certificate and you indicate that the commonName is set to "localhost". It seems to be useless to include this in the certificate since a CA would not be able to verify this identity information nor would any party verifying it be able to use it in a meaningful way.

Localhost in our case is a special IP address (here: sink). You are right, we should rename it and make clear that it is an IP address. So you can set is like you want.

It also seems to be in violation of what you write in Section 5.2 where you state that "every publisher in the network MUST have an unique identity.". You also indicated more complete information for inclusion in the certificate but it is not clear to me what purpose it serves. Could you explain?

Will do it asap.

7. Privacy In Section 5 you indicate some privacy related aspects and you hint to " access regulations based on legal and regulative implications". Could you briefly explain what those requirements are?

This part we put in due to the deployment and project relations we are running at the moment. Here it means that not every device can be able to access the data, for example, due to legal issues in the region (EU, CH, US rights). This has to be stored central in the network and it has to be checked before giving access and creating the corresponding access ticket. Here we refer to the following publications: Radhika Garg, Corinna Schmitt, Burkhard Stiller: /Investigating Regulative Implications for User-generated Content and a Design Proposal/; Degruyter, PIK-Praxis der Informationsverarbeitung und Kommunikation, Vol. 36, No. 4, December 2013, ISSN 0930-5157, pp 1–11. doi:10.1515/pik-2013-0042 <http://dx.doi.org/10.1515/pik-2013-0042> URL: http://www.degruyter.com/view/j/piko.ahead-of-print/pik-2013-0042/pik-2013-0042.xml Radhika Garg, Christos Tsiaras, Burkhard Stiller, Corinna Schmitt, Daniel Dönni: /Deliverable D7.1 - Basics, Requirements, Scenarios, and Architecture: In FLAMINGO/; Radhika Garg (Edt.), Zürich, Switzerland, October 2013

8. Use Cases. I suggest to omit the use cases from the document since the description is too brief to be useful. A small remark: From my work in the emergency services environment I had gotten the impression that there are no plans to take sensor input directly when initiating alerts. In fact, sensor alerts do rarely even get directly to the emergency services authorities but are rather pre-processed by an intermediate organization (by humans). Maybe you have spoken with other people, who have different plans. Where did you got your information from?

This section is based on discussion with our project partners within SmartenIT (www.smartenit.eu) and Flamingo ( http://www.fp7-flamingo.eu). <http://www.fp7-flamingo.eu>

9. Architecture Figure 3 shows the architecture but it is a bit confusing since it is not clear what the boxes and the lines mean. The publisher is a box separate from the sensors and from the earlier description I thought that the sensors are actually the publishers. Furthermore, the gateway was not discussed as a role up to that point in the document. The gateway shows up in Section 5.3 and its role confuses me. You write: " A sensor node has published its data, which is transmitted in direction to the global sink (cf. Figure 3 where global sink is located in the gateway component). " Does the sensor publish the data at the gateway? From the earlier sections I thought that the subscriber talks to the publisher instead. Is the gateway the subscriber? Why doesn't the sensor uploads the data to some server instead (which is frequently done in today's IoT deployments).

Lots of comments. I will address and clarify them asap. Furthermore, I will add a legend to the Figure and perhaps modify it based on you aforementioned comments.

Why do you call the entire document "two-way authentication" when the the two way authentication is just one small part of the overall authentication procedure. In fact the two-way authentication is used between the subscriber and the access control server (as shown in Figure 4), and between the publisher and the gateway. Furthermore, there has to be some authentication between the subscriber and the publisher as well (at least I hope so). What is the purpose of the access ticket? It shows up in Section 5.3 and I wonder why there is a need for an access ticket when the two parties (subscriber and publisher) already have a certificate. Why cannot you use the certificate for authentication with the publisher right away? Where do you see the access control server being deployed? Is this an entity in the local network or something you would have on the Internet? Why does the publisher have to authenticate to the gateway? From Figure 4 it is not clear whether the gateway is just an optional component or an integral part of the architecture. The document does not explain what the access token is and how it is exchanged between the subscriber and the publisher. Btw, the term CA standards for Certification Authority rather than Certificate Authority.

Will be addressed soon.

10. Hardware requirements. Hardware requirements typically are not appropriate for IETF documents. While you make the argument that an RSA-based public key cryptosystem is good enough from a performance point of view the currently mandatory ciphersuites used in CoAP are based on ECC (for those that rely on asymmetric crypto). While having hardware support for key storage is a great idea I was wondering how much your architecture actually relies on it. My impression that it would work fine just without a TPM chip. But you might have more hardware experience than I have. Could you point me to some hardware that you have in mind using?

We put this section for completeness and to show that an implementation exists. Concerning sensor nodes and TPM we are using OPAL from CSIRO. Trusting Computing becomes relevant nowadays when thinking about securing data. Drawback is that if the TPM chip is broken or you change something during booting everything is lost. Advantage is that the storage root key is stored safely and only derivates are used for your applications. Hope to answer most important questions or comments now. Others will be addressed soon. You can also talk to me during IETF in London. Regards, Corinna _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace

_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace

--

--------------040304050606050206060108 Content-Type: image/png; x-mac-type="0"; x-mac-creator="0"; name="visitenkarte.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="visitenkarte.png" iVBORw0KGgoAAAANSUhEUgAAASgAAACgCAIAAAAw8WZPAAAAAXNSR0IArs4c6QAAAARnQU1B AACxjwv8YQUAAAAgY0hSTQAAeiYAAICEAAD6AAAAgOgAAHUwAADqYAAAOpgAABdwnLpRPAAA buNJREFUeF7t3Qe8FtXRP3CT901i2htTTVeTGE035Z+YZkxijFFjQcVKVXrvvffee6/Se+9I R0CahSqCgtJBQKTl/9099y4P9yIiEOXq83zwus8+Z8+ePTtzZs7Mb2Y+9p///OeKd/uMGTNm 5cqVWq1atWr//v3v1jz9e3oGPnIzcOWVV/7ud7/z2DfeeON9993n67tMAcZ7p8/s2bMfeeSR q666Skd14s/o0aOdTH/SM5CegSwzMHny5MAjWAbXYRnMcg7muuKsvz333HOuvPXWW59++ul9 +/ad4/r0T+kZSM9A9hnAdTjopptuwp9nnZ+zMB5mu/nmm8/Nr+m5Ts9AegbedQYIMNKLGMze MivjVa1alax866233rXTdIP0DKRn4HxmIOifWXjqDMbDdRqdOnXqZPqTnoH0DFyKGcBNmLNP nz40z1QuPc14NEx86bc0412KCU/3kZ6BaAYC4/k0adKEYEt4L4PxKKP2dUEaphkvTTLpGbhU M5AwHs4i2Ii3wHsZjJdq/bxgxsvk7XPovWkl9lK90HQ/OWMGUhlvx44d1157bRBvEeNxQdxx xx0Ju7wnxjtx4sTJEyeSa/fs2b1mzZrp06YPHzp02JAh/jmYOmUyifrGG28kzU6eyBmzlh5l egYucgZSGQ/9ly1btk2bNhmMh+vw3oUxXrhq586dkyZNatyoYY1q1apXq1anVq0G9eo1rFu3 ob/16tWrU6d61arVq1WvX6/+6FGjt219NVx1kY+Uvjw9A5f/DGRhvJdffpnQixiP4INNSbV1 no/EI+hsBl2/ffuOnj17li9XrmrlKhivaZMmXTt3fnrwoKlTpsyeNXvO7NnTp00bNnRoj27d WjRv3rhhw+pVq5cuWbpTx46bN28K7KerSGymP+kZ+DDOQBbGQ/CMKYsWLboiMWa+J4kXGGb0 qFHlypatVrVqy+YtunbpsnDBgtkzZo4bOzb7Jm/evGecX75sWa+ePTWuXatW2dKl+/fre/jw YY2PH08z3oeR6NLPlGLVTJgiIMuuCP9LZZVzSzwsovGunTsbN2pUsUKF5k2bDujf74Xnn8c8 zg8cMLBCuXKv79hhzhM5dvTo2y2bN2/YoMHxY8e12bhhw/BhQ1s0bVa1cuWaNWps2rgxrXam SfTDOgPZJV5Ak12RP39+3r3zZzwtX968mW5Zr27dNq3bLFiwYPOmTXv37Hb+hRdeaFCvfptW rVu1aJnwkoO5s+c4o/3gQQN9XfbssmeXLiX9Onbo0KhRw9IlSzr+b8i9YPi55IbU49aY4yfi 5enSKclRT8czPD5pj86HiAuzMx49k7Z5RRbLCgY4h8Tz6ytbtpQpXTrs5ba8vMWZwQMHkn57 du/R47/vvPPfd92FLZ0/cuTI4UOHHIwaOfLef//7zjvuaNWyha99+vRt3qz59te2b33llT69 e7do1qxYkaKB984x4cnSENqkPs/5X3VJXijGyzKYLF8v6C6RvvD228defOGFtWvWHHrzzfPZ aV/QjdIXva8zkJ3xgn3lCiDOLADqs77y2JryH5EKNnXNmzXr3Knj/v37aJj169WbMX0GY+bK 5cunTJ78VMGCRQsXLl60qM3bcyuemzljhqt6dutWMH/+J/PntxvkynDJvr372rZp88zcuW+8 /kbMe81Lliix5eWXw9Yxu63l2LHjSxYvNs6DBw8ans+xt48tXrSI8ebNN98860Rqc/To0WZN m+Z54vF169ZdQjrW1fLlyx95ODeJ/fbbb7u7UZHhe/fuveC7RPrC88/f8+9/f+H//u/zn//c nDlz0ur3+8of/7WbXSzjRULm5Ek806RxEzZJTNK5c+eXXnypdMlSFM6li5doMGHcuP59+w3q 379mjeq7du3EVBs2rHfjwQMGdOvSuX/v3jWrVX/z4MG9+/Y9u2RJm9athw8btmDe/Igze/Zs 3bKVHeORw4dTN4cZwu3kyTffPPSrm276whe+sHbN2iBe9u8/8LOf/vSLX/wipgpSOhB9+DU8 LSfHN77+dfGIvXr0SG2TCMxwSTI1CdtEfcVdht6yCFhnmjZpqtsfXn/9gQMHjr711r3/vucr X/7y2rXR2MJVZ3QV95X6ZrPcMQy+YIEC+rzt73+rVq3qhg0bLoyHQ1cXdu1/jfbesePsmsI7 jTx5rZdwkBc8S8mFyajO0VXyrpOHfW8Sz2Vjx4whslq3arV169Y1q1a3atmyc8eOc2bNInwi Ujt5EkNWrVK1ZvXq+fPmxZlUphnTp1PMGjdswOJSrXLlgvny7969J2KJN97ApdOnTp01c2bb 1m22b9/eoV077r4e3bpHhH6md+HUyVOHDh36xc9//vnPfU6fmYy3/yc//jH58NJLEeNl/3jg 48feHjt6NA5n7EkaBHF61kvCSfvC1F+1T7ZeCR/a5TZv3oKEj9ofP/HTn/7ks5/97OZYYqcS U1ATMroNojzlTJYx/PmPf/z85z+/efPm6PwF4dSzdHjBhBUT9wljiN7FRXzi53jHLXagyH37 9x858lbGHTMfIPWeYcYgLvbu3Xfs2LGLGE7GpfFDnX6lnvQ99RnGGAZ//Ngxo0rOvJPmleW9 nC/jRZR36hQzZrkyZVq1aLFkyeIN69e3b9vu9dffGDVixBtv7Iyf5MT+ffuKFylSqkSJ8mXL 3H7bbfx4M6ZNw0779u3Ndd99LCj8B84vmB+JuPBZtHDRYw8/XKRQ4SOHDlO0WjVv7vL16zdk ed/uTnH91S9vuuqqLwSp4rP/wIGf/exnX/rSlzZu2Lh39+4qVau0bNmCCM11/3333ntP/379 XMU52aN791q1a7GjEstFixV1d+dPHD9OSyxUqBDLELZp367dnf/61x3//CdPo02pBtOmTS1W tOjAAf1LlSzlV2cGDhjwQK5ct/7lFiYi82u0NarXGPL009aXEiVKkKsUxNy5czdu0mTcuHGF Cxfu0rmLnr2fiRMnPvXUU8xXpihsDnfseB2Q4K4777rvnnt5Vg4dPvzKK6+UKF7i29/+1he+ 8H+PPfaYTa+Rv1e20X79uvXlypUrUqRI2TJlFi9afDFsE+xSR986+p6IMkvjt98+ijTfiRxx Ea/Sr3716+B/Mn6zWqVKlddefTXLuvP6668/kvvhv9zyl02bIt/vxQzJteSEV/PSSy8VLVLE HSN6OG/W03j1qlVVqlTdtXMX/rnrzjvZJ+2ngEN2vrHzrK/swiVeWHL43+rWrt2zRw/W/0kT Jgzo15/EM61+Oha74Xbv2tm+bZsmjRsVL1KU0Js0aSK6rFK58p7du/kMKlUoX71K5SqVKs5N 2b34SbfPPbdy8qRJWzZvfnrQ4LatW9uVvSfG44hH/V/60hc/9alPfe5zn/vaV79KYSMJly5Z ao/32//3/3y1GwQMd/DUk0/pnF3nq1/56qc++ckVK1bQb50nTn/60586sINFA40bN3aMl/wl 5Ht07/Hxj30Md/36l78qXqyYHkYMH+Gnf99993MrVlxzzTWf/cxn3Vr7W//ylzGjR/vp61// OsuTSb/9H7f72r170HVPbtu69ZY//9mZL171RQNwULRoUUP97ne+S2aSeKT67f/4x6HDkVHq PVGY9rNmzvrSF7/YpHHjMqVKXfPda6ZNm5Zlrc0i6rN8zUIiDerXDyr6WT/n1hpcsn79+rxP PHFg//7kQbL0w/b2veuus0JFciymMWTg8VetXJml5cL5C0y+peTc488+zuxEbzdeIF++l154 ccf2HTVq1CRCAg4k++esklCzMaNGf/5zn31126vWi+98+9tbt24bOWK4YdsdnPWVXTjjedp9 e/dWrVyJL47DAJXXrlmT6HtlyytBbQsikfb49KBBxYoUQXwMJ+PHje3SqXPRwkU2b9zUskWL B+6/P+/jjzdt1IhBJfVNWOybN23WsWOHl1560Z6Q2aZyxYpbtkTG0sTEgmAPHz70q1/+8qpo j5epah7YHyQe3WzrK1u9wv/5n//B2mYk1/33h30dLedvf/3rlZ/6FPfFiuXLceP1P/gByCjx 9bGPfezRRx5hSkXuv/rVr55fu3b5s8u+/73vfeMb39i9a1e7tm01+OY3vwlzQw0mD3XYrGmz iHliNZXW/Yn//d+HHngAb6Own//sZ/afkDomgXB2U+179+q9Yd26r3z5K9ddey0pF15tgwYN /PTYo4/ywcycMfNb3/qmUS1auNBk/u63/w83mh/KxQVAeXTuWur3ju2vOc6fL999993rYNu2 baR0o0aNyA2moA4dOljsKlWsNH78eL+aPQxWoWLFCRMmWEb7+/Tt1759+759+qD13/z611On Th0zekzXLl3r16/ft29feweT7EldK+1VyxYtrarI9403XgdB7Na1K5EFR/HG66+b3s9+5jPl ypazGw+i4PChw927dStXrvzokSMJ/0YNG331K1955OFHwoZWhzOmT0PKq1etHjpsWLeu3WrX qt2nV6+XN7/M4/W1r32NimFuF8xfULlSJauz9/j2sbcZGgy1d+/e8+fPN+zWrVozmLOu165d u3//fnQMQrJevegBJ0+afOjNQ7ZCn/70p5944gnaVvfu3V/dts19bRkqVKjYuWMncqxbNMJy NlCJjhxeXLJDmThhwnXXXkOhe+CBB1CLm9Kzvvud79h9XGLGi5aiyZOrVanct3dvE2pZmj9v Xs/uPRgVkiXZxBFfdWvXKl2iBN4rWCA/bHTtGjWeeOzxhfPnFy1cqFTxElTNxx99ZN68eanj 8wLwkvfXrk1b74+QbNywkYmM22RoAIHxfnnTTV+86iq6QZiIAwcO/uynP2Nc2bRxE7fEtddc 861vfSvMY4Xy5RE3kJq3/feY8RZRKU+cuOOfd2AnXPf44499/OMfR08jRowgJ6+++ms/+P73 se6nr7ySyFm/bl37du31QNsM96pZvYavhEm+vHkxcMJ4D+bK5cEt2L/+1a8w3sYYCeDTqVMn 7b1dmqQDil+w1Wh5+23/+N///d+pk6eElsyYH7viiqcHD3Z8y5//5BZWorO+v3eVfq7CeD/+ 0Y3r173k2GMa1fbXXnvwgQdKly6NDRhvmIK+fvXX/3LLn8uXL2/GVj73HDpmMKtUsSLSIf// 9te/0R2KFyuKmH584423/f3v3pdrv//97wPhMiA98fjjjzz88E0///mePXtoB48/9pjO/3n7 7XT4z332s3nz5OFM+v3NN1tWSpUs8fWvX61zQsbg0bHjm37xi2rVql1//fVDhwxF93g7f778 mD+T8aYbxuqVq+jhN97ww6pVqnztq18Z0H+A4V199dWYbf78BT/+0Y95s/7+178ZCRv7d77z bbxqOaMrff6zn9X5jTfeYCbDJYTkvGeeiVaW+Hk5kO1Hrv7a14x85IgRX/7SlxYvXITrvPpy 5cv36dW7Vo2aP/3xT9q2aQvnGI04/jAH7tu7J1CjiaXu6Wr2rJkF8hf49je/2aNHjxGB8V6+ 1IxnUlq2bNmsSZNpU6fOnjWrQL78hZ58avOm6DanF+Z4E2jBo4K21rhp0+FDhloL8z6RZ+6c udAtlhOYsjq1a82de4ahXCe4ZdCAAVga3VAz3Kh+3bpvHz29u4j2eIcOeWfUuUQPsdx+77rv mcRXXtmC8a757ncxD1+iDpECcqcVZzDelVdivIgfOnZ03j7zuuuuu/GHN9iU2gqSk7RBK6tF vXevXkOGDLEussdoSVC4yt2ZdpiUCEYnTTrl3rJH4sWM58W8GUnjq64KyoYP6f31q6/+7ne/ S9H9zGc+E7TrsOdElJ/8xCdmTJseWt59190f//jHRg4fbtfxpz/+0TpCfl4s470UMR440c2/ +x3z1be+8Y3q1asRgN/51rc2rN/wk5/8JISE/b9f/waxejSbAjveb3/725jtnnvuKVuGsh19 /n3nXcC3DpB4sVjBxsl2sLSeG274oZf1oxtvLFKoEBFHsg0aOJA2sW7dehTyg+99nwCc/8w8 rLt7d4SsoBQdPHDA5W7kq/UrX958NpA//clPpkyaFJ7XX+IUBa9ZvcpiUalSJWd+8Yufe4/0 +R//6Edert3NH3//B+fnzpn9/eu+x8LHrNWhfdRnty5db/7dzQ6KFStaqlQpBz/76U+s4wcP HJw0cSK59K1vftMBU/uNN9yw6rmVa9aspoksXby4QH6mwLzhkd3rB9ddZ80KLOeVEQx5Hn+c HiHsJrTBeFh9x47t48aOY2nXDDE4c4kZz51wfO1aNQkBhIXErZED+/c/cvjIGVvJmPEG9OvH X3fLH/8oIqFVq1b0GS9m5PARsNF33XFH7vvvb1Cv7jPPnFY1g5pK139m9pxXX3112bPP2gKx x9SqWdNXUiJZ5smKe/59D7q3CmK5I2+9xQNBdPzpD384fPgI1RTjURR37dplwKVLl4kYr3v3 LIxHInmvn/zkJzEbQ5GWtsX/8z8f/8Pv/0DHCNO6d89ef1u1aqkHARaBJmgsDvCbd+a8NXLK pMmB8fhYvFpbxM9+9jMzZ8586+hRQ/VQeZ54gnS1M7zlT382gYm1wDvWAxsS4TNr1syvfvWr FNpNmzYee/voJWG8SNWMTbhUuHz58nF+WpuEokTaY9++r732Ggq2uGjw29/8Bh0XLlS40FOF xo8bT6ZhvHvvucci69djb79929/+1qhBzHiPPVayZElbod/+9rd0H4IRw8yZNfuGH/7Q47Rr 165bt+5Urx9eHzEeje5HN9zw+o7tkyZOuuGH16OKTMY7aHnq1DFikvzYLm9eKr3BkDxZGG/t mtUYj2LpjtScXj17zJ8/z8xDbjA7sf1qz8/pdbNzSOM1NrbNWDdN4FtH3ipSuIi1wBnXDh40 GF8xoowbN55YmzB+PDObBZqoF7x23XXXLlm0mJvXJ7x9HwqdJZ5QDZYwBGrPXLBgweBAThiP Yd80/uJnP7eg6Pa/wnicdZUqVOzfty/RRJR5+LlxxrIzlJ9Tp6KtUes2jz/yCFNPoSefZLKz DbUXomHmfeLx+++55+EHHyhVongWVRNOSle8eeXLlitbqvTLmzaNGDacO962J7lFsO7QDEkP VGtl/fGPf+yAAAxKmhWBpkcR4rjz9amnCvm1U4cOGA95OZ4XbywjGnr8CV/pmfNj/yEevuvO aP/2zW9886+33oqSbM8MqWmTyLjCrBKuMvV/+P3v//ynPzn585/93F2gwx3f8c/bI9Pf0bf/ cdttvtqxMI1SuV1Cif30p690I8SdPIiDCRMm2ohrHGm2n/50tHVsEhmT7F5wL15lbcs6t++q ZcYNXEXaXPWF/6tRowat8qc/+TGf/ltHjtx9513snLiOZ4V8u+GGG/51xx3aWIOsoZ733nvv bdSwodEOHjTI17qxnCeBWYft8ZYsWfLQgw8SmJw6P/zh9XCGzlAR1730Em7MlStXv379vYXF ixfT3J5f+/zY0WO+8bWrX3t1m/0IzblunXp8sJH0OHnKevrLm36h/x98/3vDhgy1xuknvMEw /kzjynN01zKly7iEUIpcVnNm2w6w6onq5DtlD/vHP/7x8MMP79u3n6pJrLmWfmg5sI1kFi5e vDgWcS0VhsXBIBs2aGjHMWrkKHa1a7/73WJFi8nR/OUvfXHJokVI9Jvf+EaFCuXJTLLOpvHv f/ubBciON4iWQAPJMaqmVFvr+/Xrd813vst6BJjlzMZNZ4ccX6BxxS3ZAJh9Md7G9etNk72s dTSb5fTU3j17atWoQdvs368/QUdjHD923LgxY7t37fbEo4/16tnLDpjUpnNnIayYc9bPmTnr 1a1bEcrkiROrValii5jaLIwe7z36yKM0qN/f/DtK7MQJE6MZOXmS6YLW7n1gJC3tCiypqJCk kujCcsXOHhlFTv0H0gUNiRikT4Y+Ga8xmLn+/e9+h23sNo8fP0am5c2Td9SokWHSeRSQoAW1 RPHiwYPPKmMppQVYF/XDfkhJ++Mf/mBxpXlqsPWVLV48gYYWkwcJkpPZ84FcD+jt3nvu7dun L/Jykt7VsH59BEFeZZvb8+O8k6dsd2vWqFmmTBnvi0IY6AWJoHVCb8yoUXjg5z//ueelyJFv brRi+YqKFSsxhjVv3gwcp1evXjNmzAz384y2RowrWo6MzSFt2rTlzrELbdq0KdXLbNNrSpcq jb6Z3CxPFDANoAvsAL3KLp0716hZ004s2SzR9umBQ4cMiZTPgwebNWuGl8Lz+mvRsR/zRiwT 4ydMwPyWLZYSYkqfNiMeiOOX8QPgnvT2pnhTV65cpQOLSPv2Hdgdhg0bzt5o9SS6Vz5na7Ky YsWK7dq2a9q0mS+nTp4YNmxo5cqV586d26RJ02ARwUulSpVs2aI5FjJ7xhC2nYnCmbxBJ9nh 2Jm4o5cvX4ZaQD4YKfiHdu7cddYXd+GMN2rkCM9pO2TG+/XpQzcI+JIsH9qzrVqgVK+qZ4/u S5csYSgfO2Yswg3nWVCQfhbGMzKq4+yZszp16EiVJbgtwEwj2ZuFTuyUCJlwHCGLjx9PlqXw Nfzk48WEg6AuZsdYnnFh7BqJrzrt9c6Yej6tlMspk4Fb4saZ3Ub++miNDOexPVMNs0TcQ4aV KBpqpgNdJ8k4Q4vw9UK57mTq06VOTnIXB5Re3kJrfGaD03OV2syDhDiSM06mTGY0pbGqknxQ aXwy4yniB8qYRi/Fw3oXqSSYiiXIJKSM9kmz5InCGV1mecbk/SYHJzIHGRxd2T/ZZyk1f0Jq e2/8bAve6YfKmMNMensnxPyFM97oUSObNGw4aOCANatXYyFCL9ipsjLe668PHjjA4rRg3ryh Q4dWLF/e1q5e3ToWcraKFcuWPb92DRGRnfEisjtxgnmDJ501zBJr09+hfcSrZ9wiepWR3yKF QDOwIGG9DCQb+zair5nH0fnIG5wZphS3cybTaXoiK946/JTKAKk3DbfMaKCnTIdK8s7sdkDG f/Ob3/zPxz8ePGkp98q4NpXlkmdMHuFs7/t8zp3hBs4YZ+QGP33ezpxxclkmHj1pk9F7ZsvM Z8zwFWUAieKOwin/S+YhzHP0Y+bf1DPJcWr7cDJz6s71aPFbzHiEjDd4+sKMyYxXtvCM8WsO RynPknqD0/fNPJs8Vvxc5+tKT52qcNMwK9kf5mIYb0STBg1sABg/+vbuQ1PasX171oX51Enb 6B7du61du2bJ4iV0D1av4sWK534oN92M089+w1aYNynVgR5GqSsrIhvM1MmT165ebXfets3Z GO98aO+cbc4hTM4qbcKUZZ+45GTWu8XtOSHs3Ig7bqjwdBc98EvWQdhRx+p5+vM+zcDFMN4o sqtf374vb9o8fOgwaiToY3Z6YlRo3KD++LFjJk2YaBNFarEWCH+gNDLiUbvpkFx8z8zNsseL hJgOqZqCD2wbJowf53bAIqkSL2gyWT6xKHv3JSqs08m1Z7kkFqRZnyhDrGUsDUGlJCoTXora x4tw6gt0jl4wfuzYZUuXXjzW8ZKTRliUz2fSLvmtP7IdXjjjzZo1i0fO7o6Jn1zCVCReNhTv qZ2vvzH06aeZJWV5GD9u3HPPrWCoFezHz8bzvmTxInFmAVR9pg4ZEf3uXbsF+DVt3Hj5smep alUqVZaeLGmGUN566whQKLACRJx/0f9ff8NW0xJ+Pm/Utg0yo0XzFnrI3p6tr3jRYpCWYJ8Z N7UTO3Vq5vTpDRvU50WwdWbCejh3boYZXgoGJCsFW47gpuyyI3V1OJ+xpdt8uGfgwhnvpRdf tGGjZLKckntVK1WGLcimap7avXNnm9atGJHZLZk07QnFH4wYPnzqlEnMaM/MmQPCUrlChSyq Jqai+SyYP09L1iHBdazD3AlgRwnjOXj22We5azm+v/+979/wwxt++hPW8p+wPmfdB57tHWoD z816TgPs0L79GZfEu8ED+w/w7TA3c9QGPSwe1X969+x19113Pf/883//298pzLkffIiVuU2r Vjf/9ndQS4zXwXvx4aab9NNd5AxcIOPZtRAIsGAd2rWN4NETJ/bt1WvksGEg3ll4jx8PQgUQ wVatXp3anTq0nzVj+qwZM8SniwmaOmnStMmTy5YqlYrVjLekkcmLnXfixEmECfNuuzZtuCX4 W1IZD1CLP5S/FSry+ut/wOuNi8ZPiNCG4RPUp3DM4JYchzMEJgt7rvtzrVq5KiiHqXKJD5SR nRvQEpN6vl+fvgBQrOr/uO0f856ZB3ixcOHC3j17Yjnu6V/8/BfBX3+RLyZ9+Yd7Bi6Q8QKN Mkvy0tDWGC25E3r16EmyZaE5+h/n2/wFCwYNGkQWsX/CxYEOtG/Tlpth3JgxrNhdO3cJ+Npk rh2/+MKLTRs3nT59OifysqXPRpCxevXejhDrGa0i5nz7bcIQcAyUjDMN1/3zn/90hhWUX5GM 1fTwkUP82pHR9QDZvA+wYMaM6Ry7RiKGCMNjpNdf3xFQzgsWzHeeXxV4JUBPOHO576iRTViA ZkcgL+VvwRpvu+22alWr0YS5vAsXKgTnTYCDlYJZ7ty1K0H0fbipJ/10FzwDF8V406dOg9Vi q+QlB03gN0wiwRMRQeJhMHEMUPDQJ3yRi+3rnn8eAA9Kk1bmQxcNEi/1s2fvXszTulVLTmeQ P7Z4PsNEiMVSMXrqcAlNVYwCkMRS1ov//IfqG8D+jnfv3oU3YAi2bttmt/blL38ZWpIL+9NX fgrAh5aoZfC589sKSvDVBzrp0KHDv/zlLwU6XHvtNeGk2KJFcTwbvzAMDe824QZ8LNo92l/u 3MlRy88bocMu+IWkL/xozMCFM575sQsSWQdrv3DBQqSPjnUnxiR8jsrRc+zY9ldf4zSHwo/5 oQ/XeWAVYTUCTMMxYRLhvk+eDFfF/44GnyZLyboXX6SsVixfAWIzizh1iX7hG/9yyy0YI8lH OGDAAF/hVLS3KED04UlGIJLQpg4CS0YZ64ULBSx+/H8+PmvGTKoj5gTvgquIIi3mz+eWxHga 61zyeVApfYK8ZFkgsn+9rFwFHw0yznlPeeGMFywNZAvjXpVKlbgHunfp2kUIXdu2Hdu3jw/a AUbyH1SqUKFzhw7du3QRU2eb17VTpy6dOrVs1kxcpgP/BA3Vr1vHgWtdqLEDpk6XQ8oBKHVo 115wQ3auCxIPCAhL/O63v2MFDWwwcOBAZ4SWOBa7ASKMozIZ79uEHkSSn/D2vffe94lPfILH AtzUJaVKlEwYiWYKF0sGBldHk0YRUDOEJuS895we8WU2AxfOeIHoyROM0axxYzF1AszBncFZ alStWrJYcdgUdsiSJYqTV+wiUoxxxLVo1hSXVqxQ3p4NrlrqB9wovV+F8uVEo8vCAjztwJap fNmyMtuKCxbhDvgXAo5SZy+IRKBHGHAIY3HWCc9AtWKSggUKOmNrx/KZMJ4wEPbPkOKFQBYV ivHIW+nMXAKV5nyYFPKQpcSFIdhPUJIGHirNeJcZDefI4VwU4wXeY9IUEsrMwJjO9gjNLEpN zPi0KVMdkCQTxk9wnsSgjjKW3HfPPYLBxRAJNxRiSLUTAFq3Th0ijspXl+WzY0cxfngAZzYS zFi/PvuHG2X18J44CZ4pegM/PFmwIMuJVWDXrt3YyW7QSeGYrqI3iuYWBRMkHsZjBQ3xYIHx /vcT/wtC2bB+FAPONBJyfjLb4NjAeHzfacbLkdR9GQ/6Yhkv5r1TjRs1Jgrq1a3HrMevBRVF HEWwzMaN+bKLFC4s8teBXH033nCj8BPmeDEX4tA3btwApSnEi+4HPoYnwcapdrff9neARior BmYtlEkhOx4FMzCifupTnxRl873rrrWRu1702HXXiR9l5Rdf97Uog8DDbiTQTiiKZAc8H1/5 ylfiCL0Mxrvrrjvxm+Xg2aXP/t///Z9jO7q77767RrXqkaj88Y9lTAlRtqJX/Er8piXeZUzP OWZol4DxdCHEA2JDkIHkFrAsQoDhbhkwJ44bB8zRo2vXIYMHyXriQIRbrH+W+MY3vl63Vi0h RXJptmjalK+MRte+TRueCciPAX37yWUiaqNkyRJCE95pd4dp+bgF2tA2JbqQSuhrX/uquFtG mqJFikoJwV5SoEAB2YfkPhAwwhopPYGgSRKPNkniiQoVqC+oxC369O4jJyet9cpPXVmyRMk3 3zwoQwTx+EKcwkyGGFbNd9pq5pgXnh7o5TEDl4DxgpWFIle2dJnmzZsjX3Aqhkr1Ejq1b1+m ZKmunbrI605vnD51CiVT2pnyZcpiBtksbJzq162HY/3jKO/TsydoGBu9/EhqLURxbjHRv9Nc SQYvLdTpj+Pt2wW5eCoBLMRvCKySzUGzYGt9fcfrYGU0yeNxrBAOZF8NAU1hy2ozKdAJPEAM DCeBzjkJPCNbi2eEGk1jGi8P0s3Zo7gEjBcmIOK9ba8KJcRLHHpt2rQWB2R3JIpRRL1/XNJQ woKgBQLLsCBHC1w1kWV/JcUFBJYNGKEnmR+/vA2eXNROnluvS6wpWQ7CeLJ8AuI5nEwc3Emb yDNxZs3opJPgHkhtmbPfeXr0l8EMXDLGC2HUZAtZx1ApE96A/v1BsZIb0DzlgChfpsyTBQqo RpLniTyMnPIOLJgXGet95JKQb4cuV61K1Tq1a2/bGqUGuwymKD2E9Axc+hm4ZIyXyD3cItIH DlNFBF4v6BNGS0Dn3Xv2+NuwXv0QF8MKKlWE8jcRimXaNJ43fMiAoaIQeFeI/730j5vuMT0D l8cMXGLGS0DJ9k7SYJJd0kKxpjSoX89XyWSLFy0yacL4qZMnVShXntuAVGzauBEHoH8ay/YX cmCmue7yII/0KP5bM3CJGc8wQxR9YB6aJy8f/zhnQ/Wq1TgY+MS5B2r4r3JlTvOqVSqrSaIc lwwuIuoyWC4leP+/9dzpftMz8IHOwKVnvNTHSQwSUJ2SK4p2le5TZJ0SsIIS4EXomcrHnbZb XE4JET7Q95K++Yd8Bv67jJeksnkn82OmiEvnHfiQ01n68bLMwH+X8dLTnZ6B9AycdQbSjJcm jPQMfAAzkGa8D2DS07dMz0Ca8dI0kJ6BD2AGPpKMF2w+mZ/zmfX31PhdO0y9eXbkZzgTRWOk ZD4+V5+Z+Zsv7SDf9SnSDS5mBnI242VHY57PXCDULBe+61WXFqgZYOXJJwvvqScQygBHjBRV s36XD7R3AjJVGyCN4X63Cbssfs/BjGfoEpCJJFDDxUeKlMT/fu5k95oJVgLR7tipk7ydIhIC DPqdPn5dvWZNz569xDGcu+V5vlIDWLN6jVwZ3bt1X71qZZY+fVVnr3jxElteeeW8bnfqpIrN hvf88y8YQMoacbqkxHkOLN3sfZuBHMx4KEwAqwKOii0LxpPWUshcVAg6qFyZJXgcJEIgZIuQ 4EwyCFnJfvXrX//gB98XOBsQaoFkIx0vviTjZCxNVFFWhW9BnE43yKLkwHGYxDNOuntSR+WM WhnRANSjEkAo0k8JVaWJw02TSkO+CtuXSDcpc5tUPgoqaBhYUnbHVxVdRB7iPceyYsvYLWGh XqU5DWWHo/7T4IT3javO40Y5m/EmTpz46U9/pkOHjmKO7vxXVEoS9jr1kYjBKNleZmklxA0L qoghupdmQq22lzdvUhA8cNHevXtCEuhUPsSD5OquXTvXrn1exs5Enkj+Jy1nKr85Vv8tFLIy 87hFbbTdu/YEvTF5F9JVSMJ7y5/+BCAu6yGJnSDsDr75piSBcoS2adNGVC9MuQhj5cdSxyMD m7sEXtW/TG6ORQkKXAxh9YraWVNCugqRh4Lyk6Lt50EP6Sbv0wzkbMZTAfiqL1wV6qdLMi0a XeoHRRQ6deoo64TUg+o0pJZN10w9a/wp5C9hIQc4UCDS9773vWu+e43KktgMyrRixQq9evZU JlL6sxUrlovKFeCLGYoUKdy9e/e//vWvxKZKLC6H9q5Vq5a6hJLJ537oIdyC4nPdd79q7IqD Fi9WLMTmxlLq5JEjb/38pz8V6r569ZrTYvP48c6dOunwW9/6drkypQ3v61+7OveDD6ru4kYy d5LkkkpJhJEvTx55QQUZlyhWTP4YgcUwd5s2bVLYUZZeqXu///3vKT4uf+GggYOUQZUlTVpR 9d+tGmmZ9z5x1Xnc5sPAeKHcHBnw6KOPUgiVDZMB6ZOf/MQd/7yjR48eGC8p3aORDLyf/MQn 1CVPpJCDfn37OVm3Tl3JNr/whf+rXKmiSPZrr/nu16++WtXyBfPnhwy5KJtodfBArlwSY197 zTWqr7BnPPrIw5/8xCeFIFavVv3jH/+YMoCkaL06dWfOnKXqqqroI4ZnVPQOeqngep1IAwMr HmSsYoNXfvJTTxV8UuXuaVOnafCpT35SNaUuXbpKgla7dm3Z5tVzJ6uxk+f62BVXVK9eQ5Jf Bd+HDx9uYPJ/eljppG6++feSO+XJk2fK5CmVKlV2F0XGW7RoIaY+bXc5D454n5p8mBjvP2qs KyA+/5l5aj5ffbWK25EOqSxoQnC+ivdD06rUZzBeJAVOPProI6ovBKVOaW+UunHDevJHnukg lDCeXCxKN6qy4kCKNCextxzvbx48IKyesMWBG+NkSnZofnVepRZK41VXXdWkcZQGNxJ48Rpw 7NjbzCo33vBD7KcT8vbJgk/qYf++DLy4pGxqNrwYB+Cr7S6HmtxnNrHKEjnTrl27r3z5SwKv rA62uPICW2vcpWfPnn4lLV3L2uRY9hqrg7ymqXd/nygrfZtzzsCHgfGYWBAWmlZ73gIvhYQg 9x/dcOOBffsz9MlTGVusQJfIXXhuJCIzjSKqnP/5z3+Wy8zJwk899aMf3Sj3EsZTuzyD8fr1 y2S8ufKOKccZGO+mm26SEwnj/eRHP4qDel/A8HL4CryQRRffyu1px2XnmZB+YoORWub+++77 8he/+NILL+bO/fBvf/tbwjncDuMRtspq40kGmEJPPRUYz4LiV0kTv/XNb0iJv2nTxm9945tN mzSWoA3jqVTuV1U+pc1evSra48ntfc13viNxcHjYNC9cPjPwYWC8efPmI6xhQ4dR6iRaJ0/y 5817w/U/3LN7DyqP0hYpdRJ/NGPHJxBQuaRjEY3LOX/0aJlSpSXefHnzywTSH/7w+7/+9dZX trwsXyCKPyvjqeXgvLydzCSB8X584402cljl61+/WqVbumgkA48fW7Vq5Re/+MWmKRLPSfUk QreyHhqMjEw1alT/3Oc+F1JWR4zXurXx2E8eOXLkhz+8PmE8i4JfW7Vs+c1vfF0WpsB4zZo2 SWU8aRaxuiVAyy1btmhQpnSa8S4fjssYSc5mPDsi4uuvf/ubRJ0sCtgAsSK4B+6//+qvfVUq aHn7ZNGcOmVqEDiB94TCf+ELX7jh+uvt3277+9+nTJqocAIr4q9/9evb/n7b5z73WXwlv5hU gY89+kjgBNYUN1q0cFHY49kKOkmgsce4S+7cD3FoOOAAkM+ziZj6GjVtGnPlyvWnP/5R+9o1 a4YBUDTfOnpU1m2bwwceeMBmjFDl+mCTNE7M9uCDD1WrUkXCqOBOOHT4kAd5/NFHidNvf/tb IUVvwwYNlHRWHWXd+nWf+fSnpfpUJ8xdOnXqHD1dr16Ob/nzLSqHSvL7y5t+oe6KwkZvvnno sqO+j/CAcjDjRX7t1avLly//1JNP2iMxLXJhoTx03LdvX5aSw4cPod1ixUvIlptpVMwogrdk yRKZJvLlzVumTJmQoX3pkiWly5QhWzjBfN2/b7/k1gMHDoom6NSpRYsWlStXzsZJ/s9y5crL FoOJevfu3ahRY0qgBBb16tU/fOiwnLlVqlRRBkwy3BbNmxmXHNgMnqHPsMezFRQK7KcCBQr2 6N6dwyNTFK9ma3niiTzdu3aTSLtq1ap6s+1knlGDRQJCObVlpqEvsr5UrVKN319hzWrVqqki ZmDlK1ScN3++rrgWWrVspX9Zfd1UGaZiRYs1atgoLpT77jiYjzAvvK+PnoMZLwvwKoim4DtP jsNBIu7iqWVXzJr8L0tXiWxMlZOOQ82jjM5jX3y4Y3KQfTazDCD49pOTKWPOejK6XVzMPdtd Mu6LiVNulzGwgBA4PciUeyWmnfeVvtI3e4cZyMGM54kCICP5JM8YzoSv72RUOPdVSedJJ6kd huPkLllud8avmbfJMv/Z736Wx3mHu5zrdpmPnPrUqe3TjHCZzEDOZrzMScyE88d5ls49s7Ek OXviwFAUNsiZiA1SOzpxdgY+U5ZGl4QJvbC3G+RbKt8GGXthvSVXpfYQS9ywZFxst9lHFeT5 eRpPo3m+yAfLyZfnYMYLalXMJxnFzVNddmd9KciCnVAi97MSDaZl6oTw0HOis6WSLzY4gxmh yQ4dCkBKn5DS9+jRt0DMLmA3hR/Azdhgjx59O1Bwklz0+LsFKZxDpgW7bpZBBlY0d5eWdJN5 i5Ljv8MKmDHUeInxXJd2ADmotxzMeIYu/bsqPw5e27Zt5MiRGStuCj1loUgvm9Fvfpy7OnlJ QcI4M3bM2LJlynAqRILr5MlevXoqmB54+9CbB2vWqLEmNpkmOiFoJQxXEhWhKkP//v1nz5rZ qWOnpNlZNcwst05t075t29WrVrmcfaV69erlyparUaPmwhicfVaqSgafNIjQ1plNiTWrABvp nrgsWXhMZiR2I3lMzd5Zx5mI3NN3jKYoQ7s++zD8GkmwE6Bt3bt1MxWhWap+Hs6E/ScLsLLy qswT6HGb00tA/MoybhIdXerV4TJhzhzMeN4fFOWwYcMcrF29mjkxxazwH2rMGV8zzQwd2rdX F8VPQeVKbcNEmdRIQQ4lixd/KNcDwavO38BTFy5MPvsP7GeHJD/DGX48BlI2RgX9UpvFq39W m0pQa8MnlSKV5gRDcRICUywSg+2Lz78AL5baONFmk5PPPPPMCy9EjrvsHzRdpnTpBPzN3aLP uXPnrl+/HtLgrFOUejI1BiI5HwaQxZATfuUyZUNOFqPs42FP5tv0yM8tXx6gQhmTQPU9ccac ZJmfy4RhLtUwcjbjATEHZti6ZUsokrx27RoHEF4onS9B4T4FjJT88ZxDnh4CzIXspPcM5G55 htKEhLT245l//ON2QOdDh4CJT1HzlLYtVrjIizFBk5PFihThxHPVwAEDXeK+Rw4dIiGbNWuu OBmfOAwXMSUdfdPGjV0yccIEjgTgSb3Fmt6pdevWqT0GWaLw2PbtO/r169+sWTM98+D79O7Z S4F1qLckGogDoGbNmkYCitm7V2+IcEU2ZSilD/MouESue9VdDB7MTb0xGG6xF9DhilhzpZBy XO2G91SBAkHi+bRs0Tx1+bBqqJ7rcaZMnkT2zJgxs0uXLk0aN546dVrTpk1HjBjBf6j8k3ir nj17jBo5yvysX7/hjTdeBwQ1FRz3oS6Np2ioEsaYsaIlxowZy5uiTevWrT2vmoRmHgZ9/Ljx O19/49FHHgHdduHE8RN4VlauWKGUd9u2bT2Xik5eh/cFgkPfBtCrV68e2PdpCXipqP4y6CeH M16PHhxxFDz0V6N6dZuZmjWqL126lMyZO2f22jWrVSnqipQ6d/YWoftR8MO5c8+cPiNQ4YRx 413F+6wi9IplyytUqICybRTDm27epInqYoMHDrRjaVCvXtu2bZC4gs9g1oLcSpUsaWnX26hR o/jxlPJbv2FDsaJFpk6Z3LJ5c5KTgrdi+Yry5crjk9Dh2tVrli97dvCgwfh/1apV4pjokGTm ooULJ0+ajDQXLlx0/733GXO8LpzikYO6tr/DLerAvPzylnJlyr7x+uuulX57wfwF4h6sC5gN 0UNI099g06wOHdp3oAh07NABt4wfPz7XffeFrMH4X83QLS9vCeuOvwL5pPQGDADIVtUMB5ol K8uDDzwAzlr4qULLly2/9S9/GTd2bNHCRejVVjRTQWxWr1YtWo969hTN6NdHcudetHixsocW l7x58ryyZYvGvKkrn1u5bcuWObNnqZgtOmnDunWtW7cSh4Eb8z7++I7XtoOzzZhuwO29Jrgf RUsVG9W5laVooUKehVj+UNpgcjrjdcc5EydN4j1HuC+9+MJDDzyABIXwwDELz1F+CCwLir9P r17oA61079o1YTyiaVG8fVK62RIuvGD9+nW+hl2HIipCSJX1e27Fii5xmQegUChKQkybIUOe dgv4LMoVE0uNaAe42r0wXpvWrYiRpwoWhFp+5OFH4mJjERR7z569cG21a9dRBX41aRzXW+cc VzJJjaTFixZFEql58xXLl6cwXjWi28Ixa0a0WACg7Nq5U6Q5BrMXjW8XgXKQOEf53j17H3zg wU6dO4uHsvRUqVgxCDq3c5UDXcHQIPqE8dxu7uzZvpooSb7bt2urHwjPRvUbOFmnZk2kryq9 Y8vX4oULYdAUuLeiQc84CbNqVmnXVA9fmzVpGuEQSpZc/uwy/JzQlqXNSzG2DRs2KBplzHTR EsWKLlqw0AriwmiJqV5j+fJloVvIoeHDhls+OnboGJaMJKLyMpBVl2YIOZ3xeii57sVs2bwZ HYPzI3cUbBexbdurVStXUbeoV4+ezZs2xVpjRo/REouKQI/kXUQoTYT8OOjTp09c46Hl889H dTAD4ylstH7dOu3xtj5Rw/Rp05FmYDzhORivdu1aGI8hVJsMxpscM17/ARaC5cuXr1m7lh2V ukipU5hFvomhQ4ay06xa+Zy7h1tPGDcOPwcLCjVvxbJlWRiPNJg5Yzp5VblSZbqfZPj169XT Zt/+/YSneHYYmvnz52G8fHnzzJkzd8WKFQBlFcqWjRjv1KmK5cqJMAyP3LF9h4DwDh86ZFC8 RTnFjNeOVCf6LEmmgPoAc1eubFk6uQr1JDPgTq0aNaSrSBhPKv6pU6d4Cp24iq2rdMkStsTl SpdW/dNJJRCB4BYvXkJXN59DBj89bep0ANfiRYsuWbS4Tq1a2hi5NWXF8mUe31cQ9rHxy/Jy K5YvB/j24bOw5GzG69ShA7LzhtauXmWZP3L4kIrQY8eOmzNn9tZXtqrCZ9OCRqtbpNeuLVu2 7IwZM/55++30yUB2djIVCY2pU9lRtmx5GcosWBRjxjtRvUoVYT5UtVtvuQW5d+3WbdLESRiV MjZt2lS6mQiAu++6i/Ylao5eR1oWK1x4wrixlDEaoOKbtCb/mBDYcWzkShYvMWH8BMTtdkgz ADi7dOo8dtQosbyRfjVt2t9uvXXZ0qUx451EjuwiMN842bpgVJUrVcLSipm5+7atVLjZQn7b t21H4tE2d+/ehR/69+s/b94zIoawa/v27QcPHqTEvP1neK6tW7fBqhmzqaDaPfPMPHFStqYl ihWn1EGWkdgUh9o1a5gBxQynTJla+MknBUlAfs+bO4eSSQCSe+Da5u3BXLlEA5oiMln/BrZw wULMbxMrWMmiYAJ6dO9mxZk/f/6/77rTRprMr1O7Di0gz+OP7XzjdcqzXZyWdolUaOuXfhg8 Bw0Y4OmETRbMn4+4jhnvQ6Vy5mDG8yps53CUA+YTlISyrNYtmregpciqYLPEQgDfGCwco0aN FlBDY6RrhU0XKUT+MGYKnGOnmz17Djt4+IlWNnPGTK9cLDnCcvLZZ5996aV13j5SYyBhGGRI wIrdunbDdSLfhPkISF+37qUgEl2Ojok4VhDCSqcvvvCiMtQDBgw01Fdf3Yaw3IcNEwNoMHjg IMF77CUqchqAreabhw5ZGt4+dgxSFFc7iSXQqBxJrvUULVu2tDti15HsqEWLlhs2bIRWpTC3 atXKGYKCqta5c5cRw4YdOhhbjOJ93Yb1G8RGNW3SFOLUyfA4OjQDwiNog0L4bWbNgOAmSw8r CFMHcaeCvFgkthn9WCMYThTTtsS8tG4dY4n2Otm69ZWxY8dQHQ8ePEA7ZXbasH4dZcE4hw0d ynwiSNLwbJLhV60pONBusFu3bpCufsVqfBI0BTrLwAH9CUD7z2gVjLyCaca7NFruxfZyNhzj acRjlhUlC0IyZq0zai/7GsRgGFZG+0x3Q3J5oN3wyeKxSAFyngZwRs0yP8mFp3vIhJVmsdpn ONDjeyV3yfII2Xs7x5nEMJh9HlIGkzF7wcmS2jLJCpM5RWdBlqZ6F7Iv52cdW+pkJpdk91KE 7FUXSy6X2fU5W+JdZpOZHk56Bs53BnI244WlMDyDv/+NdfG8nEjvgOTM/hKMMAMReib67Hxf 17u1o6clYiQW25dOUMT5qoMwjKc6gqWE40QipaoM7zbSj/rvOZjxImTgsSi5nWc4cvhIAApe SlIL4XMAlJlozOzE4tY+4dbnRUoxgIad8xwpn0Of59XbmY3CTlL/zDkh7V8MXr2Ans5ySUaw VZxEmCE3mvaTMqYd0f2xY8cxYvxconwjS+alueWHupcczHgBlGxbz5gmHlQmr8R+EA4CBWec jMD4Z5yMfsgkkYTQkwszcsyePMkAGNIohJkKxJCx0mceMJ8wHjCuhPMZvUUwwwBFPM1FbJvA GdBtsgwi3+R2qaPN6OJsMUEBpZ3cInNIp/tnfhRcW6tWTaCZZc8uCyDIlIfKGH/2543Dfc/F 7R6Njy6a6qpVx4we/eqrrzVu2Ei0LjOmK3kO1LiHs6lZs4Zmad5710UjBzOeoUNISIk3e/Zs tjKZS84EQJ6BwwxaEBRI9l0+MRkLh+NhLlIrKyDFjRs2nC4WHRN+zF0Z3fCYAXIxq0iORBSk dp6p8sX6WCa78kZwasGy6DbcNwnbTa6dMGHCypUrU7six7MPO+PNRewSc2PMj107dwFzEboO xsUgmfJ2U0N44+CjTANSKmDVc51VdOtH5l9wNu51YLfXXnuVvZEbAGhG6he99ezenbN029at 7psYjd+V+D7KDXIw43nfDOuSWCZEiWgGDRhYpWrV3r37HH377aefHgLhIWPCqBEjYa840y3M cICcXc2aN2fdrlql6jPPzMUwjPi0MokkeAIgs6Smrle3Hm8SdPLokchr6759e1u0bFGrVm2+ JmEQfG4w+ERcseLF//WvO3E+vziQNN8G1JVkDbyCL7zwYrt27bnRIdpwV5hoRvmypcsEGyZX Ne+WA64tcrtJk6Zt2rR9Ye3zd999N+Al2z1HWeUqVYYNG+7K0aPHcJPobeTIUXXq1DVgcBl4 EYiZkLrChx+iQrnyQQ8MH+tRl85denTvsWPH6zzgnpcj0Ug4SPRPUXRrDhjhFJ4XkitSHUMs YmYPiYQ3G+pMJD0DAwG7hK98DOXKlnFt8utHmaPO89lzNuNhKlnDYrmBlE/xDpUvWxbFYwzw rkKFCtG7+HaLFi4Mc8hxDOj477vvHj92HLAvyCVvFXyTNZs/2n6Ok7pr5058g8CNWKhK5SpL Fi/hXwawhF8BziBDZKpdumQpkQKECc4CRgzvAh8t1R9S1icHF6xww/r1YankJuKnKl2ylFCA RMh07tTZ7dQ/AVXhsufyMmYAK5UPeL2xE5TzyBEjXFizeg1eNU5zmaQrV66M1qGN9UnMQoE8 PWhw6VIljYTHMkhX4+Gdc2DwHGikK6aSahrcxIVgJc57XoPx+Dz4ADe84YSYrE3AAIQYn57L 9cbDKdxB4plEVjds0PD5taejoghtqVy6du2q/arnVsLKOjBmrsjZs2afW2s9T9L8cDfL2YyH Vp59NgPn4cVDPwyPBSBHMEhHvbp16J8L5y/o1qWLkyWLF/NVPAHUv8zNI0cMf/Pgm+XLlFa9 AJoR40lSBPW7bNmzUBra8+pOmzKldq0oHK5i+fJJqAuEIfRJ7ty5582dC5gClmkSixQqTGpF AMW4aoIIicGDBgYEI7h9iPSJfcCRrLMdhbDhLyaCpkyZ0qFdO7gtTAuo7VeLBeCVWz/84EO2 jlKhLVq0MGStxYEtmjXXpnKFiuDaoGc4n8pK3YwYYOWqgOR6bfv2jh07YoaNGzcEMKSFwNLj oG+fvqCVXNjQBWRUtapVwFwAXPwEMSOeIEgt0ljaX0tA4EN/HYen8DW4+PbvP2AAAGh0yxAa 4om6dumapFT7cHPORT5dzmY82wxbi0TDGdCvX8h4CQMFMIUa1r30EjgFxsMMJYsVI5QwHigW /iRVYD6gojAevnLV9OnTevXoQRSgS19VCALdYE4gScqWKqWyl5PPrXgOdtGODriJXgrKGKCP gPwEkRgCE8qiiCKHPj0kpHZu0gT8MuCeMwwzjjEerVI8IY6dNjWKbNq2bWvZMmVF2UgyLawB OLNK5UrSh23dtk3RH1wEo+zXls1bIHxISLAsWiGciicNMwAUTrp6HMe2ZDHmez2hGo2hUSPA SAc0zxnTpoO/gNFE4M+KFa0drVtGz2t9oW068AjgY8IvILaC7HKSug5ikkx1OLCQlS9bThAQ /Tlgr23zwMqTh71I6vwQX56DGc+6Kw4I2M/mR6wXzSpCSxYtKmyMQkX+UNIYJKOok3btAK+e zJ9fcQ9qJ+Ai/oTWlTzTV0GiwJODBw/Ony+/JNBUTUod0rH8Q3VCZgLv2klWqlDRBgnErHSp UsTUww/lxqgLFiwsXqz42jVr8z2RBy4Z9kpyS4AskmrihImdOnTUj3BvgwkEjSswqruDO9tb zpg+TdkgLI3oGWkMHnga4llsgQgAjya2TVwfM73dncD5WKlr4MFJb2OzaxXWoDxQIHR/NS5S uPBo4Q6t2xCSJCSkuPNw4bZ/IP+lSpSkb7OFkI1AniJ94dGo3/aQ1atWE0aQdBVYK5C+kZtq wFGg6nHjxi1cYCzP2OtaDlh9NbMdtYKYeboAqGp84SXyY3xImS8HM17AFqlZ1a9fX2YMUdi+ KpwgqjJKanDq1Lxn5gpPhVoUFcZ2ggPZJ2logkRffPFFOx+bHNs8+5nVq1d16NCBGAQRtPvC J6QKsbNl88u6xRiWfVYNbZCySBlCxoZQYBty7NWrN7aBzHQM2ElRpPFKaiAsdeXKVZhEEKBq dcEHsHvXbtB7Ymfzps1GawtHAut8/vwFbdu2U3VMG/BuDYgOGE7PhVvkcdEJeKf+RXB7cBuz lSufAxPt06c3QRfkUtAAlyxaRFZ369ZVnmmTYz2KvJHHjsFG4gpD0obMpwaDU5PYrP8Vylc0 5kmTJodOEmZLpfloqnfvxmYqNwgFZGSKZmzYcA6MYJ59dslS97XrE5KX2s+HlHEu9rFyMOMl pJboP6mQwiABsvwUnjb5KRycFQOZ5WTYRGX/pE5flkQSoXEqyDO6XYqPQ6g7AcKtl9ptAhk9 Y/DvkMbi9NPFZBB4JvsgA7onOZ/l0UClGVTDr+dgmHMgRWP80BkOj3DmYmnzQ319zma8nPtq zLtNXefOnXfv2nlmIsH3+5nYReWcjtj2PME37/cAP5z3SzPeB/Zes8irD2QciWs+QtsdT8uo 9+8lpBnv/Zvr9J3SM5DMQJrx0sSQnoEPYAbSjPcBTHr6lukZSDNemgbSM/ABzECa8T6ASU/f Mj0DacZL00B6Bj6AGUgz3gcw6elbpmcgzXhpGkjPwAcwA2nG+wAmPX3L9AykGS9NA+kZ+ABm IM14H8Ckp2+ZnoEczHhxmscMMH5I7hhCb97rS4WZDLMQgIuOU+H277W3828f7hINOyOO4fSl IVDg3J8kniCjcQhNCBkv40+YkPiJMrJZJ8EZyU9JCEVSFDI1ju7MsImMyQkhF8ktUoeadBs1 eIfohIxHzoyWOOszhnGeT3xD8qbC857njL3b1L4fv+doxjsugaRMOwoehPcktDQqzfMeP+Lo JIOQux9QWIidIL04LewJGUfE1L1T6EBCxO/xbqebG3AIKfQ3yTLkZyvHoWgw70hGgR/kL1Ip QfomyQX90YnAQtmZMugvypwbLUzCC50PS5IDl8R3PPHWkWjqhCbs2bM7JErcs3uvZ08YSdj7 jtdff3Xbq8IRpb2QXdRESQkTzU9mHIObRj9l1pR3awUbBPueIywoZHPzV4LAqBTz2RbKI6rP HDoUErqde3rdyPOLAIwm8JwgbzdSP1C5lQt+X5f2whzMeN6KkiCFCxcpX768mjvmRSEuQdln ov5Px6Elj5p6gAIkhhg3Zkwo6dy8aZP1L70Ueli6eHHd2nVioZqZqTqOxQ5SMdBxdJz5axLz FjFPyoqeiKZIIsWfRFxYo5VFkU9JHGo476/g1Hx58qKSs5Kdk35Sk0z6oxrVqklmMWTw4Pnz 5rujNCoSioWrYu49JEGLHBOK9QiWlQRNLgwJHUJ2DPHjhQsXln9T7LmvIoNKlyotq8XmzS+H B1RJS+2X2nXqlChRQj4YZ6Q2Gz92rIygoorDg8ho5hYh2UT4KLckv2DqY2al1xMnhSM3adRY foCe3Xsk61d007ipg0mTJgmxdZyljkKsz2Smr86czEOHolJ7wurDTSPxHmVJy3jvyd39pNRu wwb1w7u7tFx0Ab3lbMYLOeeIK7m3vH605aVaBRFEyE0kdlu0NbKTalptGhOuio3zcS7naJmX EkKWPqm+oguPH1ezTra8kKlOqhW14MK6G9ggfFSl079mqhxbm8PqLhDbT/v37Uu4S/0gvzqJ evQfsu6RTqFlLO2itV8AePWqVTrG6YZcK/+SxJsPP/RQKKyV5Y0GaabmkdQS+MqodCv1g1QU 0YAXLmwYF5TMYOAZM2vXrOUWEq5MnKh82Fi50qSZqVi+whtv7JR/dvLEqFyZgXhezC+4XslI SdNCD+5ltP6akwH9+jspnp1AM11uahyRgD1yBMWHUuYmXz9SV+jBGwlBydnVPyeV1FMQk9Q1 53oIExjl84z0jKiQ4N69+6gbo0eNxn6+xm9nj+eVsjp5F5HUlUj32DGZF4sWLqTCkZ/27tsb K9sIIJreAwf2hzGEN67iZ4P69dKMdwHLxBmXmE35C6QeMbOWZNXhlFaUXESevFo1a6urLNeY 1H0Ki1etVk3qFOWOK1WsJNlJqxYtJUeRztkbVU1WZjuqZs8ePWlRsnFpQ0qowuU91aldS+eq z+lNTgdZfVSQrFatuvSYbVq1/sMf/oA4QqJOmQUlcZHQWvE3SVz69elrRVfRynIg54ocKtu3 vybZniRIJJWsE15/RGsxN0pRERjPZ9SIEf379lXQTycJC4WfgiClK6q8l5o8V5EwCSw0UNFS TdbQ2EdmJDUDpSSUr0VWmKaNm4Q8ufILyq0iA0WD+g0krUDrMlyE0sqknPRHFqkgE5yRu1Yi I6wlHYb0FmHOlYyVRUJ9eckpLAFS11A0ypevgLFNmhTD7qgs4e7dewIDJ0MKfbq7BIcmPzCh rKS4i1yVf0lqDPM5YcLEAf0HFCxYUBHZpc8+a3klq/M8kWf9upeGPP10hQoVpcawQjVp3ERi JSl0S5coIfWTZlKqCuo/8tYRiVUVnY5qa0s3HKeiqVSpcolixcx/SO59scR30dfnbIknKdgT jz/x5JNPNmsSZbZq07pNvz59LN5UUDm/VCr2RjGVcseoTQlLqY1e3rzl3rvvlgTJu5w+daqc JbNnziI6MJu/UdHWoUPkyUOyVE2aiaRjRJAstxUrlKdrPVXgSbLIvkKbGtVrWEddSNkjHCSH xhV66N2zR8F8+W0nsJZ8gZhZs2NH30aO8rXIfSLlHiZKDANy+6mwafwouE6t2mR1tSqVSYNA H74qE42BQ+72TZs216xZK17Io0IRDtq1aZsnTx6FKQsWKFi/Xn2XHIlqJ0RqcMkSJf/fb35D vURrmPmlFyMt2pDGjBqFQ3AsQmzbuo1nlKEoqJdlS5ci2SI+jzvv2qWzTDAOqH/9+kVZKnCm CntPFsj/zNw5tpSFCz2Fc0yC/bAMn1RN+UtlH5UwSh7BaJwnT3quSZMmWhnDE/krd8uTBQvK oSYHXKsWzTdt3HDHP26nvCycPx/34u2e3bpT/vv37xfeoIQuMhpa7yxnJtYyKjna448+Kukb SViiaFF7UfMvMWmp4sXVpldfVvFtSdaktLHLxefyXHl98jgaUprxLmrdiFZf5Ua7dpN6VeYv mpIcRCqJSuq65eXNqEeWS6RJF6JxeT1jxoxWAN3uR6lXKopMW7Z2gwYOkM6ImiR7LD3KCrp5 40aqqWoMC+fPsxVR1TH3Q7mbNm1WuFAhRRLpdWQdBpOtCK0bg0xbJFggTYmrH3n4YTk7EZbz XraRyDOp6KQslI8+/EjtWrXUHmgoU1hmfRUXSs2E2hy0bdO2atVqhC1VU1KjIB+sDldccYWF IFAMc0iF8hVcHudgjxp0aNe+b99+iHhklIEvSr9ZrVpV2fgIfyPctHGT7KOSiNKyQs5pOyvF n4MUOnb8mOxpshjGtZ2lEjtcoVyUri/6Lb5X9WpVg248beq0wYOj1NG1atRcv36DdKO7d+4k ssuWKW3XJ0116HDNmjVkjgMZqCRfDCc9nUfo27t3xM+ZezNZp3DF5s2baMKG59WYW3J42dJn B/bvp8w19Vj604h1T5zUZt2LL9FuHnzgAVkGZVKTetAW14pmybPHw3gjRgwnAx+4PxfhLJep h2VzkiLR17pxweeN6zeEEtNpxrtYxkNDiMacyq4Z8md6YWafUkfJrFq5UmQ76drVrlob/IAC vKeqFSsxYsppOX7cWGqkjF00N/obxtOPVJxv7NxZQzmO+fMaNWgwYfw4RPnmm4cOxkVV9UO9 JLJY0uSx9tW2SlXUtavXlCxRwg4K71GfnJcXjG4TLrH8Y0V0tmr1qsM0uSgzV/RJrClKk2um 7rG0fOq8/uWWW9wl2HAYFSWcJaAsGWHfZdl+Ji46Gz6SF6JCB1jOoqNz+iHpLb2f3KHO+5XU tdAQtr7Wr1sXe4RryZMK5ctZODz+sbeP4l5LQxBKfu3bu0+oEe9DZ+vff4CDMqVKrd+wgagk 1mybCRP6BR4IzVavWa0EswNSS20TBzpT+hxTydUZKdjRJ8PIVKZUaZk5ZWcsX6YsPqGTV65Y ycj79O5F37ZQhpkk8IcNifIUW0qsj8yqllEagc3qgf0HPG+ZUiWlVLXAUV9NjvRNqtWSvQS4 bYOnsxOJ52dZtGlPG1cuiu3ihVPuV6nUbc/oHl6YysNegL2HN03BkHOWQvj4Y4/LZCklprIK FmbWDUqLNyd565hRo627pCWZwDxDqWNIWPfii6+/sZNiJnlk3dq1WR3Z+qKq3IMGIg70pLFc sfrPlzcvC2SDevWdl41PyXXcpZ/evXrTyuyC6I0SUBIINDELBIlE3EkFL5Ulug6Gh4gxZsyU 4jJhJAdVK1UKxqFEPjiOWsfqn61agXz5KYoeH/V36tB+aqzU0cQ8e9KPgsaFnnrKgIsULqLW NLovUbwEg1CdWrVw7zNz5lIWlExo37YtUrRm2Z3KqDtz5ozQA6lu6iQvpKiTyXaMZL6Huutf /6Lu1qheTRZ3/dDeLXOutQzhwCWLF4WEtj169AwSL8seD08/v/Z59lL8Zj3yq+LYD+TKRQex ajxZoGB0bfcexKORFC9aTIp+Sqkq87LQSwFM0bXBk5rNg5PVrFk8D9RL2RatHfJk57rv/pjx mq5eufLAwQMVypbDqHazkhRbGW1D9J+WeBfJeiet0CNGjLQuBlMEFUj9ILttTIi1qKCUfsV3 hg8fMXnylI0bqX6bvWDrPdcTQqRKIeVZs2exgqgr8NZbR5Xz3r9/H3cg4tCnv7qVqdZ+Q4ER Ak25Dx2+eehNQ6d5yodp48SAqdkLz6+VSRZXUJ+wmeyuVFbjkQyXuT961LhKOCmEaJJ3H+wl EmwmcxHl+Vy1yvbpbPQRmf/ci3mDP0AaX5TnqVhuULAkogaT9KMZ48eQIUNtdwMvrVmzdsTI kbt2RuXEJH72UDNnzjIhhBLzCTvTM1G6segT7fcOHpRp0/RqRvvVP51NNls7KJZh02WG5cx+ bsUK+gLiHjt2rLoRJs2qpzG3xGvbtgX5lvrx1XThEzMZKxEnvaOQXt4uMVS091pf3vwyFXfi xEkyoCqDYdiS1StJz/eowAMlxcbPezRLVlJjsAQsW7bMhFhq2V3pI5HJ9OhR6wV92DFXkzdI nblYmrtE1+dg40qqNMiyssZrWkoKyxRpEq5Krj2zslesAmUa9MJFqQt2SjcZtofkzFnzYZ7R PsW5Fw0ghR5Dsyxn3tHwdmbyzOT9JeNMJYxkAIHtU0abJQ3m6WycyeVZKIOim/I4mbXHYqUx Ow0lg8nuToi4OqWj1JZZJjx7t6nzmepeP+sYkrechU4uEeNcbDc5m/Eu9unT16dn4AOagRzM eBbLZPRBOwoC6lLOZOYtguk/rLJZbhCt2SnFYrNInowLM4Esrk0VO6niNFEss8jYLG0iQGnS W1yJ/Ayxlu3howk5w5OWkez9vc5SIo6S580+1Umb0HmQOUGSx6PIQKWeqUecgYzNuCS+PExd xtPFVplU8Z78FCpsJhpH7IS/pDTwXmfq/NrnZMY7fpxxcssWxRG2ej0HDhxUEOHSTrqXGpAT sQUyep1gK1lqptIJbTDsKjOoTZVwu59Dh8LXBJpoJ7bjte0xnOKg3SZkhjH7avuhyMGGjRtY U5JLbOE2bNjI4geWoQ3XCD+4j32XF+Z2Nqs2OTjQ3mzbtlc3bFivOOtZnz1GyBzne1SyyxgS pMj5kUdGK0NVOMVGLjx7BAw6cCAq457Sizb2xgyOYRjhjRheJuNFLGQ36CnswWxVudftM5l4 wzzYHJoFM2OEoddQKzce+UZmEvMMPrpp8+bDbx6KqDae54ALDcgyW2VTcekX3/c0U+fdOAcz nilmqCxQoACsCazjunUvhepwyaoZjkmEQAepP6WKytS5ymJrdgksCNe58wiCAZBlLwJ2pIC5 tOGLZ0EN/b999K08jz/OPZg5jKikEeM7uytfBXplZgRe4dTmxEdMjgEs9PB8XGndYI6+fZQR r06dOmXKlKlapTLjQblyZSFu6tevhzIxKkc8MynPHuMNFEjevHlq166lxhBTx1nsMXFNJYUs QXaAeEKxsWha4k+4Y/T3zD1laj/hF2WG2HK13LtnjzEbQ2ob/WGApwoW7NGtW+jfje6+8061 BMMtNN7+2nYGZC+rR7fuVpAWzZt5BP4DDIMhlWoyh0yj/EChZxeqjlKkUCHNmG2xPb8O2IqZ dIlnZyKGEIAo0nLRosWKGbHfqj2YEMB5c8EH0DBnM556yEyall44abYvrlXIzEgURNrYKedB +EFEYmo+xueDaKK3EpePVXkHXDPWTML6Gq+cQb+JpYSWjGBPFSjA4a6BGIg+vftwWwErhVcb tB1m6wL58sVglIhW+KYfffhhjuCEppVibtUy8inrMwYiRmOAseKWcEmtWrWA9AMnJO8/0C4X Ip+BS/Ati2tykjfZsRKtHhlqhA09/HRW8tEtaczUHiBabkO0sg1akAio0C3RQTQlAtOsRDOT oSJGz6gSYJ5HH2vXJipbCQ4CjRlVoowrwifzAOf5+COPdOvcOQyGizXXvfc+M3t2Mg9gesEd J5ri6FtH98NVxvg1dcswlRqd4cIgVONhHyxetCgfaXTy2DFOF04Lx1FVtvETeGUxeVRbs0oV r4mnbu2aNdtffY3v4aww1w+At855y5zNeKRHcKBXr16DLbtA/ny1atYCwmShZmeP5EyFCtxK bx48wDmrUhwX9sJ4DSYh8SpGpUEFig+KzYwZylYtdQbtOetaLxicivvBSbKOeAp8kvAqMATg RQSJOHWKpZ6rmi+R6zkm8ij+BU1wJXNeE1YJbXFgQDBpYJ3u3r370qVLUjknNIM+4zcH91WC jz+NX85JhcSqVKqs8BjAGvs7lGapUqVZ+XftysB2ZhHvboHTVN4MHhdAFsLKs4tRgLHi4Nqz ew9NwTKUcL4DZQBVBQuPQEo3atBQnc0O7TOcjZwf0KfJUqGN9U5XADrd4yqZ3Bgtm7ckIWdn egWxfdmyZUBPpkyZZM6jQcbhHcFJyNOdN29eJQq5ExJG5QUh3HhKleNzkqfE2+TM4OLHaSbc JDhP4sGaQagErDaVRNG11Mm83FgujCeHM16PHqWjaoktOUxfevGFwk89ZTvUqWMnPiLeapAO OgxZBPFQIF9e72zunLla8sMiRE68ShUqzJsXvdRkpz5s+PA5szNAIZzOMGj2TlGlxZgqufgq la/A+5QQh57xGJcgwIqTsKMLFixQjxaAJuqWpH3r6EMPPIDhjYpqRMKAGloa/nXHHevXrder oIGBAweWKF4c80TdZm6QOAA5fMkiG6rRI0ciUGUrLS7aAEz97re/LV+uLJFjm9S/Xz8162hx RERQIHm0Bw0cZCsVhwedNAlPPPYYqlUxE4DOP15paiGOov268OlBg1yVaoYB++IfD/w/bOgw /jF4zgQXpta5KuoJ42kD0wyGCnwXqk+bDY44LLFg3rzQCdfl7X//O7CBn1q2bOV2XkeRIoWB 4/bt248DKedQRDz+bhQumTFt2q233NKlSxfaKfyDMwKXbv7tb82VZRFWRl1eJ7naoXA9CICO Pv9w880BqHR58lsyqhzPeDVr1qRu2QhZv4MONnTokJHDh9uPzZsblapE0JDQ9WrXpmpGK3GL FlMnTwKVUBQOzYnKCeQO0QurlS9/vmLFiou7EdngQBktQBNUy6VrpiLGq1AhqJq+gkrnzZMX TkW19IIFCgBM5H7oIVqQJRk+m/pkli3DDz34IIe4S4gaVIWRoF4QKPBkYm/k66cyhSUgiCxA DRU2HSQxaQplUi89jnEK/rXkI7hAo6HzZXE5eB+AG9hIkPxAf0ailDRmo2F6EIoiafn4o4/x Pnv8m37xC0IvuvXxEyJqBw8aDORx/3331YCfbtvWQz2cOzcfOgBa8WLFAn4a4yUSz1chObly 5YJxIzltPufMmQPdakkqWqQIHGmIh8J4ue6/H07aMfgIaCUtkWlEYGGIRQwf8U1hJxkdT5qM Dx2wCVFeQGHtUe0dDI+4BoUNwDfAIC1FMFN26tdvkDfPE8xI4cEv50/OZjwY6UBePiB5ETWw uAwcOGrkCLssaAdfMQ8oE5Cetw5WInATjIvwQRDEEUNZWOnhLQirunXrQUELlmFJGzNmTFQV uUGDu+++O6hA9CUlvyPTYhy1ybo4bNhwberUqY2qFi9eMnDAwN59ehcrVgzFJOEFkPIQzy5n PEiWc2AL28UQFuRDAQY7jqg/7KxOnoRTiwo4xyFnoQ2lC/W3Ugx5bCQbx40dg3UTksXqNjm+ Ghi8OAlJ4kER6M0eD60LHfAroCblmTRjtCDxdFi0cJFhQ6OtVwhTMkVMGsWLl6BtstzQZgd4 qN69WTUee/QxS4aW1i97vNB5vB7tJ6ysbqVKlbIAqWXta+/evXLnzq2ZWdKG/blkyZK0DA9I /qsNGEYOj0JHTZ5C1I99e/hqd0fERQcvvqASPXEdxjl92nT6vP02DdPX2lHQUwb0lApqHtwr dcN8ebJfzma8Xj17jB0zOrwnaK9Qu9yajbZodHQzWigwJ+t8zWrVAb5QFZ3Ei8EDUIt4EjmG lxQ6oaAmqmY4s3XrKxbXcEwpgg+0ZcowK2T60yiNtosJ9YDVU958Dd2CUJIVjRo2omjZaFnR O3ToWKhQIbApVGi9V9O4VKmS6DW6JCreesomqljRIqxEemCTJFHhpMlnazwiwyp0SyBJ+z2B diSAzuG5Q4qHLHu8iPH2G3aFsMezKgm9o28XyC+uZy5IKv4sVbIUiZF6LVmHSZInip9iUbfO 0f7NBzbVGpekWkiaUfYE4yRfgSotYck8AH2VK1OO7AJ8hSZjLnYX4ExbNc8IrWpmPKOY+qAw W3GaNW4irI51F9SOUs1oqWB14UKFCepXX32VZdhCCZ7qwWkxwLelS5acMSPCml6ezJY6qhzM eKj21ddeQ0+BYmDWoxQpJ07s2LH9jTeiRADIl34Cx4iWvTZaH20zorC4CPjkKVMIIpEjYTqC LXPH9h0Qj8G6Gc6Tb9Sz8NUL1qe/Wd6rbqNbZ35sooiUMKqQQGn16jWsKThWz4gG2jNE6MQS ZpWvhpdCLicobzwHBuVyEQDMKoLiUGSgaY3Jeaq1Y3XJp02bTrsL9snsBBebUt8Kj+9XEl4k m8gJC5PIJmZAV3GgGXMiJTws76idYWJn9ZMbKc4e1gVTDU1JPmahJLalCP4afzSz3oVY2PAh vYULG6ox0DPtt6M68ps3G4ApJV1BQ4NETXowBpZbQXfhwe0bx0+YCIubOQ+bpk6dRp671/r1 68yJZchPOcF/npONKymJseL3Gn+SXVMqeDL8mqwxWX5KKCMxsaTSUyoqJfSTnbhDgo/TFBZG kvIJYwsnU4+zf40vyoBrZHo6znVJ0ttZB5Y6pAyBlg3BmsxYlgFn0daS6T091TGiIPtjvtM8 pK7xqccZbJn5JKlskzxdWALOMXWnW0bzl0auZCfS9Jn0DKRnIEe7E876+s4qtc4io86mkATn +RkyJEYYhjOpP1EUQuN3IqHkkosZZJo+P8QzkIP3eGd9K1QSWxf/zmHXOvrWW7bmGcn54n18 0FEDa7HCrX3+ed5bEKegv9m6MKPbAs6YPoPrwh4yoBbfifF0yJDDCmLbmJofNhmwQdrC2WVd /sa3DzHpf7CPlrMZL2Xbdhqn//TTTwe7c8xOpzcGSWOmF5462MuQC1Azlr3Qnj2aoa9xo4YM bsAuTI6YBO6EV4oFnJlUtGW3rl1eBLOMWSqDac/cQ+pHFgYG1WRfl+w6kjFI4yPj0OkGHywV pO/+vs9ADma8iGdi0xk8brAQbHt1Gx/xsCFDnh78tLBxDm7cAZEo5Jm5TBuNiTt2wt17MN1e TgXJMzmvubm279jBssdCPf+ZeTiNKRwaA8SRI5v7wWfylKmSJsGOuTDOWxzJPKZCljfH7nLo 8GEeYSbQ3Xt261b2LrbNKINDDBzzZsNcGwOMr6RMI4YNjwXv0Q8+19z7TnbpG+ZgxkOv0FLl ypWHHfEiBw4YwIErzaOTeZ/IU7VqFeikyBfUrBlJVbx4cRlQgI/gvzZu2sixK5vlX2+9Fe+1 bNni9zf/XoIGPi7/eCCkypk4YeL9997L7ydjUpfOnSQO4Em//fbbpUtp2iTKJxkJq1P/ASuT GdYRcJkERDxyNWrWBONgKBejoPOKFStyeERcFzOexpzCXTp37t2zl5Qt0Plc2AaZ1jk/aqyY UxnPuNHrUwUKBlAIoAmpFXLxQ7s3b9rMDqxSpUpbt2yRlgfWkRe7dKmSXNIA7zKIyP8FMMX3 ChIpb7E2OpHoVnJleaxs88TCgXqSk9WqVMVpoDAEY+sYnl+2dGnJ0oOWSAWV/8cBNNOi2Fk8 Y9p0OZdopFHeruPHuKrlUwqN9QBXEVUFOHUK0AMUAwBaqiwyMGwm05+PzgzkVMYLMoQjWDiJ FNHgVLBUgb4BxKLceBE8ql4E4GzcGD6LqQOhO1mhbNk5c2djHjpnzHivUB2rx4xH3EmJi9Pk gcM2sqqCwsAHSwoowSOAYuu4BwBrGXXCvcSqdI0DYVq3ar1s6VLgKeBdQa7u2L5dlBxaQthp U6P86j4ghe3btAnHVocA/JXzC8Y6zXgfHZYLT5qDGS+ghwkxsEOSqnSJkiG3PugwQL0DYGWM B7m7dPESMqpl8xYeWA5Glkk4SRfWrVP3tde22+5RQbUXgikAh2pKTI0fO44SmPeJJwCa2rRt K/BHviqRYJrhyZUrngvTh/F0G/FzhQoyTwtKCGhMEq91XIRAHjuBambZjhRqXjhpcN9rKSWZ A7E/bLBpxkszHvDTtddee8Wtt96KQMPyHD6X1T7EYEDpJaWVLBkKmdTq2LEjbbN71279+/WX MNOAYflBpaLkykuXCleV6hz1V6lUUeQBqcX0Iic09K3AH8hJqGKX4C6cIMEjeKRiA5C44FGY Z+zo0WvWrpXpmX1EgmqAr9mz59jgMZPA4LvR3XfdBbIklTpjZteu3aZOnRKCaOSulKFdRoOn nx7CCkqiijETmtCrZ69JEybojVjmV0gzXprxcgbjeU+AjIIjxYABXkbrwslTjPhEDd8A6HME vNyxg1gTSCLOUkESRkvbQtZOqHzmRJdjV1vEkLpD5E6IA1Aoz0n7QDGjYbkRJKql9ObYLAKI viqkJToOFWrs0BYtWoh7FZojHl24YOFCv8aZRU6wrEBy+mzdGoEYiTtgaE5C5wUZgTtu377D lvKjRnbp583BqqaXl0jj+PgMGGL4NXm8VIdbuCq5PGkTqCGLkE8AK2d12WVpn3ptfIvTSbJS 73jmsC8vVSLNEu/PDORsxnt/5ih9l/QMXPIZyMGMd56wzOxTFm9YMyK7L4eNaxCA7wRAy/KY voZ3ltRDPjtNnAk6Df0HFeCsKNN33WSee5CXnC4/9B3mYMbzbpYtWy6vUcI8iQUoOcj+/jQW GGoPFkfuvR6Fk3+gL9l4hNvZN77TKGBKhYTbpkaPGYO2wWVgYqK0lpkg7ezP66HUalQ55OWX N6uywJcYb1Zfj/JhZkOZAuLYKvOvvNMy5LxtsL1uFi39A525nH3zHMx4iKBZ0yZRfoTMj/JU IcW/g7h2+elPwJSFp4XknD51GmMMt4GkfdH5zEC7ZDoyY/ZOB3R7zxmiJlPmRMaSk6nZrDM2 mUnLhEwDh5y5zTu9I+W3UEU5yOHTci8TZcrkw7UYJeTL3JfCo6m5lfp0MppED5gZER9+4tnv 3r0HV6dEZkp/GKp8M+r1hV8Dj4Vj7scK5cpivDNHmHoHNdNHuC87kDXLD2pNhoLVOZv8P7jR 52zGU3VNcishycePvQ2DIv+U5Hxy4xQvXkzCPLZEpsXVa9ZESTgkxoyqdUcVt9XiYsEXcCAB GQKKQJfHjqmJB4epJDrz4yG5igUl7NoVYTJPnFAfWGQ6OSFHy062yrhouISqfnIlAlabJi5D o0TOZoPRj58UFla7izMd54SMmu7omKFVOjC5H6XE4pZg3pT1QGIyFxJlADeJjUeGwlWrVovp VoKPTz+OSY9YRfrAkOCAT9+v7iKdCd8GDKrjUAuJKVU6CZnzpE6RlcSA9+7Z7Xk5UdTc4TUJ 1SfNlXEaAyeK3oTnO3mQBfiNndJym65169dp76TBw52q1KM3hm+w1aefHhzVOr8Myhp/cOxz 4XfO2YwHrSIBifLWXTt3ARC55Za/cLUpaHjLLbeEBGFAm9Wj/MT1uRMgUVCpnLZ8dzhBklaV 2WSMlRcE/cFh+lUmr/vuuUeZO7Qr8xxwCWkg52yUDnDrVkWbpd9CjqNHjxoSZ/gy8T169ChX tpwkKMDZfHTWAv4JiLCyZctyl1euVNG9otSA+/Yjbn6IRQsXkFdr1z7fpGkT2VflIDEGGACZ nsmoqHH8oXzCl0n1JSFn+bJlIcsgUSdMGO8nydQsHIBplStXIb2hdv7yl7/ECQ5fhBZQh10e Md6RO+64Q+Yy2ZnuvfdeTPXs0iUywEoPY7TyC4HLSFgGOOrCjRvWgwpUr1ZdAb1Vq1YpQKmu rdybUVKTOnXAXC09JnbihPGm4p577sH55kHVctrs5bBJvnDy/+CufEfGy58/P8JN1TYutyk2 NimGZJImpmhTXG1y/vB3m0y5vgkjnAZvqZmVfuHCRSFXCroPBcf9BNglozMyIhlyP/jgnNmz nh48qG3r1nLOyeEhPzSwGFHTplWrXj16Eq0YMs9jjxFTZGZAqBBxvPa41LF0Q/37RlXCBeMp m4r96GalS5biMDR1SjHjH7FIdlM6DBMLU0ogG4l8hFguPEX4SUag4XFwEymsN6kyn3/hBWxg n+avx1RqPGR0pWRKOEsiEbkyqamjkC9PHntXEDlZUlaufE6dR8147WU3mjZlqjLikXq5b7+R h6TLBw7sl2aTDJ8xY6YM0PJhmgQ7OreQH0ViMnVhZROcOWM6AFDPnlFv1jWLVFrVvGDOzc54 NKCbbrrpiqpVqwL+XuaMR7ysWPEcCIsCvDRJ9U0RLoUQWIwWJKnrvLlzPYJ4BVlxwrMIsSPi qIING9SXT5LWhIvgXYQSYUiJruCtmzRuBEs5eOBAVYXJrihT6vLl7dq0AcvEWoIhZJgO2fIk DnJ56Pm1ba/Cdnbu2Im0UcnZmTgZbv0AZONFV80U89t0yfnpDFEmJ6SD9u3bcf1TFKFqMG3o DbmHxKwYT0QFvVcaNfEWBq9SsfNMMmQUw4m9Wf26Uf4yCq+MmrVq1yarqakGuWH9Biq3NOna k2x8/ThfAV05wmTgVrs43ItOThrj/HnPPEMaW18sBDLf1qsjT/spD+i83mbNmCFTU7euUW8k /JLFZ2S/vmAS/GhemJ3xFLumpFwhg2/RokUvc8aT2hUpSAlesVx52zDYMcv2kbeOUNuwnxgc ATgegUBApgwDTtLTGFRgo6mp2M+mS+o7mqS48pLFi8u3aeNmyS+YL7/U1IhVSnBKJjYr/ORT UgOKbn/iscfJKM1syeS9kkIzlCUI9nr64fBhQ/2VcJrEK1tabfG3jTBUAnCJVJz6sUwApilR 4BKiiXFFmrAKRNCu3YapK3FG3bp09atr6caGR+IRxX169ZZkNrw2m668efJs2fKyXK6ygHk0 WDn1ekg8GjV0uASb4pjIbUH0+EfPAZ0zsP8AS0OZ0qVkE/NVOQcrl9mZPWumNcjKMmTQYJEZ AjU8ZqMG9a1fJJ7UzoI8BF65pEXLlhL+Ofhoss3FP3V2xgscd0VAjl3mjCcv+nPLlrEcEHFY TpSd1OLibiz79jlq7lj7baLwGIrv1bM3/VBouaXdvmh4DKSOFu+2bUNx+qqVq7ZqFSGbyTGp pnUrSK9gwYKRyDp1Cn+iYDOO1iWTtSHs3iNKV96vbx85p7Foz+7dataoKREtD4fErOqJlyhW nJa4bes2iE28JOxdks98efJaDkaNGvXE4483btzIMCSEJPEwHouFyKahQ4fRgXfu3GV7ZgXB xpLwYlTWlyaNGotdAlUjOYkgkRlgop6XJJRJmtosV6xtWMECBUl+T6rAyNKlz9oysP2SY0aL c+gyZUqXkb1X2maZKsUZCi+kJ9u7UoNpBzQFYVDuiJNZj9q0aknM6g3oVLSUxzd7xi+TvI3i 5bYBuXiWeH96yM54xB2hd4WXdPPNN1svE9673KYYKdOR6E5WcTF1NnUkwPoNG3x1nkyzq0G1 dkchpSSDJFMe6cQJwOgXWeTi2CI2TFXv4t4OImL9RKa/3XvYF0kbPUdugxMnXCjVioOouDYi PfLWGzsjNKb5YZthtECpLIohyTnepvup0SF1vN5wkZa4RVJkmzSWHssERlq1ehWZaTCYnPSL IKbHjslFaYemE4MJedfd2rVUSrfWf1zL6Di9kYWGePdePDg902aS0SXq8ODBuKzfgWich9/y q0+cJ+aE/wkLJMPDa2Ud4WkwFXL1unVczTxqSWzqwSDdSD+GZ0rDjLH6CunwK65Oavq9P8T6 YbpLFsbzpq666ip/I8aTzJxp7rJlvGBbT/xRiVcqOWC0nD49Y2uXnAzaUXioxHCf5WSYlHM3 S9pkX7pwvs1bq1atK1aoGDaZqb2lKhFZ5jal2RkJocP55Eapw07tOXUkyeSkOvdSM9CkdpLl eVMHnDEJmR7CZE6yDObDxBLvz7NkIZuE1yLGw3+0TRj/8CYuN4l37gkK/rdIvr2/nyj38/Hj FHVxQ2SCeSNC3wXe9f6OMH23y2EGUhkvldEixvMRrHnfffflUMYLw34nDOR/a/ZjKGQiyoKa +n6P4b/1bOl+L9kMpDJeqmqZwXgIiKWFvSXHSbxLNkPpjtIz8F+YgYTxmFEEnYeqmj6nGc8p 9pYs0ehn3aikT6ZnID0D72kGbEmYMJPd3BmM5wvrlp8lin1PnaYbp2cgPQPnmAGyDlvhvdQ2 pyVeOEvuPfLII1xAmDA9m+kZSM/AxcwAbrKvo2GmyrqsqmbqDYDI2Dldk2a/i5n39LUf5RmA Z7jxxhs56pJ93bkkXvIblnMNZx9rJ6OLvR8P7Ed5HtPPnp6Bc89A7FuabadGZ7zyyiuFH2RR L8+L8ZJGPA0MnsQl9lXqPv1Jz0B6Bs46A5REbILr8N5ZpVwq4/1/9BckHFTJneYAAAAASUVO RK5CYII= --------------040304050606050206060108-- --------------030008080208010109030404--